On Wed, Apr 18, 2012 at 8:47 PM, Ross McKay <ro...@zeta.org.au> wrote: > On Wed, 18 Apr 2012 11:08:00 -0400, Jim Giner wrote: > >>He literally wants the "addresses" visible on the sight? [...] > > Yes, they want the addresses visible and clickable on the website. They > have contact forms, but they also want the email addresses (of their > scientists and other consultants) available to their clients. And they > want the addresses to be shielded against harvesting for spam.
Ob/Deobfuscation schemes that use javascript are a partial solution. Many spam harvesters are smart enough these days to know enough about decoding email addresses even obfuscated with javascript, with or without the mailto: scheme. Any that do obfuscation by substituting html entities for the characters are quite easily cracked. (Just appearance of a string of html entities is often enough to indicate there is something there to decode.) There is no 100% solution here. Coming up with clever ways to obfuscate the address on download, and deobfuscate it afterwards to display to the user will work for a while, however, the people writing spam harvesters are just as clever as we are. If the application is going to end up with email addresses displayed on the screen, some spam harvester is going to be able to get them. Even if you come up with a method that will stop them now, it won't stop them forever. > As I said, I don't like doing it this way, but the client gets what they > want after the options have been explained to them. They need to understand the options, but even more important, the risks of any solution, and of the concept as a whole. After you've presented the risks, and the lack of a 100% solution, if they still want to do something against their own policies, you have to decide if your liability in giving it to them is going to be a problem. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
