[cap-talk] Selling capabilities programming

[James A. Donald]

James A. Donald:
 >> Thus the edit program does not need and should not
 >> have a general ambient capability to open any file it
 >> pleases...

Jonathan S. Shapiro
 > This is problematic. I agree with what you are trying
 > to say from a security perspective. The problem is
 > that *shells* really *do* require the ability to do
 > that, and users have been trained into the belief that
 > just about any application should be a shell. This is
 > particularly apparent when one considers emacs, but as
 > a second example consider the ubiquity of the File
 > menu.

All the diverse file menus should operate by requesting
one piece of trusted code, which alone has the ability
to discover what files are available, and construct a
file handle to one of them.

Existing file menus, for example in Windows, all *do*
operate by calling a single piece of code, but this code
simply gives file path to the calling program, and the
calling program has the capability to itself find file
paths and open files.

As for shells, well, we have to get by with one general
shells and a few deliberately limited special purpose
shells - a shell must be a powerbox, and we cannot have
numerous or excessively complex powerboxes.