[cap-talk] Confused deputies in hybrid systems (was: Loss of control)

[Jonathan S. Shapiro]

On Tue, 2008-02-05 at 09:09 +0000, Toby Murray wrote:
> On Mon, 2008-02-04 at 14:04 -0500, Jonathan S. Shapiro wrote:
> > On Mon, 2008-02-04 at 08:19 +0000, Toby Murray wrote:
> > > In any case in which a service may get more authority than its client
> > > from a capability passed to it by its client, the service is potentially
> > > confusable.
> > 
> > Your statement confuses permission with authority. The service did not
> > get more authority than its client held. The client had sufficient
> > authority to pass the capability into the service domain. In
> > consequence, any authority granted thereby to the service already feel
> > within the client's authority BY DEFINITION.
> 
> I see what you're trying to say but I disagree. Note that these are
> different KINDS of authority. When in the hands of the client, the
> authority is "authority to cause the service to perform X on my behalf",
> when in the service's hands its "authority to perform X directly". 

First: this is not a disagreement about whether there is an issue, and
it is only mildly a disagreement about the characterization issue. It is
a disagreement about the use of terms. Your statement above makes it
very clear that you are not using the term authority in a way that is
consistent with the rest of the capability discussion.

If we wish to do a term rotation, that's fine, but we have a large
archive of discussion using the previous definition of authority, and I
suggest that we should find a new term for this new meaning.

> Now depending on your notion of authority, one may argue that the
> authority to do something directly vs. the authority to cause another to
> do it for you, that the former is always strictly GREATER than the
> latter because one need not rely on anyone else to exercise it.

I see the line of argument. I think there are two different cases:

  1. If I merely rely on the other agent to perform its specified
     function, then the cause of reliance failure is bugs, and that
     is no more likely to happen in the agent's code than in mine.

  2. If I rely on somehow tricking the agent into doing my will, then
     yes, I agree that there is a weakening effect.

At this point we must consider authority in the context of trusted
programs. Basically: unless you admit and analyze the behavior of the
agent program into the model and deal with it, the conservatively safe
assumption is that the agent program will do what is told. That is: it
conspires maximally.

> Hence, I stand by my claim that the problem is that the cap is more
> poweful in the hands of the sevice than the client (i.e. grants the
> service more authority than it does the client).

In the strictest sense this is probably true. It is only *usefully* true
if you are prepared to admit the service program as a trusted program
("trusted" meaning: we have analyzed it).

I would prefer to find a new term here, because "trusted program"
carries connotations that I do not intend. I think what I want is
something closer to "admitted program", meaning simply that we are
taking explicit account of the program's behavior in our analysis.

shap