[cap-talk] Selling capabilities programming

[Jonathan S. Shapiro]

On Mon, 2007-07-16 at 16:06 +1000, James A. Donald wrote:
> 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...

James: a detailed discussion about the Xanadu design and the Xanadu team
is really outside the scope of this list. You asked me why something was
not an object capability system. My answer to you is a matter of
definitions. We may disagree about the definitions, but this has
absolutely nothing to do with Xanadu's success or failure.

What you are really saying is that you don't understand why protected
capabilities -- as distinct from unprotected capabilities (including
cryptographic and sparse capabilities) are important. I will start that
answer in a separate email shortly.

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

This raises my curiosity. If you don't know any of the people involved,
how do you have sufficient understanding of what happened at Xanadu to
offer such a strong opinion? What is the source of your competency?

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

It wasn't intended to be. You haven't yet asked a question.

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

Actually, it really *is* an answer. You just haven't thought about it
enough. I'll go into greater detail in my next message.

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

That is one possible style of explanation. It is not the only valid
approach. Since I don't have time to investigate Bitfrost at this time,
you will have to settle for what I *can* provide.

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