bug-hurd
[Top][All Lists]
Advanced

[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: Mon, 29 Dec 2008 17:23:45 +0100

On 29/12/2008, Arne Babenhauserheide <arne_bab@web.de> wrote:
> Am Dienstag 23 Dezember 2008 12:19:26 schrieb Michal Suchanek:
>
> > Normally you can choose how effective the 'drm protection' is - in (d)
>  > you can defeat it by using the root handle. However, security
>  > involving hardware encryption and verification of system integrity by
>  > means of hardware cryptography device can enforce the 'drm
>  > protection'. Some applications might refuse to run on system that is
>  > not known to implement effective protection.
>
>
> Accessing some service which limits the system in a way which is incompatible
>  with the GPLv3 (as soon as central usage gets "interfered with" when I change
>  the code, distributing the system in non-source form violates the GPLv3 [1]).


I cannot parse the above paragraph.
If GPLv3 requires that operating systems are distributed in source
code only then it's stupid but it's probably trying to say something
else.

>
>  I think this settles the issue.
>
>  To sum up why a system which isn't designed for this kind of treachery is
>  better than one designed for that treachery:
>
>  If my (free) system is designed for treachery, then many system services
>  depend on treacherous servers. To make it non-treacherous I would have to
>  rewrite integral parts of the system.
>
>  If my (free) system is not designed for treachery, but someone adapted it to
>  be treacherous, I can simply undo the changes he/she did (or replace any
>  treacherous servers with fake servers which simulate an unchanged system) and
>  my system will be clean again.
>
>  So when I am the admin, a treacherous system is easier to use for treachery,
>  while a non-treachersous system is easier to use in an honest and ethically
>  sound way.
>
>  Non-free systems aren't open for discussion. They can't be used in an
>  ethically sound way.
>

What do you mean by "designed for treachery" here?

A particular feature is not treacherous by itself. What we are
speaking about here is memory protection. Is that treacherous? Then
all current systems are designed for treachery.

Or is hardware assisted verification of system integrity treacherous?
Then no system I am aware of is treacherous because I know no working
implementation of this.

Is the ability to say "this system is identical to version x.y.z of
system S as certified by cryptography device vendor V" treacherous?
If version x.y.z of system S is known to implement memory protection
properly you might be able to guarantee to your users that you cannot
access their memory. For me this guarantee seems weak because it
relies on the vendor V as well as bug-free operation of system S.
Either way I still fail to see the treachery here.

A practice by content provider P that requires you to guarantee that
you cannot access their content for them to sell you the right to
access their content is indeed treacherous.
For this they would require the guarantee as above: you allow them to
become a user of your system and verify that you cannot access their
memory on your system.

But this is not bound to a particular system architecture or design.
You can bolt on the treachery to any system that provides memory
protection because there are only two domains required: the domain
with the content that is not accessible to anyone unless the provider
allows it, and the rest of the system.

A system that provides useful security is much more complex, you
usually want finer grained security than 'public' and 'inaccessible'.

So if you are going to use the 'treacherous' stamp stamp it on all
current systems except perhaps FreeDOS. They all do memory protection
so you can bolt on treachery.

In my view trying to deny users the choice to enter contracts like the
one P requires is not the right way. It is morally dubious and
technically infeasible.

The right thing is to educate and make people aware of the danger.

Even if your system does not include a component that facilitates
contracts such as P requires users should be able to add it to any
system that's free whether you like it or not. You cannot make a
system that prevents users from doing something and still call it
'free'.

Thanks

Michal




reply via email to

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