diff --git a/index.html b/index.html
index 517cae4..054f37a 100644
--- a/index.html
+++ b/index.html
@@ -266,7 +266,8 @@ <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 enough to allow measurement while preventing timing attack
+     - see <a href="#clock-resolution"></a> for additional considerations.</p>
     <p class='note'>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 <a>DOMHighResTimeStamp</a> as a time in
@@ -350,8 +351,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
-      should be set to 5 microseconds.</p>
+      the recommended minimum resolution of the <a>DOMHighResTimeStamp</a> type
+      should be inaccurate enough to prevent attacks.</p>
+      <div class="issue" data-number="56">
+        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.
+      </div>
       <p>Mitigating such timing side-channel attacks entirely is practically
       not possible: either all operations would have to execute in a time that
       does not vary based on the value of any confidential information, or, the