Firefox: Thumbnails generated with canvas are random data when privacy.resistFingerPrinting and canvas access is enabled

[karolyi]

Steps to reproduce

Hey,

Not sure this is a Firefox bug, or a bug in the way Element deals with locally generated thumbnails. Here's how to reproduce:

• Enable privacy.resistFingerprinting, and disable privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts in firefox (so the canvas access request could be shown)
• Post an image/video with big enough resolution so that element will want to create a thumbnail for it
• Instead of the thumbnail, garbage (mostly stripes) appears

My former related comment on a closed issue: #9605 (comment)

Outcome

What did you expect?

A thumbnail should have been generated properly.

What happened instead?

Random data shown as thumbs on all ends:

Operating system

Firefox with Linux, but I think it's OS independent

Browser information

Mozilla/5.0 (X11; Linux x86_64; rv:107.0) Gecko/20100101 Firefox/107.0

URL for webapp

app.element.io

Application version

it's the latest element

Homeserver

doesn't matter, it's a client side issue

Will you send logs?

Yes

[karolyi]

It seems that other canvas using sites handle canvas access properly, like this site: https://browserleaks.com/canvas

I think this must be an element bug.

[turt2live]

Related/regression from prior work:

• [Accessibility?/UX] Default-generated user icons smehow feel unpleasant to look at #14433
• Avatars are not displayed correctly when resistFingerprinting option is enabled in Firefox #14419
• extract canvas data - firefox permissions #9605

[fxbrit]

hello! I reproduced the same issue on my end.

FYI the uploaded images are not actually broken once opened, it's just the thumbnails; since user avatars are also rendered correctly I can confidently say canvas permission in Firefox is working fine.

[t3chguy]

since user avatars are also rendered correctly I can confidently say canvas permission in Firefox is working fine.

User avatars aren't rendered using canvases though? They're just straight up <img /> tags of the avatars. Canvases are used to generate thumbnails and other such mediums, not to render them. So if the canvas implementation is disabled or made to return invalid data then it is unavoidable.

[fxbrit]

I didn't express myself well at all here, sorry. everything I said above applies to the case in which canvas permission has been allowed to Element using Firefox's UI.

I mentioned user avatars because before one allows canvas access their background looks striped, but after you allow it and reload the page it's a solid color.

They're just straight up <img /> tags of the avatars.

is this also true for the auto-generated ones that are simply a letter + a solid color (eg. in this issue we have a blue background and a white letter K)?

[t3chguy]

The auto-generated ones do indeed use canvas to generate the data uri for the <img /> tag

[andybalaam]

Element's favicon also appears corrupted when privacy.resistFingerPrinting is true:

[t3chguy]

Default avatars in notifications will also be corrupted

[karolyi]

Okay, I had two days to investigate this issue further.

It seems that RFP mode in Firefox doesn't trigger the "do you want to allow canvas access" for OffscreenCanvas instances — no matter what the privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts config value is.

Whenever I use the document.createElement('canvas'), FF/Librewolf notifies me of the current page wanting to access canvas data (provided privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts is set to false), which then I can allow, and on the second paste, canvas.drawImage() draws the loaded image on the canvas properly, that can be extracted as a proper thumbnail.

As long as this is not fixed in Firefox (upstream from Librewolf), the off-screen-canvas thumbnail generation method won't work. Even worse, there is not an easy way of detecting if RFP is on, but juraj.maslar on the mozilla forums figured out a hacky way to do it:

https://discourse.mozilla.org/t/how-to-detect-privacy-resistfingerprinting/111798/3

Using this method, it would be possible to fall back to the 'old' canvas creation method that works with RFP, until Firefox unfucks this.

I'll attach a quick playground to test this, cobbled together from the (to me very messy) element code, and report the bug to Mozilla, if there isn't any reported yet.

test.tar.gz

Anyone want me to prepare a PR with a fix for this with the workaround linked above?

[karolyi]

Update, it seems there is a bug filed on this behavior already:
https://bugzilla.mozilla.org/show_bug.cgi?id=1422862