> What are the legitimate use cases for third-party cookies?
Embeds
1. As a user in BigCorp I want to embed this new AI reporting software into my larger internal portal for certain groups so they can try it out. The embedded software needs to know who the user is for authorization purposes.
2. As an end user of multiple appliance websites I would like to not have to enter my information multiple times into the support chat bot since all of these various companies are all part of the same overarching corporation and they already know my information.
3. As an end user of multiple blogs all using the same third-party commenting system I would like to already be logged in on foo.blog if I logged in earlier on bar.weblog.
These are all nice convenience features that builders and end users have gotten used to. They can all be achieved in other ways. The other ways are more painful to integrate and require a lot more work both on the part of the integrator and on the part of the end user (at least from a machine perspective - consider how much more work a pre-authenticated (no end-user-visible interstitial screens) OAUth flow is from the browser's perspective than a single request with an attached cookie).
Cases 1 & 2 are manageable through url parameters since there is shared infrastructure on both ends. These can be done without any user visible workflow changes.
Case 3 feels the most like a legitimate use case. Even with url parameters, there's no way for Disqus (or whatever) to know that a.com's user is the same person as b.com's user since those are independent entities. It is still solvable, but not in a zero-click way, by having a round-trip redirect (like an OAuth flow), to associate my user on the blog with my user on the commenting platform. But that does require that the blog track my session, which is not a requirement in the current world.
On the other hand, I'm not sure how much I like having #3 work in general -- that a blog commenting platform can implicitly know what blogs I'm visiting, and potentially even having a blog on which I have no account implicitly having access to my account on other blogs, feels a bit intrusive to me. I'd rather have that integration at the level of a browser extension that modifies user agent behavior rather than something that happens without my permission.
> Cases 1 & 2 are manageable through url parameters
Any URL parameter that isn't signed is going to be modified (Look at me, I'm the CEO now). And if it is signed then it can be leaked (web app logs generally log query string parameters, if it's in a link that can be copy-pasted then it can be widely shared by accident, etc.)
> On the other hand, I'm not sure how much I like having #3 work in general
Yeah, that is another potential architecture for the web (kind of like Project Xanadu: https://en.wikipedia.org/wiki/Project_Xanadu). It isn't how the web is currently built, so the real question is "how much of the web should break?"
Embeds
1. As a user in BigCorp I want to embed this new AI reporting software into my larger internal portal for certain groups so they can try it out. The embedded software needs to know who the user is for authorization purposes. 2. As an end user of multiple appliance websites I would like to not have to enter my information multiple times into the support chat bot since all of these various companies are all part of the same overarching corporation and they already know my information. 3. As an end user of multiple blogs all using the same third-party commenting system I would like to already be logged in on foo.blog if I logged in earlier on bar.weblog.
These are all nice convenience features that builders and end users have gotten used to. They can all be achieved in other ways. The other ways are more painful to integrate and require a lot more work both on the part of the integrator and on the part of the end user (at least from a machine perspective - consider how much more work a pre-authenticated (no end-user-visible interstitial screens) OAUth flow is from the browser's perspective than a single request with an attached cookie).