On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Wed, Apr 20, 2011 at 12:47 PM, Travis Leithead > <travis.leith...@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
