Add a note regarding HRT precision #57
Conversation
|
@toddreifsteck let me know if this covers the conclusion from 2/22 and I'll do the CR update after that. |
index.html
Outdated
| @@ -266,7 +266,7 @@ <h3>The <dfn>DOMHighResTimeStamp</dfn> Type</h3> | |||
| typedef double DOMHighResTimeStamp; | |||
| </pre> | |||
| <p>A <a>DOMHighResTimeStamp</a> SHOULD represent a time in milliseconds | |||
| accurate to 5 microseconds - see <a href="#sec-privacy-security"></a>.</p> | |||
| accurate to some microseconds - see <a href="#clock-resolution"></a> for additional considerations.</p> | |||
There was a problem hiding this comment.
'accurate enough to allow measurement and inaccurate enough to prevent attack'
index.html
Outdated
| @@ -350,8 +350,11 @@ <h3>Clock resolution</h3> | |||
| this new API an attacker may be able to obtain high-resolution estimates | |||
| through repeat execution and statistical analysis. To ensure that the new | |||
| API does not significantly improve the accuracy or speed of such attacks, | |||
| the recommended minimum resolution of the <a>Performance</a> interface | |||
| the recommended minimum resolution of the <a>DOMHighResTimeStamp</a> type | |||
| should be set to 5 microseconds.</p> | |||
There was a problem hiding this comment.
Please change from 'should be set to 5 microseconds' to 'should be inaccurate enough to prevent attack'.
|
@igrigorik Please double-check |
index.html
Outdated
| the recommended minimum resolution of the <a>DOMHighResTimeStamp</a> type | ||
| should be inaccurate enough to prevent attacks.</p> | ||
| <div class="issue" data-number="56"> | ||
| The recommended minimum resolution of the <a>DOMHighResTimeStamp</a> used to be 5 microseconds. It is however an ongoing issue and has significantly increased recently. |
There was a problem hiding this comment.
Wordsmithing the last sentence a bit...
"Due to recent developments this may need to increase significantly, but the working group has not yet reached consensus on what the new recommend minimum value should be." ?
|
FWIW, Edge is pushing updates to clamp on 100us + 100us jitter for all explicit clocks. We still aren't certain if this is the right number, but at least it leaves Chrome and Edge in alignment. |
|
100us+100us is superior to both the Firefox/Safari approach (2ms and 1ms respectively) from the gametime point of view explained in: #56 (comment) That said, it isn't perfect -- ideally this should be solved within a year with some kind of a permissions API (or confirmed hardware-level Spectre/Meltdown fixes in chips) -- it should not be a permanent humandkind thing to standardize 100us/100us -- but it is an acceptable interim solution unlike 1ms+. |
Temporary warning while #56 is being sorted out.
Preview | Diff