Add Chrome's position on the Storage Access API #165
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bvandersloot-mozilla
approved these changes
Feb 14, 2023
|
Thanks Ben! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR updates Google Chrome’s position on the Storage Access API.
In short, we are currently experimenting with the Storage Access API, with the aim to eventually ship it to release versions.
We see the Storage Access API as a useful tool for developers who want to continue supporting cross-site user experiences through the flexibility of third-party cookies. We still think that purpose-built APIs have many advantages for UX and privacy, and we believe that, in the long term, they should cover the majority of cross-site flows on the web. However, we also think that the SAA can be part of this strategy.
Because of its power and flexibility, we think that storage access grants need to be gated on strong and clear signals of user benefit and/or intent. We are currently investigating two possible ways to determine this:
First-Party Sets: Through gating SAA auto-grants on FPS, Chrome can determine user-beneficial usage of cross-site cookies through developer-submitted metadata, reducing the number of prompts we show our users.
User prompts: We are also exploring ways to allow storage access outside of the restrictions of FPS, by providing users with the context and choice to allow or deny access. We remain concerned about unnecessarily exposing users to prompts that they don’t understand, or causing a large number of prompts to proliferate on the web (and the resulting prompt fatigue). We are committed to crafting an experience that works both for users and developers.
There could be other trust signals to gate storage access in the future, and we are interested in identifying these.
We also noted security concerns to address on SAA, and think that there are different use cases for cross-site cookie access that can not be solved well through a single API (especially with regard to the security concerns). For that reason we have proposed the requestStorageAccessForOrigin variant as a related effort.