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

[Ian Bicking]

Ivan Krstić wrote:
> 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.

I'm bring it up because it's easier to define than determine.  Copy and 
pasted code?  "exec urllib.urlopen('...').read()"?  What kind of file 
operations are available?  How does metadata about origination move 
around with the content itself?  What if the user created the content 
and someone else edited it?  If the user wants to merge the changes from 
the other person, is the result user-created or not?

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

Definitely; and this is the easiest untrusted code to handle out of the 
many options.

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

OK, if it's not an exposed HTTP RPC then I think protecting it is much 
simpler, and can be done in the webapp.  Anyone can do "exec 
req.params['code']" in their webapp, obviously opening a huge hole, the 
framework can only discourage those sorts of holes.

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

Frankly it's a bit lame even with a gig of RAM, so it's hardly unique to 
OLPC, it just hits OLPC computers much faster and potentially with worse 
failure conditions (lacking swap).  Even if Javascript is memory 
limited, it may also be possible to use up memory by creating DOM nodes, 
which presumably are kept in a different memory space.

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

I've never gotten the impression that Spidermonkey is a particularly 
well-performing Javascript.  Rhino presumably was intended to replace 
Spidermonkey (I think?), but that doesn't seem like it'll ever happen. 
I might infer it's a hard problem.

OTOH, a good Javascript would be great.  An embedded Javascript with an 
underlying bytecode that other languages could target would be even 
better, and that's another benefit their engine might have (and maybe 
part of their motivation).

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

How do you see it different than Firefox extension installation?  In 
that model, you try to install something, you get a non-intrusive dialog 
that says that the installation was blocked and a link to a dialog to 
enable the site (with the form filled in).  Then you retry installation. 
  Popup blocking works the same way.  Because the UI doesn't ask any 
modal questions, no one is compelled to enable anything unless they feel 
a real desire to do so.  I.e., they won't misinterpret what "yes" and 
"no" means, or become desensitized to the dialogs.

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

Only that it creates a single-signon system that is coordinated to some 
degree with other services they might use.  This can potentially 
simplify their experience.

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

Yes; I guess I still find it easier to implement as a library, where 
perhaps multiple environments can read the same config file, and a 
simple file-based cache of public keys.  I went through this process 
with pubcookie, and found the extra server rather annoying to set up. 
Especially since it was just easiest to set up with inetd, and so it 
would have been even easier for the service consumer to just run a 
script in a subprocess to get the same information.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org