W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2013

Re: CSP: workers

From: Alex Russell <slightlyoff@google.com>
Date: Thu, 16 May 2013 18:29:08 +0100
Message-ID: <CANr5HFVpjEq7rDnbK_gzCBMC9Fe78duAGUB19YxuFjSMu-FPMg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Daniel Veditz <dveditz@mozilla.com>, Ian Hickson <ian@hixie.ch>, WebAppSec WG <public-webappsec@w3.org>
On Thursday, May 16, 2013, Anne van Kesteren wrote:

> On Thu, May 16, 2013 at 6:02 PM, Daniel Veditz <dveditz@mozilla.com<javascript:;>>
> wrote:
> > On 5/14/2013 12:08 PM, Anne van Kesteren wrote:
> >> I think it makes more sense to treat opening a worker as creating an
> >> iframe. That works better for the navigation controller scenario as
> >> well (the (shared) worker is governed by the controller that governs
> >> its URL, rather than the document that created it).
> >
> > If not from the document which created it how do you define the CSP for a
> > worker, from a CSP header when it's loaded? In all other cases we're
> > ignoring CSP headers on script files.
> Right, but a worker is not a script file. It's a worker, which is
> intended to be similar to document as far as I understand the design.
> A worker can import scripts itself using importScripts.

I don't think this makes sense. The worker has permissions to do things
which hosting documents (of which there must be at least one) can do, and
that means that if I host a worker from a doucment, it should apply the
same policy as the document that begat it.

This is why I've been advocating the splitting when policies differ.

> I'd argue its CSP policy should be defined by the headers supplied for
> it. I also don't really see what else would work for shared workers.
> Might be good if Ian could comment on this, but he's not back for a week
> or so.
> --
> http://annevankesteren.nl/
Received on Thursday, 16 May 2013 17:29:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:33 UTC