Re: DRM vs. Privacy

[Bas Wijnen]

On Tue, Nov 08, 2005 at 03:50:38PM -0500, Jonathan S. Shapiro wrote:
> [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.]

Sounds good.

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

It's our decision as well.  The GNU project is a political project, not a
technical one.  The implementation is mostly technical, but we should keep the
political goals in mind.  Anything which works against them should be
rejected.

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

They can do that, but it would be against the spirit of the GNU project.
Therefore, the GNU project may (or even should) make it hard for them to do
this IMO.

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

Indeed, there is no legal requirement for any of this.  But when we implement
a GNU kernel, we should not only live by the written rules, but also by the
philosophy.  And that may include limiting technical options which have no
other objections against them.  (I'm not sure if that applies here.)

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

Of course.  A requirement to keep changing would be absurd.

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

Many users also prefer a system that can play the latest games but spies on
them over a secure system that doesn't run those games.  That doesn't mean we
must give up and all use Windows though.

What I'm saying is that what the user wants isn't always holy.  In some cases,
we should try to convince the user that he's wrong and that our approach is
better.  These are always philosophical matters.

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

The difference is our support.  The first is something we can prevent by not
making it possible in the OS.  The second is something we cannot influence at
all.

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

I'm not really sure if I'm in favor of the argument, I'm more writing down
what I'm currently thinking.  I didn't reread what I wrote before, but it can
very well conflict. ;-)

Indeed, I am saying that we want to prevent these relationships, and therefore
we should not support the chips.  This is because of the risk: If checking for
unchanged code would become commonplace, this effectively destroys the user's
freedom to change it.  Because what's the use of changing code if doing that
makes half your system stop working?

It may happen anyway, or it may not happen even if we do support the chips.
But there is a chance that it only happens because we support the chips.  I
don't want to take that risk.

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

I agree with that, but only insofar it doesn't conflict with other principles.
I think in this case it does.  This is exactly the difference between open
source and free software people I think.  Open source advocates would probably
say "who cares about politics, let's make everything possible".  I think we
should care about politics, and that making this possible may have the effect
of restricting end-user's freedoms in the long run.

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

Why?  I'm not expecting anyone else to use a constructor.  Only programs which
I run in this "sub-Hurd" like environment see my "meta-constructor".  What
special rights does which process need that I cannot do it without changing
the TCB?  Is creating processes an operation which is reserved for the
meta-constructor?

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

I feared that.  I don't know how exactly those chips work, but they seem to
have much to do with many parts of the machine.  I don't think I like them
very much...

> The question at hand is: do we *want* to support detection.

I would like to allow the user to start a "sub-Hurd" as I described above.
This means I do not want to support detection by the code inside such a
sub-Hurd.  Technically I don't have strong feelings about supporting it when
the user wants it.

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

They do harm a third party, just not in the short term.  If such relationships
are possible, they may become commonplace.  And if they are, then it will be
impractical to adapt the system to your needs, because then you cannot use all
kinds of services anymore.  Thus allowing those relationships may lead to a
restriction of *practical* freedom of others.

> I understand that you do not mean to do so, but you are firmly advocating an
> architecture that profoundly constrains my freedom.

I do mean to do so.  Just like I think it is a good idea that the GPL limits
the freedom of users in a way that guarantees the freedom of users further
down the chain.  There too, releasing under the BSD license would give the
next user more rights, and it doesn't directly have any influence on a third
party.  But later, he may distribute it under some proprietary license.  Then
the freedom of the users after him is severely limited.  This could have been
prevented by using the GPL.

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

I agree that that must not happen.  But I'm now convinced that we need to
support the "system request" anyway, to pop up a trusted window when we don't
know the state of the system.  That can be used to break the grab as well.

And of course, the grabbing application cannot control the pointer, it is only
guaranteed that no other process receives the events.

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

I think when retaining "sytem request" and allowing to "revoke grab capability
from currently grabbing process" or even "kill currently grabbing process and
all its parents, up to but not including the shell" or something, there should
be enough opportunity for the user to "pull the plug".

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

Of course.  But if the administrator is to do his job, then he will be the one
to decide if software is good, not the installer.  It can limit it to confined
software, but I don't see a reason for that, since the shell must check for
confinedness anyway.  And installing unconfined software may occasionally be
useful.

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

Ok.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature