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/CAL5BFfVor9rcydTwksb9xFdGxaNrNkHjDdGjfKgRF6pHpMqEsw%40mail.gmail.com.
