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 <https://docs.google.com/document/d/16_TiDx3MOE7uO6vMhE6qE1jN78ZzzvUsaqcV0Cb3G0E/edit?usp=sharing>. 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 <https://github.com/WebKit/WebKit/blob/5f99dfc43d30d3af1cabbf24d111acbff994808b/Source/WebCore/workers/DedicatedWorkerGlobalScope.cpp#L60>. I would now say confidently that they do implement this. Thanks! On Wed, Sep 29, 2021 at 5:05 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > > > On Wed, Sep 29, 2021 at 4:16 PM Antonio Sartori < > antoniosart...@chromium.org> wrote: > >> >> >> On Wed, Sep 29, 2021 at 2:50 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> >>> >>> On Wed, Sep 29, 2021 at 2:14 PM Antonio Sartori < >>> antoniosart...@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. > > >> 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 <yoavwe...@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 < >>>>> antoniosart...@chromium.org> wrote: >>>>> >>>>>> Contact emailsantoniosart...@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 componentBlink>SecurityFeature>ContentSecurityPolicy >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3EContentSecurityPolicy> >>>>>> >>>>>> TAG review >>>>>> >>>>>> TAG review statusNot 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 >> ). >> > > 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 >>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>> ?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 >>>>>> <https://www.chromestatus.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+unsubscr...@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 >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF5EX2mHofXHLK_V7VTQ5v%3DPcunu_BiF%2BzFJQTFy9DSwTQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOzWxF5TgWkd_rPFLPW_dZJNRHg_KsBqzTDLuG1JM0rX_B494A%40mail.gmail.com.
