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

@torgo - I'd like to address your questions from earlier in the thread, because we've been able to put more thought into the policy enforcement, and published [this expanded UA policy proposal](https://github.com/privacycg/first-party-sets/blob/main/ua_policy_proposal.md) a few weeks ago.

> It's not clear that the registration criteria that the PR talks about would stop the kind of abuse case that we envision, specifically ad networks using this technology effectively as third party cookies after third party cookies have been deprecated. Given that, would it be possible to design the technology itself to mitigate against those abuse cases? I see the issue referenced above but is this being given serious consideration?

Ad networks would not be able to use this technology as third-party cookies because of two requirements:

* UA Policy requirement: Only domains within the same FPS can access cross-site (third-party) cookies; and only domains that conform to the [UA policy](https://github.com/privacycg/first-party-sets/blob/main/ua_policy_proposal.md) can belong to the same FPS. Since the proposed UA policy requires that the "Domains must have a common owner, and common controller.", this would disqualify ad networks that typically operate over groups of domains that have separate owners/data controllers.
* Technical requirement: No domain can appear in more than one set ([reference to explainer text](https://github.com/privacycg/first-party-sets#:~:text=no%20domain%20can%20appear%20in%20more%20than%20one%20set.)); so even if an ad network is able to convince a site author to include the ad domain in the site's FPS; that same ad domain cannot participate in another site's FPS.

> Our view is still that any kind of centralized policy-based enforcement of which parties may claim to be together in a set is problematic and that a technical-only enforcement mechanism may be preferable. However they may not be a technical-only enforcement mechanism that works in the real world because of the complex structure of ownership of legal entities and data sharing legislation globally. We await the outcome of these discussions in the Privacy CG and would be happy to spend time reviewing PRs as appropriate.

@rhiaro also touched on similar concerns around centralization, and scalability, which I captured in privacycg/first-party-sets/issues/48, and [just responded to](https://github.com/privacycg/first-party-sets/issues/48#issuecomment-932501941). Please take a read, and let me know if you think that our proposal strikes the right balance between interoperability, scalability, centralization, and abuse-resistance.

-----


> I've opened an issue about fragmentation concerns if FPS is implemented differently in different UAs: [privacycg/first-party-sets#66](https://github.com/privacycg/first-party-sets/issues/66)

Thanks @rhiaro. I just responded on the issue, please take a look.

> Also related to @martinthomson's comment in [privacycg/first-party-sets#62](https://github.com/privacycg/first-party-sets/issues/62):
> 
> > there is a switch that we know how to turn on and off, but we don't know what it is hooked up to.
> > If this switch is not hooked up to the same thing, that a failure of this process.

I [responded](https://github.com/privacycg/first-party-sets/issues/62#issuecomment-911125704) on the issue, and I believe the comment was aimed at attempting to understand the purpose/goal for FPS. As I responded, the primary purpose of FPS is to define a "privacy boundary", or more explicitly, to provide a technical mechanism that the browser can use to distinguish between what is "first-party" and what is "third-party". It turns out that groups within the W3C have on many occasions defined principles around what "first-party" means ([DNT specification](https://www.w3.org/TR/tracking-compliance/#party), [TAG Privacy Principles](https://w3ctag.github.io/privacy-principles/#dfn-first-parties)), but there is no technical manifestation of this principle. Due to the lack of an existing mechanism, browsers have approximated "resource hosted at same registrable domain" to mean "first-party"; but as many browsers are moving towards "on-by-default" privacy protections with rigorous restrictions based on the "first-party" distinction, the approximation is no longer sufficient.


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