[littlestymaar]

The article (and Google Chrome's change) is mostly about auth cookies, not tracking ones.

[jakelazaroff]

What is the technical difference between an “auth” cookie and a “tracking” cookie?

[bawolff]

None, its a usecase difference not a technical one. but samesite is designed to tackle csrf (a problem with using cookies for auth). It wont prevent user tracking.

[jakelazaroff]

Sure it can. Samesite cookies will prevent e.g. Google Analytics from identifying me between domains, since any samesite cookies they set for the domain from which they’re serving their script/pixel won’t be sent. (Presumably tracking prevention will eventually start to block cookies with samesite disabled).

[michaelt]

Browsers have offered a "block third party cookies" setting for decades.

I'm honestly surprised none of the major browsers block third party cookies by default, it's much simpler XSRF protection than this as it doesn't rely on site developers updating and setting the new flag right.

Of course, two sites that seriously want to collaborate on user tracking (or login) can always forward the user’s whole browser window there and back, with URL parameters to synchronise first party cookies.

[bawolff]

> as it doesn't rely on site developers updating and setting the new flag right.

Chrome is enabling this flag by default. Websites can opt out, but if they do nothing they are opted in.

Blocking third party cookies doesnt really stop csrf attacks. At most it makes the attack a bit more noticeable as it prevents some of the quieter methods of pulling off the attack. Since as far as i understand, if you submit a cross-domain POST form, that's still a first party cookie

[Buge]

> (Presumably tracking prevention will eventually start to block cookies with samesite disabled).

This means the privacy advantage doesn't really come now, it instead comes at some hypothetical point in the future.

[ec109685]

It makes it harder though.

[bawolff]

Does it?

Websites can just opt out if they dont like samesite cookies. Even if they couldnt, its trivial for the website operator to work around if they want (and website operators are almost always in on user tracking)

[zzo38computer]

For authentication, there is also the HTTP basic and digest authentication. However, I do not know that any web browser provides functions for the user to manage this authentication. (It would also make it easier for the user to configure cross-site authentication, too.)

[bawolff]

Not sure how this is relavent, but IE had document.execCommand('ClearAuthenticationCache'); for http or TLS auth. Dont think other browsers have anything

[zzo38computer]

Yes, I heard of that, although that is done by the document script and what I was asking is a command for the user to enter instead.

[bawolff]

Http basic/digest auth doesnt last beyond the session, so just close the browser window?

Probably putting a different username in the url would work too (in non ie)