[cap-talk] Toby's Confused deputy statement (was: Re: Confused deputies in hybrid systems)

[Jonathan S. Shapiro]

On Tue, 2008-02-05 at 15:52 +0000, Toby Murray wrote:
> On Tue, 2008-02-05 at 10:34 -0500, Jonathan S. Shapiro wrote:
> > After about three seconds thought, how about:
> > 
> >   In any case in which a service may get more PERMISSION than its
> >   client gets PERMISSION from a capability passed to it by its client,
> >   the service is potentially confusable.
> > 
> 
> See my later message in which I tried to say the same thing. I also
> generalised it further to
> 
> In any case in which a service may get more AUTHORITY from a capability
> passed to it by its client, than the client can from the same capability
> without using the service, then the service is potentially confusable.

Toby:

I think at this point we agree about what is going on, but I don't think
that this generalization is strictly right. I want to push this
discussion a little further in an attempt to clarify what we mean by
"authority" in order to explain why.

Authority is an emergent property. It is, in effect, all of the
operations that might be induced to occur (effected) in the system by
proceeding from a given configuration. In consequence, authority does
not grow, and we cannot sensibly speak about "getting more authority" as
the result of an action that is (at some point) permitted when
proceeding from a given state.

It may be that we will come back to the informal English convention that
you adopted above, but I want to understand what it means. I see two
issues:

  1. It is difficult to speak about the authority of a single process,
     because authority is a transitively emergent property. So I must
     ask: what do you mean when you speak about the authority of a
     process? [You made a cut at this below]

  2. Under this definition of authority, the closest I think we can come
     to speaking about "getting more authority" is inducing a partition
     on the universe of future computational states, one subset being
     the future states in which the action that "got more authority"
     never occurred.

As I say, I have no objection to going back to informal language, but
I'ld like to understand clearly what we actually mean when we use it.

You made a cut at this:

> How would we measure such a thing?
> 
> 1. Define the service's authority once it possesses the capability.
> 
> 2. Define the client's authority with the capability but ignoring all
> authority that arises from invoking the service (i.e. all effects the
> client can cause by invoking the service).
> 
> If 1. includes any effect that is not in 2. then the service is
> confusable.
>  
> Note that if we ignore causation and consider only permission, then thsi
> collapses to your definition above.

Yes. That all seems right.

> > The problem here is one of analytic detail. If we are prepared to
> > analyze the behavior of the service (i.e. its program) then it may be
> > possible to draw sensible distinctions between the authority of the
> > service and the authority of its client.
> > 
> > But in the absence of such analysis, I believe that we must proceed more
> > conservatively, and assume that the service obeys the will of its
> > clients. Under this assumption, and excluding other environmentally
> > imposed restrictions, the client's authority is presumptively identical
> > to the service's authority.
> > 
> 
> Essentially you're assuming the service is akin to a proxy then?

I am assuming that ANY process is either modeled or must be presumed to
conspire. In this sense, it is worse than a proxy (as you defined it)
because it can be requested to combine capabilities on behalf of the
client.


shap