Maverick: Providing Web Applications with Safe and Flexible Access to Local Devices David W. Richardson and Steven D. Gribble Department of Computer Science & Engineering University of Washington Abstract printers, scanners, smartphones, and GPS trackers are in- creasingly pervasive, yet browsers currently provide little Web browsers do not yet provide Web programs with support to Web applications for accessing them. The sup- the same safe, convenient access to local devices that port that does exist is limited to a handful of HTML tags operating systems provide to native programs. As a re- for accessing a small number of common device classes, sult, Web programmers must either wait for the slowly such as Webcams or microphones. evolving HTML standard to add support for the device Today, Web programmers that want to use unsup- classes they want to use, or they must use difficult to de- ported or exotic local devices must either wait for HTML ploy browser plug-ins to add the access they need. standards to evolve to include them, or they must im- This paper describes Maverick, a browser that pro- plement, deploy, and support browser plug-ins that users vides Web applications with safe and flexible access to may be reluctant to install. Such poor choices limit the local devices. Maverick lets Web programmers imple- functionality of Web applications and discourage the de- ment USB device drivers and frameworks, like file sys- velopment and adoption of new, interesting local devices. tems or streaming video layers, using standard Web pro- gramming technologies such as HTML, JavaScript, or In this paper, we describe Maverick, an experimen- even code executed in a native client sandbox. These Web tal browser that gives Web applications safe and flexible drivers and Web frameworks are downloaded dynami- access to local USB devices. Maverick takes the aggres- cally from Web servers and executed by browsers along- sive approach of removing the responsibility for manag- side Web applications. Maverick provides Web drivers ing devices and device frameworks from the host oper- with protected access to the USB bus, and it provides Web ating system and empowering the browser to execute de- drivers and frameworks with event-driven IPC channels vice drivers and frameworks alongside Web applications. to communicate with each other and with Web applica- Specifically, instead of requiring users to install USB de- tions. vice drivers into their host OS, Maverick dynamically finds, downloads, and executes Web drivers that are writ- We prototyped Maverick by modifying the Chrome ten with standard Web programming technologies like Web browser and the Linux kernel. Using Maverick, we HTML, JavaScript, or Native Client (NaCl) [24], and that have implemented: several Web drivers, including a USB directly communicate with the USB devices they drive. mass storage driver and a Webcam driver; several Web frameworks, including a FAT16 filesystem and a stream- Similarly, instead of relying on device frameworks ing video framework; and, several Web applications that within the host OS, such as file systems or video frame- exercise them. Our experiments show that Web drivers, works, Maverick finds, downloads, and executes Web frameworks, and applications are practical, easy to au- frameworks to provide Web applications with convenient thor, and have sufficient performance, even when imple- high-level abstractions. Maverick permits Web appli- mented in JavaScript. cations to communicate directly with Web frameworks, which in turn communicate with Web drivers. Maverick’s approach has several advantages. Web de- 1 Introduction velopers can add support for new USB devices and make them immediately accessible to any Maverick user and Web browsers do not yet provide Web programs with the Web application without waiting for updates to slowly same safe, convenient access to local devices that OSs moving standards bodies, browser vendors, or operating provide to native programs. Digital devices like cameras, systems. Maverick also inherits many of the safety and security benefits of running drivers in user-level, such as we showcase several applications. After discussing re- insulating the OS from driver bugs. lated work in Section 6, we conclude. Maverick addresses three main challenges: 1. Security. Maverick must isolate Web drivers and 2 A Brief Overview of USB Web frameworks to prevent access to unauthorized devices or interference with unrelated Web appli- Maverick exposes USB devices to Web drivers and appli- cations and native software. Maverick uses exist- cations. We chose to focus on USB for two reasons; first, ing JavaScript and NaCl sandboxes to contain Web it has become the predominant interconnect for most drivers and frameworks. In addition, Maverick ex- consumer devices, making it an attractive target. Second, poses a virtualized USB bus to Web drivers, grant- since USB is message-oriented, it was relatively straight- ing each driver the ability to send and receive USB forward to expose USB message transmission and recep- messages only to the devices for which it is autho- tion to JavaScript and NaCl. In contrast, we believe it rized. So that Web drivers, frameworks, and appli- would be much less natural to expose complex device in- cations can interact flexibly and efficiently, Maverick terconnects, such as PCI, that use more architecturally- provides them with protected event-driven IPC chan- dependent features like DMA and memory-mapped I/O. nels. In this section, we provide a brief overview of USB device abstractions and protocols. Readers familiar with 2. Performance. Web drivers and frameworks must be USB may choose to skip to Section 3. efficient. We prototyped Maverick by modifying the Chrome browser and the Linux kernel, implemented several drivers and frameworks in both JavaScript 2.1 USB Devices and Communication and NaCl, and compared them to native Linux equiv- Channels alents. Not surprisingly, user-level drivers in gen- A USB bus connects a host, such as a laptop or desktop, eral, and JavaScript drivers and frameworks in partic- to multiple peripheral devices over a star topology. Some ular, are significantly slower than their Linux coun- USB devices consist of more than one logical device; for terparts. Nonetheless, our experiments demonstrate example, a Web camera might consist of a video camera they are fast enough to support many interesting USB and a microphone packaged together into a single physi- devices and applications. As well, we show that NaCl cal box. Each of these logical devices would appear as a can achieve performance closer to that of in-kernel separate addressable entity on the USB bus. drivers and frameworks. A logical device consists of one or more communica- 3. Usability. Maverick must avoid burdening users tion endpoints associated with some specific function of with making confusing and error-prone decisions on the logical device. A host establishes a pipe to an end- how to select trustworthy and compatible drivers and point to communicate with it. There is a one-to-one map- frameworks for Web applications. To do this, Mav- ping between pipes and endpoint. Each endpoint and its erick allows users to configure their browsers to trust corresponding pipe are typed. USB supports four kinds one or more Maverick domain providers. A domain of pipes: provider is a trusted third-party like Google or Mi- crosoft that is responsible for selecting and bundling • Control. A control pipe facilitates the bidirectional together a set of interoperable Web frameworks and exchange of small control messages used to query or drivers. control a device. The USB specification mandates that hosts must reserve 10% of the USB bus band- We have prototyped several Web drivers and frame- width for control traffic. All devices have at least one works and applications that exercise them, including: control endpoint. a USB mass storage driver, a Webcam driver, a FAT • Interrupt. An interrupt pipe is a unidirectional chan- filesystem framework, and a streaming video framework. nel used to convey messages from a device to a host. Overall, our experience with Maverick suggests that Web For example, USB keyboards generate interrupt mes- drivers and frameworks are straightforward to imple- sages when key press events occur. Interrupt mes- ment, and are safe and practical from a performance, se- sages are latency sensitive; hosts must poll interrupt curity, and usability standpoint. endpoints sufficiently frequently to ensure respon- The rest of this paper is structured as follows. In Sec- siveness. tion 2, we present a brief overview of USB. Section 3 describes the architecture of Maverick, and Section 4 • Isochronous. An isochronous pipe is a unidirec- presents our prototype implementation. In Section 5, we tional channel used to transfer a continuous stream evaluate the performance and security of Maverick and of data, such as video frames or audio packets. Hosts must schedule USB messages to provide a guaranteed Maverick World Desktop World amount of bandwidth to an established isochronous Web Drivers, pipe. Isochronous pipes may experience occasional Frameworks, Applications data loss. Desktop Applications • Bulk. Bulk pipes are unidirectional channels that pro- User Level Browser Kernel vide reliable data transfer but no bandwidth guaran- Device tees. USB bulk storage devices and printers often use Frameworks bulk pipes. Maverick USB USB Virtualizer (MUV) Device Drivers OS user USB world splitter 2.2 Host OS Abstractions and Duties input USB bus bandwidth is allocated and scheduled into time slices called frames. For high speed USB 2.0 devices, USB device USB device frames have a 125 micro-second interval, permitting Hardware up to 8,000 frames per second. The host operating system is responsible for scheduling USB packets into Figure 1: Maverick “World Splitting.” Maverick splits com- puters into the legacy desktop world and the Maverick web frames. Because USB mandates reserved bandwidth for world. USB devices are partitioned between the two worlds; isochronous pipes and responsiveness for interrupt pipes, each world runs its own drivers, frameworks, and applications.