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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
