4 ms·

JavaScript is the most secure we have. The fact that it is subject to Pwn2Own is part of why. Other sandboxes have not received anywhere near the scrutiny, and

• mwcampbell 8y ago
  Do you think it's likely, though, that a language-based sandbox is more secure than a process-based sandbox? Every major browser developer has now embraced process-based sandboxing in addition to the JavaScript sandbox they already had. Believe me, I want sub-process sandboxing to be viable. But now, post-Spectre, I think it's hopeless.
  • kentonv 8y ago
    The combination of language-based sandboxing and process-based sandboxing is, of course, more secure than either on its own. More layers can only help. You could go a step further and run the process sandbox inside a VM. And run that VM on a dedicated machine. Each layer helps -- but each layer is more expensive, and at some point the cost is too high. But process-based sandboxing does not replace language-based sandboxing. Operating systems (e.g. Linux) have bugs all the time that allow processes to escalate privileges. It's also not at all clear that process-based sandboxing is enough to defend against spectre, either. But it's much harder to design an attack than can break both layers, than to design one that breaks one or the other. Certainly, if process-based sandboxing does not add too much overhead for your use case, then you absolutely should use it in addition to language-based sandboxing. But there are plenty of use cases where processes are too much overhead and we really need language-based sandboxing to make progress.