In search of better Web security: Three approaches

Tahoma: Box it and block it

First, let's look at Tahoma. The June 2006 paper outlining Tahoma was, like the bustling Port of Tacoma itself, rather focused on moving around stuff in secured containers. (Hey, why not -- otherwise they meant the other Tahoma, which is part of the Rainier volcano that slid down and is currently affixed to the mountainside like a giant blister.) The paper advocates for a "browser operating system" (BOS), a trusted computing layer on which browsers would execute -- in essence, a virtual machine for browsers.

The model had three significant features. First, it ran each client-side component of a browsing session in its very own VM. Second, it treated Web applications as first-class objects, which users explicitly install and manage and otherwise control, meaning no downloaded surprises sneaking in behind the scenes. Third, Tahoma would allow Web publishers to specify which URLs and other resources the browser may access; a fouled browser would, in that case, not be able to spread its infections. Those features correspond generally to three key architecture principles: Don't trust Web apps, don't trust Web browsers, and trust the user to identify and manage downloaded applications.

Earlier sandboxing efforts took into account that browsers should be treated as sketchy, but Tahoma advanced the thinking by isolating even the applications from each other. Trust nothing... except the BOS, and your users' good understanding of what they're downloading.

The paper notes that "the browser... has transcended its original role to become a de facto operating system for executing client-side components of web applications." Correct, and the next significant proposal -- OP -- would expand on that theme.

OP: Burn it down and start again

Entering the scene in May 2008, OP's authors stated that "our overall design approach is to combine operating system design principles with formal methods to design a more secure web browser by drawing on the expertise of both communities." To that end, they conceived of a browser sliced into four subsystems (user interface, Web page, storage, network), which would communicate amongst themselves with simple, explicit commands and would be managed by a browser kernel.

Like the writers of the Tahoma paper, the OP authors described three new security features their strategy brought to the table. First, they developed security policies with sufficient flexibility to allow for plug-ins, even if the plug-in's writer didn't choose to incorporate good security practices (or if the plug-in was compromised by an attacker). Second, the researchers cast their eyes upon the address bar and figured out how to make sure it always displayed the correct URL -- no trickery allowed. Third, they incorporated forensics, building into the kernel auto-log capability that could improve postmortem analysis of a successful or attempted attack. And the Tahoma writers likewise had three guiding principles: prevent browser-based attacks to the greatest possible extent, contain successful intrusions and limit the damage, and provide the ability to recover from successful attacks.

OP and Tahoma had different architectures but shared many design principles. In fact, noted the OP authors, "these two architectures are complementary; one could imagine OP using Tahoma to provide even stronger isolation." And bridging the gap to the next paper, in the acknowledgments section of their treatise, the OP authors express thanks for funding received by the Internet Services Research Center of Microsoft Research, from which eventually came...

Gazelle: Support and balance

The Gazelle paper debuted in February 2009, just before Microsoft's TechFest event, but there wasn't any Gazelle display tucked among the exhibits. It wasn't waiting for IE8's debut, either; when asked, IE senior director Amy Barzdukas acknowledged that some of the thinking that went into Gazelle also provided the IE team with inspiration but that it's "yet to be seen how [Gazelle] is incorporated" into upcoming versions of IE.

Gazelle advanced on Tahoma and OP, not to mention the new breed of browser architectures (IE 8, Google Chrome), by giving the browser kernel exclusive control over security protection and system resources. The kernel now runs as a separate OS process and interacts directly with it, leaving subsystems with a limited set of calls they may pass back. Like OP, it incorporates flexibility for plug-ins.

It also incorporates pre-existing browsers; the Gazelle prototype described in the paper was IE-based. Nonetheless, the authors reported some interesting new questions coming to the fore, including display protection and legacy protection for cross-origin script source. (OP was as mentioned its own browser; Tahoma incorporated a Xen VM on Linux and the Konqueror browser.)

Gazelle's tribe also ran headlong into a core balancing act familiar to much of Microsoft: security versus backward compatibility. "In our browser design," said the researchers, "we take the general stance that security [as managed by having the kernel exclusively manage resource protection and sharing] comes before backward compatibility. We will not trade significant security risks for compatibility. Nevertheless, we will also not settle on a design that breaks many parts of the web to secure just a few sites."

And now?

Gazelle's research team is already back to work, pondering resource allocations that were flagged in the February paper as requiring further study. Will the next advance in browser thinking come from Microsoft? Will, say, some yet unwritten paper at some other research facility cause a major change of direction? Maybe, but for now the trend appears to be to make security gains while diminishing the amount of initiative required by the end user.

(Fetching image of popcorn kernels by Andrew Butko, via Wikimedia Commons.)