l4-hurd
[Top][All Lists]
Advanced

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

Clarification (was: Re: Challenge: Find potential use cases for non-triv


From: Marcus Brinkmann
Subject: Clarification (was: Re: Challenge: Find potential use cases for non-trivial confinement
Date: Wed, 03 May 2006 11:20:54 +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)

Hi,

this is a clarification of a rule in the challenge.

I wrote:

> (2) The use case must contribute to the GNU Hurd as a free software,
>     general-purpose operating system.

If you want to suggest a use case, please make sure that you state
what the contribution is.

I also wrote:

> The contributed value must be explicit (that means, not speculative)
> and obvious.  Please include the content of the contribution in your
> proposal.

The conditions "explicit" and "obvious" are important.  One of my
strongest "weapon" to make a use case fail the test is to simply
suggest that the proposed goal or contribution may be inappropriate.
If we can reasonably disagree on the contribution, then it is not
explicit and obvious.

Let me give you an example.

The idea to be able to save the high score of a game in a computer is
explicit and obvious.  (Unfortunately, the example is not confined,
but it is still interesting to look at it very carefully, so I will
probably do so).

The idea to be able to cut and paste from one program to another, is
explicit and obvious.  To add the extra requirement that there is no
backflow of information seems reasonable to me, at least it sounds
desirable (after all, cut&paste is, superficially, a uni-directional
action).  The proposed solution in the paper The EROS Trusted Window
System uses confinement for formatting.  So, this is a use case that
interests me.

Any idea that presupposes DRM, and then comes to the conclusion that
DRM is needed to implement DRM, will be rejected because it is not
obvious that DRM is desirable.  In fact, this is exactly what we try
to find out.  In other words: to find out if DRM is necessary, we can
not start from the assumption that it is.

The goal or contribution must be stated in a form that does not
pre-suppose the result.  Otherwise, it is a logical impossibility to
disprove it.

This misunderstanding has happened in the past, and I was accused of
avoiding a technical question, or by answering a technical question
with a moral concern.  However, in all these cases, it should be
possible to verify that the technical question was a variation of
this: "If you want to do DRM, how do you implement DRM?"  Or: "If you
want DRM, how do you implement DRM without implementing DRM?"  In
these cases, I must reject the goal to maintain a consistent position.

I hope this is clear enough.  The term DRM above is meant to be used
in the broadest possible sense (ie, any application of trusted
computing technology).

Thanks,
Marcus





reply via email to

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