Re: Security review of High Resolution Time 2

On 12/12/2018 2:46 PM, Tom Ritter wrote:
> On Wed, 12 Dec 2018 at 16:05, Philippe Le Hégaret <plh@w3.org> wrote:
>> The security section was substantially revised to mitigate threats, to
>> revise the clock resolution and drift (see also
>> https://github.com/w3c/hr-time/issues/56).
> 
> To compare the old version to the new; which documents should we
> compare?  https://www.w3.org/TR/hr-time/#sec-privacy-security and
> https://w3c.github.io/hr-time/#sec-privacy-security seem to be the
> same...

We do maintain the snapshot in /TR so either one would work. For 
simplicity, I pointed to https://w3c.github.io/hr-time/ in my request.

> Obviously the big elephant in the room is "What level of precision
> should the spec specify" and it seems to have largely punted on this.
> There seems to be one lingering reference to "5 microseconds".
 >
> Otherwise AFAICT it says 'sub-millisecond' and does not acknowledge
> that fact that most browsers are holding it at 1 millisecond.

The full non-normative note reads:
[[
If the User Agent is unable to provide a time value accurate to 5 
microseconds due to hardware or software constraints, the User Agent can 
represent a DOMHighResTimeStamp as a time in milliseconds accurate to a 
millisecond.
]]

The accuracy has varied over the recent years indeed and each agent is 
using its own, either out of security concerns or due to hardware 
limitations. We always accommodated for that. As you can imagine, the 
hardware security issues discovered late last year impacted our 
precision significantly. If you look at issue 56, you'll see a 
discussion about those variations:
  https://github.com/w3c/hr-time/issues/56

So yes, one can say that the spec is on purpose not providing a level of 
precision, besides "accurate enough to allow measurement while 
preventing timing attack". We fully expect the precision level of 
implementation to keep fluctuating unfortunately for the benefit of 
security.

> (Something I have encountered which is not really an issue with this
> spec, but with others, is that other performance objects do _not_ have
> the same cautionary notes about accuracy, and expose timers that are
> even more precise than 5-microseconds.)

I can't speak for all specifications but our specification defines the 
DOMHighResTimeStamp type which is used by other specifications to allow 
for higher precision. Consequently, Those specifications would fall 
under the same precision limitations.

Philippe

Received on Wednesday, 12 December 2018 20:20:05 UTC