The browser's role is ever increasing. It already has become far more than a mere tool for accessing information. Today we use it to communicate, to collaborate, and to interface with applications. And if Google has its way, we'll soon be able to use it to chalk up a few righteous frags, too.
Last week, a team of Google engineers demonstrated a copy of Id Software's classic first-person shooter Quake running within a browser window at a frame rate comparable to an OS-hosted copy of the game.
How did they do it? Simple. The Google Native Client is a new set of components that allows Web browsers to download and execute native x86 code. It's not an emulator, and it's not a virtual machine. The code runs on the actual processor with access to memory and system resources and negligible loss of performance. It even gives browser-based apps access to modern, accelerated CPU instruction sets, such as SSE.
Just how crazy are these guys, anyway?
Beyond the limitations of the browser
The natural comparison is to Microsoft's ActiveX technology -- and to critics, it's not a flattering one. ActiveX controls allow developers to extend the capabilities of Internet Explorer by creating components that can access native Windows functions. But because ActiveX's security model is largely based on trust, users can easily be tricked into installing components that compromise system security. As a result, ActiveX is now a leading source of malware attacks on the Windows platform, and many security experts recommend that it be disabled.
There have been plenty of other attempts to extend the capabilities of the browser in ways that don't compromise security. The Java applet technology was among the first. Most rely on some kind of specialized programming language executed with or without the aid of a virtual machine.
But the problem with these technologies is that they invariably sacrifice performance for security's sake. That won't do for the use cases Google envisions: Not just games, but computation-intensive processes like ray tracing, image manipulation, and distributed calculation. The idea is to take advantage of the native performance of the CPU for problems where traditional, browser-hosted technologies won't suffice.
Modern browsers already include a mechanism for executing native code in the form of plug-ins. But according to Google's research paper, this route is no better than ActiveX. Experts and end-users alike view plug-ins with distrust, which seriously limits their effectiveness.
A sand castle
Google claims that its Native Client improves upon any of these past technologies by building a "sandbox" security layer around native code downloaded from Web sites. You can think of it as a kind of "virtualization lite" -- except that Native Client avoids the overhead of full-blown virtualization environments such as VMware by placing strict limitations on what kind of code is allowed to run.
As such, the notion that Native Client will execute unmodified native x86 code is a little misleading. While C source may indeed run without modification, you'll need to compile it with special versions of the Gnu C compiler and its related tool chain before it will run in the Native Client. Programs and libraries written in hand-coded assembly language will almost certainly require patches.
Native Client's cleverest security hack is to limit memory access using 80386 memory segmentation. Each process is assigned its own unique memory address space, rendering it impossible for malicious code to attack memory used by the OS or other processes. To further reinforce this, certain processor instructions and system calls are banned, the code must handle returns from subroutines using a specific method, and modules running in the Native Client can only communicate with the world outside its sandbox through a provided set of APIs.
To make sure code follows the rules, Native Client relies on static source code analysis to spot security defects and potentially harmful routines before any instructions are executed. According to Google, the rules it enforces on code at compilation time make disassembling and analyzing Native Client binaries a breeze, and the overhead imposed by this verification pass is minuscule compared to the overhead of actually downloading the component.
In addition, Google's engineers are still working on adding a second, "outer" sandbox that will trap malicious behaviors that escape the code verification and memory protection layers.
Crazy cool
It's a sound idea with a lot of promise. Given the pedigrees of Google engineers, Native Client may yet prove to be one browser extension idea that's so crazy that it just might work.
Of course, there are still outstanding questions and issues to be ironed out. Just for starters, while it's true that the x86 instruction set is available on a wide range of computers -- including PCs and modern Macs alike -- this method leaves many handheld devices in the cold, including those based on Intel's ARM chips. Web access via such alternative devices is only expected to increase in coming years, which could make an idea like the Native Client impractical for many applications.
For the processor-intensive applications that Google envisions, however, Native Client could represent a huge leap forward. Perhaps the most pertinent question that remains, then, is whether the average computer user is ready to do the bulk of his or her computing within the browser, rather than using traditional desktop applications. Is Google's vision of browser-based computing really the future? And if so, how will the traditional software industry respond?