4 ms·

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.

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-clients 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.

StavrosK 7y ago
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.
- jes5199 7y ago
  because adding that single header breaks the behavior on old browsers
- thayne 7y ago
  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.
  - StavrosK 7y ago
    I don't understand why you sometimes need to not send the header. What happens if you do, in those cases?
    - yuliyp 7y ago
      https://bugs.webkit.org/show_bug.cgi?id=198181 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.
      - StavrosK 7y ago
        That seems like a pretty egregious bug, presumably there's a spec someone is in violation of?
        yuliyp 7y ago
        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 :-(
        IX-103 7y ago
        Safari was not following the spec.
        thayne 7y ago
        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.
- bryanrasmussen 7y ago
  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 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.

StavrosK 7y ago

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.

jes5199 7y ago
because adding that single header breaks the behavior on old browsers
thayne 7y ago
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.
- StavrosK 7y ago
  I don't understand why you sometimes need to not send the header. What happens if you do, in those cases?
  - yuliyp 7y ago
    https://bugs.webkit.org/show_bug.cgi?id=198181 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.
    - StavrosK 7y ago
      That seems like a pretty egregious bug, presumably there's a spec someone is in violation of?
      - yuliyp 7y ago
        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 :-(
      - IX-103 7y ago
        Safari was not following the spec.
        thayne 7y ago
        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.
bryanrasmussen 7y ago
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 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.