l4-hurd
[Top][All Lists]
Advanced

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

RE: Design principles and ethics


From: Christopher Nelson
Subject: RE: Design principles and ethics
Date: Wed, 3 May 2006 10:20:47 -0600

> On Tue, May 02, 2006 at 04:05:07PM -0600, Christopher Nelson wrote:
> > > > The program is *STOLEN* from me.  That is a problem.
> > > 
> > > So how did this "theft" (which I don't agree it is, but
> > > anyway) happen?
> > 
> > I don't know.  If I did, it wouldn't be theft as I would have 
> > PREVENTED it from happening.
> 
> Of course.  But I don't see how a constructor can help you with that.
> 
> > Are you saying that you believe that any work a person creates is 
> > automatically public property?
> 
> No.  I'm saying that any work a person creates _and releases_ 
> should be (but
> isn't) public property, except that the cost of reproduction 
> should be paid by the receiver (that is, if you build a 
> chair, and I like it, I should not be allowed to just take 
> it.  But I should be allowed to copy it, but I must pay for 
> the materials etc, not you).
> 
> Of course I am well aware that this isn't how things 
> currently work.  However, I think they should work like that, 
> and I'd prefer not to build mechanisms which enforce other schemes.

And how to people who make things like that get paid then?  Obviously,
they don't.  Which means that they will only do things like that in
their spare time, while having to make a living doing something else.
There are models which work well with software, but not things like
music.  What, a musician is going to charge for support services in case
a person is musically incompetent, but still wise enough to realize that
they need help?
 
> > > And why do you think a confined constructor is capable of 
> preventing it?
> > 
> > If I know that no one can examine AND MODIFY my data, then 
> I can make 
> > assumptions regarding the legitimacy of that data.
> 
> But you do.  We have a protected capability system.  It's 
> your data, and you're the only one who has access to it.  
> This data cannot have been "stolen"
> without you (probably by accident) giving away this 
> capability (or copying the data to where someone else can read it).

No, you DON'T.  This is my point: because your parent has all rights to
you, you can make no guarantees about your parent, or your parent's
parent.  Which means that you do *not* have any idea about who is in the
communication chain.

> > If I know that someone can examine, but not modify, that gives me a 
> > little more security.
> > 
> > Consider Diffie-Helman key exchange.
> 
> I know.  But here we are talking about a protected system.  
> There is no "man in the middle", except the kernel (which is 
> trusted).  So there is no problem.
> If you are speaking of the problems with encrypted network 
> connections, well yes, they exist.  But they don't depend on 
> constructors either.

Bas, communication is communication.  The man in the middle attack works
just as well in an OS as it does over a network.  My point in this case,
is that the child does not know who is between it and the user, cannot
make any assumptions about it, and because it's parents can modify it's
data and present it with a "false" world view, it can never communicate
securely with any other process.

-={C}=-




reply via email to

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