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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
