What is defensive consistency?

Dean Tribble writes:
>How's this for a definition: A client is  a holder of the capability with an
>independent interest from the holders of the capability. That's a very
>general distinction, but I think that's OK. Within a security domain, I
>would still want to be able to separately analyze (the reliance sets of)
>multiple clients of the same object.

That's great.  Very helpful!  I like this way of thinking about it.

Unfortunately, this feels a little bit like an "aspirational" goal.
It describes what we should strive to achieve, but what does it mean
for the programmer who has to write the defensively-consistent code?
If a server is invoked twice, how does it tell whether those callers
have independent interests (or even be the same client invoking the
server twice)?  In an object capability language, the object being
invoked is not passed any information about the identity or interests
of the caller.

Perhaps the answer is that the programmer of the server object needs
to decide and document what promises the server will make, regarding
when it will treat two method calls as potentially made by clients with
independent interests vs which pairs of methods it will presume are made
by a single client (or by a pair of clients with the same interest).
That then shifts the burden onto the client to follow the documented
protocol.

In the case of a single object that is intended to be defensively
consistent, I can think of three kinds of defensive consistency:

a) Every method call stands on its own.  The server will always presume
that any pair of method calls might have been made by two clients with
independent interests.  Consequently, if one caller fails to establish
documented preconditions in one method call, the server can provide
incorrect service during that method call, but the server is not released
from its obligations regarding other method calls.

b) All method calls to a single instance of the server are assumed to
come from clients with a common interest.  Thus, if the server is ever
invoked by a caller that fails to establish the documented preconditions,
then that server instance is released from all obligations from there on.
(Of course, other instances of the same class are not released from
their obligations.)

c) The server object might build some special method of authenticating its
clients.  For instance, clients might pass a Token to prove who they are.
Then the server might assume that all method calls that refer to the same
token have come from a single client (or a set of clients with a common
interest).  Consequently the failure of any such caller to establish
the documented preconditions releases the server from all obligations
regarding all subsequent method calls mentioning the same Token.

And of course the server would need to document which of these three
types of defensive consistency it provides, so that clients can know
what they can rely upon and so they can know how to use the server safely.

Those three cases seems like just about it, if we're talking about a
single object.  Is that all there is to it?

I wonder if perhaps my intuition has been poorly served by focusing on
the case of building a defensively consistent object.  Perhaps I should
be thinking about a defensively consistent subsystem, which might be
composed of multiple objects and which might expose multiple facets
to the outside world.  Then perhaps we can distinguish method calls
according to which facet they are invoked upon, enabling a richer set of
options for what type of defensive consistency the subsystem provides.
Does that sound right?  Is that a more typical case?


Thanks again for your comments, Dean.  They are very helpful.