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.
