Re: Part 2: System Structure

[Bas Wijnen]

On Tue, May 23, 2006 at 04:02:37PM -0400, Jonathan S. Shapiro wrote:
> > > The argument that you are actually making is much more subtle (and, I
> > > think, more powerful):
> > > 
> > > If we can build a sufficiently large *collective* block of users who
> > > refuse DRM -- big enough that these users represent a noticeable
> > > proportion of market share or a publicly visible group whose visibility
> > > imposes noticeable embarrassment or noticeable marketing and PR costs to
> > > the content providers, we *may* be able to restore more balance of power
> > > to the viewers (either through the market or through legislation), and
> > > by doing this we may be able to force DRM use to a more acceptable
> > > middle position or even eliminate it entirely.
> > 
> > This is almost the argument, indeed.  Except that I'm assuming that real
> > DRM (with protection against the machine owner) doesn't exist yet, and we
> > can make it possible.  So I'm not building a group of people who refuse
> > it, I'm trying to avoid building a group of people who accept it.
> 
> Good. This is a very important clarification. The problem (in practice)
> with this is that there are other active (non-Hurd) efforts that will be
> in the field either at the same time or before the Hurd that will
> succeed at enforcing DRM for practical purposes.

I'm not so sure about that.  But if this is true, then indeed my position
would change into the one you wrote.

> > >    Viewed from a purely technical perspective, Marcus's proposed
> > >    technical fix is quite brilliant (which is part of why I have
> > >    struggled with it so hard -- it is very elegant, and for Coyotos-OS
> > >    objectives, extremely damaging).
> > 
> > Why is it damaging?  I think (if you include the opaque storage in the way
> > I described) everything you wanted to do is still possible.  Except
> > allowing programmers (without an account on the system) to make agreements
> > with users.  They can only make agreements when they sell the software,
> > they cannot enforce that the agreements are actually kept.  That is good
> > IMO...
> 
> Yes. This is the essence of our difference in objectives. I do not agree
> that this is good, and Coyotos-OS will not undermine these agreements.
> On the contrary, it is a design objective of Coyotos-OS to support them
> well for the first time because I (and others) believe that a very wide
> range of valid and socially liberating *economic* interactions are
> enabled by doing so.
> 
> I do not believe that it is profitable for us to debate my view on this.
> We will waste a lot of bandwidth and time, and we will not converge.

Very well, I can accept that.  But I still want to understand what you think
you win by low-level opacity.  Because I don't see anything which isn't
possible in my model that is in yours (except technically, but it can be
worked around).

> > ... the programmer is not an entity which needs protection by the system.
> 
> This is precisely the point on which we disagree. Some of the
> applications that I have in mind are *exactly* applications where the
> programmer's interests require protection by the system from the
> administrator.

But he's not going to get it anyway.  If the system doesn't allow installing a
wrapper to cheat the program, he can still alter the code before installing
it.  The difference to the programmer seems to be in the kind of guarantee he
can make.
In your system: If you install the program unmodified, I guarantee X.
In my system: If you install the program unmodified and unwrapped, I guarantee
X.

In both cases, it comes down to:
If your users trust you to properly install the program, I guarantee X to
them.

How is the programmer protected at all?

Note if you want to use TC for the programmer to check that his program is
indeed properly installed, that can be done in my system as well.  Obviously a
sub-Hurd would not get access to the TPM chip, because it isn't trusted by the
system (but only by the user).

> I am not arguing here that Hurd-OS should change anything. I am trying
> to clarify where the differences in our design objectives lie. This is
> important so that we can all understand where the areas are that can be
> cooperative and where the lines of divergence exist that lead to
> differences in the systems we are building.

I agree.  I don't actually see any difference at the moment (except that you
want to protect programmers, and I don't, but since real protection isn't
possible without TC, and is trivial on both systems with it (assuming they
implement support for using it)), I don't understand why you insist on having
opaque space banks.

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