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