The Darpa Browser

Home   |   About   |   Technology   |   Papers   |   Contact


This is the document accepted by Darpa, and is presented as is for historical interest.
Current terminology and screen shots have changed since then.

Executive Summary

Using the capability-secure open-source E programming language, and the Combex-proprietary Capability Windowing Toolkit (capWT), Combex will develop a capability secure Web browser: the HTML rendering engine for the browser will be capability confined [Lampson1973, Shap2000] so that it may not compromise any part of the system, not even the field in the browser which displays the URL.

The browser will be run on an "E Language Machine". The E Language Machine is a capability secure, trustworthy platform, built on a Sanitized Linux: a Linux from which everything has been stripped that is not needed to support the E Language Machine. In particular, all the services normally associated with Linux (terminal services, network services above the TCP/IP stack, etc.) will be removed, eliminating risk of compromise. The E Language Machine will be a fully functional computing system, but, besides the TCB, only programs written in E and confined as caplets (capability-secured applications) will be permitted to execute.

Combex will supply 2 rendering engines. A Benign Renderer will underpin the web browser for traditional browsing purposes. A Malicious Renderer will, when loaded, relentlessly attempt to escape from its capability confinement, reporting on its results as it makes attacks.

Combex was founded by, and is led by, the core developers of the E language system and the publicly available applications written in that language. Bringing the powers of E, E's developers, and the Capability Windowing Toolkit together in a single focused effort on this contract allows Combex to deliver a reliable, robust capability secure system at high speed and with essentially no risk.

Statement of Work

Objective: Provide a brief overview of the specialty area and what is to be accomplished

Capability security embodies a paradigm for secure computational systems that stands in stark contrast to conventional security systems based on Access Control Lists. Capability security is designed to provide extremely fine-grain control of resources, making the allocation of each specific resource a separate granting of authority. Access Control Lists may be thought of as systems of ID badges, with each badge granted a span of powers, with the list of powers for the ID relatively fixed; capabilities may be thought of as keys, one for each resource, which may be granted and reclaimed during processing, so that a program might, over the course of a computation, hold dozens of keys, but never actually hold more than a few at a time.

Combex will develop a capability secure Web browser in which an incorrect page rendering module (made incorrect either by the presence of bugs or by malicious code) cannot compromise any other aspect of the computer or the display, up to and including the presentation of the URL from which the page was fetched.

Scope: Provide a statement of what the SOW covers including the area to be investigated, objectives/goals, and major milestones.

This project will investigate the application of capability security to a client application problem of moderate complexity, namely, the confinement of an HTML rendering engine in such a fashion that it cannot compromise other parts of the system. It will demonstrate the flexible power of capability security to enable a broad spectrum of safe, reliable computing without locking the user or the system into a structure that does not allow meeting diverse computing requirements. The major milestones include:

  • 4 Month Milestone: Combex will deliver a demo of a preliminary capBrowseFrame running with the Benign Renderer and an early prototype of the Malicious Renderer. This demo will not include the Sanitized Linux.

  • 8 Month Milestone: Combex will demonstrate a preliminary version of the entire E Language Machine running capBrowseFrame and both renderers. This system will not yet have been reviewed by our outside consultants, and will not have been fully tested.

  • 12 Month Milestone, Contract Completion: Combex will deliver all the items specified in the Deliverables section earlier in this document.

Task/Technical Requirements: Provide a description of tasks, which represent the work to be performed, developed in an orderly progression and in enough detail to establish the feasibility of accomplishing the overall program goals.

  • Develop the capBrowseFrame, based on capWT, which drives the browser frame and mediates requests for information from the renderer.

  • Develop the Benign Renderer and the basic Malicious Renderer plug-ins for capBrowseFrame

  • Develop the Sanitized Linux that underpins the E Language Machine

  • Integrate Sanitized Linux, the Java Runtime Environment, and the E Interpreter, into the E Language Machine

  • Load and exercise Securit-Edesk, capWT, capBrowseFrame, and the renderers on the E Language Machine

  • Test and audit capBrowseFrame's confinement of the renderers

  • Make final delivery


  • Monthly status report

  • Report describing the architecture of the system, analysis made by the outside security reviewers and their attempts at breaching the system. The report shall also describe and analyze the potential alternative technologies for Capability based Clients including both innovations explored and alternatives to explored innovations, discussion of their features, and justification for the design choices made by the research team, as specified by ATIAS.

  • Full source code and binaries for the Sanitized Linux OS, the E Language Virtual Machine and Interpreter, capWT, capBrowseFrame, the Benign Renderer and the Malicious Renderer. We explicitly note that the sources for the Java Runtime Environment will not be included due to uncertainties about issues with its Community License. These sources are readily available from other places.

  • License to use capWT: As a part of this contract, Combex will open-source capWT under the Mozilla license. We believe this will accelerate development of capability systems throughout the industry, and particularly in further work on capability secure military systems.

  • One complete computer that, upon boot-up, becomes a capability-secure E Language Machine and runs Edesk, the E software development environment Ebrowser, and the capBrowseFrame with both the Benign Renderer and the Malicious Renderer plug-ins.

  • Installation manual for turning additional computers into E Language Machines.

Technical Approach and Relevant Capabilities

Combex and its Relevant Technologies

Combex was founded in 1999,to pursue opportunities for capability security in the financial and software development sectors. Combex is the home of the world's greatest repository of expertise on the capability-secure, open-source E Programming Language. The Chief Technology Officer (CTO) of Combex is Mark Miller, the chief architect and implementor of E, and the central coordinator of open source E project. The Chief Operating Officer (COO) of Combex is Marc Stiegler, the developer of over half of all publicly available E applications deployed in the world today, and author of the book (currently in draft form) E in a Walnut [Stiegler2001]. In addition, Mr. Stiegler is the chief architect for the Capability Windowing Toolkit (capWT), a proprietary Combex technology for imposing capability discipline on mutually suspicious application subsystems that must share screen and keyboard/mouse resources in a graphical user interface (gui) environment.

E itself is the result of over $10M of research and development over a seven year period; its development was first initiated by the company for the implementation of a capability secure decentralized social virtual reality. When abandoned development of its own virtual reality for marketing reasons, allowed Mr. Miller to open source the language and take control of the central repository.

The most mature version of E, version 0.8.9, runs on top of the Java Virtual Machine (jvm), versions 1.3 and above. The language not only implements capability security within single-computer applications, it applies capability security to distributed systems with strong encryption that is built into the infrastructure: E programmers are not burdened with security considerations for their distributed systems, all communication is automatically encrypted, and remote computation objects are automatically authenticated. In addition, E uses a promise-based architecture for distributed computation, eschewing threads for concurrency control. This eliminates the traditional Sword of Damocles that hangs over all thread-based programming, the threat of deadlock. A particular feature of E critical to the success of this project is the power to implement caplets, software applications that are confined by capability discipline even if they share cpu, disk, and memory resources.

A more complete description of the specific characteristics of E that make it a "capability secure language" can be found in the References. Further reading on E's other special and powerful characteristics can also be found in the References at the end of this proposal.

Though E is missing several features needed for a version 1.0 release, all implemented features have been proven robust through a series of actual application development efforts including:

Figure 1: Securit-Edesk with windows on Windows, Sun, and Linux file systems

  • Securit-Echat: A capability secure 2-person chat system. This perfectly serviceable chat system is only 5 pages long, and is used as a tutorial for new E programmers.
  • Securit-Edesk: A capability secure point-and-click distributed file management tool. It blends the functionality of a graphically oriented file manager (like TkDesk on Linux, or the File Explorer on Windows) with remote file access (comparable to FTP, though it does not use that protocol) and secure connections (as you would get through an SSH connection). This tool is used on a daily basis in several projects for Fortune 500 companies. A small sample can be seen in Figure 1.
  • E Web Server: A small web server that can recognize browser requests for URLs which represent E services on a distributed network. Requests for these URLs are forwarded to the specified service for fulfillment. The E Web Server supplies for E programs a functionality akin to that supplied by the Sun Java Web Server for Java servlets, though the E Web Server directly and inherently supports capability secure distributed backend functionality.
  • Combex Marketplace: A capability secures exchange for fungible goods such as stocks and other financial instruments. An early, simple version of the marketplace was presented, with full source code, at the Financial Cryptography 2000 Conference with a cash prize for anyone who could break the security given a fully connected client application on the network. The prize remains unclaimed.
  • Enterprise-Wide Secure Application Prototype: A prototype for a proprietary Enterprise-wide secure distributed system for a Fortune 500 company. Work on a limited-deployment version for this system is about to begin, and the developers plan to use E technologies for this version as well.

The capWT windowing toolkit is an abstraction layer built on top of the Java AWT/SWING foundation classes for capability secure gui support. Since AWT/SWING is unaware of capability security, it embodies a complex stew of undisciplined powers. capWT, by using a sophisticated array of capability security patterns including revocable forwarders, facets, sealer/unsealer pairs, and pet name systems, turns this froth into a coherent framework for securable gui development: caplets presenting user interfaces through capWT cannot convincingly forge a fake user interface, cannot intercept unintended screen or keyboard/mouse events, cannot generate unauthorized screen or keyboard/mouse events, cannot communicate with or subvert other application systems even when they are sharing the same window, and cannot achieve unauthorized access to files for either reading or writing.

Technical Approach

The basic strategy of development will be to build up an "E Language Machine" from a "sanitized" Linux OS. This machine will be able to run E programs and caplets. It will be a general-purpose computer in the normal sense of the word, having the full Turing-machine power enabled by the E language. But it will be safe from the inadvertent launch of other Linux applications and services that could compromise the system by striking from "below" the E level.

Figure 2: E Language Machine with Capability secure Client

This technical approach is depicted in Figure 1. Starting at the bottom and working to the top, the components of the system are:

  • Sanitized Linux OS: This is a minimal Linux that includes a process scheduler, a file system, a TCP/IP stack and an Xwindows gui framework but little else. There will be no xterm, or indeed any terminal of any kind, for example. It will be built using one of several commercially available tools for creating custom Linux OS's for embedded applications.

  • Java Virtual Machine: When the sanitized Linux boots, it will launch one Java Virtual Machine. This will be the first and last application the OS ever launches.

  • E Language Interpreter: The Java Virtual Machine will, in turn, launch an E interpreter. And that will be the last application the JVM ever launches.

  • Edesk: Edesk will supply a point-and-click interface to the file system and other system resources. Edesk will be able to launch multiple E applications and caplets.

  • capWT: capWT, as described earlier, is an abstraction layer that supplies securable gui tools to caplets.

  • capBrowseFrame: capBrowseFrame is a caplet that receives the basic screen/keyboard capabilities from capWT, and also receives a Web-browser-specific capability to access Web pages using URLs. capBrowseFrame supports "plug-in" HTML rendering engines; the capabilities conferred on the rendering engine are narrowly constrained, sufficient for the renderer to fulfill its function, but not sufficient for any other purpose: capBrowseFrame will impose the Principle of Least Authority upon the renderer with a vengeance. capBrowseFrame controls the field in which the URL is displayed, and also controls actual access to actual Web pages, ensuring that the URL is always correct and accurate. If a Web page is requested, either by the user or the renderer, which does not exist, the capBrowseFrame will display a message explaining why the URL cannot be accurately displayed.

  • Benign Renderer: This is a plug-in for capBrowseFrame that renders Web pages according to the HTML specification. It will be based on the Java Swing HTML-rendering widget, and will supply all the base functionality of that widget.

  • Malicious Renderer: This is a plug-in for capBrowseFrame that does not bother to render HTML, but rather spends all its time attempting to penetrate the capability discipline within which it is has been confined. It will report on its progress as it attempts to read files, write files, alter the screen outside its assigned window panel (including attempts to alter the field displaying the URL), and communicate with the outside world.

We believe that the Sanitized Linux, operating within the constraints outlined above, achieves the goal of creating a trustworthy boot process that cannot be compromised without physical access to the hardware. However, for extra assurance, we have included the Enhanced Secure Boot process as depicted in the diagram as an added-cost option for the contract. This Enhanced Secure Boot process would be implemented using the AEGIS secure bootstrap system currently being integrated with LinuxBIOS [AEGIS].

Renderer Capabilities

What capabilities will be granted to the plug-in renderer? The list of capabilities described here are the only powers the renderer will have; any attempts at malicious behavior will require the use of these capabilities alone.

  • Drawing Control over a single Graphical Panel: The renderer can draw anything it likes inside the authorized panel.

  • Read Authority for keyboard/mouse events within the panel: The renderer can receive notification of user input events, if and only if those events are directed to the panel the renderer controls.

  • Authority to request from capBrowseFrame the data from an URL embedded in the current page. The renderer must designate for capBrowseFrame the location in the current page where this URL is described as a link target.

Implicit authority conveyed to the renderer are the authority to allocate RAM (create objects), consume CPU time (do computations), and deallocate RAM eventually (by removing all references to an object, the object will eventually be scavenged by the garbage collector; since access to the garbage collector is not an authorized capability, the renderer cannot initiate such scavenging itself).

Example Sophisticated Candidate Exploits and their outcomes

We have already described how the renderer is constrained by capability discipline from engaging in simple exploits such as reading confidential data, modifying critical system files, and drawing at will across the user's entire screen. We believe these properties cover all the security requirements stipulated in the FRT. Nonetheless; here is a sample of more complex attacks and their consequences.



Attempt to use data from one html page to corrupt the data on the next one

The renderer is not allowed state that persists from page to page; each time a new page is loaded, a clean instance of the renderer begins anew.

Transmission of a user's html page to a conspiring web site: It might be useful to the developer of the malicious renderer to have the data from a page the user has accessed. A malicious renderer might try sending the data from the current URL to the conspiring web site by encoding the data in a query string for a page at the conspiring web site, and then requesting that page.

The renderer cannot reach the conspiring web site because only sites specified in the links of the current page can be specified by the renderer (though the users can specify any page they desire, by typing the URL into the URL-designating field controlled by capBrowseFrame). Even if the user loads a page of malicious data, explicitly designed to conspire with the renderer, the renderer cannot transmit any information from any page except the malicious page itself, because of its memoryless condition

Transmission of user's page through a covert channel: By using its ability to allocate RAM and consume CPU resources, the renderer could engage in "wall banging": forcing system performance to rise and fall in a pattern that can be analyzed, from which data can be extracted. A conspiring caplet, loaded and running at the same time as the renderer, could extract this data by “wall listening” and use its own capabilities to further transmit the information.

All known practical security systems are subject to such covert channel “wall banging” attacks, and the best limitation normally attempted is to limit its bandwidth. E addresses instead the other half of the problem, where a true solution is indeed possible. For the conspiring caplet to read bits from a covert channel (to “wall listen”), it must have access to a clock or some source of non-determinism. The web browsing caplet described here cannot wall-listen because it does not have such access.

Security Testing

In addition to performing an in-house audit of the code for capBrowseFrame to ensure no improper capabilities are being conveyed to the renderer, Combex will hire on a consulting basis two well known members of the Cypherpunk/hacker community to review the system and attempt system breaches. The Combex Lead Investigators will assist these "friendly assassins" in every possible way, helping them understand the machinery of confinement, giving them full access to our sources, teaching them how to write their own malicious renderers, and creating new malicious renderers on their behalf as requested.

Furthermore, with the approval of the Contracting Officer, Combex proposes to post the full source for capWT, capBrowseFrame, and both renderers, on the Web and offer $10,000 in prizes for finding a breach. Combex believes that prizes such as this will play a valuable role in accelerating acceptance, and hence adoption, of capability secure tenets throughout the security community.


Combex has excellent working relations with the EROS Group in charge of the Extremely Reliable Operating System open-source initiative, and with Agorics, owners of the original KeyKos capability operating system. Combex will work with these teams to ensure maximum interoperability of the results of this contract with their development efforts.

Limitations of the Approach

The greatest limitation of this approach is its dependence on the Java Runtime Environment (JRE). The JRE is an extremely large body of code that has not been reviewed with an eye to its internal vulnerabilities when used in a capability environment. As such, it is not entirely desirable as a part of the Trusted Computing Base (TCB), i.e., the core components of the system that have full authority. Though practical experience to date makes us confident the JRE is up to the current task, a better approach in the long-term would be to use the ENative runtime environment, currently in a nascent stage of development, designed to be deployed with capability operating systems such as EROS.

Key personnel

Mark Miller, the CTO of Combex, will be one of the two Lead Investigators on this effort. Before E, Mr. Miller co-authored the first paper explaining the criteria to be used in designing secure distributed programming languages [Kahn1988]. The languages he’s helped design according to these criteria include Vulcan for Xerox PARC, Trusty Scheme for AutoDesk, Joule for Agorics, Tclio/WebMart for Sun Labs. As noted earlier, Mr. Miller is now the chief architect of E and the central coordinator of the open source E project. In this role he not only manages source code, and design and implementation of future versions of E, he also works to prepare the world for capability security in general. Mr. Miller instigated the E Language Discussion group ( This email list supports some of the most invigorating discussions of security taking place today, with regular participation by people such as Hal Finney, Jonathan Shapiro, Ben Laurie, and David Wagner. Recently Mr. Miller created CapIDL, an interface definition language for integrating capability secure languages with capability secure operating systems, another milestone on the path to a unified, secure future. Mr. Miller is the inventor on six patents in the areas of cryptographic protocols, automated combination auctions, and distributed secure object systems. He has three more patents pending.

Prior to taking on the central role for E, Mr. Miller was a lead architect for the EC-Habitats capability-secure decentralized social virtual reality under development at During the Beta testing for EC-Habitats, no security bugs were ever identified.

Prior to these initiatives, Mr. Miller had over 24 years of experience in software architecture, design and development at companies including DataPoint, Xerox PARC, and Autodesk. At Datapoint, he created the first commercial distributed windows system, VistaView.

Mr. Miller is also the author of "Capability Based Financial Instruments", presented and published at Financial Cryptography 2000. This work unifies the heretofore disjoint research tracks of object-oriented programming, capability security, and public key cryptography into a coherent whole.

Marc Stiegler, the COO of Combex, will be the other Lead Investigator on the contract. As noted earlier, Mr. Stiegler is the author of E in a Walnut, and chief architect and developer of capWT. Prior to joining Combex, Mr. Stiegler was VP of Engineering for, where he took on the task of transforming a software development organization that had spent 3 years and $10M without developing either a product or even a justifiable schedule for creating a product. 8 months after Mr. Stiegler took charge, the EC-Habitats capability-secure virtual reality entered into Beta testing.

Prior to joining, Mr. Stiegler was the chief architect, designer, and implementer for DecideRight, a decision analysis tool that won the Software Publisher's Association CODIE Award for Best New Business Software of the Year in 1996. Prior to that he was VP of Software Engineering for Autodesk, which was at the time the 4th largest software company in the world. Mr. Stiegler drove Autodesk to be the first professional CAD vendor to ship a product on the Microsoft Windows platform, reinforcing Autodesk's position as the premier developer of CAD on the desktop.

Last but not least, Mr. Stiegler spent 9 years with the BDM Corporation in defense contracting (BDM is now a part of TRW). Mr. Stiegler's career was focused on C3I systems; the systems that today most need capability security to survive the threats of the 21st Century. Mr. Stiegler was one of the few individuals who worked on all 5 of the U.S. Army command and control "stovepipes": maneuver, artillery, logistics, air defense, and intel. Mr. Stiegler's work on the Target Acquisition and Planning System (TAP), which used Apple II computers for tactical nuclear targeting, was in the forefront of the Army's drive to use NonDevelopmental Items (NDI) and Commercial, Off the Shelf (COTS) equipment. Mr. Stiegler was also the Director of Software Development for the battalion-level part of the Distributed Command and Control System (DCCS), which introduced the Army to the GRiD highly rugged yet commercial laptop computer. DCCS was not only used by the High Technology Light Division, it also found application in the White House for communication, and in the Bureau of Land Management for fighting forest fires. A descendant of the DCCS system was used with great success in Desert Storm.

In addition to E in a Walnut, Mr. Stiegler was also the lead author of Programming Languages: Featuring the IBM PC and Compatibles, which was chosen by Byte Magazine in 1986 as one of 20 key books on the PC.


[AEGIS] AEGIS Secure boot system:

[Kahn1988] Kenneth Kahn, and Mark S. Miller, "Language Design and Open Systems," in Bernardo Huberman (ed.), Ecology of Computation (Elsevier Science Publishers/North-Holland, 1988).

[Lampson1973] Butler Lampson, “A Note on the Confinement Problem,” CACM Vol. 16, No. 10,

[Miller2000] Mark Miller, Chip Morningstar, Bill Frantz, “Capability-based Financial Instruments,” Proceedings of Financial Cryptography 2000, Springer-Verlag,

[Rees1996] Jonathan Rees, "A Security Kernel Based on the Lambda-Calculus", (MIT, Cambridge, MA, 1996) MIT AI Memo No. 1564.

[Shap2000] J. S. Shapiro, S. Weber; “Verifying the EROS Confinement Mechanism,” Proceedings of the 2000 IEEE Symposium on Security and Privacy.

[Stiegler2001] Marc Stiegler, “E in a Walnut,” Draft: