At its core both vulnerabilities are essentially local privilege escalation bugs (i.e. a random process can read e.g. secret keys from another process), but that still is a very important exploit - if I can run unprivileged C code on e.g. AWS and are able to read the memory of someone else running on the same shared machine, that's really bad.

The Javascript case is the main one that makes it remotely exploitable.

My understanding is it's anything that can make a running process mis-train the CPU core and read the values back. Consider, for example, shared hosts without separate process pools, running code from different users with the same interpreter processes.

Just because it runs in a C PoC does not mean it only runs in C.

From the Spectre whitepaper:

> In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.

The whitepaper doesn't contain example JS code however

This whitepaper describes the Javascript exploit in Section IV. I'm struggling to understand it though: http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf

This too was provided as a proof of concept (without explanation): https://brainsmoke.github.io/misc/slicepattern.html. I'm not sure what I'm looking at though

This is the first implementation in Javascript I have seen so far: http://xlab.tencent.com/special/spectre/js/check.js

At its core both vulnerabilities are essentially privilege escalation bugs (i.e. a random process can read e.g. secret keys from another process), but the Javascript case is the one that makes it remotely exploitable.

It is.