1589060 - privacy.resistFingerprinting limits canvas webgl framerate to 10 fps

Status: RESOLVED DUPLICATE of bug 1692609

(Core :: DOM: Security, defect, P3)

Description

[Kirill]

Attachment: Unity WebGL Player - AngryBots WebGL Demo - Firefox Nightly 2019-10-16 14-43-03.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36

Steps to reproduce:

If you turn on privacy.resistFingerprinting key in about:config, any canvas unity3d webgl content fps become capped on 10fps. This problem happens for me only for unity3d wasm content, so maybe it's unity-specific bug.

Example:

• Angry bots official unity demo
  https://files.unity3d.com/jonas/AngryBots/
• Simple 3d scene
  http://www.mckenna3d.com/wp-content/uploads/2018/05/WEBGL/index.html

NOT unity webgl content works without frame drop:

• https://demos.littleworkshop.fr/infinitown
• http://madebyevan.com/webgl-water/

Reproduces in firefox nightly 71.0a1

Actual results:

Any canvas webgl content fps become capped on 10fps.

Expected results:

Blocking fingerprinting, should not break browser usability.

The main problem is that a lot of people who cares about privacy set this flag with help of tutorials (how to protect self from fingerprinting and spying). Then it is synchronized via Firefox account on all their devices. After this, they can't play any unity webgl games, because of extremely low fps.

If you want to block fingerprinting, by locking fps in canvas, please make default fps lock on at least on 30fps, to make canvas unity webgl content playable.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Kirill]

I've made small demo to reproduce the bug.
Unity Webgl build here: https://kolombet.github.io/firefox-demo/

Comment 3

[Kirill]

I've found people with similar problems:
https://github.com/processing/p5.js/issues/2656

Comment 4

[Timothy Nikkel (:tnikkel)]

Are we actually only drawing at 10 fps or are we just reporting that? Comparing the 60fps animation side by side with the one reporting that it is 10 fps with resistFingerprinting on they both look just as smooth.

Comment 5

[Kirill]

Drawing is affected too, you can check it out on the angry bots demo: https://files.unity3d.com/jonas/AngryBots/
I am not sure, why it's not visible in cube demo, I'll try to change it to make low fps more obvious.
You can check it out in any big browser webgl unity games, for example, https://plarium.com/en/strategy-games/throne-kingdom-at-war/game/

Comment 6

[Kirill]

I've made one more cube demo, with the visible reproducible bug:
https://kolombet.github.io/firefox-demo-2/

Comment 7

[Tom Ritter [:tjr]]

Thanks for these reproductions! I was able to quickly confirm that this is a result of us reporting coarse granularity in our timestamps. You can confirm by disabling RFP and setting privacy.resistFingerprinting.reduceTimerPrecision.microseconds to 100000 (which is RFP's value).

Based on the age of the github issue, I don't think it's related to our (recent) requestAnimationFrame timestamp clamping. It would be interesting to figure out what API in particular that's causing the issue and how it's being used. (It's probably performance.now() and I'm curious why it's causing the issue and if Unity could refactor to avoid this...)

Comment 8

[Timothy Nikkel (:tnikkel)]

Can you move this bug to the proper component? Since it's about timers it isn't a webgl issue.

Comment 9

[Tom Ritter [:tjr]]

Looked into this a bit more after a conversation on Matrix. I dug into a blob demo https://webglsamples.org/blob/blob.html and observed that

• The location of the blobs is determined based on the current time; which is obviously coarse-grained. So the blobs jump around and don't move smoothly.
• The framerate is very jittery but the calculation of it seems based on the elapsed time from the last frame which is coarse; so it makes sense that it jitters, because sometimes that will be 0 and other times 100ms...

I think if you animated a box moving forward a small step once per requestAnimationFrame and ignored trying to calculate where it 'should' be based on the time, it would move smoothly.

Disabling timer precision reduction for requestAnimationFrame might address this in some instances - calculations based on timestamps from that API might work as expected - as long as they don't use other timestamps. The blob demo does use a separate timestamp rather than the rAF parameter.

Comment 10

[Thorin [:thorin]]

Disabling timer precision reduction for requestAnimationFrame might address this in some instances

for those following along at home ... Bug 1692609 landed

Comment 11

[Tom Ritter [:tjr]]

And fixed it!