4 ms·

This won't stop cookie-based tracking though, they can just set "SameSite=None" with their cookies

• nikbackm 7y ago
  Wouldn't that make it trivial to block them all?
  • jacobparker 7y ago
    You mean block all SameSite=None cookies? They have legitimate uses too. Consider that SameSite=Strict even breaks cross-origin links (<a> tags): if a 3rd party site links to you and a user clicks that link, the GET will be sent without cookies. To get value out of Strict for typical sites the new pattern is to have two cookies: one is SameSite=None and allows you to do GET/HEAD/etc. requests ("read-only operations", assuming you are following those parts of the spec) and one that is SameSite=Strict and allows you to do POST/etc. ("write operations"). If https://evil.com https://evil.com adds a link to your site (an <a> tag) you can allow deep linking by only checking for the None cookie. The strict cookie won't be sent for <a> tags. But POSTs/form-submissions, and any page/resource you don't want to allow deep-linking for, you would check for both the cookies. I've seen this pattern referred to as "reader and writer cookie pairs". --- This really is specifically aimed at killing CSRF attacks. It's not about tracking either way (it's orthogonal to that).
    • Buge 7y ago
      Why None instead of Lax? The uses cases you mentioned for the None cookie seem like they would still work with a Lax cookie.
      • jacobparker 7y ago
        Ah, good point. So it depends on your site. Some sites need to do things like serve embeddable content or be an OAuth identity provider, etc., and SameSite=None is required in those cases. Sorry for not being more clear about that.
  • michaelt 7y ago
    In Firefox at least, it's been possible to block third-party cookies for... as long as I can remember? And a sensible security move - it protects you against XSRF protection with very low usability cost.