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 <blink-dev@chromium.org> wrote:
*From:*Mike Taylor <miketa...@chromium.org>
*Sent:* Tuesday, January 14, 2025 7:10 AM
*To:* Liang Zhao (REDMOND) <liang.z...@microsoft.com>;
blink-dev@chromium.org
*Cc:* hirosh...@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 miketa...@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/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
<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/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
<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+unsubscr...@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+unsubscr...@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>.
