As we reviewed the actions we [the UA] could take in a variety of scenarios, tying the connect-ability to the top-level domain was the most predictable for web authors.
IE9's privacy feature [1] blocks network requests to any domain on a user's "filter list" (Tracking Protection List) when the request is not from a top-level domain (e.g., "first party" domain). In the scenario we're concerned with (involving iframes), having multiple top-level domains involved with a privacy decision (due to shared workers) either interferes with the predictability of the API, or curtails the user's privacy (both of which are bad enough consequences that we cannot implement the spec as-is). Note that our proposed change (to associated shared worker connect-ability to the top-level domain) deliberately breaks scenarios where sub-frame components want to establish and share a connection. As Ian described, if this is a specific desired scenario for shared workers, we would also recommend a more formalized cross-origin shared worker model: On Wed 4/20/2011 9:08 PM, Ian Hickson wrote: >> 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. [1] http://blogs.msdn.com/b/ie/archive/2010/12/07/ie9-and-privacy-introducing-tracking-protection-v8.aspx -----Original Message----- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, April 20, 2011 6:55 PM To: Andrew Wilson Cc: Tab Atkins Jr.; Travis Leithead; Arthur Barstow; public-webapps-requ...@w3.org; Adrian Bateman; public-webapps Subject: Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21 On Wed, Apr 20, 2011 at 5:58 PM, Andrew Wilson <atwil...@google.com> wrote: > On Wed, Apr 20, 2011 at 4:05 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> That's why we're working on trying to fix fingerprinting. >> >> The point is that privacy is something that we're all working on >> trying to improve (right?), and the WebWorkers spec needs to be >> changed to aid with that. As far as I can see all that's needed is to >> say that a UA is allowed to not share a worker, and ideally point out >> that such sharing could be disabled when the frame-parent chain >> contains cross origin iframes. > > Thanks for the clarification, Jonas. So I'm concerned that a blanket > prohibition would break legitimate use cases (iframe-based widgets on > a page communicating with one another). Let's say we have the following: > Top Level Window - http://a.com > Iframe_one - http://b.com > iframe_two - http://b.com > Top Level Window - http://c.com > iframe_three - http://b.com > If iframe_one, two, and three all create the same shared worker, would > any sharing be allowed in the situation you propose? I would at least > want iframe_one and iframe_two to end up referencing a common > instance, even if privacy policy caused iframe_three to get a separate > instance because the top-level window was pointed at c.com instead of a.com. > This seems reasonable to me - I suspect that's what you (and Travis) > were suggesting, but I wasn't positive. Yes, on the surface it seems to me that this would be ok. Though given that it's a more complex solution than a simple blanket prohibition any time cross-site frames are involved, it's possible that I'm missing some privacy leak vector. / Jonas
