Re: Part 2: System Structure

[Jonathan S. Shapiro]

On Tue, 2006-05-23 at 20:53 +0200, Bas Wijnen wrote:
> > > 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.
> 
> The system can provide a means to allow the user to give out banks that she is
> unable to change and/or inspect herself.  This doesn't need to be enforced by
> making the spacebank opaque, it can be done by not giving the user the
> capability to perform those actions.

This is insufficient. The space bank is not opaque unless it is opaque
to the user **and everyone above the user in the bank hierarchy**. The
common parent is not always the TCB.

> > 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).
> 
> This is about the total system.  If the machine owner doesn't get a capability
> to the primary space bank (and by default it shouldn't IMO, so she would in
> fact need to hack the code for it), then everything you want works.  You may
> have a bit harder time proving that it does, though. ;-)

For some of my applications, this level of protection is either
technically unacceptable (few cases, but a few) or is not different
enough to be framed effectively in the marketplace for purposes of
expressing the advantage of the platform for some application.

> > 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 do not know enough about HIPAA (or similar laws) to say much about this, but
> you seem to be changing positions all the time.  First it needs DRM, then it
> doesn't, and now it does again.

Actually, I have been consistent all along that it requires
encapsulating constructors, and Marcus has been consistent in declaring
that encapsulating constructors are DRM.

> > I am simply trying to be clear about where our objectives seem to differ.
> 
> I am not sure that our objectives differ.  I want a system which offers
> privacy as well.  I am simply saying that you cannot protect against the
> machine owner anyway (in the absence of TC hardware).

Then we differ. TC hardware will be UNIVERSAL on all new machines
shipping after July or August of **this year**.

shap