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.
