4 ms·

Restricting performance.now()'s resolution to 1ms is really bad news :( Once the other mitigations are in place, will the webkit team consider increasing the re

Restricting performance.now()'s resolution to 1ms is really bad news :( Once the other mitigations are in place, will the webkit team consider increasing the resolution again? Can we get a Developer menu or Web Inspector option to temporarily enable the old resolution again?

skygazer 9y ago
In the same article, they describe their intent to, yes, restore timing resolution, once alternative mitigations mature.
bsimpson 9y ago
It's surprising to me that there are such various levels of coarseness each browser vendor chose: Gecko [0]: accurate to 20us Edge [1]: accurate to 20us, with an additional 20us of noise Chrome [2]: accurate to 100us (thanks mkeblx for finding this) Safari [OP]: accurate to 1000us [0] https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan... [1] https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/ https://blogs.windows.com/msedgedev/2018/01/03/speculative-e... [2] https://chromium-review.googlesource.com/c/chromium/src/+/853505 https://chromium-review.googlesource.com/c/chromium/src/+/85...
- mkeblx 9y ago
  Chrome is 100us: https://chromium-review.googlesource.com/c/chromium/src/+/853505 https://chromium-review.googlesource.com/c/chromium/src/+/85...
flohofwoe 9y ago
1ms is absolutely overkill IMHO and will require rewriting a lot of code which measures frametime this way. This is not an issue for the precision reductions in the other browsers (Chrome's 100us is just about what's still tolerable, Firefox's 20us is fine). It's probably better to round the measured frametime to the next 'vsync frametime' like 16.667ms or 33.333ms anyway, but I expect a lot of WebGL demos and games to break :/
- om2 9y ago
  We are looking at ways to make it more precise but with random jitter. 1ms is a stopgap.
  - joosters 9y ago
    Can't the timing (in)accuracies be worked around by javascript? There must be countless numbers of timer-triggered events in JS, not just the high-res timers but simple second-by-second counters, frame sync events, or even external I/O. Every possible time-based event needs to be made imprecise, otherwise programmers can derive a higher precision timer from them. e.g. if you have a tight loop that just increments a counter, couldn't you just run that for a second (interrupted by a lower frequency timer source), then find out how many counts/second the JIT can perform, presumably millions or billions. To time operation 'X', you then just perform X and run the tight loop again, and compare how many fewer tight loops you completed.
- iainmerrick 9y ago
  What's an example scenario where you need an ultra-high-resolution timer? For WebGL, don't you just rely on requestAnimationFrame to call you at the right times, and draw your frame as quickly as possible? What's the benefit of being able to measure the frame time to the nearest microsecond, rather than the nearest millisecond?
  - andrewmcwatters 9y ago
    Timing behavior in literally any game.
    - iainmerrick 9y ago
      Does the timer need to be much higher resolution than the frame rate? If so, why? Maybe you want to measure the frame rate precisely? That is certainly something you can do, but not usually something you need to do.

skygazer 9y ago

In the same article, they describe their intent to, yes, restore timing resolution, once alternative mitigations mature.

bsimpson 9y ago

It's surprising to me that there are such various levels of coarseness each browser vendor chose: Gecko [0]: accurate to 20us Edge [1]: accurate to 20us, with an additional 20us of noise Chrome [2]: accurate to 100us (thanks mkeblx for finding this) Safari [OP]: accurate to 1000us [0] https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan... [1] https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/ https://blogs.windows.com/msedgedev/2018/01/03/speculative-e... [2] https://chromium-review.googlesource.com/c/chromium/src/+/853505 https://chromium-review.googlesource.com/c/chromium/src/+/85...

mkeblx 9y ago
Chrome is 100us: https://chromium-review.googlesource.com/c/chromium/src/+/853505 https://chromium-review.googlesource.com/c/chromium/src/+/85...

flohofwoe 9y ago

1ms is absolutely overkill IMHO and will require rewriting a lot of code which measures frametime this way. This is not an issue for the precision reductions in the other browsers (Chrome's 100us is just about what's still tolerable, Firefox's 20us is fine). It's probably better to round the measured frametime to the next 'vsync frametime' like 16.667ms or 33.333ms anyway, but I expect a lot of WebGL demos and games to break :/

om2 9y ago
We are looking at ways to make it more precise but with random jitter. 1ms is a stopgap.
- joosters 9y ago
  Can't the timing (in)accuracies be worked around by javascript? There must be countless numbers of timer-triggered events in JS, not just the high-res timers but simple second-by-second counters, frame sync events, or even external I/O. Every possible time-based event needs to be made imprecise, otherwise programmers can derive a higher precision timer from them. e.g. if you have a tight loop that just increments a counter, couldn't you just run that for a second (interrupted by a lower frequency timer source), then find out how many counts/second the JIT can perform, presumably millions or billions. To time operation 'X', you then just perform X and run the tight loop again, and compare how many fewer tight loops you completed.
iainmerrick 9y ago
What's an example scenario where you need an ultra-high-resolution timer? For WebGL, don't you just rely on requestAnimationFrame to call you at the right times, and draw your frame as quickly as possible? What's the benefit of being able to measure the frame time to the nearest microsecond, rather than the nearest millisecond?
- andrewmcwatters 9y ago
  Timing behavior in literally any game.
  - iainmerrick 9y ago
    Does the timer need to be much higher resolution than the frame rate? If so, why? Maybe you want to measure the frame rate precisely? That is certainly something you can do, but not usually something you need to do.