Wow, if this works, this is basically the end of CSRF. Essentially: CSRF relies on an HTTP POST to VICTIM.COM triggered by HTML on EVIL.COM, and that request carrying cookies. Today, even though SameSite exists, the default --- SameSite=None --- maintains that longstanding status quo. But after the change, the Chrome default will be SameSite=Lax, and while EVIL.COM will still be able to trigger POSTs to VICTIM.COM, those requests will no longer carry cookies.<p>To get the cookies to work from EVIL.COM, VICTIM.COM's developers will have to explicitly set SameSite=None on their session cookies. Which nobody will do, because nobody sets SameSite at all today.<p>Better still: 99 out of 100 CSRF exploits (maybe 999 out of 1000) target endpoints for which SameSite=None isn't needed; they're cookies nobody ever uses cross-site to begin with. There are only limited cases where anyone needs the behavior to change, and those cases don't track the most sensitive cookies.<p>As a vulnerability researcher for whom exploitable bugs mostly exist to spark joy: good riddance to CSRF. It was a dumb bug class, and never, ever fun to exploit.
This is a continuation of a long arc of convergent work [1][2][3][4][5] by various people over several years; I've been following along [6].<p>The innovation of this proposal is to work towards the crossdomain cookie transmission being less insecure-by-default, by eventually making the current, limitless behavior opt-in.<p>This shifts the incentive of developers: presumably those whose sites require crossdomain acceptance of cookies will modify their sites accordingly, while those whose sites don't, or those who haven't thought about the issue will see fewer incidences of the most egregious POST-based CSRF.<p>[1] <a href="https://www.microsoft.com/en-us/research/publication/atlantis-robust-extensible-execution-environments-for-web-applications/" rel="nofollow">https://www.microsoft.com/en-us/research/publication/atlanti...</a>
[2] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=795346" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=795346</a>
[3] <a href="https://github.com/mozmark/SameDomain-cookies/blob/master/samedomain.txt" rel="nofollow">https://github.com/mozmark/SameDomain-cookies/blob/master/sa...</a>
[4] <a href="http://homakov.blogspot.com/2013/02/rethinking-cookies-originonly.html" rel="nofollow">http://homakov.blogspot.com/2013/02/rethinking-cookies-origi...</a>
[5] <a href="https://tools.ietf.org/html/draft-west-first-party-cookies-07" rel="nofollow">https://tools.ietf.org/html/draft-west-first-party-cookies-0...</a>
[6] <a href="https://news.ycombinator.com/item?id=13689697#13691022" rel="nofollow">https://news.ycombinator.com/item?id=13689697#13691022</a>
This is great - the `SameSite=lax` attribute is arguably how cookies should have worked in the first place, and I'm quite pleased that it's an existing RFC and not a proprietary change being done just in Chrome. Hopefully other browsers follow suit.<p>What worries me is the vague commitment to stop browser fingerprinting - not a lot of detail there and I'm fearful that useful features might be getting crippled. I don't think I'm as convinced that browser fingerprinting is as big of an issue as CSRF (prevented by the cookie changes here). Time will tell I suppose.
Interesting. So apparently Chrome is going to stop sending cookies in cross-site requests unless they're created with `CrossOrigin=None` and the page is loaded over HTTPS?
The easiest way to improve cookie privacy is to block 3rd party cookies by default. Adding new polices is not the right solution. 3rd party cookies are completely unnecessary.
Is this another way for Google to prevent you from clearing their cookies via the 'Clear Cookies' option?<p>Its a step in the right direction with enforcing SameSite cookie scoping, but we must be cautious that Google doesn't use this to force you to always be logged in. Google has a long way to go to rebuild trust after that last browser login debacle. I don't trust em.
Not that any step towards additional privacy protections isn't a good thing, same for security.
But Google has got to be one of the major contributors to the erosion of privacy.<p>How about chrome nagging to have you sign in? How about their very own ad networks?