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/CADsXd2MVY1SqSdaP4iNWrHYNbvu9EtqAnxwAg%2B3P13Za4SR6FQ%40mail.gmail.com.
