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

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

To be clear, I was asking for statistics to understand whether the use-cases in question could be solved in a better way, while preserving privacy principles; whether with solutions such as FPS, or something else. :) 

And by _privacy principles_, I mean prevention of tracking across "first parties" (as Mozilla's own [anti-tracking policy states](https://wiki.mozilla.org/Security/Anti_tracking_policy): _"A first party is a resource or a set of resources on the web operated by the same organization, which is both easily discoverable by the user and with which the user intends to interact."_). 

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

Sorry, I'm not trying to say that all permission prompts are bad. I'm saying that prompts need to make sense to the user within the context of the task they are trying to achieve. IMO, the existing versions of the SAA prompt that I've observed across browsers are hard to understand for anyone who doesn't know what "cookies and site data" means.

I think the difference between SAA, and say, notifications permissions; is that users will probably soon learn that their site functionality is probably going to break if they didn't say "Allow" to SAA. I guess my hypothesis is: will user activity on "good" sites teach them to accept such prompts everywhere else? 

If we expect that users will see the SAA prompt very rarely in their workflow, perhaps there won't be a fatigue problem; but I worry that it's too heavy a hammer - both in terms of placing the onus on users to understand why an embed needs cookies, and in terms of allowing unrestricted access to storage - that is trying to solve for many exceedingly common usecases that exist on the web today. While SAA is a temptingly simple solution to me (as a browser engineer), I can't help wanting to find ways to _reduce_ usage/usecases for SAA. :)

> Granting a powerful feature without consent because consent would be annoying is not what we want.

Absolutely. Chrome is following a similar mantra. For powerful features such as federated login, we are also investing in [WebID](https://github.com/WICG/WebID) which similarly asks for user consent. Perhaps something like [Secure Payment Confirmation](https://github.com/w3c/secure-payment-confirmation) will be able to serve a similar purpose for payments.

In my opinion, most 3ps have the scale (since they typically provide services for many 1ps) and resources to adopt an appropriate purpose-built API with strong privacy properties. First-Party Sets allows 1ps to keep legacy behavior without violating anti-tracking principles (we checked across [multiple browsers' policy statements](https://github.com/privacycg/first-party-sets#defining-acceptable-sets)).

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

I was thinking of the "Temporary Compatibility Fix: Automatic Storage Access for Popups" section described [here](https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/); but maybe this has since been removed?

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

We are well aligned that any availability of information to third-parties must be either gated by a meaningful prompt, or by limiting/aggregating the information. The point though is that "third-party" isn't well defined on the web today. IMO, forcing site authors of the same "first-party" to move everything to a common registrable domain, with the only other available alternative being to add new consent prompts, would be unfortunate. It is entirely possible that some use-cases for FPS could make do with a promptless solution such as partitioned state, but many can't.


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