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/CAOzWxF7En0MhS_9ajoOnT%2Bxym6hLAHRALigsUmh4_Hnnc0%2B9aw%40mail.gmail.com.
