Intent to Ship: Content-Security-Policy delivery via response headers for dedicated workers.

[Antonio Sartori]

Contact emails

antonio...@chromium.org

Specification

https://html.spec.whatwg.org/#initialize-worker-policy-container

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#csp_in_workers

Summary

Dedicated workers should be governed by the Content Security Policy delivered in their script response headers. Chrome incorrectly used to instead apply the Content Security Policy of the owner document. We would like to change chrome's behaviour to adhere to what is specified.

For background, see the discussion on the github issue where this was agreed: https://github.com/w3c/webappsec-csp/issues/336

Blink component

Blink>SecurityFeature>ContentSecurityPolicy

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Shipped/Shipping See also the discussion on the issue https://github.com/w3c/webappsec-csp/issues/336

WebKit: N/A

Web developers: Positive (https://bugs.chromium.org/p/chromium/issues/detail?id=1012640) This has been reported as a bug to chrome.

Debuggability

Warnings regarding Content Security Policy are and will continue to be reported in the devtools console.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1253267

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5715844005888000

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

Have you looked into the compatibility implications of changing behavior here? How often would that remove restrictions from existing web content? How often do dedicated workers currently get CSP headers which will now be applied?

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF5EX2mHofXHLK_V7VTQ5v%3DPcunu_BiF%2BzFJQTFy9DSwTQ%40mail.gmail.com.

[Antonio Sartori]

From a quick search through httparchive (data from httparchive.requests.2021_07_01_desktop) it looks like out of 549,668 outgoing requests for dedicated workers, 457,780 of them returned a Content-Security-Policy header (hence ~80%). As a comparison, from the same data it looks like ~15% of document requests return a Content-Security-Policy.

Better data could be gathered by building some use counters in chromium's code.

I have not looked into how often that would remove restrictions from existing web contents. I don't see an easy way to do it without adding code to chrome to check both the inherited and the response CSP for each outgoing request from a worker and report when the two checks mismatch. It is surely doable but I have the impression it might be overkilled in this case.

Since the proposed behaviour is already implemented by Firefox (and it seems also by Safari), I believe the probability of this breaking something to be fairly low (developer would have noticed their websites not working on Firefox/Safari already).

[Yoav Weiss]

On Wed, Sep 29, 2021 at 2:14 PM Antonio Sartori <antonio...@chromium.org> wrote:

From a quick search through httparchive (data from httparchive.requests.2021_07_01_desktop) it looks like out of 549,668 outgoing requests for dedicated workers, 457,780 of them returned a Content-Security-Policy header (hence ~80%). As a comparison, from the same data it looks like ~15% of document requests return a Content-Security-Policy.

That's a lot! 

 

Better data could be gathered by building some use counters in chromium's code.

Unless there's particular urgency here, I think use-counters would make sense here. That can give us confidence that content won't break as a result of this change in CSP rule application.

 

I have not looked into how often that would remove restrictions from existing web contents. I don't see an easy way to do it without adding code to chrome to check both the inherited and the response CSP for each outgoing request from a worker and report when the two checks mismatch. It is surely doable but I have the impression it might be overkilled in this case.

Since the proposed behaviour is already implemented by Firefox (and it seems also by Safari), I believe the probability of this breaking something to be fairly low (developer would have noticed their websites not working on Firefox/Safari already).

On Wed, Sep 29, 2021 at 1:21 PM Yoav Weiss <yoav...@chromium.org> wrote:

Have you looked into the compatibility implications of changing behavior here? How often would that remove restrictions from existing web content? How often do dedicated workers currently get CSP headers which will now be applied?

On Mon, Sep 27, 2021 at 12:50 PM Antonio Sartori <antonio...@chromium.org> wrote:

Contact emails

antonio...@chromium.org

Specification

https://html.spec.whatwg.org/#initialize-worker-policy-container

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#csp_in_workers

Summary

Dedicated workers should be governed by the Content Security Policy delivered in their script response headers. Chrome incorrectly used to instead apply the Content Security Policy of the owner document. We would like to change chrome's behaviour to adhere to what is specified.

For background, see the discussion on the github issue where this was agreed: https://github.com/w3c/webappsec-csp/issues/336

Blink component

Blink>SecurityFeature>ContentSecurityPolicy

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Shipped/Shipping See also the discussion on the issue https://github.com/w3c/webappsec-csp/issues/336

WebKit: N/A

Why N/A?

[Antonio Sartori]

On Wed, Sep 29, 2021 at 2:50 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, Sep 29, 2021 at 2:14 PM Antonio Sartori <antonio...@chromium.org> wrote:

From a quick search through httparchive (data from httparchive.requests.2021_07_01_desktop) it looks like out of 549,668 outgoing requests for dedicated workers, 457,780 of them returned a Content-Security-Policy header (hence ~80%). As a comparison, from the same data it looks like ~15% of document requests return a Content-Security-Policy.

That's a lot! 

 

Better data could be gathered by building some use counters in chromium's code.

Unless there's particular urgency here, I think use-counters would make sense here. That can give us confidence that content won't break as a result of this change in CSP rule application.

Just to double-check that I understand correctly: For giving us confidence that content won't break, we would have to build a mechanism to check workers' response CSPs (without enforcing them) and report via use counters in case a resource which is currently allowed would have been blocked. This is what I was sketching below, and requires quite some implementation work, which I am not sure when we would be able to prioritize.

I don't think there is a particular urgency, although this is a bugfix and I believe this is a big security improvement, since it allows servers to have different policies on their main page and on the worker (so for example an application which needs eval inside a worker would not need to enable eval in the main document).

 

I have not looked into how often that would remove restrictions from existing web contents. I don't see an easy way to do it without adding code to chrome to check both the inherited and the response CSP for each outgoing request from a worker and report when the two checks mismatch. It is surely doable but I have the impression it might be overkilled in this case.

Since the proposed behaviour is already implemented by Firefox (and it seems also by Safari), I believe the probability of this breaking something to be fairly low (developer would have noticed their websites not working on Firefox/Safari already).

On Wed, Sep 29, 2021 at 1:21 PM Yoav Weiss <yoav...@chromium.org> wrote:

Have you looked into the compatibility implications of changing behavior here? How often would that remove restrictions from existing web content? How often do dedicated workers currently get CSP headers which will now be applied?

On Mon, Sep 27, 2021 at 12:50 PM Antonio Sartori <antonio...@chromium.org> wrote:

Contact emails

antonio...@chromium.org

Specification

https://html.spec.whatwg.org/#initialize-worker-policy-container

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#csp_in_workers

Summary

Dedicated workers should be governed by the Content Security Policy delivered in their script response headers. Chrome incorrectly used to instead apply the Content Security Policy of the owner document. We would like to change chrome's behaviour to adhere to what is specified.

For background, see the discussion on the github issue where this was agreed: https://github.com/w3c/webappsec-csp/issues/336

Blink component

Blink>SecurityFeature>ContentSecurityPolicy

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Shipped/Shipping See also the discussion on the issue https://github.com/w3c/webappsec-csp/issues/336

WebKit: N/A

Why N/A?

Because I am not totally sure. While Firefox argued publicly that this is how they believe CSPs for workers should work and this is what they implement, there was no signal from WebKit AFAIK. From some manual testing, it looks to me like WebKit implements this. Unfortunately our WPTs here are not so great, since many of them time out on Safari (https://wpt.fyi/results/content-security-policy/inside-worker?label=experimental&label=master&aligned).

[Yoav Weiss]

On Wed, Sep 29, 2021 at 4:16 PM Antonio Sartori <antonio...@chromium.org> wrote:

On Wed, Sep 29, 2021 at 2:50 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, Sep 29, 2021 at 2:14 PM Antonio Sartori <antonio...@chromium.org> wrote:

From a quick search through httparchive (data from httparchive.requests.2021_07_01_desktop) it looks like out of 549,668 outgoing requests for dedicated workers, 457,780 of them returned a Content-Security-Policy header (hence ~80%). As a comparison, from the same data it looks like ~15% of document requests return a Content-Security-Policy.

That's a lot! 

 

Better data could be gathered by building some use counters in chromium's code.

Unless there's particular urgency here, I think use-counters would make sense here. That can give us confidence that content won't break as a result of this change in CSP rule application.

Just to double-check that I understand correctly: For giving us confidence that content won't break, we would have to build a mechanism to check workers' response CSPs (without enforcing them) and report via use counters in case a resource which is currently allowed would have been blocked. This is what I was sketching below, and requires quite some implementation work, which I am not sure when we would be able to prioritize.

Maybe I'm missing the mark, but wouldn't that implementation work be something that's on path to what you'd need to implement anyway for this?

I certainly have no interest in making you do extra work, but with 80% (!!) of workers currently having CSP headers, I'm concerned that mismatches between the worker headers and the main document headers exist, which can result in broken content.

I take your point that if such discrepancies exist, they are currently reflected in broken content in e.g. Firefox. At the same time, I'd be more comfortable with taking a decision here based on a bit more data.

Would be good to ask for their official opinion: https://bit.ly/blink-signals

[Antonio Sartori]

I did some more research in httparchive. By filtering out only interesting CSPs delivered by workers and comparing them with their owner document's CSP, I was left with only two entries (out of the total 457,780 worker requests) which might actually break. The details are in this document. Could this give us confidence that content won't break, even without adding user counters in the code?

Regarding Safari, I did some more experiments and checked their code. I would now say confidently that they do implement this.

Thanks!

[Yoav Weiss]

Thanks!!

On Fri, Oct 1, 2021 at 9:23 AM Antonio Sartori <antonio...@chromium.org> wrote:

I did some more research in httparchive. By filtering out only interesting CSPs delivered by workers and comparing them with their owner document's CSP, I was left with only two entries (out of the total 457,780 worker requests) which might actually break. The details are in this document.

Could the doc be made public?

[Antonio Sartori]

Sorry, of course. I just forgot.

[Yoav Weiss]

LGTM1

Thank you for doing this analysis! 2/550K is significantly less than 80% :P

I believe that puts us at ~0.00036%, and the actual number of affected sites (as opposed to workers) is an order of magnitude lower. Also, there's no particular reason to believe HA is unrepresentative for this particular change. (as I wouldn't expect main page workers to vary vastly from workers in other pages)

 

That makes me agree with your assessment of this being low risk.

[Chris Harrelson]

One more requirement from my perspective, and one question below.

I agree that a TAG review is not applicable in this case, because the behavior is already in an agreed-upon specification and one browser is already shipping the behavior.

 

Am I correct that the specification in HTML covers all the behaviors in this intent?

Risks

Interoperability and Compatibility

Gecko: Shipped/Shipping See also the discussion on the issue https://github.com/w3c/webappsec-csp/issues/336

WebKit: N/A

Why N/A?

Because I am not totally sure. While Firefox argued publicly that this is how they believe CSPs for workers should work and this is what they implement, there was no signal from WebKit AFAIK. From some manual testing, it looks to me like WebKit implements this. Unfortunately our WPTs here are not so great, since many of them time out on Safari (https://wpt.fyi/results/content-security-policy/inside-worker?label=experimental&label=master&aligned).

Would be good to ask for their official opinion: https://bit.ly/blink-signals

Please ask for a signal from WebKit.

 

 

 

Web developers: Positive (https://bugs.chromium.org/p/chromium/issues/detail?id=1012640) This has been reported as a bug to chrome.

Debuggability

Warnings regarding Content Security Policy are and will continue to be reported in the devtools console.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1253267

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5715844005888000

This intent message was generated by Chrome Platform Status.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF5EX2mHofXHLK_V7VTQ5v%3DPcunu_BiF%2BzFJQTFy9DSwTQ%40mail.gmail.com.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX7OJhyuHziAv4s66%2B_wwK3GWKXB1Mb5fmcR3B4EhsqhA%40mail.gmail.com.

[Antonio Sartori]

On Fri, Oct 1, 2021 at 5:09 PM Chris Harrelson <chri...@chromium.org> wrote:

One more requirement from my perspective, and one question below.

Thanks. Replies inline.

Yes, that is correct.

 

Risks

Interoperability and Compatibility

Gecko: Shipped/Shipping See also the discussion on the issue https://github.com/w3c/webappsec-csp/issues/336

WebKit: N/A

Why N/A?

Because I am not totally sure. While Firefox argued publicly that this is how they believe CSPs for workers should work and this is what they implement, there was no signal from WebKit AFAIK. From some manual testing, it looks to me like WebKit implements this. Unfortunately our WPTs here are not so great, since many of them time out on Safari (https://wpt.fyi/results/content-security-policy/inside-worker?label=experimental&label=master&aligned).

Would be good to ask for their official opinion: https://bit.ly/blink-signals

Please ask for a signal from WebKit.

I have asked for a signal starting this thread: https://lists.webkit.org/pipermail/webkit-dev/2021-October/031999.html 

[Chris Harrelson]

Thanks!

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF75vpsv5nQmA_Tj29nOg1h4ZPmtKb9Fw_aba7Gpfo5hLw%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9-G_G4mXA9%2BhagWoSf1OkGz%2BjsmoS7hpeL8f1_1p0Jfw%40mail.gmail.com.