BAA-00-06-SNK
`FOCUSED RESEARCH TOPIC 5
`BY MARC STIEGLER AND MARK MILLER
`
`Report Name:
`A Capability Based Client: The DarpaBrowser
`
`COMBEX INC.
`
`CONTACTS
`
`TECHNICAL
`
`MARC D. STIEGLER
`PO Box 711
`Kingman AZ 86402
`Voice: (928) 718-0758
`Cell Ph.: (928) 279-6869
`Email: marcs@skyhunter.com Fax: 413-480-0352
`
`ADMINISTRATIVE
`
`HENRY I. BOREEN
`P.O. Box 4070
`Rydal PA19046
`Voice: 215-886-6459
`
`Email: hboreen@comcast
`Fax: 215-886-2020
`
`
`
`DATE OF REPORT
`
`26 June 2002
`
`
`
`
`
`.net
`
`Google - Exhibit 1031, cover
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`TABLE OF CONTENTS
`
`Executive Summary............................................................................................................1
`DarpaBrowser Capability Security Experiment............................................................5
`Introduction ......................................................................................................................5
`Goals ..............................................................................................................................5
`Principle of Least Authority (POLA)
`........................................................................5
`.....................................................6
`Failures Of Traditional Security Technologies
`Capability Security ......................................................................................................7
`E Programming Platform ...........................................................................................8
`....................................................................................8
`Preparation for the Experiment
`Building CapDesk ........................................................................................................8
`Building the E Language Machine ...........................................................................9
`Building the DarpaBrowser
`.....................................................................................10
`Building the Renderers ............................................................................................12
`Taming Swing/AWT ...................................................................................................13
`Limitations On the Approach .....................................................................................15
`The Experiment .............................................................................................................16
`Results .............................................................................................................................17
`Lessons Learned ...........................................................................................................17
`General Truths ...........................................................................................................17
`Specific Insights ........................................................................................................19
`Post-Experiment Developments ................................................................................24
`Closing Vulnerabilities .............................................................................................24
`Development of Granma's Rules of POLA ...........................................................26
`Introduction of SWT ..................................................................................................27
`Assessment of Capabilities for Intelligent Agents and User Interface Agents
`.......................................................................................................................................28
`Conclusions ...................................................................................................................30
`References.............................................................................................................................32
`Appendices............................................................................................................................36
`Appendix 1: Project Plan.................................................................................................38
`Appendix 2: DarpaBrowser Security Review..............................................................43
`Appendix 3: Draft Requirements For Next Generation Taming Tool
`(CapAnalyzer)....................................................................................................................78
`Appendix 4: Installation Procedure for building an E Language Machine...........80
`Appendix 5: Powerbox Pattern......................................................................................90
`Appendix 6: Granma's Rules of POLA.........................................................................95
`Appendix 7: History of Capabilities Since Levy.........................................................99
`
`i
`
`Google - Exhibit 1031, page i
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`A Capability Based Client: The DarpaBrowser
`Executive Summary
`
`The broad goal of this research was to assess whether capability-based
`security [Levy84] could achieve security goals that are unachievable with
`current traditional security technologies such as access control lists and
`firewalls. The specific goal of this research was to create an HTML browser
`that could use capability confinement on a collection of plug-replaceable,
`possibly malicious, rendering engines. In confining the renderer, the
`browser would ensure that a malicious renderer could do no harm either to
`the browser or to the underlying system.
`
`Keeping an active software component such as an HTML renderer
`harmless while still allowing it to do its job is beyond the scope of what can
`be achieved by any other commercially available technology: Unix access
`control lists, firewalls, certificates, and even the Java Security Manager are
`all helpless in the face of this attack from deep inside the coarse
`perimeters that they guard. And though the confinement of a web
`browser's renderer might seem artificial, it is indeed an outstanding
`representative of several large classes of crucial security problems. The
`most direct example is the compound document as so well known in the
`Microsoft Office Suite: one can have a single Microsoft Word document
`that has embedded spreadsheets, pictures, and graphics, all driven by
`different computer programs from different vendors. Identical situations
`(from a security standpoint) arise when installing a plug-in (like RealVideo)
`into a web browser, or an Active-X control into a web page.
`
`In such a compound document none of the programs need more than a
`handful of limited and specific authorities. None of them need the authority
`to manipulate the window elements outside their own contained areas.
`They absolutely do not need the authority to launch trojan horses, or read
`and sell the user's most confidential data to the highest bidder on EBay.
`Yet today we grant such authority as a matter of course, because we have
`no choice. Who can be surprised, with this as the most fundamental truth
`of computer security today, that thirteen year old children break into our
`most secure systems for an afternoon's entertainment?
`
`To tackle the problem, Combex used the EE programming language, an open
`source language specifically designed to support capability security in
`EE to build
`both local and distributed computing systems. We used
`CapDesk, a capability secure desktop, that would confine our new browser
`(the DarpaBrowser) which would in turn use the same techniques to even
`more restrictively confine the renderer. Once we had completed draft
`versions of the CapDesk, DarpaBrowser, and Malicious Renderer, we
`
`1
`
`Google - Exhibit 1031, page 1
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`brought in an outside review team of high-profile/high-power security
`experts to review the source code and conduct live experiments and
`attacks on the system. The DarpaBrowser development team actively and
`enthusiastically assisted the review team in every way possible to
`maximize the number of security vulnerabilities that were identified.
`
`The results can only be described as a significant success. We had
`anticipated that, during the security review, some number of vulnerabilities
`would be identified. We had anticipated that the bulk of these would be
`easy to fix. We had anticipated that a few of those vulnerabilities might be
`too difficult to fix in the time allotted for this single research effort, since
`the technology being used is still in a pre-production state. But more
`important than any of this, we had also predicted that no vulnerabilities
`would be found that could not be fixed straightforwardly inside the
`capability security paradigm. All these expectations, including the last one,
`were met. As stated by the external security review team in their
`concluding remarks on the DarpaBrowser:
`We wish to emphasize that the web browser exercise
`was a very difficult problem. It is at or beyond the state
`of the art in security, and solving it seems to require
`invention of new technology. If anything, the exercise
`seems to have been designed to answer the question:
`EE
`Where are the borders of what is achievable? The
`capability architecture seems to be a promising way to
`stretch those borders beyond what was previously
`achievable, by making it easier to build security
`boundaries between mutually distrusting software
`components. In this sense, the experiment seems to be
`a real success. Many open questions remain, but we feel
`that the EE capability architecture is a promising
`direction in computer security research and we hope it
`receives further attention.
`One of the by-products of this research, as a consequence of building the
`infrastructure needed to support the experiment, was the construction of a
`rudimentary prototype of a capability secure desktop, CapDesk. CapDesk
`and the DarpaBrowser with its malign renderer provide a vivid
`demonstration that the desktop computer can be made invulnerable to
`conventional computer viruses and trojan horses without sacrificing either
`usability or functionality.
`
`These results could have tremendous consequences. They give us at last a
`real hope that our nation--our industrial base, our military, and even our
`grandmothers and children--can reach a level of technology that allows
`them to use computers with minimal danger from either the thirteen year
`
`2
`
`Google - Exhibit 1031, page 2
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`old script kiddie or the professional cracker. The Capability Secure Client
`points the way to a still-distant but now-possible future in which
`cyberterror appears only in Tom Clancy novels.
`
`For a full decade, year after year, computer attackers have raced ever
`farther ahead of computer defenders. It is only human for us to conclude, if
`a problem has grown consistently worse for such a long period of time,
`that the problem is insoluble, and that the problem will plague our distant
`descendants a thousand years from now. But it is not true. We already
`know--and this project has begun to demonstrate--that capability security
`can turn this tide decisively in favor of the defender. The largest question
`remaining is, do we care enough to try.
`
`We end this executive summary with a picture we believe to be more
`eloquent than any words. On the right is the world of computer security as
`it exists today. On the left is the world of computer security as it can be.
`You, the reader of this document, are now on the front line in the making of
`the choice between these two worlds.
`
`3
`
`Google - Exhibit 1031, page 3
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`The Malicious Renderer running in two different environments. On the left, the renderer is
`running under capability confinement. It is unable to achieve any compromise of the
`security either of the browser that uses the renderer, or the underlying operating system.
`On the right, the exact same renderer is running unconfined, with all the authorities any
`executing module receives by default under either Unix or WinNT (referred to as "Winix"
`here). With Winix authorities, the renderer takes full control of the user's computing
`resources and data.
`
`4
`
`Google - Exhibit 1031, page 4
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`DarpaBrowser Capability Security Experiment
`
`Introduction
`
`Goals
`
`A precise description of the goals can be found in the Project Plan in the
`Appendix. The driving motivation was to show that capability based
`security can achieve significant security goals beyond the reach of
`conventional security paradigms.
`
`What is wrong with conventional security paradigms? They all impose
`security at too coarse a granularity to engage the problem. This failure is
`acutely visible when considering the issues explored in this research, in
`which we must protect a web browser and its underlying operating
`environment from the browser's possibly-malicious renderer. Even though
`the browser must grant the renderer enough authority to write on a part of
`the browser's own window, the browser absolutely must not allow the
`renderer to write beyond those bounds. This is a classic situation in which
`POLA is required. Let us discuss the POLA concept, and then look at a
`number of conventional security technologies to see how they fail to
`implement POLA at all, much less assist in this sophisticated context.
`
`Principle of Least Authority (POLA)
`
`The shield at the heart of capability confinement is the Principle of Least
`Authority, or POLA (introduced in [Saltzer75] as "The Principle of Least
`Privilege"). The POLA principle is thousands of years old, and quite intuitive:
`never give a person (or a computing object) more authority than it needs to do its
`job. When you walk into a QuickMart for a gallon of milk, do you hand the clerk
`your wallet and say, "take what you need, give me the rest back"? Of course not.
`When you hand the clerk exact change, you are following the POLA principle.
`When you hand someone the valet key for your car, rather than the normal key,
`you are again following POLA. Our computers are ludicrously unable to enforce
`POLA. When you launch any application--be it a $5000 version of AutoCAD fresh
`from the box or the Christmas Elf Bowling game downloaded from an unknown
`site on the Web--that application is immediately and automatically endowed with
`all the authority you yourself hold. Such applications can plant trojans as part of
`your startup profile, read all your email, transmit themselves to everyone in your
`address book using your name, and can connect via TCP/IP to their remote
`masters for further instruction. This is, candidly, madness. It is no wonder that,
`with this as an operating principle so fundamental no one even dares think of
`alternatives, cyberattack seems intractably difficult to prevent.
`
`5
`
`Google - Exhibit 1031, page 5
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`Failures Of Traditional Security Technologies
`• Firewalls: Firewalls are inherently unable to implement POLA. They are
`perimeter security systems only (though the perimeter may be applied to a single
`computer). Once an infection has breached the perimeter, all the materials and
`machines within the perimeter are immediately open to convenient assault. A
`firewall cannot discriminate trust boundaries between separate applications;
`indeed, it doesn't even know there are different applications, much less different
`modules inside those applications. To the firewall, all the applications are one big
`happy family.
`• Access Control Lists: Access Control Lists (ACLs) as provided by Unix and
`WinNT are also inherently unable to implement POLA. It is possible, with
`sufficient system admin convolutions, to cast certain applications into their own
`private user spaces (web servers are frequently treated as separate users), but
`this is far too complicated for the user of a word processor. It fundamentally can't
`discriminate between applications within a user's space, much less discriminate
`components inside an application (such as document-embedded viruses written
`with an embedded programming language like Visual Basic for Applications, or
`an Active-X control or Netscape plug-in for a Web Browser).
`• Certificates: Of all the currently popular proposals for securing computers,
`certificates that authenticate the authors of the software are most pernicious and
`dangerous. Certificates do not protect you from cyberviruses embedded in the
`software. Rather, they lull you into a false sense of security that encourages you
`to go ahead and grant inappropriate authority to software that is still not
`trustworthy. In the year 2000, an employee at Microsoft embedded a Trojan
`horse into one of the DLLs in Microsoft FrontPage. Microsoft asserted that they
`had had nothing to do with it, and started a search for the employee who had
`engaged in this unauthorized attack. What difference does it make whether
`Microsoft had anything to do with it or not? Microsoft authenticated it. The user's
`computer was just as subverted, regardless of who put it there. The real problem
`is, once again, the absence of POLA. FrontPage didn't need the authority to
`rewrite the operating system and install Trojan horses and should not have had
`such authority. The presence of a Trojan horse in FrontPage would, in any
`sensible POLA-based system, be irrelevant, because the attack would be
`impotent. There are uses for certificates in a POLA-based world, but this is not
`one of them.
`• Java Security Manager: Of the collection of current security technologies, the
`Java Security Manager comes closest to being useful. The Java Security
`Manager wraps a single application, not a user account (like ACLs) or a system
`of computers (like firewalls). By using sufficiently cunning acts of software
`sleight-of-hand, one can even place different software modules inside different
`trust realms (though ubiquitously moving individual software objects into
`individual trust domains and handing out POLA authorities at that fine-grain level
`
`6
`
`Google - Exhibit 1031, page 6
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`of detail would be too unwieldy, and too complex, to have understandable
`security properties). However, even the Java Security Manager does not begin to
`implement POLA. There are a handful of extremely powerful authorities that the
`Manager is able to selectively deny to the application. But authorities that are not
`self-evidently sledge-hammers, such as the authority to navigate around an
`entire window once you've gotten access to any individual panel, are far too
`subtle for the Java Security Manager to grasp. A malicious renderer could, with
`only a couple simple lines of code, take control of the browser's entire user
`interface, and gleefully spoof the user again and again, faster than the eye can
`blink.
`
`As we see, none of these technologies is able to seriously come to grips with the
`crucial needs of POLA either separately or in combination. This is why computer
`security is in such a ghastly state of disrepair today. The answer is capabilities.
`
`Capability Security
`
`Capabilities are a natural and intuitive technology for implementing POLA.
`Capabilities can be thought of as keys in the physical sense; if you hand
`someone a key, you are in a single act designating both the object for which
`authority is being conveyed (the object that has the lock), and the authority itself
`(the ability to open the lock). Capabilities, like idealized physical keys, can only
`be gotten from someone who already has the key (i.e., the shape of the key
`cannot be successfully guessed, and a lockpick cannot figure it out either).
`Authority is delegated by handing someone a copy of the key. Revocation of a
`capability is comparable to changing the lock (though changing software locks is
`much easier than changing hardware). One might think that making individual
`keys for every object that could possibly convey authority in a computer program
`would be unwieldy. But in practice, since the authority is being conveyed by the
`reference (designation) to the object itself, and since you have to hand out the
`reference anyway for someone to use the object, it turns out to be quite simple.
`In most circumstances the conveyance of authority with the reference makes the
`authority transfer invisible, and "free". Finally, because capabilities naturally
`ubiquitously implement POLA, an emergent property of capability-confined
`software is defense-in-depth: acquisition of one capability does not in general
`open up a set of exploits through which additional capabilities can be acquired.
`The implementation of capabilities that is today closest to production deployment
`is the EE Programming Platform.
`
`EE Programming Platform
`
`The EE Programming Platform, at the heart of which lies the EE programming
`language, is specifically designed to support capability security in both local and
`distributed contexts. EE is an open source system [Raymond99], and the draft
`book EE in a Walnut [Stiegler00] is the principal guide for practical EE programming.
`EE is still a work in progress. Indeed, the bulk of the work done to complete the
`
`7
`
`Google - Exhibit 1031, page 7
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`DarpaBrowser project was fleshing out parts of the EE architecture needed by the
`browser environment. But operational software has been written and deployed
`with EE. EE is not yet feature complete, but the features it does have are robust.
`
`Preparation for the Experiment
`
`Building CapDesk
`
`We started with the eDesk point-and-click, capability secure distributed file
`manager that was the first serious EE program used for production operations. We
`augmented eDesk with a rudimentary capability-confining launching system
`adequate for launching basic document-processing applications and a basic Web
`Browser. Adding the launching system turned eDesk into a rudimentary capability
`secure desktop, i.e., CapDesk.
`
`Key components of the launching system include
`• Point-and-click installation module that negotiates endowments on the behalf of
`the confined application. An endowment is an authority automatically granted to
`the application at launch time. Basic document processors only need user-
`agreed upon name and icon for their windows, used to prevent window forgery.
`Web browsers work most simply if endowed with network protocols, specifically,
`in this case, HTTP protocol.
`• Powerbox module that manages authority grant and revocation on behalf of a
`confined application. The powerbox launches the app, conveys the authorities
`endowed at installation, and negotiates with the user on the application's behalf
`for additional authorities during execution.
`
`8
`
`Google - Exhibit 1031, page 8
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`CapDesk operating as a capability secure, point-and-click, distributed file manager. In this
`example, CapDesk has one window open on a Windows computer, and another window open on
`a Linux computer. The user can copy/paste files and folders back and forth between the file
`systems, and directly run capability confined applications (such as CapEdit) on files on any part
`of a file system to which CapDesk has been granted a capability.
`
`Building the EE Language Machine
`
`With CapDesk expanded to be able to launch capability confined applications, it
`became possible to build an EE Language Machine (EELM). An EELM is the world's
`first general-purpose point-and-click computing platform that is capability-secure
`and invulnerable to traditional computer viruses and trojan horses. It is built by
`running a CapDesk on top of a Linux core; the CapDesk effectively seals off the
`underlying layers of software (Linux, Java, and EE Language, which together with
`CapDesk comprise the Trusted Computing Base (TCB) which has full authority
`over the system) from the applications that are running (only capability confined
`applications can be launched from CapDesk, so only capability confined apps
`can run).
`
`9
`
`Google - Exhibit 1031, page 9
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`Architecture of the EE Language Machine. A Linux kernel launches a Java virtual machine, which
`launches an EE Language Interpreter, which launches a CapDesk. CapDesk seals off the
`underlying non-capability elements of the Trusted Computing Base from capability-confined
`applications launched from CapDesk. In this sample scenario, a hypothetical capability-confined
`mail tool is running, and the user has double-clicked on an email attachment. The attachment in
`run in its own unique trust/authority realm, making it unable to engage in the usual practices of
`computer viruses, i.e., reading the mail address file and connecting to the Internet to send copies
`of itself to the user's friends.
`
`Building the DarpaBrowser
`
`A web browser needs surprisingly few authorities considering the amount
`of value it supplies to its users. A simple browser needs little more than the
`authority to talk HTTP protocol. Since the DarpaBrowser was itself
`designed as a capability confined application, this meant that the browser
`never had very much authority available for the renderer to steal if the
`renderer somehow managed to totally subvert the browser. As later
`observed by the security review team in their report,
`
`10
`
`Google - Exhibit 1031, page 10
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`Withholding capabilities from the CapBrower is doing it
`a favor: reducing the powers of the CapBrower means
`that the CapBrowser cannot accidentally pass on those
`powers to the renderer, even if there are bugs in the
`implementation of the CapBrowser.
`
`
`One of the security goals was to prevent the renderer from displaying any
`page other than the current page specified by the browser. While capability
`confinement was trivially able to prevent the browser from going out and
`getting URLs of its own choice, there was one avenue of page acquisition
`that required slightly more sophistication to turn off: if the renderer were
`allowed to have a memory, it could show information from a previously-
`displayed page instead of the new one. Therefore, the renderer had to be
`made "memoryless".
`
`With capabilities as embodied in EE, one straightforward way of achieving
`memorylessness is to throw the renderer away and create a new one each
`time the user moves to a new page. This was the strategy used in the
`DarpaBrowser.
`
`11
`
`Google - Exhibit 1031, page 11
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`An EELM with CapDesk and DarpaBrowser. The DarpaBrowser in this image is running the
`Benign Renderer, based on the JEditorPane widget of the Java Swing Library; this widget
`directly renders HTML.
`
`Building the Renderers
`
`According to the proposal originally presented for the DarpaBrowser, only two
`renderers would be built: a benign renderer, and a malicious renderer. As the
`project proceeded, it became clear that these were inadequate to test all the
`principles we wished to assess. A "text renderer" was built in time for the
`experiment. This renderer simply presents the text of the page on the screen,
`
`12
`
`Google - Exhibit 1031, page 12
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`creating a "source view". This renderer was able to present any HTML document,
`no matter how badly the HTML has been written by the page author.
`
`In the aftermath of the review, an additional renderer was built, the
`CapTreeMemless renderer, as described later.
`
`Taming Swing/AWT
`
`A key part of the effort of preparing for the experiment was taming the Java API,
`in particular, taming the AWT and Swing user interface toolkits. The act of taming
`involves applying a thin surface to a non-capability API that drives interactions
`into a capability-disciplined model. The Java API is not designed for capability
`security, yet contains an enormous amount of valuable functionality that cannot
`be easily rewritten from scratch. It turned out that the taming approach was in
`general adequate to make this API useable. Frequently, taming involves nothing
`more than suppressing "convenience" methods, i.e., methods that convey
`authority that programmers already have. Let us give a simple and a complex
`example:
`
`As a simple example, given any Swing user interface widget, one can recursively
`invoke "getParent" on the widget and its ancestors until a handle on the entire
`window frame is acquired. A malicious renderer could defeat, in a half dozen
`lines of code, the explicit goal of ensuring that the URL field and the page being
`displayed were in sync. Therefore the getParent method on the Component class
`must be suppressed to follow capability discipline.
`
`As a complex example, the most ridiculous anti-capability subsystem we
`encountered in Swing was the Keymap architecture for JTextComponents. All
`JTextComponents in a java virtual machine share a single global root Keymap.
`Programmers can create their own local keymaps and add them as descendents
`from the global root Keymap, creating a tree of keymaps; the children receive
`and process keystrokes first, and can discard the keystroke before it reaches its
`parents. The part of this that is exquisitely awful is that it is possible to edit the
`global root keymap. Malicious software can trivially vandalize keystroke
`interpretation for the entire system. Even more maliciously, objects can
`eavesdrop on every keystroke, including every password and every confidential
`sentence that is typed by the user. This is not merely a violation of security
`confinement. This is a violation of the simplest precepts of object-oriented
`modularity. Not only is it trivially easy for malicious code to attack the system, it is
`trivially easy for the conscientious programmer to destroy the system by
`accident. Indeed, the way the DarpaBrowser team first identified this particular
`security vulnerability in Swing (long before initiating the actual taming process)
`was by accidentally destroying the keymap for the eBrowser software
`development environment.
`
`To solve this problem, the methods that allowed the root keymap to be accessed
`had to be suppressed, and since child keymaps could not be integrated into the
`
`13
`
`Google - Exhibit 1031, page 13
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`system without designating the parent, new constructors had to be created for
`keymaps that would, behind-the-scenes, attach the keymap to the root keymap if
`no other parent were specified. While the actual amount of code needed to tame
`this subsystem was small, more effort was needed to design the taming
`mechanism than would have been required by the JavaSoft Swing developers to
`create a minimally sensible object-oriented design in the first place.
`
`Fortunately, the bulk of Swing is well-designed from an object-oriented
`perspective, which is what made it possible for the taming strategy to work well.
`Had the keymap subsystem not been an aberration, rewriting the user interface
`toolkit from lower-level primitives would have been more cost-effective despite
`the enormous costs such an undertaking would have entailed.
`
`The AWT/Swing API is an enormous bundle of classes and methods. A
`substantial portion of the entire research effort went into this taming effort,
`including writing two versions of the CapAnalyzer (see picture) tool to support the
`human tamer in his efforts. The approach taken in this first attempt at taming was
`to be conservative, i.e., to shut off everything that might have a security risk
`associated with it, and enable only things that were well understood.
`
`Version 1 of the EE Capability Analyzer. The human analyst is walked through all the classes in a
`Java package, given the Javadoc from the API for that class, and allowed to individually
`suppress methods, and mark the class "safe" (i.e., it confers no authority), or "unsafe" (and must
`be explicitly granted to a confined module from another module that has the authority).
`
`14
`
`Google - Exhibit 1031, page 14
`
`

`
`Combex/Focused Research Topic 5/BAA-00-06-SNK
`
`11/18/2002
`
`Limitations On the Approach
`
`Before plunging into the experiment and its results, we should carefully note the
`limitations on the approach taken in the DarpaBrowser effort.
`• Goal Limitations: As explicitly noted in the original proposal, Denial of
`Service attacks were out of scope, as were information leaks. The goal was
`to prevent the renderer from gaining authorities, such as the power to reset
`the clock or delete files. While as a practical matter the most dangerous
`kinds of information leaks were also prevented by capability confinement,
`some types of leaks, such as covert channels, were n