Re: [whatwg] Feedback on Web Worker specification

On Thu, Aug 23, 2012 at 5:39 PM, Maciej Stachowiak <mjs@apple.com> 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.

/ Jonas

Received on Friday, 24 August 2012 06:19:17 UTC