[e-lang] What is defensive consistency?

[Dean Tribble]

On 11/2/07, zooko <zooko at zooko.com> wrote:
> > b) All method calls to a single instance of the server are assumed to
> > come from clients with a common interest....
>
> This is the pattern that we are using in the tahoe project [1].
>
> The contract that a server has with a particular agent is
> encapsulated into an object (hosted on the server), and the server
> gives that agent a reference to the object.  Then the natural scope
> of defensive consistency is that object.
>
> Make sense?  It feels right to me.

It's definitely a good and common pattern. It doesn't completely
address defensive consistency, however, because there is typically
some underlying object that the per-client objects share. If a client
can induce it's server object to do something to the underlying object
that compromises other clients, then defensive consistency is
compromised. Having a per-client object does often simplify providing
defensive consistency, though, just because it's easier to encapsulate
the parts that must be protected for each client.

> > c) The server object might build some special method of
> > authenticating its clients.
>
> This gets into the question of "tracking the bases of the reference
> arrows" (i.e., who is the caller), vs. "tracking the pointy ends of
> the reference arrows" (i.e., which object).  I think there are some
> unsolved puzzles in there, but in the main, object-capabilities tend
> toward the extreme of  "all tracking is tracking of pointy ends and
> not bases".  See Horton [2] for an example of how that extreme stance
> approaches the problems fo which other people use the bases of arrows.

Just to be clear, the primary insight about defensive consistency is
that it allows one to continue to only track the pointy ends when
considering vulnerability and consistency, even in capability systems.
 Without defensive consistency, you must also track the bases!