Indeed, I've been feeling indifferent about all these timing sidechannels ever since the very first ones (Spectre/Meltdown). The PoCs have not been particularly convincing to me, given that they are extremely contrived and rely on knowing the exact details of the system being exploited to such an extent that someone with those details would be better off with other ways in, and assumes those details haven't changed at all during the amount of time required to do the attack --- the nature of these side-channels is such that even the smallest change in environment can completely change the results.

In other words, if I choose a process on my system at random, and dump a few dozen bytes from it, I can technically claim to have leaked some data; but the use of that data to an attacker likely depends strongly on factors which are outside of the attacker's control. It's somewhat like finding a (real-world) key on the ground: you theoretically now have access to something you shouldn't have, but you have next to no idea what that something is.

But I feel confident that these issues are purely academic and, while interesting, serve more to provide content for PhD theses than represent urgent hazards on the web.

They also provide content for sensationalist clickbait articles and fuel the paranoia that drives society towards authoritarianism and furthers the war on general-purpose-computing, which IMHO is a much bigger issue to worry about.

> Yeah, JS is the only hairy part. I considered mentioning it, since I know it was going to come up. But luckily, all I've seen so far are basic demos (like leaky.page) that read data from a carefully-crafted array that the page itself populated.

Only PoC says very little. If I were head of a nation state APT I'd look into exploiting this because attack surface of JS is high. I'd only use it targeted, for example on Microsoft Azure team as outlined in Darknet Diaries #78.

If a nation state wants to hack into my computer, I have absolute confidence they will succeed. They are not a part of my personal threat model.

If they’re targeting me in particular, I agree.

If they’re targeting Joe and Jane Average, the long history of government tech procurement failures means I expect them to fail — fail dangerously, but fail.

To add more to the hairy part: WASM. And that's growing rapidly.

https://googleprojectzero.blogspot.com/2019/04/virtually-unl... one of the many public browser RCE. Or look for the ps5 jailbreaks, the browser is the common denominator for most systems and its leaky as hell given that JS is dynamically typed and everything gets JIT-ed to hell (https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/) most exploits I've seen are about tricking webkit into type mismatching + JIT "invalidation". WASM open this hole even wider

How would the statically typed WASM open an even wider hole? Assuming you mean that the size of wasm's hole is larger than js, not that their combined holes are larger than either one.

Wasm has more control over time and memory access than JS does. From a capabilities model, it is more secure, but from a threat model due to side channels, Wasm is a more effective tool than JS.

This thread discusses SAB (shared array buffer) and Wasm side channels https://github.com/tc39/security/issues/3

But to compensate those tricky features are sandboxed much more rigorously than JS is, e.g. https://developer.chrome.com/blog/enabling-shared-array-buff... - no SAB without site isolation.

Be afraid. Be very afraid, the hackers are reading this too, as well as the malevolent nation-states hell bent on hacking. I cannot show you a proof of concept right now, but I am betting that within a year, maybe even as quickly as six months. you will see this in the wild.