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

Reply via email to