[cap-talk] Toby's Confused deputy statement (was: Re: Confused deputies in hybrid systems)
Jonathan S. Shapiro
shap at eros-os.com
Thu Feb 7 10:29:57 EST 2008
On Wed, 2008-02-06 at 11:43 -0800, Jed Donnelley wrote:
> On 2/6/2008 1:03 AM, Toby Murray wrote:
> > On Tue, 2008-02-05 at 21:31 -0500, Jonathan S. Shapiro wrote:
> >> I am not sure how to proceed here. I simply raise the issue. Offhand,
> >> the issue seems to imply a need to define some sense of "intent" -- at
> >> least for some forms of analysis. That strikes me as a potentially
> >> sticky wicket. Possible in some cases, but frought with opportunities
> >> for erroneous models.
> Whew, I hope not. The notion of the authority that a
> capability adds seems pretty clear to me (operations,
> no matter how emergent, that can be performed with the
> capability, but not without it).
But the scenario at hand does not entail adding a capability. It entails
communicating an existing capability (or not) and the impact of that
decision. The complication is that if we restrict these communications
incorrectly in our model, we will discover that other, potentially
interacting, elements of the overall system behavior will be
Depending on the problem we are trying to model, this will all prove to
be either very easy or completely intractable. I predict there are few
cases in the middle.
> >>>> 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.
> >>> I think this corresponds to what I said above about measuring the
> >>> difference between a subject's authority when it may, and may not,
> >>> perform a particular action. Let me know if I've misinterpreted you here
> >>> though.
> >> We seem to be converging. Did my comments above address this point?
> > Yes.
> Converging I would say, but the terminology still sounds
> what I hope is unnecessarily convoluted.
The terminology is completely straightforward. It's just that it doesn't
mean what you want it to mean.
Challenge: please try to state what *you* mean by "adding a capability"
and its impact on authority. Try it first using reasonably precise
English, and then try to formalize it. I suspect you will find that the
notion you are trying to capture proves to be very squirmy indeed.
> In the interest of simplicity can we try the modification of
> Toby's original (simple) statement that I suggest in:
> In any case in which a service may get more authority than its client
> from a capability, the service is potentially confusable by that
> capability sent from the client.
For reasons that I have already addressed -- and that Toby has agreed
with elsewhere -- this statement is devoid of content unless we are
prepared to formally analyze the program obeyed by the service. In the
absence of such analysis, the service is presumptively a maximal
conspirator, and the client and the service therefore have identical
authority throughout the scenario.
More information about the cap-talk