W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 23 Aug 2011 05:19:27 +0000
To: public-webapps@w3.org
Message-Id: <E1QvjOZ-00047e-Ox@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13373

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-08-23 05:19:27 UTC ---
(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.

-- 
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 Tuesday, 23 August 2011 05:19:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT