Contact emails bra...@microsoft.com, johann...@chromium.org, cfred...@chromium.org
Explainer https://github.com/privacycg/storage-access Specification https://privacycg.github.io/storage-access (Merging to HTML is tracked in https://github.com/whatwg/html/issues/9000) Design docs Original Design <https://docs.google.com/document/d/1q5Q-8MJcfZamGAXLpjiXiPYR1Tov5JOGw0Z8Fv0TWFk> Updates to enable per-frame grants <https://docs.google.com/document/d/1tMFYW_6Av8x-6ercbnMFUtBqpfvT97Nt8Jffsx1qve0/edit> Summary Browsers may block third-party resources from accessing cookies and other storage for privacy and security reasons. The most popular reason is cross-site tracking prevention. Such blocking breaks authenticated cross-site embeds such as commenting widgets, embedded payment providers, and subscribed video services. The Storage Access API provides a means for authenticated cross-site embeds (iframes) to check their blocking status and request access to cross-site cookies if they are blocked. As a Chromium default, we intend to ship the Storage Access API without user-facing permission prompts, instead relying on information from First-Party Sets to determine which sites should be granted storage access. The request is auto-denied outside of First-Party Sets <https://github.com/WICG/first-party-sets>. However, there is a flag that allows other Chromium-based browsers to show user permission prompts. This is utilized e.g. in Microsoft Edge, but the Edge team also intends to support integration with First-Party Sets after Chrome ships (see separate I2S on FPS). Blink component Blink>StorageAccessAPI <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI> TAG review https://github.com/w3ctag/design-reviews/issues/807 TAG review status Positive <https://github.com/w3ctag/design-reviews/issues/807#issuecomment-1431464692> Risks Interoperability and Compatibility The API surface itself is simple (examples here <https://github.com/privacycg/storage-access#the-api>). The API does not impact the web platform unless pages explicitly invoke it. Different browser implementations may react differently to storage access requests (e.g. the user flow for Safari <https://webkit.org/blog/11545/updates-to-the-storage-access-api/> or Firefox using heuristics <https://searchfox.org/mozilla-central/rev/611660bff9e6d52f1769bf216a7fbd12ece4d2d2/dom/base/Document.cpp#17626>) and likely will choose to use different heuristics and/or user-signals. These heuristics already vary among browsers shipping this API, so sites cannot rely on the storage access request succeeding in any specific situation. A goal of the API is to allow browser vendors to apply rules that they think best serve their users while allowing sites to navigate those implementation differences. We are still working on reaching alignment across browsers where possible. Gecko: Shipped ( https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API) WebKit: Shipped (https://webkit.org/blog/8124/introducing-storage-access-api) Web developers: Positive There has been great developer interest in the Storage Access API, given that it provides the only predictable way of working with cross-site cookies in many browsers. Various developers have chimed in on https://github.com/whatwg/html/issues/3338 and filed issues on https://github.com/privacycg/storage-access. To summarize, there seems to be general support for the idea of providing an API like this, but opinions have greatly differed on what the provided capabilities should be. We recognize that the current iteration of the SAA is limited in some capabilities, e.g. no access to DOM Storage (recently also removed in Firefox <https://groups.google.com/a/mozilla.org/g/dev-platform/c/qXbgQc7WoxM/m/wQ5MrQ5ABwAJ>), and are considering potential future improvements. An example of this kind of mixed-but-positive feedback is a recent presentation by the Google Workspace team: https://github.com/privacycg/meetings/issues/25 Other signals: Ergonomics The Storage Access API doesn't provide the same developer ergonomics as "plain" cookies, for privacy and anti-abuse reasons. Notably, it is built for specific use cases that involve an iframe that a user interacts with to perform some kind of login/authentication, such as embedded comment widgets. Cross-site cookie access in non-interacted/non-authenticated user flows, such as for online ads, is generally out of scope for this API. To provide better developer ergonomics in non-iframe use cases for access to cross-site cookies within a first-party set, we intend to ship an extension to the Storage Access API called "requestStorageAccessFor <https://github.com/privacycg/requestStorageAccessForOrigin/>" (see related I2S). However, that API should be considered an enhancement and not directly covered by this intent Activation For this initial release, Chrome is shipping the Storage Access API without a user prompt. Access will be granted based on First-Party Sets (see related I2S). This means the same activation risks as for the First-Party Sets I2S apply here as well. 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 Debuggability Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? No. This will be supported on Windows, Mac, Linux, Chrome OS, and Android, but will not initially be supported on Android WebView. 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 Note that in writing these tests we're dealing with some underlying test framework issues, such as - Flaky testdriver.bless/click support in cross-origin iframes ( https://bugs.chromium.org/p/chromium/issues/detail?id=1066891) - Lack of a (well-functioning) WebDriver API for blocking 3P cookies ( https://crbug.com/1408969 <https://bugs.chromium.org/p/chromium/issues/detail?id=1408969>) The resulting test coverage isn't terrible, but we're still working to improve these underlying conditions to ensure better coverage of edge cases and less flakiness on CI. Flag name StorageAccessAPI Requires code in //chrome? True, as we’re adding a new permission and integrating with FPS. As mentioned in the FPS I2S, Chromium-based browsers should be able to consume the list through component updater. Tracking bug https://crbug.com/989663 Estimated milestones Shipping in M113. Anticipated spec changes We recently made significant changes <https://github.com/privacycg/storage-access/issues/122> to the SAA that improve the security posture and overall API design. Most notably, the new design has consensus across all three browsers, greatly reducing interop and compat risks. There are still some aspects of the API that are under active discussion <https://github.com/privacycg/storage-access/issues>. Most of the discussed changes will extend the capabilities of the API and should be backwards-compatible (with one known exception <https://github.com/privacycg/storage-access/issues/154>, where it’s TBD whether the breaking change across all browsers is worth the gain). Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5612590694662144 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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4hnt1Rd5WSC%3DFU9dQriOP%3DKF0Cz9McxoT2_7UgP0u%3DKPw%40mail.gmail.com.
