Antoine van Gelder wrote:
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.
I don't really see how KCM helps a whole lot. It allows people to
easily define some trust relationship, but trust relationships are
complex and imperfect anyway. Just because you know someone doesn't
mean you should trust that their laptop won't become compromised. And
even if you do trust them in that way, it doesn't mean you are *right*
to trust them in that way.
It's much easier to trust someone to interrupt you with IM messages, or
share content, or trust someone to see some writing you've produced.
These things don't cascade out of control very badly. This is where KCM
seems most useful.
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
I think this might be necessary anyway. I don't think the laptop is
going to be so locked down that the child couldn't hose the laptop if
they try. And these are kids, who knows what they'll try. So there
still needs to be a backup and restore strategy, and hopefully one that
doesn't mean losing all the child's data.
I think Ivan has in mind a separate storage for all the personal data,
that is distinct from normal files. How this relates to storing code,
I'm not sure -- but with Python and Javascript I know we don't need to
use the filesystem directly, and that's probably true of other
environments as well.
The storage would also be versioned. It's not a system-wide versioning
-- there's just no space for that, and even the revisions that are kept
around will probably get trimmed to save space. Anyway, some time-based
restore should be possible. Though I'm not sure in what situation that
would be necessary. Unless the child did the equivalent of "rm -rf",
and then of course the files need to be restored back into existence.
But I doubt, for instance, that you'll need to (or be able to usefully)
go back in time to the point just before your system lost integrity,
because no user data should be involved in the integrity of the system.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
