Re: Evercookie: Indestructible cookies

You are confirming my intuition that this is very troubling, if not 
entirely surprising.  I think it spans the work that Ashok is doing on 
client-side storage, and the work you are driving DanA on privacy.

I'm tempted to suggest that we devote some time at the F2F to this 
particular constellation of concerns:  I.e. how the various client-side 
state capabilities of user agents can be used together to thwart the user's 
ability to control identity tracking, other privacy concerns etc.

What's less clear to me is how to frame this.  I think the best use of F2F 
time is if one or two TAG members work on this actively during the coming 
few weeks, with the goal of having the facts gathered and the issues well 
framed by the time we meet. I know Ashok is traveling for a couple of weeks.

DanA, do you have the time and interest to take the lead.  If not, anyone 
else?

If any TAG members feel this is a bad use of time, speak up, or I'll just 
move ahead.  Maybe we'll slip a bit of discussion into today's call if it 
fits.  Thank you!

Noah

On 9/23/2010 8:05 AM, Appelquist, Daniel, VF-Group wrote:
> This is diabolical. It should be a wake-up call to us on Web privacy.
>
> Considering that many of the options listed are ³part of HTML5,² Iım most
> worried that HTML5 could become associated with a lack of privacy. If
> anything, the reverse should be true: we (w3c&  web standards community)
> should work to ensure that the HTML5 ³brand² stands for _enhanced_ privacy.
>
> Dan
>
> On 22/09/2010 09:49, "Noah Mendelsohn"<nrm@arcanedomain.com>  wrote:
>
>> Following up on [1], I note this [2]:
>>
>> "    evercookie is a javascript API available that produces
>>       extremely persistent cookies in a browser. Its goal
>>       is to identify a client even after they've removed standard
>>       cookies, Flash cookies (Local Shared Objects or LSOs), and
>>       others.
>>
>>       evercookie accomplishes this by storing the cookie data in
>>       several types of storage mechanisms that are available on
>>       the local browser. Additionally, if evercookie has found the
>>       user has removed any of the types of cookies in question, it
>>       recreates them using each mechanism available.
>>
>>       Specifically, when creating a new cookie, it uses the
>>       following storage mechanisms when available:
>>        - Standard HTTP Cookies
>>        - Local Shared Objects (Flash Cookies)
>>        - Storing cookies in RGB values of auto-generated, force-cached
>>           PNGs using HTML5 Canvas tag to read pixels (cookies) back out
>>        - Storing cookies in Web History (seriously. see FAQ)
>>        - HTML5 Session Storage
>>        - HTML5 Local Storage
>>        - HTML5 Global Storage
>>        - HTML5 Database Storage via SQLite"
>>
>> Noah
>>
>>
>> [1] http://lists.w3.org/Archives/Public/www-tag/2010Sep/0029.html
>> [2] http://samy.pl/evercookie/
>>
>>

Received on Thursday, 23 September 2010 13:29:44 UTC