With great frustration, LGTM3. This intent should probably not be shipping in this shape. Apple screwed up the design of this API in epic style, were informed as much *before they shipped*, and we are now shipping two separate APIs in this space, none of which really do what we think an API of this style should (to Mike's point).
It's late in the game, and I understand why some folks here think we need to ship this feature, but I'd *also* be LGTM for a renamed/redesigned version of this feature (ala an extension of requestStorageAccessFor() with arguments to cover the current frame as well). Would suggest the feature owners here strongly consider that route before finally submitting the CL to enable this by default. Best, Alex On Wednesday, March 29, 2023 at 2:10:20 PM UTC-7 Mike Taylor wrote: > LGTM2 (shame we can't rename this the Cookie Access API... :)) > On 3/29/23 5:40 AM, Yoav Weiss wrote: > > LGTM1 > > On Mon, Mar 20, 2023 at 10:34 PM 'Johann Hofmann' via blink-dev < > [email protected]> wrote: > >> Contact emails >> >> [email protected], [email protected], [email protected] >> >> 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 [email protected]. >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4hnt1Rd5WSC%3DFU9dQriOP%3DKF0Cz9McxoT2_7UgP0u%3DKPw%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 on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUr%2BD%2BS0okoTeHy8dDA61JvLnmAqmRt96-1QQcwsC6nZw%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUr%2BD%2BS0okoTeHy8dDA61JvLnmAqmRt96-1QQcwsC6nZw%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/630870ee-be00-4d8d-bd28-971626eefbd2n%40chromium.org.
