Original URL: https://www.theregister.com/2011/09/12/google_native_client_from_all_sides/

Google Native Client: The web of the future - or the past?

This time, it's Mozilla v Google

By Cade Metz

Posted in Software, 12th September 2011 02:20 GMT

Chad Austin believes in Google's Native Client because he believes in the web.

He sees the web as the ultimate programming platform – something that spans not only disparate devices but the competing interests of the world's corporate tech giants – and he sees Native Client as a way of bringing most any language to the platform, including C, C++, and other lightning-fast "native" languages that have access to a machine's underlying hardware.

Native Client – a Google open source project more than three years in the making – is specifically designed to run native code securely inside web browsers, and for Austin, it puts web applications on "the same playing field" as local applications, providing the raw speed needed to compete with traditional software on 3D games, video editing, and more.

"Native Client democratizes web technology," says Austin, a typical Silicon Valley developer who writes a typical blog on the side. "The web needs to be a first-class platform at the level of Windows and iOS."

Many agree with Chad Austin. But just as many accuse him of talking nonsense, dismissing his democratization argument as one big oxymoron. Applications built with Native Client, they say, aren't web applications. In bringing native code to the browser, they say, Native Client undermines everything the web should be: a contained set of technologies that behave the same way on any machine.

"The web is not native. It's not meant to be. And it will never be," cries one voice. "And I for one am glad that it's so different from native development."

Mozilla, maker of the Firefox browser, is among those who take a dim view of Native Client. In January, Austin took the open source outfit to task with a post entitled "Mozilla’s Rejection of Native Client Hurts the Open Web", and his views were met with a virtual avalanche of both praise and scorn.

Chad Austin

Chad Austin

At Hacker News, the online-hangout-du-jour for Valley developers, the arguments were equally vehement on each side of the issue, and though both camps spewed their fair share of pointless vitriol – "Native Client is a bunch of horse poo," howled one coder – both also had some rather sensible things to say.

Some were technical arguments, picking apart how Native Client may or may not operate. Others were religious arguments, concerned with what the web should and shouldn't be. And in many cases, the technical and the religious couldn't be separated.

Native Client is due to make its official debut inside Google's Chrome browser this fall – it's already in the Chrome beta – and its fate will ultimately be decided by developers, including those who agree with Chad Austin and those who don't.

Its future lies with Google's ability to answer not only the technical concerns but the religious concerns as well. Developers take their religion very seriously, particularly when it comes to the web.

In search of the multilingual web

"In the browser," Brad Chen likes to say, "you can use any language you want – as long as it's JavaScript." Chen oversees the Native Client project at Google, and he describes his baby as an effort to expand the browser beyond JavaScript, the standard web scripting language originally developed at Netscape in the mid-90s.

"While JavaScript is a fabulous language and it just keeps getting better, there is a lot of great software that isn't written in JavaScript, and there are a lot of software developers that are brilliant, but they would rather work in a different language," says Chen, who spent four years on the faculty at Harvard and several more as a software engineer at Intel before joining Google.

"If we're successful with this [Native Client] project, we will make other languages more useful in the context of the web. We want to create a system that gives languages like C and C++ – but eventually others as well – the same excellent level of portability and safety that JavaScript provides on the web today."

That's a tall task. And so far, Google believes it has achieved half of it: the safety half. The portable bit comes later.

"We want to create a system that gives languages like C and C++ – but eventually others as well – the same excellent level of portability and safety that JavaScript provides on the web today."

– Brad Chen

As it stands today, Native Client is a software "sandbox" meant to securely run native code inside a browser. JavaScript is an interpreted, dynamically-typed language, and it was specifically designed to protect netizens from malicious and buggy code, but native languages such as C and C++ – which have access to a machine's underlying components – were not. Native Client seeks to add such protection.

"One of the key features of the web is that it's safe to click on any link. You can fetch code from some unknown server on the internet," says Google vice president of engineering Linus Upson, a former Netscape engineer who has championed Native Client inside Google and out. "Before, when you downloaded a native application, you had to install it and you had to trust it. With Native Client, you can now download native code, just like you download JavaScript and run it, and it's every bit as safe."

A sandbox twenty years in the making

Native Client is inspired by a research paper published by a team of academics at the University of California, Berkeley in the early 90s. The paper described a means of sandboxing native code known as "software-based fault isolation". In essence, this system used a special instruction sequence to ensure that machine code programs conformed to certain security properties, and then it could analyze the resulting code to determine whether those properties were indeed followed.

Brad Chen

Brad Chen

The trouble is that the technique wasn't feasible for use with the x86 instruction set used by modern Intel and Intel-compatible processors. But Google changed that, in part by tapping the instruction set's rarely-used "segment registers". Expanding on a second paper from MIT and Harvard academics Stephen McCamant and Greg Morrisett, Google produced a version of the system that not only worked with x86, but did so with low overhead, letting native code run fairly close to its original speed. "They took the idea and really made it real," Harvard professor Morrisett tells The Register. "They have a very good handle now on how to do this stuff."

With the 32-bit x86 instruction set, Native Client uses the segment registers to restrict where in memory a program can read and write data and to ensure that a program doesn't jump to code outside a certain range of memory. But it also includes a modified compiler and a code verifier that work to keep code jumps in line.

An ordinary program will read a data value from memory into a register and then jump to the address that value represents. But with Native Client, the compiler performs a bit of arithmetic on that value before the jump to ensure it doesn't target bad instructions, and then the code verifier double-checks the compiler's work.

Among other things, the verifier must ensure that a program doesn't leap past the extra instructions inserted by the compiler. "You've added this arithmetic to make sure the jumps are in range. But the real issue is that if it's really clever, a program will arrange for a jump to jump past that arithmetic," says Morrisett. "You might protect one jump but not the next one."

Greg Morrisett

Greg Morrisett

Originally, it was difficult to write such a verifier for x86 because the lengths of the instructions vary. If the lengths aren't the same, it takes far too long to find rogue instructions. As you parse the sequence of raw bytes looking for these bad boys, you have to assume that they could start at any given byte.

But McCamant, then a grad student at MIT, realized this problem could be eased by "padding" the instructions with dummy bytes. "On a RISC machine [where all instructions are the same length], there's only one parse. But on an x86 machine, there can be multiple parses, and it was infeasible to check all of them," says Morrisett. "The trick was to force the instructions to be aligned in a certain way." And Google ran with the idea. In addition to boosting the performance of the system by way of the x86 segment registers, Google improved on the speed of McCamant's padding method.

The games Google plays

Like any other piece of software, Native Client will contain its own security holes, and according to Morrisett, this is a particular worry with the code verifier. In 2009, Google ran a contest to identify bugs in Native Client, and yes, some were found. But Morrisett now describes the system as "pretty robust".

The larger point is that in providing software-based fault isolation on x86, Native Client still maintains the speed of native code – or thereabouts. According to Morrisett, the sandbox adds only about 5 per cent overhead, which gives Native Client a significant advantage over JavaScript.

"It gives you a tremendous improvement in performance compared to other options for running code in the browser," he says. "It makes it possible to do serious rendering and serious number-crunching in the browser without a big performance hit."

Specifically, Native Client can provide more in the way of parallel execution than JavaScript, and it allows for much faster vector arithmetic. For Google, it's a way of opening the browser to 3D games, video editing, and other applications that require that extra bit of oomph, and such applications can be moved to the platform with relatively little effort. Existing native applications must be ported for use on Native Client, but developers needn't start from scratch. They can use their existing codebase.

"[Native Client] gives you a tremendous improvement in performance compared to other options for running code in the browser. It makes it possible to do serious rendering and serious number-crunching in the browser."

– Greg Morrisett

This proposition fits quite nicely with Chrome OS, the fledgling Google operating system that puts all applications inside the browser. With Chrome OS, running existing 3D games and other desktop applications isn't really an option. But the Native Client project pre-dates Google's operating system effort, and the ultimate goal is to bring a new breed of applications to the entire web.

"JavaScript now does integers well, but JavaScript engines haven't really gotten around to vector arithmetic yet, and that's where native code currently tends to have a big advantage...These things aren't important to all software, but when they are, it can mean one or two orders of magnitude in performance," says Google's Linus Upson.

"The sweet spot is 3D games. They do a lot of computation, and the codebase already exists in C++, so they don't have to be rewritten. It allows us to get a lot more fun and exciting games on the web."

The rub is that Native Client isn't the web – at least not yet. It will soon be an integral part of Google's browser and its browser-based operating system. But that's a little different.

Opera man says no to Salt and Pepper

Native Client plugs into Google's Chrome browser via a new API Google calls Pepper. Google has always used "NaCl" as a diminutive for Native Client, and inevitably, it plays off the word "salt" when naming complimentary technologies. Pepper replaces the longstanding NPAPI browser plug-in interface that was developed at Netscape, and the idea is to securely provide Native Client programs with access to all the same browser tools that JavaScript developers have access to.

"Our goal is to have an execution arm that can have no side effects – zero interaction with the outside world – and that's what we think we have achieved with the sandbox," says Brad Chen. "But the thing is that if you can't interact with the outside world, including the browser, you can't actually do anything. That's where these Pepper interfaces come in. They're designed to expose to Native Client exactly what is also being exposed via JavaScript."

The addition of Pepper, says Greg Morrisett, potentially creates more security concerns for the technology, but Google believes Pepper is far safer than NPAPI. The company based the original version of Pepper on the old Netscape plug-in API, but it has since rebuilt the technology from scratch.

Google salt


Google has already used the Pepper API to integrate Adobe's Flash Player with Chrome, and later this month, it will turn on Native Client in the stable version of the browser, opening the doors wide to third-party native applications.

This doesn't make Flash part of the web, and it doesn't make Native Client part of the web either. Native Client hasn't been integrated with other browsers. It hasn't been standardized. And it requires compilation on a specific instruction set. In addition to the x86 version, Google has built versions for 64-bit x86 and ARM, but this still falls short of a web that runs on any device.

Google is well aware of this, and in an effort to alleviate the problem, Linus Upson says that when Native Client launches, Google will only allow Chrome to run Native Client applications that have been compiled for all available processor platforms. Chrome will only accept Native Client applications distributed through the Chrome Web Store, and Google will only allow Native Client apps into the store if they're available for both 32-bit x86 and 64-bit x86 (the ARM version of Native Client is not yet ready for prime time).

"We don't want to bake one instruction set into the web," Chen says. "If it's in the store, we can – through policy – make sure all future architectures are supported too."

Hakon Wium Lie

Håkon Wium Lie

But the ultimate plan is to create a new version of Native Client that can run on any processor. This Portable Native Client – PNaCl, pronounced "pinnacle" – is already under development. Basically, instead of generating x86 or ARM code, this version will transform native code into bitcode using a compiler based on the open source LLVM (low-level virtual machine) project. When the browser downloads the bitcode, PNaCl will then translate it to machine code and validates it in the same way Native Client validates machine code today.

This could potentially give Native Client the same reach as JavaScript. But there are still hurdles to leap. Part of the problem is that Portable Native Client requires more overhead. Currently, Upson says, PNaCl can generally execute much faster than JavaScript, but it does not yet start up as fast. Before officially launching PNaCl, Google wants to ensure the gap is closed. But even if it does outperform JavaScript, it may not win a place inside other browsers. Apple and Microsoft have yet to weigh in on Native Client, but Mozilla and Opera are openly opposed to the idea.

"NaCl seems to be 'yearning for the bad old days, before the web', to paraphrase Tim Berners-Lee," says Berners-Lee's former colleague and not-quite-namesake Håkon Wium Lie, who now serves as Opera's chief technology officer.

Mozilla at the gates of DLL Hell

Wium Lie believes that despite the performance gains offered by Native Client, browser makers should stick to improving the existing web standards, including HTML, CSS, and JavaScript. "The web platform has everything we need to do everything people want, and if there's something lacking, we should fix the web platform rather than go out and build a new platform," he tells The Register. "And that's really what Native Client is about: building a new platform – or porting an old platform into the web. I don't see the need for it. It will just bring in complexity and security issues, and it will take away focus from the web platform."

Simpler, he says, is better. "HTML won because of simplicity," he continues. "It's easier to teach people when things are simple. It's easier to deal with security when things are simple. If you add another platform, that's more for the security experts to look over."

Web standards need expanding, he says, pointing to the new WebGL standard as an example. But that's very different from allowing native code into the browser. "WebGL gives us an interface to the hardware, to graphics processors. But we don't need binary code. That's another beast," he says. "Native Client lets you run legacy games. But it's not worth it."

His view not only contradicts Google's message, it contradicts Google's terminology. For Wium Lie, Native Client is not the web. For Google, it very much is. For Opera, Native Client is a browser plug-in. For Google, it's part of the browser, something very different from Java or Silverlight.

"We don't want to go back to a place where it's just binary delivery over the internet. We've seen people try to do it before."

– Chris Blizzard

Mozilla makes many of the same arguments as Opera, and then it goes a little further. With JavaScript, says Mozilla open source evangelist Chris Blizzard, you can improve the performance of a program simply by improving the browser that sits under it, but that's not the case with Native Client. "The promise of the web is that it's cross-platform, that it's source driven, that it evolves with time. Native Client doesn't actually solve any of those problems that the web actually solves," Blizzard tells us.

"Once you download the native code, there's no opportunity for browser optimizations. There's no opportunity for all kinds of things. You have to keep in mind that the evolution of browsers over the last several years has been that we have made a 10X improvement on existing sites. The evolution of browsers has made everyone's applications faster whether or not you've updated that site in X number of years.

"With Native Client, all of that disappears. The fast innovation we've seen on the web disappears. A source code–based world means that we can optimize things that the user hasn't even thought of, and we can deliver that into their hands without you, the developer, doing anything."

But Blizzard also points out that native code is, well, native code. "What are you going to do about version compatibility? What are you going to do about DLL hell? What are you going to do about Lib C hell? There is reason why Microsoft's operating system has continued to bloat over time and they have to ship multiple versions of things and they have to worry about backwards compatibility. We experience those problems too on the [browser] add-on side. Binary add-ons are more difficult for developers to update.

Chris Blizzard

Chris Blizzard

"All of these things exist in the native code world. It's not a world we want to see. We think the web is a step forward. We don't want to go back to a place where it's just binary delivery over the internet. We've seen people try to do it before. Microsoft's ActiveX is one example. Native Client may have better security properties, but it's reasonably similar."

Native Client is often compared to ActiveX, Microsoft's ill-fated effort to equip browsers with software controls written in C++, Visual Basic, and .NET, and it's not a flattering comparison. ActiveX was a notorious security hole, enabling an epidemic of malicious drive-by-downloads on Microsoft's Internet Explorer. But Blizzard's comparison goes beyond security. Even if it's secure, he says, Native Client isn't a good thing.

Much like all those developers at Hacker News, Opera and Mozilla blend the technical with the religious in making their arguments. But even the religious can't be discounted. After all, developers and browsers makers drive the web. Mozilla still controls a good 25 per cent of the browser market, so even if you don't agree with its stance, its stance matters. If you code for Native Client, many developers will say, you'll reach only a portion of popular browsers – and you'll further fragment the world of online apps.

Google defends baby from red herring

Google understands the complaints, but the company believes it can win the critics over. "We've open sourced Native Client and tried to stay consistent with web standards because we'd like to build something that makes sense for the web," says Brad Chen. "But it's a really ambitious technology. It's not something that we expect other browser vendors to just swallow up with no reservation. It's our job to demonstrate that it's not just safe but really useful."

The ActiveX analogy, Chen and Upson say, is a red herring. "Native Client doesn't add any new capabilities that aren't actually in JavaScript and HTML5. It just makes them available to C and C++ programmers. It fits with the web's security model, whereas ActiveX was actively hostile to it," Upson says.

Asked how Native Client differs from ActiveX, Chen takes a different tack. "You can start by asking how JavaScript is different than ActiveX," he says. "It's safe and it's portable. And safety and portability are at the top of the list for Native Client. I don't think they were ever at the top of the list of the people who were working on ActiveX."

Again, portability is still to come. But clearly, Google believes it can get to the point where PNaCl significantly outperforms JavaScript in both startup and execution.

Chen and Upson also point to efforts like the Emscripten project, which seeks to convert LLVM bitcode to JavaScript. Even if Native Client isn't available in other browsers, Upson says, this would allow all Native Client applications to span the web.



Asked about Blizzard's by-improving-the-browser-you-improve-the-apps argument, Upson says that with Emscripten in place, the issue goes away. "You could start with C code and run it in Native Client or use Emscripten and convert it to JavaScript and run it that. Then the model stays exactly the same," he says. "Native Client does offer some additional capabilities like threading that Emscripten does not, but we can continue to improve underlying Native Client runtime as well."

The trouble is that this adds still more overhead. It's hard to see it ever keeping pace with raw JavaScript.

In the end, there are valid arguments to be made on both sides of the fence. But whatever the stance of Mozilla and Opera and the developer community at large, Google will push ahead with the effort – and push it far.

The beauty of the web is in the eye of the coder

After adding Native Client to Chrome, letting you download and run native apps into the browser, the company also has plans to run Chrome itself inside the Native Client sandbox – or at least pieces of Chrome. "We're people, and we make mistakes, and we write bugs and some of those bugs can become security vulnerabilities," Upson says.

"Native Client is designed so that even hostile code can't do harm to your computer. Wouldn't it be nice to be able to use that same sandboxing technique on our own Chrome code, which is trying to be correct but occasionally contains flaws? If we ran our own code in the Native Client runtime, even our own bugs couldn't be turned into security vulnerabilities."

Linus Upson

Linus Upson

Google may run Chrome's PDF viewer inside of Native Client, for instance. Portions of the browser that require access to the local file system can't be moved into the sandbox, but the company is confident that many other pieces can.

What's more, Google is exploring the use of Native Client on the server-side. A new Google grant program for visiting academics discusses building high performance server applications that run inside the NaCl sandbox. It appears that Google is aiming to sandbox native code wherever it runs. And why not? As Upson points out, Native Client protects against bugs as well as actively malicious code.

But the most interesting possibilities lie with web apps. With Native Client, you could potentially deliver any code to the browser, including software that's traditionally supplied by the browser manufacturer or through third-party plug-ins. Developers wouldn't need to wait for a browser to support a particular video codec, for instance. They could deliver the codec themselves via Native Client.

Unity Technologies has long offered a plug-in for running 3D games in the browser at its Unity platform, but the San Francisco-based outfit is now porting the game platform to run as a Native Client application. This means that developers can deliver their Unity-based games to Chrome without asking the user to install the plug-in – and at the same time, they can take advantage of the Native Client sandbox.

"One of the things that has always been important to us is to reduce friction for customers accessing Unity on the web," says Unity vice president of strategy Brett Seyler, who spearheads the company's collaboration with Google on Native Client. "When Native Client reaches Chrome, it means means Unity developers can reach 20 per cent of the browser market without the usual plug-in requirement. Reducing friction anywhere on the web is beneficial."

Similarly, the developers behind Mono – the open source incarnation of Microsoft's .Net platform – are working on a Native Client port. This would allow Mono apps to arrive in the browser alongside the latest version of Mono itself.

"I think of it as one plug-in to rule them all...Native Client blurs the line between native and web applications."

– Robert Isaacs

For independent coder Robert Isaacs, who has built a Native Client platform that plays classic DOS games, Native Client is the plug-in that puts an end to all plug-ins. "I think of it as one plug-in to rule them all. If you want to execute .Net in your browser, Native Client could be the base technology that allows you to do that. Then you wouldn't have to wait for Microsoft to come out with a new Silverlight version and make sure your users have it installed. You could just deploy the latest version of Mono on Native Client," he says.

"Native Client blurs the line between native and web applications."

It does. But while Isaacs says this with nothing but praise – and so many others join him in that praise – a blurring of the lines is exactly what Mozilla and Opera and others are so opposed to. The beauty of the web is in the eye of the beholder.

In the long run, one beauty is sure to win out over the other. With Chrome controlling 20 per cent of the market – and Google wielding such influence over the web in general – Native Client certainly has the backing it needs to succeed. "Chrome has the momentum. It's clearly the fastest growing browser right now, and Native Client is compelling enough that I believe it will catch on with developers," says Chad Austin. "If they can maintain that ecosystem, I think Google could be in a pretty powerful position in terms of the future of the web."

But not everyone agrees with Chad Austin. ®