Technology | DOI: 10.1145/1538788.1538795
Kirk L. Kroeker
Toward native Web execution

Several software projects are narrowing the performance gap between browser-based applications and their desktop counterparts. In the process, they’re creating new ways to improve the security of Web-based computing.

Most internet users expect the performance of browser-based applications to be the same as desktop applications,

do not

 

which are driven by code created from high-quality compilers and designed to run natively at the operating system (OS) level. However, several ongoing projects at Google, Microsoft, and other companies aim not only to close that performance gap, but also to eliminate some of the security weaknesses that have plagued Web browsers since the early days of the Internet.

For years, the Netscape plug-in API and Microsoft’s ActiveX have provided a way to use native code modules as part of a Web application. Along with enhanced browser functionality, these extension technologies provide full access to the OS’s file and networking interfaces. But by relying on trust rather than strong technical measures for safety, these extension technologies are vulnerable to social-engineering attacks in which users are tricked into permitting malicious operations.

One software project that challenges this trust model yet still offers native performance is Xax, developed at Microsoft Research. Xax separates native instruction execution from native OS access, leveraging legacy code to deliver desktop applications on the Web. The project’s goal is to incorporate legacy code into browser-based applications, which then run at native performance levels and rely on a security mechanism that is more flexible than language isolation.

“Rather than use a language-based isolation mechanism, why not instead use the well-evolved and ubiquitous memory management unit?” asks researcher Jon Howell, who developed Xax at Microsoft Research.

Howell and his colleagues at Microsoft Research are currently exploring

Xax running a Mandelbrot set explorer to measure performance overhead. This CPu-bound benchmark runs as quickly inside the Xax container as when hosted in a native os process, nearly 30 times faster than the fastest Javascript implementations, according to Microsoft.

 

how a Xax interface can be used to deliver not just Web extensions, but all of a Web application’s content, including the rendering functions normally provided by a browser. Realigning the client’s role in this way, according to Howell, will help make browsers more secure and lead to more flexible applications that can use new rendering frameworks without forcing developers to wait for widespread client adoption.

In theory, it is possible to deliver a new codec or a variant of an HTML renderer in Flash or JavaScript. However, the new code, including all of its

libraries, would need to compile to the special language and tolerate performance penalties. “Being able to deliver native code to the client loosens the constraints,” says Howell.

 

Different Approaches In contrast to Xax, which relies on the memory management unit for memory isolation and a kernel system-call patch to prevent OS access, Google’s Native Client takes a different approach. Using an OS-portable sandbox, Native Client relies on x86 segmentation hardware to enforce memory isolation and

IMAGE COURTESY OF MICROSOFT RESEARCh