However there are always exceptions to the rule, and I’m dealing with one now (which brought me here): Email-addresses posted in reactions by your visitors. These folks DO need to be protected against themselves. Except for bold people like ‘A Guy Who Uses Gmail’ maybe.

First, someone writes a “good obfuscation” program. Then, they blog about it to the world, make it into a downloadable plugin, or start selling it. Even a really clever obfuscation code, once slavishly copied by millions of web sites, will become worth the manpower and money for spammers to adjust their bots to intercept it.

If you are going to use JavaScript, at least put some effort in to make up your own completely unique code. Otherwise you are hanging the fruit lower than you need to.

And if you are one of the millions of developers who are fans of basic ROT13 email obfuscation, god help you.

I don’t see how “they can figure out how your code works by looking at it” is a reasonable argument against javascript-powered address obfuscation.

Well, it’s a reasonable argument because “encoding” an email with javascript is like sending a coded letter with the codebook in the same envelope. You are including the instructions on how to decode what you sent. As you point out (and I point out in my post), there are plenty of ways to interpret javascript on the server, and then simply read the resulting page. There’s no need for the spammer to “look at the code personally.”

Email aliasing is a cute idea, but what about the legit user who saves your alias in her address book, only to have her emails bounced later when you discard that address? Is your spam filter really so ineffective that you have to resort to this shell game to read your email?

@mark, I agree that “a mix of different things combined with some robust javascript algorithm,” plus a viable fallback for users with out js, plus a changing, time-based salting function…well, that’s likely to keep you spammer-free, for the most part. For now. I envy you for the time you have to put into all of this.

But you haven’t solved the problem that you still send spammers the codebook along with the code. Eventually, someone’s going to write programs to read what you’re sending them, and then your spaghetti-code, security-through-obscurity “encryption” will have to be revised. Surely this sort of pointless spy-vs-spy is not the best use we have for our time?

As I wrote in the original post, I’m not trying to throw the book at anyone here. Spam is a pain, I get it. And obfuscation can cut down on it. My points are that:

1. The common, text-based techniques are kind of stupid.
2. JS techniques can help, but they are by their nature both vulnerable and inelegant.
3. The future of the Web is in making things more machine-readable, not less. Munging is on the wrong side of history.

If your spam filter doesn’t work, by all means: do what you got to do. You’ll get no condemnation from me. But I’ve not heard anything yet to make me revise these three points.

“NEVER obfuscate” can’t be the solution – actually, its the problem.
Like Bobby said, a good obfuscation prevents 99% of all bots (and people behind it) to harvest your email.
simply because it needs manpower and money to manually adjust the bot to your algorithm.

of course something like “me at domain dot com” is stupid as hell. of course any parser in the world can translate hex-coded emails.
it has to be a mix of different things combined with some robust javascript algorithm and you are fine.
fallbacks for non js users included.
maybe even a changing algorithm (based on the time of day/month).

but NOT obfuscating is worse!

On a different note, is there some way to use raw IP addresses instead of URLs that could throw a bot scanning for “x”@”y”.”z” off balance without overly confusing a desirable emailer?

Another possibility is the use of email aliasing. Maintain a single account for which you keep the direct address secret. Create an alias on an email server and use that alias “au naturale” in your sites, forwarding messages sent to it on to your central account. When you start to get too much spam through that alias, create a new one and repeat. Is this a reasonable solution, or am I misunderstanding some easy-to-foil step in this process?

Finally, a comment: I notice you keep mentioning that even the most complex obfuscation methods are easily discovered and routed if someone just looks at the code. Well… since there are so many possibilities, any spammer (hell, any programmer) would be hard-pressed to write a bot that could break them all by automation. A spammer would have to look at the code personally for each potential address to be certain of even (I’m guessing) 50% success… why bother, when the spammer could just look at the email address directly as the browser renders it on the page? What I’m trying to say is, I don’t see how “they can figure out how your code works by looking at it” is a reasonable argument against javascript-powered address obfuscation. The goal of obfuscation is to necessitate a human individual’s involvement in the identification of your email address with minimal confusion to that individual… methinks a sophisticated javascript obfuscation method accomplishes that goal.

c.a.r.t.e.r@cartercole.com is the same as
carter.@cartercole.com is the same as
c.a.rter+spam@cartercole.com

so i can filter or send any form of my address to spam and know where it was harvested from

to get around this you could find addresses with gmail domain and remove everything after the + and the periods so its the clean version (unless the normal address has a period like carter.cole@dadada.com)

I also agree that, for the time being, Javascript-based obfuscation holds the most promise. It’s not a silver bullet, though, as I discuss in my post. The ATG product you mentioned (and sell on your site as a downloadable exe) is a good example. Let’s take a look at what ATG cranks out:

<script type="text/javascript">
function SLMEJMBF(A){
var S = String.fromCharCode(109,97,105,108,116,111,58,116,101,115,»
116,64,101,120,97,109,112,108,101,46,99,111,109);
A.href = S;
}
</script>
<a href="#" onmouseover="SLMEJMBF(this);" onfocus="SLMEJMBF(this);">mail example</a>


For starters, if the client has javascript disabled, it breaks completely. That means tough luck, NoScript user: no email for you. This isn’t an insurmountable problem, though; check out Philip Hutchison’s gracefully-degrading script, for example.

Second, the “encryption” you use is pretty trivial. You rely on Javascript’s “fromCharCode” method to read the munged address–so can the harvester. I added a simple function to my de-obfuscator demo to show how easy this is (it’s example 11).

If I can break this munge with a 10-line function in a few minutes, trust me: someone else already has. Granted, this gets a lot harder to beat if you get just a little trickier; for instance, you might try breaking the address down into 10 strings and then concatenate them out of order–now a simple regex isn’t enough.

But the basic problem hasn’t gone away: your server dishes out your unencrypted Javascript to anyone who wants it, no questions asked. That makes it a fundamentally bad place to put secrets.

Thanks for your comment, and good luck with ATG!