Re: Part 2: System Structure

[Jonathan S. Shapiro]

On Tue, 2006-05-23 at 18:41 +0200, Bas Wijnen wrote:
> On Tue, May 23, 2006 at 11:43:10AM -0400, Jonathan S. Shapiro wrote:
> > The two possible positions are:
> > 
> >   1. The default should be translucent, but it should be possible for
> >      a user to choose to execute an opaque program.
> > 
> >   2. The designers should not allow the user the freedom of this choice
> >      in the absence of extensive new development effort, and therefore
> >      mandate that all banks be translucent.
> 
> You are (perhaps intenionally) forgetting the option that the default is
> opaque.

I did not forget it. I omitted it because it seemed from previous
discussion that this decision about the default was already made. The
option certainly exists technically.

> > It appears to me that you are choosing position (2).
> 
> No, actually if I have to choose from those two, I think I'm tempted to choose
> 1.  What I said is that I would like to choose 2 if that would not raise any
> problems.  I now think that the ping case may actually show a real problem for
> which users will want to provide read-only memory.

Technically, I do not see how to choose (1) without introducing opaque
banks. An opaque bank must be opaque even to users of its parent banks.
It is possible that there is an alternative implementation that I am not
seeing.

> The point I was trying to make is that the system should not allow programs to
> make things harder that are possible anyway.  That means that the machine
> owner must simply be able to see everything in the system if she desires this,
> and a program must not be able to hamper debugging it if all users which
> provide capabilities to it agree that debugging is a good idea.

I believe that this is technically inconsistent with option (1). In
particular, it makes the user's voluntary decision contingent on the
machine owner. I see many use cases for Coyotos-OS where this is not
okay (in the sense that violation by the machine owner must have
prohibitive cost) for *good* social reasons (such as medical privacy).
Satisfying these cases relies on exploitation of DRM technology. I
understand that the Hurd designers are opposed to DRM, and I have given
up the expectation that Marcus will think with an open mind about the
feasibility and desirability of technical solutions satisfying HIPAA and
similar laws. I am simply trying to be clear about where our objectives
seem to differ.

> Since programs don't have a will...

This seems to be a deep philosophical assumption. I think that it may be
over-simplified. It is certainly true that programs do not have a will
in and of themselves. However, a program *embodies* the will of its
developer in the form of decisions made by the developer about how the
program executes. It therefore may be imagined to have a "will by
proxy". This is widely recognized in the high-security community: the
author of a program must be modeled as a principal, because programs are
executing that obey the author's will.

Ignore programs for a minute, and consider only humans, I believe that
we would agree that if two people A and B wish to engage in some legal
and ethical action, then (1) it is legitimate for them to agree to do
so, (2) it is legitimate for B to say to A "I will take care of some
part of the problem X, but I will do so using undisclosed means", (3) it
is legitimate for A to *choose* to trust B or not, and (4) provided A
decides to trust B, it is permissible for A to lend money to B for the
undisclosed action.

Money is similar to storage in two ways: (1) it does not disclose how it
is used, and (2) it can be paid back. It is an opaque resource. We have
agreed that A may choose to trust B, and we have agreed that in the real
world it is acceptable for A to provide B with opaque resource.

Now let us return to the programmatic scenario: we appear to be saying
that all of the above is *not* acceptable if the form of B's behavior is
to embody that behavior in a program that is executed by A.

I understand (I think) how we arrived at this qualifier, but it still
seems very strange to me.

> > Speaking on a purely subjective basis, I find this incredibly arrogant,
> > and I think that the users will too.
> 
> I will not deny that I am indeed incredibly arrogant, at least in some cases.
> This is one of them.

Arrogance is not always a bad thing, but I have found that it is
important as a designer to recognize when I am indulging it.

shap