|
From: | Michal Suchanek |
Subject: | Re: Part 2: System Structure |
Date: | Wed, 24 May 2006 12:53:27 +0200 |
On 5/23/06, Marcus Brinkmann <address@hidden> wrote:
At Tue, 23 May 2006 10:46:34 +0200, Tom Bachmann <address@hidden> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Bas Wijnen wrote: > >> I'd like to encourage everyone to consider this. It sounds like a viable > >> compromise > > > > What exactly is "this"? > > > > The proposal by jonathan: > > > There are opaque and translucent banks. The difference is that > > the opaque bank will not issue a given page more than once. A > > translucent bank will, which is how the user gains access to > > the content. Jonathan's proposal achieves technically what he wants to achieve by it. However, to me, it's a compromise in the same way that the feature to run an executable in an e-mail attachment by clicking on the attachment is a compromise between the interests of virus developers and the users. Putting "dangerous" code at the bottom of the system, and then trying to recover safety by extensions, is not good system design. I think everybody agrees with that. We do not agree on an estimation what constitutes "danger", but if you read what I wrote in Part 1, you will understand why the above does not constitute a compromise for me. Also, please pay attention to what I wrote about the GNU project in part 1. Supporting DRM is in direct conflict with the interests of the GNU project. Thus, for a GNU project, there can only be compromises with legitimate (in the context of the GNU project) interests whose benefit compensates the involved risks (again, for the GNU project).
The constructor in Jonathan's systems is a powerful tool. It allows running programs on user resources and trust that they perform in certain way (cannot be tampered with). This allows 'outsourcing' system (and other) services so that most of them runs on user resources and only small and simple part resides in the system. This is central to most of the examples already mentioned, at least those that can be specified enough to be considered valid. It makes it possible to build very secure services much more easily than any other system I can think of. I just want to ask how this design pattern is replaced in your (recursive) system. It seems that just leaving it out will make the system much less secure because building secure services will become much harder. Note: there is a separate problem of the machine owner. Jonathan wants protection from the machine owner but it looks like it is inappropriate for the Hurd. We do not want TPM, and that is the only way of protection from the machine owner. On the other hand, good protection from unauthorized access (network or terminal) is still an improvement over current systems. And one has to trust the machine owner in many other ways. For one, if you store valuable data on the system you want a backup that can be read on another system as well. If the data was protected by TPM it would not be possible. Thanks Michal
[Prev in Thread] | Current Thread | [Next in Thread] |