Intent to Ship: Storage Access API with Prompts

3 460 zobrazení
Přeskočit na první nepřečtenou zprávu

Chris Fredrickson

nepřečteno,
2. 8. 2023 16:47:4102.08.23
komu: blink-dev
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

nepřečteno,
2. 8. 2023 17:02:3502.08.23
komu: Chris Fredrickson, blink-dev


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

nepřečteno,
7. 8. 2023 14:47:4507.08.23
komu: blink-dev, Mike Taylor, 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

nepřečteno,
7. 8. 2023 18:46:4107.08.23
komu: blink-dev, Chris Fredrickson, Mike Taylor
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

nepřečteno,
8. 8. 2023 12:08:4308.08.23
komu: blink-dev, Alex Russell, Chris Fredrickson, Mike Taylor
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

nepřečteno,
16. 8. 2023 11:52:4016.08.23
komu: blink-dev, Chris Fredrickson, Alex Russell, Mike Taylor
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

nepřečteno,
16. 8. 2023 12:37:1116.08.23
komu: Alex Russell, blink-dev, Chris Fredrickson, Mike Taylor
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.

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

nepřečteno,
16. 8. 2023 13:31:4816.08.23
komu: Jeffrey Yasskin, Alex Russell, blink-dev, Chris Fredrickson, Mike Taylor
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

Yoav Weiss

nepřečteno,
22. 8. 2023 10:50:0022.08.23
komu: Chris Harrelson, Jeffrey Yasskin, Alex Russell, blink-dev, Chris Fredrickson, Mike Taylor

Mike Taylor

nepřečteno,
22. 8. 2023 13:26:1022.08.23
komu: Yoav Weiss, Chris Harrelson, Jeffrey Yasskin, Alex Russell, blink-dev, Chris Fredrickson

LGTM3

Chris Fredrickson

nepřečteno,
26. 9. 2023 11:20:2926.09.23
komu: blink-dev, Mike Taylor, Jeffrey Yasskin, Alex Russell, blink-dev, Chris Fredrickson, Yoav Weiss, Chris Harrelson
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.
--
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.
--
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.
--
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

nepřečteno,
16. 10. 2023 13:42:4716.10.23
komu: blink-dev, Chris Fredrickson, Mike Taylor, Jeffrey Yasskin, Alex Russell, blink-dev, Yoav Weiss, Chris Harrelson
We're now rolling this feature out to 100% on Chrome Stable (M117 and later).
Odpovědět všem
Odpověď autorovi
Přeposlat
0 nových zpráv