Feeds

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

This time, it's Mozilla v Google

The Power of One Brief: Top reasons to choose HP BladeSystem

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

NaCl

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.

Securing Web Applications Made Simple and Scalable

More from The Register

next story
Apple fanbois SCREAM as update BRICKS their Macbook Airs
Ragegasm spills over as firmware upgrade kills machines
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Captain Kirk sets phaser to SLAUGHTER after trying new Facebook app
William Shatner less-than-impressed by Zuck's celebrity-only app
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
EU dons gloves, pokes Google's deals with Android mobe makers
El Reg cops a squint at investigatory letters
Chrome browser has been DRAINING PC batteries for YEARS
Google is only now fixing ancient, energy-sapping bug
prev story

Whitepapers

Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Reducing security risks from open source software
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.