CSP, Fetch, and Service Workers

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