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 (eg, 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 (eg, 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 (eg links to known github issues in the project 
for the feature specification) whose resolution may introduce web 
compat/interop risk (eg, 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.

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

Reply via email to