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
Warnings regarding Content Security Policy are and will continue to be reported in the devtools console.
No milestones specified
--
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.
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).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.orgSpecification
https://html.spec.whatwg.org/#initialize-worker-policy-containerhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#csp_in_workersSummary
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>ContentSecurityPolicyTAG review
TAG review status
Not applicableRisks
Interoperability and Compatibility
Gecko: Shipped/Shipping See also the discussion on the issue https://github.com/w3c/webappsec-csp/issues/336
WebKit: N/A
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.orgSpecification
https://html.spec.whatwg.org/#initialize-worker-policy-containerhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#csp_in_workersSummary
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>ContentSecurityPolicyTAG review
TAG review status
Not applicableRisks
Interoperability and Compatibility
Gecko: Shipped/Shipping See also the discussion on the issue https://github.com/w3c/webappsec-csp/issues/336
WebKit: N/AWhy N/A?
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 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.
Risks
Interoperability and Compatibility
Gecko: Shipped/Shipping See also the discussion on the issue https://github.com/w3c/webappsec-csp/issues/336
WebKit: N/AWhy 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
----
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?
YesFlag name
Requires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1253267Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5715844005888000This 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.
One more requirement from my perspective, and one question below.
Risks
Interoperability and Compatibility
Gecko: Shipped/Shipping See also the discussion on the issue https://github.com/w3c/webappsec-csp/issues/336
WebKit: N/AWhy 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-signalsPlease ask for a signal from WebKit.
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.
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.