Added a list of potential mitigations to timing attacks

index.html

@@ -43,8 +43,28 @@
           'Angelos D. Keromytis'
         ],
         date: 'March 2015'
+      },
+      'SPECTRE': {
+      title: '',
+      href: 'https://spectreattack.com/spectre.pdf',
+      authors: [
+        'Paul Kocher',
+        'Jann Horn',
+        'Anders Fogh',
+        'Daniel Genkin',
+        'Daniel Gruss',
+        'Werner Haas',
+        'Mike Hamburg',
+        'Moritz Lipp',
+        'Stefan Mangard',
+        'Thomas Prescher',
+        'Michael Schwarz',
+        'Yuval Yarom'
+        ],
+        date: 'January 2018',
       }
-    },
+    }
+    ,
     testSuiteURI: "https://wpt.fyi/hr-time/",
     wgPatentURI: "https://www.w3.org/2004/01/pp-impl/45211/status"
   };
@@ -335,12 +355,13 @@ <h3>Clock resolution</h3>
       on.</p>
       <p>However, 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. For example, cache attacks
-      and statistical fingerprinting is a privacy and security concern where a
-      malicious web site may use high resolution timing data of various browser
-      or application-initiated operations to differentiate between subset of
-      users, and in some cases identify a particular user - see
-      [[?CACHE-ATTACKS]].</p>
+      data that they can't see or access otherwise. For example, cache attacks,
+      statistical fingerprinting and microarchitectural attacks are a privacy
+      and security concern where a malicious web site may use high resolution
+      timing data of various browser or application-initiated operations to
+      differentiate between subset of users, identify a particular user or
+      reveal unrelated but same-process user data - see [[?CACHE-ATTACKS]] and
+      [[SPECTRE]] for more background.</p>
       <p data-tests='timing-attack.html'>This specification defines an API that
       provides sub-millisecond time resolution, which is more accurate than the
       previously available millisecond resolution exposed by
@@ -350,11 +371,19 @@ <h3>Clock resolution</h3>
       improve the accuracy or speed of such attacks, 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>In order to mitigate such attacks user agents may deploy any technique
+      they deem necessary. Deployment of those techniques may vary based on the
+      browser's architecture, the user's device, the content and its ability to
+      maliciousely read cross-origin data, or other practical considerations.
+      </p>
+      <p>
+      These techniques may include:
+      <ul>
+        <li>Resolution reduction.</li>
+        <li>Added jitter.</li>
+        <li>Abuse detection and/or API call throttling.</li>
+      </ul>
+      </p>
       <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
@@ -363,6 +392,13 @@ <h3>Clock resolution</h3>
       associated complexity for the browser and application developers and the
       associated negative effects on performance and responsiveness of
       applications.</p>
+      <div class="note">
+        As a result of [[SPECTRE]], browsers have significantly increased the
+        level of mitigations they employ on both explicit and implicit high
+        resolution timers. See <a
+        href="https://github.com/w3c/hr-time/issues/56">Issue 56</a> for more
+        details.
+      </div>
     </section>
     <section>
       <h3>Clock drift</h3>