43
43
'Angelos D. Keromytis'
44
44
] ,
45
45
date : 'March 2015'
46
+ } ,
47
+ 'SPECTRE' : {
48
+ title : '' ,
49
+ href : 'https://spectreattack.com/spectre.pdf' ,
50
+ authors : [
51
+ 'Paul Kocher' ,
52
+ 'Jann Horn' ,
53
+ 'Anders Fogh' ,
54
+ 'Daniel Genkin' ,
55
+ 'Daniel Gruss' ,
56
+ 'Werner Haas' ,
57
+ 'Mike Hamburg' ,
58
+ 'Moritz Lipp' ,
59
+ 'Stefan Mangard' ,
60
+ 'Thomas Prescher' ,
61
+ 'Michael Schwarz' ,
62
+ 'Yuval Yarom'
63
+ ] ,
64
+ date : 'January 2018' ,
46
65
}
47
- } ,
66
+ }
67
+ ,
48
68
testSuiteURI : "https://wpt.fyi/hr-time/" ,
49
69
wgPatentURI : "https://www.w3.org/2004/01/pp-impl/45211/status"
50
70
} ;
@@ -335,12 +355,13 @@ <h3>Clock resolution</h3>
335
355
on.</ p >
336
356
< p > However, access to the same accurate timing information can sometimes
337
357
be also used for malicious purposes by an attacker to guess and infer
338
- data that they can't see or access otherwise. For example, cache attacks
339
- and statistical fingerprinting is a privacy and security concern where a
340
- malicious web site may use high resolution timing data of various browser
341
- or application-initiated operations to differentiate between subset of
342
- users, and in some cases identify a particular user - see
343
- [[?CACHE-ATTACKS]].</ p >
358
+ data that they can't see or access otherwise. For example, cache attacks,
359
+ statistical fingerprinting and microarchitectural attacks are a privacy
360
+ and security concern where a malicious web site may use high resolution
361
+ timing data of various browser or application-initiated operations to
362
+ differentiate between subset of users, identify a particular user or
363
+ reveal unrelated but same-process user data - see [[?CACHE-ATTACKS]] and
364
+ [[SPECTRE]] for more background.</ p >
344
365
< p data-tests ='timing-attack.html '> This specification defines an API that
345
366
provides sub-millisecond time resolution, which is more accurate than the
346
367
previously available millisecond resolution exposed by
@@ -350,11 +371,19 @@ <h3>Clock resolution</h3>
350
371
improve the accuracy or speed of such attacks, the recommended minimum
351
372
resolution of the < a > DOMHighResTimeStamp</ a > type should be inaccurate
352
373
enough to prevent attacks.</ p >
353
- < div class ="issue " data-number ="56 ">
354
- Due to recent developments this may need to increase significantly, but
355
- the working group has not yet reached consensus on what the new
356
- recommend minimum value should be.
357
- </ div >
374
+ < p > In order to mitigate such attacks user agents may deploy any technique
375
+ they deem necessary. Deployment of those techniques may vary based on the
376
+ browser's architecture, the user's device, the content and its ability to
377
+ maliciousely read cross-origin data, or other practical considerations.
378
+ </ p >
379
+ < p >
380
+ These techniques may include:
381
+ < ul >
382
+ < li > Resolution reduction.</ li >
383
+ < li > Added jitter.</ li >
384
+ < li > Abuse detection and/or API call throttling.</ li >
385
+ </ ul >
386
+ </ p >
358
387
< p > Mitigating such timing side-channel attacks entirely is practically
359
388
not possible: either all operations would have to execute in a time that
360
389
does not vary based on the value of any confidential information, or, the
@@ -363,6 +392,13 @@ <h3>Clock resolution</h3>
363
392
associated complexity for the browser and application developers and the
364
393
associated negative effects on performance and responsiveness of
365
394
applications.</ p >
395
+ < div class ="note ">
396
+ As a result of [[SPECTRE]], browsers have significantly increased the
397
+ level of mitigations they employ on both explicit and implicit high
398
+ resolution timers. See < a
399
+ href ="https://github.com/w3c/hr-time/issues/56 "> Issue 56</ a > for more
400
+ details.
401
+ </ div >
366
402
</ section >
367
403
< section >
368
404
< h3 > Clock drift</ h3 >
0 commit comments