It looks like SharedArrayBuffer was released in July 2017 in Chrome and August 2017 in Firefox [1], so I think it's new enough that almost any non-internal website using it would need a fallback anyway. So my impression is it's not quite as nuclear as other web technologies being disabled, but still pretty bad.

I personally used it for a experimental hackathon project in April (in Chrome Canary, behind a flag), and I believe it was necessary for one of the aspects of the project, so it's a shame to see it disabled, but my impression is it's more "future web tech" than "the way the web works today".

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

High performance applications need to share memory between threads. That feature let you do it in JS, and is the basis of the future shared memory multithreading feature in Web Assembly.

So if you want the next Photoshop or Final Cut Pro to be browser based we’ll need to make it work securely.

Seems like virtualization is the way to go for JavaScript. Hypervisors such as XEN in HVM mode with modern processors don’t result in a large performance penalty, so I imagine Chrome will gravitate towards it for running untrusted code.

If running JS (that can access the DOM) in a separate process from the renderer were feasible, browsers would have done it long ago.

You just need to run it in a process without any secret data from other origins or the browser/system.

That seems feasible without significant performance loss in most cases.

There is still a fingerprinting issue though that might not be possible to fully remove without huge performance cost.

Process isolation does not prevent Spectre. In theory, you can carry out Spectre over the network.

That's what Site Isolation is, but it has significant drawbacks: it cannot always protect against cross origin cookie leakage, and pages can have a lot more cross domain iframes than a reasonable process limit can account for.