[whatwg] [Workers] CSP and SharedWorkers

[Jonas Sicking]

On Wed, Sep 25, 2013 at 8:00 PM, Kyle Huey <me at kylehuey.com> wrote:
> It's unclear how SharedWorkers should interact with Content Security
> Policies.  This came up during code review of the SharedWorker
> implementation in Gecko[0].  There was a public-webappsec thread[1] on this
> back in May that didn't really reach a conclusion and I'd like to drive
> towards one here.

For both Shared Workers and Service Workers is seems pretty clear that
we can't "inherit" the policy of the loading document. Any such
constructs would feel non-sensical in too many situations. So here I
think we should let the worker get its CSP from the script load
itself.

With Dedicated Workers we could in theory inherit the policy of
loading document, but it feels like that creates a lot of
inconsistency with Shared/Service Workers.

So my off-the-top-of-my-head suggestion would be to always let workers
get the CSP from the script load.

Though one question is what to do for workers loaded from blob:, data:
or filesystem:.

Maybe we should disallow shared/service workers from those types of
URLs, and make dedicated workers inherit the CSP when loaded from
those URLs. Though I could see shared workers from filesystem: being
useful.

What do implementations do with regards to linking <script> to
blob/data/filesystem? Are they treated like normal protocols, or are
they treated like eval()? If they are treated like normal protocols
then maybe we can simply not have any special rules for them and say
that for now they never get a CSP.

> I don't have strong feelings about whether or not we should
> deny a page with a more liberal CSP from connecting to a SharedWorker with a
> more strict CSP, but I suspect others might.

What do we do for <iframe>s here. If nothing then I don't think we
should do anything for workers either.

/ Jonas