Hacker News Reader

Comment by jacobparker | Hacker News Reader

Hey, there are some important mistakes in this warning:

1. The value that is invalid for older browsers (including older versions of Chrome!) is None, not Lax. It is always (as far as anyone knows safe to explicitly set SameSite=Lax in all browsers, assuming your site is ready for that.

2. The latest Safari (v13) has changed their behaviour to match the latest spec.

See this article for details on detecting/dealing with it: https://www.chromium.org/updates/same-site/incompatible-clie...

TL;DR: old (but not too old) Chrome responds by rejecting the cookie entirely (which Google says was an valid interpretation of the spec, at the time of those versions) and old (but not too old) Safari responds by interpreting the None value as Strict (I think there is some debate on whether the spec allowed this back then, but at this point it doesn't matter/I don't care).

View on HN

The latest safari may have changed the behavior. But the bug is tied to the OS version, and Apple has said they won't backport the new behavior to iOS 12 or Mac OS 10.14. So people who can't or won't (for example users of old iphones) upgrade the OS will not get the fix. So user-agent sniffing will probably be necessary for years.

> See this article for details on detecting/dealing with it: https://www.chromium.org/updates/same-site/incompatible-clie....

Yes, they recommend using a few dozen lines of user-agent sniffing code. Despite the fact that user-agent sniffing is generally considered bad practice.

> So user-agent sniffing will probably be necessary for years.

Only if you set None (either to opt-out or to do a None/Strict pair). Setting Lax doesn't require sniffing.

But yeah, that seems like a safe bet.

Here is the bug that I'm referring to: I think the link you posted to is the same bug but doesn't mention the additional issue. https://bugs.webkit.org/show_bug.cgi?id=198181

According to that bug report it says the issue was fixed in Safari 13 and also iOS 13 like you said, but caniuse says there is still an issue.. I'm on 12 right now and can't update to check atm. https://caniuse.com/#feat=same-site-cookie-attribute

Yep, that's the issue. I think I see the confusion now (I stand by my original comment).

SameSite=Lax was never an invalid value, so it was never mishandled by browsers (very old browsers gracefully degrade to treating it like None, which is as good as possible). In the original spec there was Lax, Strict, and unspecified (i.e. the Set-Cookie header didn't have a SameSite attribute, the default behaviour) but, critically, no None.

Browsers developed around that time that treated unexpected values as equivalent to unspecified/what we now call None (e.g. Firefox) turned out to have picked a more forwards-compatible approach. Browsers like Safari and Chrome took stricter action for unexpected values (the idea here is a vague "secure by default" feeling) but it's awkward now that the default is changing from what is (now) called None, to Lax.

In that issue, consider the title "Cookies with SameSite=None or SameSite=invalid treated as Strict" redundant: None was an invalid value according to Safari at that time, which wasn't wrong.

SameSite=Lax is 100% safe to set (assuming your site is ready for that). You only need to browser sniff if you're considering setting SameSite=None.

I think OP was saying that Safari treats "lax" as invalid, while "Lax" is valid. Note the casing.

Interesting theory. I don't think it's true, though. The original spec mandated case-insensitive comparisons and it looks like WebKit has always been doing that to me.

Reply on news.ycombinator.com