<br><div><span class="gmail_quote">On 7/30/07, <b class="gmail_sendername">Jameson Chema Quinn</b> <<a href="mailto:jquinn@cs.oberlin.edu">jquinn@cs.oberlin.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Many of you are probably aware of the document on the wiki, "Correlating Bitfrost and Threats", attributed to Marc Stiegler. <a href="http://wiki.laptop.org/go/Correlating_Bitfrost_and_Threats" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://wiki.laptop.org/go/Correlating_Bitfrost_and_Threats
</a> . Still, browsing the archive for this mailing list, I do not see that this document has been discussed.</blockquote><div> <br>I hadn't seen it (thank you for pointing it out). Went ahead and read it and will add my feedback into the appropriate wiki section. Brief comments below. I encourage discussion on the list, though. This is where most people watch for such talk, and is a much more natural place to have a discussion.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><ul><li>The installation of applications under Bitfrost should be
tweaked so that, in addition to asking the application for a list of
requested endowments, the user is asked what kind of application is
being installed ("category-based installation"). The installation
endowment becomes the intersection of those endowments requested, and
those endowments appropriate for the application type.</li></ul></blockquote><div><br>Good on paper but I'm not convinced this could be shown to be useful in practice. The vector this is explained through is email attachments. That a malicious attachment (shock!) could be sent via email, somehow executed and rub with the email activity's Bitfrost permissions. To avoid this, instead of using vague (and contradictory) labeling systems, we will simply not let attachments be openly executed, a lesson we learned a decade ago. When they are executed, it is either (1) exploiting some Mail or Web activity(local or webmail, respectively), and are thus confined to the rate limiting, datastore limiting and containerization that are inherint to Bitfrost for such activities or (2) it is--less likely, given the scenario--seen as a new activity/application and the first-run installation sequence would be used. Again, limited to the containers, datastore limitation and token bucketing that limits the scope of any executable would have.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><ul><li> A computer-based training system that makes olpc owners
resistant to nigerian hoaxes should be explicitly included in the
security specification.</li></ul></blockquote><div>Training is beyond the scope of Bitfrost itself, of course. Training materials that are properly i18n'able and such I'm sure would be useful. A global help system for the XOs is being planned, and this is likely the proper place to explore the idea.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><ul><li> The Bitfrost mechanism for updating firmware should be given a
detailed end-to-end security review to ensure attackers cannot breach
the system and render olpc computers unrecoverable.</li></ul></blockquote><div><br>Absolutely. This is covered in Bitfrost @ P_BIOS_CORE<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<ul><li> Resources for these additional development efforts can be
acquired by postponing development of the centralized "anti-theft" user
identification system and the centralized backup system until a later
release.</li></ul></blockquote><div><br>No, they can't. Anti-theft is a highly, highly requested feature from our launch countries (from what I understand). Also, backup systems are critically important for a first-launch system. The likelihood of bugs is exponentially higher the newer the code, as is true of any software project, so being able to cope with such potential failures is an absolute must.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><dl><dd><ul><li> If olpc is unable to abandon these centralized
systems, decentralized architectures are proposed that achieve the same
goals while reducing single point of failure risk and privacy risk.</li></ul></dd></dl></blockquote><div>Currently, yes, the P_Theft systems phones home (the mechanism is optional, not required) to a centralized system. Making it more distributed is perfectly acceptable, and I am sure we would appreciate discussion in this direction. Something akin to the backup system (see next graph) might be reasonable;. Thoughts?
<br><br>The decentralized goals of data backup (if this is what you were thinking as part of 4a) is also addressed. Data is has a trickle up ability of the datastore of the XO, an SD card(?), the school server, potentially regional server(s), potentially country server(s) and some Global Servers In The Sky system. This is as distributed as can be. All data, again, is encrypted, so no peeping toms can look what their children are doing. Further suggestions are always welcome.
<br></div><br>Cheers!</div><br>-- <br>Michael Burns * Intern<br> One Laptop Per Child