Google plugs PC power into cloud computing

Even at the cutting edge of cloud computing, Web-based applications can be frustrating to write and to use.

Spreadsheets can't sort data well, there are lags between mouse clicks and the program's response, graphics look Mickey Mouse rather than lavish. But Google, among the most aggressive cloud computing advocates, is trying to address some of those shortcomings.

The company has released experimental but still very much real software that brings in some of the power of the PC, where people often use Web applications. Google Native Client--first released in 2008 but updated with a new version Thursday--is a browser plug-in for securely running computationally intense software downloaded from a Web site. And on Tuesday, Google released O3D, a plug-in that lets Web-based applications tap into a computer's graphics chip, too.

The projects are rough around the edges, to say the least. Native Client--NaCl for short--is more security research project than usable programming foundation right now, and O3D exists in part to try to accelerate the arrival of some future, not necessarily compatible, standard for building 3D abilities into Web applications.

But both fundamentally challenge the idea that Web apps necessarily are stripped-down, feeble counterparts to the software that runs natively on a personal computer, and they come from a company that has engineering skill, a yen for moving activity to the Internet, and search-ad profits that can fund projects that don't immediately or directly make money.

"There are things you can do in desktop apps that you can't do in Web apps. We're working very hard to close that gap, so anything you can do in a desktop application you can do safely and securely from a Web application," said Linus Upson, a Google engineering director.

So what actually could be done with the technology if it matures enough for mainstream use? Anything from photo editing to video games. Google has demonstrated Native Client by running the Quake first-person shooter video game and a fractal graphics explorer. The company conceives of it more as a helper for existing Web applications than as a full-fledged environment for creating and running programs, like Sun Microsystems' Java, Adobe Systems' Flash and Flex, or Microsoft's Silverlight.

Native Client piqued the interest of Avi Muchnick, chief executive of start-up Aviary, which today uses Flash to run its online photo editing and illustration tools.

"Google Native Client would open up the floodgates for Web-based application development, because in theory people could easily repurpose existing programs that were originally written for the desktop," Muchnick said. Instead of programmers trying to learn Flash application programming, "they could use a language like C++ that they are already experienced with."

Native Client tackles security
The promise of Native Client is giving Web applications all the power of x86 processors from Intel and Advanced Micro Devices, including low-level features to accelerate multimedia chores and to juggle multiple threads of instructions at the same time. But the challenge is unlocking that power without giving the keys away to computer attackers.

"It's easy to run native code on computers. The hard part is being able to do so securely," Upson said. And Google is being cautious about Native Client in light of the risks of giving software low-level access to a computer.

Indeed, Google engineers call Native Client security software before they call it anything else. Google engineering manager Brad Chen heaped praise on the discovery of the first Native Client vulnerability. Likewise, there is a contest to find Native Client security holes, with cash prizes of $16,384 (that's 2 to the 14th power), and the latest Native Client release includes four fixes from contest entries even though the contest doesn't close until May 5.

"We're hoping to reveal our security problems before the system gets anywhere near an end-user desktop," Chen said. Native Client is open-source software, too, which Google hopes will help the security community dig into the project.

Security limits
When installing software through conventional means--from a CD-ROM or installation file you specifically choose to download, for example--you have control over what's running natively on your computer. You're the security gatekeeper. But security is harder when you visit a Web page that runs software automatically.

Browsers today can run applications using a programming language called JavaScript, whose security is maintained through restraints that block programs from reading files on your computer or getting access to the memory used by other programs, for example. The problem, though, is that the separate engine required to run the JavaScript programs makes the language slow compared with native software.

Native Client has constraints of its own. It's geared to give the browser a secure programming foundation that runs software at native speeds directly on the computer's hardware, but it imposes to two levels of security to modules of code downloaded from the Web.

First, an "inner sandbox" scrutinizes the instructions contained in the module, which programmers must create using specially modified programming tools that ensure the module can be scrutinized before running. "Our validator can...insure that the executable includes only the subset of legal instructions, disallowing unsafe machine instructions," according to a Google Native Client research paper (PDF). This stage also takes advantage of a feature built into 32-bit x86 chips called segmentation that keeps programs from making improper use of memory.

The idea, called static analysis of binary code, isn't new, but it hasn't made its way widely beyond academia. "It's been a topic of interest in the research community for last 15 years," Chen said. "It was in part our judgment that it had been sufficiently understood and studied that we could incorporate this."

The second "outer sandbox" provides a second layer of security. It monitors the code as it runs, permitting it only to make a small variety of requests to the operating system.

"The basic approach is sound and can be made to work in principle," said Internet security researcher Edward Felten, a professor of computer science and public affairs at Princeton. "They're trying to hit a sweet spot where they provide the performance of native code with strong security guarantees. Native Client is really interesting approach to trying to do that."

Recycled software
One of the promises of Native Client is the reuse of existing software, though modifications are required to ensure adherence to the security rules.

"It took two days to port Quake source code, which had more than 100,000 lines," Chen said.

Native Client software modules must be created through a specially modified version of the open-source compiler GCC, which converts the programs that humans write in understandable languages into the computer-comprehensible binary modules.

However, once created, the same software module can be run through Native Client on Windows, Linux, or Mac OS X on an x86-based computer.

It's this attribute that appeals to programmer Mark Seaborn, a non-Google programmer who has successfully contributed to the project. He's been working on a Native Client version of a major supporting library used by GNU and Linux. "That could bring open-source software from GNU/Linux to a wider audience, because it could then run on Windows under NaCl without needing to be ported to Windows," Seaborn said.

Adobe's Alchemy
Google isn't the only one eyeing the vast amount of software already written in C or C++ that could be brought to Web applications. Adobe's Alchemy research project has a similar end, though instead of running the code natively as Google does, it converts it into the JavaScript cousin called ActionScript used by Adobe's Flash and AIR software foundations.

Alchemy, too, can handle computationally intense chores, such as running the Ogg Vorbis audio format decoder that's not natively supported in Flash, said Tom Barclay, a senior member of Adobe's Flash Player team. And Adobe demonstrated Quake with Alchemy. "The idea with Alchemy is to let people reuse logic and libraries," Barclay said.

Google Native Client has a performance advantage over Alchemy, Barclay acknowledges, but Alchemy has a big advantage of its own: it's not limited to x86 processors. While x86 dominates on desktops and laptops, it's relatively rare for smaller computing devices.

"For us it's more important we're completely consistent across architectures and browsers and operating systems," Barclay said.

Google does plan eventually to extend beyond 32-bit x86 chips to support other architectures, including ARM designs widely used in phones and 64-bit x86 chips that new PCs come with, said Henry Bridge, a Google product manager. "We believe the Web should portable, and don't intend to change that with Native Client. We are evaluating a number of alternatives for supporting machines without hardware segmentation, but since we haven't made any decision yet there isn't much more I can say on what we will eventually do," he said.

O3D makes its mark
Whereas Native Client deals with software that runs on the central processing unit (CPU), O3D deals with the graphics processing unit (GPU). Computers these days typically come with both, but Native Client and O3D are separate projects for now, so programmers will have to deal accordingly.

"We think the possibility of combining CPU and GPU computing would be great," Bridge said. "At present they don't actually work together, but we're looking at getting them to work together in the future."

Where the greater tension lies is in the best way to bring 3D to Web applications. Mozilla, the organization behind the Firefox browser, shares Google's ambition to have 3D Web applications and is working on a lower-level 3D interface in conjunction with the Khronos Group that oversees the widely used OpenGL 3D technology.

Mozilla evangelist Chris Blizzard suggested in a blog post that the suddenly accelerating JavaScript performance means a lot of higher-level work needed for 3D rendering can be handled in JavaScript from the Web page rather than through a plug-in module.

"Much of the work that Google happened before browsers got as fast as they have, so there's a good reason why they felt that they needed to implement so much of the code as native code and deliver it as a plug-in," Blizzard said. "JavaScript engines have gotten a lot faster since they started their plug-in and we think that it's time that we start using them."

Bridge, though, replied on Blizzard's blog that JavaScript just isn't fast enough for some 3D tasks. "Javascript is getting faster all the time and we love that, but until someone builds some apps it'll be hard to know what's fast enough," Bridge said. However, he agreed that plug-ins are undesirable, saying that Google hopes to build support for both Mozilla's technology and for O3D directly into its own browser, Chrome.

Overall, though, Mozilla and Google are more allies than rivals. Both want to advance Web application technology, and the main competition is a continuation of the status quo with its tall barrier between Web-based applications and native software.

"Web apps have been limited by mostly having to be written in a slow and slightly weird language, JavaScript," Seaborn said. Google's new technology, though, "can narrow the gap between Web apps and native applications."