Re: Part 2: System Structure

[Bas Wijnen]

On Tue, May 23, 2006 at 12:13:17PM -0400, Jonathan S. Shapiro wrote:
> [If you are not interested in my comments about policy goals -- which in
> this note are not confrontational -- skip down to the part starting with
> "purely technical matters"]
> 
> On Tue, 2006-05-23 at 00:29 +0200, Bas Wijnen wrote:
> > We should not give people the choice to be oppressed, because it is not
> > the people who choose this, but the oppressors (in this case by not
> > providing any non-DRM content).  If DRM is not possible on any system (if
> > we would implement it, it would be the only system where it's possible),
> > they will provide the content through other means.
> 
> This is not factually true. The user *can* choose not to accept DRM
> content today, and a content provider could elect not to use it.

This is not what I was saying.  I'm saying that if we allow "real" DRM (that
cannot easily by circumvented even by using a sub-Hurd), then the content
providers (as far as they believe in DRM) will stop providing non-DRM content
and tell all people to use our system.  When that happens, the people
technically still have the choice to refuse DRM'd content, but that would mean
no content at all, which is not acceptable for most of them.  So effectively
they don't really have a choice.  I don't want to be the reason that such
things are made possible.

> The suggestion that the decision is entirely one-sided is complete nonsense.
> The problem is not lack of choice. The problem is imbalance of power.

Yes, but that means in practice that there will be a lack of choice.

> And this imbalance is not universal (see aside, but this is probably not
> central to the discussion).
> 
>   Aside: in the US, the porn industry (which accounts for the
>   overwhelming majority of DVDs produced and sold) generally does
>   *not* use content encryption, and I am not aware of any legal
>   case against copying that has been brought by the business
>   alliances in that industry. They rely instead on (a) a continuing
>   supply of new, um, faces, and (b) very low production costs.

Sure, this is an example of content providers which don't believe in DRM.
The problem is mostly the music an movie industrie, as far as I know, which
do.

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

Of course if people disagree and really want it anyway (as far as you can
speak of "wanting" in the presence of marketing, but anyway), they can choose
not to use the Hurd, but some other system which does allow this protection
(which has to be built first).  I hope that doesn't happen.  But if it does,
at least I haven't stimulated it.

> 1. RMS is mistaken about a detail: the source of DRM compatibility in
>    Coyotos is *not* the constructor per se. It is the combination of the
>    constructor logic and the requirement of opaque storage.

I'm not sure if RMS is mistaken, because I don't know what he thinks exactly,
but I agree with you.  I presume RMS considers "the constructor as in EROS",
which requires opaque storage by default, to be the source.  This is true as
well (although opaque storage without a constructor is just as bad).

>    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, because the
programmer is not an entity which needs protection by the system.  It isn't
actually a meaningful entity at all.  The only reason that the program is
acting as a proxy of the programmer is because the user who started the
program wants it to.  That user is the one who needs protection, not the
programmer.

> 2. None of the translucency policies that have been discussed are
>    enforced by the Coyotos kernel. If you are prepared to modify the
>    existing space bank very slightly (so that it does not enforce
>    opacity) and trivially adapting the existing core utilities, the
>    policy that you describe can easily be implemented.

Yes, I agree.

> So: eliminating DRM does not require eliminating constructors. A
> translucent space bank design is entirely sufficient. All of the rest of
> the properties that you are worried to avoid are a consequence of
> opacity. [It is possible that I have failed to consider something, but I
> am fairly confident about this statement technically.]

I think you haven't missed anything.

> I can even see approximately how the forensic support needed to make
> *use* of a translucent space bank could be implemented. It will be much
> easier to do this in Coyotos than in EROS, because processes are a
> separate object type. I would be willing to assist in the necessary
> space bank design changes, because I think that the debugging ability
> would be useful for Coyotos-OS independent of Hurd-OS.

That's very nice.  I think we will indeed want this.

> For Coyotos-OS, I will need to retain the mechanism supporting space bank
> opacity.

Are you sure about this.  The only thing that this allows is to hide
information from the common parent of the client and the server (because the
server will refuse to use storage that isn't authenticated by its own parent).
Is there any reason this is useful?

IMO, if a server was started from a parent which allows inspection of its
space bank, then the server shouldn't be allowed to fight that.  It shouldn't
even be allowed to know about it at all.

> For Hurd this can be compiled out or simply disabled on the prime
> bank by setting the "do not permit opaque child banks" restriction on the
> prime bank capability.

I'm pretty confident that we will want this, indeed.  I still think you might
want it, too. ;-)

> This offers a design option: keep the basic foundational utilities (with
> the addition of space bank translucency) as they are, and then build the
> rest of the system on top of this -- possibly following the hierarchy
> style that Marcus has proposed, or possibly modifying it in whatever way
> seems appropriate to you.
> 
> The advantage to this is that it will allow you to re-use the driver
> infrastructure and persistence infrastructure of Coyotos, which will
> save all of us a lot of work.

I had expected this to be possible all the time, indeed.  Actually, if it
wouldn't be possible, I think we would have a pretty big problem (because it
means a lot of extra work).

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