3 ms·

I didn’t read the article, but I would advice against the idea that I can read a good chunk of your memory with Meltdown and Spectre via a JS ad. I am fuzzy on

I didn’t read the article, but I would advice against the idea that I can read a good chunk of your memory with Meltdown and Spectre via a JS ad. 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.

roblabla 7y ago
> They made it difficult to get a good timing source in JS, so there’s that. 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.
- deleted 7y ago
  [deleted]
- Filligree 7y ago
  Didn't they disable SharedArraybuffer for that reason?
  - striking 7y ago
    Yes and no? > 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 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/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
majewsky 7y ago
> They made it difficult to get a good timing source in JS 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.
- progval 7y ago
  I find it amusing that having an expansive monitor could be used to leak data more efficiently from CPU caches and RAM

roblabla 7y ago

> They made it difficult to get a good timing source in JS, so there’s that. 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.

deleted 7y ago
[deleted]
Filligree 7y ago
Didn't they disable SharedArraybuffer for that reason?
- striking 7y ago
  Yes and no? > 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 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/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

majewsky 7y ago

> They made it difficult to get a good timing source in JS 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.

progval 7y ago
I find it amusing that having an expansive monitor could be used to leak data more efficiently from CPU caches and RAM