Traditional C "Hello World" working in NaCl(groups.google.com)
groups.google.com
Traditional C "Hello World" working in NaCl
https://groups.google.com/forum/#!msg/native-client-discuss/lT5bsW1ZlKQ/WsXJ5y_2s54J
6 comments
As a side note, why is it that I have to sign in to Google in order to be able to see this? Is registration /really/ necessary for Google Groups?
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.
Another poster said this only happens if you are logged in but need a session refresh.
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.
Strange, I'm not logged in to my Google account and could read the article without any issues.
It works fine here (Chrome on Windows) even if I log out.
I think it's a bug. Are you on a mobile browser?
I think it's a bug. Are you on a mobile browser?
Yeah I think it's a bug with mobile... happens on my ipad all the time (super annoying) but not my PC.
Can someone please explain to me why running native code coming from a web site is a good idea?
Because I see this as "Google's ActiveX"
Because I see this as "Google's ActiveX"
Read the paper. It's a subset of x86 that retains better security properties for distribution.
http://src.chromium.org/viewvc/native_client/data/docs_tarba...
http://src.chromium.org/viewvc/native_client/data/docs_tarba...
Very interesting. The security features are very thorough.
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
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
The good news is its being very actively pro-actively fuzzed and fixed.
Worth looking at too: zeroVM http://zerovm.org/
Worth looking at too: zeroVM http://zerovm.org/
Someone might as well find a vulnerability in a Javascript engine. What's your point?
At best that takes care of the security issues. The other thing that makes ActiveX an affront to the web is the platform lock-in.
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...)
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...)
...and Windows Installers are a lousy way to get someone to be able to run your program.
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)
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)
[deleted]
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.
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.
I would assume the NaCl apps won't run by default. Maybe you get that "click to activate" thing that firefox is implementing for Flash and Java
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.
[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
[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
Yeah, that's not what happens, at least not today.
I wonder how it handles a bogus printf format string.
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.
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 ;)
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 ;)
[deleted](1)