7 ms·

So these cookies may die but it’s a perpetual arms race. Browser fingerprinting will (or has) replace(d) cookies for tracking purposes.

littlestymaar 7y ago
The article (and Google Chrome's change) is mostly about auth cookies, not tracking ones.
- jakelazaroff 7y ago
  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)
simonw 7y ago
Browser fingerprinting is a hack, and exploits clear loopholes in browser privacy models. I wouldn't rely on it because it's committing to an ongoing arms race against the browsers. One that I expect them to win.
- thenewnewguy 7y ago
  > I wouldn't rely on it because it's committing to an ongoing arms race against the browsers. One that I expect them to win. Don't be so sure about this. The world's most popular browser is developed by the world's largest advertising company. I'm not saying Google is intentionally sabotaging Chrome, but I doubt they're putting significant resources into anti-ad technologies.
  - contravariant 7y ago
    Well, in the end it's their competitors that are hurt most when they close loopholes without warning. All chrome needs to do is hamstring ad-blockers (which they just did) and add a fingerprint that only google can use (like tying your google account to the browser for no reason...)
- nordsieck 7y ago
  > Browser fingerprinting is a hack, and exploits clear loopholes in browser privacy models. > I wouldn't rely on it because it's committing to an ongoing arms race against the browsers. It doesn't seem to me that browsers are trying to win at all. For example, one of the greatest discriminators - font list - has been known about since people were talking about browser fingerprinting. The fix would be pretty easy too: in incognito mode (or when toggled by the user), only support 2 fonts: 1 serif and 1 san-serif that ship with the browser on all platforms. I don't think any of the browsers want to do that. There are a number of other longstanding fingerprinting issues that are similarly easy to fix.
  - bzbarsky 7y ago
    Last I checked, Safari in fact restricts the fonts web pages can see/use to ones that ship by default with MacOS. So you can't fingerprint a Safari user via fonts any further than "Safari user". So yes, browsers, at least some of them, are in fact trying to win here.

littlestymaar 7y ago

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

jakelazaroff 7y ago
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)

simonw 7y ago

Browser fingerprinting is a hack, and exploits clear loopholes in browser privacy models. I wouldn't rely on it because it's committing to an ongoing arms race against the browsers. One that I expect them to win.

thenewnewguy 7y ago
> I wouldn't rely on it because it's committing to an ongoing arms race against the browsers. One that I expect them to win. Don't be so sure about this. The world's most popular browser is developed by the world's largest advertising company. I'm not saying Google is intentionally sabotaging Chrome, but I doubt they're putting significant resources into anti-ad technologies.
- contravariant 7y ago
  Well, in the end it's their competitors that are hurt most when they close loopholes without warning. All chrome needs to do is hamstring ad-blockers (which they just did) and add a fingerprint that only google can use (like tying your google account to the browser for no reason...)
nordsieck 7y ago
> Browser fingerprinting is a hack, and exploits clear loopholes in browser privacy models. > I wouldn't rely on it because it's committing to an ongoing arms race against the browsers. It doesn't seem to me that browsers are trying to win at all. For example, one of the greatest discriminators - font list - has been known about since people were talking about browser fingerprinting. The fix would be pretty easy too: in incognito mode (or when toggled by the user), only support 2 fonts: 1 serif and 1 san-serif that ship with the browser on all platforms. I don't think any of the browsers want to do that. There are a number of other longstanding fingerprinting issues that are similarly easy to fix.
- bzbarsky 7y ago
  Last I checked, Safari in fact restricts the fonts web pages can see/use to ones that ship by default with MacOS. So you can't fingerprint a Safari user via fonts any further than "Safari user". So yes, browsers, at least some of them, are in fact trying to win here.