- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 21 Apr 2011 04:08:09 +0000 (UTC)
- To: Travis Leithead <Travis.Leithead@microsoft.com>
- cc: Adrian Bateman <adrianba@microsoft.com>, public-webapps <public-webapps@w3.org>
On Wed, 20 Apr 2011, Travis Leithead wrote: > > 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 What sites the user sees in his or her browser window depends entirely on the browser vendor's decisions here, it's a UI issue. There's no reason 3rdparty.com couldn't appear as well. Similarly, whether the same shared worker can actually be obtained by two unrelated iframes is also a decision the user agent has to make. FWIW, on the long term, I intend to add a feature wherein a page can open a shared worker cross-origin (assuming the other origin agrees) directly, without having to use iframes. There's a whole host of features that such a mechanism would enable which currently have to be done using the awkward iframe mechanism you describe. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 21 April 2011 04:08:33 UTC