On Wed, Apr 20, 2011 at 3:41 PM, Jonas Sicking <[email protected]> wrote: > On Wed, Apr 20, 2011 at 3:19 PM, Tab Atkins Jr. <[email protected]> wrote: >> On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking <[email protected]> wrote: >>> On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. <[email protected]> >>> 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
