Of course it will! Spawn a separate process with a JS VM per page, on a separate core if you can afford, and the problem goes away.

The price is steep, though — at least with the current crop of hardware.

I did say a single protection domain, because it seems unlikely that any popular web browser is going to switch to a model where DOM access requires IPC.

That said, even a single VM per page doesn't help, because you have scripts from advertising networks running alongside other scripts. You'd need at least a VM-per-origin-per-page.

This depends on the threat model. E.g. running the JS VM on a separate hardware host under a stripped-down supervisor would prevent any web page from stealing secrets from your "main" machine, but not from each other.

I suppose that once a page includes third-party scripts, it already gives them the key to its kingdom, like sniffing anything from DOM or altering it in arbitrary ways. Thus per-page isolation seems sufficient to me; maybe even per-page-set isolation when I open many pages from the same site (this needs a way of clearly defining what "the same site" is).

> I suppose that once a page includes third-party scripts, it already gives them the key to its kingdom, like sniffing anything from DOM or altering it in arbitrary ways

doesn't same origin policy prevent this?

No, loading a script (from anywhere) effectively invites it into the origin of your page, giving it access to everything connected to the origin of the page. That is, the origin of the script is not considered, only that of the page.

Think about loading jQuery from a CDN, for example, which people do. If third-party scripts couldn't access the DOM it wouldn't be very useful.

What about web workers or service workers? Don't browsers force all script execution in the workers into a separate process?