The same way the underlying printf implementation does? This isn't wrapping printf(3), just the underlying write(2).
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 important part of the design - the bit that makes it achievable - is that it's not a general x86 VM. It only accepts a limited subset of valid x86 object code, a subset chosen to make validation a tractable problem. This requires a modified compiler be used.
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 ;)
You are right. It's very annoying. It's even worse than having links that are behind a paywall, because at least a paywall usually indicates that funds are flowing to the person (reporter, etc.) who created the content. The google groups situation is quite different, and quite annoying. I never login to google groups to see something listed on HN. I wonder whether HN could provide an option to let readers avoid such items, by removing them from the listing or flagging them?
You are only being asked for a password because you're (partially) logged in to a Google Account already. Either log out, or open Google Groups links with "open in incognito window" if you use Chrome.
If you're signed in to a Google account already but your session is inactive, you might be asked to re-authenticate. If you're not signed in at all, you don't get asked.
I'm a fan of fast native code, but I worry that this promotes sneaky code in the background once it gets widely adopted.
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.
It doesn't run by default. But remember it's Google who's pushing this, and their browser has momentum. I'd guess it's just a matter of time before they run it by default. They already cashed out for security bounties for NaCl in the past[1] and seem to have increased resources recently[2] since it's quite a lucrative market for gaming.
27 comments
[ 4.3 ms ] story [ 64.5 ms ] threadAre 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 ;)
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
Worth looking at too: zeroVM http://zerovm.org/
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...)
I see Native Client as being an extremely nice solution to several issues at once:
- runs fast
- the programs don't need an installer
- I can trust a Native Client program (that's me personally)
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