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