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

[Ivan Krstić]

Ian Bicking wrote:
> "User-created" is a bit vague to me.  The-owner-of-the-laptop created?

"User-created" to me means "not imported from someone else over the
network". Network-imported content should get filed separately from e.g.
the kid's notebook, and I think that's a worthwhile delineation.

The greater problem is that I don't *like* the fact that we're denying
Javascript by default unless it's signed. It goes against our
educational principles; there's a lot to be gained from making it easy
for kids to whip up simple apps and share them with friends.

So I do want to change that.

> Of course, if
> there's HTTP based RPC on the laptop then "outside the browser" still
> includes things well within the realm of OLPC's security requirements.

There isn't direct HTTP-based RPC; instead, the server-side code
executing within the Python microserver can issue D-Bus requests. But
you can imagine that webapps will expose convenience methods for AJAX
requests that then go on to call into D-Bus; if these are accessible to
any JavaScript running on localhost, we have a problem. But:

> Simply checking the
> Referer header might be sufficient, as we can reasonably trust that it
> is accurate since we know the software stack on the computer.  (Unless
> Referer is turned off for privacy reasons.) 

That's my plan; for localhost, Referer should be present and trusted.

> In general, the issues around Javascript don't seem difficult to
> resolve, and there's not too many gotchas, because untrusted Javascript
> has been run for a long time now.  I also think Javascript has a lot of
> potential for offline content, if used properly.  Also, it may be the
> best scripting language we have for sharing untrusted programs.

+1.

> I don't know a whole lot about CPU and memory boundaries.  Well, I know
> if you write "while (1) {}" in Javascript, the browser will eventually
> interrupt it.  If you do "a=[]; while (1) {a.push('x')}" well, that just
> times out.  But if you use timeouts, you can get memory use to explode
> pretty easily.

And given our memory and CPU capabilities, these things are considerably
greater problems than when you have a gig of RAM to exhaust, and another
gig of swap. So we certainly want to solve this.

Alan Kay's team wrote a Javascript engine that supposedly outperforms
Spidermonkey by up to 75 times. I'm skeptical, but the team will be
visiting soon, and I certainly want to take a look at the work. Chris
told me that actually replacing Spidermonkey with anything else within
XULRunner would be very difficult, but for a 75x speedup (and the
ability to implement CPU and memory caps as a free bonus), it might be
worth the engineering effort.

> Well, considering something like Moodle, it seems quite likely that it
> wouldn't be deployed on the school computer, but instead on some
> upstream computer that is just on the internet somewhere. 

Eventually, it really ought to be deployed on the school server. But in
the interim, having the school server act as an identity broker to an
upstream server providing a service (e.g. Moodle) seems fine to me.

> possible that well-meaning people may make special services for OLPC
> users, but the developers otherwise have no relation to OLPC.  While
> initiating a relationship with these services doesn't need to be easy or
> automatic, it seems like the option will be useful.

Sure. When I talk about whitelists, I don't mean hard-coded ones. But I
might mean whitelists that you have to edit in a dialog somewhere,
instead of being able to modify by clicking an automatic popup.

> Maybe if IDs
> weren't trackable between these services that would mitigate some of the
> privacy issues.

What good are anonymous IDs for things like classroom and school
administration software? If a kid wants a Flickr account, he should
create a username and password.

> Hmm... I don't really understand the entire system you are proposing,

Say Moodle is running on the school server, and wants to authenticate
me. I'm a kid with an OLPC laptop, in range of the school server. I go
to the Moodle login page. My browser sees that I'm talking to the school
server which is whitelisted, and automatically detects the login page
(which includes a nonce), submitting the signed nonce back. Moodle now
has a signature blob that it needs to verify against the user database
on the machine, but which it does not manage. So it spawns off a simple
HTTP GET to some port on localhost, where an identity broker is running;
the broker takes the signed blob and the user's purported identity,
verifies the signature, and returns either a "nay" or an "aye, here's
information about the user" response. Make sense?

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