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

Thanks for the comments and discussion in the thread! I just wanted to share Brave's (loosely) point of view on first-party sets, and why we don't think they'd be a good addition to the web platform.

1. Having related groups move their properties and applications to a single origin / eTLD+1 is a feature, not a bug.  The origin is one of the few security and privacy boundaries we hope (even if imperfectly) users understand, and it''s emphasized in many browsers' UIs accordingly.  If nothing else, the platform emphasizes that different origins deserve different levels of trust and caution.  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.

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.

3. A concern I have about first-party sets that I haven't seen discussed much yet (though apologies if i've missed it in minutes) is how, in a first-party-sets-world, to information users about the privacy implications of first-party sets _before_ they visit the site.  This seems extremely important (despite the prevalence of dark patterns on the Web, of folks changing URLs out from under users, etc).  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.  That may no longer be the case in a FPS world (if I understand most of the intended use cases for FPS so far). 

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

Thanks again all for the discussion!

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