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

Re: CSP, Fetch, and Service Workers

From: Paul Frazee <pfrazee@gmail.com>
Date: Tue, 25 Mar 2014 09:45:42 -0500
Message-ID: <CAD4FMegHQmUTKmWWQtS5HjMA+zO_3ENkZp0staDOKrxoEAM3xA@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>, Alex Russell <slightlyoff@google.com>, Jungkee Song <jungkee.song@samsung.com>
Help clarify this for me: ServiceWorkers would apply security policies by
proxying in the network stack, correct?

The issue of context is partly what I try to address with the JS API
proposal for CSP [1] which would allow policies to be set on individual
objects, making the Document just one policy-consumer, while ServiceWorker,
for instance, would be another. I think there's an advantage in doing that,
because it stays in the existing framework of CSP, and the policies can
apply to non-networking APIs.

My two cents, I'm still familiarizing with the existing proposals so bear
with me.

1. http://lists.w3.org/Archives/Public/public-webappsec/2014Mar/0078.html

Be well,
Paul F

On Tue, Mar 25, 2014 at 9:24 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Feb 6, 2014 at 7:31 PM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> > 1) What fetch contexts do we want to have? See
> >
> > *
> http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/thread.html#msg27
> > * http://wiki.whatwg.org/wiki/Contexts
> > *
> https://github.com/slightlyoff/ServiceWorker/issues/140#issuecomment-33190003
> >
> > Basically, fetch contexts would represent some kind of union between
> > CSP and other things that can cause fetches not governed by CSP and be
> > slightly more low-level than the CSP primitives as to cater to other
> > use cases.
> >
> > Do people here have opinions on the names we use?
> Ping?
> > 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.
> > While you can have <script src=http://x.example/> in a page, there's
> > no guarantee the response fed from the service worker will be from
> > there. This seems like something people using service workers have to
> > realize and put an appropriate policy on the service worker itself.
> >
> > 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?
> >
> > Obviously passing the fetch context to the service worker is for
> > 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.
> --
> http://annevankesteren.nl/
Received on Tuesday, 25 March 2014 14:46:50 UTC

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