Re: DRM vs. Privacy

[Bas Wijnen]

On Tue, Nov 08, 2005 at 02:07:51PM -0500, Jonathan S. Shapiro wrote:
> 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.

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:

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.  There must be a huge benefit
to compensate that.  I don't think there is, therefore I am not just not in
favor of supporting it, but even against it.

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

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

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

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

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

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.  So they'll ask my object if it created those
constructors, and it'll say "yes" (and it's even true).  Then they'll ask my
"constructors" if they're confined, and they'll say yes (and that's not true).
Then they'll execute, and I'll debug.

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

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

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

> > > 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.  That may include spying.  However, if he wants it to be useful, it
must violate the confinement check, and that will be detected by the user (and
so it will not be used).

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

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

I'm assuming that all control comes in the form of capabilities.  When I say
"the administrator", I really mean anyone who holds the relevant capability.
This need not be the same person for all "administrative" operations.  Since
assuming that it is the same person doesn't change any of the arguments,
failing to recognise this does not affect the conclusions.

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