Security and privacy considerations for DOMHighResTimeStamp resolution · Issue #79 · w3c/hr-time (original) (raw)

Note: the intent of this issue is to provide a reference and track the ongoing research, discussions, proposals, and implementation techniques employed by various browsers on how they expose or provide access to high resolution time.

Paraphrasing Section 7.1: Clock resolution...

Access to accurate timing information, both for measurement and scheduling purposes, is a common requirement for many applications... This specification defines an API that provides sub-millisecond time resolution, which is more accurate than the previously available millisecond resolution exposed by DOMTimeStamp.

... Access to the same accurate timing information can sometimes be also used for malicious purposes by an attacker to guess and infer data that they can't see or access otherwise.

To ensure that the new API does not significantly improve the accuracy or speed of such attacks, the recommended minimum resolution of the DOMHighResTimeStamp type should be inaccurate enough to prevent attacks... In order to mitigate such attacks user agents may deploy any technique they deem necessary. These techniques may include: Resolution reduction, added jitter, abuse detection and/or API call throttling.

This problem space space remains an unsolved and an evolving one. There is no existing industry consensus or a definitive set of recommendations that applies to all browsers, which is reflected in the range of different implementations and platform-specific techniques used by various browsers.

Relevant prior art and discussions:

  1. Reducing resolution (SPECTRE and microarchitecture timing attacks): Reducing the precision of the DOMHighResTimeStamp resolution #56
  2. PING review feedback: Privacy (PING) review #20