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

karolyi commented 1 year ago

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: https://github.com/vector-im/element-web/issues/9605#issuecomment-1277393364

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 commented 1 year ago

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 commented 1 year ago

Related/regression from prior work:

fxbrit commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

andybalaam commented 1 year ago

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

t3chguy commented 1 year ago

Default avatars in notifications will also be corrupted

karolyi commented 11 months ago

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 commented 11 months ago

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

element-hq / element-web