I think it's a bug. Are you on a mobile browser?
Because I see this as "Google's ActiveX"
http://src.chromium.org/viewvc/native_client/data/docs_tarba...
Of course, until someone finds a vulnerability, or a way through the validator, or an exploit on an abstracted function.
Still, it's a good security model
x86 code is not suitable as a web standard. (And neither is the LLVM intermediate representation, for reasons expounded on in e.g. http://permalink.gmane.org/gmane.comp.compilers.llvm.devel/4...)
With javascript we basically have open-source web apps. I often skim through js source to learn new tricks - and obfuscation doesn't really stop me (apart from google's java-translated js) . With compiled NaCl I probably wouldn't be able to find out a lot.
I'm not talking about "stealing user data" when I say sneaky code. No, with compiled native code a whole new game is started: computational-intensive code. It wouldn't be that difficult to include code that gets a job to work on for a few minutes: breaking captchas, brute-forcing passwords, anything that shift computational effort from a server to a client.
[1] https://developers.google.com/native-client/community/securi... [2] m.yahoo.com/w/legobpengine/news/google-bringing-high-end-gaming-chrome-via-native-054102268.html
Are you trying to ask if it catches, e.g., format string vulnerabilities? I think the answer to that is: Native Client's aim is to be a safe x86 VM, so — hopefully. But to me personally, it seems unlikely that they've thought of everything.
The unlikelihood that the original design was perfect is probably why they had the "Native Client Security Contest" a few years ago - and indeed independent researchers found several flaws. Personally, I'm a lot happier with it now that they've fixed everything that Mark Dowd could find wrong with it ;)
