[cap-talk] Selling capabilities programming

[Jonathan S. Shapiro]

On Thu, 2007-07-26 at 13:06 +1000, James A. Donald wrote:
> Jonathan S. Shapiro wrote:
>  > 2. strict confinement: I know that the program has no
>  > initial write
>  >      authority to anything. In consequence, I am in
>  >      full control of where it can send information.
> 
> Typically, we want the program to be able to write to
> its own configuration directory - for example to save
> the default state of tick boxes in dialogs, the default
> position of windows, and so forth, and we want the user
> to start the program by clicking on name that represents
> start information, that grants the program various
> permissions, among them permission to write to a
> configuration file.  This startup information will be
> set up by an installation script that the user did not
> write, and is unlikely to ever look at.

This is an assertion. It does not consider three obvious alternative
designs:

  1. The design in which the user supplies a capability to
     the configuration directory at startup, or

  2. The design in which the user is handed a "first start"
     program that initializes the program, including config
     state, and returns a capability to an instance that is
     "closed over" the capability to the config state.

  3. The design in which the config state directory is known
     to the powerbox. Note that the powerbox is in a position
     to know which application it initiated and maintain an
     durable application-specific data space on behalf of
     that application. This makes more sense than an ambient
     authority system, because the application is not in a
     good position to know the proper extent of state sharing.
     If you send me your document, should I get your defaults
     too? Probably some yes and some no. My point is that the
     answer is context sensitive and ambient authorities lack
     any context.

Also, you are interpreting "program" too narrowly here. Even if I want
the word processor's "shell" to have access to config data of this sort,
it does not follow that I want the word processor *plugins* to have that
access.

>From the applications that I have looked at (which is by now quite a
few), almost every place where current applications use plugin
technology based on dynamic shared libraries is a place where a confined
subprogram would be a better choice if the underlying OS supported that
idiom.

Note that even Microsoft believed this at one point. Back when what is
now ActiveX was still called OLE, there was a big push for "out of
process servers". Problem was: they couldn't make them work fast enough.
This may have had something to do with the fact that (a) their fastest
interprocess communication primitive at the time was five decimal orders
of magnitude slower than the state of the art, and (b) their protocols
rely on lots of round trips to do anything interesting.

The last MS document I recall that placed any emphasis on this was the
OLE Beta 2 specification. After that it quietly disappeared.


shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC