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

> I don't think it is correct to say that the origin serves as a privacy boundary on the web today, because AFAIK even where third-party cookies are currently blocked, third-party is equivalent to cross-domain, not cross-origin.

and 

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

But, I don't think we should take those exceptions as signifying that cross eTLD+1 flows are some necessary property of the web.  We should take such exceptions (ether centrally curated a la disconnect, or user curated a la Storage Access API) as what they are, an artifact of the Web having serious privacy problems today, and issues we should be sure to solve going forward.

> We still need to develop an interim compat mechanism like the Disconnect list or First-Party Sets.

This is interesting! Is the intent for FPS to be a temporary, for-a-year-or-two, bridge to something else?  If so, that is very interesting and encouraging, but its surprising given the FPS conversations I've listened in on (which is << all of them, so grain of salt).  But, many of the proponents of FPS in the calls I've participated in seem like "we want cross site information flows forever and always" and not "just for a year until X ships".  Could you clarify here?

> It seems like this problem would exist even in a world without FPS, no? Since your recommendation was that Facebook should have to redirect instagram.com to instagram.facebook.com; it seems like browsers would then have to inform users of the redirect before committing that navigation?

Apologies but I'd don't quite follow the concern above.  My point is that either 1) there should be a firm privacy boundary between instagram.com and facebook.com which the browser should enforce, or 2) Facebook should make it clear to users that there is no such boundary with www.facebook.com and instagram.facebook.com.

But what would be really really bad if it appeared to users like there was a privacy boundary between IG and FB, but there really wasn't one (or a significantly weakened one) bc of FPS.  

But there wouldn't be any need for notification in the example you gave.  Users would still know that things they did on instagram.com were different and isolated from facebook.com and instagram.facebook.com, regardless of any bouncing (unless you're describing pushing identifiers across storage areas, a la bounce tracking, in which case, thats another problem to be solved and [is being tackled in PrivacyCG](https://github.com/privacycg/proposals/issues/6)).

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