1863439 - RFP ignores solid-color canvas randomizing exception

Status: RESOLVED WONTFIX

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

Description

[Thorin [:thorin]]

Bug 1852541 provided a solution to not randomize canvas if it was a solid color (rgba). This works for FPP but not RFP

test: https://arkenfox.github.io/TZP/tests/canvasnoise.html

control

• disable RFP
• normal window
  • expected: green matches
• private window (FPP)
  • expected: red hashes and result is [cached]
  • check "use a solid color" and click re-run: expected: green matches

test

• enable RFP
• in any window
  • expected: red hashes and result is [per-execution]
  • check "use a solid color" and click re-run
    • expected: green matches
    • got: red hashes etc

Comment 1

[Tom Ritter [:tjr]]

I looked at the code but could not figure out why this is happening... Might need to throw a bunch of debug statements around.

Comment 2

[Fatih Kilic]

Attachment: Bug 1863439: Check solid color canvas before randomizing. r?timhuang

This patch extracts previous AllPixelsMatch lambda to its own public function. AllPixelsMatch is then used to check if the canvas is only a solid color before returning a placeholder or a randomized canvas.

Comment 3

[Thorin [:thorin]]

So before we do this, can we confirm that a repeated 1 x 1 px canvas (and therefore guaranteed a single color) with repeated calls where the "element" in it is moved each time to plot a full canvas, is not feasible? e.g. the letter a since it has lots of curves in it. Draw that positioned at 0,0 and measure, then 0,1 and measure etc

Comment 4

[Fatih Kilic]

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

So before we do this, can we confirm that a repeated 1 x 1 px canvas (and therefore guaranteed a single color) with repeated calls where the "element" in it is moved each time to plot a full canvas, is not feasible? e.g. the letter a since it has lots of curves in it. Draw that positioned at 0,0 and measure, then 0,1 and measure etc

Hmm I think this is a workaround for this protection. We only check if the canvas size is more than 1x1 (I said canvas size but I'm not sure if we are using the canvas size or the size passed to getImageData call, if it is the latter then the situation is possibly even worse). I can't think of a way to protect against this except for software rendering, but my knowledge around the browser and the canvas API is still very little. I'll try to write some tests for the cases you mentioned and see if this workaround is possible. (I'm almost pretty sure drawing at 0,1 then 0,2 should be a valid workaround, I want to see if getImageData with 1 pixel calls is also a workaround)

Comment 5

[Fatih Kilic]

Yeah it looks like there is a workaround https://codepen.io/fklc/pen/MWMeqXq. Even with +AllTargets or resistfingerprinting, you get non-zero pixels and they are not randomized

Comment 6

[Fatih Kilic]

I think it makes more sense to track this in another bug though. I created a new bug 1909476

Comment 7

[Fatih Kilic]

Do we want to land this though? The current implementation of solid color check prevents this protection workaround. It is a bug but also a feature I guess?

Comment 8

[Thorin [:thorin]]

OK, so my thoughts are RFP does not want this as it is an exploit that can compromise a user's fingerprint. I've pinged richard, lets see what they say.

FPP has a different threat model, and I think the universal solid color canvas exception needs a rethink - make it a per site remote override so it's not universal. Can't believe meet caused this :)

Edit: and I totally realize that I opened the issue :)