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

[Ian Bicking]

Dan Williams wrote:
> 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.

I think making GUI stuff available to programs is a bit difficult, but 
otherwise I think this is one of the smaller problems.

In some situations the distributed code won't be an independent program, 
but some algorithm used elsewhere.  E.g., a robot AI for an automated 
competition, or some simulation, or a game that works in a very 
constrained framework (e.g., a quiz).  The constrained environments are 
a plus IMHO, when they are applicable.  And they also tend to be easier 
to figure out what should and shouldn't be available.

In some fashion, maybe every situations is like this.  So if you are 
distributing a general GUI program, you are distributing something 
written to a restricted GUI framework specially set up for use by 
sandboxed code.

That said, my experience with restricted Zope code is that it *was* 
quite frustrating to work with, and generally felt too restricted.  I 
think this has something to do with having sandboxed and unsandboxed 
Python code in the same process, and the challenge of avoiding 
unintended leaking where the sandboxed code could access something it 
shouldn't.  As a result all normal Python code and modules were denied 
by default.

> 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

This is a much bigger problem.

> 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.

This is potentially such a large and well-connected set of homogeneous 
computers that security seems like a very big deal.

Actually figuring out what code is executable seems a little difficult. 
  Is there a place where "external" content goes, and all interpreters 
(Python, Squeak, etc) have to know never to execute code located there? 
Or conversely, everyplace except explicitly permitted locations is 
denied, and maybe one special location for user-created content is 
permitted ("My Programs").  Is *everything* required to be signed in 
some fashion, and even user-created code has to be signed by the user?

> 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?

Well, child-generated shared program content is not going to be an issue 
immediately, I would think.  It takes a while to acclimate to the laptop 
at all before you start programming, and initial programming may best 
take place in an environment where sandboxing is more the norm (e.g., 
logowiki, Javascript, a slightly tweaked UCBLogo).

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org