Re: [w3ctag/design-reviews] First-Party Sets (#342)

> > The Storage Access API could be (or already has been) used to fix these issues. FPS could not. The benefit of the Storage Access API is that it can **also** be used to fix many of the types of things we might want to fix with FPS. Either way, we are going to have to work through a more generic approach to resolving breakage from reliance on cross-site state and we prefer to focus our efforts on these generic solutions.
> 
> I think FPS can be used to whittle down many of the use-cases where users may feel compelled to grant storage access today. If you have any statistics around commonly granted pairs of storage access, it may be an interesting case study to see if there are alternate solutions for them.

We don't collect this kind of data from our users, but I agree that in the future "raw" cross-site cookie access should be a last resort. This applies to FPS as well, though.

> My primary concern with the Storage Access API is that the prompt is not something that most users can understand, and that it will suffer the same consent fatigue problems as the widespread "cookie notice" prompts.

Sorry for going slightly off-topic but I think we should discuss these claims about prompt fatigue on the Storage Access API because they seem connected to the idea of having a consent step for something like FPS. There are valid concerns to showing permission prompts, but I'd like to show why I'm quite confident that the Storage Access API prompt is in a good position to avoid them:

- **Concern: "Users might not understand the Storage Access API prompt."** Yes, not all of them will, despite our best efforts to give simple explanations. Will that have bad consequences? Probably not. All available Firefox Telemetry (e.g. [on notifications](https://mozilla.report/post/projects/notification_permissions.kp/index.html)) shows that users do not tend to blindly accept unwanted or surprising prompts. On the contrary, more spammy, invasive and surprising prompts have overwhelming rates of denial in our statistics. This can be further influenced by prompt design. I'm a bit surprised that the Chrome team is making the argument that prompts are generally bad and confusing when we have seen many examples of extremely powerful features such as WebUSB being gated behind permission prompts brought forward by Chrome folks.

- **Concern: "Bad actors will start spamming this prompt at every opportunity and/or coerce the user into accepting it."** We have already fought many instances of prompt spam and abuse and I'm not worried about this prompt, because the cost/benefit ratio just doesn't add up for non-essential use cases. To create anything remotely resembling a tracking network a third party would have to beat the strict storage access API requirements and get user consent several times. If this happens, it will be possible for browsers to detect and prevent.

- **Concern: "Too many sites need this, users will be annoyed."** From several months of running State Partitioning + Storage Access API in pre-release Firefox it's become clear that there are just a few very common valid use cases of cross-site cookies such as federated login, and a long tail of other diverse uses. Storage Access API is able to solve both, but only the former will really account for "prompt fatigue" and as such we should discuss limited or consent-oriented solutions to these common problems. Granting a powerful feature without consent because consent would be annoying is not what we want.

- **Concern: "This is another instance of the (in-content) cookie consent prompt."** I don't think that this is a fair comparison. As mentioned before, this prompt is entirely controlled by the user agent and can not be designed in a way that tricks the user into giving more consent than they would normally want to. It's also entirely contextual and bound to specific cookie use of a named third party, while at least in Europe the common interpretation of the law seems to be "show this big dialog at the beginning and we're safe". This is literally impossible with the Storage Access API.

> Since browsers that currently support Storage Access API only require it under specific circumstances (heuristics, blocklists, etc.), I suspect we haven't seen it's full-scale impact.

Safari does not use any heuristics to relax showing the prompt AFAIK.

> Also, note that developers that have adopted Storage Access API might need to implement extra user friction/notices to ensure that users grant them storage access so site functionality isn't broken. As an example, [see how Zendesk](https://support.zendesk.com/hc/en-us/articles/360034788653-Zendesk-support-for-cookie-restricted-browsers-Safari-Chrome-) shows a "Safari cookie requirements" notice and instructs users to click "Allow".

Yes, this pre-prompting pattern has been recommended by both the [Chrome](https://developers.google.com/web/fundamentals/push-notifications/permission-ux) and Firefox teams in the past. It can obviously be done badly but it's in the interest of the site to give the user as much context as possible as to why they are seeing a permission prompt and what the functionality is needed for. How this is presented is largely something that the first party can control (in this case the first party chose to leave it to Zendesk). I don't see any malicious use here, though I suspect that this could also have been solved by only state partitioning without any kind of cross-site cookie access, which is something we should encourage in the future.

>   First-Party Sets is something that is trying to solve a generic need of multi-domain sites. Multi-domain sites are not unique to large conglomerates.
> 
>  I am not suggesting that cross-party usecases should all be forced to using the Storage Access API. I would like to ask that perhaps we need to understand the requirements better and recommend purpose-built APIs as appropriate for those use-cases.

What are the requirements for FPS that could be built using APIs that either ensure better user consent or reduce the amount of information available to third parties?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/342#issuecomment-823145498