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 perspectiveA .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 perspectiveThe 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.
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.