W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2014

Re: CSP, Fetch, and Service Workers

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Wed, 26 Mar 2014 07:31:59 +0530
Message-ID: <CAPfop_3qc1P8RTUmkYFU=jvoFYPTcNt9V0Vq0QrzF1YX0c+uow@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebAppSec WG <public-webappsec@w3.org>, Jake Archibald <jakearchibald@google.com>, Alec Flett <alecflett@google.com>
Hi

>
> Do people here have opinions on the names we use?

I don't have opinions about names, but

> non-CSP related uses. It seems to me it still makes sense to share the
> vocabulary as per 1) though I could be convinced otherwise I suppose.
> Sharing would at least make it easier to design an API as you'd only
> need to pass one parameter to Fetch.

+1. Sharing vocabulary is better.

> 2) We have to carefully consider how large parts of CSP are no longer
> effective in the world of service workers. You no longer have the
> close tie between an API that initiates the fetch and the response.

Where does CSP fall with a SW? Does it run after the SW or before SW?
I.e., if SW makes a request to alice.com will the page's CSP apply to
that request? If a page makes a request to alice.com, will CSP apply
before the request hits the SW?

> A service worker can basically handle the network request itself, in
> which case the originating page knows about as much as default-src, or
> it can default to the network, in which case you could probably still
> use a the policy for the fetch context in place as you know the
> service worker did not touch anything. Is that useful?

I don't understand this paragraph. Can you explain further?

thanks
Dev
Received on Wednesday, 26 March 2014 02:02:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC