l4-hurd
[Top][All Lists]
Advanced

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

Re: L4-hurd Digest, Vol 40, Issue 23


From: Bas Wijnen
Subject: Re: L4-hurd Digest, Vol 40, Issue 23
Date: Tue, 2 May 2006 23:26:49 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Tue, May 02, 2006 at 01:44:43PM -0700, C Y wrote:
> > Hello,

Hi,

> I should say I personally would not suggest that an OS prohibit any
> possibility of DRM, since I doubt my own ability to certify that there
> is no legimitate use for it, but that's just a personal opinion.  There
> are an incredibly large number of uses for computers, and the search
> space for use cases is beyond easy determination.  

I agree that there may be legitimate cases, given the size of the search
space.  However, we know there are harmful cases, and currently we haven't
seen any legitimate cases that are big enough to support in a general-purpose
operating system.  This means that on the short term, the only good effect of
implementing such a feature is that it might speed up research and a
legitimate case may be found sooner.  On the other hand, it is certainly
harmful to implement it.  For that reason, I think it is a very bad idea to
implement DRM in the system if we can at all avoid it.

> > Yes, we are taking your "freedom" to enslave others.
> 
> There are many, many situations where I can envison a need to do this,
> assuming I'm understanding the use case correctly.  Whether it is
> legitimate is up for debate I suppose, but I might want to (for
> example):
> 
> a)  Automatically disable any internet communication when I am in the
> process of editing certain files, such as personal financial data.  I
> can store this on physically removable media, but when it is loaded
> into the computer for manipulation I would want to disable any internet
> activity.  I would also want to prevent any program from automatically
> reading those files - I would want them read ONLY on my explicit
> command, and only from my own user account.

On the Hurd, if you hold the right capabilities (not just anyone can do such
things), this is possible.  I wouldn't consider this "enslavement" either,
this is a design decision for the system administrator.  In the situation you
describe, it seems that you are the only user of the computer.  There is no
ethical problem in that case.

> b)  Allow only work-related programs to run on a server if an important
> distributed scientific simulation is running, in order to free up more
> CPU time.  In a university setting, machines are often multi-purpose -
> I may use CPUs both for student labs, and idle time for simulations. 
> Since the only legitimate student use of these machines is for lab time
> I want to be able to restrict people (at least the standard student
> accounts) from running programs outside of lab time.

It depends a bit on how scheduling capabilities are implemented, but I suppose
this should be possible as well.  Also, this doesn't seem like "enslavement",
but more like a contract in the social realm, which is enforced technically.

> c)  If I have just recieved a report of a serious security
> vulnerability or correctness flaw in a program, I may (depending on the
> problem) want to disable the running of this program for every account
> save my own until I can implement and test the fix.  I may want to
> unlock it for someone else during this procedure if I have to enlist
> help, but still keep it locked for general use.

I don't think this will be possible on the Hurd.  That is, if a user sees this
coming and copies the program into his own storage, then he can continue to
use it from there.  This is of course only possible if the program is not a
system service, because the user needs access to all capabilities of the
program in order to be able to run it from his own space.  And the good news
is that if the user is indeed able to run it from his own space, then only his
own resources are in danger of being compromised.

In case this is a system service (which is likely given the measures you want
to take), then this is indeed possible on the Hurd.  Again, I don't think this
amounts to "enslavement".

In all three examples, you describe things that a system administrator (on
different kinds of systems) may legitimately want to do.  Also in all cases, I
think the Hurd allows this (at least to the degree that is needed IMO).

> Anyway, I'm not an expert on these issues, so I apologize if I'm
> speaking redundantly or to the wrong problem.

If you were trying to formulate use cases for the challenge, then I think that
you are indeed addressing the wrong problem (that is, these are not use cases
for non-trivial confinement).  However, you seemed to be responding to a
message about "the freedom to enslave", and the examples were quite relevant
IMO.

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

Attachment: signature.asc
Description: Digital signature


reply via email to

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