Unanticipated consequences of FireFox's 2ms imprecision of performance.now (including accidental security degradation)

*Note: Invited Expert in W3C Web Platform Working Group relating to
requestAnimationFrame on high-Hz display, with one commit.*

Hello,

Firstly, Spectre and Meltdown are indeed extremely serious security
issues.
Many vendors, rightfully, doing emergency fixes including temporarily
reducing timer precision.

However, I have seriously grave concerns about Mozilla/FireFox's decision
to reduce *performance.now()* precision to 2ms in upcoming FireFox Version
60 -- there are unanticipated major side effects, including one that will
reduce security.

MAJOR SIDE EFFECT #1:

The precision degradation is so massive (even at 60Hz) -- affecting
fullscreen WebGL and WebVR majorly -- that I have heard from a friend that
a site that plans to automatically detect the 2ms imprecision and
automatically prompt the user with step-by-step instructions to fix the
imprecision for their site.  As a global FireFox setting, this is
problematic from a security perspective. A global setting changed.

I think the safer solution is:

*"In an absolute emergency: Personally if there's a duress to reduce timer
precision, then a temporary permissions API (cameras and fullscreen have
more security/privacy fears) to prompt the user for permission to stay at
5us precision.  At least during the duration of security studying, until
being reverted to maximized precision."*

MAJOR SIDE EFFECT #2:

As a past game developer (most standards writers aren't game developers),
let me tell you:

Accurate gametimes are necessary for accurate calculations of 3D object
positions, especially in full-screen WebGL games.

At sub-refresh-cycles, animations should still use sub-millisecond accuracy
to prevent jank, when calculating time-based animations (e.g. calculating
object positions based on time) -- that's what 3D graphics often do
compensating for fluctuating frame rates, they calculate object world
positions based on gametime.

That means 1000 inch per second moving balls (~60mph) can be wrongly
mispositioned by 2 inches if the gametime is off by 2 millisecond.  That
can mean goal/nogoal.  Fastballs, baseballs, hockey pucks can go much
faster than this.  Low-precision gametimes will ruin a lot of HTML5 and
WebGL game programming.

Gametimes need sub-millisecond accuracy, especially full-screen WebGL
games, because they calculate real-world 3D object positions based on
gametime.

That way everything looks correct regardless of framerate. Framerates
fluctuate all over the place, so video games using 3D graphics use gametime
to calculate the position of everything.  3D object positions are
calculated based on gametime.  Wrong gametime means everything janks like
crazy in full screen WebGL games.

Again, this is for 60 Hz.  I'm not even talking about higher refresh
rates.  1ms gametime errors create noticeable motion-fluidity flaws in 60Hz
full-screen WebGL games!

Things even janks crazily with 5ms and 8ms gametime errors on a 60Hz
display.  You're in the driver's seat of a 300mph car, in a racing game --
a 2ms gametime error becomes large even on a 60 Hz display.
 Jank/jerkiness/stutter can get huge even at sub-refresh-cycle levels even
on a 60 Hz display, even with sub-refresh-cycle errors.

Also, don't forget that there are advantages to frame rates above refresh
rates in reducing latency: https://www.blurbusters.com/
faq/benefits-of-frame-rate-above-refresh-rate/

My prediction is FireFox may get a tsunami wave of huge complaints from
game designers suddenly hit by major precision reductions in ability to
calculate gameworld positions.

MAJOR SIDE EFFECT #3:

*Depending on how timer precision is degraded, it potentially eliminates
educational motion tests in web browsers.  Many scientific tests such
as www.testufo.com/ghosting
<http://www.testufo.com/ghosting> and www.testufo.com/frameskipping
<http://www.testufo.com/frameskipping> (display overclocking) is heavily
dependant on perfect frame rate synchronization, and the site is able to
detect whenever Chrome misses a frame.   *


*Peer reviewed papers have already been written based on browser motion
tests (including www.blurbusters.com/motion-tests/pursuit-camera-paper
<http://www.blurbusters.com/motion-tests/pursuit-camera-paper> ...) thanks
to browser's ability to achieve perfect refresh rate synchronization)*

Even one of my sites, TestUFO, depending on how the site is degraded in
upcoming FireFox A/B tests (new versus old browser) -- it may be forced to
do something similar to the popup in "MAJOR SIDE EFFECT #1" -- for specific
kinds of peer-reviewed scientific motion testing.  Is there a way for me to
tell users how to whitelist only one site (TestUFO.com) for high-precision
timers, without doing it as a global setting?   (Thought exercise for W3C)

The TestUFO website already automatically displays a message telling
TestUFO users to switch web browsers instead of IE/Edge for 120Hz testing,
due to IE/Edge continued violation of Section 7.1.4.2 of HTML 5.2.  More
than 50% of TestUFO visitors are using a refresh rate other than 60 Hz.

MAJOR SIDE EFFECT #4:

It makes WebVR useless.

Its premise (without creating nausea/headaches) is heavily dependant on
accurate gametimes for accurate positions of 3D objects (see MAJOR SIDE
EFFECT #2 above).

MAJOR SIDE EFFECTS #5-100

I have a much longer list, but for brevity, I am shortening this email to
point out the graveness of FireFox's decision.

CONCLUSION

The approach by the FireFox team should be refined.

If continued short-term emergency mitigation is absolute critical, it
should includes a Permissions API (much like Full Screen mode and WebRTC
camera permissions) to case-by-case ask the user for permission to use
high-precision timers (allowing 5us or 1us precision).

If absolutely necessary, this could even be limited to Organization
Validation HTTPS sites, combined with only exclusive same-origin use, even
triggered by a click, and only after confirming via a popup Permission API
(like for WebRTC), that 5us/1us precision becomes granted to that
particular site.

Long-term, these restrictions should be removed once the underlying causes
of Spectre/Meltdown becomes solved.  However, massive precision reductions,
that forces web developers to give instructions to visitors how to
configure their web browsers, is a less secure solution.

Thanks,
Mark Rejhon
Founder, Blur Busters / TestUFO
(Past Invited Expert, W3C Web Platform Working Group for HTML 5.2)