5 ms·

I both love and hate this. I'm all for anti-fingerprinting, but i'm also for interactive graphics on the web, and getImageData() is essentially your way of acc

by tomxor 4y ago

I both love and hate this. I'm all for anti-fingerprinting, but i'm also for interactive graphics on the web, and getImageData() is essentially your way of accessing a pixel buffer... I would be better if it was more conditional. e.g instead gate the call that ultimately attempts to send any derivatives of that data over the network - although I understand that may entail significant complexity in the JS engine. Alternatively, gate getImageData() only if fingerprintable context methods have previously been called, i.e those with antialiasing, compositing, blending differences etc or any other rendering method with potential differences emerging from the underlying algorithm. That way someone just trying to use the pixel buffer as an output doesn't get punished by needlessly causing modals to be thrown in front of the user.

infinityio 4y ago
I wonder whether introducing slight per-pixel-per-draw noise into the values could be used here, to mask this sort of detail? Or would you be able to average it out somehow
- gruez 4y ago
  >Or would you be able to average it out somehow Isn't it pretty obvious? Generate the same image 1000 times and take the median pixel value for each pixel to get the "real" image.
  - leodriesch 4y ago
    If the noise would not change between individual calls but only on page reloads it would be pretty hard to get 1000 samples.
    - gruez 4y ago
      how do you ensure the noise doesn't change between calls? if I want to fingerprint how the letter "a" is rendered, how do you ensure that I can't try drawing "a1", "a2", "a3", etc. which are "different" draw calls, but still allow me to build a composite image of what "a" looks like?
- tomxor 4y ago
  I think you're right on both... adding noise would reduce the accuracy of the fingerprint, but boarder biases would continue to be detectable. For instance i'm aware of some quite significant biases between firefox and chrome in antialiasing fillRect() for subipixel values as the dimensions drop bellow 1x1 pixel that only a distracting amount of noise would be able to conceal for one sample. I know that's already detectable via the useragent string, but I suspect those who are focused on collecting those biases will find strong ones for other data points.
- fn-mote 4y ago
  In general noise is never the answer to fingerprinting. It makes gathering "accurate" data a little harder; it doesn't stop statistical analysis from revealing the truth.
- antonok 4y ago
  This totally works as an approach! Brave does it for canvas data and a bunch of other web APIs as well. The "farbling" noise is deterministic per profile/origin combo to prevent being able to average it out across multiple page loads, but otherwise random. https://brave.com/privacy-updates/4-fingerprinting-defenses-2.0/ https://brave.com/privacy-updates/4-fingerprinting-defenses-...
  - codedokode 4y ago
    This allows to run fingerprinting script on hundred of domains and filter out the noise though.
    - antonok 4y ago
      If you own hundreds of domains, you're welcome to try, but there's no good reason to. Fingerprinting scripts rely on a canvas being identical between sessions to identify that the same user is even there in the first place. If you can already single out one user's activity across a hundred domains, you don't need to fingerprint them any further.
cowtools 4y ago
I've also encountered problems with getImageData(). I just want to be able to blit a sprite sheet for god's sake. It would be tolerable if there were a couple pre-defined functions that could handle blitting, compositing and other operations, and return an HTMLImageElement with the same permissions as the source. The problem I forsee with getImageData() and gl.readPixels() is that despite all this security, it's possible that it leaks some data through the openGL implementation, like with a spectre/meltdown type attack. Like imagine there is some cached data on the GPU that lingers between draw calls, I don't know.
jimmaswell 4y ago
Gimping features like this by default is going way too far and will only lead to giving Chrome more dominance.
- gruez 4y ago
  What do you mean "by default"? Unless you have resistfingerprint enabled (not the default), webgl/canvas should behave as expected. If you're the type of developer that takes offense to this (ie. the user agent acting in a manner that the user would like it to act), I think that's going too far for you as a developer, and would only lead to the dominance of your competitor ;)
  - dessant 4y ago
    The problem starts when the user has not been educated about the potential drawbacks of enabling such a feature. The privacy.resistFingerprinting option is the leading cause for angry Firefox users and unwarranted negative reviews on my part, despite being an obscure feature that can only be enabled from config. Things will break in unexpected ways, while web developers are the ones expected to spend their time offering support for a browser that has been rendered broken. They need to be very careful about how these features are presented, and evaluate how they affect the entire web ecosystem.
    - gruez 4y ago
      >They need to be very careful about how these features are presented, and evaluate how they affect the entire web ecosystem. It's hidden behind an about:config option (rather than being in the settings page), and the linked article literally says "It is likely that it may degrade your Web experience so we recommend it only for those willing to test experimental features". What more do you want?
      - 6510 4y ago
        Give the settings page a "blog" (like the extensions page) describing each setting that has been changed manually in a way users can understand it so that they might learn the drawbacks and can restore it.
robonerd 4y ago
> interactive graphics on the web, and getImageData() is essentially your way of accessing a pixel buffer I'm sure it's a great feature when you need it, but most websites have no legitimate need for it. Having this sort of feature off/blocked by default and whitelisted on a case-by-case basis makes a lot of sense to me. Are you trying to use a webapp image editor? Makes sense to whitelist it. Are you trying to read a local newspaper article online? Keep that shit off by default. In fact, that's how I treat even first-party javascript, because most websites are made worse by turning javascript on. It seems to follow a 90-9-1 rule; 90% of websites need no javascript, 9% need first-party javascript whitelisted, and 1% require some 3rd-party javascript.
- woojoo666 4y ago
  Whether or not you need it is tangential imo. People should be able to experience cool interactive visuals on websites without sacrificing their privacy
- horsawlarway 4y ago
  The problem here is that the main audience impacted by these "permissions prompts" has zero idea whether what the site is requesting makes any sense. You - as a developer - probably know that an image editing site might need this permission and other sites don't. The average user has zero (ZERO) clue. They don't know, they don't really care. Instead they arbitrarily accept or deny based on how scary the popup text is, or how annoying it becomes, or how much they depend on the site. Which is pretty terrible from all perspectives - Users get prompts that require decisions that they don't have the knowledge or context for. - Valid sites & businesses lose traffic because some users are scared away by scary sounding prompts that they don't understand. - Malicious sites still get a broad swath of data on users who don't give a rats ass about the prompts and have been conditions to just always hit yes. I think this style of implementation is basically always indicative of a failure.
  - mmis1000 4y ago
    I think that is basically why vista's UAC prompt is so hated. They jump on so many place may or may not relevant to user's safety. And users don't really have clue the request is valid or not. Ends up just accept everything or "ok google, how to disable the damn UAC propmt"
diebeforei485 4y ago
Pages without a large visible (z index) canvas don't need this info.

by tomxor 4y ago

infinityio 4y ago

I wonder whether introducing slight per-pixel-per-draw noise into the values could be used here, to mask this sort of detail? Or would you be able to average it out somehow

gruez 4y ago
>Or would you be able to average it out somehow Isn't it pretty obvious? Generate the same image 1000 times and take the median pixel value for each pixel to get the "real" image.
- leodriesch 4y ago
  If the noise would not change between individual calls but only on page reloads it would be pretty hard to get 1000 samples.
  - gruez 4y ago
    how do you ensure the noise doesn't change between calls? if I want to fingerprint how the letter "a" is rendered, how do you ensure that I can't try drawing "a1", "a2", "a3", etc. which are "different" draw calls, but still allow me to build a composite image of what "a" looks like?
tomxor 4y ago
I think you're right on both... adding noise would reduce the accuracy of the fingerprint, but boarder biases would continue to be detectable. For instance i'm aware of some quite significant biases between firefox and chrome in antialiasing fillRect() for subipixel values as the dimensions drop bellow 1x1 pixel that only a distracting amount of noise would be able to conceal for one sample. I know that's already detectable via the useragent string, but I suspect those who are focused on collecting those biases will find strong ones for other data points.
fn-mote 4y ago
In general noise is never the answer to fingerprinting. It makes gathering "accurate" data a little harder; it doesn't stop statistical analysis from revealing the truth.
antonok 4y ago
This totally works as an approach! Brave does it for canvas data and a bunch of other web APIs as well. The "farbling" noise is deterministic per profile/origin combo to prevent being able to average it out across multiple page loads, but otherwise random. https://brave.com/privacy-updates/4-fingerprinting-defenses-2.0/ https://brave.com/privacy-updates/4-fingerprinting-defenses-...
- codedokode 4y ago
  This allows to run fingerprinting script on hundred of domains and filter out the noise though.
  - antonok 4y ago
    If you own hundreds of domains, you're welcome to try, but there's no good reason to. Fingerprinting scripts rely on a canvas being identical between sessions to identify that the same user is even there in the first place. If you can already single out one user's activity across a hundred domains, you don't need to fingerprint them any further.

cowtools 4y ago

I've also encountered problems with getImageData(). I just want to be able to blit a sprite sheet for god's sake. It would be tolerable if there were a couple pre-defined functions that could handle blitting, compositing and other operations, and return an HTMLImageElement with the same permissions as the source. The problem I forsee with getImageData() and gl.readPixels() is that despite all this security, it's possible that it leaks some data through the openGL implementation, like with a spectre/meltdown type attack. Like imagine there is some cached data on the GPU that lingers between draw calls, I don't know.

jimmaswell 4y ago

Gimping features like this by default is going way too far and will only lead to giving Chrome more dominance.

gruez 4y ago
What do you mean "by default"? Unless you have resistfingerprint enabled (not the default), webgl/canvas should behave as expected. If you're the type of developer that takes offense to this (ie. the user agent acting in a manner that the user would like it to act), I think that's going too far for you as a developer, and would only lead to the dominance of your competitor ;)
- dessant 4y ago
  The problem starts when the user has not been educated about the potential drawbacks of enabling such a feature. The privacy.resistFingerprinting option is the leading cause for angry Firefox users and unwarranted negative reviews on my part, despite being an obscure feature that can only be enabled from config. Things will break in unexpected ways, while web developers are the ones expected to spend their time offering support for a browser that has been rendered broken. They need to be very careful about how these features are presented, and evaluate how they affect the entire web ecosystem.
  - gruez 4y ago
    >They need to be very careful about how these features are presented, and evaluate how they affect the entire web ecosystem. It's hidden behind an about:config option (rather than being in the settings page), and the linked article literally says "It is likely that it may degrade your Web experience so we recommend it only for those willing to test experimental features". What more do you want?
    - 6510 4y ago
      Give the settings page a "blog" (like the extensions page) describing each setting that has been changed manually in a way users can understand it so that they might learn the drawbacks and can restore it.

robonerd 4y ago

> interactive graphics on the web, and getImageData() is essentially your way of accessing a pixel buffer I'm sure it's a great feature when you need it, but most websites have no legitimate need for it. Having this sort of feature off/blocked by default and whitelisted on a case-by-case basis makes a lot of sense to me. Are you trying to use a webapp image editor? Makes sense to whitelist it. Are you trying to read a local newspaper article online? Keep that shit off by default. In fact, that's how I treat even first-party javascript, because most websites are made worse by turning javascript on. It seems to follow a 90-9-1 rule; 90% of websites need no javascript, 9% need first-party javascript whitelisted, and 1% require some 3rd-party javascript.

woojoo666 4y ago
Whether or not you need it is tangential imo. People should be able to experience cool interactive visuals on websites without sacrificing their privacy
horsawlarway 4y ago
The problem here is that the main audience impacted by these "permissions prompts" has zero idea whether what the site is requesting makes any sense. You - as a developer - probably know that an image editing site might need this permission and other sites don't. The average user has zero (ZERO) clue. They don't know, they don't really care. Instead they arbitrarily accept or deny based on how scary the popup text is, or how annoying it becomes, or how much they depend on the site. Which is pretty terrible from all perspectives - Users get prompts that require decisions that they don't have the knowledge or context for. - Valid sites & businesses lose traffic because some users are scared away by scary sounding prompts that they don't understand. - Malicious sites still get a broad swath of data on users who don't give a rats ass about the prompts and have been conditions to just always hit yes. I think this style of implementation is basically always indicative of a failure.
- mmis1000 4y ago
  I think that is basically why vista's UAC prompt is so hated. They jump on so many place may or may not relevant to user's safety. And users don't really have clue the request is valid or not. Ends up just accept everything or "ok google, how to disable the damn UAC propmt"

diebeforei485 4y ago

Pages without a large visible (z index) canvas don't need this info.