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/CAFUtAY9zUSKYfMJY%2B%2ByFF2kiNSy%2BxpZvEVabazeduGM1e6%2BATw%40mail.gmail.com.
