on a binary validator to isolate the OS
interface, preventing direct access to
the OS and resources such as the file
system and the network.
Despite the different implementation techniques, the idea behind Xax
and Native Client is similar, according
to Howell. “Let the software use the
processor however it likes,” he says,
“and rely for isolation on a simple bit
of hardware designed to do just that.”
Xax and Native Client are but two of
the software technologies designed to
close the performance gap and strengthen the security of Web browsers. Sun’s
Java, Microsoft’s Silverlight, and Adobe’s
AIR represent another approach to isolating untrusted modules from OS interfaces while narrowing the performance
gap with native execution. Of course, unlike Xax and Native Client, these application frameworks tend to be used mainly
as replacements for the browser-based
application environment.
Another alternative approach that is
gaining popularity is full virtualization.
Systems such as Xen or VMware aren’t
commonly used to deploy Web-based
applications, but that might change
soon. Because virtualization systems
use code-distribution formats based on
native code, they avoid the performance
obstacles of JavaScript and other similar languages. And to protect native OS
interfaces, they wrap untrusted code
in an entire instance of the OS and run
that on top of simulated hardware.
“The desire is to have some kind
of strong isolation barrier that an attack will not be able to penetrate,” says
Mendel Rosenblum, cofounder of VMware and a computer science professor
at Stanford University. “Hardware-level
virtual machines provide precisely that
high-assurance barrier yet can run existing browsers at near-native speeds.”
Rosenblum says the computer industry’s focus on low-level isolation
mechanisms is missing the larger
point about what virtualization layers
can do for performance and security,
especially as the Web evolves from a
document-delivery mechanism into an
ecosystem of interactive applications.
“The ability to run sophisticated code
safely, and with high performance on
the clients, will allow the new applications running in the cloud to support
the richer, highly interactive interfaces
users are accustomed to,” he says.
full virtualization
is an alternative
approach that is
gaining popularity.
In the meantime, despite the proliferation of technologies that aim to sidestep the performance issues associated
with running single-threaded scripts in
browsers, JavaScript remains indisputably popular among developers as the
only viable choice for programming
browsers today. While most believe it
is unlikely that JavaScript performance
will catch up to the speed of native code
execution, both Firefox’s TraceMonkey
and Google’s V8, the JavaScript rendering engine in the Chrome browser,
have received industrywide praise for
narrowing the performance gap.
“One thing we should never lose
sight of is the fact that language virtual machines are not all about straight-line speed of code and that there are
many moving parts in the system that
need to be balanced against each other,”
says Ivan Posva, a Google software engineer who developed the V8 JavaScript
implementation for Chrome. Still, he
says, V8 has narrowed the gap.
In terms of the next speed increase
that users can expect from JavaScript
rendering engines, Posva says he remains skeptical about the ability of ap-plication-specific or language-specific
hardware to offer significant improvement. “Currently in V8 there are still
many more optimizations that can be
applied on general-purpose CPUs,” he
says. “I do not think that JavaScript-oriented hardware support would be a
silver bullet.”
In addition to the performance issue, there remains the matter of security. JavaScript running in a browser
opens up the possibility for local security attacks in which a malicious application tries to elevate its privileges.
“Browser designers need to be aware
that the more control we give the third-party programmers via JavaScript, the
more control somebody malicious
could potentially have,” Posva says.
“This is not a security issue on its own,
but there is a lot more potential control
in modern, high-performance virtual
machines that can be used to exploit
an independent security bug.”
To mitigate these risks, V8 uses a
layered approach with a sandboxed
renderer. “V8 tries to minimize the attack surface by not giving total control
over the generated code for a piece of
JavaScript and by following common
practices such as marking all data nonexecutable,” says Posva. “V8 has to ensure that the policies set by the binding
layer are followed properly.”
Posva says the performance of V8
will improve regardless of whether it
is embedded in a sandboxed environment. “We had to make some design
decisions in V8 to allow it being embedded in the sandboxed renderer process within Google Chrome,” he says.
“But none of these decisions prevent a
nonsandboxed use of V8, and none of
these decisions had an impact on the
real-world performance of V8.”
That performance versatility might
become increasingly important as
browsers evolve, perhaps even to the
point where they are no longer distinguishable from the applications they
run. “In a few years,” says Microsoft’s
Howell, “I don’t think we’ll mean the
same thing by ‘browser’ that we mean
today; we’ll mean much less.” Howell
predicts that most of the functions of
the traditional browser will be rendered
moot, replaced by flexible code linked
directly into the Web sites users visit.
Howell’s prediction amounts to saying that the browser itself will become
the sandbox, more or less a simple isolation framework. “Because Xax has
such a narrow interface, and because
we can compile the browser itself for
the Xax container, you can think of Xax
as a way to virtualize the browser,” says
Howell, who maintains that treating
the host OS as something special is a
short-lived phenomenon.
“As Web applications get richer,
they’re just as important to protect as
the host OS,” he says. “If Web applications are sandboxed, users can try one
with no risk of exposing everything on
their computer.”
Based in Los Angeles, Kirk L. Kroeker is a freelance
editor and writer specializing in science and technology.
© 2009 ACM 0001-0782/09/0700 $10.00