Thanks!! On Fri, Oct 1, 2021 at 9:23 AM Antonio Sartori <antoniosart...@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 > <https://docs.google.com/document/d/16_TiDx3MOE7uO6vMhE6qE1jN78ZzzvUsaqcV0Cb3G0E/edit?usp=sharing>. > > Could the doc be made public? > 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/CAL5BFfXH%2Bc4g7pborxTypx52y9v8yPWrsnBz-AsbjV3P5Xt8JQ%40mail.gmail.com.
