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>.
