[cap-talk] Don't understand capabilities

[Sandro Magi]

Marcus Brinkmann wrote:
> Actually, one of the most straightforward ways to name a book is to
> physically operate on it. 

I'm puzzled. By "name a book", you seem to imply something other than
"my copy of 'Catcher in the Rye'", which clearly does not operate on the
book.

If by "designating" it, you mean handing it over to someone, that's not
just an act of designation, that's communication of a capability. I
think people implicitly understand that naming something conveys no
authority, but handing it over does.

> But apart from that, you have demonstrated
> my point: One can name an object without operating on it.  That's why
> designation and authority are separated.
>   

Sure, you can name anything, anytime, any way. I can say "Marcus
Brinkman's computer", which clearly "designates" your computer, but I
can't produce any side effects on "Marcus Brinkman's computer" without
the capability to do so.

> I don't think that brands provide quite the same type of naming I
> mean.  In the real world, I do not need somebody any authority to be
> able to name an object.
>   

You don't need any authority on the object to hold its brand. If I
understand it correctly, a brand is just a GUID, not a reference to the
object itself.

>> You still have to be able to touch the book to actually operate on it
>> (open it, read it, burn it, etc.). That's a capability. Any disagreements?
>>     
>
> Sure, that's a capability.  But the world is larger than that.
>   

Right, but I thought we were concerned with the world of access control. :-)

If we're dealing with the world at large, then sure, designation and
authority might be separate in some cases, and can perhaps even be
useful when separated. When actually producing side effects however, you
seem to actually need the "capability" to do so (in any sense of that
word). I'd be interested to hear counterexamples.

>> As for the "naturalness" of capabilities, what could be more natural to
>> a programmer than an unforgeable reference? Pointer arithmetic is
>> learned, and with great difficulty.
>>     
>
> I am not talking about programmers, though.  The human mind and body
> are quite flexible enough to acquire rather unnatural abilities after
> years of training.
>   

Agreed. I only focused on programmers because they're the ones who have
to build abstractions that make sense to "lay people". Our goal
would/should thus be to make their abstractions naturally secure.

> Furthermore, just because capabilities do not have a direct analogy in
> the real world does not mean that they are necessarily hard to
> understand. 

To be fair, I don't think access lists have a direct analogy in the real
world either; they are both idealized abstractions.

> I also found that there is a large dictionary of technical terms which
> one has to learn, and there are dialects as well.  In fact, every
> capability-based system seems to be different, and the differences
> matter greatly in understanding how they can be used in practice.
>   

Indeed. I think E and "security as design patterns" will be most
fruitful here.

> So, maybe I am overemphasizing the issue of human nature.  But even
> with all of the above in mind, I don't believe that a good
> human-computer interface will reveal implementation details like
> capabilities. 

I agree, with the caveat "except when necessary". Sometimes the only way
to achieve a goal is the hard way. http://www.freenigma.com/   might be
good enough for most people, but it probably isn't enough for those that
can accept nothing less than the security guarantees provided by PGP
(the security not provided freenigma of course).

Sandro