Dan Williams wrote: > So you'll at least be able to ensure that, if you're > passed an activity, nobody modified it in-transit, and that somebody > signed an activity bundle.
We'll be able to do this for most all communication, so it's not that part that worries me, it's this part: > Now, whether or not you trust that person is > a different story, and how/if you ask the child what they want to do > with it. This assumes that trusting a person is the same as trusting code that the person thinks is trustworthy. That's an assumption that's absolutely and clearly incorrect on just about every level. > Ideally that integrates into the KCM such that if your friend Kristin > signed the activity bundle with a private key, and you have Kristin's > public key stored because you have a trust relationship with her, it's > all magic. We can't do this until we have working Python sandboxing. Before then, movable code will need to be restricted to e.g. OLPC-signed or country-signed code; I see no other way to prevent a simple worm from wreaking complete havoc on the machines. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
