How does SameSite cookie header prevent tracking?

Question

I understand how SameSite cookie header prevents CSRF. But how does it prevent tracking by 3rd party sites, since they could set SameSite=Lax or None, and the browser will still send them: https://web.dev/samesite-cookies-explained

Maybe it doesn't prevent tracking, but most articles describing it also mention tracking among the problems, before describing the SameSite solution:

Your promo_shown cookie should only be sent in a first-party context, whereas a session cookie for a widget meant to be embedded on other sites is intentionally there for providing the signed-in state in a third-party context.

Agreed, but what prevents 3rd party sites setting SameSite=None on promo_shown cookie?

Answer 1

The proposals in this document do not in themselves mitigate the privacy risks described in Section 7.1 of [RFC6265bis]. Entities who wish to use cookies to track user activity from cross-site contexts can continue to do so by setting cookies that declare themselves as "SameSite=None".

Requiring that explicit declaration, however, gives user agents the ability to easily distinguish cookies used for stateful cross-site requests from those with narrower scope. After the change proposed in Section 3.1, only those cookies that make an explicit "SameSite=None" declaration can be directly used for cross-site tracking. It may make sense for user agents to use that information to give users different controls for these cookies, or to apply different policies for expiration and delivery.

-- https://tools.ietf.org/html/draft-west-cookie-incrementalism-00

---

"This change will enable users to clear all such cookies while leaving single domain cookies unaffected, preserving user logins and settings. It will also enable browsers to provide clear information about which sites are setting these cookies, so users can make informed choices about how their data is used." -- Google Chrome.

This Google Chrome interpretation suggests we leave all the responsibility with users to perform these actions manually. However, that is not the only possibility. Other browsers could chose to automatically expire "SameSite=None" cookies after a certain length of time. The exact behaviour could be configurable, or the browser could allow it to be customized by browser extensions.

---

However IMO they (Google, Inc. are prominent as the spec authors) have left a blind spot in this draft. They claim to assume malice

Blunt approaches to cookie blocking have been tried, and in response we have seen some user-tracking efforts move underground, employing harder-to-detect methods that subvert cookie controls [...] This is why Chrome plans to more aggressively restrict fingerprinting across the web.

On the other hand, this initial short draft doesn't discuss what happens if trackers correlate "SameSite=None" cookies with "SameSite=Strict" or "SameSite=Lax" cookies.

Changing to not deliver "SameSite=None" cookies when on the same site might resolve this. However, I am not sure that helps when we still have "SameSite=Lax" to consider. I expect this would also be a constraint on backwards compatibility, perhaps an impossibly restrictive one.

Also, the draft mentions "expiration". Perhaps I am too ignorant or naive, but I would appreciate a reminder that trackers can renew cookies on every visit. If we are really taking an adversarial approach, I would think we need to use a different mechanism. I.e. periodically purge tracking cookies, regardless of when the cookie was last re-set.