On Wed, May 03, 2006 at 10:20:47AM -0600, Christopher Nelson wrote: > And how to people who make things like that get paid then?
That's a good question, and it requires a good answer. I can't give you one, though, since I haven't thought much about it. But it is clear to me that once the cost of making a copy is 0, charging people per copy just doesn't make sense. A new way needs to be found to pay artists for their music. I'm sure people who care enough about it will come up with something. > > > 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. Ah, you're confusing yourself with a process. The user session is a direct child of the primary space bank. The system design guarantees that - The primary space bank will not disclose its contents - The session itself (which is also part of the TCB) will not give out any capabilities to its space bank (but only to newly created subspacebanks). The user's shell is a direct child of the session. No process is going to spy on that shell. The user interacts with the system through this shell. There is no danger of spying. A shell starts processes. It can spy on them if it likes. But that's the user spying on his own processes (usually this is called debugging). Or he can choose to not do this. The processes cannot see the difference. But the user knows: If he doesn't personally debug his programs, noone does. However, there is a "chain of processes". What about a browser plugin? Can the browser spy on it? Yes, it can. But this is no problem for the user (since the browser is confined, and under control of the user) and the only reason the plugin exists in the first place is that the browser wanted to start it. If the plugin does encryption, that's not to protect against the browser: it doesn't have anything to hide, there's nothing in the plugin that the browser couldn't have without it. So: the process indeed doesn't know if it's spied upon, but the user does. > The man in the middle attack works just as well in an OS as it does over a > network. Of course. But there is no middle man here, except the user himself. So there is no danger of this kind of attack. > My point in this case, is that the child does not know who is between it and > the user, No, but the user does. > 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. Correct. If the user wants to modify the communication in order to see how the client reacts, then he can. And it's very good that the client does not have a defense against this type of debugging, because it's very useful. In short: the parent is trusted. The client cannot do anything that the parent can't. If there's an untrusted parent in between the user and a sensitive client, then something's very wrong in your configuration. If you think this can happen in normal situations (on a system which is designed to prevent it), then please let me know how you imagine this. 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
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
