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

[Ian Bicking]

Ivan Krsti? wrote:
> Ian Bicking wrote:
>> What about local content?  Javascript content on a host can open
>> XMLHttpRequests to the same host, so any content on localhost that isn't
>> scrubbed could initiate any kind of RPC to localhost.
> 
> With present plans, only user-created or OLPC-signed content is allowed
> to execute JavaScript. I'm open to revisiting this in rev2, since I
> think it can be made more permissive without loss of security: e.g. a
> cap on CPU and memory utilization, and denial of XHR would be enough to
> solidly contain unsigned JavaScript, but I don't think there's time to
> do this for rev1, unless it gets picked up by someone in the community.

"User-created" is a bit vague to me.  The-owner-of-the-laptop created? 
That seems rather difficult to determine.  Content seems particularly 
likely to be collaboratively developed at which point there isn't any 
owner, and even if there was an owner that ownership metadata about the 
content doesn't seem very stable.  Also, it's not something that lends 
itself to the concept of ownership very well, so I would expect it to be 
a bit baffling to children why content works in one context and not another.

The security of Javascript seems quite good as it is.  There's some XSS 
issues that are still out there, but those generally only effect the 
integrity of content or accounts outside of the browser.  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.

Currently anyone can create a form like <form 
action="http://localhost/...">, and it works.  This is problematic in 
itself, even though you can at best post a url encoded submission, which 
probably won't be a valid RPC call.  Anyway, protecting localhost better 
than it is -- Javascript or no -- would be good.  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.)  I dunno.

Not serving content under the same domain name as RPC would also go far 
to help things.  It leverages all of Javascript's existing cross-domain 
security boundaries.  In that model the domain that serves RPC is 
separated from the domain that serves content, and the content-serving 
domain is easier to protect.

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.


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.  Here's what I used:

<script type="text/javascript">
a = [];
function addOne() {
     for (i=0; i<1000; i++) {
       a[a.length] = new Date();
     }
     setTimeout(addOne, 10);
}
setTimeout(addOne, 10);
</script>



>> Would it be akin to how popup blocking works in Firefox (and extension
>> installation)?  I.e., reject by default, but notify the user of the
>> rejection and allow them to change that decision.
> 
> What scenarios do you envision where full identity authentication is
> desirable, outside of the mesh and the school server? If there are
> compelling ones, we can implement the popup-like interface, but
> otherwise, I'd like to make it more difficult to approve the authentication.

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.  It's quite 
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.  Maybe if IDs 
weren't trackable between these services that would mitigate some of the 
privacy issues.

>> Would it have to be a broker, or could this just be a protocol with
>> library implementations in the environments most likely to be relevant
>> (Python, PHP, Ruby, whatever).  
> 
> To remove the need for callers to implement access directly to the data
> repository and deal with locking, the callers instead speak to something
> that does this for them. That something is the broker; the protocol to
> speak with the broker will presumably have libraries in a bunch of
> different languages (in fact, it's very likely to just be HTTP).

Hmm... I don't really understand the entire system you are proposing, 
but anyway this detail isn't really important right now.

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