- From: Thomas Roessler <tlr@w3.org>
- Date: Sat, 25 Sep 2010 20:08:25 +0200
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- Cc: Thomas Roessler <tlr@w3.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, "www-tag@w3.org" <www-tag@w3.org>
On 25 Sep 2010, at 17:03, Noah Mendelsohn wrote: > Maybe the "private browsing" modes of user agents should address some of these, e.g. by clearing DNS caches, or perhaps selectively obscuring the availability certain fonts, etc. > > Yes, it's an arms race, but that seems to be a business that "private browsing" is already in? > In designing the Web into an application platform, we've added more and more client capabilities and client state — that includes "innocuous" capabilities like HTTP caching or offline web applications, and it includes more deliberately Webapp-controlled state like cookies, local storage, and whatever Flash and Silverlight have to add to that mix. It has been going on for about fifteen years. We're now collectively waking up to the fact that this client side state can be used by web applications to track visitors — which is, of course, possible anyway for the large majority of all web users who never touch their browsers' default cookie settings. But still — there's a case to be made that using flash cookies and similar techniques to "get around" somebody disabling cookies is indeed a violation of privacy. After all, that person has taken active steps to not be tracked, and (some) web sites are actively violating that choice. That's bad. There are two questions, then: - What's the accountability for Web applications that engage these sorts of steps? What can user agents do to make these things more transparent? - What can browsers do to put effective anti-tracking technology in users' hands? The private browsing modes are a step in the right direction, as is the torbutton plugin (which combines UI for state isolation and IP anonymization through Tor). > Noah > > On 9/25/2010 10:55 AM, Bjoern Hoehrmann wrote: >> * Noah Mendelsohn wrote: >>> 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" >> >> Note that it primarily exploits various methods for data storage which >> are relative well known, but does not use much other information that >> browsers and popular plugins volunteer to web sites, which tend to be >> less well-known. The combination of fonts installed on my system for >> instance is almost certainly unique, and the list can be obtained using >> Flash, Silverlight, Java, and so on, and you can get reasonably close >> to obtaining it through probing well-known names through JavaScript. >> If it's not sufficiently unique, you can always exploit that I rarely >> clear the DNS caches between browser and tracking sites, or whatever >> else floats your boat. > >
Received on Saturday, 25 September 2010 18:08:37 UTC