l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Confinement (even with TPMs) and DRM are not mutually exclusive


From: Jonathan S. Shapiro
Subject: Re: Confinement (even with TPMs) and DRM are not mutually exclusive
Date: Wed, 07 Jun 2006 01:43:03 -0400

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]