Thanks for that testing information. I think that's enough testing to support shipping this change.
LGTM1 On Thu, May 7, 2026 at 3:30 AM 'Yoshisato Yanagisawa' via blink-dev < [email protected]> wrote: > Sorry for the slow reply, > > Regarding the testing for this feature: We identified sites using data URL > Dedicated Workers ( > https://chromestatus.com/metrics/feature/timeline/popularity/5568) and > Shared Workers ( > https://chromestatus.com/metrics/feature/timeline/popularity/5569). > > I inspected whether these sites use BroadcastChannel, localStorage, > indexedDB, or self.origin. For 63 sites, no *Workers started for a few > seconds after page load. For the remaining 119 sites, no issues were > detected. We performed dynamic inspection (injecting a trap) on more than > half of them. > > Debuggability depends on the API the page uses: > > - If they use the storage API, a SecurityError should occur, which is > easy to detect. > - If they use BroadcastChannel, it will silently fail. > - If they use self.origin, it will return null. This is easy to > detect, although the change is implicit. > > The good news for BroadcastChannel is that its usage for this specific > case appears to be very small now ( > https://chromestatus.com/metrics/feature/timeline/popularity/5856). > > I hope this addresses your concerns regarding the safety of this change in > non-enterprise environments. > > 2026年5月7日(木) 0:16 Vladimir Levin <[email protected]>: > >> 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/CAPNB-6UO95aHWhJngFc4wyyycoEG8wzQkn7wHPapd--0v4Pwdw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6UO95aHWhJngFc4wyyycoEG8wzQkn7wHPapd--0v4Pwdw%40mail.gmail.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/CAOMQ%2Bw-MENXKnr4bM4Yt8Gy9F8iVGQcYJ0M%2B%2Bf%3DDbZfSiRVHKQ%40mail.gmail.com.
