- From: <bugzilla@jessica.w3.org>
- Date: Fri, 19 Aug 2011 22:46:32 +0000
- To: public-webapps@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13373 Travis Leithead [MSFT] <travil@microsoft.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|NEEDSINFO | --- Comment #2 from Travis Leithead [MSFT] <travil@microsoft.com> 2011-08-19 22:46:31 UTC --- It's not so much an expected leak, as it is an "unexpected" privacy leak. Let me try to explain... What I don't want to have happen is an unexpected sharing of a SharedWorker where the document doesn't "opt-in". This is what would happen if an implementation decided that two frames were in the "same unit of related browsing contexts" yet those frames did not share a common top-level browsing context. Today, using cross-document messaging [1], there is an implied opt-in, as the sender can be selective about the domain of the reciever, and the receiever can validate the origin domain. Two sites must be rather explicit when they wish to share data. Yet, it is possible... As you mention: >> (Of course, if they can communicate -- e.g. by passing ports >> along a chain of shared workers and iframes each step of >> which is allowed, even thought the first and last >> participants are blocked from seeing each other >> normally -- then that's non-conforming.) In the scenario I describe in Comment 0, it _is possible_ to bridge a SharedWorker shared by Iframe_one and Iframe_two to Iframe_three by: 1. Iframe_one (b.com) gets a reference to Top Level Window (a.com) and sends it a port to the SharedWorker (the one shared by Iframe_one and Iframe_two) via postMessage. This is cross-domain but allowed if both sides are willing. 2. Top Level Window (a.com) gets a reference to Top Level Window (c.com) via window.open(), and sends the SharedWorker port. (Again this is cross-domain.) 3. Top Level Window (c.com) has previously loaded Iframe_three (b.com), obtains its window, and sends it the SharedWorker port. 4. IFrame_three (b.com) now has a reference to the SharedWorker shared by Iframe_one and Iframe_two. The takeaway is that through the above steps, the sites in the different domains (b.com/a.com/c.com) took explicit steps to "accept" the port and pass it on. It was deliberate--in a sense they "opted in". If Iframe_three was simply automatically connected to the same SharedWorker as Iframe_one and Iframe_two, I'd be concerned--that's what I'm trying to avoid. Regarding implementor conformance: It sounds like you are saying that as an implementor, I am free to define that when two frames are not in a "unit of related browing contexts" (which I will define as a "tab" for illustrative purposes), then they don't need to connect to the same SharedWorker instance (even if they share the same domain and other criteria as specified in [2]). As a browser user agent, I might allow the round-about scenario described above (because there is an opt-in path), but disallow the case where the frames are trying a connection from different "tabs." If such a behavior is conforming per this specification, then I guess I don't have any further concern. [1] http://dev.w3.org/html5/postmsg/#web-messaging [2] http://dev.w3.org/html5/workers/#shared-workers-and-the-sharedworker-interface -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Friday, 19 August 2011 22:46:37 UTC