Douglas Mayle wrote:
> Not to mention the fact that a javascript solution doesn't function in 
> script free environments...  Accessibility, and all that...

Accessibility for what?  Accessible browsers also run Javascript.  From 
what I can tell this whole no-javascript==accessibility meme is based on 
nothing.  Certainly it's far more accessible than a captcha.

Google bots don't run Javascript, but of course that's exactly who we 
want to hide this from.

   Ian

the method proposed in the alistapart
article<http://www.alistapart.com/articles/gracefulemailobfuscation>chris
linked to addresses many of these concerns. could we do something like
this?
On Fri, May 16, 2008 at 1:53 PM, Douglas Mayle <douglas@...>
wrote:

> Not to mention the fact that a javascript solution doesn't function in
> script free environments...  Accessibility, and all that...
>
>
>
> On May 16, 2008, at 12:17 PM, Ian Bicking wrote:
>
>  Chris Abraham wrote:
>>
>>> Hi,
>>> Recently we had a complaint from a user that email addresses were being
>>> exposed in the listen archives.  So I have now rigged in an obfuscation
>>> function in listen that will obfuscate addresses in the from, subject and
>>> body of messages for display purposes.  We now have to decide how we want to
>>> obfuscate.  What's the best way to do it for the least amount of trouble.
>>>  I've read up on encoding methods, replace('@', '<at>') methods, javascript
>>> methods and the google "cabra...@..." method (in which the ...
>>> is a link to a captcha).  I think the google method is probably the best but
>>> it is a bit of a pain to implement and requires a captcha engine.  So, any
>>> votes?  See http://www.alistapart.com/articles/gracefulemailobfuscation for
>>> a good overview of the various options.
>>>
>>
>> I think there actually exists a CAPTCHA service for this, where the user
>> clicks through with an encrypted link.  But I can't remember the name of it.
>>
>> Otherwise I would prefer Javascript obfuscation, where you use
>> document.write to write out the email.  I think there's a more advanced
>> version that actually encrypts it, and requires some effort to decrypt
>> (which only happens if you actually click on the email).  OTOH, things that
>> take "some effort" in Javascript take little effort in C, but a little
>> obfuscation would add to that.  Also, I don't know what the state of the art
>> in email scraping is, but it's quite possible that there are browser-based
>> bots that can execute Javascript.
>>
>>  Ian
>>
>

Attachments

text.html (text/html) 2.8 kB

So we have several places on openplans.org where emails are exposed:
1) listen list addresses on the list summary pages
2) list posts by nonmembers of the site shown on list archive pages  
and on the messages themselves
3) when included in the body of list messages shown on the message views
4) when included in the subject lines of messages show in several places
5) wiki pages, blog content, etc.

And to deal with these, I suggest for:
1) we should obfuscate these in listen using an overridable method.   
Currently I will implement a javascript solution which can be  
accompanied by a captcha for non-js people.  The captcha part doesn't  
need to be implemented by us, at least not right now.
2) we can just show the part of the email address leading up to the  
@.  So a list post by nonmember "cabraham@..." will show as  
being from "cabraham@...", from "Chris Abraham  
<cabraham@...>" will be from "Chris Abraham".  This should  
be sufficient to identify who sent the message.  We will not need any  
deobfuscation since we don't currently provide any way for anyone to  
access a member's email address and can maintain this standard for  
nonmembers.
3) same as (1)
4) same as (1)
5) we can consider tackling these in the future

Sound okay to everyone?
Chris



On May 24, 2008, at 2:22 PM, Ethan Jucovy wrote:

> On Fri, May 16, 2008 at 12:17 PM, Ian Bicking <ianb@...>  
> wrote:
>> Chris Abraham wrote:
>>>
>>> Hi,
>>> Recently we had a complaint from a user that email addresses were  
>>> being
>>> exposed in the listen archives.  So I have now rigged in an  
>>> obfuscation
>>> function in listen that will obfuscate addresses in the from,  
>>> subject and
>>> body of messages for display purposes.  We now have to decide how  
>>> we want to
>>> obfuscate.  What's the best way to do it for the least amount of  
>>> trouble.
>>>  I've read up on encoding methods, replace('@', '<at>') methods,  
>>> javascript
>>> methods and the google "cabra...@..." method (in which  
>>> the ... is
>>> a link to a captcha).  I think the google method is probably the  
>>> best but it
>>> is a bit of a pain to implement and requires a captcha engine.   
>>> So, any
>>> votes?  See http://www.alistapart.com/articles/ 
>>> gracefulemailobfuscation for
>>> a good overview of the various options.
>>
>> I think there actually exists a CAPTCHA service for this, where  
>> the user
>> clicks through with an encrypted link.  But I can't remember the  
>> name of it.
>>
>> Otherwise I would prefer Javascript obfuscation, where you use
>> document.write to write out the email.  I think there's a more  
>> advanced
>> version that actually encrypts it, and requires some effort to  
>> decrypt
>> (which only happens if you actually click on the email).  OTOH,  
>> things that
>> take "some effort" in Javascript take little effort in C, but a  
>> little
>> obfuscation would add to that.  Also, I don't know what the state  
>> of the art
>> in email scraping is, but it's quite possible that there are  
>> browser-based
>> bots that can execute Javascript.
>
> The only concern I have with Javascript obfuscation is that Plone
> tends to try very hard to have full functionality without Javascript,
> so it might be frowned upon in the community regardless of its merits.
>  Chris, I'd drop a note on the Listen developers' list and see what
> the consensus is there.
>
> I think OpenPlans will need to override whatever is built in to
> "vanilla Listen," though, if that solution makes email addresses
> viewable even to non-robots.  OpenPlans.org at least tries to have a
> policy of hiding all email addresses (or at least claims to, on the
> "Create an account" page) so I think there we'll need to do something
> more like the Google obfuscation method ("cabraham@..." -- but without
> the CAPTCHA link to see the full address at all) if we're going to be
> displaying anything informative.  So please make the obfuscating code
> (whatever ends up being decided upon) overrideable, whether as a
> utility or just as a method on a view that we as consumers of Listen
> can subclass to replace that one method.
>
> egj
>
> !DSPAM:4017,48385cf4156261431913854!
>