[cap-talk] Understanding capabilities in a web-desktop setting

[Jonathan S. Shapiro]

On Thu, 2008-08-07 at 18:54 -0400, Ivan Krstić wrote:
> On Aug 5, 2008, at 10:51 PM, David-Sarah Hopwood wrote:
> > So, we have to try something different. Capabilities are different  
> > [+],
> > so let's try those.
> 
> We don't know that capabilities "work" -- or that they're simpler than  
> alternatives -- in the long term. There are no notable current  
> production systems employing capabilities that we could watch over a  
> prolonged period of time.

Ivan, this simply isn't true. Every major telephone switching system in
the world operates on either an actual capability fabric or a set of
software disciplines that seek to implement a capability fabric in
software. We have very extended experience with those systems, and we DO
know that they work. We also know that the system with longest MTBF in
history to date -- KeyKOS -- was a capability system that was used in
real applications.

Beyond that, we have a number of systems that are capability-like that
operate successfully in large measure because of the same properties we
advocate as advantages for capability systems.

Whether capabilities present a viable user interface pattern is more
dubious. We have some very very promising examples of how to do that,
but we don't have very broad user experience.

Oh. And then there is the AS/400, which is arguably the most successful
mid-range system in history.

The real issue, I think, is that all of these examples have been
successful commercial systems. Teaching competitors to build better
competing systems wasn't on their agenda.

>  Anyone in charge of building a current  
> production system would likely be making an irresponsible decision if  
> they chose to employ what's essentially an untested security approach,  
> unless the _purpose_ of the system was to serve as a testbed for that  
> approach.

That would be true if it were untested. Unfortunately the truth is more
grim. It is well tested, but it has been suppressed from the academic
literature, in large measure due to well-intentioned resistance
motivated by exactly the kind of argument you are presently making, and
in smaller measure due to issues of academic orthodoxy.

Capabilities are not orthodox. Look at this as a problem in religious
schism and the current state of affairs will start to look very
familiar.

> Capabilities are currently hand-waving. Nothing more. They're mostly  
> undocumented and unexplained. My calls on this list for a single  
> cogent, coherent writeup with good non-hypothetical examples such as  
> those from the Tahoe FS, went unanswered.

Ivan: I'm not sure what you mean here. The formal explanations and
underpinnings for capabilities are at least as strong as those for ACLs.
There are working examples of both types of systems.

What *is* true is that the problem of orthodoxy is real. Capability
systems have a much smaller advocate base, and the rate of advance has
therefore been slower. This does not mean that capabilities are a bad
idea. It means that an entrenched majority can defeat any opposing
position by the simple expedient of starving it of resource. The fact
that the entrenched majority has seen fit to do so in this case may mean
that there really are technical grounds (from the ACL perspective) to
see capabilities as a threat. Or it may simply mean that lots of
individuals are looking out for number one. It's hard to tell.

What is *also* true is that there are few examples of working systems
that you or I can touch and play with. That is a very real problem. But
note that ignoring your "testbed only" judgment above is a precondition
to actually solving it.


shap