I've gone back and forth on this since it was first announced.<p>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.<p>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.<p>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.<p>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.<p>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.<p>So, yeah. I get that it's annoying, but I'm with Google on this one.
Not mentioned in the article, but critical for debugging and testing - Chrome has added a 2 minute grace period, where cookies set in that time period are still allowed on non-get requests even without a samesite policy. This is considered temporary and will be removed some day in the future.<p>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.
This kills most Cross-Site Request Forgery vulnerabilities, since sites will now need to explicitly opt-in to allowing authentication cookies to be served in cross-site requests.<p>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.<p>Previous discussion from back when this was first announced: <a href="https://news.ycombinator.com/item?id=19853090" rel="nofollow">https://news.ycombinator.com/item?id=19853090</a>
For anyone else wondering: the new default SameSite=Lax should (continue to) work fine for cookies with the "Domain" attribute, for sharing with subdomains.
My website has one affiliate link to Amazon page and a PayPal Buy It Now button (implemented as a form). Chrome's console message suggests I add 'SameSite=None' and 'Secure'. Any advice on where I would add those properties and if they are the right value for these type of links? I didn't realize these type of links had anything to do with cookies.
Archived copy, which can be read without JS enabled:<p><a href="https://archive.is/YOIND" rel="nofollow">https://archive.is/YOIND</a>
This change makes a mockery of Google's commitment to a compatible web. There have been 5 SameSite drafts over two year. This change is strictly incompatible with two of the drafts that shipped in two different browsers (Chrome 66 and Safari 12). Users of LTS Linux distributions will find random websites broken because of this change. It's a great idea on paper, but by shipping so many incompatible versions in the draft stage, Google has virtually ensured breakage for certain user agent - service combos. They should have held the change for another 18 months.
I find it ironic that Microsoft will be implementing it when the latest version is IS11 on a fully patched windows 7 host doesn’t support samesite.<p>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.