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/a526bf3c-6ecd-4ac5-9726-c8db7e9f5d51n%40chromium.org.
