Re: What is defensive consistency?

BTW Welcome!

On 11/1/07, Raoul Duke <[email protected]> wrote:
> > No, because if you already rely on the correctness of the other component,
> > and its contract includes some bound on operations, then you can just as
> > well rely on it for that too.
>
> I guess I'm paranoid and don't trust that kind of thing. Sorta musing
> as to how far you can go with keeping distance from Other People's
> Code ;-)

Reliance analysis helps reasoning about system partly because it is so
boolean and (fairly) objective. In the simple analysis, "trust" is
irrelevant: component A's correctness relies on component B's
correctness, so if B is out to screw A, then A is screwed.  I suspect
your intuition speaks to partial correctness; for example, A may rely
on B for printing, but not saving.  Thus, if B is incorrect, it could
steal the document, print something different, etc., but it couldn't
delete eh original or mutate its contents. That's a useful additional
wrinkle, but note that the simpler model allows (we hope) for much
simpler analysis of much larger systems.

> ... unless the system includes some DBC or formal methods and static
> checking re: all those contract issues, which I guess E might do?

Mostly, E (and other capability systems) provide strong encapsulation.
The simple analysis above allows some analysis based simply on graph
reachability.  If both A and C point at B, do we need to include C in
the set of things we worry about for A's consistency.  If B is
defensively consistent, then we don't.  If B is not defensively
consistent, then we do.  There's nothing wrong with A relying on C in
the abstract, but I think that would mean that there cannot be a
security boundary between A and C, for example.