[cap-talk] Wikipedia: Object-capability model - confused deputy?

[Jed Donnelley]

At 10:03 AM 1/8/2007, Mark S. Miller wrote:
>Jed Donnelley wrote:
>...
>Given the terminological confusion this has caused, even among ourselves, I'm
>wondering if such a common description was too much to hope for. In any case,
>I'll keep trying.

I'm still hopeful.  I'm afraid that some of the confusion may come 
from the medium.

>Although the objcap model is purposely incomplete as a model of
>computation, it is intended to be complete enough to explain how actual objcap
>systems are able to avoid confused deputy problems. To do this, it must talk
>about c-list indexes as well as message argument indexes (without making
>assumptions about whether these are the same or different). Since these
>indexes are data, the objcap model must speak (at some appropriately abstract
>level) about data.

The way I read the above is that you're trying to clarify the point that
in an object-cap model when a subject receives a message that
generally can contain data and capabilities (references to objects),
it can distinguish this data and these capabilities from:

Others that it may already have, and

Others received from other sources.

to be able to deal effectively with confused deputy issues.

Do we really need to delve into implementation issues like
c-list indexes to make this clear?  After all, in E there are no
"c-list indexes".  In a hardware capability system like the Plessey
250 (leaving aside whether it was pure 'object-capability') there
are no c-list indexes.

When one discusses parameter passing in computational
systems I don't believe there is any need to describe how
receivers distinguish passed parameters from other data
until one is looking into the implementation of a specific
system - e.g. offsets relative to the base of a stack, etc.

> > 1.  The "capability" term is more specific as it excludes
> > potentially other types of confusing references (e.g. data),
> > and
>
>In an earlier message of yours, I thought you agreed we need to discuss the
>handling of data in parallel to the handling of capabilities. By speaking of
>references, we get the economy of doing both in one breath.

I'm not arguing that the "reference" term isn't useful in it's more general
context, only that when defining the "Object-capability" model
we should focus on the specific sorts of references that point
to objects - "capabilities".

> > 2.  Using the term "capability" makes clear why the model is
> > called the 'Object-Capability' model and not the "Object-Access"
> > or "Object-Reference" model, and
>
>My take is that it's called the objcap model a) for historical reasons, and b)
>because, in the objcap model, data provides only information, so only
>capabilities provide the means to cause effects in the world outside oneself.

Right, "capabilities", not any other sort of reference (e.g. to data).

> > 3.  The term "capability" binds explicitly to the whole history
> > of capability based systems.  Of course this can cut two ways,
> > seeming to broaden the usage more than wanted in the subset that's
> > the "Object-capability" vs. the simple "Capability" model.
> > However, does using the "reference" term really help in that
> > regard?  To me that term is even more ambiguous.  At least the
> > "capability" term suggests the binding of designation and
> > permission.
>
>Since data provides only information, only non-data provides permission to do
>anything, so only references to non-data, i.e., capabilities, bind designation
>to permission.

Setting aside for the moment the discussion about capabilities as data,
from the above it sounds like we're in violent agreement.

>In the whole history of OS-based and network-based cap systems, data and
>non-data are usually distinct. However, the mechanics for handling them are
>quite parallel: They are both carried in messages. They are both held in
>per-subject address-spaces/c-lists. In both messages and
>address-spaces/c-lists, both caps and data are addressable by indexes which
>are themselves data.

All true (again leaving out the capabilities as data systems).  How does this
relate to the 'reference' vs. 'capability' discussion?

>However, although previous actual capability systems had this parallelism,
>previous models of capability systems often left out data, leading to models
>that could not account for why objcap systems enable one to write unconfusable
>deputies.

This is a part of the discussion that puzzles me in two senses.

Firstly, I don't see how it relates to the reference vs. capability terminology
issue.

Secondly, I find it pretty difficult to imagine a capability system that
"left out data" and that then somehow lead to potentially confused
deputies.

Perhaps you can clear this up for me again as you did so well
with the creation case by citing some examples?

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