I know that it is not a new idea, but I woke up this morning thinking that I might be able to use some simple encryption algorithms to obfuscate email addresses on my website, so that it will not be easily recognisable by the spam bots. While there are quite a few sites on the Internet that detail complicated cryptography algorithms in Javascript, I put my bet on a simple one – rot13, and finger crossed that spam bots won’t be able to execute Javascript.
A few minutes of hack creates a rot13.js Javascript source file, and now here’s my email address: . Dig into the source reveals…
... here's my email address:
<script type="text/javascript">
Rot13.write('<n uers="znvygb:fpbggl@lnat.vq.nh">fpbggl@lnat.vq.nh</n>);
</script>
It writes both the mailto: and the email address using Javascript. I’ve now fixed my resume page, so that you can now click on my email address to send mail to me, but from spam bot point of view it is just some garbage.
Ops. Forget to mention that this trick might not work with many text-based web browsers like my favourite w3m.
Another way of protecting emails with javascript is this: http://www.jracademy.com/~jtucek/email/index.html
It is a 10-bit RSA implementation that hides your email from spambots, but allows you to send email while using javascript-supporting broswers.
That is certainly cool. RSA is certainly cool, and you got to keep the private key so that it will take some “effort” even for a human to decrypt it. That’s certainly the direction that spambot harvest prevention should move to.
Thanks for the link.
I don’t get it. Why go to the trouble of RSA encryption for the email address? Any encryption will do; even shifting each letter by one.
It’s just as hard for the harvester to decrypt simple letter-shifting as the RSA method, since in both cases all it needs to do is execute the JavaScript. I can tell you which implementation is shorter…
While thinking of a way to make an email address unreadable/unusable for spam bots, I just had that same idea – why not use ROT13? Well, you’re half a year ahead, but I think the idea is still pretty cool. :-)
Fantastic! Just what I was looking for. Thanks.
Good thing I put up a fake address for the bots — your mini BBS doesn’t Rot13 our email addresses!!! (0_0)! (^_-)
What about a simple substitution like
myaddress&msn.com with the underlying html having the real mailto:myaddress@msn.com
But the problem with this is that if a person doesn’t have a java script supported browser they can’t see your email, correct?
Was thinking the other day, of generating web pages, with dynamic names, containing a list of dynamically generated email address… *hey, spammers uses dynamically generated email address right ?* with links to similar pages… I wonder if spam bots will run out of space ?
Well, just another way to discourage spammers from traversing your sites… rather than protecting by encrypting, generating false ones… that way they’ll have trouble determining the real from the fake ones…
Oh… hide it from human readers… *by camouflaging the link*
This doesn’t deter spam bot harvesting as the last part of your email (edu, com, org, …) is a key to showing how it was encrypted. It would be trivial (and guaranteed) for the spammer to detect rot13 and “unlock” the address. A better way is to use a key to the encryption process, that your website provides. Then, at least your email address will not be easily crackable.
And, also, you may not want to display the email address (even write it to the page), since a text-based javascript-aware app could still get to it. Better to do the decryption dynamically when a link is clicked.
My .02
nice way to protect users and yourself from spam. Interesting. thanks for the tips.
I was thinking this would be a great way to obfusicate an e-mail address, until I saw reply #10. As I’ve been looking at ROT13, I’ve come across a PERL script for detecting if text is in ROT13. It’s based on the fact that the most common letters are “e”, “s” and “t”, etc. (“r”, “f” and “g” in ROT13, respectively). So, if you have a lot of e’s, s’s and t’s, you have text, but if you have a lot of r’s, f’s and g’s, then you have ROT13.
Not fool proof, but should be pretty effective. No reason a spambot couldn’t do that. But would it?
The question is, is protecting your e-mail address with ROT13 common enough that spambots are even going to be built to bother? After all, the point of a spambot is to gather in an automated fashion, right? Is there a human being looking over the addresses and throwing out the “bad” ones? I think not. I think they just send to the bad addresses anyway. If an address nets a bounce message, does a human look at it or does it just get removed (or do they just keep spamming it anyway)? If spambots were to take ROT13 into account, then why not just ROT13 all the addresses send to both the original and ROT13 versions, and who cares if they bounce? Or take the address, ROT13 it, see which domain name (the orginal or ROT13) has a DNS MX record, and add that one to your list.
I’m doubtful that a spambot will run javascript, but I’m even more doubtful that it would run a cgi-bin program through a FORM. I’m kind of looking for an HTML form that I can put on a web page that will run a cgi-bin script to decode the ROT13.
Of course, you aren’t tied to ROT13. Nothing wrong with ROT12 (it’s just that unlike ROT13, encoding and decoding aren’t inverse operations). Nothing wrong with a rotating cypher that includes special characters like “@” (and not just A-Z like ROT13 does). If you really want some security, you might have to “roll your own” cypher. If everyone made there own cypher, it would be impractical for spammers to even try decyphering any of them.
(I wonder how many spammers are reading this getting ideas).
Another idea is to take your address, fire up a graphics editor (like say MS-Paint), create a graphics file (GIF, JPEG, PNG, etc.). Graphics editors will allow you to add “text” to the graphic. Your spambot would have to do OCR to get the text out (and that is a pretty expensive operation to do on the *chance* that a graphic contains an e-mail address – it isn’t going to happen). The downside of this approach is that people have to retype the address (whereas if you provide a means to decode the ROT13, someone could copy & paste the address). Of course, these aren’t mutually exclusive. You could put a Javascript ROT13 translater on your page along with a graphic with your ROT13 encoded address in the graphic. Overkill? :-)
Just let me conclude the discussion so far. It has been more than a year since I wrote this blog entry, and my conclusion is – don’t bother. As comment #10 and #12 has pointed out, it is easy for the harvester to figure out whether the encoded message is Rot13.
To solve that, you can use more complicated encryption algorithm. However, at the end it is just meaningless.
All you need is just once instance of your email address being harvested by the spambot, be that on your blogsite, mailing list archives, your friends’ sites, websites that you have registered to that do not protect address, your contacts’ virus infected addressbook, etc. All the spammers need is just one copy of that, and immediately your address is sold – on CD-ROMs supplied to all the spammers around the world.
That’s how I concluded that it is all meaningless. There is always the weakest link – so why work so hard to have it protected?
Instead, more time needs to be invested into spam filtering, using SpamAssassin or things similar. That is more effective to combat spam, than encrypting your email address using 512bit AES or whatever.
This Mailto Harvesting Experiment is one datapoint that indicates that the harvesters don’t do javascript processing.
Even more interesting is that he received no spam for a plain text “username AT example DOT com” for obfuscation.
If that is true you could just use a javascript using write.document of the href with something like ‘mail’ + ‘to:user’ + ‘name’ + String.fromCharCode(64) + ‘example.c’ + ‘om’ instead of writing a separate function to do any encoding, even ROT13, and use a noscript clause that has in plain text username AT example DOT com for the few people who don’t have javascript.
Why don’t you just create a submit form that populates a database, rather than emailing you the comment? Then when you decide that you have a legitimate contact, you can send them your email address.
On my website I’m using this and it seems really good. But I wasn’t happy that people eithout javascript couldn’t read it at all. eg screen readers or lynx.
So here’s my solution: have the
Rot13.write(‘hi’);
Then put
A link free readable obfuscation like: mail to: foobar At this domain
This seems to me like a good way to do it because it complies well enough to w3m and is easy for people with decent browsers.
Sorry in the last comment I placed (script language=”JavaScript”)(/script) elements around the rot13 bit and (noscript)(\noscript) around the link free bit. This makes it so that if you do have javascript, only the working one works and you don’t see the mail to: foobar At this domain at all.
I still believe obfuscation is somewhat effective at preventing spam. However, if I was writing a harvester program, I would base it on a browser object that can deal with Javascript (eg an embedded Internet Explorer object). This isn’t hard to do, and by doing this it would break ANY javascript based encoding – either ROT13 or something key based, it wouldn’t matter.
You also have hex encoding, which is trivial to break and in my opinion worthless.
Image based encryption – more difficult to break, but less usable.
You also have “harvey at this domain name” as a fairly secure method.
Or force the user to enter a captcha before they can see the plaintext email.
None of these options are ideal, but I still do the Javascript encoding – it will keep the script kiddies out at least.
I have JavaScript mailto obfuscation using concatenation of exploded components which hides the address string from the spambots. Spambots are unlikely to have JavaScript capabilities as this would increase the already huge length of time it takes them to spider. The fact that there are so many easy targets out there ensures this method remains effective.
As a fall back for people who have no JavaScript I include noscript tags containing an image version of the address so humans can always see the address. Having ‘rich AT domain DOT com’ as alt text ensured no-one is left out.
For Mac OS X users it is surely more convenient to manually use (copy-paste) a Dashboard widget called obfuscatr. It provides JavaScript or just plain hexadecimal encoding of your email addy. obfuscatr output is also a lot more complex (and therefore safer) than the one proposed above.
See the details at flash tekkie.
obfuscatr was also featured in MacWorld Italy of March 2008.
Pingback: 13 tips for hiding e-mail addresses from the spammers « PCStuffBlog.com