[cap-talk] Selling capabilities programming

[James A. Donald]

James A. Donald:
 > > My original claim was that capabilities *may* be
 > > [usefully] represented by a sparsely populated
 > > address space, that is to say, secrets.

David Hopwood wrote:
 > That claim is true (if a little imprecisely stated),
 > and no-one has denied it.

This claim has been denied with such passion and
persistence as to persuade me that any attempt at
rational discussion is pointless.

 > That was not the original claim you made, however. You
 > said:

 > # Seems to me that capabilities programming is
 > suffering # from the same ailment as the Xanadu system
 > suffered - # that the ideal imagined capability system
 > is getting # further and further from being written.

You are wrong:

On Fri, 13 Jul 2007 I posted that capabilities may be
usefully implemented as secrets.

I received a response that led me to doubt the
rationality of those responding, and so on Mon, 16 Jul
2007 I wrote:

: :	Seems to me that capabilities programming is
: :	suffering from the same ailment as the Xanadu
: :	system suffered - that the ideal imagined
: :	capability system is getting further and
: :	further from being written.  Towards the end,
: :	Xanadu as imagined, was not merely code, but
: :	rather required as a precondition for its
: :	existence a profound social transformation.
: :	They spent decades refining the concept of
: :	Xanadu, in the process removing it ever
: :	further from reality, rather than providing
: :	useful software embodying and utilizing that
: :	concept.
: :
: :	In the context that we are defending the
: :	users from malware, rather than management
: :	from users, restricting the propagation of
: :	permissions strikes me as bloody useless.
: :
: :	The more easily capabilities can be passed
: :	around, the finer we are apt to slice them.
: :	The finer we can slice them, the less
: :	gratuitous authority we give applications.
: :	Only some rather special capabilities need
: :	special treatment, and those capabilities are
: :	not critical to the major problems we face
: :	today.


You cannot usefully "protect" networked capabilities,
because authority over a network is divided.


 > You were told why it is undesirable to implement
 > unprotected capabilities in new systems.

Which is the claim you just said no one was making.

Well are they making it or not?

 >> then "protection" of capabilities is merely an
 >> implementation detail,

 > It obviously is not, since it affects user-observable
 > security properties.

No it does not.  This as already been dealt with at
excessive length, and with far too much repetition.  If
two programs are permitted to communicate, the security
properties are the same as if they can transfer
capabilities unobserved and undetectably.

Therefore, "protecting" capabilities is of limited
value, and that value must be compared with the
implementation costs of "protection", which in the
networked case can well be substantial.