The claim that process isolation is "antiquated" is absurd, since it's what everyone else is doing except for those, like Firefox, who have not yet started to do anything at all. I don't know any other projects that do what NaCl does, so regardless of whether Google <i>should</i> switch to pure NaCl for sandboxing, if they <i>did</i>, it would be innovation, not scrapping an antiquated technology.<p>As for whether they should - although Native Client's software fault isolation can provide better latency than hardware-based solutions because there's no need for a context switch, it takes a hit in throughput (7% overhead) because of the code contortions involved (though being able to trust the executable code might improve things). There would be significant issues with supporting JIT in such a model, because JITs typically like to have rwx memory. Multiple sandboxes in the same process wouldn't work with the current NaCl model on 32-bit platforms. And although the SFI has been well secured, putting user code in the same address space as the master process might make exploitation easier - this would be partially mitigated if the address of the user code could be hidden from it, but doing that would require additional overhead because addresses could no longer be stored directly on the stack.