[cap-talk] Authority is always potential (was: Re: Reinterpreting POLA...)

[Jed Donnelley]

On 9/19/2007 12:29 AM, Toby Murray wrote:
> On Tue, 2007-09-18 at 13:42 -0700, David Wagner wrote:
>> Toby Murray writes:
>>> Indeed. In either case, however, the user would be unhappy were the
>>> mailer to have the (behavior and) ability to insert "not" into the
>>> user's message or otherwise corrupt its meaning. When analyzing a model
>>> of the mailer, what I care about, then, is whether the behavior
>>> represented by the model allows the mailer to acquire authority that
>>> exceeds that which the user is willing to trust it with -- i.e. whether
>>> in the model (which is assumed to capture all possible behaviors of the
>>> relevant mailer) the mailer can perform or cause the user's message to
>>> be corrupted.
>> Got it.  Now I understand where you are going.  It makes sense.
>>
>> Your final (nicely worded) paragraph illustrates a confusion of my own.
>> You point out the distinction between ability and behavior.  The ability
>> of the mailer is independent of its code and is determined by things like
>> what capabilities it is provided with, what restrictions the underlying
>> platform or OS enforce, and the behavior of other entities that it
>> interacts with.

Hmm.  I appreciate the struggle you seem to be having with terms
here, with DavidW using "ability" for what Toby later seems to
refer to as "potential authority".

DavidW:
>> The behavior of the mailer depends on the code of the
>> mailer as well as on its ability.  When we talk about the authority that
>> the mailer has, do we mean to take its behavior into account, or only
>> its ability?  I am used to thinking about the authority of an entity
>> only in terms of that entity's ability, not its behavior.

I'm completely with David on this one in that for me the
"authority" of an executing program is determined by
its environment and is what DavidW refers to above as
its "ability" (which I think is an unfortunate term for
this meaning) and what Toby refers to below as the
"potential authority" (also unfortunate in my opinion)
of the executing program:

> There is a very real distinction between "potential" authority and
> "actual" authority. Potential authority should always be a superset of
> actual authority.

I call this simply the 'authority' of the executing
program.  I believe this is the common usage and hope
we can agree on this.

> One can compute potential authority of an object by making no
> assumptions about its behavior and, therefore, modeling the object to
> exhibit all legal possible behaviors.

That is why reasoning about the authority (not 'potential
authority' or 'ability') of an executing program is so useful.

I hope this isn't a tangent, but of course it's also
important to consider the input to an executing program
when consider the range of its possible behavior.  For
example, a program might be an interpreter of some sort
(e.g. common scripting languages) where the range of its
behavior can vary widely depending on what input it
receives (what script it is asked to execute).  In
such a case I would guess that Toby would say that the
executing program's 'actual' authority may be driven by
its input to closely approach its 'potential' authority?
Similarly input like a buffer overflow may affect the
behavior of a program in whatever authority environment
it might find itself.

I consider an executing program's potential authority
simply its 'authority', and its 'actual' authority as
that part of its authority that it exercises in any
situation.  I don't have a term for what one might consider
a reasoned limit on that part of a program's authority
that it may be able to exercise based on its coding.

I understand that Toby is focusing on reasoning about
the potential behavior of programs from knowledge about
the program code:

> Often, I think the choice of whether to try to model potential or real
> behavior (which will lead to computing potential or real authority,
> respectively) will be based on how much one knows about the software
> they are modeling.

For example, if one has the program:

halt;

it's safe to assume that no matter what authority it
is executed with and what input it is given, it will
not exercise any of its authority.

> Suppose we had some magical means to produce CSP models from real code,
> such that the model produced was guaranteed to exhibit all possible
> behaviors of the code. Suppose further we have some abstraction that
> has been coded and we want to reason about its properties. We can derive
> the (accurate) CSP model from the code and then reason about the actual
> authority of internal entities that make up the abstraction.
> 
> But now suppose we want to know how that abstraction affects the
> authority of the objects, o,p,q,... with which it is composed. Then the
> correct thing to do, imo, is to model o,p,q so as to exhibit all
> possible legal behaviors, within the constraints of the model and the
> behavior of the abstraction. Now we're reasoning about potential
> authority.

Can we please stick to referring to the 'potential' authority
of the executing program as its 'authority' (e.g. much as we
do with a person) and use some other term or terms to express
constraints on the program's behavior that may arise from the
coding of the program?

I admit that I don't know what term to use for any such
constraint (independent of the program environment which
defines its "authority" and it's inputs), perhaps others do,
but I hope it doesn't involve the use of the term "authority".

--Jed