4 ms·

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

bawolff 7y ago
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.
- ec109685 7y ago
  It makes it harder though.
  - bawolff 7y ago
    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)
- jakelazaroff 7y ago
  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 7y ago
    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 7y ago
      > 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
    - deleted 7y ago
      [deleted]
  - Buge 7y ago
    > (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.
zzo38computer 7y ago
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 7y ago
  Not sure how this is relavent, but IE had document.execCommand('ClearAuthenticationCache'); for http or TLS auth. Dont think other browsers have anything
  - zzo38computer 7y ago
    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 7y ago
      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)

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.

ec109685 7y ago
It makes it harder though.
- bawolff 7y ago
  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)
jakelazaroff 7y ago
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 7y ago
  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 7y ago
    > 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
  - deleted 7y ago
    [deleted]
- Buge 7y ago
  > (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.

zzo38computer 7y ago

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 7y ago
Not sure how this is relavent, but IE had document.execCommand('ClearAuthenticationCache'); for http or TLS auth. Dont think other browsers have anything
- zzo38computer 7y ago
  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 7y ago
    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)