Re: Challenge: Find potential use cases for non-trivial confinement

[Bas Wijnen]

On Mon, May 01, 2006 at 05:00:26PM +0200, Pierre THIERRY wrote:
> > > As a very short part of the algorithm is to be kept secret by the
> > > company who created it,
> > In that case they must not give it away at all.
> > 
> > Giving away code in a form that can run but not be studied is
> > something that the Hurd doesn't need support for IMO.
> 
> I have never considered, in any case, giving away code in any form in my
> use case.

It requires the other party to run the code.  The trivial way to allow this is
by giving it away.  Your use case didn't allow this, I just made that
explicit.

> > The good thing about non-technical solutions is that they leave room
> > for humans to decide if things are "right".
> 
> Why the hell then should we worry about security among users of the same
> system? Let's them choose socialy what they have access to, instead of
> enforcing those access policies with technical solutions!

As Marcus said, not everything can actually be solved socially.  But apart
from that, I agree that if the permissions are so simple that they can be
adequately described in technical terms, then we should allow this (if it
doesn't cost too much).  However, these cases of split ownership (where one
party owns the information and the other the storage) are not trivial at all.
If you try describing them technically you likely get it wrong.  For example,
if you try to implement copyright through DRM, then you will find that all
kinds of legal uses are suddenly no longer possible.  In such a case, I think
we shouldn't pretend that there is a technical solution (which would result in
"it wasn't protected, so I was allowed take it"), but solve it on the social
level instead.  If that isn't possible either, then we have a new problem. :-)

> There *are* legitimate cases where you want a technical solution to
> enforce some security policy.

Yes.  But some other cases, such as DRM to protect copyright, have
unreasonable side-effects.  We do not need to support such things IMO.

> Please don't use arguments you wouldn't apply to another case.

I agree that I shouldn't, and I don't think I did.

> > > the company would like that the program could be executed without
> > > being disclosed, while giving guarantee to the user that the
> > > processed data would not leak from their session.
> > In that case they must make sure they run it on their own computer,
> > without a network connection
> 
> That doesn't make possible for a logged in user to use the software
> without being able to inspect it.

Correct.  I was again showing why this was not a solution for the problem.

> > Summary: I think this is a case of "we don't want to support this".
> 
> Why?

Because the only reason it is needed is to support development of non-free
software.  Even more non-free than is currently possible, in fact.

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

signature.asc
Description: Digital signature