LGTM2
On Thu, May 7, 2026 at 11:19 AM 'Chris Harrelson' via blink-dev
<[email protected]> wrote:
Thanks for that testing information. I think that's enough testing
to support shipping this change.
LGTM1
On Thu, May 7, 2026 at 3:30 AM 'Yoshisato Yanagisawa' via
blink-dev <[email protected]> wrote:
Sorry for the slow reply,
Regarding the testing for this feature: We identified sites
using data URL Dedicated Workers
(https://chromestatus.com/metrics/feature/timeline/popularity/5568)
and Shared Workers
(https://chromestatus.com/metrics/feature/timeline/popularity/5569).
I inspected whether these sites use BroadcastChannel,
localStorage, indexedDB, or self.origin. For 63 sites, no
*Workers started for a few seconds after page load. For the
remaining 119 sites, no issues were detected. We performed
dynamic inspection (injecting a trap) on more than half of them.
Debuggability depends on the API the page uses:
* If they use the storage API, a SecurityError should occur,
which is easy to detect.
* If they use BroadcastChannel, it will silently fail.
* If they use self.origin, it will return null. This is easy
to detect, although the change is implicit.
The good news for BroadcastChannel is that its usage for this
specific case appears to be very small now
(https://chromestatus.com/metrics/feature/timeline/popularity/5856).
I hope this addresses your concerns regarding the safety of
this change in non-enterprise environments.
2026年5月7日(木) 0:16 Vladimir Levin <[email protected]>:
To add to Rick's question: do we know of valid cases that
would be broken by this change? If so, what are the
mitigations authors need to take to not be broken?
Thanks!
Vlad
On Wednesday, May 6, 2026 at 10:04:08 AM UTC-4 Rick Byers
wrote:
What's the failure mode? Is there a clear error shown
on the console and available to window.onerror which
would enable a developer to easily debug and correct
this, and locate the enterprise policy via a web
search? It does seem like we need to be making this
change, and aligning with Firefox and Safari suggests
the non-enterprise risk is probably fairly low (though
WebView is still a potential concern). But as long as
we have done everything reasonable to make
debuggability
<https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.2vhygov7rgj5>
high, my sense is we should just go for it. It's not
like we have a great other option if we find some
sites are broken by it, we need to fix this hole right?
On Fri, May 1, 2026 at 8:57 AM Mike Taylor
<[email protected]> wrote:
On 4/30/26 4:53 a.m., Chromestatus wrote:
*Contact emails*
[email protected]
*Explainer*
/No information provided/
*Specification*
https://html.spec.whatwg.org/multipage/workers.html#script-settings-for-workers
*Summary*
Assigns a unique opaque origin to Dedicated and
Shared Workers created from data: URLs, rather
than inheriting the security origin of their
creator. This alignment with the HTML
specification enhances security by isolating
these workers from the creator's same-origin
state, preventing them from accessing sensitive
data via mechanisms like BroadcastChannel or
same-origin storage. To maintain correct
isolation boundaries, these workers still reside
within the same storage partition (e.g., by
preserving the top-level site or nonce) as their
creator. See:
https://html.spec.whatwg.org/multipage/workers.html#script-settings-for-workers
Step 3.
*Blink component*
Blink>Workers
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWorkers%22>
*Web Feature ID*
Missing feature
*Motivation*
Currently, Dedicated and Shared Workers created
from data: URLs in Chrome inherit the security
origin of their creator, which deviates from the
HTML specification. This behavior allows these
workers to access sensitive same-origin
resources, such as BroadcastChannel,
LocalStorage, and IndexedDB, potentially leading
to data leakage where untrusted or dynamically
generated scripts can join a page's same-origin
communication state. This change aligns Chrome
with the standard by assigning a unique opaque
origin to such workers, ensuring proper security
isolation. It also improves interoperability, as
other major browser engines already follow the
specification by not inheriting the origin for
data: URL workers. The implementation maintains
necessary isolation boundaries by preserving the
creator's storage partition (e.g., top-level site
or nonce).
*Initial public proposal*
/No information provided/
*TAG review*
/No information provided/
*TAG review status*
Pending
*Goals for experimentation*
None
*Risks*
*Interoperability and Compatibility*
Interoperability Risk: Low. This change actually
improves interoperability by aligning Chrome's
behavior with the HTML specification and other
major browser engines, such as Firefox and
Safari, which already assign opaque origins to
data: URL dedicated and shared workers. Chrome is
currently the outlier by allowing origin
inheritance in this scenario. Compatibility Risk:
Moderate. The primary risk is that data: URL
dedicated and shared workers will no longer be
same-origin with their creator. This will break
sites that rely on these workers to access
same-origin resources, such as joining a
BroadcastChannel associated with the creator's
origin or accessing same-origin storage like
LocalStorage and IndexedDB. Use counters indicate
that approximately 0.13% of page loads use data:
URL dedicated workers
(https://chromestatus.com/metrics/feature/timeline/popularity/5568),
and 0.01% use data: URL shared workers
(https://chromestatus.com/metrics/feature/timeline/popularity/5569).
To mitigate disruption, especially in enterprise
environments, the change is guarded by a feature
flag (kDataUrlWorkerOpaqueOrigin) and will be
accompanied by an enterprise policy to serve as
an escape hatch.
Is there any way we can increase our confidence
that this is a safe change for non-enterprise
environments? Have you been able to test any sites
with the feature enabled?
/Gecko/: Shipped/Shipping
/WebKit/: Shipped/Shipping
/Web developers/: No signals There are no
specific signals from web or framework developers
at this stage. While the change impacts a small
percentage of page loads (0.13%), it is currently
unclear how many developers intentionally rely on
the existing non-standard origin inheritance
behavior.
/Other signals/:
*Activation*
There are no activation risks for new users. For
existing developers who intentionally or
unintentionally rely on data: URL dedicated and
shared workers sharing same-origin state, they
will need to migrate to explicit communication
using postMessage() or use regular script URLs to
maintain same-origin access.
*Security*
The change is a security improvement that
prevents data leakage via BroadcastChannel and
storage. A key security consideration in the
design was ensuring that while the origin is made
opaque, the worker still remains within the same
storage partition (preserving the top_level_site
and nonce) as its creator. This ensures that the
worker cannot be used to bypass existing
isolation boundaries established by the parent
context.
*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?
/No information provided/
*Debuggability*
No new DevTools features are required. The change
will be visible to developers in the console or
debugger as the worker's self.origin will
correctly report as "null". Existing debugging
tools for workers and BroadcastChannel remain
functional and will reflect the new opaque origin.
*Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, ChromeOS,
Android, and Android WebView)?*
Yes
This feature is implemented in the core Chromium
worker infrastructure (within the content layer),
which is shared across all platforms. The logic
for calculating the worker's storage key and
renderer origin for data: URLs is applied
consistently to all Blink platforms, ensuring
uniform security behavior and specification
compliance on Windows, Mac, Linux, ChromeOS,
Android, and Android WebView
*Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
No
https://wpt.fyi/results/webmessaging/broadcastchannel/opaque-origin.html
*Flag name on about://flags*
/No information provided/
*Finch feature name*
kDataUrlWorkerOpaqueOrigin
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
False
*Tracking bug*
https://crbug.com/40051700
*Measurement*
https://chromestatus.com/metrics/feature/timeline/popularity/5568
https://chromestatus.com/metrics/feature/timeline/popularity/5569
*Estimated milestones*
Shipping on desktop 150
Shipping on Android 150
Shipping on WebView 150
*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).
/No information provided/
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/6290352295247872?gate=5325345554300928
This intent message was generated by Chrome
Platform Status <https://chromestatus.com>.
--
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
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69f31888.050a0220.11d88c.0845.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69f31888.050a0220.11d88c.0845.GAE%40google.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
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a2a3cdb-8db5-4c78-adf7-9fe5cd8a17ce%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1a2a3cdb-8db5-4c78-adf7-9fe5cd8a17ce%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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6UO95aHWhJngFc4wyyycoEG8wzQkn7wHPapd--0v4Pwdw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6UO95aHWhJngFc4wyyycoEG8wzQkn7wHPapd--0v4Pwdw%40mail.gmail.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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-MENXKnr4bM4Yt8Gy9F8iVGQcYJ0M%2B%2Bf%3DDbZfSiRVHKQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-MENXKnr4bM4Yt8Gy9F8iVGQcYJ0M%2B%2Bf%3DDbZfSiRVHKQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
