Re: DRM vs. Privacy

[Jonathan S. Shapiro]

On Tue, 2005-11-08 at 19:02 +0100, Bas Wijnen wrote:
> > > Sure.  What I was saying is that it's fine with me if the Hurd doesn't
> > > support answering, or more specifically, if it doesn't support any
> > > protocols on top which certify authentic programs.  If it's trivial to do
> > > and doesn't cost anything, I don't have a problem with it.
> > 
> > It's pretty trivial to do from a software perspective.
> 
> But it does cost something.  If it needs to be useful, then for a start it
> costs:
> 
> > The burden on the OS distributor isn't trivial, however.

This is not a technical burden on the implementation. It is a management
burden that is voluntarily accepted (or not) by a particular distributor
of the OS in order to support certain relationships among their user
communities.

> Furthermore, it costs control.  That is, it creates a system where the user
> may loose control to a content provider.  

Nonsense! The user absolutely has not lost any control at all. They can
always remove anything installed by the content provider. If they choose
not to agree, then they never had the content in the first place to
control or fail to control.

What you are really arguing is that the two parties should not be able
to jointly negotiate middle positions on control according to their
needs and requirements. This sounds like exactly the sort of restrictive
policy that we should be trying to avoid.

> The user can refuse to give the
> control away, but he can't get it back once he lost it.

There is exactly one piece of control that the user is giving up. When
the user enables access to the TPM logic, what they are saying is:

  After this point, I am not obligated to answer at all, but there
  are certain falsehoods that I can no longer speak undetectably.

That is all. It is not a choice that is forced on the user.


> 
> > > > > IMO this should only work as far as the user in control wishes it to
> > > > > work.  The user in control is the one who created the constructor.
> > > > 
> > > > Then the user in control is me, personally.
> > > 
> > > Hehe, no you're not the one I meant. :-)  I meant the one who called the
> > > meta-constructor and thereby instantiated the creation of the constructor.
> > 
> > I don't think you understand all of this yet. If I ask your machine "are you
> > running an authentic Coyotos", then I know whether you are running the
> > Coyotos TCB. If you are, then I know that you are running my (i.e.  me
> > personally) implementation of the metaconstructor. If that is true, then I
> > know the properties of the constructors executing on your system.
> > 
> > You can swap the metaconstructor if you like, and the new system may be
> > perfectly good, but it will not be able to certify itself as an unmodified
> > Coyotos system.
> 
> Oh, but it is.  The TCB isn't modified, I just created an object which happens
> to behave like a meta-constructor (but it isn't *the* meta-constructor).

The metaconstructor (and, for that matter, the constructor) is part of
the TCB.

> Perhaps I don't quite understand how TPM/TCPA is supposed to work, but I'd
> assume that the OS gets a question from the network, it forwards that to the
> chip, gets an answer, and forwards that over the network.

That's not how it works, but I just had a student walk in for a meeting,
so I can't answer this immediately.

> > > > This sounds like dogma. *Why* should any program be debuggable?
> > > 
> > > Because the user who creates the constructor for it (which once again
> > > isn't always you ;-) ) _should_ be in control.  If I'm creating a
> > > constructor around some downloaded binary, then I should be the one who
> > > controls what happens with it.  I don't want untrusted code to be in
> > > control.

I don't want untrusted code in control either, but control is not
binary. It is not either/or. It can be factored. Why do you believe that
control should be absolute?

> The
> administrator can do anything he likes at install time, including adding a
> spying wrapper.

The administrator can do what the installation software permits them to
do. Nothing more.

> > Alternatively, are you saying that the administrator should be able to alter
> > the behavior of my compiler simply by virtue of being the administrator?
> 
> Yes.  He needs this control because he is the one who installs updates to the
> compiler.

This is simply not correct. Even if he updates the compiler, the
administrator does not require this control.

> > Yes, you could alter the installer to do what you say. I don't think that
> > you are thinking through the consequences of such a change.
> 
> The consequences aren't as deep as you think, because you seem to
> misunderstand what I'm proposing. :-)

Wouldn't be the first time. Heck, half the time I don't understand what
*I'm* proposing

> The situation is that I get some code which a
> content provider wants me to execute to protect his content.  I'm saying that
> I can spy on that code, because I'm the one who creates the constructor for
> it, *and* I'm the one calling that constructor.

You are making a bunch of assumptions that may be valid in some systems,
but they are not necessarily valid, and in my opinion you have offered
insufficient justification. I think that at the moment you are
advocating a technical decision based on a single point of dogma, and
that we haven't explored the option space completely enough to come to a
final decision. My main concern is that you appear to be proceeding from
mistaken assumptions about what factoring of administrative control is
feasible. If the feasible factorings change, it has significant impact
on the viable design space.

shap