It says at the bottom of the article but for anyone wondering, yes they are only talking about 3rd party cookies and they're planning on completing this transition this year (we'll see).
To save anyone a click, 3rd party cookies are defined by Google in this case as cookies that have the “samesite=None” attribute. So explicitly only cookies intended to track users by sending cookies across domains.
Oh, definitely not "only cookies intended to track users". This applies (IIANM) to e.g. any browser storage within an iframe. That is, if you want to have an SSO cookie on some login.auth.example and want to open the login form in an iframe, bad luck. The iframe cannot store or access the SSO cookie (or any other, like various preferences). And it's even worse (IIANM; I'm not yet sure if today's specific step applies this widely, but the whole "third-party tracking protection" definitely do): the foreign-origin iframe cannot use _any_ kind of storage, no localStorage, no sessionStorage, nothing. Not even for the time the iframe is active (no tracking there!). We are nowhere near the ad/tracking business but still need to handle these issues. (Not like we expect this to change, so we need to implement other solutions, usually much more complicated and less user-friendly.)
12 comments
[ 2.6 ms ] story [ 35.7 ms ] threadFor Google - that's privacy sandbox.
Fixed it for you. There's a huge difference. Especially considering secure httponly cookies are the recommended way to store session cookies and such.