Third-party JS, tracking, unblocked advertisements, possibly malicious on-site code, etc.
If you're allowing any site to run JavaScript, you're running entirely arbitrary and uncontrolled code on your machine, and thus is in dire need of the mitigations.
It's a different situation for a server designed to not run remote code, which makes it practically impossible to exploit speculative execution vulnerabilities.
You might trust the site you go to; but that's not all the javascript that gets loaded, there are includes that a lot of web developers will use for convenience, there are ad networks and there are bugs that could allow some unintended javascript to get loaded (like with bit-squatting[0]).
It's not a given that you're safe running javascript if you only visit sites you trust. Even if you are INCREDIBLY sanitary, which I would argue is unrealistic (just check your history and you'll see that you probably visit many sites off of a google search).
[0]: http://www.youtube.com/watch?v=lZ8s1JwtNas / http://dinaburg.org/bitsquatting.html
I am fuzzy on the details, but I do think it’s possible.
Meltdown is out of order execution detectable from caches. They made it difficult to get a good timing source in JS, so there’s that.
Spectre is training the branch predictor unit to execute code that you want in caches. You would need a good timing source again.
So there is some security in place. I think a creative hacker will get around it though.
No, they didn't. A while loop with a counter is a good timing source, and you can't really prevent that without severely crippling everything's performance. Want a good timing source in your browser? Just follow those three easy steps:
1. Start a while loop in a webworker
2. In that while loop, incrementing a counter in a SharedArrayBuffer
3. In the main javascript, read that number from the SharedArrayBuffer.
Bam, a decent clock.
> Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre. Chrome [re-enabled it in v67](https://bugs.chromium.org/p/chromium/issues/detail?id=821270) on platforms where its site-isolation feature is enabled to protect against Spectre-style vulnerabilities.
from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
It's true that Date.now() has a reduced precision, e.g. Firefox with privacy.resistFingerprinting=true rounds to the nearest 100 ms increment. But you still get high-precision timestamps from window.requestAnimationFrame(), so you get a precision of at least 16 ms, assuming 60 Hz refresh rate, or even higher on gaming rigs with 144 Hz monitors.
My application depends on libuseful version 1 or later. libuseful_1 depends on libtiny, but libuseful_2 depends on libbigballofmud, which consists of libtiny and 800 other libraries that have been merged together for political reasons. libuseless, which was also merged into libbigballofmud, depends on rce-daemon, or nvidia-brick-the-install, or systemd, and I've never heard of rce-daemon before, so it's not blacklisted and installs with no error message. As the other two options suggest, this is not hypothetical.
Is this in reference to when the nvidia driver had
sudo rm -rf /usr /lib/something/something
But no; my desktop machine has a video card that doesn't display anything (black screen) if booted with the non-legacy nvidia drivers. I had to boot off a old 32-bit install to get rid of them and then wrestle apt/dpkg back into a sane state.