[sugar] Integration with web apps (and Moodle specifically!)

[Dan Williams]

On Mon, 2006-09-04 at 19:30 -0400, Ivan Krsti? wrote:
> 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.

Right; we've got two conflicting goals here:

1) not worming every OLPC out there through Melissa-like virus
propagation from people you trust

2) Making it easy for kids to learn about computers and share content


Python sandboxing would work, but there are a few issues with that:

1) you need the right balance of restriction vs. freedom, of course.  If
it's too restricted people just won't use it (Post-Its on monitors) or
it will be so cumbersome that's it's useless.

2) There's no code, of if there is code, it's not upstream in python,
meaning somebody has to finish it and maintain it

3) it takes a loooong time to get the details right.  Javascript & Java
have shown that.

4) How about activities that aren't done in Python?  Possibly you
restrict those even more to encourage people to write them in python, or
you restrict those to be country or OLPC signed such that the vast
majority of activities _are_ written in python.  Third-party apps are
likely here and we don't want to unneccesarily restrict the third-party
ecosystem.

Restricting activities to just country-signed or OLPC-signed activities
right off the bat would essentially destroy any ability of kids to
exchange activities.  We obviously can't do that.  We also can't have a
free-for-all.  We also don't have a lot of time to get this done.
Where's the middle ground?

Dan