Mozilla standards position request: https://github.com/mozilla/standards-positions/issues/1200 WebKit standards position request: https://github.com/WebKit/standards-positions/issues/476
On Wednesday, March 19, 2025 at 4:40:17 PM UTC-4 Chris Fredrickson wrote: > 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/aa70d40a-5894-437b-9538-38e946e32c80n%40chromium.org.
