[cap-talk] Capability analogies

[David Hopwood]

Ka-Ping Yee wrote:
[...]
> The typical real-world analogy for a capability system is a key.  If
> you possess the right key, you can unlock the door and enter the room.
> This analogy errs *against* capabilities:
> 
>   - It ignores confinement.  People are free to move about the world
>     and interact with anyone.  So, naturally you can give anyone your
>     key, or a copy of it.  Not true for programs.
> 
>   - It ignores delegation, to a degree.  It is usually obvious that
>     keys are easier to delegate than IDs -- you can lend your friend
>     a key.  But it is not usual for people to carry around key cutters
>     and make duplicate keys instantly, whenever they want.
> 
>   - It ignores behaviour.  Keys are inert, but capabilities have
>     programmable behaviour.  You can't give a key to a key.  That's
>     nonsense.  But of course you can pass capabilities as arguments
>     to other capabilities.
> 
>   - It ignores attenuation.  When people think about keys it doesn't
>     occur to them that one could create keys on the fly that provide
>     temporary access to the room -- or even to different parts of
>     the room.  It is completely counterintuitive that one could do
>     this without rekeying (reprogramming) the door, but just by
>     programming the keys.

It also ignores the fact that in a capability system, capabilities are
the usual way to designate anything. In terms of the analogy, it is as
if everyone spoke in a language in which words were keys (and you could
only speak a word if someone had spoken it to you, or if you had made
it up uniquely).

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>