[jackbeck]

The problem with a lot of these attempts at fingerprinting prevention is that they cause additional data which can be used to more accurately fingerprint users.

getImageData() is blocked - datapoint

Any detectable difference from what a “regular” browser would return is another point of entropy.

[danShumway]

It's a problem to be aware of, definitely.

However, the accuracy of device fingerprinting with `getImageData()` is as far as I can tell a lot higher than the accuracy from trying to fingerprint people based on whether they're returning blank data from that call.

If turning off a feature reveals a new 3 bits of information, but leaving it on would have revealed 5 bits, then it's still probably a good idea to turn it off.

Again, not to say that people shouldn't care about those 3 bits, they should. But it's not necessarily a waste of time even if a site tries to use anti-fingerprinting as its own metric. It only becomes a waste of time if the anti-fingerprinting is more unique than leaving the holes open.

[jackbeck]

Yup, I agree with you about this. It’d be interesting to do a deep dive into a library like FingerprintJS and see what has the most weight in terms of uniqueness. Maybe getImageData is worthwhile blocking, but perhaps other APIs will increase the amount of entropy.

[m-p-3]

If the default for Firefox is that it blocks these, then you don't really get a useful datapoint.

[jackbeck]

At the moment it’s not the default though. So people who enable this feature will, ironically be more unique and therefore more accurately fingerprintable.