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.
johannhof
commented
1 year ago
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.