At Thu, 01 Jun 2006 10:37:24 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > Many of the arguments and policies that are emerging for Hurd in this > list are about "Freedom to". Freedom to debug. Freedom to inspect. > Freedom to reverse engineer. These are all good things, and in a system > that is presumptively single user (or multiuser, but all collaborating > without deceit) these are probably the only things that you need to > consider. > > My question is: what rights should the user have concerning "Freedom > *from*"? Freedom from interference by other users. Freedom from spying > by other users. And so forth.
The two examples you explicitely mentioned are fine, and in fact necessary to exercise the "freedom to"'s as you call them. The "And so forth" may be fine or not, depending what it contains. > My question is: what rights should the user have concerning "Freedom > *from*"? Freedom from interference by other users. Freedom from spying > by other users. And so forth. My design contains complete isolation between child processes, if the parent so desires. > Real systems today are *always* multiuser and *never* collaborative. > When you point a web browser at my web page and run my javascript code, > your machine instantly becomes multiuser, and if you don't assume (at > least in the general case) that I'm out to get you then you're a moron. > Like it or not, a successful Hurd needs to ensure "freedoms from" in > order to be effective in a connected environment. I definitely support this requirement. You are "misunderestimating" me if you think that this is not something I have carefully considered before making my proposal :) The java script code is downloaded, and turned into an isolated child process by the browser. The browser itself is (with respect to other user applications) an isolated process, started by the user's shell, and wrapped in a powerbox. This is one possible way to run potentially malicious code while containing the damage. Not at all different from how to do it on EROS/Coyotos, really. > The interesting thing here is that "freedom to" and "freedom from" > invariably involve conflicting choices that must be balanced and > architectural compromises that must be made. I don't see any conflicts in the examples you gave. The only conflicts I see involve the "multi-party computing pattern", aka DRM. > If the real purpose of the "Flexibility" goal is "Freedom", then it > seems like a good idea to enumerate *both* types of freedom so that we > can remember all of them at the same time. As I don't see any conflict, I don't think there are two types of freedoms here. There is only one freedom, the freedom of the user to use, inspect, modify and distribute the bits running through their resources. This includes patterns of isolation between parts of these resources (but not isolation of the resources from the user). I have described before how I think this "freedom" is actually nothing but the definition of ownership, so it is a conservative call. There is a case where I recognize two types of freedoms: If you have two participating agents, namely the freedom of the one agent and the freedom of the other agent. As usual, the freedom of the one agent ends (latest) where the right of the other agent starts. These rights however are of social nature, and can in principle not be enforced or even expressed technically, because they involve judgement decisions which may in disputed cases only be justified by a later process, for example in court. A somewhat meta-physical point: To some extend, this caveat also applies to "user freedom", because neither ownership nor privacy is a completely absolute right[1]. However, they are strong and well-established concepts nevertheless, and I have no problems with assuming them, at least for all practical purposes. Thanks, Marcus [1] In Germany, the court can request that certain information is produced. If one refuses, one can face a series of penalties including jail time until compliance. I believe other countries have similar laws. In the US, Judith Miller from the New York Times was held in jail for refusing to name the source of the Valerie Plame leak, and was only released when she cooperated (under unknown conditions) with the Special Counsel Investigation into the Valerie Plame exposure. _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
