At Sun, 30 Apr 2006 20:29:28 +0200, Pierre THIERRY <[EMAIL PROTECTED]> wrote: > > [1 <multipart/signed (7bit)>] > [1.1 <text/plain; us-ascii (quoted-printable)>] > We have so far two different confinement types discussed, that I will > continue to call trivial and non-trivial confinements. To some of us, at > least to Marcus (who shall expose us at long the arguments in the > future), there is an ethical issue in implementing non-trivial > confinement.
I can even tell you why there is an ethical issue. The reason is that non-trivial confinement separates ownership of digital content into a party that has access and modification right and a party which has the right to decide durability. If these two parties are different, ownership is diversed, and immediately raises matters of political nature (when applied to any real-world scenario). > So my questions are: > > 1) Do anyone knows, even remotely, what would be needed to implement > this confinement in the Hurd? Particularily, what would be needed for > the implementer to do, and what could prevent him to do it in the Hurd > design? The underlying mechanism is, at the hardware level, a "trusted computer" chip, which is a chip that contains a cryptographic key which _nobody_ can read out and which is certified by the manufacturer of the hardware. At the operating system level, the mechanism is the kernel-supported confinement check and a bunch of supporting user space servers (at least the space bank and the meta-constructor, plus the actual constructors used for program instantiation). You can read all about it in the mailing list archive from last october and november, plus in the EROS papers. > 2) If someone implements this, will it be integrated in the Hurd, even > if disabled by default? This doesn't even make sense if the issue were not contentious. > 3) What will I eat now? Pizza :) Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
