- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 20 Apr 2011 15:13:58 -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 12:54 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Wed, Apr 20, 2011 at 12:47 PM, Travis Leithead > <Travis.Leithead@microsoft.com> wrote: >> (This time before the deadline :) >> >> Microsoft has the following additional feedback for this Last Call of Web Workers. >> >> We are concerned about the privacy implications we discovered when reviewing the current web workers editor's draft in its treatment of shared workers [1]. Specifically, the spec as currently written allows for 3rd party content to use shared workers to connect and share (broker) information between top-level domains as well as make resource requests on behalf of all connections. For example, a user may visit a site "A.com" which hosts a 3rd party iframe of domain "3rdParty.com" which initially creates a shared worker. Then, the user (from a different page/window) opens a web site "B.com" which also hosts a 3rd party iframe of domain "3rdParty.com", which (per the spec text below, and as confirmed several browser's implementations) should be able to connect to the same shared worker. The end user only sees domains "A.com" and "B.com" in his or her browser window, but can have information collected about those pages by way of the third party connected shared worker. >> >> Here's the relevant spec text: >> >> SharedWorker constructor steps: >> 7.5. "If name is not the empty string and there exists a SharedWorkerGlobalScope object whose closing flag is false, whose name attribute is exactly equal to name, and whose location attribute represents an absolute URL with the same origin as scriptURL, then let worker global scope be that SharedWorkerGlobalScope object." >> >> Given our current position on privacy and privacy technologies in IE9 [2], we will not be able to implement shared workers as described above. >> >> We believe it is appropriate to limit the scenarios in which connections to existing shared workers are allowed. We propose that connections should only be established to existing shared workers when *top-level* domains match (rather than when the "location attribute represents an absolute URL with the same origin as scriptURL). By limiting sharing to top-level domains, privacy decisions can be made on behalf of the top-level page (from the user's point of view) with scoped impact to the functionality of the 3rd party iframe. >> >> [1] http://dev.w3.org/html5/workers/#shared-workers-and-the-sharedworker-interface >> [2] http://www.w3.org/2011/track-privacy/papers/microsoft-bateman.pdf > > 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? / Jonas
Received on Wednesday, 20 April 2011 22:14:55 UTC