An update, Mozilla has confirmed at https://github.com/web-platform-tests/interop/issues/855 that the apple.com issue no longer repro and they not aware of any other current or recent site breakages related to this. They have also closed https://bugzilla.mozilla.org/show_bug.cgi?id=1912873.
On Monday, February 24, 2025 at 1:03:59 PM UTC-8 Mike Taylor wrote: > Thanks - it is indeed confusing to follow all the various points in this > thread (sorry if I made it more so). > On 2/24/25 4:00 PM, 'Liang Zhao' via blink-dev wrote: > > There seems to be something that requires clarification. This feature only > tries to change behavior for CSP blocked worker. "new worker" could also be > blocked due to other reasons like cross origin, and we are not trying to > change behavior of that scenario. > Among the sites that were broken, only apple.com was due to CSP blocked > worker. Other sites were due to cross origin worker url. > https://bugzilla.mozilla.org/show_bug.cgi?id=1471805 and related code > change (https://phabricator.services.mozilla.com/D188592) that is still > open is for the cross origin case. There was an attempt to also address CSP > blocked worker in the same change, but that has not happened. From the code > review comment, it seems that it is not easy for Mozilla to also handle CSP > case. > > Appreciate the advice on telemetry data collection, will collect a usage > count when "new worker" is blocked by CSP. > > On Monday, February 24, 2025 at 7:27:50 AM UTC-8 Mike Taylor wrote: > > Hey Liang, > > Thank you very much for chasing down some answers! > > The situation is still a little tricky to evaluate, perhaps because there > are conflicting statements across a number of Bugzilla bugs and GitHub > issues. > > Here's a summary of my understanding: > > WebKit states concerns about webcompat (which I share, based on the number > of bug reports Firefox has seen): > https://github.com/web-platform-tests/interop/issues/855#issuecomment-2612231865 > > Interop 2025 accepted the proposal, so presumably Firefox agrees (and you > already stated as much). But > https://bugzilla.mozilla.org/show_bug.cgi?id=1471805 (the patch for Gecko > to match Blink/WebKit) is still open with no updates pointing to Interop > 2025 or similar. > > On the breakage we're aware of: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1912873 is still open (it > should probably be closed as incomplete because the site was updated to > remove the problematic video in question - unclear if Apple actually fixed > the CSP issue?) > > https://github.com/webcompat/web-bugs/issues/100874#issuecomment-1615265834 > talks about chase.com breakage, due to an embedded Google Map expecting > the error. I tried to load that site to verify today, but it seems like it > no longer exists. There's also a different site called "exploretock.com" > which was broken in Firefox, maybe fixed now? > > If anyone from Mozilla is reading, it would be cool if someone went and > cleaned up a bunch of bugs so the situation was less confusing. > > (some comments below) > On 2/21/25 1:29 PM, 'Liang Zhao' via blink-dev wrote: > > An update for the question on Mozilla coordination. Mozilla has not > changed their behavior and does not plan to do so. They actually filed an > interop issue at https://github.com/web-platform-tests/interop/issues/855, > which was discussed at interop 2025. My understanding of that discussion is > that Chrome and Safari should change the behavior to align with spec, and > revert to current behavior if we have to due to site compat. > There are actually other cases where Mozilla fire error event while Chrome > and Safari throw exception, like not same origin worker url. Most of the > cases in > https://github.com/web-platform-tests/wpt/issues/41745#issuecomment-2377512723 > , https://github.com/webcompat/web-bugs/issues/100874 and > https://bugzilla.mozilla.org/show_bug.cgi?id=1927467 are for those cases. > We are not trying to change behavior for those cases with this feature. The > support.apple.com issue is related to CSP blocked worker. The site has > been updated and doesn't have the issue any more. > > On Wednesday, January 22, 2025 at 1:20:52 AM UTC-8 Mike Taylor wrote: > > In > https://github.com/web-platform-tests/wpt/issues/41745#issuecomment-2377512723 > > - there's discussion of breakage on support.apple.com with this behavior, > and Firefox developers mentions moving their behavior to align with > Safari/Webkit given this breakage. The Bugzilla issue links to > https://github.com/webcompat/web-bugs/issues/100874 and > https://bugzilla.mozilla.org/show_bug.cgi?id=1927467. > > Have you coordinated with Mozilla on this? > On 1/21/25 7:50 PM, 'Liang Zhao' via blink-dev wrote: > > > > On Monday, January 20, 2025 at 4:48:38 AM UTC-8 Mike Taylor wrote: > > I'd still like to better understand the compat risk here - I suspect it's > low, but I would not be surprised if there is code attempting to handle the > difference between Chrome/Safari & Firefox with UA sniffing (which means it > may break after this change). > > Have you tried to look at any usage in the wild, to get a sense of how > sites are dealing with CSP blocking a worker today? > > The expected way to handle CSP blocking is to update CSP policy to allow > the worker. Normally, a site’s own content security policy should not block > its own workers. If a worker is blocked, the worker would not run and part > of the site would be broken. The developer should update the site’s CSP > policy to allow the worker. DevTools console message would clearly state > that the worker is blocked by the site’s own CSP and CSP reporting feature > allows site to detect the blocking of workers in the wild. Whether a worker > runs should be more important to a site than the behavior when the worker > is blocked. If a site cares about the blocking, it is expected that the > site either updates its CSP to allow the worker, or removes the worker > related code if the worker should not run. This is the main reason of my > assessment of low compat risk. It is a behavior change when an error of a > site's configuration has already caused bigger issue to the site. > > I hear you, but if we change the behavior my concern is about the user's > experience. Waiting for devs to notice and fix the breakage is not ideal. > > I thought about collecting telemetry data and decided not to. We could > collect counts of worker being blocked by CSP, but it would be hard to > collect data on how a site might handle the blocking, like whether a site > sniffs UA string and behaves differently, has a try-catch or has code to > handle error event later if we don’t throw exception in constructor. As it > is expected that it could happen that CSP blocks some workers, like during > testing of a site, a raw count of the blocking would not help much on > measuring the impact of this behavior change. > > Having some kind of telemetry would help here, even if imperfect. If we > know at least 3 sites were broken in Firefox for years (apple.com, > dining.chase.com, exploretock.com), it seems safe to assume there is more > we don't know about. > > > Will add telemetry data collection to collect a usage count when "new > worker" is blocked by CSP. > > > On 1/17/25 7:27 PM, Liang Zhao (REDMOND) wrote: > > Got positive signal from Safari. > > > > On Wednesday, January 15, 2025 at 5:25:48 PM UTC+1 Chris Harrelson wrote: > > Please also fill out the various reviews in your chromestatus entry > (privacy, security, enterprise, debuggability, testing). > > > > > > > > On Tue, Jan 14, 2025 at 2:43 PM 'Liang Zhao (REDMOND)' via blink-dev < > blin...@chromium.org> wrote: > > > > > > *From:* Mike Taylor <mike...@chromium.org> > *Sent:* Tuesday, January 14, 2025 7:10 AM > *To:* Liang Zhao (REDMOND) <liang...@microsoft.com>; blin...@chromium.org > *Cc:* hiro...@chromium.org; mk...@chromium.org > *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Ship: Fire error event > instead of throwing for CSP blocked worker > > > > You don't often get email from mike...@chromium.org. Learn why this is > important <https://aka.ms/LearnAboutSenderIdentification> > > On 1/13/25 5:19 PM, 'Liang Zhao (REDMOND)' via blink-dev wrote: > > *Contact emails* > > lz...@microsoft.com > > *Explainer* > > None > > > > I think an explainer (or even an inline text explaining the change, > providing an example, etc) would have significantly helped folks understand > what it is that you're trying to ship. > > Could you write something to that effect? > > > > When the url is blocked by Content Security Policy, script code “new > Worker(url)” and “new SharedWorker(url)” currently throws exception. > According to spec, the CSP check is done as part of fetch which happens > asynchronously and the constructor should not throw. Instead an error event > should fire after the object is returned. > > This feature aligns Chromium behavior with spec. > > > > > > *Specification* > > https://fetch.spec.whatwg.org/#concept-main-fetch > > This points at a relatively long algorithm. Can you point out the specific > steps that are relevant here? > > > > Step 7 of the linked “main fetch” section. Updated the spec link in > chromestatus to https://www.w3.org/TR/CSP3/#fetch-integration, which is a > better place to understand that CSP check is part of fetch instead of > details of how fetch is done in the fetch spec. > > > > *Summary* > > When blocked by CSP, Chromium currently throws SecurityError from > constructor. Spec requires CSP to be checked as part of fetch and fires > error event asynchronously. This aims to make Chromium spec conformant, > which is not throwing during constructor and fires error event > asynchronously. > > Which constructor? > > The constructor of Worker and SharedWorker objects. Also updated the > chromestatus so that it is clear. > > An example demonstrating where developers need to catch those exceptions > now would be helpful IMO. > > > > Before the change if developer wants to handle the worker being blocked > failure, the code would be something like this: > > try { > > var worker = new Worker(url); > > … > > } catch (e) { > > // error handling code > > } > > After the change, the code would be something like this: > > var worker = new Worker(url); > > worker.addEventListener('error', function(event) { > > // error handling code > > }); > > … > > > > *Blink component* > > Blink>SecurityFeature>ContentSecurityPolicy > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3EContentSecurityPolicy%22> > > *TAG review* > > None > > *TAG review status* > > Not applicable > > *Risks* > > > > *Interoperability and Compatibility* > > Are you able to expand on the compatibility implications for this change, > i.e., do we know if Firefox has any site breakage as a result of their > behavior? What scenarios might surprise developers who are relying on > Chrome's current behavior, etc? > > > > We are not aware of any site breakage for Firefox due to its behavior. If > a site has a worker that is blocked by CSP and has code after "new > Worker()", those code currently does not run in Chrome or Safari, but runs > in Firefox. After the change, those code would run in Chrome. > > Also, if sites are doing something as a result of catching a CSP failure > exception, that would stop working (unless they shift to start listening to > the relevant event), right? > > > > That is correct. If a site has code that runs upon catching SecurityError > exception during new Worker()/SharedWorker(), those code would not run. > Instead. if the site has error event listener, that event listener will run. > > > > Currently Firefox works as spec-ed while Safari works the same as Chrome. > With the wrong test code in WPT tests, Firefox is failing the tests: > https://wpt.fyi/results/content-security-policy/worker-src/dedicated-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned > > https://wpt.fyi/results/content-security-policy/worker-src/shared-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned > > After updating Chrome code and WPT tests, Firefox passes the tests while > Safari fails the tests. > > Can you explain what you mean by wrong test code? > > The current WPT test code expects exception to throw, which is not what’s > required by the spec. The test code has a TODO comment states that the test > code is wrong with a link to https://crbug.com/663298, > > > > *Gecko*: Shipped/Shipping > > *WebKit*: No signal > > Have we asked for a signal from WebKit folks? > > > > Filed an issue at https://github.com/WebKit/standards-positions/issues/451 > . > > > > Positive signal from > https://github.com/WebKit/standards-positions/issues/451: “As such I > suggest we mark this as position: support one week from now.” > > > *Web developers*: No signals > > *Other signals*: This changes the behavior the same as Firefox. > > *WebView application risks* > > *Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications?* > > > > *Debuggability* > > When worker is blocked by CSP, there is DevTools message logged about the > blocking by CSP. This behavior is not changed. > > > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > > Yes > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > > Yes > > > https://wpt.fyi/results/content-security-policy/worker-src/dedicated-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned > > https://wpt.fyi/results/content-security-policy/worker-src/shared-worker-src-child-fallback-blocked.sub.html?label=experimental&label=master&aligned > > Note that the test code currently has the wrong expectation and will be > updated as part of this feature work. > > > > *Flag name on about://flags* > > None > > *Finch feature name* > > None > > *Non-finch justification* > > This is a simple change of behavior for uncommon scenario where worker is > blocked by CSP, and the changed behavior is the same as Firefox and spec > aligned. It is unlikely that a site depends on the current behavior of > throwing exception for blocked worker. > > Can we back up "it is unlikely" with some data? Absent that, I would > strongly suggest we put this behind a flag. > > Changed the plan to put this new behavior behind > NoThrowForCSPBlockedWorker feature flag. Also updated the chromestatus. > > > > *Requires code in //chrome?* > > False > > *Tracking bug* > > https://issues.chromium.org/issues/41285169 > > *Estimated milestones* > > Shipping on desktop > > 134 > > DevTrial on desktop > > 134 > > Shipping on Android > > 134 > > DevTrial on Android > > 134 > > Shipping on WebView > > 134 > > > > *Anticipated spec changes* > > *Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way).* > > None > > *Link to entry on the Chrome Platform Status* > > https://chromestatus.com/feature/5177205656911872?gate=5108732671033344 > > -- > 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+...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CO1PR00MB2285E0FC0FEC6768415E9F979E1F2%40CO1PR00MB2285.namprd00.prod.outlook.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CO1PR00MB2285E0FC0FEC6768415E9F979E1F2%40CO1PR00MB2285.namprd00.prod.outlook.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+...@chromium.org. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BY1PR00MB2289751B22915D40E547832F9E182%40BY1PR00MB2289.namprd00.prod.outlook.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BY1PR00MB2289751B22915D40E547832F9E182%40BY1PR00MB2289.namprd00.prod.outlook.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+...@chromium.org. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2cc3be3-3e77-4e9c-9ab0-e0325e3ef292n%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2cc3be3-3e77-4e9c-9ab0-e0325e3ef292n%40chromium.org?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+...@chromium.org. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/909c58a5-94d2-4a26-9daf-efb9b72bf3efn%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/909c58a5-94d2-4a26-9daf-efb9b72bf3efn%40chromium.org?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+...@chromium.org. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15aa5f37-cb14-4acc-bc93-92bb17fb1c53n%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15aa5f37-cb14-4acc-bc93-92bb17fb1c53n%40chromium.org?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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6acff529-0767-4f35-8cb4-6becb9701f9dn%40chromium.org.
