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. `._.-(,_..'--(,_..'`-.;.'