Every once in a while it comes up again. JavaScript – used totally wrong. This times it’s Hivelogic’s “Enkoder” script reborn for Wordpress. What people just don’t get is: JavaScript was never meant to be used as a heavy cavalry, a knight in shining armor, or else a bit of code that can may be used to do anything – because it’s not.
JavaScript can do a lot of things, but that doesn’t mean it should be used that way. But that’s not the problem – not this time. The problem is that people are still insisting on believing that using JavaScript to hide text means that the bad guys won’t ever see it. But that’s just not true.
For one thing, as we all know, the weapons reach the bad guys first, and it takes a long time for the “good guys” to get them later. Just because GoogleBot and Yahoo! Crawler don’t exactly understand JS-rendered text, doesn’t mean that the spam bots, email harvesters, blog spammers, and more don’t. As a matter of fact, more spam bots come to NeoSmart Technologies with javascript enabled engines than authentic users with JS enabled browsers (stats thanks to SpamKarma 2) – and they’re on your site too.
Just like people insist on writing their emails as ramblings [at] neosmart dot net
or one of it’s variations, and it never occurs to them that spambots can harvest these just as well as they can ComputerGuru@NeoSmart.net
with or without the mailto: entity defined, it just doesn’t matter. It takes the code masters over at HiveLogic a month or more to write such a complicated algorithm, but it takes spam bot and email harvester authors mere hours to add JS processing to their engines – and all of a sudden everyone is vulnerable.
There really is no good way to prevent an email address from being listed in spam directories and sold in bulk along with thousands of others to spammers around the web – especially not image renders of email addresses, OCR is actually a rather practical method once combined with baesian filters to identify a likely email-in-image target. The best thing one can do is to sign up for a good email service if you use free webmail (don’t use AOL, Hotmail, Walla, WowMail, SpyMac, or most others; use Yahoo!, Live.com, or GMail if you have to), or if you have your own MX server, invest in a quality spam-control engine (don’t use BrightMail or anything else Symantec!). If it’s too late to change whatever it is that you picked or your email address is all over the web such that it doesn’t make a difference, get a decent client-side program instead (reviews to come!).
Remember, you can never beat them completely, just do your best to bat them away. Using disposable email addresses helps, but it’s not the best way since spammers will send messages to random email addresses and bookmark those that don’t bounce back – you really can’t win outright, just keep trying.
However (and this is important!) Hivelogic deserves recognition for their algorithm. I personally used it the month it went public (3 or 4 years ago?), and it was a great idea, the innovation is there, and it definitely worked for a couple of years, but times change and technology swarms and grows, and nothing lasts forever. If you really want security via obsecurity, then this is your award-winning horse that’ll take you quite far, but remember, no one is perfect, and nothing lasts forever.
I mostly agree with you: any “protection” script just makes the e-mail harvesting slightly less easy. With the current Javascript engines at hand, there’s little you can do to protect your address. The only real protection is on the (e-mail) server side.
For example, go to the Enkoder’s author contact page (“Enkoder protected” :P):
http://hivelogic.com/contact
and write this in the address bar:
javascript:alert(document.getElementsByTagName("a")[2].href)
And that’s not counting on someone not liking you and spreading your address everywhere 😛
So, unless you just want to avoid the naïve e-mail harvesters (perfectly valid option), forget about e-mail protection (not only javascript-based).
Code fixed by NST – caused by XSS protection
I’ve posted a small response to your post on Weaselhat, the home of PHPEnkoder. I think you’re mostly right that client-side hiding is infeasible, but I also feel you should take a closer look at some of the options and possibilities.