- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 20 Apr 2011 16:05:15 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Travis Leithead <Travis.Leithead@microsoft.com>, Arthur Barstow <art.barstow@nokia.com>, "public-webapps-request@w3.org" <public-webapps-request@w3.org>, Adrian Bateman <adrianba@microsoft.com>, public-webapps <public-webapps@w3.org>
On Wed, Apr 20, 2011 at 3:57 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Wed, Apr 20, 2011 at 3:41 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> On Wed, Apr 20, 2011 at 3:19 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >>> On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking <jonas@sicking.cc> wrote: >>>> On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >>>>> Please correct me if I'm missing something, but I don't see any new >>>>> privacy-leak vectors here. Without Shared Workers, 3rdparty.com can >>>>> just hold open a communication channel to its server and shuttle >>>>> information between the iframes on A.com and B.com that way. >>>> >>>> Not if the user disables third-party cookies (or cookies completely), right? >>> >>> No, what I described is independent of cookies. You just have to use >>> basic long-polling techniques, so the iframe on A.com sends a message >>> to the server, and the server then passes that message to the iframe >>> on B.com. >> >> But how does the server know to pair the two incoming connections and >> forward data between them? If 50 users visit these sites, all the >> server sees is 100 incoming connections with no idea which are coming >> from the same user. > > True, you need some side-channel to link the two iframes for a > particular client. You can use something simple like one of the > *other* within-domain communication mediums (cookies, localStorage, > etc.) to share a uniqueid, Yes, that's why those features needs to be similarly isolated when 3rd party cookies are disabled to be truly effective. > or you can just pull information out of the > client, which the two windows are likely to share, and use that as the > identifier. We already know that you can fingerprint a larger > percentage of users with only a handful of information sources > available to JS. That's why we're working on trying to fix fingerprinting. The point is that privacy is something that we're all working on trying to improve (right?), and the WebWorkers spec needs to be changed to aid with that. As far as I can see all that's needed is to say that a UA is allowed to not share a worker, and ideally point out that such sharing could be disabled when the frame-parent chain contains cross origin iframes. Which reminds me that I need to add a similar note to IndexedDB. Firefox 4 completely disables use of IndexedDB in iframes which has cross origin frame ancestors. I know we talked about this with the chrome folks, but I don't remember what they ended up doing in this regard. / Jonas
Received on Wednesday, 20 April 2011 23:06:14 UTC