Last week Google integrated Native Client into the beta of Chrome 14. Native client lets you compile C/C++ code to run in the browser. It depends on a new plug-in API called Pepper. These are open source projects sponsored by Google and implemented in the Chrome browser, and therefore also likely to turn up in Chrome OS which is an operating system in which all apps run in the browser.
Native Client is cool. For example, NaCLBox lets you run old DOS games in the browser by porting DOSBox to Native Client.
Another project is Qt for Google Native Client, a project currently in development. Qt is an excellent and popular GUI and application framework which would speed development of Native Client apps as well as enabling many existing applications to be ported.
It is also worth mentioning that Native Client provides another way to run .NET code in the browser, via Mono with NaCl support.
Why Native Client? Google’s vision, or at least the part of it that focuses on Chrome OS rather than Android, is that everything runs on the Internet and in the browser, making the local operating system unimportant and easily replaced. Native Client removes any performance compromises in managed languages such as JavaScript, ActionScript or Java, as well as easing migration for businesses with existing C/C++ code.
Writing native code for the browser is nothing new. Both Microsoft’s ActiveX and the NPAPI plug-in API used by non-Microsoft browsers let you extend the browser with native code. However Native Client is seamless for the user; you do not have to install any additional plug-in. The main limitation is that Native Client applets do not have access to the local operating system, for security reasons.
It is also worth noting that Native Client apps are not altogether cross-platform. They must be recompiled for different CPU instruction sets, with the current implementation supporting x86 and ARM though you have to compile two binaries. Google says it will support LLVM output to enable cross-platform binaries though this will impact performance.
But is Native Client secure? That is an open question. Google was aware of the security challenge from the beginning of the project. Unlike the plug-in mechanisms which rely mainly on trust in developer competence and signed code to verify the origin of the plug-in or ActiveX control, Native Client inspects the actual code for unsafe instructions before allowing it to run. There is also an “outer sandbox” which intercepts system calls.
However, adding any new way for code to run makes the browser less secure. Google ran a Native Client Security Contest to help identify vulnerabilities, and the contestants did not have any problem finding security flaws. Of course all of these discovered flaws will have been fixed, but there may be others and likely will be.
And is Native Client necessary? The latest JIT-compiled JavaScript engines are fast enough to enable most types of application to run at a satisfactory speed. This is not just about performance though; it is about reusing existing skills, libraries and applications. There is no doubt that Native Client is nice to have; whether its benefits outweigh the risks is harder to judge.
The last question, which may prove the most significant, is political. Google has forged ahead on its own with Native Client, saying as vendors always do that it hopes it will become a web standard. In the early days of the project, it looked like a Native Client plug-in might enable the feature in other browsers, but abandoning NPAPI for Pepper makes this difficult. Will other browser vendors support Native Client?
Here is a comment from Google’s Ian NI-Lewis that I find remarkable:
As you probably know, the rule in Web standards is "implementation wins." So we’re concentrating on getting a good quality implementation out the door. We’re doing that in Chrome. That doesn’t mean that NaCl is intended to be "Chrome only," just that we have to start somewhere.
So Native Client is non-standard, and therefore less interesting than HTML 5 until either Google has a Microsoft-Office-like de facto monopoly of web browsers, or it persuades Mozilla, Microsoft and Apple to support it.
That said, you can think of Chrome as an installable runtime in the same way as the Java Virtual Machine or Adobe Flash, just a potentially more intrusive one. Here is our app, you have to install the free Chrome browser to use it. If this happens to any great extent, I can foresee other browser makers hastening to support it.
For things like feature-rich editors that allow you to create/edit rich content (or games) where superior performance is required NaCl may turn out to be an important option. Say for example you wanted to move a full-featured word processor like Word or Open Office to the cloud. Or, provide something like Excel. Google Docs is a valiant attempt but does not do what Word does.
Now that Canvas/SVG/WebGL etc have reduced the need for graphics-rich plugins what is still missing from Web standards? Raw computational performance. It would be interesting to see threaded C++ go up against JavaScript for counting primes. 😉
If Google can make NaCl at least as safe as Java then things may get interesting…
I find it funny that the statement “the rule in Web standards is “implementation wins.” is all of a sudden something they push as positive. I know of another browser that did just that…
I think you could have found space for a complete quotation. You missed the first line: “We are passionate about making NaCl a standard across all browsers. Our efforts in this area are ongoing.”
Overall these comments should probably be taken in the context of how standards are progressed via RFC. Here multiple implementations are built by different organisations, and someone might have thrown out a spec before they started. If Google don’t build out only their own first then they are open to criticism from others that they are hijacking the process by offering up non-standard plugins for Firefox et al.
I don’t think Google would build this if they were not serious about adoption by some users. Whether those users are on Windows, OS X, or Linux is something worth thinking about. If this pushes the security boundaries Google may be happy for it to only be used by the Chrome OS project where there is a need for native development tools of some kind.
This seemed appropriate:
“In the last month of Rage’s development we’re taking some of our Flash GUI stuff and converting it to C++ because the interpreter for doing the ActionScript stuff in the GUI is taking multiple milliseconds sometimes.”
http://www.codingthewheel.com/game-dev/john-carmack-script-interpreters-considered-harmful
I can’t help thinking that this kind of technology is useless without a lot of programmers liking it and willing to put a lot of hours. Which is the intended audience? Do native coders feel they need something like this? What about web programmers? What are the tools that could be used?
I am curious to find out what blog system you happen to be working with? I’m experiencing some minor security issues with my latest blog and I would like to find something more risk-free. Do you have any recommendations?