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

Ivan Krstić krstic at solarsail.hcs.harvard.edu
Mon Sep 4 03:37:17 EDT 2006


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.

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

-- 
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


More information about the Sugar mailing list