[Bug 13373] Privacy: Limit SharedWorker connections to same top-level domain

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