5 ms·

Firefox makes a fuss about anti-fingerprinting, and I have "Enhanced Tracking Protection" set to Strict, yet I see uncommon values for WebGL Vendor and WebGL Re

Firefox makes a fuss about anti-fingerprinting, and I have "Enhanced Tracking Protection" set to Strict, yet I see uncommon values for WebGL Vendor and WebGL Renderer in https://amiunique.org/fp https://amiunique.org/fp . Unless this study feeds into changing things like that, it seems a bit pointless.

codetrotter 6y ago
> yet I see uncommon values for WebGL Vendor and WebGL Renderer I don’t know how Firefox does it but instead of trying to make the WebGL fingerprint the same for everyone every time they could also try to make it unique for everyone every time and it would have the same effect. If every time you loaded a page your WebGL fingerprint differed then a website can’t use that to tell if it was the same browser that loaded the same page previously or any other page anywhere else previously. (Assuming that the WebGL fingerprint anonymization was so good that it could indeed not be correlated between different fingerprints in any meaningful way.)
- bluedispatcher 6y ago
  This is what Brave does if I'm not mistaken.
- kmeisthax 6y ago
  Part of the problem with either approach is that certain identifying information is also necessary for just making the web work. For example, on the EFF's Cover Your Tracks page (what is basically a fingerprinting demonstration), it shows that the screen resolution of my monitor conveys 16.25 bits of information. I use a particularly wonky landscape display mounted in portrait mode, which doesn't help the matter, but there's a problem: we can't lie about it. You see, a while back we decided to allow writing CSS that changed the design of a website based on the size of it's containing viewport. This is called "responsive design" and is very useful; however, it also means that websites rely on having a correct window size in order to display content correctly. We cannot be inconsistent about our lies: if we were to, say, lie about the screen resolution but still handle media queries faithfully, then not only can the fingerprinter see through our lie, it can use the fact that we lied as extra information. (Remember how DNT served as an effective tracking indicator?) So that would mean browsers would have to start, say, snapping browser windows to certain common viewports or capping the number of distinct breakpoints a website's CSS is allowed to have; both of which have UX or compatibility implications.
  - ifigjfur8485 6y ago
    A better long term solution would be to make websites behave more like print has for the past 500 years, and only allow them to pull info from the server while greatly restricting what they can transmit back. Only allow POST buttons to send home strictly textual data the users themselves typed out. Yeah, this would break certain cool legit websites like those that run HTML5 games that need to constantly transmit info back to the server. But this wouldn't have to break sites like HN/Reddit/Twitter/news/science/whatever. If you wanted a web that could give you beautiful images and typography without fingerprinting, such a thing could be built. It would break big Adtech tracking though so we'll never see this simplifying improvement in a big-Adtech funded browser (like Chromium).
    - codetrotter 6y ago
      > Only allow POST buttons to send home strictly textual data the users themselves typed out I’m almost with you but in that case even shopping online would not work. Unless you force the user to manually type in the SKU of each item they want to add to their cart and so on. That’s not gonna happen :p
      - iuiujmfi787 6y ago
        Good point. There would be a few details like this to work out, of course. My first suggestion would be to allow text-boxes to be pre-populated with form data (like QTY and SKU) subject to tight restrictions. (There would be no script code sniffing the user's fingerprint before the text boxes are populated with SKU data, for example.) So a web dev could still create a shopping page with Add-to-Cart buttons such that clicking the button tells the server the SKU and QTY added to cart for session SESSION_ID. And the user transparently observes exactly which sequence of Unicode codepoints is being transmitted to the server upon clicking the Add-to-Cart button.
    - kmeisthax 6y ago
      >and only allow them to pull info from the server while greatly restricting what they can transmit back The first forms of user tracking involved 1px GIFs that existed purely so that the server could log the request. If you allow any code execution at all, then the client can send data back to the server by asking for data from the server. Reads are just bidirectional writes.

codetrotter 6y ago

> yet I see uncommon values for WebGL Vendor and WebGL Renderer I don’t know how Firefox does it but instead of trying to make the WebGL fingerprint the same for everyone every time they could also try to make it unique for everyone every time and it would have the same effect. If every time you loaded a page your WebGL fingerprint differed then a website can’t use that to tell if it was the same browser that loaded the same page previously or any other page anywhere else previously. (Assuming that the WebGL fingerprint anonymization was so good that it could indeed not be correlated between different fingerprints in any meaningful way.)

bluedispatcher 6y ago
This is what Brave does if I'm not mistaken.
kmeisthax 6y ago
Part of the problem with either approach is that certain identifying information is also necessary for just making the web work. For example, on the EFF's Cover Your Tracks page (what is basically a fingerprinting demonstration), it shows that the screen resolution of my monitor conveys 16.25 bits of information. I use a particularly wonky landscape display mounted in portrait mode, which doesn't help the matter, but there's a problem: we can't lie about it. You see, a while back we decided to allow writing CSS that changed the design of a website based on the size of it's containing viewport. This is called "responsive design" and is very useful; however, it also means that websites rely on having a correct window size in order to display content correctly. We cannot be inconsistent about our lies: if we were to, say, lie about the screen resolution but still handle media queries faithfully, then not only can the fingerprinter see through our lie, it can use the fact that we lied as extra information. (Remember how DNT served as an effective tracking indicator?) So that would mean browsers would have to start, say, snapping browser windows to certain common viewports or capping the number of distinct breakpoints a website's CSS is allowed to have; both of which have UX or compatibility implications.
- ifigjfur8485 6y ago
  A better long term solution would be to make websites behave more like print has for the past 500 years, and only allow them to pull info from the server while greatly restricting what they can transmit back. Only allow POST buttons to send home strictly textual data the users themselves typed out. Yeah, this would break certain cool legit websites like those that run HTML5 games that need to constantly transmit info back to the server. But this wouldn't have to break sites like HN/Reddit/Twitter/news/science/whatever. If you wanted a web that could give you beautiful images and typography without fingerprinting, such a thing could be built. It would break big Adtech tracking though so we'll never see this simplifying improvement in a big-Adtech funded browser (like Chromium).
  - codetrotter 6y ago
    > Only allow POST buttons to send home strictly textual data the users themselves typed out I’m almost with you but in that case even shopping online would not work. Unless you force the user to manually type in the SKU of each item they want to add to their cart and so on. That’s not gonna happen :p
    - iuiujmfi787 6y ago
      Good point. There would be a few details like this to work out, of course. My first suggestion would be to allow text-boxes to be pre-populated with form data (like QTY and SKU) subject to tight restrictions. (There would be no script code sniffing the user's fingerprint before the text boxes are populated with SKU data, for example.) So a web dev could still create a shopping page with Add-to-Cart buttons such that clicking the button tells the server the SKU and QTY added to cart for session SESSION_ID. And the user transparently observes exactly which sequence of Unicode codepoints is being transmitted to the server upon clicking the Add-to-Cart button.
  - kmeisthax 6y ago
    >and only allow them to pull info from the server while greatly restricting what they can transmit back The first forms of user tracking involved 1px GIFs that existed purely so that the server could log the request. If you allow any code execution at all, then the client can send data back to the server by asking for data from the server. Reads are just bidirectional writes.