Intent to Implement and Ship: CSP's `worker-src` directive.

[Mike West]

# Contact Emails

mk...@chromium.org

# Spec

https://w3c.github.io/webappsec-csp/#directive-worker-src

# Summary

CSP3 adds the 'worker-src' directive, which restricts the URLs which may be loaded as a Worker, SharedWorker, or ServiceWorker. It falls back to 'child-src' (which, in turn, falls back to 'default-src').

# Motivation

Currently, we ship `child-src`, which restricts both frames and workers. This seemed like a great idea, but turns out to be a suboptimal granularity for developers. CSP3 splits `child-src` by undeprecating `frame-src` (which we've already done) and adding `worker-src`.

# Interop Risk

Low. CSP implementations ignore directives they don't understand; adding new directives will not break existing sites.

Mozilla plans to implement the new directive: 

# Compat Risk

Developers who need to restrict workers but not frames can already do so in an interoperable way using `child-src` and overriding it with `frame-src` (e.g. `worker-src 'self'` ~= `child-src 'self'; frame-src *`). This isn't terribly pretty, but workarounds rarely are.

In the glorious future, when we've all implemented CSP3, policies can shrink back to something more reasonable.

# Technical Constraints

None.

# All Blink Platforms?

Yes.

# OWP Bug

https://crbug.com/662930

# Chromestatus

https://www.chromestatus.com/features/5922594955984896

# Requesting approval to ship?

Yes. This is a fairly small change, as it rests on top of all the other CSP infrastructure we already have. I'd like to just land it out from behind the flag.

# Web Platform Tests

(This isn't part of the template, but perhaps we should add it? +Rick?)

I plan to port/upstream the tests from https://codereview.chromium.org/2480303002 once we land them. It's not totally trivial, as they need substitution, but pretty straightforward.

-mike

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

Regarding web-platform-test in the template, Rick and I have talked about that. The long-term goal is that virtually all features can be effectively tested using web-platform-tests, so that this would be the default way of working. Then we would certainly ask about this in intents and look at test results in other implementations. At this point I think we could fruitfully ask about it without requiring anything,  though.

[Rick Byers]

LGTM3

On Thu, Nov 10, 2016 at 6:44 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Regarding web-platform-test in the template, Rick and I have talked about that. The long-term goal is that virtually all features can be effectively tested using web-platform-tests, so that this would be the default way of working. Then we would certainly ask about this in intents and look at test results in other implementations. At this point I think we could fruitfully ask about it without requiring anything,  though.

Moved this discussions to blink-api-owners-discuss here.  Feedback appreciated!

Thank you for doing this!  If you can file bugs for the related issues you find in other engines, that's even more awesome :-)

 

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

On Thu, Nov 10, 2016 at 5:07 PM, Rick Byers <rby...@chromium.org> wrote:

LGTM3

On Thu, Nov 10, 2016 at 6:44 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Regarding web-platform-test in the template, Rick and I have talked about that. The long-term goal is that virtually all features can be effectively tested using web-platform-tests, so that this would be the default way of working. Then we would certainly ask about this in intents and look at test results in other implementations. At this point I think we could fruitfully ask about it without requiring anything,  though.

Moved this discussions to blink-api-owners-discuss here.  Feedback appreciated!

Darn, forgot the link.

[Mike West]

Thanks, all. This landed in https://codereview.chromium.org/2480303002, and the tests were upstreamed to WPT in https://github.com/w3c/web-platform-tests/commit/45185609658ce4ee3576db5a5f362d9e0274bd6b.

-mike

[John Mellor]

Is there a risk we'll need to fork this again to distinguish between service workers (which are much more powerful) and ordinary workers?

[Mike West]

This landed in time for M56, but I'm going to pull it back behind a flag due to some discussion that's popped up at https://github.com/w3c/webappsec-csp/issues/146. I expect to resolve that one way or the other for the next release.

On Fri, Nov 11, 2016 at 12:21 PM, John Mellor <joh...@google.com> wrote:

Is there a risk we'll need to fork this again to distinguish between service workers (which are much more powerful) and ordinary workers?

I don't think so. That is, I think we need to deal with service workers at an origin-wide level, as they're origin-wide concepts. There's a bit of discussion on that point at https://github.com/w3c/webappsec-csp/issues/146#issuecomment-260285995 if you'd like to hop in!

-mike