Re: Restricted storage

[Bas Wijnen]

On Thu, Jun 01, 2006 at 12:44:47PM -0400, Jonathan S. Shapiro wrote:
> > 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.
> 
> 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.

Well, the general idea stays the same.  If you bring up problems, I see if
there's a way to solve them (or if perhaps they shouldn't be solved at all).
I think you don't really know what the general idea is, though, so that may
make all this a bit hard.  I was hoping that you'd get a feeling for it at
some point.  I have described it several times, so I'll not do that again at
this point.

> I recognize that the design is still evolving, but this effect makes
> discussion *extremely* frustrating.

I'm sorry to hear that.  If there's anything I can do to avoid this, please
let me know.

> 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.

Good point, that should of course revoke the donation.  And it brings in the
same problems as when the user could do it without being revoked.

I think this is actually a good reason to make this functionality a system
service.  The revocation could then be delayed, because the service is trusted
to voluntarily let go of the storage when it is asked to do so.

> > > > 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.

Sorry, you misunderstood me.  "You" was meant as the user, not as the OS
designer.

> > 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.

You mean for some parts you can have one, and for other parts the other?  I
agree.  However, for each part, you must trust TC or the owner+installer, not
both.  The whole idea of TC is that you don't need to trust the owner (and
installer).

> 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.

There is a very limited case where owner and/or administrator may be hostile.
These all fall in the "are not of interest to the Hurd" category, I think.
Unless there is reason to assume this is a very large group, I agree we should
not focus on it.

> 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.

Of course, our "requirements for the user" are also valid for the
administrator.  In particular "awareness" (he knows what happens) and
"security" (he is in control) should handle this.

Yes, I know this means we need a good user interface.

> 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.

Large scale installations typically happen within some organisation.  It's the
organisation's (potentially sensitive) data that's being handled.  In that
case, the user's aren't the ones who need protection, but the organisation.
They should have a good way of choosing who is to administer their machines.

I think society has enough safeguards to prevent (most) problems, or at least
solve them.

So I think organisations can trust their administrators as well.

> 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.

My organisation doesn't need to trust your organisation's installer.  This
isn't about a "general pool", this is about specific individual people.

> > > 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).

While I would probably read parts of the code and likely compile the thing
before installing that compiled version, I agree that even in that case I
would need to rely on you for some part.  However, I would rely much more on
the "free software idea".  If someone finds a bug (accidental or not), it gets
fixed.  I see this happen for example in Debian all the time.  With TC, that
doesn't work.  Someone finds a bug, fixes it, sends it back to you, you go to
the RIAA and tell them there's a new version, they don't respond very fast, a
long time later perhaps the machine will be able to actually run the fixed
version and still use TC, and the bug fixer will probably have given up.

So because the mechanism I trust is likely not to work very well in the
presence of TC, I have in fact less trust in a system with TC than one without
it.  This mistrust in increased by the fact that TC is created by big
corporations, who want to "own my computer".  I don't trust these
corporations, and I don't trust their motives.

> 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.

For the lack of informedness, we need "awareness" and "security".  I don't
think removing the tools from the owner/installer/administrator is a good way
to solve the problem in most cases.  While they may not be so well informed,
they usually _are_ the people who it's all about.  The whole idea of the Hurd
is to allow users to do things.  "They don't know how it works, so don't allow
them to use it" is exactly what we're fighting.

> Note also: Marcus's statement about trust requiring a subject is
> incomplete. A better formulation is:
> 
>   X relies on Y about/concerning {Property}

Yes, this is why I said that your comment about one set of trusted groups
being strictly larger than on other set of trusted groups did not mean
anything.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature