[cap-talk] In defense of Object Capabilities (was: Non-Delegatable Authorities in Capability Systems)

[Jed Donnelley]

On 12/19/2007 8:28 AM, Karp, Alan H wrote:
> Jed wrote:
> 
> A whole bunch of stuff I agree with, but I'm less
> outraged than Jed.  I don't think of this paper as
> presenting a practical mechansim as much as disproving
> another "capability impossibility", much the way
> caretaker debunks non-revocability.  In that sense,
> the paper presents a political solution, rather than
> a technical one.  It addresses people who say "I can't
> use capabilities because I need to block delegation."
> even though the systems they build never actually do.

Good seque to my position:

I believe we as a community are waffling.  I don't
think we can have it both ways (sadly).  I assume
most of you listened to David Wagner's Google Tech
Talk and the others that preceded it.  The same
tired and wrong argument about "loose" capabilities
came up as a question there:

http://youtube.com/watch?v=EGX2I31OhBE

at 50m40s (anybody know how to make a URL
to that time mark for youtube?):

The questioner correctly stated about the
Object Capability model (somewhat
anthropomorphically): "If you have a
capability then you can give it to someone
else" (that you have a capability to...)

The questioner said, "That doesn't seem like
a good idea.  You might want to give someone
a capability but not give them the right
to pass it on to someone else."

David Wagner rightly answered with "Don't
prohibit what you can't prevent."  This
feeds into the well known communicating
conspirators situation (which I wish David
had referred to):

http://www.erights.org/elib/capability/conspire.html

that MarkM so effectively portrayed and
where he said:

"Can Alice arrange to prevent Bob from giving
Mallet the Power? The answer is simply no."


This argument comes up again and again.
I think we really need to decide how to
answer it.  We either need to argue, as I
have above that,

A.   This isn't really a problem - that
the object capability model is correct
and "best" in allowing all capabilities to
be communicated over capability enabled
channels (both because such communication
of authority can't be prevented anyway AND
because it's only by enabling such capability
communication that we have a fully modular
programming model), or

B.  Yes, this is a problem and here is
a solution (non-delegatable authorities
in whatever form).  In this second case
I believe we need to come up with an
appropriate form and stick to it.  We
need to make it widely available to those
who program within the Object Capability
model.


Why can't we waffle as I argue Alan is
doing?  We can't because it has become
abundantly clear with the coming together
of the object programming model and the
capability model that the power of this
model derives exactly from its "decomposability".
That is from the ability to break code into
pieces that can be reasoned about separately
that can communicate authorities according
to POLA.  If we support non-delegatable
capabilities we break that model.  With
non-delegatable capabilities we can't take
what was a single module/object implementation
and break it up into two or more modules/objects
with communicated authority because we might
not actually be able to communicate an
owned capability even to a new "sub" object
within our implementation.  Of course we
know that we could do so by proxying, but
then we end up always being prepared to
proxy and in fact using proxying as needed
to get around this misguided effort at
non-delegatability.

As I argue in my previous message:

Try to imagine non-delegatable objects in
a language like Joe-e.  I believe you simply
can't do it.  There may be some inadequacy
(kludge, hack) in E or possibly some other
'capability' models that appear to allow
blocking of communication of some capabilities.
In those cases I believe those situations need
to be fixed lest they lead to compounding
of the fissure in the model to seemingly create
non-delegatable capabilities (as Toby and
Duncan have ably done in their paper).

The basic problem is that non-delegatable
objects completely break the basic programming
paradigm of object programming.  I argue that
they (thus) break the basic capability programming
paradigm.  It's non-delegatable object capabilities
that are the bad idea.

We simply can't have it both ways.  I'm sorry.
I wish there were a way, but I don't see it.

If we take Alan's approach and argue that
the paper by Toby and Duncan demonstrates
that one can support non-delegatable
capabilities in the object capability model
then when people start writing code, they
are going to find situations where they
think - "Oh, at this point I'd like to
delegate this permission, but I don't
want it to be able to propagate further.
Now I need that non-delegatable capability
tool.  Where did I put that now?"

What do we give them?  What do we give them
in Joe-e?  How do we support such a mechanism
with the Waterken Server?  How do we support
such a mechanism in Coyotos?  What happens
when the object that they pass the non-delegatable
capability to needs to modularly make use of
another object with the communicated authority?

As MarkM said, "The answer is simply no."   That
thought, "...I don't want it to propagate further..."
is simply misbegotten.


> I also appreciate the beauty of the new pattern, much
> the way I appreciate Gothic architecture while not
> wanting to design my own home that way.

While I appreciate the cleverness of the technique,
I see it as somewhat like trying to create an
uncontrolled "goto" out of a loop construct or
perhaps more closely (since I see it as destructive
rather than constructive) like trying to show
how one program can destroy the modularity that
another created.

I think we need to make a decision on this issue
and stick with it.

Are we going to find ourselves, next year, in the
position of giving another object capability
presentation and having the same "loose"
capabilities question come up (it will) - this
time with a reference to the paper by Toby and
Duncan - and then ask, "Where is the non-delegatable
object reference mechanism in <>?" (Joe-e,
Waterken, Coyotos, ...)

I believe it's time to just say no to non-delegatable
capabilities.  I certainly feel that it's time to
"have it out" on cap-talk on this issue.  I respect
Toby and Duncan and I believe I understand the underlying
motivation for their effort and the concerns like those
expressed by the questioner after David Wagner's talk.
However, I believe the thinking is just wrong and
needs to be cut off if the object capability model
is to move forward.

--Jed  http://www.webstart.com/