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/bcf02d1d-38f4-452c-aae0-f6ed629b3f69n%40chromium.org.
