Enabling privacy.resistFingerprinting on Firefox's about:config breaks camera movement.

[samuel-zuk]

Description: Enabling privacy.resistFingerprinting on Firefox's about:config breaks camera movement.

• A-Frame Version: 1.2.0
• Platform / Device: Linux Mint 19 x86_64 (Ubuntu Bionic), Firefox 85.0
• Reproducible Code Snippet or URL: https://aframe-camera-movement.glitch.me/

Hello all, I had recently been trying to track down a strange bug that followed me around on my Firefox install for all A-Frame apps I had tried to run in the browser, and had narrowed it down to the privacy.resistFingerprinting setting I had set to "true" in my about:config page. Essentially, when moving the camera (i.e. changing the position, manipulating the rotation with look controls operated normally) with this setting enabled, the camera movement would either be incredibly choppy and sluggish, or the camera would jitter back and forth, occasionally warping somewhere else in the scene. This occurred while using both the default controls (wasd-controls and look-controls) or the movement-controls component in the aframe-extras package, although the ways in which the movement bugged out varied between the two (example linked above).

Not sure what can be done to prevent this (it only seems to affect the camera position from my testing), but I've included some links here that could help lead in the right direction if this is something that can be worked around:

• https://wiki.mozilla.org/Security/Fingerprinting
• https://bugzilla.mozilla.org/show_bug.cgi?id=1217290
• https://bugzilla.mozilla.org/show_bug.cgi?id=1409677
• https://bugzilla.mozilla.org/show_bug.cgi?id=1329996
• https://gitlab.torproject.org/legacy/trac/-/issues/16005

[dmarcos]

Yeah not sure. It look like Firefox is intentionally introducing noise in the input. Not sure what can be done about it on the A-Frame side @takahirox Do you know how resistFingerprinting is affecting WebXR WebGL? Thanks. No worries if you don't

[takahirox]

Sorry, no idea. I will forward the question to the Firefox devs.

[tomrittervg]

I'm the FF maintainer of resistFingerprinting (RFP). While we do make some limitations to WebGL as part of RFP, what you've described is more consistent with the timer clamping we do.

For whatever reason I cannot load your demo; but to narrow it down, try turning RFP off, but setting privacy.resistFingerprinting.reduceTimerPrecision.microseconds to 100000 (which is the value that RFP locks it to.) If it reproduces it, is the timer clamping aspect of RFP; not the WebGL modifications.

It would be very interesting indeed if you were able to find a way to resolve this and produce smooth movement without requiring a high-resolution timer. I've talked to people and it seems like it ought to be possible, but no one's really been interested in trying. You can detect Tor Browser/RFP users by calling performance.now() twice and if both are a multiple of 100ms, you know you're dealing with such a user and can display a warning or a link to a help article or something.

[dmarcos]

Thanks @takahirox @tomrittervg for the info. Much appreciated.

Not sure what can be done in the A-Frame side to produce smooth animation at 60Hz / 90Hz... without an accurate timer.

[samuel-zuk]

Just tested with RFP off and with the reduceTimerPrecision setting changed and yep, same results. Results are worse on more populated scenes also, here's an example of that on the project I work on (link to the page shown here):

[samuel-zuk]

Thanks @takahirox @tomrittervg for the info. Much appreciated.

Not sure what can be done in the A-Frame size to produce smooth animationa at 60Hz / 90Hz... without an accurate timer.

Somewhat of a naive idea, but I noticed that in the three.js docs that THREE.Clock() is capable of using Date.now() instead of performance.now(). I know Date.now() is less accurate than performance.now() under normal circumstances, but would it be better than the heavily clamped performance.now() value forced with RFP on? Link here.

Err, scratch that, Date.now() is also clamped by RFP

[tomrittervg]

Err, scratch that, Date.now() is also clamped by RFP

Wouldn't be much of a security mitigation if we left that bit open now, would it? :)

[kdashg]

I have filed a bug about the difficulties here against Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1692609

[dmarcos]

@samuel-zuk @jdashg Thanks folks for looking into it. Much appreciated

[dmarcos]

This looks that's still being addressed on the Firefox side.

[dmarcos]

Is this still an issue?