[whatwg] Feedback on Web Worker specification

[Jonas Sicking]

On Thu, Aug 23, 2012 at 11:17 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Thu, Aug 23, 2012 at 5:39 PM, Maciej Stachowiak <mjs at 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.

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