Features-test

The controlling idea is that when an XO is stolen it will stop working after a time (activation lease time) unless it contacts a re-leasing server (usually a School Server). For example, if an XO is stolen and taken away from its school server, after the expiration of the lease time it will no longer boot up. If the XO is stolen but still comes within range of its school server, it can still be prevented from booting if the XO information (probably serial number) has been added to a black list on the XS.

• If the laptop is stolen, and doesn't contact its local school server within some period time (activation lease time) the XO will no longer boot. This state is known as passive-kill.
• Si se roba el XO y el XO no se contacta a su servidor (XS) local de la escuela dentro de una cierta hora del perío (tiempo del arriendo) el XO va a encender (boot). Este estado se conoce como muerte-pasiva.

• When the XO boots up and contacts the XS, its lease time is extended. e.g. if the activation lease time is 30 days and it starts on November 1, then the XO boots up on November 20 and contacts the XS, it will continue functioning without contacting the XS until December 20. This state is known as activated.
• Cuando el XO arranca y entra en contacto con el XS, su tiempo del arriendo es extendido. e.g. si el tiempo del arriendo de la activaciós 30 dí y comienza el 1 de noviembre, despuéel XO arranca el 20 de noviembre y entra en contacto con el XS, écontinuaráuncionando sin entrar en contacto con el XS hasta el 20 de diciembre. Este estado se conoce como activado

• Optionally as set by the administrator, if an XO is deactivated and tries to boot up when in the vicinity of its controlling school server, then it will boot unless it has been added to a blacklist. The blacklist is a list of XOs (by serial number?) which has been entered in to the school server by its administrator. That is, the activation lease time will be automatically extended whenever the XO contacts its controlling XS, unless it has been entered in the black list. Laptops that request their new lease from the XS and find themselves in the blacklist get into a state known as active-kill.
• Opcionalmente como fija por el administrador, si un XO se desactiva e intenta boot cuando esta en la vecindad de su servidor de la escuela que controla, despuéboot a menos que se haya agregado a una lista negra. La lista negra es una lista de XOs (por número de serie?) cuáha sido entrado adentro al servidor de la escuela por su administrador. Es decir, el tiempo del arriendo de la activacióeráutomácamente cuando el XO entra en contacto con su XS que controla, a menos que no se haya inscrito en la lista negra. Laptops que contactan el XS y se encuentran en la lista negra entran en un estado llamado muerte-activa.

• Must allow setting of the activation lease time by the deployment lead (user interface required). That is, they can set it for 90 days or whatever they want. The granularity should be at 24 hours and be from 1 day to never expire. Must allow setting this once for a recurring interval (e.g. XO leases expire every 60 days).
• Debe permitir el ajuste del tiempo del arriendo de la activacióor del despliegue (interfaz utilizador requerido). Es decir, pueden fijarlo por 90 dí o lo que quieren. La granulosidad debe ser en 24 horas y ser a partir de 1 dínunca a expirar. Debe permitir el fijar de esto una vez para un intervalo el repetirse (e.g. los arriendos de XO expiran cada 60 dí).

• Must not be possible for the user to set the date on the laptop to keep it within the lease period or to force it to outside the lease management. This might mean you cannot change the date or there is no root access, or it might mean an alternate time source is used.
• Necesidad no ser posible para que el usuario fije la fecha en el ordenador portál para guardarlo dentro del período del arriendo o para forzarlo fuera de la gerencia del arriendo. Esto pudo significar usted no puede cambiar la fecha o no hay acceso a root, o puede ser que signifique que una fuente alterna del tiempo estátilizada.

Note: XO-1 hardware is limited to 1 RTC clock so we cannot really do this.

• Must support the same as described above but allow the server which determines the activation to be across the Internet. The lease management server can be in a data center managed by the deployment or on a server managed by OLPC.
• Soporte los mismos requerimientos mencionados en el ultimo punto pero permita la activacion contra un servidor conectado a Internet. El servidor puede estar en un centro de datos manejado por NOC local o en un servidor manejado por OLPC.

• Must support the same requirement as described above but allow the reset of the activation to be done via USB key. That is, when an XO's lease expires, it must be booted with the USB key containing a special code. This can be done before it expires to extend the lease.
• Soporte el mismo requisito como se describe anteriormente pero permita que el reajuste de la activación sea hecho vía llave del USB. Es decir, cuando el arriendo de un XO se expira, ése debe boot con la llave del USB que contiene un código especial. Esto puede ser hecha antes de que expire para extender el arriendo.

• Should support the ability for an XS to continuously generate new leases every nnn time as set by the user (e.g. every 2 weeks). This will allow an XS to be placed in a school and then it does not need Internet access or anyone from outside the school to continuously update the lease times.

• Should support a GUI accessible from the XO which is password protected and encrypted (aka no passwords in the clear across the network/wireless). This GUI will allow a user in the school to enter an XO by serial number or better by name and have that XO added to the blacklist (see above, essentially its lease is not renewed).

See also write up on "Actual security requirements": User:Mstone/Commentaries/Security_1 and
Server side "Blueprint" at: http://wiki.laptop.org/go/XS_Blueprints:Lease_and_update_server

• Firmware Key and Signature Formats#Version 2
• http://dev.laptop.org/~cscott/joyride-api/bitfrost.leases.crypto-module.html
• http://lists.laptop.org/pipermail/security/2008-June/000441.html

• Must allow activation of XOs via wireless AP connection to a School Server
• Must work with all APs which the XO can work with. In particular, must work with open, WEP, WPA and WPAv2 APs.
• Should allow activation of many receiver XOs from a source XO. That is, the same as above but with the "server" being an XO.
• Must allow addition of activation keys to the Activation Server via USB.
• Should allow addition of activation keys to the Activation Server via network access.
• Should make it possible for the deployment to perform all activation tasks without OLPC intervention.

• See also image customization feature.

• Must support Right to left (RTL) in all Sugar GUI elements.
• Must support Right to left in Write
• Must include at least two good Arabic fonts
• Must support shaping in Write and in Sugar.

Test cases: