La beta de rastreo de contactos NHS COVID-19 ya es de código abierto tanto para iOS como para Android, junto con parte de la documentación. Como continuación de nuestra entrada «Staying alive», hemos analizado a fondo el código fuente. Es una grata sorpresa encontrarlo con licencia MIT, lo que indica un compromiso de NHSX con la transparencia y la calidad.
En los dos últimos días, varios ingenieros han estado revisando la app para descubrir si es capaz de mantenerse activa y, en tal caso, ¡cómo lo hace! Entenderlo ha exigido un conocimiento del framework CoreBluetooth correspondiente más profundo del que tienen la mayoría de los desarrolladores. No es un framework en el que los ingenieros suelan tener que adentrarse.
Bastante pronto detectamos y comunicamos cómo funcionaba el truco en los dispositivos Android. Esta noche compartimos qué ocurre exactamente en iOS. Vamos paso a paso.
Primer inicio
En el primer inicio, la app envía una solicitud PUT a https://api.svc-covid19.nhs.uk/api/devices/registrations con un código de activación, un token de notificaciones push y la primera mitad del código postal introducido por el usuario. Como respuesta, el servidor devuelve un linkingId que se almacena en los ajustes de la app.
La app también solicita permisos de notificaciones push y de Bluetooth, como cabría esperar. No solicita permisos de ubicación y, por lo tanto, no valida el código postal del usuario. Solo se necesitan los primeros dígitos de un código postal.
Se ha afirmado que la app para Android accede a datos de ubicación, porque el aviso de acceso a la API de Bluetooth en dispositivos Android parece pedir permisos de ubicación. Sin embargo, lo desmentimos ayer: es una consecuencia de cómo Android gestiona las solicitudes de permisos de Bluetooth.
Mantenerse activa en Android
Evitar que una app se duerma en segundo plano es trivial en Android, ya que las API estándar admiten esta funcionalidad y dan a los ingenieros acceso de bajo nivel al hardware Bluetooth.
Sin embargo, en iOS la historia no es tan sencilla. Cuando las apps pasan a segundo plano en iOS, su funcionalidad se reduce de forma significativa. Esto también ocurre con CoreBluetooth, el framework de Apple que da a los desarrolladores acceso al Bluetooth. A falta de una solución alternativa ingeniosa, esto dificulta mucho más que la app detecte iPhone que puedan estar ejecutándose en modo de segundo plano. Hicimos pruebas con varios dispositivos iOS dejados sin tocar durante varias horas y observamos que el sondeo se producía con menos frecuencia, pero que los dispositivos seguían comunicándose durante la noche.
Usar Android para despertar iPhone
Ayer también comunicamos que, cuando están en segundo plano, las apps de iOS siguen emitiendo anuncios de Bluetooth, pero de una forma distinta y específica de Apple. Creíamos que los ingenieros de NHSX y Pivotal habían aplicado ingeniería inversa a esto y habían añadido compatibilidad con ello a la app para Android. Podemos confirmar que es así, y sus detalles técnicos se pueden consultar aquí. Esto significa que, además de que los dispositivos iOS pueden mantener la app en segundo plano, los dispositivos Android pueden despertar a un dispositivo iOS «dormido» sin importar cuánto tiempo lleve en segundo plano.
Entonces, ¿qué implicaciones tiene esto? Pues que, para que la app funcione, un iPhone debe estar con bastante frecuencia al alcance de un dispositivo Android, para poder enviarle keepalives que lo mantengan en segundo plano. Eso por sí solo podría no ser una solución viable, pero...
Usar dispositivos iOS para despertar... otros dispositivos iOS
En la entrada de ayer, «Staying alive», comunicamos que creíamos que la app para iOS usaba «keepalives» para eludir las restricciones del segundo plano. Tras examinar el código fuente de la app para iOS, concluimos que, efectivamente, es así. Pero ¿cómo funcionan exactamente?
En pocas palabras, un keepalive, en este contexto, es una idea que se les ocurrió a los desarrolladores de la app: es una notificación enviada entre dos dispositivos iOS que ejecutan la app para mantener viva la conexión entre ellos. Lo interesante es que esto también tiene el efecto de permitir que la app permanezca activa durante mucho más tiempo, ya que, cuando un dispositivo recibe un keepalive, iOS permite que la app siga activa para realizar algo de procesamiento adicional.
Desde un punto de vista práctico, esto significa que la app podrá mantenerse activa siempre que esté cerca de otros dispositivos. En cierto sentido, esa es la razón de ser del proyecto de rastreo del COVID-19: incluso sin este truco técnico, hará falta una masa crítica de usuarios que ejecuten la app de rastreo para lograr un buen resultado en materia de seguridad pública.
Al margen de esto, la app no se duerme de inmediato ni entra en estado suspendido cuando pasa a segundo plano. La cuestión pasa a ser, entonces, si la mayoría de los usuarios estarán rodeados de suficientes dispositivos iOS o Android como para que las soluciones alternativas sean viables. Nuestra opinión es que parece probable, y más aún en el caso de los usuarios que estén con más frecuencia en zonas pobladas. El Bluetooth tiene un alcance efectivo decente.
Algunos observadores han sugerido que la capacidad de la app para recibir notificaciones silenciosas significaba que usaba estas capacidades para despertarse a sí misma de forma remota. Sin embargo, estas capacidades se usan simplemente para informar al usuario de si ha estado cerca de alguien que haya contraído el COVID-19. La app también usa notificaciones locales que detectan cuándo el sistema cierra la app, e indican a los usuarios que la vuelvan a abrir. Se usa una notificación similar cuando el usuario desactiva el Bluetooth.
El director ejecutivo de Reincubate, Aidan Fitzpatrick, dice:
Sí, es cierto que el próximo framework
ExposureNotificationde Apple en iOS 13.5 elimina la necesidad de estos keepalives. Sin embargo, conviene señalar que:
- iOS 13.5 no se ha publicado, y puede que no lo haga en algunas semanas
- Hasta ayer, la última beta de iOS 13.5 tenía un fallo de seguridad grave, lo que sugiere que los equipos de ingeniería de Apple están trabajando a fondo
- Una vez publicada, probablemente pasarán meses hasta que la mayoría de los usuarios de iOS la instalen (aunque es inusual, la adopción equivalente en Android puede ser más rápida)
- Los dispositivos iOS más antiguos, como el iPhone 6, no pueden ejecutar iOS 13 y no podrán usar la técnica de Apple
- No hay ninguna razón por la que la app NHS COVID-19 no pueda pasar automáticamente en el futuro a usar el framework de Apple, o incluso ejecutar ambos mecanismos en paralelo
La app será cada vez más eficaz a medida que más personas la usen, y el beneficio de la adopción masiva creará en este sentido un efecto volante. La app australiana COVIDSafe tuvo dificultades porque no admitía detectar dispositivos iOS en segundo plano desde un dispositivo Android, y no tenía este ingenioso mecanismo de keepalive entre dispositivos iOS.
Es importante reflexionar sobre en qué circunstancias resulta apropiado usar una tecnología como esta. Si el rastreo de contactos logra salvar vidas, ¿qué criterios deberían evaluarse para decidir si se aplica a futuras enfermedades? Una vez sentado el precedente, ¿hay argumentos para que esta tecnología se use para combatir enfermedades infecciosas ya existentes? Es previsible que distintas sociedades evalúen las contrapartidas de forma diferente.
Salvaguardas de privacidad
Aunque redactar un análisis detallado de las matemáticas del protocolo queda un poco fuera del alcance de esta entrada, sí examinamos las salvaguardas de privacidad. La app parece ceñirse estrictamente al documento publicado por el NCSC. Podemos confirmar que ningún dato de claves sale del dispositivo del usuario hasta que este notifica síntomas y que solo entonces salen del dispositivo las claves anonimizadas de los dispositivos con los que ha estado en estrecha proximidad. La primera mitad del código postal introducido por el usuario se envía a la API como parte del servicio de registro.
En última instancia, el código sugiere que el uso de la app supone poco riesgo técnico para la privacidad hasta que el usuario notifica síntomas y se pone en contacto con el NHS para concertar una prueba. En ese momento, el resultado de su prueba sería gestionado por el NHS, aunque eso no es distinto con la app o sin ella. Sin embargo, cuando varios usuarios entran en contacto, notifican síntomas y conciertan pruebas con el identificador que les ha proporcionado la app, puede que sea posible vincularlos de forma centralizada, o puede que no. Esa es una cuestión del back-end y, como afirma NHSX en su informe de privacidad de la app, el código es la verdad en este aspecto.
Protección frente a informes falsos
Como el back-end del sistema no es de código abierto, no es posible confirmarlo, pero parece que no se envían notificaciones push a otros dispositivos hasta que los ciudadanos dan positivo por COVID-19. Cuando un usuario notifica síntomas, se le da un código de referencia que puede usarse para reservar una prueba. (Este código resulta ser el mismo que el linkingId que describimos en la sección de registro).
