> It'd be much, much nicer if we could just use memory safe languages all the time, everywhere. Sandboxing is ultimately a kludge: a recognition that our tools are so dangerous that failure is not just a possibility but an inevitability. It comes at a huge cost in developer productivity, code complexity and sometimes runtime performance suffers too.
I disagree. Both Java and .NET are memory safe and both have supported some form of VM-level isolation for many years. Sure, the kind of missed-length-check-leads-to-complete-compromise we're used to from C is very rare, but at least Java is full of hole anyway.
Process-granularity sandboxing gives a clear hardware-assisted security boundary that can be quite difficult to break through.
tl;dr memory safety is great but it does not replace sandboxing.
The problem is that there's a lot of kernel attack surface, and, moreover, anything big enough to render the Web needs a huge IPC layer between a trusted chrome process and an untrusted content process, which is ripe for attack. (The latter is how most of the Pwn2Own exploits worked.)
I disagree. Both Java and .NET are memory safe and both have supported some form of VM-level isolation for many years. Sure, the kind of missed-length-check-leads-to-complete-compromise we're used to from C is very rare, but at least Java is full of hole anyway.
Process-granularity sandboxing gives a clear hardware-assisted security boundary that can be quite difficult to break through.
tl;dr memory safety is great but it does not replace sandboxing.