That might be because those cookies have been stored for a while. I get quite different results when I check one of my side projects in a normal browser window versus incognito. The latter results in far fewer warnings, and the majority are no longer Google properties (ironically a couple are, but it's much better).
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).
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.
