[cap-talk] Selling capabilities programming

[James A. Donald]

Jonathan S. Shapiro wrote:
 > 1. It is off-topic. Please explain the relationship,
 > if any, between your (erroneous) understanding of
 > Xanadu and the subject at hand, which is defining the
 > term "protected capability system"?

If a capability system is "protected", must be protected
from something that is actually harmful - must be
protected from some problem that actually troubles
users.  Many of the problems that Xanadu sought to solve
were not at all well defined as to what would constitute
a solution and what was in fact a problem.  For example,
automatic micropayments were a central and essential
part of the Xanadu system - but there have been lots of
efforts to provide for automatic micropayments, and
actual acceptance of these systems has been
indistinguishable from zero - plus it is a hard problem
to solve requiring human, institutional, moral, and
legal change, not merely software.  Hard to do, hard to
make work with all the other aspects of Xanadu, and few
customers wanted it.   I very much want to see the
micropayment problem solved, and expect it will be
solved, but tossing that very large problem in with all
the others showed a disturbing lack of interest in
reducing the problem to chunks small enough to be
successfully delivered.  "Protection" without
explanation of a concrete real world problem that one
needed to be protected from sounded to me like a similar
lack of interest in actual delivery of version 1.0 -
Version 1.0 being the version containing only those
features that the customers really need right now.

 > 2. It is false to the exchange at hand. You disregard
 > my comment that the cryptographic scheme you sketched
 > was appropriate for the e-gold problem, but is not
 > appropriate for a general capability infrastructure.

I did not disregard, but responded to, your talk of
"general capability infrastructure"  "General capability
infrastructure" is an excessively broad and ill defined
problem class.  We should recognize general problems in
particular concrete problems, find the general in the
particular, rather than starting from the general.  An
infrastructure that is general in the sense of being
suitable for dealing with a very diverse set of
incompletely imagined problems, is apt to be cumbersome
in dealing with any one particular set of problems.
Generality should be found by abstracting from diverse
particular concretes, else one finds oneself addressing
floating abstractions, which inevitably turns into an
endless chase.

A generality may be illustrated by one particular
concrete in straightforward generalizations, but three
concretes are required for less straightforward
generalizations.   A non trivial generality without any
concretes is most likely a floating abstraction, and
floating abstractions will get you into trouble, in
engineering projects, gets you into projects that get
ever further from completion, instead of closer to
completion.

 > 3. It is a vicious, personal attack. You know
 > perfectly well that several participants here worked
 > on Xanadu.

I was unaware that several participants here worked on
Xanadu - indeed, I do not recall any of the Xanadu
participants.  It did not occur to me that this example
would be inflammatory in this context.

 > Perhaps you like to hurt people. I cannot think of
 > another reason for this behavior.

I had no intent to offend people.

I am interested in capabilities as a solution to the
crisis that is now upon us - the particular entirely
concrete crisis that is now upon us, the crisis which
your response seemed to me to ignore.

 > If you want to make this conversation productive, you
 > would do better to ask *why* the distinction between
 > protected and unprotected capabilities matters.
 >
 > The problem with unprotected capability systems is
 > that they cannot enforce authorities of *any* sort.
 > That is a statement of mathematical fact, supported by
 > multiple formal works. It is also a statement of
 > empirical observation, since systems of the type you
 > describe have consistently failed to enforce policy
 > successfully for reasons that are axiomatic to their
 > design.

This is not, in fact, an answer.

I have already explained why it is not an answer, and my
explanation deeply offended you.

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

 > Actually, it is *exactly* this context in which it is
 > useful, because restricting permission propagation is
 > the essence of the power box design that you advocate.
 > The power box approach is founded on authority
 > confinement, and cryptographic capabilities cannot be
 > confined.

Again, this is not, in fact, an answer.

An actual explanation would resemble the Bitfrost
specification, which continually invokes particular
familiar concrete problems that are apt to affect
particular identifiable real life customers and end
users in their specific activities.  An actual answer
would sound like a fragment of the Bitfrost
specification.

It is generally advisable to produce software that
solves some large class of problems, and is forwards
compatible with software that solves some larger class
of problems, rather than attempting to solve everything
before one can solve any one thing.  Thus, for example,
Horton makes a lot of sense as a solution for some
capabilities, perhaps essential for some capabilities,
but does not make much sense as a framework within which
all capabilities must fit. The framework needs to be
forwards capable of having Horton fitted into it at some
later date, but not the other way around.  Wish lists
belong in version 3.6 - (Version 1.0 being only usable
for lack of something better, and version 4.0 being the
version that develops excrescences as a result of
marketing checklists)