When Adobe introduced the PDF document format several years ago it was a simple format in which you could describe most printed pages non algorithmically. By its high level design it could only generate pixies for pages, search for text and scroll. It became common and adopted in many venues. Adobe has gradually added function to their standard and now it may execute 3rd party code to the detriment of the person opening the PDF document.

As an exercise I imagine how the function of Adobe’s unmodified Reader might be installed in a suspicious capability OS. In addition to the classic ‘preferences’ information kept for the user by the application between runs of the application, there is another body of control information kept by the system for the application and user to be kept between runs of the application. A tentatively call that an ‘access manifest’ after rumors a feature by such a name in the Chrome OS and also proposed Mozilla projects. The code of the application is not allowed to run except in compliance with this manifest.

The average user’s perspective

A .pdf file has arrived at your machine. You have an opinion but no assurance of its provenance. You would like to read it. You double click the document and if this is the first time you have read a .pdf file a system dialog box appears asking if Adobe’s Reader is the program with which you wish to view the file. It gives alternatives. If you choose Adobe Reader then it asks if there is any reason to grant that program any ability beyond producing an interactive window on the screen. There is no reason that you are aware of for the document to make any changes to your machine and so you answer ‘no’. The dialog asks what information the program is to be allowed. There may be a list of information items that the application is known to want, there may even be a list in information items that the application demands. I assume here that there are no demands.

A new window opens with the content of the document. The window is interactive and responds to keyboard and mouse input. It is able to put things on the clipboard, but only when the mouse is clicked in the window. It is able to read the clipboard but only upon mouse click in the window. The application cannot move the cursor. These last three rules are variously understood by user; indeed some users assume that this is how all systems work.

System Designer’s perspective

The adobe reader has been wrapped in a standard wrapper but perhaps tailored a bit by a security expert to peculiar demands of an application. If it is my machine I appoint the expert—perhaps me. If it is my company’s machine perhaps the expert is someone else. The most surprising thing about the list of items that the application may want to query is how many there are. The system has the ability to generate synthetic values as responses to such queries by the application. An unsettled question is which of these queries may be a deal breaker with the legitimate application author who may have a business plan to protect.
Current Time
The application author or the originator of the PDF document may wish to place limits on the times that the document may be viewed. My only judgement here is such a restriction should be known upon first viewing of the document. It may condition whether a payment is made. I do not know whether Adobe supports such restrictions.
Size of Screen
within which an application window must presumably fit. Market segmentation schemes may temp the application author or document author to restrict function of availability by platform. Double scrolling may be necessary if subterfuge is required.
System Fingerprint
may be used to monitor compliance with contracts under which the application or document is available.
Network Access
is taken for granted in many applications and operating systems. It is not possible to fake access to the net, but it is possible to intercept and transform the data streams. Given tamper resistance, crypto may protect the wary application from the machine operator.
If the system architects aspire to allow demands for classes of queries, on the part of application or document authors, they commit to some degree of physical tamper resistance. I do not address this problem further here.

For legacy applications written for extant systems, queries about directory contents may be satisfied by an initially empty user directory. Some applications may find in convenient to keep files. What is novel here is that the application may request privacy for such directories, contingent again on tamper resistance. Persistent private application directories that last between application sessions, like web cookies, interfere with some of the above goals. Some of the problems can be solved by supporting multiple sets of private application files; but this may confound application limitation schemes. There is clearly a chess game to be played. Such matters are considered more extensively here.

Elements of these features are rumored in Chrome OS. I have not sought details. I suspect that they each require blocks of kernel code. In a proper capability system all of the above can be provided outside the kernel. Given the games to be played it is strategic that code for new wrinkles not damage previous security arrangements. Capabilities allow this strategy.