Security
Security needs to be a guiding principle of the entire OLPC design. Without a security model that is workable, implementable, and usable, the child's laptop will quickly become an unusable laptop.
While the danger in creating a "Security" page is that it can become a ghetto for security discussions, there are specific topics that can best be discussed in pages created specifically for this purpose. Each of these issues is given a specific page for the discussion of security policy and implementation.
Security Goals and Principles
- Usable security. The security mechanisms need to be easy to understand and easy to use. Ideally, secure operation should emerge organically and naturally through the laptop's normal operation. The user shouldn't have to be forced to decide between doing something in a manner that is secure and a manner that is expedient.
- Visibility. Security state and configuration should be evident. It should be clear when a given operation changes or somehow compromises the security of the system.
- Reversibility. It should be relatively apparent how to reverse configuration changes and restore security settings.
- Least Surprise. "The system should match the user’s experience, expectations, and mental models. In the context of computer security, this principle means that the computer should not perform an action in a manner that is not secure when the user expects the computer to be behaving in a secure manner. For example, if the user fills out a form on a web page that was fetched with SSL (and therefore has a lock in the browser’s status bar), the browser should warn if the form’s POST operation causes the data to be sent without encryption to another web server. (Ideally, the browser would even warn the user of this possibility before the user had invested time in filling out the web form.) Likewise, if the user instructs the computer to delete a file and the file disappears from the computer’s list of files, then the file should actually be deleted."
- Good Security Now. We can't build a system that offers perfect security, so we're going to try to build a system that offers good security now.
- Standardized Security Policies (no kit) Provide a small number of standardized security configurations that can be audited, documented, and taught to users.
- Consistent and Meaningful Vocabulary Prevent confusion by using words consistently to convey the same idea or concept in different programs and contexts. Likewise, prevent confusion by assigning consistent meanings to the same word in different applications or contexts.
- No External Burden Design security systems to have minimal or no negative impact on the friends, associates and co-workers of those using the technology, so that they do not push back on the users of the tools and ask that the use be curtailed.
(Quotes above are taken from [1])
Security Technologies
Security technologies must be appropriate for kids who are the primary users of the devices. Children have different conceptual views of the world, so adult-oriented security measures will not necessarily meet their needs. (Arguably, existing security measures don't meet adults' needs either.) In addition, the OLPC will be used in unusual network environments unlike the environments commonly encountered in the west. Few existing security tools and practices have been designed to work in peer-to-peer networks let alone, networks in which peers dynamically appear and disappear depending on whether the kid is reading or pedalling.
For the early phases the focus should be on basic built-in and invisible security measures that do not require any administrative actions by the kids. This needs to be coupled with a response team of developers who are ready to fix, improve and create additional tools and measures as experience is gained and problem areas are identified.
Quick response is superior to complex infrastructure built-in to the device.