The 10-Kilobyte Web Browser Jon Securityhowell, Bryan Parno, and John R

The 10-Kilobyte Web Browser Jon SECurityHowell, Bryan Parno, and John R. Douceur

Jon Howell is re-envisioning the n theory, browsing the Web is safe: click a link, and if you don’t like what delivery of client applications, you see, click “close” and it disappears forever. In practice, this guaran- building a large scale, tee doesn’t hold, because the browser is complex in both implementa- consistent distributed name I tion and specification. We designed and built an alternate Web app delivery service, building formally model in which the client-side interface specification and code—the pieces verified software, and improving verifiable computation. [email protected] that replace the browser—are extremely simple, yet can run applications even richer than today’s JavaScript apps. This article describes how we achieve Bryan Parno focuses on this goal, and suggests a path forward into a future free of today’s bloated protocols for verifiable browser interface. computation and zero- knowledge proofs, building Today a Web browser is a 100 MB operating system. Most of those megabytes interpret practical, formally verified JavaScript and render images, but the browser’s most important job is to provide the user secure systems, and developing next- with the ability to visit different Web sites safely, confident that merely viewing one Web site generation application models. won’t have any effect on any of the other sites she uses and relies on. Reliable isolation is best [email protected] achieved in a simple design. The ideal Web browser would be a VNC viewer: each site renders its own content entirely independently, and the only job of the client machine is to show the John R. Douceur is interested various pixels to the user. in the design of distributed Of course, real browsers don’t have such a simple specification. They’re vastly more compli- algorithms, data structures, cated, including HTML, DOM, CSS, JavaScript, JPG, PNG, and a complex specification for and protocols, and in the how various applications might interact with one another. This complexity forms a vulner- measurement, evaluation, and able surface, and hence real Web browsers don’t actually succeed in isolating different pages; analytical modeling of systems and networks, users are cautioned to avoid “dangerous” links lest their browser be compromised. with particular focus on statistical analysis and simulation. [email protected] This ideal VNC pixel browser may seem absurd at first, but clearly it gets isolation right. You might complain that the performance stinks because it depends on a fast, available network, but we can fix that by allowing each site vendor to borrow a little virtual machine on the client; think of it as a pico-datacenter. That VM is strongly isolated from the other sites’ VMs, just as customers in a real datacenter, say of a cloud-hosting provider, are isolated from one another. In this new model (Figure 1), the specification of the browser is tiny and robust. Without a simple, clear specification, isolation is unachievable. With a clear specification, like this VM+VNC analogy, seeing how isolation can be rigorously maintained is easy; we push all the challenges of deciding how sites should interact with one another to the sites themselves. Promiscuous sites can still share cookies or engage in risky, CSRF-prone behavior (e.g., host- ing user-supplied content), but cautious sites (e.g., bank Web sites) now have the control to reject those complex interactions. The proposal of a virtual machine for execution and VNC for displaying pixels gives an intuition for how simple the interface can be, but we can go even simpler. We propose a minimal client execution interface called a picoprocess. A picoprocess is native code running in a hardware address space. It can allocate memory and threads, use futexes to schedule threads, read a real-time clock, and set a real-time alarm. All communication—to remote servers or to neighboring processes—is via IP; thus, an attacker can’t do anything more threatening on the client machine than it could do from a server. (An attacker might relay IP attacks through its presence on a client, but the client’s IP packets enter the Internet outside

6 December 2013 Vol. 38 No. 6 www.usenix.org SECurity The 10-Kilobyte Web Browser

Figure 1: The current, the ideal, and a new way to browse the Web any firewall, so the relay doesn’t gain any privilege from the cli- but it can bring those semantics to classic desktop applications, ent’s IP address or network position.) The client provides a source like the GIMP. When the plan is realized, your Webmail provider of randomness to enable the app to encrypt its messages over IP. might be based on real Outlook and you might edit documents Finally, the app displays its content by using its own libraries to with MicrosoftWord.com or LibreOffice.org: solid desktop app render to an off-screen bitmap, then asking the client to paint a code supported by its site rather than by the end user. rectangle of pixels on the screen, semantics as simple as VNC. Our Embassies paper [1] proposes this application delivery in This minimal interface replaces the role of the VM described detail, discussing the tradeoffs consequent in shifting complex- above. Because it’s even simpler than a conventional VM, the ity from clients to applications. Our USENIX paper [2] shows interface can be implemented easily on any host, from desktop how these complex apps can be repackaged to run inside the OSes to native microkernels. On Linux, for example, the picopro- constrained picoprocess; source code is available [3]. cess is a Linux process, blocked from making Linux system calls by one of several mechanisms: kvm, ptrace, or filtering system How Do We Get There from Here? calls down to read and write on a single open file handle to a The overall vision involves reconsidering several of our assump- monitor process. tions about the roles, responsibilities, and relationships that make up today’s Web software ecosystem. Rather than end users Despite this tiny client picoprocess, the ability to run native selecting a JavaScript implementation (“download a fast new code means the app itself can provide glorious complexity. The browser!”), site vendors will choose their client-side software GIMP photo editor and the AbiWord word processor run in this stacks the same way they choose today among Python, Ruby, and container [2]. We also run a WebKit browser, to show how the PHP on the server side. Such an ambitious change may need to trusted complexity of a conventional HTML browser can be happen in small steps. repackaged as safely isolated rendering code. A key step on the way to Utopia is the shift from specifying This idea is ambitious: we’re describing a substantial refactor- client-side software in Web 2.0 (the complex amalgamation of ing of the Web, shifting much responsibility from the browser JavaScript, DOM, CSS, and so on) to specifying it as native code (and the user) to the vendors that create the applications, so that that interacts through primitive low-level interfaces, such as visiting a site is no longer a risky proposition. But the ability to painting raw pixels. It’s an important step because it opens the send binary code rather than JavaScript means the idea goes door to shifting rendering components inside each application. farther: it not only realizes the “safe click” promised by the Web, www.usenix.org December 2013 Vol. 38 No. 6 7 SECurity The 10-Kilobyte Web Browser

Figure 2: Three applications that currently run in an Embassies picoprocess But it’s also a step that’s compelling all by itself. The Xax [4] and Native Client [5] projects, both introduced in 2008, showed that delivering binary code to the client and executing it safely is fea- sible. Those systems were interesting enough to let us send down interesting components: Doom on NaCl, or PDF and OpenGL renderers on Xax. Going beyond components to full applications exposes big opportunities. We can already package up GIMP and make it a Web app. We can do the same for the Gnumeric spreadsheet; add a bit of “cloud’’ and you have made an open-source alternative to Google Docs’ spreadsheet. We can fit KDE Marble (a spinning globe) into a picoprocess; that is the foundation of a Google Earth alternative that doesn’t require a trusted plugin. The opportu- nity to deliver rich apps is exciting in itself, even before we reach the ambitious goal of gutting the browser.

Figure 2a: GIMP in an Embassies picoprocess Challenges to Delivering Rich Apps This goal is within reach. We have the technology; however, three tasks remain. First, we need to settle on a suitably shaped native code container. Second, we need to publish a picoprocess browser plugin. Third, we need to wrap up cool apps and publish them as Web apps.

How the Native Code Container Affects Deliverability We said above that Xax delivered fairly modest stacks of librar- ies. Xax suffered from a practical burden: a high cost of modify- ing libraries and applications to run in the new environment. The Xax system replaced the ubiquitous glibc with a patched- together uclibc. In practice, that broke some libraries, and required linking others statically rather than dynamically. This approach worked only for short stacks of libraries. As we tried to enlarge the library stack, each new package required a new effort to disassemble its build system, and some software couldn’t even Figure 2b: AbiWord in an Embassies picoprocess conceive of being built as a static library. These are mundane concerns, but they proved a practical barrier to our ambitions of porting rich desktop apps. NaCl has encountered similar challenges, for similar reasons. NaCl’s isolation mechanism requires modifying the compiler’s code generation step to produce code that NaCl can verify is safe. This requirement implies perturbing the build process (and often the link steps) of each package. We suspect that the NaCl team encountered a mundane but tedious and expensive burden much like the one that affected our Xax development. So the choice of isolation container can have a profound effect on the ease of migrating apps to the new environment. NaCl’s choice of verification based on software-fault-isolation (SFI) is driven by a desire to attach untrusted libraries onto the side of an existing browser, right inside the same process. For our ambi- Figure 2c: WebKit in an Embassies picoprocess tions, this objective is a red herring: even today’s NaCl libraries don’t need tight coupling with the browser; rich apps will stand

8 December 2013 Vol. 38 No. 6 www.usenix.org SECurity The 10-Kilobyte Web Browser further alone; and, ultimately, we’d like to see the browser disap- Whereas conventional browsers include caching behavior, pear entirely. Because it doesn’t offer intra-process isolation, the Embassies apps control their own bootstrap and caching. An app picoprocess can exploit MMU protection, and hence provides a can fetch its 100 MB of program image from any cache on the familiar execution environment for existing code. Internet and then check its hash to ensure they are the right bits. That cache can be an untrusted app on the same machine, obviat- Still, that decision wasn’t enough to make porting easy in Xax. ing the need for network connectivity. The local cache can trans- We made two fine-grained changes from Xax to Embassies mit the image in a single IPv6 jumbo frame, making app start fast; that worked out well. The first was that, where Xax allowed the we see start time overheads of ~100 ms. Thus “sending big apps” application to control its address space layout, Embassies only is only an intuitive abstraction borrowed from today’s Web; in allows the app to ask for how much memory it needs, not where it deployed Embassies, it’s fast and works when disconnected. goes. This actually increases the burden on the app—the execut- able must be position-independent—but it makes implementing Once the app is running, native code enables performance better the host much easier. In Xax, each new host added weird new than JavaScript. The picoprocess’s isolation comes from paging address-space restrictions; in Embassies, this problem disap- hardware, and hence introduces no overhead; CPU-intensive GIMP peared entirely. rotations are just as fast inside Embassies as on desktop GIMP. More importantly, the main reason we couldn’t use glibc or dynamic Delivering Cool Apps libraries in Xax was that we had no support for the x86 segment With an appropriate container available as a ubiquitous plugin, registers, used for thread-local storage (TLS). That meant we had to it’s time to start packaging desktop apps as Web pages. Our ATC compile all components with --no-tls, and we couldn’t find a way to ’13 paper [2] (and published code [3]) lays out how to achieve this use dynamic linking without TLS. The x86 segment-as-TLS is a packaging, showing it working for lots of apps, from a spread- goofy hack in any case; it uses deprecated hardware to compen- sheet to an interactive 3D globe map. These apps need a little sate for the architecture’s tiny register set. Because contempo- modification to make useful Web sites: for example, they need rary operating systems rely on paging for memory protection, plumbing so that saving a document routes the content to client- this (ab)use of segmentation hardware has no security risk. By or server-side Web storage. adding it to the Embassies picoprocess x86 specification, we’re able to use standard glibc, conventional shared library linkage, The long-term vision is an exciting one: it promises finally to and, hence, just about every package as is, with binary compat- make browsing “safe,” and broadens browsing to include both ibility. (This whole discussion is moot on any other, sane archi- Web apps and desktop apps. Even if you don’t yet buy that vision, tecture, where TLS just uses a conventional program register.) the first step down the road is exciting all by itself: delivering all our favorite desktop apps as easily as clicking a link. The result—the Embassies specification for a native code container—is a spec to which a wide variety of rich apps can be ported with little effort. We’ve ported AbiWord (word proces- References sor), Gnumeric (spreadsheet), Gnucash (accounting), Midori [1] Jon Howell, Bryan Parno, and John R. Douceur, “Embas- (WebKit-based HTML renderer), GIMP (raster graphics design), sies: Radically Refactoring the Web,” USENIX Symposium Inkscape (vector graphics design), and Marble (3D globe). At the on Networked Systems Design and Implementation (NSDI), same time, the container is small, well-specified and secure, and awarded “Best Paper,” April 2013. practical to implement on any host platform. [2] Jon Howell, Bryan Parno, and John R. Douceur, “How to Run POSIX Apps in a Minimal Picoprocess,” USENIX A Browser Plugin Annual Technical Conference (ATC), June 2013. Now that we know what shape the container should be, achiev- ing the initial step of delivering rich apps as Web apps is within [3] http://embassies.codeplex.com/. reach: we need to implement the container as a plugin for the [4] John R. Douceur, Jeremy Elson, Jon Howell, and Jacob R. popular browsers, and test it for security. Lorch, “Leveraging Legacy Code to Deploy Desktop Applica- tions on the Web,” USENIX Symposium on Operating Sys- Performance tems Design and Implementation (OSDI), December 2008. We’ve described this new model using a strong analogy to the Web, to appeal to its “safe click” semantics. That doesn’t mean [5] Bennet Yee, David Sehr, Gregory Dardyk, J. Bradley we have to keep the Web’s online requirement, or that we have to Chen, Robert Muth, Tavis Ormandy, Shiki Okasaka, Neha fetch our (now 100 MB) apps every time we open a site. Narula, and Nicholas Fullagar, “Native Client: A Sandbox for Portable, Untrusted x86 Native Code,” IEEE Symposium on Security and Privacy, May 2009. www.usenix.org December 2013 Vol. 38 No. 6 9