- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 20 Apr 2011 15:57:40 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- 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: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, 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. ~TJ
Received on Wednesday, 20 April 2011 22:58:28 UTC