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.
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
That's a tall task. And so far, Google believes it has achieved half of it: the safety half. The portable bit comes later.
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.
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."
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".
"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."
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.
"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
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 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."
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.
"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
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
"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.
"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."
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."
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.
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.
No comments yet.
Leave a comment
You must be logged in to post a comment.
Trackbacks are disabled.