[jacobparker]

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 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]

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]

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.