Get Ready for New SameSite=None; Secure Cookie Settings
blog.chromium.org
blog.chromium.org
It's a very tough pill to swallow and is absolutely going to break a lot of web content. There's just no way around that. And there are very few things that are worth breaking the web over.
This is probably one of them. The security benefits of this change are very, very high. It's fixing something that arguably was broken since the introduction of cookies.
I am, as a rule, fairly skeptical when Chrome/Chromium devs say they're going to break something for security. Usually I think they're wrong, this time I think they're right, and I'm grateful that they've pushed for the change.
Also to the Chromium team's credit, they're taking the lead on something that they are 100% going to get criticized about. There are going to be some very angry threads about how they did it wrong, and how a 2020 release is too soon. I don't think the rollout has been perfect either, but... somebody has to do it. Once everything dies down, Firefox is going to implement the same changes, and no one will bat an eye because everyone will have already adjusted to Chrome. There's very little upside to being the browser that makes these changes first, but one of the browsers needs to do it first.
A nontrivial portion of our privacy/security problems on the web come from some fundamentally bad sandboxing; and frankly, cookies are badly sandboxed. This change makes the default at least a little better, and will immediately block a large number of CSRF attacks.
So, yeah. I get that it's annoying, but I'm with Google on this one.
When ad companies attempt to circumvent Safari's third-party cookie policy, Safari tries to block them as part of their non-standard ITP (Intelligent Tracking Prevention) program. https://clearcode.cc/blog/intelligent-tracking-prevention/
Firefox has followed suit with an "Enhanced Tracking Protection" feature, which was optional, but became mandatory in September of this year. https://blog.mozilla.org/blog/2019/09/03/todays-firefox-bloc...
Rather than fearing to break the web, Apple has broken the web's ad tech frequently and aggressively; users seem not to mind.
Browser vendors fear "breaking the web," in part because they're afraid that users will switch browsers if their favorite web site stops working. But it turns out that if you just break the web's ads, users tend to like it, if they even notice in the first place.
The point is to block CSRF attacks on ordinary websites for developers who don't know enough to secure their cookies.
> But it turns out that if you just break the web's ads, users tend to like it, if they even notice in the first place.
Breaking just the web's ads wouldn't have the same impact on security. The reason this change is valuable is because it's not restricted to specific blacklists or domains or applied via an algorithm, it's universal. I really like the tracking protections that Safari/Firefox are adding, but comparing them to this is apples and oranges.
They're policies that are designed for different purposes.
[0] https://groups.google.com/d/msg/mozilla.dev.platform/nx2uP0C...
I think that's just a smart move in general. There's certainly no PR reason to preemptively turn this setting on, it's better to see what happens when Chrome does. If it turns out to be a disaster, you delay, if not, you flip the switch a few days later so you're not lagging behind on security. Again, I have a reasonable amount of respect for the amount of publicity that the Chromium team has done here, because I think that if things go wrong, they're the ones who will be blamed by most people.
It's good to bring up that Mozilla and Microsoft are also on board with this. It's not Google going off and doing something on their own or forcing the change despite objections, pretty much everyone including Mozilla seems to agree, and would like to see this change.
If you test with Chrome 78, and your app works, you can't know if it'll work once the 2 minute grace period goes away. Please test your app using an old version of Chrome (76/77) with the flags for this enabled.
Of course, it'll probably be a long time before enough browsers support this that you can actually rely on this behavior, and even once support is universal there'll probably still be some sites doing dumb stuff like setting `SameSite=None` on authentication cookies without taking additional precuations, or allowing data to be modified with GET requests. But overall this is a huge win for security on the web.
Previous discussion from back when this was first announced: https://news.ycombinator.com/item?id=19853090
Will it? All major browsers now receive automatic or timely updates. The speed of features rolling out over all major browsers is pretty rapid now days and unless you care about supporting IE you can expect new features to be ready to use within a year.
There is only so much you can do to support users using a discontinued browser many many years out of date. Unless you want to be stuck in 2013 forever you have to let them go eventually.
Instead of your site simply being broken or a certain feature on it not working, you'd instead be opening up all users on older browsers to a CSRF attack against your site.
Apparently browsers will use the public suffix list to determine what constitutes the first part of a domain which is identifying, and anything beyond that is considered SameSite.
So www.foo.com is the same site as api.foo.com, but user1.github.io is not the same site as user2.github.io. Because github.io is on the public suffix registry.
That is according to web.dev anyway...
"SameSite" affects sending the cookie in situations where top-level site in the browser context is different from the target site of the request where the browser is determining if it should send cookies. e.g. on example.site with an iframe to widget.site
"Domain" determine the the highest level domain to which cookies should be sent, regardless of the browsing context. e.g. on example.site an iframe on widgets.example.site or top-level navigation to accounts.example.site
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se... details: > * If omitted, defaults to the host of the current document URL, not including subdomains. > * If a domain is specified, subdomains are always included.
I have a couple of setups where an application has a single sign-on for root and subdomains. The shared cookie has the Domain attribute set to the root domain, but (so far) they have no explicit SameSite attribute.
I searched around and came to the conclusion that the above setup will behave the same way with new default SameSite=Lax. However, there wasn't a canonical reference that I could point to, to prove this works as I expect.
If there are any cookies, you will need to add SameSite=none or similar to the Set-Cookie directives for the cookies which are intended to be shared cross-domain.
Then there are the apps that forked Chromium 66 and then renamed it, so you can't tell what version it is. We're planning to just break them, since it's impossible to tell what to do there.
https://www.chromium.org/updates/same-site/incompatible-clie...
Ubuntu 16.04 LTS currently has Chromium 77 and Firefox 69.
I have no idea why the host OS is relevant, but the feature should never have been limited by it, and it’s a nasty move given it’s a security feature and not just some random shiny new button.
It’s still in support, and the function shouldn’t even care about the host OS, I think the lack of implementation was more likely completely intentional (on the level of ‘if Windows.version < 10 return true’) which is an absolute dick move.
Disclaimer: despite working for Google, I don't have a clue about this. I'm deep in the backend.
1: https://superuser.com/questions/75841/what-is-1e100-net-and-...
One of the nice side effects is it will temporarily break tracking, though.
In my opinion, cookies on cross-site requests (third-party cookies) should be sent to web servers under a different request header, since they're semantically different (do not necessarily imply user authorization and intent) from cookies attached to a request initiated by the user from a first-party page.
I thought "third-party cookies" generally referred to cookies that were set in a third-party context. Whereas you're talking about cookies being read in a third-party context.