(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 -Travis -----Original Message----- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Thursday, April 14, 2011 5:42 PM To: ext Jonas Sicking Cc: public-webapps Subject: Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21 On Apr/14/2011 6:39 PM, ext Jonas Sicking wrote: > On Thu, Apr 14, 2011 at 7:31 AM, Arthur Barstow<art.bars...@nokia.com> wrote: >> This is a Request for Comments for the March 10 Last Call Working >> Draft of Web Workers: >> >> http://www.w3.org/TR/2011/WD-workers-20110310/ >> >> If you have any comments, please send them to the following list by >> 21 April >> 2011 at the latest: > There are currently two bugs filed against the spec. Do these bugs > count as last call comments? > > http://bit.ly/fl2uSB > Yes, I think both of these bugs should be considered LC comments. (Bug 12067 was submitted between the Feb 12 "is Workers ready for LC?" query [1] and the Feb 28 CfC to publish the LC [2]. As such, it probably should have been considered before publishing the LC.) On March 9, Adrian submitted comments after the CfC closed and those comments should also be considered LC comments: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0877.html -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0536.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0696.html
