[sugar] Integration with web apps (and Moodle specifically!)
Antoine van Gelder
hummingbird at hivemind.net
Tue Sep 5 15:36:26 EDT 2006
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
>
<snip>
> 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?
*delurk*
Nice statement of the question.
Don't have a solution myself.
But I'll try and state the problem as best I understand it so far:
B. Secure from <- D. Lock down ability
hijack by to share & execute
malicious code arbitrary code
/ /|\
A. OLPC succeeds |
as an education /
project. |
\ \|/
C. Open computing <- D' Make it easy for kids
environment for to execute and share
kids to explore their own (and others)
and play in code
For A we _must_ have B&C, and to get B&C we feel pressure to do D&D'.
But when we try to do D&D' at the same time then the wheels fall off.
A common solution is to solve D&D' conflict is to build a big wall
between critical system code and user code with user code running in a
sandbox of one kind or another which can not cause mischief for the system.
Good solution but has a negative in that you can sometimes be limited in
terms of being able to easily do interesting things in the sandbox
without having to drag the entire digital certification industry in it
with you.
The proposed KCM solution is very interesting as it looks like it may
solve this problem without the complexities usually associated with code
signing although, as Dan said, experience has shown that with sand
boxing it takes a long time to get the details right.
But just for fun, let us look briefly to a time when this problem was
not so big:
"The only reason I ever had the courage to explore my C64 to its
limits as a kid was because I could instantly restore it to the
out-of-the-box state with the big red button my dad helped me
wire to the RST pin :-)
With my C64 I had no persistent environment that could be
corrupted, my applications were on separate floppies that could
not corrupt each other and my data was on yet another set of
floppies."
Large hard drives, multi-tasking operating systems and networking have
created the problem.
Suddenly everything is sharing the same space and can mess with each other.
So, to summarize, this problem does not exist when:
* Things can't modify each other
* The environment can be easily reset to factory state
But we cannot recreate the past by making all of this true again because
then we lose advantages of:
* Being able to easily access our data
* Being able to easily extend our environment
* Being able to interface small applications to create
big applications
I don't have a solution yet, apart from my own highly dodgy thoughts
about an ability to roll back the file system to any point in the last
'x' days where x=drive space and/or storage space on a central server
which would break the arrow between B&D by making it so easy to restore
the system to a pre-hijack state that it doesn't matter if malicious
code is executed. I know, lots of problems with this idea!
But... if any of the other arrows in the conflict can be shown to be
based on an assumption that is either not true for OLPC specifically
(OLPC has different constraints to normal laptop, these constraints are
still being explored and understood) or can be made to be no longer true
for OLPC then the problem may have a novel and workable solution.
So, what are the assumptions underlying the arrows ?
If A we must B because... ?
If A we must C because... ?
If B we feel pressure to D because... ?
If C we feel pressure to D' because... ?
We cannot D & D' at the same time because... ?
namaste
hummingbird
More information about the Sugar
mailing list