1962412 - Canvas randomization is ineffective

Status: NEW

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Masatoshi Kimura [:emk]]

Attachment: unrandomize.html

Steps to reproduce:
Open the attached file in private browsing.

Actual result:
The script can recover original (unrandomized) pixels.

Expected result:
We should either make the canvas randomization effective or remove the false sense of privacy measures. The current implementation does not worth web-compat tradeoff IMO.

Comment 1

[Emma Zühlcke [:emz]]

Tom, could you take a look? Thanks!

Comment 2

[Tom Ritter [:tjr] (OOTO until April)]

It is expected that determined adversaries can bypass canvas randomization - but that doesn't mean that fingerprinters actually do so. When deployed fingerprinting scripts are still being mislead by the randomization, it still has considerable value. Presently, I'm not aware of any fingerprinting script that has bypassed FF's randomization (although we know its possible) although they detect and ignore Brave's and Safari's.

Independent of that, I'm don't think your POC is actually demonstrating a randomization bypass. You generate a known image programmatically, then detect the randomness we add. Canvas randomization is designed to make fingerprinting canvases - where the adversary doesn't know value of the image ahead of time - different between origins (and other contexts, such as Normal vs PBM) so they cannot be correlated.

Comment 3

[Masatoshi Kimura [:emk]]

Attachment: unrandomize.html

(In reply to Tom Ritter [:tjr] from comment #2)

It is expected that determined adversaries can bypass canvas randomization

Please do not treat legitimate users as adversaries.

but that doesn't mean that fingerprinters actually do so. When deployed fingerprinting scripts are still being mislead by the randomization, it still has considerable value. Presently, I'm not aware of any fingerprinting script that has bypassed FF's randomization (although we know its possible) although they detect and ignore Brave's and Safari's.

I guess fingerprinters did not know it is so easy to bypass the randomization.

Independent of that, I'm don't think your POC is actually demonstrating a randomization bypass. You generate a known image programmatically, then detect the randomness we add. Canvas randomization is designed to make fingerprinting canvases - where the adversary doesn't know value of the image ahead of time - different between origins (and other contexts, such as Normal vs PBM) so they cannot be correlated.

I updated the recover script so that it does not access the original image at all.

Comment 4

[Tom Ritter [:tjr] (OOTO until April)]

(In reply to Masatoshi Kimura [:emk] from comment #3)

Created attachment 9480980 [details]
unrandomize.html

(In reply to Tom Ritter [:tjr] from comment #2)

It is expected that determined adversaries can bypass canvas randomization

Please do not treat legitimate users as adversaries.

:confused: Firefox users can disable canvas randomization globally by controlling the ETP settings and on individual pages with the ETP Toggle. I'm referring to fingerprinters.

but that doesn't mean that fingerprinters actually do so. When deployed fingerprinting scripts are still being mislead by the randomization, it still has considerable value. Presently, I'm not aware of any fingerprinting script that has bypassed FF's randomization (although we know its possible) although they detect and ignore Brave's and Safari's.

I guess fingerprinters did not know it is so easy to bypass the randomization.

We are taking advantage of that fact. When fingerprinters evolve their scripts we will have to change the canvas randomization behavior - it's an arms race that we will never be able to win but as long as we are ahead then cross-site tracking of Firefox users is thwarted. There might eventually become a point where the effort needed to trick fingerprinters is so great we have to give up, but fortunately that seems like it might be a very long time from now.

Comment 5

[Thorin [:thorin]]

unless I'm missing something with this PoC ...

Using a known pixel test to determine that randomizing is happening is expected and nothing new. A known pixel test holds no real entropy. In a closed set of users, such as Firefox FPP users - it can reveal if it is per execution or persistent, and it can reveal degrees of randomizing (what channels, % of pixels, range of shift in values) - but all users are the same so this is equivalency. By reverting the altered pixels with the known ones to return what you already know is not achieving anything - all you did was determine that canvas is protected (and other equivalency of FPP canvas). A canvas test that exposes entropy would not be a known canvas - it would be compiled with e.g. css named colors, math (transforming), shapes/curves, fonts, text etc so as to produce different results with hopefully maximum entropy (the whole point of fingerprinting)

What pixels and what channels (rgb) are altered, and by how much is protected by a seed per first party partitioning, and is applied per canvas - so knowing that pixels a, b, and c are changed in one canvas, does not translate to the next canvas. If you want to revert the randomizing, you will have to average, which can be expensive for fingerprinting scripts - and in terms of commercial/advertising tracking is simply not going to happen with all the low hanging fruit (the 95% of users who lack protection) and given Firefox's threat model this is not an issue (yet)

+1 INVALID or WONTFIX

Comment 6

[Masatoshi Kimura [:emk]]

(In reply to Tom Ritter [:tjr] from comment #4)

:confused: Firefox users can disable canvas randomization globally by controlling the ETP settings and on individual pages with the ETP Toggle. I'm referring to fingerprinters.

The "user" here means the user of the Canvas API, not the end user of the browser. Some web apps (such as image editors) have to ask end users to disable private mode and ETP strict.

Comment 7

[Masatoshi Kimura [:emk]]

(In reply to Thorin [:thorin] from comment #5)

unless I'm missing something with this PoC ...

Using a known pixel test to determine that randomizing is happening is expected and nothing new. A known pixel test holds no real entropy. In a closed set of users, such as Firefox FPP users - it can reveal if it is per execution or persistent, and it can reveal degrees of randomizing (what channels, % of pixels, range of shift in values) - but all users are the same so this is equivalency. By reverting the altered pixels with the known ones to return what you already know is not achieving anything - all you did was determine that canvas is protected (and other equivalency of FPP canvas). A canvas test that exposes entropy would not be a known canvas - it would be compiled with e.g. css named colors, math (transforming), shapes/curves, fonts, text etc so as to produce different results with hopefully maximum entropy (the whole point of fingerprinting)

This is not a known pixel test. This script does not require any prior information about the canvas pixels. The PoC uses a known image only for automated testing. The actual fingerprinting script will of course draw in canvas in a way that maximizes entropy. Even in that case, this script can restore pixels exactly the same way.

Let me explain how this script is restoring the pixels.
Call getImageData() to get a randomized data. Some pixels are randomized. (x = unaltered, y = randomized)
(1) xx xx yx xx xx xx xx xy xx xx xx xx yx xx xx xx
Flip the first bit and call getImageData() again. Different pixels will be randomized because the seed includes the canvas data itself.
(2) zx xx xx xx yx xx xx xx xx xx xy xx xx xx xx xy
Flip the second bit and call getImageData() once again.
(3) xz xx xx xx xy xx yx xx xx xx xx xx xx yx xx xx
Take a majority vote between (1) to (3) to decide which pixel to use.
(4) xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx

If the same pixel happens to be randomized, the restore fails. But the failure rate converges to zero if the canvas has enough pixels because the current randomize implementation will randomize at most 255 bits.

Comment 8

[Thorin [:thorin]]

This is not a known pixel test ... The PoC uses a known image ....

OK. That wasn't clear. The PoC should use a real world fingerprinting canvas

If you want to revert the randomizing, you will have to average, which can be expensive for fingerprinting scripts

So averaging then. This is a known limitation of subtle randomization.