Define security policy

[alecf]

We need to define the security policy more concretely. This has lead to a long discussion on the chrome side:

https://codereview.chromium.org/27278002/#msg23

We need to define the restrictions between the calling document, the pattern, and the script url in terms of what kinds of origins are compatible with what.

[annevk]

What security policy? The policy around the worker itself or around fetching?

[slightlyoff]

I've spent a lot of time thinking about this WRT CSP (in particular, how do you "split" thing when a worker has a CSP policy that's different to a document it colludes with over postMessage). I've come to the view that security is origin based. Registrations aren't about changing the same-origin policy or creating a separate set of actors to play in the origin model. @BrendanEich has suggested some sort of nesting for policies in the past, but I think this is far, far, far too complicated to reason about (my critique of pure OCap too, FWIW).

Should we need the ability to segment origins, I suggest we do it via CSP. A new directive might allow us to give content a separate storage partition (not shared with the rest of the origin), similar to the partitions used in the <webview> tag from Chrome Apps: https://developer.chrome.com/apps/tags/webview.html#partition

This would have a few important benefits: because use of the partition would cut the renderer off from communication with existing windows, their ambient authority would be moot. Also, since the partition would affect any/all iframes, the ability to misuse existing latent permissions at 3rd party sites would become moot. Lastly, assuming we allow naming of them that is eventually mangled with the origin internally to produce the resulting identifier, we'd be able to give sites a way to segment themselves bit-by-bit.

/cc @mikewest @abarth

[devd]

have you seen the sub origin proposal and the accompanying list discussion? iirc, we ended up also agreeing on having serialization.

http://blog.joelweinberger.us/2013/08/suborigins-for-privilege-separation-in.html

http://lists.w3.org/Archives/Public/public-webappsec/2013Aug/0016.html

[jakearchibald]

Had a chat with @mikewest around CSP and SW. Here's what we came up with:

Registration

The child-src directive would dictate where a ServiceWorker could be fetched from. This is intersected with SW's own restrictions, so if child-src only allowed urls on another origin, a SW could not be registered.

This would only be effective on origins without a SW installed. If there's an existing SW it could serve a page with whatever CSP header it likes.

child-src is also used for iframes & other worker types. It may make sense to have a separate directive for SW registrations.

Within the SW

As with other worker types, the CSP policy comes from the worker request & not the page.

A new directive, fetch-src, would dictate where the SW can make requests. This would apply to fetch(), Cache (which uses fetch internally) and XMLHttpRequest.

The meaning of other directives applies to responses rather than requests. Eg if the SW's script-src is set to "http://example.com", and it responds to a fetch event with .purpose == 'script' using a response from "http://evil.com", it would fail.

It would also fail if the response was manually constructed, or manually edited. Each directive may contain unsafe-response to allow manually constructed/edited responses.

A new directive, navigate-src, would control where top-level pages could be served from, intersected with SW's requirement for them to be non-opaque responses.

Reading through CSP 1.1, here's what I think applies:

• child-src - applies for workers, shared workers & iframes. Obviously iframes are controlled by the scope of their url, not the pages (are SharedWorkers the same?)
• connect-src
• default-src - should this also affect fetch-src?
• font-src
• img-src
• media-src
• object-src
• referrer - controls the header when using fetch() etc
• report-uri - logs failed responses and requests
• script-src
• style-src

[devd]

+1 on separate directive for SW registrations, rather than reusing child-src.

I don't think default-src should affect fetch-src.

[jakearchibald]

As @slightlyoff suggests in #224, there should be a directive to control the scope of registrations.

[annevk]

For registration I think we should have a "serviceworker" directive (as well as request context as otherwise CSP would not be informed about it).

fetch-src can just be connect-src. The same request contexts should probably apply.

There is a question of preserving the request context. If does a fetch, and service worker forwards it to the network, does it still have img-src and will redirects be appropriately blocked?

[KenjiBaheux]

This is an old issue which might have outlived its purpose. It's unclear what is still impact MVP if anything.

[annevk]

Yeah I think this is mostly sorted in other issues now and is specified in actual specifications to some extent.