On Tue, 2006-06-06 at 23:13 +0200, Bas Wijnen wrote: > On Tue, Jun 06, 2006 at 11:13:55AM -0400, Eric Northup wrote: > > I have been very concerned to see the discussions leaning towards > > abandoning the security benefits associated with the design patterns > > from KeyKOS and its descendants. > > The security you speak of, as far as I understand (but I agree with Marcus > it's better to be specific, so I will be) is the security of programs against > users owning them (where owning means the program received all its > capabilities and the initial code image from that user). This will never > work.
Bas: >From a purely technical perspective, this statement appears (to me) to be wrong. It is very clearly possible to technically achieve DRM. Not in an absolute sense, but in the sense that the cost to break it is too high to be practical. This is the only sense in which *anything* is *ever* secure, and it is a sufficient basis for commerce. If you perceive a technical reason why what you say is true, I would be interested to know it. > The sole reason this program exists is the user. It shouldn't have > protection against her. This is an example of "post hoc, propter hoc" reasoning. You are reasoning backwards from conclusions. The conclusion (a value judgment) is that "the sole reason the program exists is the user". This conclusion is highly questionable. If you would qualify this by saying "In the architectural/design philosophy of the Hurd, the sole reason that a program exists is to server its user" then I have no objection to the statement. I simply want it to be clear that this is a declaration of philosophy with technical implications, and should not be confused with a statement of technical fact or feasibility. > So the user knows if the device is "direct". The program doesn't need to > know. Um. No. Anybody who has looked at the trusted path issues in electronic voting can explain at great length that it is *extremely* difficult for either the user or the computer to know this, and that all currently feasible mechanisms for this rely on some form of very carefully implemented DRM that permits end-to-end authentication of a closed device at the user end. What you assume here certainly isn't as simple as you make it, and is actually false in the absence of extremely careful design (that does not exist in *any* current commodity product). > > -Some devices may offer limited guarantees of exclusivity. For > > example, that while printing a contract, no other program can > > insert the word "not". > > I'd say that invoking a capability to a printer should send a whole document, > not only a part. No need for exclusivity in that case. What you describe is technically referred to as "exclusivity". shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
