[cap-talk] Wikipedia: Object-capability model - excluding distributed case?

[Jed Donnelley]

At 10:03 AM 1/8/2007, Mark S. Miller wrote:
>Jed Donnelley wrote:
>...
> > In defining the "Object-capability" model, do we intend to exclude
> > distributed (network) systems where any notion of a "capability"
> > (communicated object reference) must necessarily be serialized
> > (data)?
>
>Yes, they are excluded. Network cap systems[*] cannot be objcap 
>systems, since
>they cannot implement the properties guarantees by the objcap model, as
>explained in section 11.5. I would say that cryptographic capabilities are
>capabilities, but cryptographic/network capabilities systems are 
>distinct from
>objcap systems.

In your section 11.5 you say you are distinguishing "The Limits of 
Decentralized
Access Control":

"This dissertation mentions three forms of capability system: 
operating systems like DVH,
programming languages like the non-distributed subset of E, and 
cryptographic capability
protocols like Pluribus. The object-capability model we have 
presented applies only to the
first two: operating systems and programming languages. Our model 
implicitly assumes a
mutually relied upon platform, which is therefore a central point of failure."

However, in fact when I read what your concerns seem to be they focus more
on limits on a decentralized system when viewed from the perspective of
an unconstrained communicator on the network.

Let's see if I can make some progress by stepwise refinement.  We agree
that a single E system qualifies as an "object-capability" system.

Now let's consider two (just two) such systems that have a hard wired
connection between them.  Further consider that the inter "Vat"
communication mechanism doesn't use Swiss numbers, but rather just
indexes into a list of remotely accessible objects.  This is more along
the lines of the DCCS which used no encryption.  It's simpler in that
unlike the DCCS there are no third party transfer issues to deal with,
so there's no need for a mechanism for A to introduce B to C and
there's no need to note which emulated objects are accessible by
A and which by B.  Everything listed is accessible by the vat
communicator at the other end of the line by simple identification
with an index.

Does this dual node distributed system qualify as an "object-capability"
system?  I argue that from the perspective of objects running within
the systems their view is indistinguishable from a single E system.
They are confined just as in a single E system (11.5.1), and the
*-properties can be enforced just as in a single E system (11.5.2).

Regarding  "11.5.3 Implications for Revocation", I believe such a two
node system is as capable of dealing with dependence on transactions
just as much as is a local system - except that of course it has a bit
more hardware that could fail.  Even in a local system I argue that
hardware failures can cause what appear to be incomplete message
transmissions or message transmissions that haven't been acted
upon.  Perhaps I'm a bit sensitive/tuned to this situation because
of the way local process to process communication was handled in the
NLTSS system.  In that system local communication could either happen
by direct memory copies (in the usual case that both the sending and
receiving buffers could be brought into memory simultaneously) or
by buffered communication.  Just as with any effort to deal with the
Two Generals problem, such buffered communication could fail with
a transmission initiated but not acknowledged.  Since I argue that such
failures can happen in the local, single node, case - I don't see a reason
to exclude the two node case from qualifying as "Object-capability" for
that reason.

Let me stop there and ask whether this dual node system with local
E on both ends and no cryptography between qualifies as an
Object-Capability system.  If not, why not?

One thing is true.  The vat implementation on either end can access
all the objects emulated at the other end.  Is that much alone sufficient
to be disqualified from the "Object-capability" category?  Of course one
can create such extensions to a single E system within a single vat.
Such extensions are no longer "object-capability"?

I really don't get it.  Of course even beyond that I will be very sad
if a focus on "object-capability" systems excludes what I consider
to be the dominant relevant case - namely the distributed case where
"the network is the computer".  I guess in that case I'll have to retreat
up a level to deal just with "capability" systems.  Still, I very much want
to understand why others feel that is necessary.  What the functional
requirements are that can't be met in the distributed case.  If we
can deal with/accept this dual node case, I believe the general network
case can be handled and included in the "object-capability" fold...

Of course what then is excluded may still be an interesting question.

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