Spectre Attack / by Robert Walker

First - Read about it here: https://spectreattack.com/

Given the seriousness of the attacks capabilities (leaking data from processor cache based on what the process speculated was going to happen), I expect to see lots of attention thrown at this problem.

In the short-term, there appears to be little we can do software side to prevent the exploit, but I did notice that all of the researches required very precise timings to prevent cache time-out and/or overwrites.  They use a variety of pauses (empty loops) and timing checks to make sure they are accessing what they want.  

One of the more serious proof-of-concepts shown uses a JavaScript to execute inside of a Chrome instance.  The researchers even note here that they used HTML5 timings to work around the built-in measures of Chrome which deliberately round performance.now() and event.timeStamp so as to prevent micro-second level performance attacks such as this one.  

Therefore I expect, at least on software side, that many libraries may implement their own versions of time rounding to prevent other programs from knowing the exact execution times.  Keep this in mind if your program requires timing precision!

Bonus:  A JSFiddle to show how timing can be different in Chrome and Edge.  First, load in Edge and see the timing - it should be precise to many decimal places (floating point +/- 5 ┬ÁS).  In Chrome it is rounded to three decimal places (generally, millisecond accuracy).  Attackers can use these simple functions to time their attacks in Edge, but its more difficult in Chrome.