1663586 - privacy.resistFingerprinting.randomDataOnCanvasExtract causes canvas glitches on https://london.my-netdata.io

Status: REOPENED

(Core :: Graphics: Canvas2D, defect)

Description

[Yannick Markus]

Attachment: Screenshot_with_error.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Hardware:

• CPU: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz
• iGPU: VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
  Software:
• OS: NixOS 20.03.2910.42674051d12 (Markhor)
• Kernel: 5.4.62
• iGPU driver: i915
• Firefox: Mozilla Firefox 80.0

This bug happens in any window manager / desktop manager and every window protocol I've tried; here a list:

• SwayWM (Wayland) with wayland support in firefox enabled
• SwayWM without wayland support enabled (xwayland window protocol)
• Any X11 desktop manager (e.g. KDE Plasma)

As an example, you can visit https://london.my-netdata.io/ which is a demo site for netdata, hosted by DigitalOcean. It also corrupts some QR codes (I remember seeing it in Nextcloud) and https://devdocs.io favicon.

Actual results:

There is a weird glitched overlay (see attached images) on some graphics.

Expected results:

Should have shown the default graphics (see attached images). The non-broken graphics were taken on ungoogled-chromium on the same machine in the same configuration.

Comment 1

[Yannick Markus]

Attachment: Screenshot_with_error2.png

Comment 2

[Yannick Markus]

Attachment: Screenshot_Chromium.png

Comment 3

[Yannick Markus]

Attachment: Screenshot_Chromium2.png

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 5

[Darkspirit]

Thanks for the report! Is this bug still reproducible with https://nightly.mozilla.org? Please also open about:support, click on "Copy text to clipboard" and paste it here.

Comment 6

[Yannick Markus]

Attachment: about:support outputs

Comment 7

[Yannick Markus]

So, I've just checked. It seems to have a connection to my settings. If I use a new, clean profile, it doesn't show up.
If I use safe mode, the error persists.

I'll attach my user.js, maybe that's it.

Comment 8

[Yannick Markus]

Attachment: user.js

Comment 9

[Darkspirit]

Gnome Wayland, Debian Testing, Mesa 20.1.5, Intel HD Graphics 630 (KBL GT2)
Thank you! I can reproduce the broken canvas, but not the broken favicon. These glitches vary by zoom level.

Occurs with Basic and WebRender if resistFingerprinting is enabled:
mozregression --launch 80 --pref gfx.webrender.force-disabled:true privacy.resistFingerprinting:true -a https://london.my-netdata.io

Before 78, these canvases had white backgrounds instead of glitches.
mozregression --good 77 --bad 78 -a https://london.my-netdata.io/ --pref gfx.webrender.force-disabled:true privacy.resistFingerprinting:true

11:27.12 INFO: Last good revision: 5b6a16bd94feb25ac39102798942b19650d5ec5a
11:27.12 INFO: First bad revision: ab2a75db3ebe80fbedb60769df57ee9680d927e8
11:27.12 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5b6a16bd94feb25ac39102798942b19650d5ec5a&tochange=ab2a75db3ebe80fbedb60769df57ee9680d927e8

ab2a75db3ebe80fbedb60769df57ee9680d927e8 sanketh — Bug 1621433 - In RFP mode, turn canvas image extraction into a random 'poison pill' for fingerprinters r=tjr,jrmuizel

Comment 10

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

I think this is working as intended; in the sense that the site is reading canvas data - which RFP will give a random value for - and then display it back to the user.

Comment 11

[Yannick Markus]

(In reply to Tom Ritter [:tjr] (ni? for response to sec-[advisories/bounties/ratings/cves]) from comment #10)

I think this is working as intended; in the sense that the site is reading canvas data - which RFP will give a random value for - and then display it back to the user.

Makes sense to me. Would it be possible to implement something like CanvasBlocker's fake mode, which is described as following: "Values obtained by the APIs are altered so that a consistent fingerprinting is not possible" and does not introduce any breakage?

BTW, this is my first bug report here and I'm pleasantly surprised by the quick & competent feedback, thanks!

Comment 12

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

(In reply to Yannick Markus from comment #11)

(In reply to Tom Ritter [:tjr] (ni? for response to sec-[advisories/bounties/ratings/cves]) from comment #10)

I think this is working as intended; in the sense that the site is reading canvas data - which RFP will give a random value for - and then display it back to the user.

Makes sense to me. Would it be possible to implement something like CanvasBlocker's fake mode, which is described as following: "Values obtained by the APIs are altered so that a consistent fingerprinting is not possible" and does not introduce any breakage?

This feature comes from Tor and is intended for their use, so ultimately we take our queue from what they want, although we have proposed and committed improvements. They considered that approach of slight randomness insertion but the general belief is that via repeated calls to Canvas extraction, the randomness can be averaged out and the underlying true value exposed.

This is why Tor originally implemented no-permission canvas extraction (it's possible to grant the website a permission via the icon in the address bar that gives them the true value) as returning just a white square.

You may ask; then, why is it random now? We return a fully random result (not a real result with randomness averaged in) because it is no worse then, and in some cases better than, returning a white square. An attacker who is performing an intelligent fingerprinting attack learns no data different between a white square and a fully random value - they learn only that the user has Resist Fingerprinting enabled. However an unintelligent fingerprinting script will naively include the canvas value in the fingerprint resulting in a completely random fingerprinting for a user every time. Because RFP hides most but not all fingerprintinable values (for example approximate screen size is exposed) a user will have a fingerprint shared with a subset - not all - of RFP users. Making a fingerprint random for a user every time is better than that. (We adapted this idea from Brave who implemented something similar.)

Comment 13

[Kelsey Gilbert [:jgilbert]]

I'm reopening this as valid, particularly since this isn't relied on by Tor Browser.

Comment 14

[Kelsey Gilbert [:jgilbert]]

This feels too easy to work around and too user-impacting to keep as default for RFP.

Comment 15

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

(In reply to Jeff Gilbert [:jgilbert] from comment #13)

I'm reopening this as valid, particularly since this isn't relied on by Tor Browser.

I'm not sure what you mean; using the random data is the default behavior for Tor Browser and was implemented only after conferring with them.

Comment 16

[Darkspirit]

(In reply to Jeff Gilbert [:jgilbert] from comment #14)

This feels too easy to work around and too user-impacting to keep as default for RFP.

Did you mean to disable privacy.resistFingerprinting.randomDataOnCanvasExtract by default in Firefox? (It's the pre-regression state with white background.) At the moment it just looks like a worrying graphics engine bug.

Comment 17

[Timea Cernea [:tbabos][inactive]]

Updating flags, still reproducible by force-enabling privacy.resistFingerprinting preference on latest Beta 83.0b2 and latest Nightly 84.0a1.

Comment 18

[Kelsey Gilbert [:jgilbert]]

(In reply to Darkspirit from comment #16)

(In reply to Jeff Gilbert [:jgilbert] from comment #14)

This feels too easy to work around and too user-impacting to keep as default for RFP.

Did you mean to disable privacy.resistFingerprinting.randomDataOnCanvasExtract by default in Firefox? (It's the pre-regression state with white background.) At the moment it just looks like a worrying graphics engine bug.

Right, randomDataOnCanvasExtract is causing user-facing regressions when coupled to RFP.

Comment 20

[Simonas Kazlauskas [:nagisa/:simukis]]

I've hit this on gdbgui's xterm emulator (https://www.gdbgui.com/).

If privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts is set to false, you refresh & accept the prompts asking for canvas data readback & refresh again, then canvases start looking correct again.