[cap-talk] Terminology for Confused Deputies, rights amplification example
Jed Donnelley
capability at webstart.com
Wed Feb 6 02:36:32 EST 2008
On 2/5/2008 7:51 AM, Jonathan S. Shapiro wrote:
>On Tue, 2008-02-05 at 01:43 +0000, David Hopwood wrote:
>>'When I use a word,' Humpty Dumpty said, in rather a scornful tone,
>>`it means just what I choose it to mean -- neither more nor less.'
>>
>>'The question is,' said Alice, 'whether you can make words mean so
>>many different things.'
>This quote was in my .signature for many years. But shame on you for
>chopping off the conclusion:
> 'The question is,' said Humpty Dumpty, `which is to be master --
> that's all.'
>The entire point is that whoever controls the lexicon controls the
>dialectic, and consequently the outcome(s).
Whew. Thanks for that clarification Jonathan! Never
a more clear situation than the current one in my
opinion.
Of course I think we aren't concerned here with a
kind of power except in so far as it results in
improved clarity.
That's where this situation regarding terminology
for Confused Deputies seems so difficult to me.
Perhaps we need some different terminology.
I believe the facts of the situation are quite
clear. Let's take the case of rights amplification.
This is a situation where two capabilities can
be combined to yield more "rights" (trying to
pick a generic term - the ability to successfully
carry out more operations as invocations than
would otherwise be available) than either would
by itself convey. Just for the sake of simplicity,
let's suppose we have two capabilities like
1. Light control permission, and
2. Light A control.
The idea here is that to be able to control
any lights at all, you need to have the
"Light control permission". Even with
that permission you still need a capability
to control any particular light (turn it
on or off).
The "Light control permission" provides
the global right to turn on lights, but
it must be combined with a permission
like the "Light A control" to actually
be able to turn on and off a specific
light. You must invoke the general
"Light control permission" capability
and pass it a capability to control
a particular light with any request
to turn on or off a light.
Now let's suppose we have two subjects,
Alice and Bob. In our initial conditions
if we look at their c-lists we see:
Initial conditions:
Alice Bob
<empty> "Light control permission"
At this point in time neither is able to
turn on or off any lights. Alice because
she has no capabilities at all, and Bob
because, even though he has the general
right to turn on and off lights, he
doesn't have any permissions to turn
or off specific lights.
Now somebody from on high grants both
Alice and Bob the same new capability,
"Light A control" and we end up with
this situation:
After God strikes:
Alice Bob
"Light A control" "Light control permission"
"Light A control"
At this point, sadly, Alice still can't
do anything. Even though she now has
a capability that would give her control
of Light A IF she had the global "Light
control permission", she doesn't have
that general right, so she still can't
do anything.
On the other hand Bob is now enabled.
With those two capabilities Bob can
now turn on and off light A.
Such rights amplification may be controversial
and problematic in various ways (one of which
will show up here), but I hope we all understand
it.
Here we have a situation where we have
"given" the same capability token to
two subjects, and the resulting ability
to do things is different. Bob is able
to do more with the capability token
than Alice is.
Now consider the following situation:
Alice Bob
"Light A control" "Light control permission"
"Send to Bob"
At this point can Alice turn on Light A
or not? It seems that this now depends
on the behavior of Bob. As Jonathan says,
whether Alice has the "authority" to turn
on light A or not is an "emergent" property.
If Bob is helpful but dumb, then Alice
may send a message to Bob:
'Please turn on this light <"Light A control">.'
If Bob would then invokes his "light
control permission" and pass it the
"Light A control" that he received from
Alice, then the light A would be turned
on. At that point we would suddenly
realize that yes, Alice really did have
the "authority" to turn on light A as
soon as she received the capability
to send a message to Bob because of
the way Bob was programmed. Alice's
"authority" to turn on the light
"emerged" from Bob's behavior.
In this case I'm not sure whether we
should use the term "confused deputy"
for Bob. I'm unsure because in this
case Bob does have enough information
to determine what rights were communicated
from Alice. We could say that Bob may
indeed foolish (buggy?) because Bob
combines his personal "Light control
permission" with the capability passed
to Bob from Alice. I don't believe that
Bob is a "confused deputy" in the sense
that Norm Hardy initially described when
he coined that term, though there is
the potential for Bob to be confused.
To really confuse a deputy you need to
create a situation in which the deputy
has no way to determine what authority
the sender of a request had so the deputy
unwittingly, despite its best effort,
is forced into a dilemma where it will
"emergently" grant more rights through
the communicated capability than it
intended to (intending to only allow
Alice the rights that Alice communicated
in the message).
At this point I intend two additional
messages:
1. Terminology for Confused Deputies, Nickel review of Horton, and
2. Terminology for Confused Deputies, Horton induced confused deputies.
Watch this list to see if I get there ;-)
--Jed http://www.webstart.com/jed-signature.html
More information about the cap-talk
mailing list