Let's presume that the world can be convinced of the safety of native client security. What's it worth? I think this is the same question as, "What kinds of things aren't good enough on the JVM or CLR?"
Modeling/Simulation/etc. certainly benefits from running on the metal. But, with the exception of SETI@Home, etc., nobody runs untrusted simulation code. Games are the obvious target. A webby sort of Photoshop might also benefit. What else?
Am I wrong to think it obvious that Google's goal is to do away with the last major reason(s) to run Windows? Is there any other benefit to being so close to the metal when we have nice, sandboxed VMs that JIT compile quite efficient code?
You'd rather they make or dispose of an undecidable claim? Everything has implementation flaws. They're right; nobody came up with a way to beat the simplified, scrubbed x86 subset they came up with to run NaCL in.
The vulnerability you're talking about is a straightforward implementation flaw. Admittedly, it's a flaw NaCL's design begs you to make: forgetting about an aspect of x86 encoding is a problem you only have if you're going to let raw x86 instructions hit the processor. But the fix for it is no harder than the fix for, say, an implementation fault in the ELF loader code.
Hah, well, as you authored it you know what it says better than I! :)
But I'm inclined to say that "they're at greater risk of implementation flaws because of their design" -- and unlike you, for me I believe that itself does actually count as a design flaw.
(And on a side topic/rant since you mention the ELF loader: were I to have Google's resources, I would be far more paranoid than they about this whole thing. e.g.: the ELF loader doesn't need to be fantastically speedy; why not write it using tools/languages with stronger guarantees of memory safety? (That would hold for anything that wasn't inner-loop stuff, as well.)
Another example: The verifier & safety of the allowed instructions are the crown jewels; why not hire the pointy-headed folks who do formal verification for some stronger assurances that the allowed instructions really are safe and that the verifier is complete?)
Edit to add: And if changing the language & tooling isn't feasible, they could have at least pulled a neat trick and run the ELF loader (and similarly exposed code) within their own sandbox, rather than outside of it.
I really hope this goes somewhere. I think there's a good chance they'll be able to make it difficult to attack this client to the point that other targets (Flash, Java, QuickTime, etc) will be easier to do damage with. And native code in the browser would rock, obviously.
Modeling/Simulation/etc. certainly benefits from running on the metal. But, with the exception of SETI@Home, etc., nobody runs untrusted simulation code. Games are the obvious target. A webby sort of Photoshop might also benefit. What else?
Am I wrong to think it obvious that Google's goal is to do away with the last major reason(s) to run Windows? Is there any other benefit to being so close to the metal when we have nice, sandboxed VMs that JIT compile quite efficient code?