[cap-talk] Wikipedia: Object-capability model

[Jed Donnelley]

At 08:15 AM 1/5/2007, Mark S. Miller wrote:
>Ka-Ping Yee wrote:
> > I think it's high time Wikipedia had an article entitled
> > "Object-capability model".

Delightful.  This will certainly give me a chance for review,
though it means yet more reading...  Let me just react to what
you have written so far:

> > Here's what i think should go in the main definition of the term:
> >
> >     1. Objects access or designate other objects through unforgeable
> >       references (pointers).

Would this be clearer with wording like:

1.  Active objects designate and are granted access to other objects
through unforgeable references (pointers) termed "capabilities."

?  I realize the whole "active object" vs. "process" business comes
up here.  I believe these terms are synonymous.  Perhaps that's worth
stating for clarification:

1.  Active objects (processes) designate and are granted access to
other objects through unforgeable references (pointers) termed
"capabilities."

?

> >     2. Computation is performed by sending messages along these
> >       references to other objects.

2.  Computation is performed by sending messages containing data
and capabilities along these references to other objects and
receiving data and capabilities in reply.  This send/reply
scenario is usually termed an "invocation".

Am I wrong about that "invocation" term?  Is there something in
this effort to distinguish the object-capability model from historical
"capabilities" and capability-based systems?  If so, that's fine, but
isn't it also wise to bind to that historical thread and at least
point out comparable terminology?

Without explicitly mentioning a reply (receiving on some context) there
is no way to get more capabilities.  Of course the notion of sending
requires a dual receiving.  Seems it should be noted.

> >     3. One comes to have a reference to an object via (a) creation,
> >       (b) endowment, or (c) introduction.

Hmmm.  Perhaps here is where I already need to do some more reading.
I think I should provide an initial reaction before doing such reading,
coming as it does from my historical perspective.

 From that perspective I would rewrite the above as:

3.  Active objects come to have references (capabilities) to
other objects by initial conditions or by receiving them in
response to invocations.

I don't see any need for a separate "creation" category.  Is either
"endowment" or "introduction" the receipt of a capability as noted
in #2?  If so, what is meant by the other?  Are you referring to
outside access to ... "my" c-list?  In that case it sounds to me
like a special case of "initial conditions" with different timing.

I guess now it's time for to reread MarkM's thesis ;-)

> > Is that enough for a precise definition?
>
>No, but it's a great start. It probably is the right thing for a high level
>summary on the wikipedia page, given that the reader is referred 
>elsewhere for
>a more precise statement. The one thing I would add to it, even as a summary,
>is "(d) initial conditions".
>
>* It doesn't account for how local naming preserves distinctions. That's why
>there's all this stuff about "index" in Section 9.1 "The Object-Capability
>Model". This logic needs to be stated to account for how (and how much) an
>object can come to know about other objects by interacting with them. Without
>this, one cannot precisely account for confused deputy issues. See 
>for example
>previous e-lang discussions about "c-lists as sets" vs "c-lists as maps".

Hmmm.  Do you (MarkM) believe this level of detail is necessary?  After all,
one need not make the same distinctions about data.  When "I" receive data
from some other source (e.g. as part of an invocation) I know where it came
from and where it went to.  There is just as much of a "confused deputy"
problem with data as with capabilities (e.g. consider the data as a capability
as data such as a password).  Similarly with any capabilities that I might
receive.  That much obvious knowledge (the knowledge of what, from whom,
to where) suffices (and indeed is all that is available) to deal with
confused deputy issues.

If the distinction is important for capabilities then I believe it should
include the equivalent discussion about data.

>* It doesn't explain how new code enters the system. My attempt to state the
>issues here precisely, in my Chapter 10, is the least clear part of 
>my thesis,
>and the one most needing a rewrite. However, without making these 
>points, it's
>hard to say why existing memory safe encapsulated object languages like Java
>and Smalltalk are not object-cap languages.

I wonder if being more explicit about data in the definition might suffice
to cover this topic.  That is, data can be made available to an active
object also via 'initial' conditions (here I include any outside access
to the object, whether initial or not) and as the result of invocations.
Such data can of course be code.

>* It doesn't say that an object is *only* able to (overtly) affect the world
>outside itself according to the references it holds, and is only able to be
>effected by the world outside itself according to those who hold 
>references to it.

I agree that this is an important point.

> > (The rest of the article, which i hope you will all help me write,
> > can cite systems and papers and compare the specific meaning of
> > "object-capability" to the usage of "capability" in security theory
> > and the usage of "capability" in practice.)
>
>I think it's a great idea! Please do!

Ditto.  Good stuff.

--Jed  http://www.webstart.com/jed-signature.html