[cap-talk] Another "core" principle - Brinkmann

[Jed Donnelley]

At 05:34 PM 12/28/2006, Jonathan S. Shapiro wrote:
>On Fri, 2006-12-29 at 01:25 +0100, Valerio Bellizzomi wrote:
> > >Precisely. If the model ignores this, it's both non-believable and fails
> > >to model observability correctly.
> >
> >
> > Can you expand on Observability ?
> > I will read your reply tomorrow, heading to bed now :-)
>
>Suppose that I (a keeper of the space) can write a mapping slot. You (a
>client of the space) cannot read the capability in that slot, but you
>can traverse it. By reading the thing that it points to, you can
>determine that the capability in that slot has been altered.

On a meta note I'll mention that I'm often unhappy with what I
regard as the varied nuances of descriptor type object-capability
operating systems because they can provide so many different
sorts of capability communication mechanisms.  The implementors
of such systems seem to regard this opportunity to vary the
interface as valued flexibility.  To me it argues against
consistency in the object-capability paradigm and works against
any hope for a consistent object-capability message.

One level down I can explain my dismay with such nuances by
noting that it will be difficult to impossible to map any
such variations into a common network-wide object-capability
communication scheme.  This is a reason that I feel it's so
important that any object-capability system implement
something the DCCS that transparently maps the internal
capability objects across a pure data network to see
what sort of protocol they can map to - e.g. in
collaboration/cooperation with other object-capability
systems.  If we can't come up with an inter operable standard
for object-capabilities, then I fear our hopes for greater
market share are dim indeed.

Finally, let me address this particular instance.  Firstly,
I confess ignorance of the specifics of the implementation that
the above paragraph applies to, so I may be misunderstanding
something.  Accepting that possibility, however:

The above paragraph where "You (a client of the space) cannot
read the capability in that slot, but you can traverse it"
suggests a situation where a subject has a permission ("you
can traverse it") but cannot share it ("You ... cannot read
the capability).  This drops right back into mechanisms
that prohibit capability communication (delegation in the
most limited sense) - forcing something like a proxy
mechanism for modular extension of services in accord
with POLA and seeming to try to create illusions about
blocking communicating conspirators.

To me any such mechanism is anathema.  I regard such mechanisms,
in addition to being misleading, as working against modular
extensions that are faithful to POLA.  I'm interested to hear
others (e.g. Shap) defend such a mechanism.

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