Other than javascript in a browser there does not appear to be much in the way of actual spectre attack vectors, though. So once browsers are patched spectre appears to be basically "fixed" for most practical purposes.
Worth noting that many of the claims around Spectre are wholly un-demonstrated. The PoC only involves reading memory from within the same process (aka, the PoC read memory through a side channel that it had full ability to read anyway). Trying to exploit this in a different process is entirely undemonstrated, and there's not even any real discussion in the paper of how it would work. In theory it's doable, but the issues around how you do this once process switching and IPC enters the picture seems substantial yet the paper does not make any attempt to tackle any of that.
"This section describes the theory behind our PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second."
>>Worth noting that many of the claims around Spectre are wholly un-demonstrated.
>This is untrue.
Anything that is not demonstrated in a reproducible way (that is, some downloadable PoC code) is wholly un-demonstrated.
To date, afaik, that goes for Spectre in whole.
However, the description of spectre from spectreattack.com is this:
"Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets."
That, however, is not demonstrated by any of these PoC, not that I can find.
Far worse for an unpached system, yes.
But in terms of fixing the problem, Spectre is much worse, with a larger impact.
It's so bad that I suspect some people will deliberately run without Spectre protection.