Re: Restricted storage

[Jonathan S. Shapiro]

On Thu, 2006-06-01 at 18:11 +0200, Bas Wijnen wrote:
> On Thu, Jun 01, 2006 at 12:02:28PM -0400, Jonathan S. Shapiro wrote:
> > > It is not much different from how you plan to do it though.  Suppose I do
> > > this without system support.  I join a group and donate some storage to
> > > it.  A part of a private key gets stored on that storage.  I decide to
> > > leave the group and revoke my storage.  Then the private key that was
> > > (partly) stored on it is lost, giving the whole group problems.  If you
> > > want to make this system usable, the storage must be durable.  There may
> > > be approaches which work without the system administrator, but they need
> > > support from the system, that is the machine owner.
> > 
> > 1. This is a different failure mode.
> > 2. When I said "donate", I did not mean "revocably".
> 
> Ah, so you want to change your system in order to allow irrevocable donations?
> (Or were you planning to allow that already?  I thought you didn't.)  Well,
> when allowing irrevocable donation, that is obviously opaque.

Bas:

Since the design that you imagine is not concretely described anywhere,
it is very difficult for me to keep track of what it does from one
minute to the next. I recognize that the design is still evolving, but
this effect makes discussion *extremely* frustrating. Good or bad, there
*is* a specification for the EROS space bank. While there is a list of
contemplated extensions that are not currently document, this list is
short enough to describe concisely in email (and will be documented when
the corresponding Coyotos doc page is written). Donation is an example
of this.

In the design extension that I am contemplating, the user's "donation"
is exactly as revocable as the user's own storage. It can be revoked,
but only by revoking the entire user. There are serious problems with
this, as you have recognized. This is why we haven't done it and prefer
to rely on opaque, non-commingled storage at the moment.

> > > They will have to do it socially anyway.  The trust this is about is trust
> > > in the machine owner.  With TC, it is trust in the OS builder (and the TC
> > > component manufacturer).
> > 
> > In most circumstances, the decision to trust the OS owner involves a
> > much smaller degree of exposure than the decision to trust the machine
> > owner.
> 
> However, since the machine owner is likely someone you know, quite possibly
> yourself, it may be preferrable to depend on them anyway.

In the world of applications for Coyotos, the assumption that I know the
machine owner is mostly untrue. [Caveat: merely knowing the *name* and
contact information of the machine owner is not "know" in the sense that
you mean the term. There is no connotation of confidence in this very
limited kind of knowledge.]

> > > > But the factor that you seem to be ignoring is the importance of
> > > > *confidence*.
> > > 
> > > Why would people have more confidence in us and the TC component builders
> > > than in the person who installed the OS on the machine (which in many
> > > cases they may be themselves)?
> > 
> > Easy: In one case, they *only* need to rely on the OS+TC builders. In
> > the other case, they need to rely on OS+TC+Installer.
> 
> No, in the other case they don't need trust in TC.

Agreed. The dependency tradeoff would be more accurately be captured as:

  TC+OS vs.
  Owner+OS+Installer 

Further: in a system supporting TC these are not mutually exclusive.

In most of the Coyotos applications that I envision, the Owner and the
Installer are not dependable (note: dependable, as opposed to
trustworthy). There definitely *are* scenarios where owner or installer
are hostile, but I'm not focused on those at the moment. For the general
case, the problem is that neither the Owner nor the Installer of a
typical machine are *competent*. They are not actively hostile, but they
cannot be relied on to take sensible precautions or competently
administer anything. For many purposes, it doesn't matter if the source
of failure was hostility or lack of competence/knowledge. Failure is
still failure.

For individual interactions, where there is personal knowledge about
owners and installers, the Owner+OS+Installer dependency set may be
perfectly fine. For larger scale interactions the ability to know these
parties decays *very* quickly, and the necessary confidence decays with
it.

The group consisting of {TC + OS-architects} is a small enough group to
"qualify" (in the sense of establishing human confidence about them)
even for these larger scale interactions. The general pool of owners and
installers is not.

> > I would add: of these, the Installer is the weakest link; there is a
> > qualitative reduction in confidence here.
> 
> Not true again, in many cases the installer is the user himself, or a
> trustworthy person (who is trustworthy especially because they can punch him
> in the face if something goes wrong).

I'm probably about to get embarrassed, because it is going to turn out
that you have a great deal of experience that I do not know about, but
hopefully you will see the point that I am trying to make anyway. This
is going to sound arrogant, but I truly do not mean it to be. I am
simply trying to test your hypothesis. 

Suppose you (personally) install an OS that I (personally) wrote. For
purposes of determining the level of confidence you should have in this
system, which one of us is more important to deciding issues of trust?

In practice, since we have different objectives, the answer *might*
legitimately be "Bas should rely on Bas first". I suspect that even this
would be debatable, and might depend on the context.

But for purely technical considerations of reliance, the answer is
probably:

  Bas should rely on Bas primarily as a potential source of errors
    of installation and configuration.
  Bas must rely on Shap as a source of baseline technical soundness
    (to the extent that any exists).

In practice, of course, the situation is not so black and white, but if
this is even *sometimes* true for Bas v. Shap, then it is fair to assume
that it is universally true for less well informed installers and
owners.


Note also: Marcus's statement about trust requiring a subject is
incomplete. A better formulation is:

  X relies on Y about/concerning {Property}


shap