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.

We think (1) would be better and that's what we plan to do, unless other 
implementors feel strongly about taking the other approach. In either case, 
more clarity would be useful.

Regards,
Maciej


On Aug 22, 2012, at 1:29 PM, Jeffrey Pfau <[email protected]> wrote:

> Hi,
> 
> While working on enhancing WebKit's privacy infrastructure, I noticed that 
> shared workers don't have a UA security policy escape clause like 
> localStorage and other APIs. The process to create a shared worker does not 
> allow UAs to abort creation with a SecurityError if it decides that a 
> document, origin, or script violates the UA's security policy.
> 
> Adding something like the following (based on the localStorage policy clause) 
> to the SharedWorker constructor steps would help:
> 
> The user agent may throw a SecurityError exception instead of returning a 
> SharedWorker object if the request violates a policy decision (e.g. if the 
> user agent is configured to not allow the  script to share data).
> 
> What do you think?
> 
> Jeffrey

Reply via email to