Intent to Ship: Storage Access API with Prompts

[Chris Fredrickson]

Contact emails

cfre...@chromium.org, joha...@chromium.org, shu...@chromium.org

Explainer

https://github.com/privacycg/storage-access/blob/main/README.md

https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md

Specification

https://privacycg.github.io/storage-access

Summary

The Storage Access API provides a means for authenticated cross-site embeds to check whether access to unpartitioned cookies is blocked and request access if it is blocked. This request may be surfaced to the user as a prompt, or auto-granted/auto-denied. Chrome will support the Storage Access API by implementing all the behaviors listed in the specification, i.e. with user prompts, and additionally having its own user-agent-specific behaviors. Chrome’s implementation is available for testing starting in Chrome 117.

The Storage Access API is related to other cookie-focused projects like CHIPS and First-Party Sets as preparation for phasing out third-party cookies in Chrome.

Note that Edge previously sent an I2I for the Storage Access API feature (with their own user-agent-specific behavior), and Chrome has previously sent an I2S for support for the Storage Access API gated on First-Party Sets membership (without user prompts). This I2S is intended for support for the API across sites that are not within the same First-Party Set.

Blink component

Blink>StorageAccessAPI

TAG review

https://github.com/w3ctag/design-reviews/issues/807 (review of overall API, not of prompts)

TAG review status

Positive

Risks

Interoperability and Compatibility

There is minor compatibility risk as Firefox and Safari already differ slightly in their user-agent-specific prompt requirements. Chrome's planned behavior is closest to Safari's current behavior, and we aim to standardize as much of this user-agent-specific behavior as possible over time.

Gecko: Shipping

WebKit: Shipping

Web developers: 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.

Other signals: Edge has shipped Blink's previous implementations of this API, which differ from Chrome's plans. We have kept (and intend to continue keeping) Edge engineers in the loop about these changes and there will be feature flags to control Blink's behavior.

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

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. It will be supported on all Blink platforms except Android WebView initially. We may add WebView support in the future.

Is this feature fully tested by web-platform-tests?

No. Browser UI is not testable by WPTs, since that is UA-specific. (The Storage Access API spec itself is tested by WPTs.)

Flag name on chrome://flags

#storage-access-api, #permission-storage-access-api

Finch feature name

StorageAccessAPI, PermissionStorageAccessAPI

Non-finch justification

None

Requires code in //chrome?

True

Estimated milestones
    Shipping on desktop: 117

    Shipping on Android: 120

Anticipated spec changes

Some minor changes are expected in order to properly take user settings into account: https://github.com/privacycg/storage-access/pull/174 and an analogous change for document.requestStorageAccess.

There is ongoing discussion on how to offer access to unpartitioned DOM storage via this API.

The spec has been in incubation being co-developed by all three browser engines for a while and is close to graduation as tracked here: https://github.com/whatwg/html/issues/9000.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5085655327047680

Links to previous Intent discussions

Intent to prototype: Intent to Prototype: Storage Access API with Prompts

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 8/2/23 4:47 PM, Chris Fredrickson wrote:

Contact emails

cfre...@chromium.org, joha...@chromium.org, shu...@chromium.org

Explainer

https://github.com/privacycg/storage-access/blob/main/README.md

https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md

Specification

https://privacycg.github.io/storage-access

Summary

The Storage Access API provides a means for authenticated cross-site embeds to check whether access to unpartitioned cookies is blocked and request access if it is blocked. This request may be surfaced to the user as a prompt, or auto-granted/auto-denied. Chrome will support the Storage Access API by implementing all the behaviors listed in the specification, i.e. with user prompts, and additionally having its own user-agent-specific behaviors. Chrome’s implementation is available for testing starting in Chrome 117.

The Storage Access API is related to other cookie-focused projects like CHIPS and First-Party Sets as preparation for phasing out third-party cookies in Chrome.

Note that Edge previously sent an I2I for the Storage Access API feature (with their own user-agent-specific behavior), and Chrome has previously sent an I2S for support for the Storage Access API gated on First-Party Sets membership (without user prompts). This I2S is intended for support for the API across sites that are not within the same First-Party Set.

Blink component

Blink>StorageAccessAPI

TAG review

https://github.com/w3ctag/design-reviews/issues/807 (review of overall API, not of prompts)

TAG review status

Positive

Risks

Interoperability and Compatibility

There is minor compatibility risk as Firefox and Safari already differ slightly in their user-agent-specific prompt requirements. Chrome's planned behavior is closest to Safari's current behavior, and we aim to standardize as much of this user-agent-specific behavior as possible over time.

Could you elaborate on the differences for prompt requirements, and how that might lead to compat issues?

--
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/5e44f071-97ba-41e0-a0cd-7bd3a210d6bdn%40chromium.org.

[Chris Fredrickson]

Hi Mike,

Sure. MDN has a section (which may be incomplete or outdated) on the implementation differences between Safari, Firefox, and Chromium-based browsers. But specifically related to the prompt requirements, there are two aspects that may cause compat issues:

1. Permission lifetime. Storage Access grants have different lifetimes in different browsers, so web developers may have to show a prompt more often than they expect:

   1. Firefox: 30 calendar days.

   2. Chrome: 30 calendar days.

   3. Safari: 30 days of browser usage.

2. User interaction requirement. Whether a user gesture is required by document.requestStorageAccess() is inconsistent across browsers:

   1. Firefox: always requires user interaction. (This is a nonstandard behavior, but it appears Firefox is being updated to not require user interaction in some cases.)

   2. Chrome: requires user interaction unless the user has already granted access.

   3. Safari: always requires user interaction. (This is a nonstandard behavior.)

Since Firefox and Safari currently impose stricter user interaction requirements than what the spec dictates, this could lead to compat issues if web developers assume that browsers don't impose additional browser-specific constraints.

There's one additional aspect, where web developers may not need to call document.requestStorageAccess() at all in certain situations in some browsers (which could lead to broken experiences if web developers assume they can always omit the explicit call):

• Firefox: if foo.example has obtained storage access while embedded under bar.example, and the user loads a bar.example page that includes a foo.example iframe, then that iframe will load with implicit storage access -- without having to call document.requestStorageAccess() first. (This is a deviation from the specification, but this part of the spec was changed relatively recently for security reasons; Firefox is planning to incorporate the recent changes.)

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Alex Russell]

Hey Chris,

Thanks for the details here.

Can you perhaps outline why we didn't take the opportunity here to rename this to better represent what the API actually does? E.g., `requestUnpartitionedCookieAccess()`? And was any effort made to move the API to a more suitable object; e.g. `navigator`? Was this discussed with the TAG?

Best,

Alex

[Chris Fredrickson]

Hi Alex,

I hear you about the method names. However since Safari, Firefox, and Edge had all previously shipped this API using these names and web developers have already begun using it, it would have been disruptive for Chrome to force a rename. We opted to limit the disruption we caused to improving the ergonomics and security posture of the API instead (1, 2, 3, 4, 5, 6), since that was indeed disruptive but there was at least cross-browser interest in making those changes.

Re: navigator vs document, there was previous discussion of this here. We did not specifically ask the TAG about which object they preferred, but they closed their review with no comments. Considering that each document's access is independent of access obtained by other documents (due to the per-frame security model), the choice of document makes some sense to me, personally - but there may be some best practice I'm unaware of.

FWIW, Chrome is exploring ways to use document.requestStorageAccess() to provide access to unpartitioned DOM storage in the future, in which case the current name would be more appropriate.

Chris

[Alex Russell]

Hrm; the TAG had (many years ago, when I served) noted big problems with the shape of this API. It's surprising we're taking it as-is.

[Jeffrey Yasskin]

I see this as the other vendors endorsing Blink's general policy, implied by the wording in https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews, that there's a high bar for name changes after shipping. If this API, which has a clearly inaccurate name and was shipped with no invitation for cross-vendor feedback, isn't worth changing after shipping, then it's not worth changing most APIs that Blink ships first either.

Jeffrey

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/5e44f071-97ba-41e0-a0cd-7bd3a210d6bdn%40chromium.org.

--

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/8884e737-21c8-4c01-9cc3-caaf125e52e2n%40chromium.org.

[Chris Harrelson]

I agree with Chris F. that it's not worth the disruption to change the name or its location, and that leaving the name as-is, even if suboptimal, is a better outcome for web developers.

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnGvxVw8CwP1sPk-%2Bxf-ObjuTxXe2a9LdaSe2g6wv0d1w%40mail.gmail.com.

[Yoav Weiss]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9iRq4Z75qEhWP9rFAGUStasGVCi6wc4btVT2-CoJiuHw%40mail.gmail.com.

[Mike Taylor]

LGTM3

[Chris Fredrickson]

Belatedly updating this thread in case folks are monitoring it -- we've enabled this feature on 1% of Chrome Stable (M117) clients. We'll update this thread again when we roll out to a higher percentage.

As a reminder: if people would like to test this feature out before we've fully shipped it, they can can follow the testing instructions here: https://github.com/cfredric/chrome-storage-access-api#testing-instructions

LGTM3

LGTM2

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/5e44f071-97ba-41e0-a0cd-7bd3a210d6bdn%40chromium.org.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8884e737-21c8-4c01-9cc3-caaf125e52e2n%40chromium.org.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnGvxVw8CwP1sPk-%2Bxf-ObjuTxXe2a9LdaSe2g6wv0d1w%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.

[Chris Fredrickson]

We're now rolling this feature out to 100% on Chrome Stable (M117 and later).