Re: DRM vs. Privacy

[Jonathan S. Shapiro]

On Tue, 2005-11-08 at 17:58 +0100, Bas Wijnen wrote:
> > To be honest, I don't see Hurd running on ATM machines any time soon,
> > but I *can* imagine Hurd being used in distributed gaming scenarios. One
> > of the endemic problems in distributed gaming is that the players cheat.
> > I don't care if the player hacks the game -- that is not what I mean by
> > cheating. But in my view, when a player signs on to a collaborative
> > gaming system, part of what they are saying is "I promise to play by the
> > rules of the game." Given the actually observed player behavior, it is
> > not unreasonable to check that this promise is being upheld.
> 
> True.  But does such a chip solve this problem?  If we know we're running on a
> true Hurd system, we're not anywhere near authenticating that it's a real
> version of the game.

True, but if we know that we are *not* running an authenticating, secure
OS, then we are already done, because we cannot *determine* whether we
are running an authentic game.


> 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. The burden on the
OS distributor isn't trivial, however. I'm not really advocating
TPM/TCPA here. We're going to support it at the Coyotos layer, mainly
for experimental purposes. There is no requirement for Hurd to expose
that functionality.

> > > 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. I can't stop you from doing this (and I don't
want to), but I can observe that it has been done if you answer the
authentication query at all.

And of course, if you decline to answer, I know that if I really care
what you are running for some reason then I probably shouldn't
collaborate further with you.

> > 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.

But you are not the user who created the constructor.

Let's take GCC. The user who creates the GCC constructor is the author
of GCC. Are you really saying that this person should be in control?
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, there are some administrators who might be both trustworthy and
competent to do that. After all five of those have installed Hurd, then
what?

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.

> > Remember that there is no notion of UID, and the program has no way to know
> > who is debugging it.
> 
> It can create a capability at constructor creation time.  Whoever holds it is
> allowed to debug it.  Obviously this will break the confinement unless the
> process calling the constructor authorizes the capability.  But if I create
> the constructor this way, then I know that noone else has the capability, so I
> do authorize it.

But you are not the party who needs to authorize it. The party who needs
to authorize it is the party *calling* the constructor (i.e. requesting
the process instantiation).

A consequence of your proposed design is that an administrator can snoop
every password change on the system. Why should the administrator be
able to do that? What actual, justified need is there for allowing this?

If a process refuses to let me debug it on request, and I care, I can
always kill the process before I do anything else with it. The
administrator doesn't need to have anything to do with this.

shap