Browser leaks <canvas> fingerprint through iframes

[frzsombor]

Description

On Firefox, I am using a fingerprint blocking plugin called CanvasBlocker, which seems working pretty well. There is also a test page for that plugin. Using Firefox and the plugin, I always get "faked" fingerprint in all test cases, but it looks like Brave browser leaks the original fingerprint even in strict mode in some test cases. (I only checked the canvas tests)

Steps to Reproduce

1. Set fingerprint protection to standard or strict
2. Navigate to https://canvasblocker.kkapsner.de/test/test.html
3. iFrame Test 4, iFrame Test 5 and iFrame Test 6 leaks original fingerprint

Actual result:

Original (equal to Google Chrome) fingerprint gets displayed in some cases.

Expected result:

Same fake fingerprint in all test cases

Reproduces how often:

All the time

Brave version (brave://version info)

Brave | 1.16.68 Chromium: 86.0.4240.111

[diracdeltas]

cc @pes10k

[pes10k]

This is already fixed :) brave/brave-core#6941

[frzsombor]

@pes10k I've downloaded and tried it with the (almost) latest, Version 1.18.30 Chromium: 87.0.4280.40 (Official Build) nightly (x86_64) version, but experienced the same issues.

[pes10k]

@frzsombor Ah, looks like there are still paths not covered. Thank you very much for the bug report. We'll get it sorted!

[stephendonner]

@goodov @pes10k for the testplan here, is it:

1. load https://canvasblocker.kkapsner.de/test/test.html
2. ensure that all hashes match?

That's what the original report says, just wanted to double-check 👍

[frzsombor]

For me, the last three test cases (blob Test, offscreen Test, offscreen Worker Test) are NOT the same as the other test cases above them in a fresh Chrome, but identical to each other. When I posted this issue I debugged the code of the website and I found that this is not a problem but a normal behaviour, however can't remember the reason for the difference. The problem was that the hashes starting with 'cd475...' were the same as I saw (and still see) in an original Chrome. I think the goal should be that all the test cases should be different from the ones that someone sees in a Chrome browser and they should be identical to each other - except the last three, but those should also be identical to each other. I hope this makes sense and thanks for your work.

[stephendonner]

Verified PASSED using the inline testplan, and comparing Chrome

Google Chrome	90.0.4430.85 (Official Build) (x86_64)
Revision	5bc145d831c180d9ff94f29a0d7a2e1cbd30ef36-refs/branch-heads/4430@{#1311}
OS	macOS Version 11.2.3 (Build 20D91)

to both Shields down and Shields up behaviors on

Brave	1.25.33 Chromium: 90.0.4430.85 (Official Build) nightly (x86_64)
Revision	5bc145d831c180d9ff94f29a0d7a2e1cbd30ef36-refs/branch-heads/4430@{#1311}
OS	macOS Version 11.2.3 (Build 20D91)

Steps:

1. load https://canvasblocker.kkapsner.de/test/test.html in Chrome and Shields down Brave
2. confirmed they have the same Hash: 392ca3251952e526ce62c27e478e4a5d50d7417df441c761ec74cf7b1bd7a192 / 2ec58fab03d6b0c6782a0c44664577f666cbd1b4542a2c4b6f4cd9ceebe4b57a values
3. switched Shields up and confirmed that Brave's hashes changed to Hash: 8006fe98c0587ea98bf5b16920630ec8d638550e187b445a9765f05f0a9d411b / f626a2480fedf5265962aff4f5de4ffde041a3259a4e9bd306dcc69c45390999

Chrome vs. Shields-down Brave	Chrome vs. Shields-up Brave 👍

---

Verification passed on

Brave | 1.25.53 Chromium: 90.0.4430.93 (Official Build) beta (64-bit)
-- | --
Revision | 4df112c29cfe9a2c69b14195c0275faed4e997a7-refs/branch-heads/4430@{#1348}
OS | Windows 10 OS Version 2004 (Build 19041.928)

Details

• Ensured all the hashes are equal for each test
• Ensured the hash before and after the "/" do not match
• Ensured if "refresh" is clicked the hash isn't changed

Shield Down	Shield Up

---

Verification passed on

Brave	1.25.59 Chromium: 90.0.4430.212 (Official Build) beta (64-bit)
Revision	e3cd97fc771b893b7fd1879196d1215b622c2bed-refs/branch-heads/4430@{#1429}
OS	Ubuntu 18.04 LTS

Ensured the hash is changed when shields are up