On Fri, Oct 1, 2021 at 5:09 PM Chris Harrelson <chris...@chromium.org>
wrote:

> One more requirement from my perspective, and one question below.
>
>
Thanks. Replies inline.


> 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?
>

Yes, that is correct.


>
>
>>>>>>>>>>>
>>>>>>>>>>> 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.
>

I have asked for a signal starting this thread:
https://lists.webkit.org/pipermail/webkit-dev/2021-October/031999.html

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

Reply via email to