Sorry for the delay, for some reason Alex's message didn't show up in my inbox!
*Alex*: Up to 100% of Storage Access API (SAA) usage could be affected, if we assume that *every *usage of SAA later involves a cross-origin, same-site network request that is required to be credentialed. However, it's also possible that *none* of the network traffic in the cross-origin, same-site bucket actually needs to be credentialed, so the breakage is *somewhere* between 0% and 100% of SAA usage... which is not very helpful. It's impossible for the browser to measure more specifically (other than checking the credentials mode), since the browser can't tell that cookies are required to be present on a given request. While writing this I realized that the browser *does *know the request's credentials mode, so the breakage estimate can at least exclude the portion of requests that opt out of cookies entirely. I'll update the metric accordingly; I expect this will reduce the 9% figure a bit. *Vlad*: Not exactly, the upper bound of breakage is 0.08% of pageloads (under the same assumptions as above). In practice I expect the real figure to be much lower, as not every such iframe will issue a cross-origin, same-site request; and of those that do, probably not all of those requests actually need to be credentialed. The 9% figure is the proportion of network traffic that could be affected from iframes that have called SAA. E.g., if we assume that every iframe that calls SAA then sends 11 network requests (and one of them is cross-origin same-site), then about 9% of that traffic falls into the bucket that's changing in this launch. As that example illustrates, it's possible that *all* of the 0.08% of pageloads that use SAA are affected by this launch; it's also possible that only a small fraction are affected. Re: nature of the breakage, the cross-origin same-site subset of network requests would no longer carry cross-site cookies from an iframe that has called `document.requestStorageAccess()`, by default. The real consequences of that could be anything from a completely broken experience, to unnoticeable; but since sites use cookies in such a variety of ways, it's kind of impossible to predict where on that spectrum this will fall. Re: vendor signals, yes, I'll do that. On Wednesday, March 19, 2025 at 11:23:28 AM UTC-4 Vladimir Levin wrote: > Is it a correct reading that that it's roughly 9% of 0.08% of pageloads > that will be affected? That still seems large. Can you speak to the nature > of the breakage? Specifically, do the sites that currently use it become > unusable or is it a milder change from that? > > On the process side, do you mind filing vendor signals (Gecko and Webkit) > for this? > > Thanks, > Vlad > > On Monday, March 17, 2025 at 2:28:23 PM UTC-4 Alex Russell wrote: > >> Hey Chris, >> >> Do you have a sense for what fraction of Storage Access API use (yes, I >> know it's low) will be impacted by this change? Is there a way to tell? >> >> Best, >> >> Alex >> >> On Wednesday, March 12, 2025 at 9:04:37 AM UTC-7 Chris Fredrickson wrote: >> >>> Contact emails >>> >>> cfred...@chromium.org >>> >>> Explainer >>> >>> None >>> >>> Specification >>> >>> https://github.com/privacycg/storage-access/pull/213 >>> >>> Summary >>> >>> Adjusts the Storage Access API semantics to strictly follow the Same >>> Origin Policy, w.r.t. security. I.e., using document.requestStorageAccess() >>> in a frame only attaches cookies to requests to the iframe's origin (not >>> site) by default. >>> >>> Note: the CookiesAllowedForUrls enterprise policy and/or Storage Access >>> Headers may still be used to unblock cross-site cookies. >>> >>> >>> Blink component >>> >>> Blink>StorageAccessAPI >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EStorageAccessAPI%22> >>> >>> TAG review >>> >>> Not requested since this is a small change to the existing Storage >>> Access proposal that improves security and has no impact on privacy or user >>> experience. >>> >>> TAG review status >>> >>> N/A >>> >>> Risks >>> >>> Interoperability and Compatibility >>> >>> The Storage Access API specification is imprecise about its integration >>> with Fetch, and does not define whether same-site, cross-origin requests >>> ought to be credentialed after an iframe has used the Storage Access API. >>> >>> Chrome and Firefox both currently include cookies on these same-site >>> cross-origin requests, so there is some risk to making their behaviors >>> diverge. We have discussed this with other browser vendors and they >>> expressed that they were not concerned with Chrome making this change. >>> >>> However, the Storage Access API currently has very little usage in >>> Chrome (0.08% of pageloads). The cross-origin, same-site subset of usage is >>> an even smaller portion (9% of network requests from affected pageloads). >>> So, the impact of breakage is small regardless. >>> >>> Sites that are broken by this can fix themselves using the >>> recently-shipped Storage Access Headers >>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/gERgwZfN_-E/m/QIJbT1zUCgAJ> >>> >>> feature. >>> >>> >>> Gecko: No signal >>> >>> WebKit: No signal >>> >>> Web developers: Positive ( >>> https://github.com/privacycg/storage-access/issues/210#issuecomment-2527687508 >>> ) >>> >>> Other signals: >>> >>> 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? >>> >>> None >>> >>> >>> Debuggability >>> >>> Cookies (and the reasons why they are included/excluded) are debuggable >>> via the Network panel in Chrome DevTools. >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)? >>> >>> Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? >>> >>> Yes >>> >>> >>> https://wpt.fyi/results/storage-access-api/requestStorageAccess-cross-origin-fetch.sub.https.tentative.window.html >>> >>> >>> Flag name on about://flags >>> >>> storage-access-api-follows-same-origin-policy >>> >>> Finch feature name >>> >>> StorageAccessApiFollowsSameOriginPolicy >>> >>> Requires code in //chrome? >>> >>> False >>> >>> Tracking bug >>> >>> https://crbug.com/379030052 >>> >>> Estimated milestones >>> >>> 136 >>> >>> >>> Anticipated spec changes >>> >>> None anticipated. >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5169937372676096?gate=5134161335287808 >>> >>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bdbfd19f-b77e-4e5f-a0c2-c101647d0704n%40chromium.org.
