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

[Ivan Krstić]

On Aug 5, 2008, at 10:51 PM, David-Sarah Hopwood wrote:
> In an environment where commercial pressures to finish a project on
> budget and on time are dominant, then this approach may be considered
> too inefficient. But as far as I can see, very little actual  
> innovation
> occurs in that kind of environment in which that view is prevalent.
> Refinement of well-established ideas, yes, but not innovation.

You're confusing innovation with revolution. Though it holds a great  
deal of appeal, the latter is most absolutely not a precondition for  
the former.

> Frankly, I can't see what harm it does if someone makes a decision  
> about
> what security mechanism(s) to work on that is initially fairly  
> arbitrary.

Starting with a problem and working towards a solution is engineering;  
starting with a solution and working towards a problem is dicking  
around. Dicking around can be very educational and enjoyable, so I  
don't mean to suggest it is a bad thing; if Tomas is looking to learn  
about capabilities by seeing if a good PIM system can be constructed  
with them, more power to him. But if he's looking to build a PIM  
system with certain security properties, he's looking to do  
engineering, and that's where choosing to use capabilities up front  
and then working backwards makes no sense.

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

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. Interested developers are  
reduced to joining an obscure and often exasperating mailing list to  
ask what the capability approach even means. Against this backdrop,  
ACLs and their known deficiencies look pretty damn good.

> As far as I can see, we do not have a large or diverse enough sample
> of capability systems that have been put into production, to be able  
> to
> come to any conclusion about what their eventual cumulative complexity
> "most often" is.

Precisely, because the cumulative complexity of using an unfamiliar  
solution with largely unknown properties in a production system  
generally outweighs the complexity of using a familiar one with known  
properties, some (or even many!) of which are bad. If this were not  
so, the industry would have moved away from the excrement that is X. 
509 ages ago.

--
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | http://radian.org