Google to rebuild Chrome on secure foundation

SAN FRANCISCO--Native Client, an obscure security project at Google, is about to get much more important as the foundation for Chrome, CNET has learned.

Native Client--NaCl for short--got its start as a part of Chrome as a way to run software modules downloaded over the Net safely and quickly. With the move, though, the tables will turn, and Chrome will itself become a NaCl module.

"We want to move more and more of Chrome to Native Client," Linus Upson, vice president of engineering for the Chrome team, said in an interview at the Google I/O show here. "Over time we want to move the entire browser in Native Client."

The move is a bold bet on a project that hasn't yet even been enabled by default in Chrome, much less tested widely in the real world. But if it works, Google will get a new level of security for Chrome--and for its new browser-based operating system, Chrome OS.

Inevitably, programmers introduce bugs into their products. But if Chrome is running as Native Client, those bugs aren't as big of a security problem: "It becomes extremely difficult for a bad guy to compromise your computer," Upson said.

Google is starting small, not with the whole browser, Upson said. The first part of Chrome to run within a Native Client framework is the PDF reader, Upson said. And that move is coming soon.

"It'll happen this year," Upson said.

Native Client innards
To understand Native Client, it's best to understand its chief alternative today. Web-based software today runs within the browser in JavaScript, a language that's much slower to run than native software that runs directly on an operating system.

JavaScript performance has grown by leaps and bounds in recent years, helping Google expand what can be done with Web apps such as Google Docs. But JavaScript programs aren't prepackaged to run on a particular processor the way native software is. Instead, it's written in higher-level instructions compiled on the fly into machine-comprehensible code that runs not on the hardware but instead in a virtual environment called a JavaScript engine.

There's a good reason for that approach. Running native software you just downloaded over the Web, with the full privileges of native software such as Microsoft Word or Adobe Photoshop, poses a huge security risk. It's the reason today's operating systems ask if you really want to run that installer you just downloaded: do you really trust the source? If attackers could run whatever software they wanted on your machine just because you happened to visit a particular Web site, it would be a golden age for malware.

Native Client, though, is intended to make that high-risk behavior safe with two main types of protection.

First, it confines running software to a sandbox--in fact, to two levels of sandboxes--that restrict the privileges of the software. Second, it scrutinizes the machine code instructions in advance to make sure it's not performing any of a set of restricted operations that could enable an attack--for example, writing data to the hard disk or launching new computing processes.

Special programming tools
That means not just any old machine-readable binary code will run on NaCl. Instead, a specially crafted compiler must be used to build the NaCl module without any of the offending instructions.

With Native Client, "you can run untrusted machine code, verify it doesn't do anything bad, move at the full speed of the hardware, and maintain the security model of the Web," Upson said. "Full speed" is a pretty bold claim, but Google thinks it can reach performance just a few percent shy of an ordinary native program.

Running Chrome within Native Client is one idea. Google has plenty more: decoding video, encrypting corporate data, and running the calculations of video game physics engines. With planned improvements later encompassing 3D graphics, NaCl could be better for more game technology, too.

One big problem for early versions of NaCl was compatibility, since it used native code compiled for a specific processor, Web programmers would have produce different versions for different types of chips. Initially only 32-bit x86 chips were supported, but 64-bit ones arrived later. However, ARM processors--the lineage used in virtually all smartphones today--were not.

Thus, Google created a variation called PNaCl, short for Portable Native Client. It uses software modules compiled not all the way to native instructions but to an intermediate and universal form called Low Level Virtual Machine (LLVM). The browser itself handles translation the rest of the way into the native language of the processor.

Native Client has passed at least early stages of security scrutiny, and Google is exquisitely sensitive to security issues. The fact that the company is willing to base its entire browser on NaCl is a tremendous vote of confidence for the technology.

Skeptics
But not too many others have voted publicly for NaCl. Unity, a start-up with a cross-platform engine that can be used to build video games on everything from browsers to mobile phones, is one fan. Upson insists there are other developers interested as well, but there hasn't been the level of public declarations of support the way there has been even for modestly successful new Web technologies such as WebGL.

Indeed, one major potential ally, Mozilla, isn't interested. To refresh your memory, Mozilla's Firefox is the lineal descendant of the Netscape Navigator browser from the 1990s that rattled Microsoft with its promise of new Web-based applications. Mozilla programmers took pleasure in producing a JavaScript version of an image-editing app that Google earlier had produced to show off chores that seemingly were too taxing not to be running native.

Much of the browser world today is focused on Web performance through other means. It's not just JavaScript that's getting faster: hardware acceleration is speeding up many graphics tasks, including Cascading Style Sheets (CSS) for formatting and animated transitions; Canvas and Scalable Vector Graphics (SVG) for 2D graphics; and WebGL for 3D graphics. Work on faster processing of Web page elements, faster loading of pages, more intelligent caching, Web page preloading, multithreaded JavaScript work, and other improvements are speeding up other aspects.

So with all these other high-speed Web programming options, might NaCl be left by the wayside? No, said Upson.

"It's tremendously important," he said. "The high-level [interfaces of Web browsers] keep getting faster, but they don't give you the full performance of the hardware," he said.

In addition, there's a programming reason for NaCl, he argued. A lot of people write software such as games in C or C++ that's relatively easy to port to NaCl. "You don't have to rewrite it in JavaScript," he said.

For now, though, a lot of that is vision. Upson is working hard to make it reality, though, and hopes to enable Native Client by default in Chrome.

"It's a hard problem," Upson said of NaCl. "We don't want to ship it until it's really good."