How would this protect user privacy? What's the expected leak here?

As far as I can tell, SharedWorkers do not introduce a communication channel that isn't already possible with any number of other features, e.g. IndexDB, Web Storage, XHR, cookies, fingerprinting, walking Window hierarchies, etc.

In any case, it's up to the UA to define the scope of "user agent" — so long as two frames aren't in the same unit of related browsing contexts, there's not much the spec can say that would force the UA to treat the two frames as related. Just make sure they really are separate and can never communicate, and you're fine. (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.)

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

(In reply to comment #2)
> 
> 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.

If they can communicate indirectly, then they should be able to open a shared worker. That's the entire point of the shared worker feature.


With what you propose, there would be no way for sites to provide shared services. For example, imagine if example.com provided a dictionary (spelling checking) service, and facebook.com and plus.google.com both wanted to be able to use that service. So that example.com uses only minimal resources on each user's machine (it expects to be used by many sites), it uses a shared worker to communicate back to its server. Both facebook.com and plus.google.com open an iframe to example.com and that iframe then opens the shared worker. The sites can then check spelling by communicating to a port vended from the worker through the iframe to the sites, and all the checking happens in the one worker.

If we did what you suggested, this would not be possible. Indeed, either example.com would have to run multiple copies of the spelling checker service (wasting user resources), or it would have to open a top-level window to open the shared worker (which would mean highly annoying popups).

Since your proposal does not improve privacy in any material way, and harms legitimate use cases, I do not think it makes sense.

I think the point is exactly to prevent multiple "3rd party iframes" from talking to each other. That's the whole point of features like "disabling third party cookies" which many of us wishes was the default behavior.

Indeed Safari even disables third party cookies by default, though they have a somewhat more conservative definition of third party cookies.

I agree that the spec shouldn't mandate that multiple third party iframes should be silo'ed and prevented from talking to each other. However UAs should be allowed to do so if they wish to have a more restrictive privacy policy.

So basically the web workers spec should contain language like the text under the "Blocking third-party storage" section of http://dev.w3.org/html5/webstorage/#user-tracking

I would be satifised with some text that provides an out for User Agents that wish to add additional [optional] privacy restrictions on top of the generic SharedWorker connection algorithm.

How do you feel about cross-origin shared workers? (e.g. bing.com invoking a shared worker on facebook.com and communicating with it?)

Is that something that just won't be supported?

Currently, SharedWorkers are defined to connect only under same-origin conditions.

If you're asking what I think about adding support for cross-origin shared workers, I believe that would be a great feature and something we would consider implementing assuming it was speced to be secure. Cross-origin should require some degree of permission (CORS-like) since it essentially would allow connections to already-running or newly created local JavaScript "services" where the service is provided from some cross-origin source--like XHR the cross-origin source may want to restrict access. Even in this scenario, I would imagine that privacy features should be able to veto the connection for the same reasons we are discussing.

It turns out that a lot of users care about their privacy online. When users of IE opt-in to enhanced privacy features (e.g., our "tracking protection" feature), we need to limit the connect-ability of shared workers as we've already discussed. I'd really like the spec to allow this.

We can add some prose that says that user agents are allowed to ignore certain existing shared workers when determining whether to create a new shared worker or whether to reuse a shared worker when the constructor is called; for example, allowing a browser to consider each tab in a "privacy mode" to be a separate context unable to directly open a connection with shared workers in other contexts. Would that be sufficient?

IMHO, though, calling this a privacy feature is highly misleading and will just give users a false sense of privacy. This feature doesn't allow any more privacy-violating behaviour than can already be done purely with server-side analytics using fingerprinting. I think selling this as a privacy feature is essentially selling snake oil. This isn't a "privacy" feature, it's a "marketing" feature.

I believe that would be an acceptable resolution of this bug. Thanks.

Done.

Checked in as WHATWG revision r6744.
Check-in comment: Allow shared workers to be isolated.
http://html5.org/tools/web-apps-tracker?from=6743&to=6744