Intent to Ship: Opaque origin for data: URL Dedicated and Shared Workers

[Chromestatus]

Contact emails

yyana...@google.com

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

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.

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?

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.

[Daniel Clark]

> Is this feature fully tested by web-platform-tests?

> No
> https://wpt.fyi/results/webmessaging/broadcastchannel/opaque-origin.html

Should this say “yes” or are there more tests that should be written than just the linked one?

--
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/69f31888.050a0220.11d88c.0845.GAE%40google.com.

[Yoshisato Yanagisawa]

Yes.  Good catch!

That is the test for this feature.  Updated the chromestatus.

2026年5月1日(金) 6:02 Daniel Clark <dan...@microsoft.com>: