"ZombieLoad": a new set of speculative-execution attacks

It really is more than a little unfair to use this revelation as another reason to go on an(other) anti-Javascript rant. Sure, Javascript is at this time a leading vector for how most people might be exposed to security threats, but Javascript also enables much or most of the useful stuff we take advantage of and benefit from on the internet.

I well understand that "real" programmers and software engineers are contemptuous of Javascript and those who use it to build software and websites, but I think there's more than a little bit of envy in there as well. Yes, Javascript has a chaotic, undisciplined ecosystem of add-in functionality, but that ecosystem is also both enormously useful and just plain enormous. Futhermore, Javascript has been a vehicle and driver for widespread popularization of some decent ideas about what a high level language should offer (even if Javascript didn't necessarily invent those ideas). Again, I sometimes detect a hint of envy from "real" programmers in this regard.

Finally, I find it particularly unreasonable that this particular security threat, which has been brought to us by arguably some of the most highly skilled "real" computing engineers on the planet, should be your excuse for going on a rant about Javascript.

Blame the Arpanet, where passwords (FTP and Telnet) flew around unencrypted (and everyone on the Arpanet knew how to exploit that) and if the hacker wasn't patient enough for packet snooping, Finger provided a convenient backdoor to every system. Pre-Java and JavaScript, there was none of this executing random code over the Internet; you just downloaded the random code over the Internet (or, for many people, from the BBS).

Maybe the Internet could be better, but if billions of people are on the Internet, billions of people are going to be executing random code, either directly or by downloading it. Directly would be worse; maybe a world where the only way to run code on your computer for most people was download it from the **** Store might be safer, but not more free.

There isn't a clear distinction between "executing random code" and "processing random data". Processing data downloaded from unknown untrusted sources is kind of the fundamental purpose of the internet, as a system of end-to-end communication with no central authority, and I assume you're not trying to argue against the existence of the whole internet. Data formats usually get more sophisticated over time, as people add useful features, and sufficiently sophisticated data is indistinguishable from code. (PDF documents (and, even worse, PostScript) are obviously code masquerading as data files, but e.g. OpenType fonts and SVG filters and PowerPoint animations are also Turing-complete languages.)

So you're always going to end up dealing with the security implications of essentially executing untrusted code, and it seems better to be honest about it and do it in a real programming language (like JS) rather than pretending it's just data and must be inherently safe.

In the context of Spectre, there's also the NetSpectre attack, which explains how you can attack a remote target by sending not-even-vaguely-code-like data to the target system. You just send some requests that trigger a speculative array read based on secret data, which leaks into the cache state, then measure the cache state via the latency of network responses. The only way to truly solve that problem (without disabling speculation) is to disconnect from the internet entirely. Limiting the expressivity of data won't help.