At Mon, 01 May 2006 00:33:33 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > On Mon, 2006-05-01 at 05:43 +0200, Marcus Brinkmann wrote: > So we must now examine Marcus's *real* proposal, which is extremely > radical: Marcus proposes that ownership of storage should imply the > ability to read that storage.
I'm surprised that this was not clear. I said it in no uncertain terms at the very beginning, when I explained what I understand by "user autonomy" and "user freedom" (ie, the right to use, inspect, alter and copy all resources attribute to/owned by the user). > But the really silly part is that this compromises the entire system > architecture to no purpose, because it fundamentally does not solve the > "no hidden bits" problem. I can still fabricate a process that runs > completely out of *my* storage and hand it to you. You can run it or > not, but you *still* can't know what it does. All that has actually been > accomplished here is to guarantee that if you *do* talk to this process, > you necessarily disclose information **to the creator of the process**. The system will not, by default, run programs from foreign storage. Yes, if you want to do that, you can do it. If you want to be really stupid, you can send nude pics of yourself over the web. You can run unconfined programs in EROS, too. The point is that this is never done by default, so you have to hit yourself over the head several times to get there. It will be harder to run such programs in my system than it is to run unconfined constructors in EROS. The default operation will be safe, in that it preserves confinement as well as the user's freedom to use, inspect, copy and alter their storage. I have already explained why I think that this is important to the free software movement and development. > Remember those dialog boxes that let you say "I never want to send > software registration information back to the vendor?" A naked storage > allocator is a lot like removing that choice for the user. FUD. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
