Currently I am a student software engineer for the University of California Irvine where I build web tools for the for the student portal, ZotPortal.  If you aren’t too sure of what a web portal is, think iGoogle – lots of different content pieces on one page.  These content pieces are called portlets and I design, engineer, and maintain them on ZotPortal. I want to talk about two different things in this post, 1) a portlet I designed that enables people to search for on campus organizations at UCI and 2) some different ways of obfuscating email addresses (or other data) from potential scrappers/spammers. The connection will become apparent later.

The Campus Organizations Portlet was the first portlet I built. The idea was simple enough: given a feed of all the campus organizations, parse out the data, and display all the organization information in a searchable UI. There are currently around 540 different organizations to show, so the data needed to be broken up into separate pages.  I decided to use the Fluid Pager javascript component to page through the data without having to reload the page. This enables us to place each organization in its row along with its info box and category. The gapped paging scheme makes navigating through the pages a breeze without cluttering the pager bar. Some more javascript was added for to display organization info and the search bar to re-render the pager with just the search results.

Now, on each organization’s information panel we supplied a mailing address so a user could contact the club leaders. And since this portlet is accessible from the guest view, there is potential for spam bots to troll through our student portal and collect all of the club email addresses to sell or send spam to. I wanted to hide the email addresses from the spammers while at the same time enable the viewer to use the email. So, I spelled out the symbols in the email to confuse any would-be spam bots reading through my portlet data. Instead of coolclub@uci.edu, coolclub[at][you see eye][period]edu. An average spam bot wouldn’t recognize this as an email address, spam avoided! The only thing that bothers me with this approach is the fact that the user has to do the work of replacing [at][you see eye][period] with”@uci.”. Sure, it isn’t very difficult or time consuming, but it would be a lot better if the user could simply copy/paste or click a mailto tag.

I found someone in a similar dilemma and a really good answer was provided to him.  Examining these different methods of obfuscation allows us to pick the best one for our situation.

1. CSS direction
   • Code
     • <span style="unicode-bidi: bidi-override; direction: rtl;">moc.elpmaxe@zyx</span>
   • Renders as
     • xyz@example.com
2. CSS display
   • Code
     • xyz<span style="display: none;">foo</span>@example.com
   • Renders as
     • xyz@example.com
3. ROT13 encryption
   • Code
     • <script>var email = decodeROT13(klm@rknzcyr.pbz); emailElement.append(email);</script>
   • Renders as
     • xyz@example.com
4. Using ATs and DOTs
   • Renders as
     • xyz[AT]example[DOT]com
5. Building with javascript
   • Code
     • <script>var email = 'xyz'; m += '@'; m+= 'example.com'; emailElement.append(email);</script>
   • Renders as
     • xyz@example.com
6. Replacing ‘@’ and ‘.’ with entities
   • Code
     • xyz@example.com
   • Renders as
     • xyz@example.com
7. Comment splitting
   • Code
     • xyz<!-- eat this spammer -->@<!-- ha ha -->example.com
   • Renders as
     • xyz@example.com
8. Urlencode
   • Code
     • xyz%40example.com
   • Renders as
     • xyz@example.com
9. Plaintext
   • Renders as
     • xyz@example.com

The author of this study (credit to Silvan Mühlemann; his original post can be found here) even watched each of these methods for over a year just to see the different amounts of spam each strategy would receive.  These were his findings…

The current obfuscating strategy I use received the lowest amount of spam out of the ones that got spam in this study.  However, there are better strategies, with zero spam, that don’t require any work from the user (strategies 1-3).  So, I should change the strategy for obscuring the organization email in the portlet since there doesn’t seem to be any cost Late February 2011, we changed the obfuscating method and decided to use CSS direction.  We still are looking into a combination approach with CSS direction for display and javascript building for a mailto link for better and easier interaction.