Also LGTM, thank you for the analysis Yoshisato! Rick
On Thu, May 7, 2026 at 3:49 PM Mike Taylor <[email protected]> wrote: > Thank you, LGTM3 > On 5/7/26 11:30 a.m., Vladimir Levin wrote: > > LGTM2 > > On Thu, May 7, 2026 at 11:19 AM 'Chris Harrelson' via blink-dev < > [email protected]> wrote: > >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-MENXKnr4bM4Yt8Gy9F8iVGQcYJ0M%2B%2Bf%3DDbZfSiRVHKQ%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/CAFUtAY-9SYi2uXqerM44LUAqAf%3Dtk2zjJ_MCYfvTfehpLGyWrQ%40mail.gmail.com.
