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

[Dan Williams]

On Mon, 2006-09-04 at 03:37 -0400, Ivan Krstić wrote:
> Ian Bicking wrote:
> > So are we talking about laptops identifying themselves to other laptops?
> 
> Yes. That's where the emergent PKI idea comes in.
> 
> > Or even the laptop identifying itself to... itself?  If HTTP-based RPC
> > is a major means of communication inside the system, then one can
> > imagine a need for identification.
> 
> Generally, this isn't an issue. Local web apps execute within the
> microserver; to do this, they already had to be trusted in some way.
> Once they're running, they can access system services via the
> microserver, which brokers D-Bus (or something else if needed) on their
> behalf.
> 
> > peer-to-peer code sharing that isn't entirely trusted (and I'm not sure
> > how feasible that is) then we'll need to really consider the security of
> > those communications.
> 
> It seems like the Sugar guys want to do this, but they're not providing
> a security model, nor an explanation of how they're addressing it.
> They're implementing mobile agents, and well, the security industry
> learned in the '90s that mobile agents don't work well at all. So, I'd
> like to see some careful thought about security from them really soon,
> or I'll be screaming murder.

We discussed some of this with Simson on Friday.  The activity bundles
will at least be signed by the originator to determine identity, and
communication in the system will be encrypted to deter
man-in-the-middle.  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.  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.

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.

Dan

> > One interesting thing is that URL-based capabilities -- where knowledge
> > of a URL implies permission to do some action -- is feasible on
> > localhost since there's no real danger of someone intercepting the
> > communication. 
> 
> Right.
> 
> > For peer-to-peer communications, does the mesh
> > networking mean the opposite, that interception should be assumed to be
> > possible?
> 
> Maybe. KCM gives us the primitives to easily secure all communication
> that we care about.
> 
> > particularly familiar with KCM, but I'm guessing it's a little like how
> > SSH works? -- i.e., you assume that there's a secure initial connection.
> 
> Yes.
> 
> > That would certainly be better than chain-of-trust systems; I've been
> > rather shocked how hard PGP clients make it to mark a key as trusted,
> 
> That model is pretty broken.
> 
> > # Student gets some popup -- like HTTP Basic login, except it doesn't
> > # ask for username/password; maybe it asks for an identity, plus
> > # confirms that a login should occur; maybe offers to automatically
> > # login in the future?
> 
> I think a whitelist-driven approach is right here. Really, the only
> situation where you want to communicate and authenticate the full
> identity is e.g. to the school server, or to other laptops in direct
> physical proximity. Everything else should be rejected by default. If
> we're popping up a yes/no dialog to protect the kid's privacy, we've
> already lost.
> 
> > I guess something like a common identity system would be the sort of
> > thing that would make up what Martin was talking about as a "web app
> > framework".  That's not normally what's talked about as a "framework",
> > but I'm not sure what to call it, and I can certainly see the value.
> 
> Right. A common identity identity broker of some variety that runs on
> the school servers will definitely be provided, allowing any application
> to call into it via a stable API.