You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apparently some fingerprint detection methods use the canvas and how it draws things. I didn't dig too deep into the methods there.
In the interest of privacy and security Firefox does something in the canvas drawing functions to obfuscate/mangle output to prevent these fingerprinters from working. As a side-effect this causes extra random single pixel spots to show up in labels, see below. (The cause being Firefox's privacy settings was identified on the forums)
Check out the sandcastle that produced that image here. Note that it renders normally in chromium based browsers and Firefox with the "Suspected fingerprinters" protection off.
The Firefox setting that matters is in about:preferences#privacy under “Privacy & Security” > “Enhanced Tracking Protection” > “Suspected fingerprinters” (Note I had to switch to "Custom" to force this on.
I do not know if this only impacts Firefox on Linux or Firefox on all systems with this setting enabled.
Random data is introduced to background images when the image is read back by the website. If a website merely renders data to the background, it will render without alteration. Although typically this does not happen, if the website reads the image data in the background (and potentially displays it to you again), it will have subtle noise that may affect how the image is displayed.
This sounds exactly like the cause. I believe we render labels to a canvas then copy that as an image to render into the web gl context which would probably trigger this issue. We may need to look into different methods to achieve this if we deem it a big enough problem to tackle fixing.
I'm mostly just opening this issue to keep a record of this issue and provide a single point to link back to if we see this on the forums or reported in other issues.
The text was updated successfully, but these errors were encountered:
The level of obscurity here is ... nearly fascinating. There is a lot of context, but from the description and images, I'd go out on a limb and make a wild guess that the screenshots by @anne-gropler are related to the custom measureText, which is checking for some exact pixel values to determine the label size.
(Note: I once started a PR which replaces this, at #11747 - replacing the actual function was relatively easy, but there are always caveats and corner cases. Maybe that PR can be revived, even though this will not avoid the "noise" to begin with, but only the odd label sizes)
Apparently some fingerprint detection methods use the canvas and how it draws things. I didn't dig too deep into the methods there.
In the interest of privacy and security Firefox does something in the canvas drawing functions to obfuscate/mangle output to prevent these fingerprinters from working. As a side-effect this causes extra random single pixel spots to show up in labels, see below. (The cause being Firefox's privacy settings was identified on the forums)
Check out the sandcastle that produced that image here. Note that it renders normally in chromium based browsers and Firefox with the "Suspected fingerprinters" protection off.
The Firefox setting that matters is in about:preferences#privacy under “Privacy & Security” > “Enhanced Tracking Protection” > “Suspected fingerprinters” (Note I had to switch to "Custom" to force this on.
I do not know if this only impacts Firefox on Linux or Firefox on all systems with this setting enabled.
According to the page on Firefox's protection against fingerprinting under the suspected fingerprinters it says:
This sounds exactly like the cause. I believe we render labels to a canvas then copy that as an image to render into the web gl context which would probably trigger this issue. We may need to look into different methods to achieve this if we deem it a big enough problem to tackle fixing.
I'm mostly just opening this issue to keep a record of this issue and provide a single point to link back to if we see this on the forums or reported in other issues.
The text was updated successfully, but these errors were encountered: