One more requirement from my perspective, and one question below. On Fri, Oct 1, 2021 at 2:50 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> *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 >>>>>>>>>> >>>>>>>>> I agree that a TAG review is not applicable in this case, because the behavior is already in an agreed-upon specification and one browser is already shipping the behavior. Am I correct that the specification in HTML covers all the behaviors in this intent? >>>>>>>>>> >>>>>>>>>> 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 >>>>> >>>> Please ask for a signal from WebKit. >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>>> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX7OJhyuHziAv4s66%2B_wwK3GWKXB1Mb5fmcR3B4EhsqhA%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/CAOMQ%2Bw97hCiPAkvJc2-1nODZa95Nav-7N6mefxDpY-O8a4RPoQ%40mail.gmail.com.
