Thanks for this post. I wonder how soon we see universities adopting the altmetrics you mention? I’m having a hard time imagining it.

That is a great infographic. Quite informative and attractive. Thanks for sharing this.

I am visiting the websites of the @scio12 attendees, saying “Hi” and giving a shoutout on twitter! I look forward to seeing you there in January!

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!