1670447 - deprecate randomDataOnCanvasExtract

Status: UNCONFIRMED

(Core :: DOM: Security, task, P3)

Description

[Thorin [:thorin]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

In bug 1621433 (FF78+) RFP switched to a random canvas

• privacy.resistFingerprinting.randomDataOnCanvasExtract

Now that it's working as intended, we can hardcode random by default, deprecate the pref, and remove the white canvas code

enforce RFP users to conform and not compromising their FP : see here

Comment 1

[sanketh]

This might be a Tom question. :)

Comment 2

[Tom Ritter [:tjr]]

I don't know... I'd be inclined to keep this pref around for now. This is still kind of a weird behavior.

Comment 3

[Thorin [:thorin]]

and... another one re uploaded images, reddit link with terrible advise to flip the pref for random canvas

Also

[suggestion from someone] Enable Canvas Image data when the site asks for it. The image will load normally.
[OP] The sites never ask anything, though

I'm even thinking this could be a bit of a hole for Tor Users, TBH

Comment 4

[Thorin [:thorin]]

sorry for the noise... another one .. seriously .. how is that even go to fix the images, they'll just be all white sigh

Comment 5

[Thorin [:thorin]]

wow .. even tor browser users are being advised to do this

maybe Tor Browser should lock the pref in the meantime .. pinging sysrqb

Comment 6

[Matthew Finkel [:sysrqb]]

(In reply to Simon Mainey from comment #5)

wow .. even tor browser users are being advised to do this

maybe Tor Browser should lock the pref in the meantime .. pinging sysrqb

Hrm. Thanks Simon! Do we know why they're not receiving the permission prompt? Is there a pattern we're missing in the current behavior?

Comment 7

[Thorin [:thorin]]

sysrqb

• see Bug 1631673 - whatsapp, twitter, instagram, linkedin
• see https://lists.torproject.org/pipermail/tbb-dev/2020-April/001066.html
• there's a tor ticket somewhere ... but I can't find it

Comment 8

[sanketh]

Even if the prompt is shown and the user allows access, there is a UX hurdle where the user may need to reload the page for the setting to take effect. See Bug 1633813 I wonder if this is part of the problem, where the users toggle the prompt but don't reload but after they reset the config, they reload the page and it is the reload the solves the problem?

Comment 9

[Matthew Finkel [:sysrqb]]

(In reply to sanketh from comment #8)

Even if the prompt is shown and the user allows access, there is a UX hurdle where the user may need to reload the page for the setting to take effect. See Bug 1633813 I wonder if this is part of the problem, where the users toggle the prompt but don't reload but after they reset the config, they reload the page and it is the reload the solves the problem?

(Huh. I replied with the below message via email three days ago, but I guess it was never added)

This sounds like a reasonable explanation.

I wonder if we can provide a better UX by being less precise. Instead of
prompting at the time of extraction (ex. calling getImageData), we
prompt when the first canvas element is initialized on the page. The
prompt says something like "Will you allow <website> to access
information about graphics in the future that could uniquely identify
your computer?". If the user allows it, then extraction is permitted,
otherwise the site gets randomness. When permission is denied, Firefox
could even keep a counter of the number of times the site received
randomness and show it in the ETP display (but that is more in Johann's
area)

Really, we need a standardized async API for this.

Comment 10

[sanketh]

(In reply to Matthew Finkel [:sysrqb] from comment #9)

I wonder if we can provide a better UX by being less precise. Instead of
prompting at the time of extraction (ex. calling getImageData), we
prompt when the first canvas element is initialized on the page.

I like this solution. It gives a lot of power to the user and might unbreak a lot of the cases we've been seeing, at the cost of giving the user an all-or-nothing choice. In practice, this might not be a problem as most canvas extraction issues seem to be on sites the users already trust like WhatsApp, Twitter, and Instagram.

Comment 11

[Thorin [:thorin]]

and another one: https://old.reddit.com/r/firefox/comments/neru1j/broken_images_across_firefox/

hopefully this is the right ni

• jscher, the random pref does not control canvas protection, it only controls whether it returns a white canvas (default pre FF78) or randomized per execution (default FF78+). Toggling the pref will only make users stand out when using RFP

Comment 12

[jscher2000]

(In reply to Simon Mainey from comment #11)

• jscher, the random pref does not control canvas protection, it only controls whether it returns a white canvas (default pre FF78) or randomized per execution (default FF78+). Toggling the pref will only make users stand out when using RFP

Thanks for explaining that.

Comment 13

[jscher2000]

Why did I uncheck the NI box? Sorry for the extra comment.

Comment 14

[Thorin [:thorin]]

is it time to remove the pref, related code, and footgun yet, after three years?