Submitted by Google has released an early version of Native Client, a framework designed to run portable x86 binaries inside a web browser – in a sandbox. Native Client also includes technologies that allow for easier communication between JavaScript and Native Client executables, which makes it possible for web applications to leverage native code when it comes to processor intensive tasks. This sounds eerily similar to Microsoft’s ActiveX – one of the biggest security failures of the Windows operating system. Google insists, however, that Native Client is much, much more secure.
Google also released a research paper concerning Native Client, and in this paper, they detail the extensive work they have done on making sure Native Client is a safe and secure way of running native code inside your web browser. When comparing it to ActiveX, the paper claims:
Perhaps the most prevalent example of using native code in interactive web pages is Microsoft’s ActiveX. ActiveX controls rely on a trust model to provide security, with controls cryptographically signed using Microsoft’s
proprietary Authenticode system, and only permitted to run once a user has indicated they trust the publisher. This dependency on the user making prudent trust decisions is commonly exploited. ActiveX provides no guarantee that a trusted control is safe, and even when the control itself is not inherently malicious, defects in the control can be exploited, often permitting execution of arbitrary code. In contrast, NaCl is designed to prevent such exploitation, even for flawed NaCl modules.
Native Client is available as a preview release starting today. On a final note, everybody who does not mention Google OS in the comments gets a cookie.
Native Client == NaCl == Sodium Chloride == table salt
Just a coincidence?
Or are they subtly trying to hint that someday this technology should be ubiquitous and bring extra flavor to every website?
My first thought too. I assume there is no connection other than the fact they probably think it’s funny to call it NaCl and let just the few people “get it.”
And with this line of cryptogram the software will eventually stress out our systems and force us to get check ups and change our diets.
Only a percentage of people are classified as “sodium sensitive”. But none of us can do without salt entirely. Think about it:
http://tinyurl.com/5b7879
http://tinyurl.com/6n5jvn
Edited 2008-12-10 22:22 UTC
Really? Duh. If you take my post seriously then you miss the point of it.
So Native Client raises our blood pressure if used too much?
I hope not. Otherwise, Mayor Nannystate Bloomberg would ban its use in NYC.
.. not sure it will happen though.
I for one will be _VERY_ hesitant to run native code from some website.
Actually I might not even install the plugin ;P
Agreed. It’s one thing to provide a sandbox for scripting code that requires an interpreter. It’s another matter entirely to sandbox code that’s running natively on the CPU. Without knowing more about the security they’d be putting in place, I’m not at all comfortable with this idea.
I’m not even sure what the advantages of running native code are supposed to be. Poor implementations of non-JIT Java with horrid support for UIs back during the heyday of Java “applets” combined with more years of poor implementations of non-JIT javascript have given portable runtimes (and the letters ‘j’, ‘a’, and ‘v’) a bad name. Java is really only a little clunky these days, and Javascript engines are getting ready to not suck. We’re finally mostly rid of the rid of the ActiveX terror. This is not the time to be pushing native code. It’s finally time to start pushing client-side Java and Javascript.
Then again, the guys at Google are a lot smarter than I am. So there must be some uber-rarified reason for doing this.
Edited 2008-12-10 20:41 UTC
Agreed. Pushing and optimizing Java might be the better option IMHO.
Secretly I am hoping that open source and open standard will break the dominance of X86. It would be really nice to have a fast ARM Netbook in 2009 that can run nearly everything for a whole working day (8 to 10 hours).
100% working open source flash is the only thing I still really need.
And I don’t think Google is smarter than I am
(Lively anyone?)
The problem with “JIT” is that the results are simply thrown away after use. A much better approach would be “JITAR” (Just in Time And Retain), which would then amortize the translation of executable code across multiple invocations. Combined with efficient fine-grained dynamic linkin, a mechanism for finding and using common libraries (not necessarily maintained by a single source), and reliable version checking — all to reduce the actual amount of compilation done across applications — it could be extremely efficient.
Of course, given its relative ubiquity, x86 (or a reasonable subset) could be used as the intermediate language to even further reduce compilation for common cases.
Well, we know the guys at Google know how fast javascript can run. So either they’ve found it is too slow for something they want to do (what the heck would that be?) or this is just an experimental project with no major application in mind.
…they just want to bring more Quake to the world!
Back in the day, I loved Quake 1. I wasn’t a gamer. Not at all. But I downloaded the demo to my W95 box and played it. And I was completely hooked. We didn’t call it Quake 1 back then. We just called it “Quake” because it was the only one. The demo shows E1M3 (episode 1, map 3). And that is interesting. Because I had the most notable dream about it some years ago. Years after Q1, or even Q2 was considered even remotely current.
I was on that very level. I just sort of found myself there. Except it wasn’t a game. It was real. No monsters were present. No one at all, in fact. It was completely silent. It was like a Disneyland recreation but without the cars and without the other people. I walked from the cave, where you start out, into the hallway shown in the screenshot. (It’s the first appearance of the grenade launcher.) The Ogre wasn’t there, though. I walked around for a while, and was just amazed that I was really able to view what I was considering to be some sort of recreation even in the dream. The architecture was awesome, as Quake 1 architecture usually was. Then I guess I moved on to another dream or woke up. But to this day, I’m glad for the experience.
Edited 2008-12-10 23:37 UTC
Rewriting C code in Java is expensive.
It is, but that’s relevant only if existing unmodified C code will run on this new platform. There’s a question of libraries (both static and shared), of binary formats, of all sorts of things like that. If my code calls printf, for example, where will it find the function implementation, and how? The story doesn’t answer any of those questions.
Expensive? Relative to what? Google’s expenses on marketing vaporware costs far more than that cost.
But why, Google, why? Why do we need to run x86 binaries in a browser which is itself an x86 binary? Can’t we like have normal secure web standars and instead dive further into obscurity and incompatibility?
I think they want to compete directly with other managed environments [.net and Java] and their “bytecodes” are very similar to the x86 opcodes [I say “very similar”, should I say “identical”?]. In this way, they can create a JIT compiler in a simpler way and they get normal x86 binaries running with no modification [or simple modifications] in their “vm”.
Nice approach I think, though I see the possibilities surpass the web and the webbrowsing and invade the virtualization and process isolation arena.
Edited 2008-12-10 21:16 UTC
maybe i am missing hte bigger picture, but does anyone else think that google’s time could have been btter spent on something else?
Maybe. But then again, a lot of major advancements in technology have come from companies investing in research that seems of questionable importance to their main business plan.
Xerox, anyone?
Seems a bit silly to build this with x86 in mind, especially since google wants have a piece of the action on the mobile market with Android. And I don’t see any mobile x86 devices appearing any time soon…
So, does Android compile on x86?
I was just looking to code a website! (www.muslimnur.com)
This must be one of the most backwards projects that Google has done. This is totally a step backward, not forward. There is no future for native code on the web.
Let’s look at their example:
For example, imagine that you run a photo-sharing website and want to let your users touch up their photos without leaving your site. Today, you could provide this feature using a combination of JavaScript and server side processing. This approach, however, would cause huge amounts of image data to be transferred between browser and the server, leading to an experience that would probably be painfully slow for users who just want to make a few simple changes. With the ability to seamlessly run native code on the user’s machine, you could instead perform the actual image processing on the desktop CPU, resulting in a much more responsive application by minimizing data transfer and latency.
Well, if you code your app poorly, then yes you will have tons of latency and data transfer back and forth. However, someone who knows what they’re doing would do all the processing on the client-side anyway, with a rich client-side JavaScript framework like SproutCore. So the argument for “increased latency and bandwidth use” is irrelevant.
The only real argument is performance. But JavaScript engines (V8, SquirrelFish, TraceMonkey, etc) are becoming insanely fast. Sure, perhaps not quite as fast as running native code, but close.
And with native code the runtime has to do extra work like verifying the binaries which has an additional overhead. Not to mention the incompatibility between different architectures (I’d like to see that X86 code running on an iphone… and if it does using some kind of VM, to compare its performance to optimized JavaScript running on V8 or SquirrelFish), and the additional burden for the developer.
This is just yuck.
Edited 2008-12-10 22:13 UTC
I think that’s a bit of an exaggeration. The javascript engines are certainly becoming a lot faster, and for most purposes, are fast enough. But to say they’re close to native speed is exaggerating more than a little. For heavy computation work, it’s hard to beat true native code.
I violently disagree. Try writing a full-featured postscript document viewer (i.e. Acrobat) or a timeline based vector/rastor graphics runtime with scripting support (i.e. flash) in javascript or java and see what the uptake on that would be. You cant do everything in Java – sometimes performance matters. I think people are missing the point because of the whole “it runs quake!” angle…
1. This is potentially a _safe_ and browser-neutral alternative for activeX and netscape plugins.
2. Neither of those 2 technologies is remotely secure or trustworthy – this promises to be.
3. If (I stress if) this can be made provably secure ,i.e. the runtime can guarantee that code running within it cannot perform certain operations this could be very very useful indeed.
I would argue that the real benefit of this is not so much to create a new development path for web applications, it is to replace an already existing, heavily utilized, but horribly broken one. Just because we are all used to the fact that plugins are plain ass insecure and untrustworthy doesnt mean we should accept it as a fact of life.
As things stand now, both acrobat and flash do massive amounts of system configuration, registry changes, file-type associations, writing executable images and libraries all over the place, etc. They do this simply because they can. A runtime that would permit these types of applications to be developed, but would inherently limit their ability to affect the underlying operating system and filesystem would imho be a very good thing.
Correction to the OSAlert summary: Google does not claim that Native Client is actually secure *at all*. In fact, they released it early as open source so it can even CLOSE to have a chance to be secure.
And as for Native Client itself, I think this idea is pretty ridiculous considering the gap between unmanaged and managed performance has only gotten considerably smaller over the last few years. Then there’s the fact that developers would need to deploy multiple Native Client executables to support anything except stock PCs, and the fact that the performance gains of such a platform over Java, .NET/Silverlight, or Flash-based RIAs will not only be negligible, but it will continue to shrink as those systems gain more runtime performance enhancements. I just can’t imagine a world where this would actually be beneficial to a normal web developer (although clearly this could be useful in medical and other latency-intensive/precise software).
Interesting project though and I’m glad they open sourced it right off.
don’t forget it can be used not only on the web, but on the client-side too… plugins can use NaCl and solve some problems that plugins have in these days…
Yay, the ActiveX it’s cool for everyone to play with?!
Not many ActiveX analogies, apart from the fact that they run native code, of course. ActiveX is far more complex than NC could ever be.
But I doubt that Native Client can actually run native code because that would be highly risky, even when removing “dangerous instructions”. To be secure, NC should be sandboxed and thus run inside a VM. If it runs inside a VM, NC basically is like Java applets, Flash or Silverlight. So Google created its own version of those frameworks, something which was highly probable in the past and now it’s a reality.
If it doesn’t compile into bytecode and it actually compiles to native code, it will be highly difficult to secure, even when stripping out dangerous code during compilation.
Whatever it is, as I stated in past, this is a confirmation from Google that Javascript+HTML model is not suitable for complex Web-based application. This is a *direct* confirmation that Flash/Silverlight/Java path is the right one. As it was expected
why do do we need all those complex web applications anyway, sure they are convenient but isn’t that stretching the initial goal of the web.
Plus I don’t think plugins/applets is the way to go, as it cut a significant share of the user (mobile, alternative OS,….) from the actual content.
I’m inclined to agree. I’ve written AJAX apps and while they work well, the overhead is ridiculous even with other people writing the frameworks. Web apps are exciting until you see what it takes to make them work.
I think Google is readying for Photoshop in the browser, or maybe it is time for games.
Before anything else, Security, or usefulness,
Does NaCI runs on anything other then x86 is the most important question. Or will be it possible to run on other processors.
If it is x86 only then i will say it is a SERIOUS step backwards.
I could see the usefulness of Native Code. But being x86 only seriously hurt.