> 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 Should this say "yes" or are there more tests that should be written than just the linked one?
From: [email protected] <[email protected]> On Behalf Of Chromestatus Sent: Thursday, April 30, 2026 1:53 AM To: [email protected] Cc: [email protected] Subject: [EXTERNAL] [blink-dev] Intent to Ship: Opaque origin for data: URL Dedicated and Shared Workers Contact emails [email protected]<mailto:[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. 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]<mailto:[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/CH3PR00MB2511606DE8634612E74661B4C5352%40CH3PR00MB2511.namprd00.prod.outlook.com.
