l4-hurd
[Top][All Lists]
Advanced

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

Re: Execute without read (was Re: the deadly hypercube of death, or: han


From: Marcus Brinkmann
Subject: Re: Execute without read (was Re: the deadly hypercube of death, or: handling permissions)
Date: Fri, 28 Apr 2006 01:47:48 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Fri, 28 Apr 2006 01:10:54 +0200,
Pierre THIERRY <address@hidden> wrote:
> 
> Scribit Marcus Brinkmann dies 28/04/2006 hora 00:47:
> > > Wouldn't it be possible to be able to execute a program without
> > > being able to read it?
> > However, I don't know any actual use cases of this pattern that I am
> > interested in supporting.  Quite the opposite: I find the use cases I
> > do know morally objectionable.
> 
> In general, I think you should not decide to drop a feature only because
> you find it's uses morally objectionables. For two reasons:

I think that's an excellent reason to drop a feature, especially if
its are its _sole_ uses.
 
> First, you may not have envisionned some use cases that are not morally
> objectionable, so you are volontarily limiting users' freedom because
> you just missed something. That morally objectionable, at least. ;-)

I have thought about it hard and long.  I have talked to a variety of
supporters to hear the best use cases they can offer.  I have
developed a framework to argue about it at a rather abstract and
objective level.  I have developed a design principle that I find
important to support, that, if applied, rejects the feature.  All this
together is a strong indication that rejecting it is a good idea.  The
whole process has taken me about half a year.

> Second, you should consider that the morally objectionable uses are part
> of the freedoms of the users.

I wrote "principle of user freedoms (as I define them)".  These
principles of user freedom have analogies in the GNU principles of
software freedom, and the anti-DRM provision of the GPL v3, but I have
come upon them from a completely different line of thought.

Maybe you should wait for me to formalize my arguments until you jump
to conclusions about why I am rejecting this.  So far I only gave you
the summary.

> That's precisely why free software doesn't
> limit the use of software. And there are a bunch of people that would
> surely not agree with you that all the uses you rejected are morally
> objectionable, or that some that you enabled were indeed morally
> objectionable.

I have no intention to limit the use of software beyond what the GPL
v3 requires (or, as a matter of fact, GPL v2).

> I fully support the fact that you won't implement yourself some schemes.
> But as an OS architect, you must not close doors to other implementers
> of thoses schemes, at least for this only reason.

As an OS architect, no.  As a free software programmer and activist, I
have strong reasons to do so.

> Naturally, if it is a
> burden to let the door open to some undesirable scheme, we don't have to
> shoot ourselves in the foot for what we don't want.
>
> > Your mileage may vary, but in the end this boils down to the DRM and
> > Trusted Computing discussion.
> 
> Not sure. What about the following use case:
> 
> Alice and Bob are two students attending a software development course.
> On the departement's system where they have both an account, Alice want
> to let Bob try her first draft of the program they have been asked to
> produce.
> 
> Either she knows Bob has difficulties, or they are in a fair
> competition, and Bob is known to be quite honest but easy to tempt to
> cheat. So she wants him to only be able to execute the program, not read
> it.

I would recommend that Alice and Bob go to a keg party and have a beer
over their differences.

I would further educate Alice about the importance of exchange of
ideas and learning from each other, which is a fundamental requirement
for all success in the sciences.  I would also tell her that
developing software is team work, and if she wants to increase her
chances at getting a good job, she should learn to work in a team
early on.  I would explain to her that it is often easier to rewrite a
program from scratch than to reverse engineer it, and if Bob is able
to cheat by using her program in a way that is not obviously
detectable, then he is probably good enough that it doesn't matter
anymore if has the ability to cheat.

Furthermore, I would talk to Bob and warn him about the danger of NDAs
and similar offers of information which do not increase his abilities
to do something, but increase his liabilities and restrain him from
helping others.  He would be better off looking for people to
cooperate with at a mutual level.

It's really sad that some students have swallowed up the story of
"everybody against everybody" so early in childhood that they bring
this attitude to university.  It's something that we should work
against, not support.

Thanks,
Marcus





reply via email to

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