Google Sandboxing Tries to Make Browsing Safer

When you've got as much money as Google, one thing you can do is throw it at projects you believe in. Google seems to believe in sandboxing as a security technique, and a lot of what it's doing is innovative.

Google seems to be very interested in the concept of sandboxing. I count three
separate efforts the company is involved in. Who knows, they may actually
amount to something useful.
The Chrome browser is built around a sandboxed architecture in which browser
applications are locked down using Windows-specific features such as Job
objects and restricted tokens. I
wrote about this at length when Chrome debuted. It's not especially
innovative, but it's a step in the right direction.

Google bought GreenBorder
last year, a company that uses virtualization to sandbox programs and
specifically browsers. There hasn't been any news about this that I've seen
since the purchase, but the basic point is the same: Prevent anything that goes
wrong in the browser from affecting the rest of the system.

The newest and probably most interesting sandbox is the Google Native Client, known
casually in the company's docs as NaCl. (I'm not sure if the "salt"
reference has any meaning.) What is NaCl? Many of the quick reactions to it are
miles away from what I got out of Google's
white paper on the technology. (The white paper seems like a very honest
explanation of the technology to me, even if some of the writing is really
bad.)
Some wrote that it's a new ActiveX-an easy mistake, perhaps, based on a very
superficial read of it as a way to run native code inside a browser, but the
similarities are only superficial. NaCl is designed with a very different
philosophy than ActiveX, which put no real restrictions on what the code in the
object can do, and whose only security feature is support for digital
signatures. NaCl has a sandbox, and a very restrictive one, more about which I
will write below.
Some wrote that NaCl is a harbinger of a Google operating system, and this
seems like a real stretch to me. NaCl is a fairly primitive feature; if the
operating system is the gorilla, NaCl is probably just the banana. (Of course,
Google may be writing other parts of Kong at the same time.) I think it's much
more plausible to view NaCl as a way for the company to make code running on any
operating system in any browser safer and more reliable.
NaCl is a run-time environment for native code to run inside a browser, any
browser on any operating system that runs on an x86 processor. It will probably
appear as a plug-in for Firefox and an ActiveX control for IE. Applications
that run in this environment, called modules, are heavily restricted: Many x86
instructions are prohibited, and there is no calling allowed into the host
operating system.
Other important features, like hardware exceptions, are disallowed, and this
is an interesting symbol of the primitive programming environment. Posix file
I/O is provided; I'm not sure if that's enough for everyone. NaCl does support
C++ software exceptions.
NaCl itself provides some system services through NPAPI (the Netscape Plugin
API) and a "service run-time"
interface that provides memory management, thread support and other such
features. There are actually two sandboxes, an "inner-sandbox" which
uses static x86 code analysis and x86 segmented memory to block dangerous
actions and force safe techniques onto programs.
Yes, you read that right: segments. They're actually bringing back the whole
segment:offset thing and far jumps that we thought went away with 32-bit code.
This will likely send many programmers to the windows on high floors, and I'm
not entirely clear on why it's worth adding a fair amount of complexity. (In
fact, it's the use of segmentation that makes support for hardware exceptions
impossible.) You can all read the white paper and explain it to me.

Larry Seltzer has been writing software for and English about computers ever since,much to his own amazement,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.