> I still have reservations that Specter can be actually exploited It's not easy, and many systems are more easily broken into by other means (e.g., unpatched

> I still have reservations that Specter can be actually exploited It's not easy, and many systems are more easily broken into by other means (e.g., unpatched known-vulnerable programs). But people are already demonstrating exploits; it's not theoretical. > and certainly not by JavaScript running in a browser it seems (even without the timing fixes -- just too much noise in the system to get a real world exploit). Your faith is unwarranted. The paper itself evaluated JavaScript as implemented by v8, which is used by Chrome: "as part of our defensive work, we implemented a number of the described mitigations in the V8 JavaScript virtual machine and evaluated their performance penalties. As we’ve noted, none of these mitigations provide comprehensive protection against Spectre, and so the mitigation space is a frustrating performance / protection trade-off." Also, modern statistics is pretty amazing at removing noise. Don't make claims about "too much noise" until you've tried them. > Most of the machines I use, if you are already able to run native code, the battle has already been lost. Perhaps, but many others are in a different circumstance. We've moved to a world where people run on clouds (shared machines with your enemy) and automatically run JavaScript provided by malicious parties. This isn't hopeless. You can run on clouds but run on temporarily-isolated CPUs so there's no leak. A lot of applications can be easily written to work without JavaScript (though many can't, and many developers have no idea that this might be desirable). For many, providing confidentiality when the CPUs always leak is a real problem. > I think the security community can sometimes have Chicken Little syndrome. That's certainly true. These are not easy to exploit today, especially given some mitigations. But think of these as warning shots - these are problems for which there is NO practical full mitigation today. It would be unwise to ignore the problem. Attackers are likely to gradually get better at exploiting this over time, and if that happens, the only solution available is to NOT share CPUs running programs (disable JavaScript and use more-expensive isolated-CPU clouds) OR replace most CPUs with CPUs that do not yet exist. > I most definitely wouldn't want performance enhancing techniques that might have side-channel vulnerabilities to not be produced or used because they might be exploitable in a use case (eg, web serving and rendering) that doesn't fit most others (eg, internal servers). Understandable, and that may be just fine for your situation. However, most systems try to use least privilege to reduce damage (e.g., if you break into one component, you don't get everything). This attack makes it easier to breach such isolation - so even in that case, you might have reason to be concerned. The sky is not falling, at least not today. But there are reasons to be concerned.