Eratosthenes: Radically Refactoring the Web Jon Howell, Bryan Parno, John R. Douceur, Microsoft Research Abstract of evolving complexity. On the Internet, application Web browsers ostensibly provide strong isolation for providers, or vendors, run server-side applications over the client-side components of web applications. Unfor- which they exercise total control, from the app down tunately, this isolation is weak in practice; as browsers to the network stack, firewall, and OS. Even when ven- add increasingly rich APIs to please developers, these dors are tenants of a shared datacenter, each tenant au- complex interfaces bloat the trusted computing base and tonomously controls its software stack down to the ma- erode cross-app isolation boundaries. chine code, and each tenant is accessible only via IP. The We reenvision the web interface based on the notion strong isolation among Infrastructure-as-a-Service data- of a pico-datacenter, the client-side version of a shared center tenants derives not from physical separation but server datacenter. Mutually untrusting vendors run their from the simplicity of the execution interface. code on the user’s computer in low-level native code con- This paper extends the semantics of datacenter rela- tainers that communicate with the outside world only via tionships to the client’s web experience. Suspending dis- IP. Just as in the cloud datacenter, the simple semantics belief momentarily, suppose every client had ubiquitous makes isolation tractable, yet native code gives vendors high-performance Internet connectivity. In such a world, the freedom to run any software stack. Since the datacen- exploiting datacenter semantics is easy: The client is ter model is designed to be robust to malicious tenants, it merely a screencast (VNC) viewer; every app runs on is never dangerous for the user to click a link and invite its vendor’s servers and streams a video of its display to a possibly-hostile party onto the client. the client. The client bears only a few responsibilities, primarily around providing a trusted path, i.e., enabling 1 Introduction the user to select which vendor to interact with and pro- viding user input authenticity and privacy. A defining feature of the web application model is its We can restore reality by moving the vendors’ code ostensibly strong notion of isolation. On the desktop, a down to the client, with the client acting as a notional user must accept responsibility for installing apps, and pico-datacenter. On the client, apps enjoy fast, reliable if an app misbehaves, the consequences are unbounded. access to the display, but the semantics of isolation re- On the web, if the user clicks on a link and doesn’t like main identical to the server model: Each vendor has au- what she sees, she clicks the ‘close’ button, and web app tonomous control over its software stack, and each ven- isolation promises that the closed app has no lasting ef- dor interacts with other vendors (remote and local) only fect on the user’s experience. through opt-in network protocols. Sadly, the promise of isolation is routinely broken, and The pico-datacenter abstraction offers an escape from so in practice, we caution users to avoid clicking on “dan- the battle between isolation and richness, by deconflating gerous links”. Isolation fails because the web’s API, re- the goals into two levels of interface. The client imple- sponsible for application isolation, has simultaneously ments the client execution interface (CEI), which is dedi- pursued application richness, accreting HTTP, MIME, cated to isolating applications and defines how a vendor’s HTML, DOM, CSS, JavaScript, JPG, PNG, Java, Flash, bag of bits is interpreted by the client. Different vendors Silverlight, SVG, Canvas, and more. This richness intro- may employ, inside their isolated containers, different duces so much complexity that any precise specification developer programming interfaces (DPIs). Today’s web of the web API is virtually impossible. Yet we can’t hope API is stuck in a painful battle because it conflates these for correct application isolation until we can specify the goals into a single interface: The API is simultaneously API’s semantics. Thus, the current web API is a battle a collection of rich, expressive DPI functions, and also a between isolation and richness, and isolation is losing. CEI that separates vendors. The conflated result is a poor The same battle was fought—and lost—on the desk- CEI: neither simple nor well-defined. Indeed, this con- top. The initially-simple conventional OS evolved into a flation explains why it took a decade to prevent text col- rich, complex desktop API, an unmanageable disaster of oring from leaking privacy information [56], and why to- complexity. Is there hope? Or do isolation (via simple day’s web allows cross-site fetches of JPGs or JavaScript specification) and richness inevitably conflict? but not XML [60]. The semantics of web app isolation There is, in fact, a context in which mutually- wind through a teetering stack of rich software layers. untrusting participants interact in near-perfect auton- We deconflate the CEI and DPI by following the pico- omy, maintaining arbitrarily strong isolation in the face datacenter analogy, arriving at the Eratosthenes archi- 1 tecture. We pare the web CEI down to isolated native • We show a small, well-defined CEI specification code picoprocesses [22], IP for communication beyond (§3) that admits small implementations (§6.1) and the process, and minimal low-level UI primitives to sup- hence suggests that correct isolation is achievable. port the new display responsibilities identified above. • With a variety of rich DPI implementations running The rich DPI, on the other hand, becomes part of the against our CEI, we demonstrate that application web app itself, giving developers unparalleled freedom. richness is not compromised but enhanced (§6.2). This proposal doesn’t require Alice, a web app devel- • We show how to replace the cross-app interactions oper, to start coding in assembly. When she writes a baked into today’s browser with bilateral protocols geotagging site, she codes against the familiar HTML, (§4), maintaining familiar functionality while obey- CSS, and JavaScript DPI. But, per the datacenter model, ing pico-datacenter semantics. that DPI is implemented by the WebKit library [55] that • We implement this refactoring (§5) and show that it Alice’s client code links against, just as her server-side can achieve plausible performance (§6.3, 6.4). code links against PHP. Because Alice chooses the li- brary, browser incompatibilities disappear. 2 Trends in Prior Work Suppose a buffer overflow is discovered in libpng [44], a library Alice’s DPI uses to draw images. Because Al- Eratosthenes is not the first attempt to improve web ice links WebKit by reference, as soon as the WebKit app isolation and richness, and indeed prior proposals developers patch the bug, her client code automatically improve on one or both of these axes. However, they do inherits the fix. Just like when Alice fixes a bug in libphp not provide true datacenter-style isolation — they imple- on her server, the user needn’t care about this update. ment, often for compatibility, part or all of the aggregate Later, Alice adds a comment forum to her application. web API inside their trusted computing base (TCB). Including user-generated HTML has always been risky, At the architectural level, our proposal employs the often leading to XSS vulnerabilities [26]. But Alice principle of a native, low-level interface to execution and hears about WebGear, a fork of WebKit, that enhances I/O, similar to the Exokernel [27]. The Exokernel, how- HTML with sandboxes that solve this problem robustly. ever, aimed to expose app-specific performance oppor- WebGear can innovate without imposing client browser tunities; in Eratosthenes, the low-level interface serves upgrades; Alice simply changes her app’s linkage. to maximally enforce isolation boundaries among ven- Ultimately, independent development of alternative dors. The Exokernel project said little about how to re- DPIs outpace WebGear, and Alice graduates to a .NET store inter-app functionality in a principled fashion. or GTK+ stack that is more powerful, or more secure, or Below, we discuss web-related proposals based on more elegant. Alice chooses a feature-full new frame- their effects on the web API. work, while Bob sticks with WebBSD, a spartan frame- 2.1 Better Browsers for the Same API work renowned for robustness, for his encrypted chat Chrome and IE8+ both shift from a single process app. Taking the complex, rich semantics out of the model to one that encapsulates each tab in a separate host CEI gives developers more freedom, while making cross- OS process. This increases robustness to benign failures, vendor isolation—the primary guarantee established by but these modifications don’t change the web interface— the client—more robust than today’s web API. multiple apps still occupy one tab; hence isolation among Via the pico-datacenter model, we develop a CEI with: web apps is still weak. OP’s browser refactoring [17] is • a minimal native execution environment, also constrained by the web API’s complex semantics. • a minimal notion of application identity, Given this constraint, IBOS pushes the idea of refac- • a minimal primitive for persistent state, toring the browser quite far [48]. It realizes the idea of • an IP interface for all external app communication, sites as first-class OS principals [23, 50], and container- • and a minimal blit-based UI semantically equivalent izes renderers to improve isolation. IBOS must still in- the screencast (VNC) model discussed above. clude HTTP to define hscheme; host; porti web prin- Such an ambitious refactoring of the web interface is cipals, and must use deep-packet inspection on HTML necessary to finally resolve the battle between rich DPIs and MIME to partially enforce the Same-Origin Policy and a simple, well-specified CEI.