Do you recall any details about this program? Like what type of enciphering did you do, that the program broke?

Don’t get me wrong, I know this is a cat & mouse game, and I certainly do not consider this method anywhere near unbreakable. I can just report that:

1. Based on a test I did, entity-encoded emails are safe from harvesters
2. I get no spam to the addresses listed (and enciphered) on these page.

So the cat (harvester) is not too concerned with winning the game (likely because there is far to much low-hanging fruit out there).

But even if the cat awakes, I am pretty optimistic, since legitimate use of email addresses will always be done by a human, and no script can fully mimic a human.

The question is how do we make the least obtrusive turing test?

Two ideas I am presently pondering is:

1. Use XMLHttpRequest both to fetch the valid address, but also (as a trap) blacklist the client’s IP (or feed it bad data) — a script is likely to follow the wrong path, for a human, use of CSS can make that near impossible.
2. Use DOM events, e.g. check that mouseEnter was actually called for the link clicked — we could require more intricate “gestures” to be performed.

I have some concerns though about a) making it easy to automatically obfuscate a page (so requiring server support for XMLHttpRequest is maybe not ideal) and b) still support browsers w/o JavaScript, non-mouse users, etc. One solution to that problem though could be, to always provide challenge/response protected email addresses by default, and then have JavaScript alter them to non-protected addresses, when the turing test has determined the page is viewed by a human.

If this method works for you: great, but don't be surprised if one day you'll find that you name is on the spam lists.

Meanwhile I can report that I receive zero spam for the JavaScript-obfuscated addresses published at this site (and they have been here for quite some time).

Based on a previous test I did it seems majority of harvesting bots doesn’t even entity-decode pages fetched.

So what are you basing your comment on Bob?

Running a simple regular expression on the input will always be many times more efficient, in terms of email addresses harvested/time, than running the javascript on the page.

If this method becomes common enough and computers fast enough to make running the javascript worth it, the code can always be made more complex, to make the decoding of email addresses slower.