> 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?"

> Single logical site spread across multiple domains.

Is there really need for this? I get subdomains can help routing, but beyond that sites spreading over multiple domains are chaotic and phishing-prone. People get used to jump from foo.com to foo.net or scammyfoo.tk and enter their credentials if they look similar. I think that a big part of how password managers help is by keeping passwords from their users and not sharing them with any random domain that may read similar or misleading.

A common need for this is during an acquisition or merger.

It's fine and all to assume that domain is identity, but that doesn't actually map too well to relatively complex organizational hierarchies.

Ex - Bank A and Bank B merge. There is going to be a period where they have to navigate that two domains represent a single organization. It's often a fairly high level of effort to move to a completely new domain, and it won't be done overnight.

Yes - eventually you want to be back on a single domain, and I think there is definitely a world where this leads to some very bad patterns (HR and healthcare are two examples - if you've ever seen a login need to bounce between like 5 different domains because they've refused to actually do the technical work to consolidate back on a single domain, and treat the domain as marketing).

But it's a really valid spot to end up in, and is the most common cause of having a single entity spread out over multiple domains in my experience.

More common are multiple sites (which use their own domains for esthetic / brand reasons), but are actually hosted by the same SaaS provider and could therefore share authentication infrastructure.

Imagine an easy-to-use website builder for restaurants where each restaurant gets a memorable domain, and they let you order things online. It would be great for customers if they didn't have to enter their payment details and shipping address for each new restaurant they order from. Maybe they could even see opening hours and product availability for the closest restaurant to their address. There's no privacy risk here, as all these websites are actually on a single provider anyway. They're just multiple entries in some SQL database, each with a `domain` associated with them.

Oh yeah, there are definitely valid use cases. If you’re a web hoster, you host many sites under user’s domains. There are plenty of features you might want to offer your users — for example, if they’re logged into their hosting account, visiting their domain shows them some kind of status or site editing bar. Or maybe there are social features, like liking posts or commenting on other people’s sites without having to create new accounts and logging in everywhere. 3rd party cookies make this possible. Alternatives (at least as of a couple years ago) are often still worse user experiences.

For a modern example, restaurants have online ordering systems. And a lot of them use the same service under the hood. (Eg toast.) If you want to use the same credit card you used somewhere else, you have to login on every single restaurant site using the SMS code. (Eg “link pay.”) Allowing 3rd party cookies would make that flow faster, since you could visit other restaurant’s domains while still being logged into the 3rd party payment domain. (And specifically, logged-in inside an iframe so the restaurant site can’t read your payment info.)

These flows all feel very dangerous to me because they potentially allow a site to access information about me that I have not explicitly allowed.

Take the web hosting example; naively if I visit any site hosted by that company, can they detect that I have an account and am logged in to my hosting account? That feels like a dangerous amount of leakage, and you're relying on the hosting website to make the correct restrictions rather than having it structurally embedded in the user agent.

The shared payment system feels even worse -- is it then possible for a random website to get a payment through this system, or extract information about my payment account?

> What are the legitimate use cases for third-party cookies?

None, looking at it from a web users' perspective

You can make up scenarios that require them, but these are artificial and contrived, and boil down to "I can extract more value"

When you are the one extracting value, and you are an articulate intelligent person, I expect you will have screeds and screeds of logical sounding reasons why third party cookies are good for me as a web user.

You would be wrong

I have been deleting them for years.