> reducing the resolution of timer interfaces does not mitigate any attack. > quick-fix mitigations are dangerous, as they can establish a false sense of secur

> reducing the resolution of timer interfaces does not mitigate any attack. > quick-fix mitigations are dangerous, as they can establish a false sense of security. This demonstrates - again - the danger of treating security as default-permit. This blacklist-style thinking is very common, but it is guaranteeing eventual failure because you cannot enumerating badness[1]. Limiting the granularity of performance.now assumes that providing any timing information at all is safe. It's the same basic misunderstanding of what it means to design for security I hear way too often whenever a new security issue is being discussed: someone always asks "Is this an actual problem in the wild, or whining about some hypothetical that isn't a 'real threat'?" So what; future threats are nt limited to only the attacks we know about today. As I sain in a recent comment[2], the thing that nobody really wants to talk about is that it isn't possible to know the behavior of programs a Turing complete language without running the program. Declarative documents in HTML+CSS were safe, but trying to run potentially malicious Turing complete programs safely is provably futile endeavor. [1] http://www.ranum.com/security/computer_security/editorials/dumb/ http://www.ranum.com/security/computer_security/editorials/d... [2] https://news.ycombinator.com/item?id=15708099 https://news.ycombinator.com/item?id=15708099