Tor browser wrecks images because of local optimization

Uploading an image using the Windows Tor browser wrecks JPG uploads.

Setting composer media optimization image bytes optimization threshold to something ridiculously high circumvents the problem. This is very likely an issue with the Tor browser but so far it seems only to be happening in Discourse so I thought I’d post it here anyway, even if it’s only to share the workaround trick.

On my test the Tor browser blocked this call here:

with

Blocked https://try.discourse.org/ from extracting canvas data because no user input was detected.

which is obviously a lie, since the File Picker is user input.

That was detect by our failsafe mechanism:

Resize failed: Image corrupted during resize. Falling back to the original for encode

Which prompts Discourse to only re-encode the file, which appears to be successful, but then fails with a 422 when finishing the multi-part upload…

Tor Browser should block the canvas creation API instead of silently corrupting return values :thinking:

Anyway, looks like users can disable the silently failure of canvas operations by toggling privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts on about:config which will allow users to see this prompt:

I just tested and that fixes the upload.

4 Likes

Impressive. Thank you @falco!!!

3 Likes

In my experience, the same issue also occurs with some favicons (presumably uploaded as JPG files). Does toggling privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts also fix that issue?