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

Thanks for sharing your feedback, @pes10k!

> First-party sets, and expecting users to understand that different origins now have different amounts of "differentness" will make even these kinds of determinations even more difficult, and likely impossible to all but expert users.

Our intention is not to multiple new levels of "different-ness"; but we hope that the users only have to understand two types of boundaries - a security boundary (origin), and a privacy boundary (First-Party Sets, where a singleton FPS is equivalent to registrable domain). 

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

Regarding user understanding, I would venture to say that FPS offers the opportunity to highlight the notion of this privacy boundary in the browser UI, in addition to continuing to highlight the origin/domain as the security boundary. 

I wonder if forcing multiple distinct sites onto a common registrable domain could also potentially have the opposite effect of what we want, by training users to pay more heed to the subdomain (because it directly indicates the brand/app name) than the domain, and unwittingly teach them to make security decisions solely based on subdomains. 

> 2. If the concern is that clustering multiple "properties" onto a single origin will cause security problems (a problem I totally understand and buy and appreciate), lets try to fix that problem (possibly by allowing a single site declare sub-site/origin security / isolation boundaries), instead of trading privacy for security.  For example, I know https://w3c.github.io/webappsec-suborigins/ didn't get broad support last time it was floated, but that seems like a place to build from.

Note that even if we do manage to corral together every platform feature that treats the site/domain as a security boundary, and resolve the issues over multiple years:

- We still need to develop an interim compat mechanism like the Disconnect list or First-Party Sets.
- Site authors still have to account for older clients/browsers that don't have these solutions in place. It seems like an undue burden to require that site authors maintain substantially different patterns of deployment for different clients.

> For example, right now in at least Safari, Brave and Firefox (and more generally browsers that block or partition 3p cookies / storage), I can have an Instagram account, and a Facebook account, and I can log into each as 1p, and know that there is no "web platform supported" (i.e. handwaving away things like fingerprinting, and other known-but-not-solved leaks on the web) way that Facebook and Instagram should be able to link those accounts. 

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](https://github.com/disconnectme/disconnect-tracking-protection/blob/2c2b6f7e1975f8107e8b999e1e4445122d27d7e8/services.json#L7813)).

> TL;DR; for point 3, i'd be very interested to know more about how FPS-supporters imagine informing users of FPS, and their implications for tracking _before the user commits to visiting a site_.

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?


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