Re: DRM vs. Privacy

[Jonathan S. Shapiro]

[Bas: When I got to the bottom of your note, I realized that I should
have started this from another direction entirely. I want to send out
these comments anyway, but I suggest that we need to proceed through the
design from the bottom and work up in order to have a clearer
discussion.]

On Tue, 2005-11-08 at 20:57 +0100, Bas Wijnen wrote:

> You're saying that as if we aren't this distributor. ;-)  Of course we shall
> not be the only distributor, but I think we don't want others to accept this
> burden either.

That is not your decision to make. It is the distributor's.

> The GNU project is meant to allow people the freedom to change software.  If a
> distributor will only support unchanged versions of the system, he is really
> setting up a barrier against changing it.  We don't want to stimulate that
> kind of thing.  So as supporting it has this as a potential side effect, a
> cost would be that we are losing our principles.

It is true that the GNU project allows people to change their software,
and protects their right to do so. But it is also true that a
distributor can offer things **in addition to** software, and these
offers may be conditioned on *not* changing the software.

For example, I can ship you a completely GPL system, and I can offer you
a warranty and/or support contract on that system. You are free to
change the system, but I am free to say "the warranty and/or support
contract applies only to the configuration that I sent you."

GPL has *never* required that support providers be willing to support
arbitrary code changes by the customer. The philosophy encourages that
the support provider should be reasonable and flexible, but it doesn't
require it.

GPL also does not say "you, as the user, must be changing your system
all the time". It says that you *can*, not that you *must*. From the
user perspective, it is very likely that I would prefer to pay for
support, and that as part of this deal I understand that there are
freedoms that I will refrain from exercising in order for meaningful
support to be possible.

> > > 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.
> 
> Compared to a system where the user can debug any program that he starts (this
> does not include programs which take external capabilities such as su),
> assuming that there is a way to make debugging impossible does cost the user
> control.  Not over the content, but over the executable which cannot be
> debugged.

Nobody has required the user to execute the program that declines to be
debugged, in the same way that nobody requires the user to execute
Windows after buying a laptop. Please explain the distinction between
these two examples.

> Anyway, I don't think this is a big thing, as this loss of control only
> happens with the explicit consent of the user.

We agree that consent is hugely important. If we were talking about
something where the user was deprived of the ability to exercise choice,
I would be arguing strongly against doing any of this. If it is done at
all, it should not be done behind the user's back.

> > 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.
> 
> I'm not arguing for that, I'm just claiming that it follows from not
> supporting those chips.

Yes. If we do not support these chips, then we reduce all control
negotiations to the choices "all" or "nothing". If we *do* support these
chips, then a much wider range of possibilities is opened.

But what you *appear* to be arguing is that two competent parties should
be *prevented* from forming these relationships, and to ensure that they
cannot do so we should not support the chips.

> > This sounds like exactly the sort of restrictive policy that we should be
> > trying to avoid.
> 
> You say that like it follows from a design principle.  Which one is that?  I'm
> interested because I want to know if I agree that we want it.

The principle is a social principle, not a technical principle: if two
competent parties wish to engage in a feasible relationship that does
not harm third parties, it is not appropriate for me to decide by fiat
that they should not, nor is it appropriate for me to engineer into my
designs a decision that would have the effect of preempting their
freedom.

> > The metaconstructor (and, for that matter, the constructor) is part of
> > the TCB.
> 
> I know that the meta-constructor is.  But I'm creating an object, pretty much
> like any other process, which happens to work like the meta-constructor.  But
> when someone asks the meta-constructor if it created one of its
> "constructors", it will say "no".  But they aren't going to ask the
> meta-constructor, because I'll give them a pointer to my object and claim that
> it is the meta-constructor.

Sure, but the only way you could do that is by modifying the account
setup software. Ultimately, this will work its way back in the chain of
trust to something that can be detected.

You can definitely make the changes you describe, but you cannot make
them in a way that is undetectable of a TPM/TCPA chip is present and in
use and the underlying system is structured to support detection. The
question at hand is: do we *want* to support detection.

> > 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?
> 
> Because I think all control should be with the user.  It may be possible to
> give all or part of it away, but that shouldn't be done, and therefore I think
> it may not need to be supported.

Yes. This is what I thought. You wish to make an a priori design policy
that I, as a competent user, should not be permitted to engage in
certain relationships that harm no third party. I understand that you do
not mean to do so, but you are firmly advocating an architecture that
profoundly constrains my freedom.

>   This is the same reason for which you don't
> want to support grabbing the display, I think. :-)  Only there I think it is
> useful, and so it should be possible (although it shouldn't happen
> accidentily)

In my mind, the two cases are very different. I want to prevent display
grab because if this is done the user has totally lost control
altogether. In the previous discussion, the user has given up *partial*
control, but they are able at any time to stop the activity and regain
control (e.g. by killing the programs involved). Once the mouse has been
stolen, they cannot stop any activity of any sort.

Try it this way: The user should always be able to pull the plug on an
interaction.

> > > 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.
> 
> Sure.  But that will include installing new code.  And so he can install any
> code he likes (he may have prepared it before using the installation
> software).

Perhaps, but the installer does not need to agree to replace parts of
the system TCB.

> > > > 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.
> 
> If he updates the compiler, he can choose to put in a new one which does what
> he wants.

Only if the installer permits this.

> > > 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'm happy to explain (or change my mind ;-) ).  Can you tell me what
> assumptions I am making that may not be valid?  I think I'm only making
> assumptions which directly follow from design choices.  However, I didn't make
> those choices explicitly, and I guess I should.  I don't really know what they
> are though, and knowing what strange things I'm assuming may help with that.
> :-)

That will be good for both of us. I could be missing things as well. I
need to go do something else at the moment, so let me come back to this.


shap