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

> > This is certainly not true for Firefox's Default ETP mode, because the Disconnect entities list groups facebook.com and instagram.com as one entity (reference).
> 
> Good point and thank you for the correction. I only mean that the "site" is usually the privacy boundary.
> 
> The Moz folks should correct me if I'm wrong, but current Firefox partitions all cookies by default, not just sites labeled by disconnect (with some exceptions for compat / existing SSO flows). But, in general, the site is a privacy boundary in at least Firefox, Safari and Brave (though with differences between them on how to handle cases that expect privacy harming, cross site data flows currently).

That's right. Let me add a bit more context to what we've [shared before](https://github.com/privacycg/proposals/issues/17#issuecomment-641691610) when this was brought up in a past First Party Sets discussion:

We started using Disconnect's entity list as part of our original "Tracking Protection" feature, which is a content blocking feature. When blocking content, it's absolutely necessary to have an entity list for web compatibility reasons. For example, Facebook's `fbcdn.net` domain is on Disconnect's blocklist and would thus be blocked when visiting `facebook.com`. This resource blocking would make that page entirely unusable. When we developed ETP (i.e., cookie blocking based on the same blocklists) we continued to have it respect the entity list, in part for consistency across our blocklist-based features and in part out of an abundance of caution to avoid web compat issues. I'm sure there are some instances where the entity list prevents cookie blocking breakage, but I suspect that many of the rules on that list aren't "required" for a cookie blocking feature.

As Pete said, we believe site is the right privacy boundary for passive cookie access. Our state partitioning feature applies to all third parties and does not use an entity list. We have no plans to add one. It does automatically relax partitioning under a variety of circumstances [documented here](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/State_Partitioning#dynamic_state_partitioning) for webcompat reasons. But we're working to figure out how we can narrow these over time with the goal of removing them entirely at some point.

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