[cap-talk] Persistence as a cap value

[James A. Donald]

Jed Donnelley wrote:
 > I wonder if you could give an example of a capability
 > that made sense to issue/communicate as
 > non-persistent?  To me it seems useless to even create
 > such a capability as it may disappear before there is
 > even a chance to use it - as a system can be restarted
 > at any time.

The capability to access a particular file: my word
processor should not be able to open or modify any
@#$%^&* file it pleases, let alone my solitaire program,
but rather should invoke some specially privileged
software that brings up the file menu user interface,
and this specially trusted software grants the invoking
program the capability to open the file that the user
has designated.  (though we should allow programs to
access their install directory as they please)

Similarly, the capability to access a particular web
site.

File transfer:  It is convenient to IM someone the
privilege to access a particular file, which capability
should by default expire if he or I exit the IM program.

 > If having a capability disappear before it's first
 > intended use would cause a problem, then it must be
 > issued as persistent.

Rather, the circumstances that might cause a capability
to disappear before it was used - typically one of the
computers or programs involved crashing or being shut
down or being rebooted or restarted - indicate we have a
problem, in which case the situation is most likely not
what the user intended or expected, in which case the
safest course of action, the least surprising, the least
confusing to the user, is that nothing happens.

In any situation where arguably we need persistent
capabilities, we quite likely have something that is
highly user hostile, for example Microsoft's linked
documents, in which case the solution is not to
implement persistent capabilities, but to figure out a
way of addressing and representing the problem that does
not boggle the user.  Instead of linked documents,
project files.