
Temporarily rolling back SameSite Cookie Changes - KarlKemp
https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html
======
lol768
Seems like a reasonable concession to make during these unprecedented times.
Sites using CSRF tokens properly should be fine.

Mozilla did the same for their TLS 1.0/TLS 1.1 change:
[https://hacks.mozilla.org/2020/02/its-the-boot-for-
tls-1-0-a...](https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-and-
tls-1-1/)

------
oblib
I just heard of this a couple weeks ago and almost got bit by it.

I was reading the console.log while debugging some code with the Opera browser
and it contained a message warning me they were going to implement it in just
a few weeks.

For me it had to do with delivering .js app code from one server that
connected to a CouchDB server running on a different vps, so the impact
would've resulted in users calling and me having no clue about why things were
broken.

I don't know how I missed hearing about it before but the CouchDB team had
already done what was needed on their end. Finding out how to implement it was
a bit difficult for me though, but I got lucky when someone brought it up on
the CouchDB users email list and their message pointed me to what I needed to
do. I generally just glance at those emails.

I suppose I ought to bookmark web.dev and make a point to visit it. Thank you
for sharing that link dmix.

------
snomad
While they may be rolling back at the browser level, if you have any role in
administering a site, you should still consider turning them on.

In php.ini, this is as easy as

    
    
      session.cookie_samesite = "Lax"

------
SquareWheel
This is appreciated. This change did break some things for me, and I've been
scrambling to understand what SameSite cookies are and how this affects
things.

~~~
ninju
This site that does a good job of explaining then rationale behind the change

[https://web.dev/samesite-cookies-explained/](https://web.dev/samesite-
cookies-explained/)

~~~
SquareWheel
Thanks for the link! web.dev was the first resource I turned to, and it had
some excellent articles on the topic. Though I'm now onto more complex topics
like "cookie passing when submitting a form in a third-party iframe".

------
dmix
The explainer of the changes are here: [https://web.dev/samesite-cookies-
explained/](https://web.dev/samesite-cookies-explained/)

~~~
danielmichaelni
Does this mean that if we use SameSite=Lax for our session cookies, we don't
need to worry about CSRF attacks?

~~~
jacobparker
Mostly, if you opt in: [https://caniuse.com/#feat=same-site-cookie-
attribute](https://caniuse.com/#feat=same-site-cookie-attribute) .
SameSite=Lax will still send cookies for some types of GET requests, depending
on the complexity of your site and UX there are ways to be more protected
(with SameSite=Strict, cookie pairs etc.)

Once all browsers behave like Chrome is trying to (SameSite=Lax by default) we
will have dramatically less CSRF on the web. Other browsers are likely to
adopt this change eventually if Chrome sticks with it. You will at least need
to consider users with out-of-date browsers for a while yet (and implement
XSRF tokens and/or explicitly opt-in to Lax/whatever).

The old behaviour will still (and always?) be around with SameSite=None. It
has uses, but misuses could create CSRF vulnerabilities. There will still be
CSRF problems on the web but it will get a lot rarer and, mercifully, not the
default.

~~~
lonelappde
This API is a disaster. None is insecure, but Lax is private?

Lax and Strict are adjectives. What are they even modifying? Not "SameSite"!
They are referring to "SameSiteRestriction" or something.

Why not align with CS of CSRF as AllowCrossSite, and values Always /
OnUserRequest / Never ?

------
dugmartin
We had quite a few old Rails 3 apps at work and had to create a gem to make
sure this change didn’t break them - when they start rolling it back out it
might be helpful for folks: [https://github.com/concord-consortium/secure-
samesite-cookie...](https://github.com/concord-consortium/secure-samesite-
cookies)

------
duxup
I wonder how much impact this even would have had.

But rolling it back is fine if they're going to go through with it later.

------
0az
Amusingly, I was bit by this today because of some issues that required
Cisco's secure email service: opened the attached HTML file, but couldn't log
in, since they haven't added support for Same site.

Found a workaround, but I'm glad they're doing this for the duration.

------
ninju
Everything I read about the original change gave me the impression that it's
all backward compatible with earlier versions of Chrome. If you have already
made the require changes there's no reason to roll anything back or undo do
any work.

Is my understanding correct?

~~~
SquareWheel
That's right. Not unless you go back to extremely old versions of Chrome,
which would not have understood the SameSite=None setting.

------
rooam-dev
My question is how Chrome knows if it's a big impact or not? I assume it's
based on metrics sent to google's servers. Can those be disabled?

~~~
dotproto
Can't speak for other Chromies, but what's crossed my radar has been direct
outreach from developers and bug reports.

