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+unsubscr...@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.
