l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

DRM and freedom (was: Re: awareness + flexibility + security


From: Marcus Brinkmann
Subject: DRM and freedom (was: Re: awareness + flexibility + security
Date: Thu, 10 Nov 2005 17:33:15 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 10 Nov 2005 16:40:19 +0100,
Bas Wijnen <address@hidden> wrote:
> Following the DRM discussion, we may want to explicitly add the GNU project
> freedoms to the design principles.  At least me and Antrik have used them to
> reject supporting the TC chips, so it fulfils Jonathan's "definition" of a
> design principle ("they can be used to reject things"). :-)

This is a very important, and as you can imagine, sensitive topic.  It
is not as clear cut as you make it.

We all agree that DRM are Evil(tm), and we don't want to support them
at all.  This is beyond question.  We have to analyze if strong
security, which means the ability to enforce privacy, builds on the
very same principles as DRM technologies.  Our intuition is that, yes,
it does.

This means that we have to make a very difficult judgement.  It's a
judgement of political strategy---does it actually make a difference
to DRM if we support technologies that can be used to implement
DRM?---and balance; how much are you willing to give up along with
low-level primitives that also support DRM technologies.

We have to have this discussion, but it is not helped by knee-jerk
reactions.  I am taking this issue very serious, and will talk to a
number of people about it, including Jonathan, Richard, and I hope
that I can also include Eben in this discussion (I haven't asked him
yet).

However, note what the consequence is of what you are saying.  If you
reject TC technologies, and strong security like confiment and
mandatory access control via capabilities, and principle of least
authority and fine-grained separation permissions, then this has deep
consequences.  To me, it suggests that there is then probably no
advantage of using a capability system at all, and one should better
look at other models.

If you say that "no, no, I just want to reject TC, but I still want
all the other capability stuff", then you have a problem, because it
will be trivial to just change the underlying kernel to support TC,
and then to build a subsystem that runs in parallel to the Hurd which
enforces DRM technologies.

This can even be true if your system is not suitable for DRM at all.
There are various companies, groups and people trying to implement
these technologies in Windows, Linux, and other systems.  It's harder
on those systems, but we don't have a reason to believe that they will
fail completely.

At the very last resort, they can simply bribe the politicians to make
computer systems that don't support DRM illegal.  And in fact, they
can make DRM mandatory why forbidding privacy, for example by
requiring a key repository.

So, we have three issues here:

* The technology question if DRM and privacy are inseparable or not.
* The strategic question if it makes a difference if we have a structure that
  makes implementing DRM easier.
* The political question, which is how much privacy we want.

The hardest is a balance between the second and third point.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]