[josefx]

> Every single person who starts writing a new application in a memory-unsafe language that will deal with untrusted inputs is declaring up front that they are willing to tolerate the inevitable vulnerabilities and exploits caused by that decision.

Meanwhile we banished Java and Flash from browsers, with JavaScript still leading every pwn2Own contest because these "memory safe" languages are ultimately still implemented by humans paid to prioritize new features instead of security. I still haven't seen a website that absolutely needed multi threading, certainly didn't break anything of note when it had to be disabled as specter mitigation.

[titzer]

I worked on V8 for almost 7 years. It being written in C++ is a cause of a large number of issues. And even larger number of issues is caused by its absolutely massive complexity and the low-level nature of what it does, particularly the object model and the JIT compiler's complex optimizations. Low-level is really dangerous and error prone.

I think every VM should be rewritten in a memory-safe, GC'd language. While there are bugs at the meta-level (i.e. the compiler IR and object representation), making the runtime code itself memory-safe should be table stakes for even talking about a trustworthy implementation.

[UncleMeat]

Memory safety is not a security panacea and you should run far away from anybody who says that it is. What I am arguing is that it is table stakes.

Browsers also have a uniquely difficult security challenge in that they, by design, execute untrusted code and compete based on the performance of their js engines.