[cap-talk] Is "Authority" Subjective?

[David Wagner]

Marc Stiegler writes:
>Yes, there is a bit of subjectivity in the meaning of "authority".

I agree, but I think the primary bit of subjectivity is in what kinds
of authority we consider relevant and which we consider negligible.

For instance, one could argue that the ability to perform pure computation
is itself an authority (it consumes electricity and so has an externally
visible effect on your electric bill, for instance; also, it uses some of
your CPU and so has an externally visible effect on how responsive your
machine is to remote clients).  But for the most part, for the authority
analyses we tend to do, this is usually not the kind of authority we
usually care about.  Therefore, we deem that kind of authority "below
notice" and "ignorable".

As a way of shorthand, we might say that the ability to perform pure
computation (or not) is not an authority at all.  That way we can say
nice short statements like "this code has no authority", even if what
we really mean is that "it has no authority worth mentioning" or "it
has no authority other than the ability to consume CPU cycles".

I suspect that in any security analysis, there is an implicit step where
decide and agree upon what kinds of authority are not worth mentioning
(and hence shouldn't be considered authority at all, for purposes of that
analysis) and what kinds are relevant.  That involves drawing a line,
and that is indeed subjective and potentially domain-specific.

For instance, in some cases we might put pure computation and knowledge
of secrets in the "not considered authority for purposes of this analysis"
category, and ability to influence the data sent to remote clients in the
"considered authority for purposes of this analysis" category.

However, once we've agreed upon these categories, I'm not sure there
is any subjectivity left.  It might be that there is a notion of authority
that is completely objective, once we've agreed on what should and shouldn't
count as authority.

Notice that while this categorization may be left implicit, you may be
able to partially recognize what a language designer considered "not worth
mentioning" by what abilities are ambient.  The ability to perform pure
computation and to allocate memory is ambiently available to all code in
many object capability languages, reflecting the designer's categorization
of pure computation and memory allocation as "not worth considering".

Still, despite the apparent subjectivity of how to draw these lines,
I suspect there is a great deal of consensus among everyone over the
broad outlines and on most aspects of those decisions.  For instance,
we probably all agree that the ability to overtly cause side-effects
that are externally visible ought to count as authority.  (We might have
to decide what we mean by "externally" in any given application, but in
practice it's often clear enough.)

>Consider 3 cases: the authority to invoke the object that will create
>a new List object, the authority to invoke the object that will create
>a new Mint object, and the authority to create money in an existing
>Mint object.

My analysis:

1) Ability to create a new List object is usually not considered
authority, because it is indistinguishable from pure computation and
does not have any overt side effects that are visible to the rest of
the program.  In other words, instead of invoking the ListMaker object,
you could have just written your own MyListMaker which does exactly
the same thing, and no one else would be able to tell the difference.

2) I don't recall mintmaker well enough to know whether this ought
to be considered to invoke authority.

3) Creating money in an existing Mint object does carry authority if
that Mint object is reachable from any other external object, because
then it is an externally visible side effect to an object whose state
others can view.  On the other hand if some function f() internally
allocates a new Mint object, creates some money in it, then destroys it,
without allowing it to escape or be captured by any enclosing scope,
this causes no externally visible side effects (outside of f()).
While in principle we might be willing to say that the transaction,
taken as a whole, didn't involve any authority, that's probably not
a very helpful way to talk about things.  In practice, we have to assume
that the act of adding money to a Mint object may potentially create
externally visible side effects and thus must be considered an exercise
of authority (this may be a conservative view, but at least we won't
err on the side of failing to notice some relevant exercise of
authority).

>Ah, but now consider an existing mint, being used by other people. We
>consider the ability to manufacture money inside this mint *is* an
>authority. Is it pure computation?

Well, I'd say that it is not pure computation.  By definition, it is not
"pure" if it causes side-effects to state that is visible to other parts
of the program.  You are mutating state that is externally visible --
where by "externally" I recognize that it may not be visible to clients
on any other machine, but nonetheless it may still be visible to other
clients on this same machine and thus must be considered "externally
visible".  By "external" I mean "external to the code performing the
allegedly-pure computation".

Comment: The strict definition of "pure" requires that the code have no
side effects at all if you want to classify it as "pure".  However, a
common relaxation of this definition allows us to classify a computation
as "pure" if it causes side effects but those effects are not externally
visible.  For instance, if you allocate a new array of integers, operate
on them, and finally destroy the array without allowing any of that
to become externally visible or to escape or aliased, then we might
be willing to call this a "pure" computation even though it involves
side effects.  In other words, anything that is indistinguishable from
"pure" computation is also reasonable to call "pure".