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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
