5 ms·

Really disappointed in you Google for not addressing fingerprinting much sooner.

tptacek 7y ago
Be disappointed all you want, but they're not really "addressing" fingerprinting. It is exceptionally difficult --- computer-science Hard difficult --- to prevent fingerprinting; all you can really do is break popular libraries people use today. It's an arms race, and a much harder arms race than exploit-hardened runtimes are.
- techntoke 7y ago
  It's actually pretty easy overall... just don't use JavaScript and don't send user-agent string that shows browser/OS information.
  - ayrx 7y ago
    You will be part of the rare minority that uses that configuration which by itself is a fingerprint.
    - anonymfus 7y ago
      The point probably was to make that configuration default
      - tptacek 7y ago
        That configuration will not be the default. You might just as productively argue that the best way to defeat fingerprinting would be to default to Gopher.
        progval 7y ago
        You can do a lot of things with just HTML and CSS, more than what Gopher allows. And for what you can't, a banner asking for permission to run Javascript, like we have/had for Java/Flash/ActiveX
        olliej 7y ago
        Can a user meaningfully determine the correct answer to that question? The experience is “I clicked no and nothing worked” vs “I clicked yes and the site worked”. I get that you don’t like it, but the reality is that the web is a platform that includes JS as a core technology. The reason for limiting java and activex was because they had catastrophically terrible security properties more or less by design. Even flash had problems, but was sensible enough to correct many deficiencies and defer to the browser for interaction with anything outside of its view. Which is why you weren't asked about running flash on every website you went to. JS and the various web/html/dom APIs all have much much stricter constraints than anything flash had - they are designed to be safe in spite of all content being untrusted. More over dialogs like that are largely recognized among browser developers as being a form of blame shifting - a regular user has no reasonable way to determine whether or not saying “yes” is safe. The purpose of asking them, is so that if something does go wrong you can say “they shouldn’t have clicked yes”.
        progval 7y ago
        > Can a user meaningfully determine the correct answer to that question? > The experience is “I clicked no and nothing worked” vs “I clicked yes and the site worked”. I agree; but the extra click may be an insentive for web developpers to try not to use JS. > Which is why you weren't asked about running flash on every website you went to. Firefox did ask about running Flash, because "attackers can also use the security flaws in Flash": https://support.mozilla.org/en-US/kb/set-adobe-flash-click-play-firefox https://support.mozilla.org/en-US/kb/set-adobe-flash-click-p... > they are designed to be safe in spite of all content being untrusted But they have flaws, like Flash.
        tptacek 7y ago
        tomjen3 7y ago
        That would be pretty nice in many ways.
  - daxterspeed 7y ago
    No web browser is going to disable JavaScript by default and Google is one of the worst offenders when it comes to User-Agent sniffing (you can experiment with this on your own by setting a custom User-Agent and attempting to use various Google websites). And even then that's far from enough to stop fingerprinting. Ordering of http headers has been used to fingerprint browsers. The <picture> element can be used to leak browser screen size. CSS can leak information in @media and @support queries by requesting specific images. It's even possible to create "DNS cookies". More: http/2 passive fingerprinting: https://www.akamai.com/us/en/multimedia/documents/white-paper/passive-fingerprinting-of-http2-clients-white-paper.pdf https://www.akamai.com/us/en/multimedia/documents/white-pape... Fingerprinting servers based on header order: http://www.net-square.com/httprint_paper.html#httpheader http://www.net-square.com/httprint_paper.html#httpheader List of CSS Media queries, including vendor specific ones: https://browserleaks.com/css https://browserleaks.com/css DNS Cookies Demonstration: http://dnscookie.com/ http://dnscookie.com/
    - tptacek 7y ago
      DNS cookies, by the way, are awesome.
  - incompatible 7y ago
    User-agent strings should have been abolished long ago. It may not do much against sniffing, but it would spare us monstrosities like "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134"
    - cpv 7y ago
      I was surprised to see how many popular websites rely on things like user agent or referer header to deliver functionality. As soon as you start tinkering with them, they stop working, or say you use an older browser, etc.
      - olliej 7y ago
        Back in the day, safari 2.0.4 encountered a large amount of site breakage because sites were using useragent.indexof(“4”)!=-1 as the test for “are you Netscape 4”, and if you were then they’d use netscape’s layer apis (netscape’s alternative to css). Any changes to the user agent are very scary - that’s kind of how they ended being as terrible as they are. Yet still sites continue to use the user agent to gate access. The same sites also like to complain about how bizarre UA strings are.
    - om2 7y ago
      Unfortunately websites break if you stop sending it or dramatically change it. Most browsers can't afford the risk of a dramatic change here.
      - dredmorbius 7y ago
        Breaking things is (sometimes) the only way to progress.
  - olliej 7y ago
    Browser and OS information is not the biggest info leak, it really isn’t. Compared to cookies in the request. Time stamps in the request and the tls header. IP address, etc etc People vastly overestimate the value of those data in the UA
  - om2 7y ago
    There's a lot of fingerprintable info in HTTP headers other than User-Agent and in parts of the User-Agent string other than the browser/OS versions.
  - deleted 7y ago
    [deleted]
- deleted 7y ago
  [deleted]
- tomjen3 7y ago
  Is it? As I understand it, fingerprinting relies on properties and headers, both of which could be altered (eg adding headers for software that doesn't exist, and only sometimes, change the order, etc). You probably can't make them do it so that websites can't see the browser type, and you might not want to.
  - tptacek 7y ago
    No, fingerprinting is much deeper than that. Look at how DNS cookies work, for instance; you can create a serviceable fingerprint of a device just from how resolvers randomize multiple A records for the same label.
olliej 7y ago
This is a completely unrelated aspect of the modern web. Fingerprinting is a giant mess of edgecases to manage. For all my feelings on Chrome’s privacy track record, this is an incredibly big improvement to security across the web. More specifically this change to cookie policy is a “fix an entire class of security bugs” change vs piecemeal fixes to individual instance of a bug class.

Be disappointed all you want, but they're not really "addressing" fingerprinting. It is exceptionally difficult --- computer-science Hard difficult --- to prevent fingerprinting; all you can really do is break popular libraries people use today. It's an arms race, and a much harder arms race than exploit-hardened runtimes are.

techntoke 7y ago
It's actually pretty easy overall... just don't use JavaScript and don't send user-agent string that shows browser/OS information.
- ayrx 7y ago
  You will be part of the rare minority that uses that configuration which by itself is a fingerprint.
  - anonymfus 7y ago
    The point probably was to make that configuration default
    - tptacek 7y ago
      That configuration will not be the default. You might just as productively argue that the best way to defeat fingerprinting would be to default to Gopher.
      - progval 7y ago
        You can do a lot of things with just HTML and CSS, more than what Gopher allows. And for what you can't, a banner asking for permission to run Javascript, like we have/had for Java/Flash/ActiveX
        olliej 7y ago
        Can a user meaningfully determine the correct answer to that question? The experience is “I clicked no and nothing worked” vs “I clicked yes and the site worked”. I get that you don’t like it, but the reality is that the web is a platform that includes JS as a core technology. The reason for limiting java and activex was because they had catastrophically terrible security properties more or less by design. Even flash had problems, but was sensible enough to correct many deficiencies and defer to the browser for interaction with anything outside of its view. Which is why you weren't asked about running flash on every website you went to. JS and the various web/html/dom APIs all have much much stricter constraints than anything flash had - they are designed to be safe in spite of all content being untrusted. More over dialogs like that are largely recognized among browser developers as being a form of blame shifting - a regular user has no reasonable way to determine whether or not saying “yes” is safe. The purpose of asking them, is so that if something does go wrong you can say “they shouldn’t have clicked yes”.
        progval 7y ago
        > Can a user meaningfully determine the correct answer to that question? > The experience is “I clicked no and nothing worked” vs “I clicked yes and the site worked”. I agree; but the extra click may be an insentive for web developpers to try not to use JS. > Which is why you weren't asked about running flash on every website you went to. Firefox did ask about running Flash, because "attackers can also use the security flaws in Flash": https://support.mozilla.org/en-US/kb/set-adobe-flash-click-play-firefox https://support.mozilla.org/en-US/kb/set-adobe-flash-click-p... > they are designed to be safe in spite of all content being untrusted But they have flaws, like Flash.
        tptacek 7y ago
      - tomjen3 7y ago
        That would be pretty nice in many ways.
- daxterspeed 7y ago
  No web browser is going to disable JavaScript by default and Google is one of the worst offenders when it comes to User-Agent sniffing (you can experiment with this on your own by setting a custom User-Agent and attempting to use various Google websites). And even then that's far from enough to stop fingerprinting. Ordering of http headers has been used to fingerprint browsers. The <picture> element can be used to leak browser screen size. CSS can leak information in @media and @support queries by requesting specific images. It's even possible to create "DNS cookies". More: http/2 passive fingerprinting: https://www.akamai.com/us/en/multimedia/documents/white-paper/passive-fingerprinting-of-http2-clients-white-paper.pdf https://www.akamai.com/us/en/multimedia/documents/white-pape... Fingerprinting servers based on header order: http://www.net-square.com/httprint_paper.html#httpheader http://www.net-square.com/httprint_paper.html#httpheader List of CSS Media queries, including vendor specific ones: https://browserleaks.com/css https://browserleaks.com/css DNS Cookies Demonstration: http://dnscookie.com/ http://dnscookie.com/
  - tptacek 7y ago
    DNS cookies, by the way, are awesome.
- incompatible 7y ago
  User-agent strings should have been abolished long ago. It may not do much against sniffing, but it would spare us monstrosities like "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134"
  - cpv 7y ago
    I was surprised to see how many popular websites rely on things like user agent or referer header to deliver functionality. As soon as you start tinkering with them, they stop working, or say you use an older browser, etc.
    - olliej 7y ago
      Back in the day, safari 2.0.4 encountered a large amount of site breakage because sites were using useragent.indexof(“4”)!=-1 as the test for “are you Netscape 4”, and if you were then they’d use netscape’s layer apis (netscape’s alternative to css). Any changes to the user agent are very scary - that’s kind of how they ended being as terrible as they are. Yet still sites continue to use the user agent to gate access. The same sites also like to complain about how bizarre UA strings are.
  - om2 7y ago
    Unfortunately websites break if you stop sending it or dramatically change it. Most browsers can't afford the risk of a dramatic change here.
    - dredmorbius 7y ago
      Breaking things is (sometimes) the only way to progress.
- olliej 7y ago
  Browser and OS information is not the biggest info leak, it really isn’t. Compared to cookies in the request. Time stamps in the request and the tls header. IP address, etc etc People vastly overestimate the value of those data in the UA
- om2 7y ago
  There's a lot of fingerprintable info in HTTP headers other than User-Agent and in parts of the User-Agent string other than the browser/OS versions.
- deleted 7y ago
  [deleted]
deleted 7y ago
[deleted]
tomjen3 7y ago
Is it? As I understand it, fingerprinting relies on properties and headers, both of which could be altered (eg adding headers for software that doesn't exist, and only sometimes, change the order, etc). You probably can't make them do it so that websites can't see the browser type, and you might not want to.
- tptacek 7y ago
  No, fingerprinting is much deeper than that. Look at how DNS cookies work, for instance; you can create a serviceable fingerprint of a device just from how resolvers randomize multiple A records for the same label.

olliej 7y ago

This is a completely unrelated aspect of the modern web. Fingerprinting is a giant mess of edgecases to manage. For all my feelings on Chrome’s privacy track record, this is an incredibly big improvement to security across the web. More specifically this change to cookie policy is a “fix an entire class of security bugs” change vs piecemeal fixes to individual instance of a bug class.