Traditional C "Hello World" working in NaCl | Hacker News Reader

Traditional C "Hello World" working in NaCl

groups.google.com

59 pointsginsweater25 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?

Strange, I'm not logged in to my Google account and could read the article without any issues.

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?

Another poster said this only happens if you are logged in but need a session refresh.

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.

It works fine here (Chrome on Windows) even if I log out.

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.

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.

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"

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...

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

The good news is its being very actively pro-actively fuzzed and fixed.

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...)

...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'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.

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

Yeah, that's not what happens, at least not today.

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

I wonder when we will see the first obfuscated C for NaCI code contest.

Just a note, it's NaCl, spelled NACL, as in the molecule "sodium chloride" (and the abbreviation of the name "Native Client").

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.

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 ;)

Reply on news.ycombinator.com