On Thu, Aug 23, 2012 at 11:17 PM, Jonas Sicking <[email protected]> wrote: > On Thu, Aug 23, 2012 at 5:39 PM, Maciej Stachowiak <[email protected]> wrote: >> >> To expand a little on rationale for what Jeffrey said: >> >> We're working on an experimental preference setting for WebKit to block data >> storage in a third-party context, similar to the third-party cookie blocking >> feature in many browsers, but covering all forms of client-side storage. The >> intent of this is to make it more difficult for third-party content (such as >> ads or social media "like" buttons or similar) to track you across different >> sites, if you enable the feature. >> >> In thinking about the design, we came to the conclusion that SharedWorkers >> are actually a form of client-side shared storage. In particular, you could >> set a global variable in a SharedWorker, and then vend it to subframes from >> the same domain on other pages. It seems that to match the intent of the >> feature, we have to do one of two things: >> >> (1) Refuse access to SharedWorkers in a third-party context when the feature >> is enabled. This doesn't seem sanctioned by the spec, though other storage >> features have an explicit escape clause to refuse access based on >> privacy/security policy. >> >> (2) Create a dedicated worker instead of connecting to or spawning a shared >> worker when a third party context attempts to access a SharedWorker and the >> feature is enabled. We think, but are not sure, that something like this is >> sanctioned by the spec. > > I don't think you can do (2) since shared workers have a different > syntax from dedicated workers. > > Shared workers: > window code: > var worker = new SharedWorker(url, name); > worker.port.postMessage(...); > > worker code: > onconnect = function(e) { > e.ports[0].postMessage(...); > } > > Dedicated worker: > window code: > var worker = new Worker(url); > worker.postMessage(...); > > worker code: > onmessage = function(e) { > self.postMessage(...); > } > > > As you can see, much more than the constructor syntax differs. So if > you create a dedicated worker when the shared-worker constructor is > called, it's unlikely that the page will work at all.
But doing (1) definitely sounds like the right thing to do. We haven't implemented shared workers in Firefox yet, but for when we do, we are definitely considering doing that such that shared workers can't be used to do tracking, by using the strategy described in (1). / Jonas
