- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 6 Feb 2014 20:31:00 +0100
- To: WebAppSec WG <public-webappsec@w3.org>
- Cc: Jake Archibald <jakearchibald@google.com>, Alec Flett <alecflett@google.com>
Two things. 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? 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 Thursday, 6 February 2014 19:31:27 UTC