Hacker News Reader

Comment by Lx1oG-AWb6h_ZG0 | Hacker News Reader

Meanwhile, Google is forcing this massive change across the web right now by defaulting cookies to SameSite=Lax, something that breaks a lot of login scenarios. The only way to fix it is to start emitting SameSite=None. BUT WAIT, a lot of fairly recent browsers (e.g., iOS < 13, Chrome 51-66) don't support it, so you actually need to do this crazy user agent sniffing to not break things: https://www.chromium.org/updates/same-site/incompatible-clie....

I find it ridiculous that one part of Chrome is forcing me to add user agent sniffing while another part is trying to deprecate it. They need to get their act together: their decisions have massive consequences across the ecosystem and they need to be more responsible.

View on HN

I've seen this complaint a lot, and to me it amounts to saying "this default is wildly insecure but is used by a tiny fraction of sites, so I'd rather keep the insecure default rather than ask those sites to add a single header".

Perhaps you can correct me on why that's not so.

because adding that single header breaks the behavior on old browsers

The problem isn't that they need to add a header. The problem is that they need to add the header _or not_ depending on which browser is making the request. Which means you have to sniff the user agent, even though pretty much everyone agrees browser agent sniffing causes problems, and the same browser that is pushing this change is also trying to get rid of the only way to know if that header should be set or not.

And I think the chrome team could have come up with a solution that didn't involve browser sniffing, such as sending a header in the request identifying that SameSite=Lax is the defualt, or that SameSite=None is accepted. But instead they recommended sniffing the user-agent string.

I don't understand why you sometimes need to not send the header. What happens if you do, in those cases?

https://bugs.webkit.org/show_bug.cgi?id=198181 . If you tell Safari SameSite=None it treats it as SameSite=Strict. If you tell Chrome a couple months from now without SameSite=None, you get SameSite=Lax. There's no way to do this without UA sniffing.

That seems like a pretty egregious bug, presumably there's a spec someone is in violation of?

The blame lies somewhere between Safari and Chrome. The "None" value was added after the Safari implementation, and then Chrome wants to do the default-changing this year now. Unfortunately it looks like the fix isn't going to get backported to iOS 12, so here we are :-(

Safari was not following the spec.

Depends on whuch spec you mean. Older versions of safari (anf chrome) were following the original proposed standard (rfc 6265), which said invalid values should be treated as strict. Later versions of Chrome are following a later internet-draft (rfc 6265bis, which I think was proposed by google), that introduced SameSite=none, and changed the behavior for unknown values to be the same as none.

The point is that UA sniffing provides a last resort way of dealing with bugs in browsers until they are properly fixed (if ever). Imperfect as UA sniffing is, it's a lot better than having literally no way to identify and fix an issue people are having.

The question here is whether the browser is a tool to solve your business issues, or whether it is a a service that is more similar to police, firefighters or healthcare. I am way more biased towards the second.

If you send SameSite=None, Chrome 51 through 66 ignore the Set-Cookie header. Chrome 80 requires SameSite=None for cross domain POSTs (e.g. authentication). Google is recommending removing the User-Agent header while Google websites use User Agent detection to workaround bugs in Google User Agents. See https://www.chromium.org/updates/same-site/incompatible-clie... for details of other incompatible User Agents.

Currently (unless this has change in the past couple weeks) if you add SameSite=None on Safari it will treat it as SameSite=Strict. https://bugs.webkit.org/show_bug.cgi?id=198181

So this means that if you need to use SameSite=None you cannot without UA sniffing, which I think is what the parent was complaining about.

Reply on news.ycombinator.com