It's not just untrusted native code. A lot of these exploits in general are exploitable through js.

And I know there are folks on hn who think js is an abomination and noscript is the answer to all of life's persistent problems. "My web browser should be exclusively for reading text." But personally I'm not interested in taking us back to the 1990s.

I don't need to be in the 1990s, I just wished websites wouldn't need to draw from ~200 untrusted sources and possibly worlds largest malware distribution channel to show some ads from even less trusted sources right next to badly formatted text.

I mean the text is probably from poorly trusted sources as well but that's a different problem.

but text has a limited attack scope compared to say: an entire interpreted language and DOM.

> I just wished websites wouldn't need to draw from ~200 untrusted sources

That's just how it is though. Even if you're using vanilla js.

Don't get me wrong, I know what you mean... it's just that it's really hard to actually find arguments for that... philosophy

At this point, I think it doesn't really matter as long as your site has a good ux.. which is obnoxiously hard to measure

With Noscript enabled I have the power to chose what to trust and not to trust. That means I have gradual control over what runs and doesn't run, and can chose to only allow the bare minimum for getting a specific page to run. It's that simple.

JS is fine as a technology, but blindly executing every single piece of code on every single web page is simply not a good way of doing things.

In what ways could JS be limited to preclude such attacks? (E.g. no JIT compilation, cache flush after every opcode, etc.).

No constant addition and removal of new APIs. Lockdown of special purpose APIs with explicit user request to unlock: 99.9999% of sites will never need WebGL, 99.9999% of sites don't need an Audio API. Modern JavaScript has the attack surface of Java and Flash combined and enabled by default, instead of hardening this against attacks browser are stuck in the same feature race they have been in since back when IE6 was still dominant browser.

> cache flush after every opcode

This would make JS outrageously slow, like hundreds of times slower than it is now.

You don't need it to be very fast just to respond dynamically to some event handlers and whatnot. (The basic scripting stuff JS was intended for.)

You also don't need modern wheels, when just pulling a simple carriage wheels were invented for.

Modern JS engines are not written for playing funny tricks with "window.status" or "window.title" as in 1990, but for more complex applications.

Not all uses are useful, but that's to subjective. As with wheels.

Any cloud provider with sufficient security doesn't allow customers to share SMT cores anyway. For example, AWS hard partitions their physical servers, which is why you can get exactly 16 m4.xlarge instances, 8 m4.2xlarge, 4 m4.4xlarge, 2 m4.8xlarge, or 1 m4.16xlarge instances on a physical box.

I do predict that the VPS providers will see some nasty side-channel attacks in the coming years due to the way they've chosen to share SMT between customers to reduce their costs and overprovision their hardware.

Physical containment would work fine. Given the current small footprint of computing modules, we could just run each separate untrusted cloud apps from a node the size of a pi0. All we need is a high throughput interconnect with a well defined interface to exchange information.

... wait, that sounds like plan9's dream

Yep.

I understand that half the world runs on this stuff nowadays. That doesn't make it any less insane.

Your customer database is in a random DC somewhere halfway across the world running on the same box as some other arbitrary code.

Nice one. It's Web Scale(tm).