The immediate response from browsers was to disable shared memory across JavaScript contexts (previously you were allowed to create a SharedArrayBuffer and share it across WebWorkers, which if you're familiar with UNIX you should read as "mapping a shared memory segment in multiple processes" or "threads with shared memory") and to disable high-resolution timers, which makes it hard to get useful information out of timing attacks. I believe SharedArrayBuffer is coming back now-ish and I'm not totally sure what the mitigations are.

The panic fix was to short term remove SharedArrayBuffer which was necessary to create a high precision timer. But the real fix is http://www.chromium.org/Home/chromium-security/site-isolatio...

Browsers just resort to process sandboxing entirely. They assume JS can escape its sandbox, but since it can only read contents that were produced from its origin anyway it doesn't really matter.

Browsers and cloudflare workers removed/neutered high resolution timers (and things from which you can build high resolution timers) to make exploitation difficult.

CPU speculates past the bounds check and loads values you should not read into cache and you try to find out which value was loaded into cache using precise timing but the timer is imprecise so you don't know what the value was which you were not supposed to be able to read.

Ultimately, code from each security origin is going to have to run in its own process space.