Contact emails
Explainer
None
Specification
https://fetch.spec.whatwg.org/#concept-main-fetch
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.
Blink component
Blink>SecurityFeature>ContentSecurityPolicy
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
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.
Gecko: Shipped/Shipping
WebKit: No signal
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?
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.
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
Contact emails
Explainer
None
Specification
https://fetch.spec.whatwg.org/#concept-main-fetch
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.
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.
On 1/13/25 5:19 PM, 'Liang Zhao (REDMOND)' via blink-dev wrote:
Contact emails
Explainer
None
Specification
https://fetch.spec.whatwg.org/#concept-main-fetch
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.
Blink component
Blink>SecurityFeature>ContentSecurityPolicy
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
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.
Gecko: Shipped/Shipping
WebKit: No signal
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?
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.
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
--
On Mon, Jan 13, 2025 at 5:31 PM 'Liang Zhao (REDMOND)' via blink-dev <blin...@chromium.org> wrote:Contact emails
Explainer
None
Specification
https://fetch.spec.whatwg.org/#concept-main-fetch
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.
Does Chromium throw the exception _and_ send the event?
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 |
On 1/13/25 5:19 PM, 'Liang Zhao (REDMOND)' via blink-dev wrote:
Contact emails
Explainer
None
Specification
https://fetch.spec.whatwg.org/#concept-main-fetch
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.
Blink component
Blink>SecurityFeature>ContentSecurityPolicy
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.
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
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?
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.
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
On 1/13/25 5:19 PM, 'Liang Zhao (REDMOND)' via blink-dev wrote:
Contact emails
Explainer
None
Specification
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.
Blink component
Blink>SecurityFeature>ContentSecurityPolicy
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.
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
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
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
On 1/13/25 5:19 PM, 'Liang Zhao (REDMOND)' via blink-dev wrote:
Contact emails
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
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
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
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.
Got positive signal from Safari.
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.”
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?
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?
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?
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2cc3be3-3e77-4e9c-9ab0-e0325e3ef292n%40chromium.org.