On Tue, 2006-06-06 at 23:13 +0200, Bas Wijnen wrote: > Now when the program is being run as it should be by the user, everything is > fine. But what happens if the user will run it "improperly", for example in a > debugger? Then the guarantee is no longer valid. However, that doesn't mean > that it's a wrong thing to do. In particular, when the user starts a program, > that's the user's business, not the administrator's, and certainly not the > programmer's. If the user wants to run the program in a debugger, then it > mustn't start protesting. It must do what the user wants...
In my view, this is completely wrong. Yes, it is possible to build relationships in the way that you describe, and to permit (even encourage) permissive execution in the way that you describe. There is nothing wrong with this. It probably should be the common case. The problem here is liability and lawsuits: if something goes wrong, there is no evidence to decide later whether the program was executing legitimately or not. Neither the developer nor the user is adequately assured that a robust determination of whether liability might exist under contract is possible. Alternatively, it is possible and legitimate to establish more binding and checkable relationships. For example, a developer may say to a customer "I have tested this program in a certain environment, and I am willing to accept significant liability if it fails while running in that environment. However, *because* I accept liability, I will only permit you to run the program in a way that I can validate. Either I can validate it, or I will not accept liability." [This does not stop us from having an alternative, non-liable version; we are merely establishing and auditing the conditions under which liability applies.] The potential to mechanically audit the conditions of execution in order to allow a simple determination of whether liability exists is critical. Simultaneously, the ability to guarantee that a program is only executed as intended is absolutely necessary in order for a developer to consider accepting liability. In questions of liability, it isn't enough to check the interface. You rely on the implementation as well. >From the standpoint of design philosophy, it is important to me to design a system in which developers and users can be held accountable for their contracts. The problem with DRM isn't the mechanism. The problem is that it is a badly structured, one-sided contract. The reason that ActiveX is such a disaster is that it relies on interfaces. You install an ActiveX control. It uses 15 others. One of these gets upgraded in a way that breaks the interface contract. In consequence, a seemingly unrelated control misbehaves in a way that the user can observe. Good luck figuring out who to call or who to blame. My goal is accountable systems. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
