*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. On Fri, Oct 1, 2021 at 10:12 AM Antonio Sartori <antoniosart...@chromium.org> wrote: > Sorry, of course. I just forgot. > > On Fri, Oct 1, 2021 at 9:30 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> 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/CAL5BFfX7OJhyuHziAv4s66%2B_wwK3GWKXB1Mb5fmcR3B4EhsqhA%40mail.gmail.com.
