Wouldn't that make it trivial to block them all?

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).

Why None instead of Lax? The uses cases you mentioned for the None cookie seem like they would still work with a Lax cookie.

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.

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.