>> :-) The way I had thunk it, it would need to be both unique and
>> reversable. The confirm/reveal script would decode it to figure out
>> what email address to show to the user. Gotta be deterministic on the
>> decode, you see. At least for the first part, anyway.
>
> No good. Someone WILL crack the code eventually and then spam away.
No, it is trivial to make it so computationally expensive to crack it
that spammers won't bother trying. Even using 56-bit DES would suffice.
However, the decryption must take place on the server side, not on the
client in Javascript, or the key will be available to the attacker.
If I understand the original proposal, it was to replace email addresses
on the web pages with links of the form
http://site/cgi_form?id=encrypted_email_address
The user would click the link, and the CGI script on the server would
first verify that it thinks the user is a person, not a robot, then
decrypt the email address and return the cleartext.
Assuming that the encryption is done properly, the weakest point in the
system is the test for robots (harvesters). That's the point that
spammers would attack, if they could be bothered to try. As long as
that test looks like it would take some work to defeat, I doubt that
spammers would bother. There's plenty of other low-hanging fruit on
the web for them to harvest. They're willing to spend time improving
harvesting tools for things that aren't too difficult, or would return
a large number of valid email addresses, but this would be difficult
for a small return, so they're unlikely to mess with it.
Received on Sat Dec 07 2002 - 13:27:58 GMT