Yes, this can, and will, be abused for tracking users across domains that they don't expect to be related.
But there are also legitimate use cases for this.
For example, consider the stackexchange family of sites. They are clearly related, have a unified branding, etc. but are on separate domains. On Firefox, which blocks third party cookies, I have to log in to each of those domains separately. I can't log in to stackoverflow.com, then go to superuser.com and already be logged in. That is a problem that First party sets would solve.
You can argue that it would be better for those sites to be subdomains of a single unified domain, but when the sites were created there wasn't any compelling reason to need to do that, because third party cookies were still very much alive and kicking. And I can say from experience that migrating an app to a different domain without breaking things for users is a royal pain, and can be very expensive.
I'm not saying that First Party Sets should be accepted as is, but it is attempting to solve real problems. And I think a solution that simultaneously protects users' privacy and maintains a good experience for sites that are legitimately related will be difficult to find, or maybe impossible.
> I can't log in to stackoverflow.com, then go to superuser.com and already be logged in.
I would expect a popup like “This site wants to share cookies with stackexchange.com, press Allow to sign in, press Reject to reject forever or press Ignore to decide later”. Takes a single click to enjoy the benefits of both worlds. The mechanism should make sure that every website has a single “first-party domain” shared across all subsites and that first-party domain must not share cookies with any other site than itself to minimize confusion.
> Also, there is no way to know which related site the user is logged in to, so they would have to prompt for every one of their sites.
This is not how it works. The mechanism is about allowing a cluster of websites to choose a single first party domain and have all of them share cookies together, not sharing arbitrary cookie from arbitrary domain, otherwise it would create loopholes in connected components that bring back the downsides of third-party cookies. What you mentioned should be done using SSO.
After thinking about it a bit more, I have a clearer picture of how it should work in my mind:
* All cookies are double-keyed: the primary key is the origin of the top-level page and the secondary key is the origin of the page that sets the cookie, just like how partitioned cookies work right now.
* stackoverflow.com uses a header, meta tag or script to request changing its primary key domain to “stackexchange.com”
* The browser makes a request to https://stackexchange.com/domains.txt and make sure that “stackoverflow.com” is in the list, authorising this first-party domain change
* When the user agrees to the change, the page is reloaded with stackexchange.com as the primary key, thus stackoverflow.com can obtain login details from stackexchange.com via CORS or cross site cookies.
* A side effect is that all cookies and state are lost when switching the first-party domain. Should stackoverflow.com be acquired by a new owner, say x.com and changes its first-party domain to x.com, all cookies on stackoverflow.com are lost and the user will have to login on x.com again, maybe using credentials from stackexchange.com. It’s unfortunate but it works around the issues mentioned in the post in a clean way, avoiding loopholes that transfer cookies by switching the first-party domain frequently.
> You can argue that it would be better for those sites to be subdomains of a single unified domain, but when the sites were created there wasn't any compelling reason to need to do that
I can also argue that Safari and Firefox have been blocking third party cookies for years now. So stack overflow has had plenty of time to adapt and migrate to the "right" organisation.
To me it look like either they care about allowing unified sign in on their various domaines, and they should have migrated to a subdomain model a long time ago, because users of Firefox, Safari etc have been negatively impacted for a long time. Or they do not care that much (which is fine), but then chrome blocking third-party cookies and the discussion around first party sets should not concern them too much.
Or, they do care, but not enough to spend the significant resources and opportunity costs to do something about it for the minority of users who don't use chrome. Of particular note, changing domains can really hurt SEO.
Stack overflow was founded in 2008. Netscape added a block third party cookie button in 1997 (and the web has mostly worked fine with that feature turned on ever since).
This reminds me how google conveniently made the switch to manifest v3 when there were legitimate use cases like adblockers. Sure, technically speaking v3 is more secure and that may be better for users but your comment just made me think the opposite is in motion here.
Nothing wrong with manifest v3. It's just that ad blocking is so important that it should be an exception to the whole thing. Ad blockers should be literally built into the browsers so that they have full access, only conflicts of interest stops this.
> For example, consider the stackexchange family of sites. They are clearly related, have a unified branding, etc. but are on separate domains. On Firefox, which blocks third party cookies, I have to log in to each of those domains separately. I can't log in to stackoverflow.com, then go to superuser.com and already be logged in. That is a problem that First party sets would solve.
Other sites seem to handle this fine with redirects and cross-origin headers. Sure, at some point you land on "signin.foo.com", but from the user experience you were authenticated without having to sign in again.
OIDC seems like it can reasonably help in a fair number of these cases, maybe? it's iffy because (a) the major providers, are, well, Google and their ilk, (b) SSO solutions trend toward reducing user confusion at the cost of choice--im still out on whether the common "enter your email/account identifier so we can select which IDP we use" login flow is something of an anti-pattern or not
i generally like having the option for "sign in with github" as opposed to the all-encompassing "sign in with google" (ignoring that github is a microsoft account but not quite at this point)
smaller-scope IDPs for a particular field ("ey, you work on code stuff? you probably have either a github or gitlab account to log into our code-adjacent service" or "ey, you use stackoverflow? you can use that same login on superuser") is maybe a decent middle ground, where shared authentication is more explicit than third-party cookies were
Stack Exchange sites have a horrible authentication system so using them as an example is a bad start.
However they could solve this "problem" in a number of ways, the most straightforward being to use subdomains instead of individual domains.
I put "problem" in quotes as it's not even a problem; it's browsers working as intended. When you visit different domain names, you should expect that your browser won't be aware of data (cookies) stored by other domains.
First Party Sets are legitimately terrifying to me, it gives a commercial party (Google) complete control over who is and isn't allowed to set cookies in a third-party context. It's Google using their absolutely dominating market share to force even more control.
> On Firefox, which blocks third party cookies, I have to log in to each of those domains separately. I can't log in to stackoverflow.com, then go to superuser.com and already be logged in. That is a problem that First party sets would solve.
Yes, this can, and will, be abused for tracking users across domains that they don't expect to be related.
But there are also legitimate use cases for this.
For example, consider the stackexchange family of sites. They are clearly related, have a unified branding, etc. but are on separate domains. On Firefox, which blocks third party cookies, I have to log in to each of those domains separately. I can't log in to stackoverflow.com, then go to superuser.com and already be logged in. That is a problem that First party sets would solve.
You can argue that it would be better for those sites to be subdomains of a single unified domain, but when the sites were created there wasn't any compelling reason to need to do that, because third party cookies were still very much alive and kicking. And I can say from experience that migrating an app to a different domain without breaking things for users is a royal pain, and can be very expensive.
I'm not saying that First Party Sets should be accepted as is, but it is attempting to solve real problems. And I think a solution that simultaneously protects users' privacy and maintains a good experience for sites that are legitimately related will be difficult to find, or maybe impossible.