[Top][All Lists]

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

Re: Niches for the Hurd: evaluation method; was: DRM musings, capabiliti

From: Michal Suchanek
Subject: Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff
Date: Tue, 30 Dec 2008 14:04:52 +0100

On 30/12/2008, Arne Babenhauserheide <arne_bab@web.de> wrote:
> Am Dienstag 30 Dezember 2008 12:43:45 schrieb Michal Suchanek:
> > Yes, it does. But with DRM content protection it is not the system
>  > what makes the computer useless but the services or devices outside of
>  > the computer that would require a particular version of the system. I
>  > do not see how you can prevent this by the system itself or any
>  > license except by disallowing to run any not-free-enough (lgpl, gpl
>  > <3, bsd, non-free) application on the system altogether.
> The system provides something to the applications from outside which allows
>  these applications to find out the version of the system.
>  If this something is free, I can still tell the applications that my system
>  hasn't changed, and they continue to run, regardless of their licensing.
>  That something is then rougly speaking a part of the API of my system.
>  If that something isn't free, a part of my systems API isn't free, and since
>  that something can be used to check the version of any part of my system it
>  must not be unfree if any part of the system is free.

You need a special hardware to verify the integrity of the system, and
I can imagine that in a modular system the hardware driver might work
without modifications to the system  - think one of the initial
servers loaded with the mach kernel.

The driver itself need not be non-free, it would just reveal what
version (or more precisely the exact bitwise checksum) of the system
is running regardless of the actual version.

>  > In this case the code change would not make the system cease to work,
>  > it would render some applications (which must be non-free to perform
>  > their function and thus not part of the system) unusable on the
>  > system.
> Now please think a step further. What happens if running that application is
>  the primary function of the system?
>  (Take any application, and somewhere in the world you'll find someone who
>  almost exclusively uses that application)

If you distributed the system preinstalled on a camera, and the
imaging software on the camera would refuse access to your pictures
unless a verified version of the system is running then you can argue
it's the primary function.

However, for a general purpose system a random application
malfunctioning cannot be blamed on the system. Otherwise no system
would be allowed ;-)

>  > > It is designed to make it hard for the admin of the system to decide
>  > > whether DRM should be effective on his own system.
>  > >
>  > >  I thought I said that often enough.
>  >
>  > Probably not that clearly then. I fail to see how a system design can
>  > make a decision hard. It may come with poor documentation but that's
>  > all it can do in this regard.
> ThatTaking that decision means configuring / changing your system to allow or
>  not to allow DRM to be effective.
>  And the system design can make acting on the decision hard, just like code
>  obfuscation makes it hard to fix bugs.
>  If I have to rewrite a nontrivial part of the system to make DRM ineffective,
>  then the system is clearly designed for allowing effective DRM, and so it is
>  treacherous.

The Coyotos system is probably not complete enough at this point to
argue about the challenge of implementing a capability for accessing
all memory.

I would think that adding a 'debug' capability that allows you reading
(and writing if you wish so) all storage is not too difficult if it is
not already present for debugging purposes. However, matching the
memory to actual objects might be more challenging depending on the
way capabilities to the objects are implemented. Still you need a
debugger for that on any other system, too.

If you do not use hardware cryptography you can also shut down the
system and examine it offline (because of the persistence) which is
not possible with currently common systems and makes poking at things
actually easier because you get a consistent snapshot.



reply via email to

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