Intent to Ship: Storage Access API (within First-Party Sets)

[Johann Hofmann]

Contact emails

bra...@microsoft.com, joha...@chromium.org, cfre...@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

Updates to enable per-frame grants 

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. 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

TAG review

https://github.com/w3ctag/design-reviews/issues/807

TAG review status

Positive

Risks

Interoperability and Compatibility

The API surface itself is simple (examples here). 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 or Firefox using heuristics) 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), 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" (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?

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)

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 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. Most of the discussed changes will extend the capabilities of the API and should be backwards-compatible (with one known exception, 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.

[Yoav Weiss]

LGTM1

--
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+...@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.

[Mike Taylor]

LGTM2 (shame we can't rename this the Cookie Access API... :))

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.

[Alex Russell]

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

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[Johann Hofmann]

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

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.

--
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+...@chromium.org.