W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2013

Re: [whatwg] [Workers] CSP and SharedWorkers

From: Jake Archibald <jaffathecake@gmail.com>
Date: Thu, 26 Sep 2013 15:28:11 +0100
Message-ID: <CAJ5xic9wJf54vO9gaGXqhNNZ6LhaTBPhMy3GTab2jk5XgBY+eA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Sid Stamm <sstamm@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Daniel Veditz <dveditz@mozilla.com>, "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Kyle Huey <me@kylehuey.com>, Alex Russell <slightlyoff@google.com>, Jonas Sicking <jonas@sicking.cc>
On 26 September 2013 14:57, Jake Archibald <jaffathecake@gmail.com> wrote:

> Note, this only covers registration. If http://example.com allows
> controllers from http://example.co.uk, and successfully calls
> registerServiceWorker("/*", "http://example.co.uk/service.js"), that
> controller will be used for all top-level fetches on http://example.com,
> and all fetches originating from documents on http://example.com,
> regardless of their CSP headers.

Oops, that's misleading, I mean the existing worker will be used for all
fetches even if the CSP rule of the page has changed to disallow
registering of that worker. The CSP of the page will still govern script
loading, XHR etc. If the page's CSP disallows a resource from a particular
URL, it won't consult the worker at all.

If the page requests an allowed url, and the worker serves up a response
(cached or otherwise) from a not-allowed url, CSP should block it.

(apologies for saying "controller" when I mean "service worker")
Received on Thursday, 26 September 2013 14:28:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:09 UTC