I'm not really grokking the explanation in the article of why the SameSite cookie attribute doesn't fix CSRF. I thought that was the whole design intent of SameSite=Secure on an HTTPS cookie, was to fix CSRF. Can someone boil it down?

The article seemingly says "these cookies won't be sent with an unsafe request. But that doesn't fix it!" And doesn't elaborate?

The problem boils down to the lack of equivalence between a site and an origin. The article explains how https://app.example.com and https://marketing.example.com may sit at very different trust levels, but are considered the same site by the browser. You don't want https://marketing.example.com to be able to make requests to https://app.example.com with your authentication cookies, but SameSite wouldn't prevent that.

Same-Site cookies are, well, same-site. Not same-origin. This is already a deal-breaker for many deployments, because they don't trust blog.example.com and partner.example.com as much as admin.example.com (both in the strict sense of trust, and in the senso of not having XSS vulnerabilities the attacker can pivot off).

Worse, by the original definition http://foo.example.com and https://admin.example.com are same-site, and unless the site uses HSTS with includeSubDomains, any network attacker controls the former. Chrome changed that with Schemeful Same-Site in 2020, but Firefox and Safari never deployed it.

The other replies answer this question, but it’s worth mentioning the public suffix list which contains a list of domain suffixes that have subdomains that are controlled by different people. E.g github.io, wordpress.com

Browser use this list to prevent cookie shared between sites using the suffixes on the list. E.g evil.github.io will not receive cookies from nice.github.io, or any other .github.io origin, regardless of the SameSite attribute