Developer key philosophy: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Removing all content from page)
(→‎Notes: avoid confusing cryptographic keys with colloquial name for memory device)
 
(5 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{draft}}

This page explains the reasons we have implemented developer keys. For information on what developer keys are, see the page on [[activation and developer keys]] for an overview, or [[developer keys]] for specific information on how to obtain and use that kind of key.

== Motivation ==

Well-designed software and hardware, when properly made, should let you do the things you are supposed to do. Another part of good design is ensuring that people who are not supposed to be able to do things (for instance, stealing laptops, or maliciously installing software intended to break an XO on a child's computer) are unable to do them.

Instead of locking down what children can and cannot do with the software on their machines, we have chosen instead to allow them to do ''whatever they want'' within a safe environment - as long as they are running a stable build that has been signed off on by OLPC to have working security (and other vital features), they can do pretty much whatever they want.

Developers, however, don't always want a "safe environment." It's important for developers to be able to use and test software that might crash, as it's better to find a bug on a developer's machine than on the XOs of 10,000 schoolchildren. A developer key allows a developer to bypass security features on their machine so they can experiment with bleeding-edge software.

== What isn't locked down ==

Even without a developer key, children can still do all these things (and more):

* Browse the web freely, without locks or filters (unless their particular deployment, school, teacher, or parent implements them).
* Download whatever learning materials they want.
* Install and run whatever software Activities they want on their XO - our security system prevents Activities from interfering with each other and with a child's data, so even if an Activity were to be maliciously designed, it would not break anything else on the laptop.
* Install and run signed, stable, OLPC-approved operating system and Sugar (UI) builds.

== What is locked down ==

These are the things you ''cannot'' do without a developer key.

* Install unstable, unsigned, or experimental OLPC software builds on your XO.
* Temporarily run, or install, a Fedora, Ubuntu, Gentoo, or Microsoft operating system (nor anybody else's except OLPC's).
* Type commands to the firmware (e.g. tell it what media to boot from).

== How to open the lock ==

Every XO user -- this means you, kids! -- has a right to unlock their own machine. This right is guaranteed by the GNU GPLv3 license on much of the software in the machine, and is also part of the [[OLPC on free/open source software|basic philosophy]] of the OLPC organization. Anyone can get a developer key (each machine needs a different key). See [[Activation and developer keys]] for how to do so. Any laptop user who values their rights -- that means you, kids! -- should get a developer key if they don't want to be restricted in how they can use their laptop.

== So why is there a lock, if anyone can open it? ==

The theory is that if your machine is stolen, it will refuse to run. The thief could get around this refusal if they could install any kind of software on the machine. In theory, a stolen laptop will not be given a developer
key, if the thief asks for one after it is stolen. It is an option of each country, whether they want their
laptops to arrive locked, or unlocked. Give 1 Get 1 donors do not get an option; theirs arrive locked, though for inscrutable reasons, not for anti-theft reasons. As of October 2008, no stolen laptop has ever been successfully turned off
by this mechanism. Every laptop user suffers a loss of freedom, in the hope that one day, at least one thief will be punished, or perhaps deterred.

== Notes ==

Our current implementation is not ideal. Some things that you currently need a developer key to do (auto-installation of rpms from a USB flash memory drive, for example) are things that we would like to move into the list of features that a child or teacher could do without a developer key. However, until we can come up with a stable, secure way for these features to be implemented on a child's XO, only developers experimenting with new builds and software can do these things. (Ordinary users can install RPM's over the network with "yum install", and can install RPM's from USB memory device using "rpm install". These commands work in the Terminal after turning on root privileges with the button toward the upper right corner.)

[[Category:Developers]]
[[Category:Philosophy]]

Latest revision as of 22:33, 5 August 2009


Pencil.png NOTE: The contents of this page are not set in stone, and are subject to change!

This page is a draft in active flux ...
Please leave suggestions on the talk page.

Pencil.png

This page explains the reasons we have implemented developer keys. For information on what developer keys are, see the page on activation and developer keys for an overview, or developer keys for specific information on how to obtain and use that kind of key.

Motivation

Well-designed software and hardware, when properly made, should let you do the things you are supposed to do. Another part of good design is ensuring that people who are not supposed to be able to do things (for instance, stealing laptops, or maliciously installing software intended to break an XO on a child's computer) are unable to do them.

Instead of locking down what children can and cannot do with the software on their machines, we have chosen instead to allow them to do whatever they want within a safe environment - as long as they are running a stable build that has been signed off on by OLPC to have working security (and other vital features), they can do pretty much whatever they want.

Developers, however, don't always want a "safe environment." It's important for developers to be able to use and test software that might crash, as it's better to find a bug on a developer's machine than on the XOs of 10,000 schoolchildren. A developer key allows a developer to bypass security features on their machine so they can experiment with bleeding-edge software.

What isn't locked down

Even without a developer key, children can still do all these things (and more):

  • Browse the web freely, without locks or filters (unless their particular deployment, school, teacher, or parent implements them).
  • Download whatever learning materials they want.
  • Install and run whatever software Activities they want on their XO - our security system prevents Activities from interfering with each other and with a child's data, so even if an Activity were to be maliciously designed, it would not break anything else on the laptop.
  • Install and run signed, stable, OLPC-approved operating system and Sugar (UI) builds.

What is locked down

These are the things you cannot do without a developer key.

  • Install unstable, unsigned, or experimental OLPC software builds on your XO.
  • Temporarily run, or install, a Fedora, Ubuntu, Gentoo, or Microsoft operating system (nor anybody else's except OLPC's).
  • Type commands to the firmware (e.g. tell it what media to boot from).

How to open the lock

Every XO user -- this means you, kids! -- has a right to unlock their own machine. This right is guaranteed by the GNU GPLv3 license on much of the software in the machine, and is also part of the basic philosophy of the OLPC organization. Anyone can get a developer key (each machine needs a different key). See Activation and developer keys for how to do so. Any laptop user who values their rights -- that means you, kids! -- should get a developer key if they don't want to be restricted in how they can use their laptop.

So why is there a lock, if anyone can open it?

The theory is that if your machine is stolen, it will refuse to run. The thief could get around this refusal if they could install any kind of software on the machine. In theory, a stolen laptop will not be given a developer key, if the thief asks for one after it is stolen. It is an option of each country, whether they want their laptops to arrive locked, or unlocked. Give 1 Get 1 donors do not get an option; theirs arrive locked, though for inscrutable reasons, not for anti-theft reasons. As of October 2008, no stolen laptop has ever been successfully turned off by this mechanism. Every laptop user suffers a loss of freedom, in the hope that one day, at least one thief will be punished, or perhaps deterred.

Notes

Our current implementation is not ideal. Some things that you currently need a developer key to do (auto-installation of rpms from a USB flash memory drive, for example) are things that we would like to move into the list of features that a child or teacher could do without a developer key. However, until we can come up with a stable, secure way for these features to be implemented on a child's XO, only developers experimenting with new builds and software can do these things. (Ordinary users can install RPM's over the network with "yum install", and can install RPM's from USB memory device using "rpm install". These commands work in the Terminal after turning on root privileges with the button toward the upper right corner.)