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

> Question: could the first party set enforcement be accomplished using existing data available through certificate validation or existing data in the DNS registration system? This would address the internationalization issues raised as well and would not require spinning up an independent enforcement authority...

We did consider whether EV certificates, which perform a kind of organizational validation could be used for First-Party Sets; but were discouraged from going in that direction by TLS/WebPKI experts. The primary reason is that doing so would couple TLS certificates (which are intended for connection encryption), with FPS (which is intended to convey a notion of site identity); and that coupling site identity with encryption would actually result in bad outcomes for users.  Please see [this comment](https://github.com/privacycg/first-party-sets/issues/12#issuecomment-618049494) by Ryan Sleevi for more details.

I do agree that either using the information in the DNS registration system, or plugging in to the domain registration process may be the right long term direction. Regarding use of existing/publicly accessible information from domain lookups; we would likely need to account for failover situations - e.g. when the domain owner has set up privacy protection; so perhaps plugging FPS validation into the domain registration process itself might be the thing to consider?

> Hi @krgovind we discussed today at our [virtual f2f](https://github.com/w3ctag/meetings/tree/gh-pages/2021/12-Madripoor)... We're concerned we may be going around in circles on this. One idea we had to break the cycle is to refocus our attention on a specific use cases linked to FPS - e.g. [Same Party Cookies](https://github.com/w3ctag/design-reviews/issues/595) or possibly CHIPS. This would enable us to go back to the problems we're trying to solve and maybe find better ways to try to solve them. Would that make sense to you? We could then take a look at the specific user needs addressed by those designs and evaluate FPS on the basis of those needs. Yes: we had previously said that we would hold off on reviewing Same Party Cookies until we reviewed FPS - but by talking about Same Party Cookies in isolation we may be able to make some progress here.

Is the intention to zoom in on specific applications for FPS? I am happy for us to start with SameParty cookies and CHIPS. However, does it also make sense to also touch upon the intended use of FPS in other platform features that are currently in development, such as sharding FedCM's [directed identifiers](https://wicg.github.io/FedCM/#mitigation-directed-identifiers) by FPS, and [navigational tracking mitigations](https://github.com/privacycg/nav-tracking-mitigations) exempting navigations across domains within the same FPS from anti-tracking mitigations? I think the purpose of FPS serving as a _privacy boundary_ for the web really manifests itself when we look at the full expanse of applications.


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

Message ID: <w3ctag/design-reviews/issues/342/1006948418@github.com>