Hi Alex, thank you for expressing your concerns and for approving this in spite of them :)
I understand your frustration on the difficult process that this went through and agree that many mistakes were made. However, I want to gently push back on the idea that this resulted in us shipping an API that we're unhappy with (arguably the name is what we're really most unhappy about). Through our involvement we were able to go back to key design concerns (such as the security considerations linked in the I2S, or observability of the grant through permissions) and found Apple and Mozilla open to our feedback and ideas for how to change the API, potentially at the cost of compat for them (though I don't think they've yet implemented the latest per-frame spec changes). This gave us the simplified per-frame design that we have now, in addition to the requestStorageAccessFor API that gives access to the (conceptually) same capabilities with different semantics. There are still some wrinkles that won't make everyone happy, which may just be the result of designing an API under complicated constraints. We also weren't able to get to everything on the feature wishlist, which includes access to DOM Storage APIs and an easier workflow for developers when users load a fresh document that has already been granted storage access, but I think we're at a point where those things should be relatively painless additions to the API (in terms of backwards compat for developers) vs. the big overhauls we made now, before shipping in Chromium. Again, this isn't to suggest anyone repeat what happened here, but I don't think we're quite as dire on this API or feel like we "need" to ship it without wanting to. Cheers, Johann On Wed, Apr 12, 2023 at 6:00 PM Alex Russell <slightly...@chromium.org> wrote: > 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 < >> blink-dev@chromium.org> wrote: >> >>> 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 >>> <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 blink-dev+unsubscr...@chromium.org. >> >> 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 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_OO4gEjVWNtNANyM9rJTqv9s88dnQsLxQuNfVsfuNOoQ5aBw%40mail.gmail.com.
