Hacker News Reader

Comment by account42 | Hacker News Reader

> The unfortunate climb-down will also have secondary effects, as it is likely to delay cross-browser work on effective alternatives to third-party cookies.

We don't need "effective" alternatives to third-party cookies. The only reason that's even considered is because the advertising industry has captured the browser market and are using that control to ensure their continued ability to track users.

In fact, blocking third-party cookies is not nearly enough. We need to make sure most users have the capability to block all online ads.

View on HN

I agree with you. But I also work on Keycloak and there are legitimate reasons why 3rd-party cookies are needed, they are essential for silent authentication flows and session management, which are part of the OpenID Connect standard.

Browser vendors have not yet provided APIs to both block cookies and allow for user consent to let these flows work. The Chrome team seems to be re-inventing the wheel with the Federated Credential Management API, which is not even close to done or feature complete with OAuth/OpenID Connect. This is why their end-of-year deadline was never a realistic.

All APIs introduced around the cookie phase-out are either fundamentally broken, or only serve to give established players such as Google more control over the user data.

For example, first-party sets are an allowlist curated by Google to determine who gets to set cookies in a third-party context, the FedCM API is barely implemented by a single vendor, the CHIPS API still breaks the most common cross domain authentication flows, and the Storage Access API is an inconsistent mess between vendors.

Can you give some pointers or what to search for regarding OIDC and 3rd party cookies?

I've implemented both OIDC SSO and SLO between a lot of varying services and identity providers and have never needed 3rd party cookies so I'm curious.

Only place I've seen it are some really old SAML implementations and even those could be reworked to not use 3rd party cookies.

This is specific to when you run a deployment where a user is authenticated cross domain with a authentication server.

If a user wants to sign in to foo.com through auth.com it is not possible for foo.com to know if the user has a session, so it needs to redirect the user to auth.com to understand if the user has a session. Previously this could be handled by embedding an iframe into foo.com with auth.com that can read the session cookie, this is no longer possible due to cookie protection.

Also if a user is signed into auth.com and foo.com, and then signs out of auth.com it is not possible to detect the user has signed out, as foo.com cannot access cookies set on auth.com.

> there are legitimate reasons why 3rd-party cookies are needed

There are indeed. But given that 3rd party cookies are most commonly used for nefarious purposes, dispensing with them strikes me as the lesser of two evils. I do that myself with my browser settings.

> most commonly

Says who?

Says me, based on my personal observations. Most third-party cookies are related to advertising-related tracking.

I have third party cookies blocked, and have done so for at least a few years. The vast majority of sites, including SSO providers, function just fine. There shouldn't be a need for third party cookies to enable auth flow when you can pass data back to the originating site in a number of other ways outside of the cookies.

You can only pass data back to the originating site in one other way with GET and three other ways with any method that is expecting to have a body. But URL parameters are not a reasonable place to put sensitive information (even short-term authentication tokens) so that leaves us with body elements and headers. Headers can't be added programmatically in a redirect that needs to involve the client so you're left with POST-POST-POST and other fun. This doesn't _break_ the web, just makes it slower.

That said, once you introduce embedding (A embeds B, both A and B want to delegate the user's identity through SSO-C) you find the real pain points of lacking ambient authentication on the web. But even this case is possible if the websites cooperate ... which unfortunately means that techniques that enable cooperating websites can be used for cross-site tracking as well.

Worth noting that Apple and Mozilla both have some third party cookie deprecation, but significant unspecified carve outs and exceptions. It feels like Google's kind of had to go it alone with figuring out how this all really is going to work, what the specs really should do. And yeah, it's a much bigger project than the original times were set for.

A very healthy % of the explainers Google is working on directly or indirectly relate to 3rd party cookies and/or storage buckets/isolation. https://github.com/orgs/explainers-by-googlers/repositories?...

> Worth noting that Apple and Mozilla both have some third party cookie deprecation, but significant unspecified carve outs and exceptions

Yep - the fact that there are hard-coded carve outs in webkit's source code for "theonion.com" and other such websites (and a bucket of heuristics which no one likes but which allow third-party cookies as first party in some scenarios) is why the web hasn't been more broken by this ... yet.

> The only reason that's even considered is because the advertising industry

No, it isn't. I've seen a lot of cases when 3rd party cookies were used in complex web based software, especially in enterprise software.

This maximalism is tiresome.

Reply on news.ycombinator.com