[cap-talk] capabilities as channels and as communication protocols

[David-Sarah Hopwood]

David Barbour wrote:
> On Mon, Mar 2, 2009 at 9:23 PM, James A. Donald <jamesd at echeque.com> wrote:
> 
>> Do people think that this description of capabilities makes sense?  I
>> solicit criticism.
[...]
>> A capability is an object, object in the sense of "object oriented
>> language", that combines unforgeable designation with permission - it is
>> an object that enables an entity to do something, to do something to or
>> with a very specific thing, the thing designated.
> 
> What does 'unforgeable' mean? If I can guess at 160-bit numbers and
> eventually obtain a capability in a distributed system, was that
> 'unforgeable' or just 'difficult to forge'? To me, 'unforgeable' means
> 'impossible to forge', which physically cannot apply to delegable and
> transferable capabilities in a distributed system. All we can do is make
> forgery arbitrarily, and cryptographically, difficult - and then mount a
> more active defense to detect likely forgeries.
> 
> And regarding "object" and reference to "object oriented language" - that's
> poorly defined. You'd need to eliminate issues of, say, examining references
> to the caller or the call-stack as is performed in Common Lisp for its
> condition-reset mechanism. You'll also face issues that in most object
> languages, you have capabilities to do stuff even without object refs.
> You'll further face issues that many OO languages lack any sort of
> protection against viewing their guts, such that they cannot grant
> capability to JUST do a specific thing - they grant the whole gamut of
> implementation.
> 
> And then there is "enables". You could create an unforgeable reference to an
> object that opens a file... but if that capability is part of the
> environment ('ambient'), then anyone to whom you passed the object isn't
> getting any new capabilities... they're just getting a helper object.
> 
> Besides, you should define 'capability' first, then explain why 'objects'
> can (under certain constraints) be such fine examples of them. That would
> help eliminate the object-capability bias, and force you to reduce
> conceptual dependency on ill-defined concepts.

I agree with all of these comments.

[...]
> No, capability *grants ability*. That's the reason it includes a
> communications channel or the ability to open one. Ability isn't a feature
> of permission. Ability AND 'permission' are both features of capability. If
> you grant one decoupled from granting the other, you did not grant a
> capability. Granting ability without authority is just dangerous, since then
> you need to control use of the ability by other mechanisms (usually 'trust'
> and more active detection + rectification). Granting authority without
> ability is often futile, though it does work at times as an element of
> rights escalation.
> 
> Anyhow, that's my criticism. I'm reluctant to mention it to a forum that is
> so object-capability biased and that doesn't bother rectifying
> distributed-system capabilities with misleading phrases like 'unforgeable'
> despite the clear examples in Pluribus.

If any Pluribus documentation says that its capabilities are "unforgeable",
that documentation is imprecise, and should be changed to say "unguessable".

> Last time I said even suggested that capability might allow for more
> than object capability, I received confusion from many ...

Capabilities definitely include non-object capabilities, otherwise there
would have been no point in making the distinction by introducing the
"object capability" terminology. Since object capabilities are not directly
transferrable over a network, and most people here are interested in
networked capability systems at least to some extent, I find it surprising
that there was any confusion about this.

Object capabilities do have clear advantages over non-object capabilities
where they are implementable. Besides the most commonly mentioned advantage
of supporting confinement, object capabilities allow precise garbage
collection of capability-referenced objects, since it is possible to
reliably trace the graph of capability references without having to
recognize capability representations in data. That makes them more suited
to language-based capability systems.

> ... and attacks from a subset of that many.

What name did you post under? I only find 4 messages from anyone with
name containing "Barbour" on cap-talk (since 2003), none before 2009-08-02.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com