1670447 - deprecate randomDataOnCanvasExtract

Status: RESOLVED FIXED

(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?

Comment 15

[Thorin [:thorin]]

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

it's now 4 years and we're simply not going back - time to rip out this footgun and complexity. Does it even work as advertised with RFP enabled + FPP + RFPTargets + PB mode + ETP Strict. Rhetorical question. It's not worth testing. Time to rip it out!

ni: tom and fkilic

Comment 16

[Fatih Kilic [:fkilic]]

I can take a look into this. I also have D224260, which is similar to filling canvases with all-white pixel data. I'll just write up another patch building on top of D224260, just to be safe (it looks like our tests aren't 100% comprehensive. For example, service workers had the ability to get canvas data without any randomization in the past. to me, having a fallback to all-white pixel data is safer than returning non-randomized pixel data because we forgot to create randomization key somewhere)

Comment 17

[Thorin [:thorin]]

having a fallback to all-white pixel data

maybe I'm missing something .. but if you can catch a fallback then just you can add a test for it and fix the hole

Comment 18

[Fatih Kilic [:fkilic]]

Yeah we fixed service workers issue and added a test, but we didn't have any test in the past hitting that code path. Even if I add a assertion and run a try, we wouldn't have noticed anything because there was no test testing service workers. I think we patched everything, but I'm also not sure if we are missing anything. I hope we'll ever run into this fallback case, but if we do, at least we'll be safe.

Comment 19

[Thorin [:thorin]]

still seems weird to me :) Anyway, all I really want it to remove the pref (and code related to it) so it's one less parameter to deal with

Comment 20

[Fatih Kilic [:fkilic]]

Attachment: Bug 1670447: Deprecate randomDataOnCanvasExtract. r?tjr

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/23f2b7e66e23
Deprecate randomDataOnCanvasExtract. r=tjr

Comment 22

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/23f2b7e66e23