Google's Chrome OS does not run local applications or store local data. Everything is handled inside the browser. But when the much-hyped operating system debuts on netbooks at the end of next year, you can bet it will execute native code on behalf of online Google applications such as Gmail or Docs and Spreadsheets.
In other words, Google apps will tap directly into the netbook's processor in an effort to close the performance gap that separates them from the local software offered by its bete noir, Steve Ballmer's Microsoft. And this being Google, they won't use Java, Flash, or Silverlight.
In typical fashion, Google is playing coy over the role of native code in its fledgling OS. But the company says its Native Client project - which executes native code inside today's Google Chrome web browser - is an "important part" of an effort to boost the performance of web-based applications running on its netbook operating system, set to appear on x86 and ARM netbooks around November 2010.
Currently, Native Client (NaCl) runs only on x86 machines - via Windows, Mac, and Linux. But Google has confirmed it's building a version for ARM.
Google unveiled its Native Client plug-in a year ago, calling it "a technology that aims to give web developers access to the full power of the client's CPU while maintaining the browser neutrality, OS portability, and safety that people expect from web applications." Then, in October, it rolled the plug-in into the latest version of its Chrome browser, which serves as the basis for Chrome OS.
Chrome OS is essentially the browser running atop a Goobuntu flavor of Linux.
At the moment, Native Client is turned off by default in Google's browser. But clearly, bigger things are ahead. During Google's November press conference unveiling an early version of Chrome OS, vp of product management Sundar Pichai and engineering director Matthew Papakipos were hit with not one but two questions about the role of Native Client in their fledgling operating system. And twice they answered only in part.
"We are investing a lot in additional technologies like Native Client, which will make it really possible for some of the most performance-intensive desktop applications to become web applications," Pichai said in response to question number one.
Then, when a second questioner asked if Native Client would be "an important part" of Chrome OS, Pichai said "work is underway to make [Native Client] work on ARM." And though he declined to "go into all the technical details," Papakipos explained that Native Client applications would run on ARM just as they run on x86 chips.
"We'll make sure there is a way for you to have Native Client–based applications that will run equivalently on x86 and ARM," Papakipos said. "There's a lot of work going on with that today. You'll see more of that."
You can bet, however, that Google will offer native code versions of its online apps when the OS debuts at the end of next year. Last month, Dave Girouard - president of Google's enterprise division - said that in a year, Google Docs will be so effective that users will be able to "get rid of [Microsoft] Office."
This fall, Google also unveiled a new programming language it calls Go, an effort to crossbreed a dynamic web-happy language like Python with a compiled language like C+. The company has since said it plans to integrate the language with Native Client. It would appear this effort has barely gotten off the ground, but that's certainly the aim.
"We have an embryonic implementation of the NaCl support for Go," a Go developer told Cnet. "It's restricted by a couple of details of NaCl's implementation, but we hope to see changes to NaCl one day that will make Go a full-fledged language in that environment."
We also asked Google to discuss the future of Go. But it has yet to respond.
It's no surprise that Google is working to boost the performance of webware. By design, Chrome OS is an effort to usurp the Microsoft model with 100 per cent "cloud-based" applications. But some have questioned whether Native Client undermines the "open" browser ethos Google has so vehemently pushed for in recent months.
A plug-in is a plug-in
"I don't see really what [Native Client] brings. I think it goes against what we're aiming for - which is to offer the web browser as the application platform."
This, Bolstad says, is the best way to battle the performance of local applications. "The thing that the web browser has going for it is that it's portable," he continues. "You can write cross-platform web applications and expect to get near-native execution speeds. Maybe not today but it's not far away."
The Native Client plug-in is available for other browsers, including Opera and Firefox. But it's still a plug-in. And it's not the only one. Google has also released its own 3D browser plug-in, O3D.
"The web’s main attractions are platform independence and instant deployment. Yet the industry’s obsession with moving every desktop application online is provoking plugin development which negates the advantages," writes Craig Buckler, director of OptimalWorks, a UK-based website-building consultant.
"Relying on a plugin violates platform independence. Creating a Go-based client-side application will almost certainly tie you to Google Chrome since NaCl will never be available for all OS and browser combinations. Many web applications still rely on IE because ActiveX was used - even though Chrome and Firefox have ActiveX implementations."
Then, of course, there's the security issue.
The new Active X?
Native Client is akin to Microsoft's Active X or Java or Flash, all regularly derided for exposing security holes in their execution of native code. "There is a security concern," Opera's Bolstad says. "I'm not saying there's anything in particular that's insecure about their current implementation. But the moment you start executing native code, there is a trust issue. Users may not realize that they're allowing native code to execute when they visit a webpage."
Google does acknowledge the difficulty of ensuring security with such a platform. But the company is confident it has taken the necessary precautions. "To help protect users from malware and to maintain portability, we have defined strict rules for valid modules," Google said when it first open sourced the project.
"At a high level, these rules specify 1) that all modules meet a set of structural criteria that make it possible to reliably disassemble them into instructions, and 2) that modules may not contain certain instruction sequences. This framework aims to enable our runtime to detect and prevent potentially dangerous code from running and spreading."
But no matter how secure the plug-in is in and of itself, Native Client is still a plug-in. Folks like Buckler question whether Google is opening the same Pandora's Box it opened with Google Chrome Frame, the infamous plug-in that turns Microsoft browsers into Google browsers. Buckler cites the rather convincing argument against Chrome Frame laid down by Mozilla CTO Mike Shaver.
"Although Chrome Frame is a niche solution to a known problem, Mozilla is worried that the web could become fragmented if companies eschew web standards in favor of plugin-based solutions," he says.
After the release of Chrome Frame - which essentially put a browser inside a browser - Shaver questioned whether Google's plug-in would send netizens into a state of confusion. "The user’s understanding of the web’s security model and the behaviour of their browser is seriously hindered by delegating the choice of software to the developers of individual sites they visit," he said.
"It is a problem that we have seen repeatedly with other stack-plugins like Flash, Silverlight and Java, and not one that I think we need to see replayed again under the banner of HTML5."
Google with NaCl
Shaver tells The Reg that Native Client is a slightly different case, but he still sees Buckler's concern. And he still prefers HTML5. "[Native Client] is not as clean when - in terms of what the user's mental model is - compared to HTML5, which is what we would prefer," he says.
"[Native Client] is not quite a problem to the same degree as [Google Chrome]. It's not as problematic structurally. But if you can implement a complete web stack with standards without having to mix-and-match components, I think it's better for web users."