some dynamic images display poorly without access to HTML5 canvas image data
Summary
Certain dynamic images for which HTML5 canvas image data are requested do not render correctly without explicitly agreeing to share HTML5 canvas image data. For example, maps provided by mapbox.com
seem to have this problem by default, even though there is no indication of a problem when attempting to load these images using ordinary Firefox. Loading a page that embeds a resource from mapbox.com
in Tor Browser yields an image that looks like this:
The stripey pattern in Exhibit A appears to result from the random canvas data that Tor Browser is configured to provide by default. The randomisation can be removed, although the resulting images are still broken. When the user sets privacy.resistFingerprinting.randomDataOnCanvasExtract
to false, the result is that white rectangles appear instead of stripey patterns:
Please note that such sites request HTML5 canvas image data via an icon in the URL bar. If a user opens the dialog and chooses to explicitly allow access to HTML5 canvas image data to the site, then Tor Browser will display the embedded content correctly, like this:
Note that vanilla Firefox always renders correctly (as in Exhibit C) and does not ask for HTML5 canvas image data. Suggest it is reasonable to conflude that vanilla Firefox allows (dangerous) access to HTML5 canvas image data by default.
Expected behaviour
I am not sure why canvas image data are actually necessary to render this image correctly; I would hope that there would be a way to provide something generic to the requesting site, revealing nothing while allowing such images to render correctly.
Environment
The behaviour described in this bug report was observed in both Tor Browser 11.0.14 and Tor Browser 11.0.15. The dangerous behaviour in vanilla Firefox was observed in 91.11.0esr (Debian).