- From: Paul Frazee <pfrazee@gmail.com>
- Date: Tue, 25 Mar 2014 09:45:42 -0500
- 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>
- Message-ID: <CAD4FMegHQmUTKmWWQtS5HjMA+zO_3ENkZp0staDOKrxoEAM3xA@mail.gmail.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