Una inmersión técnica profunda en la aplicación de rastreo de contactos NHS COVID-19

La beta de rastreo de contactos NHS COVID-19 ahora es de código abierto para iOS y Android , junto con cierta documentación . Como seguimiento de nuestra publicación " Mantenerse con vida ", hemos profundizado en el código fuente. Es gratamente sorprendente encontrarlo bajo licencia del MIT, lo que indica un compromiso de NHSX con la transparencia y la calidad.

En el transcurso de los últimos dos días, varios ingenieros han estado revisando la aplicación para descubrir si, ¡y cómo! - Es capaz de mantenerse con vida. Comprender esto ha requerido una comprensión más profunda del marco CoreBluetooth relevante que la mayoría de los desarrolladores poseen. No es un marco en el que los ingenieros generalmente necesiten profundizar.

Bastante temprano, vimos e informamos cómo funcionaba el truco para dispositivos Android. Esta noche, compartiremos lo que está sucediendo en iOS. Vamos a atravesarlo.

Lanzamiento inicial

En el primer lanzamiento, la aplicación realiza una solicitud PUT a https://api.svc-covid19.nhs.uk/api/devices/registrations con un código de activación, un token de notificación push y la primera mitad del usuario ingresado código postal. En respuesta, el servidor responde con un linkingId que se almacena en la configuración de la aplicación. La aplicación también solicita notificaciones push y permisos de Bluetooth, como era de esperar. No solicita permisos de ubicación y, como tal, no valida el código postal del usuario. Solo se requieren los primeros dígitos de un código postal.

Se ha afirmado que la aplicación de Android accede a los datos de ubicación, ya que la solicitud de acceso a la API de Bluetooth en dispositivos Android parece solicitar permisos de ubicación. Sin embargo, desacreditamos esto ayer: esto es una consecuencia de cómo Android gestiona las solicitudes de permisos de Bluetooth .

Mantenerse vivo en Android

Evitar que una aplicación se suspenda en segundo plano es trivial en Android, ya que las API estándar admiten esta funcionalidad, lo que brinda a los ingenieros acceso de bajo nivel al hardware de Bluetooth.

Sin embargo, en iOS la historia no es tan simple. Cuando las aplicaciones están en segundo plano en iOS, su funcionalidad se reduce significativamente. Este es también el caso de CoreBluetooth , el marco de trabajo de Apple que brinda a los desarrolladores acceso a Bluetooth. A falta de un sonido de trabajo inteligente, esto hace que sea mucho más difícil para la aplicación detectar iPhones que podrían estar ejecutándose en modo de fondo. Probamos con varios dispositivos iOS que se quedaron solos en el transcurso de varias horas, y notamos que las encuestas se realizaban con menos frecuencia, pero que los dispositivos aún se comunicaban durante la noche.

Usando Android para despertar iPhones

Ayer también informamos que, en segundo plano, las aplicaciones de iOS continúan transmitiendo anuncios de Bluetooth, pero de una manera diferente que es específica de Apple. Creíamos que los ingenieros de NHSX / Pivotal habían realizado una ingeniería inversa de esto, y le agregamos soporte a la aplicación de Android. Podemos confirmar que este es el caso, y sus detalles técnicos al respecto se pueden encontrar aquí . Lo que esto significa es que, además de que los dispositivos iOS pueden mantener la aplicación en segundo plano, los dispositivos Android pueden activar un dispositivo iOS "inactivo", independientemente de cuánto tiempo haya estado en segundo plano.

Entonces, ¿cuáles son las implicaciones de esto? Bueno, significa que para que la aplicación funcione, un iPhone debe estar dentro del alcance de un dispositivo Android con bastante frecuencia, por lo que puede enviar alertas para mantenerse en segundo plano. Eso por sí solo podría no ser una solución viable, pero ...

Uso de dispositivos iOS para despertar ... otros dispositivos iOS

En la publicación de ayer " Permanecer vivo ", informamos que creíamos que la aplicación iOS estaba usando "keepalives" para eludir las restricciones de fondo. Después de examinar el código fuente de la aplicación iOS, concluimos que este es el caso. Sin embargo, ¿cómo funcionan exactamente?

En pocas palabras, un keepalive, en este contexto, es una idea que se les ocurrió a los desarrolladores de la aplicación: es una notificación enviada entre dos dispositivos iOS que ejecutan la aplicación para mantener viva la conexión entre los dispositivos. Lo interesante de esto es que también tiene el efecto de permitir que la aplicación permanezca despierta durante mucho más tiempo, ya que cuando un dispositivo recibe un estado de alerta, iOS permite que la aplicación permanezca despierta para realizar un procesamiento adicional.

Desde una perspectiva práctica, esto significa que la aplicación podrá mantener su estado vivo dado que está cerca de otros dispositivos. En cierto sentido, esta es la razón del proyecto de rastreo COVID-19: incluso sin este truco técnico, una masa crítica de usuarios necesitará ejecutar la aplicación de rastreo para lograr un buen resultado de seguridad pública.

Independientemente de esto, la aplicación no se duerme inmediatamente y entra en un estado suspendido cuando está en segundo plano. Por lo tanto, la pregunta es si la mayoría de los usuarios estarán cerca de suficientes dispositivos iOS o Android para hacer posibles las soluciones. Nuestra opinión es que esto parece probable, y más aún para los usuarios que están más regularmente en áreas pobladas. Bluetooth tiene un alcance efectivo decente.

Algunos observadores han sugerido que la capacidad de la aplicación para recibir notificaciones silenciosas significaba que estaba usando estas capacidades para despertarse de forma remota. Sin embargo, estas capacidades se utilizan simplemente para informar al usuario si han estado cerca de alguien que haya contraído COVID-19. La aplicación también utiliza notificaciones locales que detectan cuándo el sistema mata la aplicación, instruyendo a los usuarios para que vuelvan a abrir la aplicación. Se utiliza una notificación similar cuando el usuario deshabilita Bluetooth.

El CEO de Reincubate, Aidan Fitzpatrick, dice:

Sí, es el caso de que el próximo marco de Apple ExposureNotification en iOS 13.5 obvia la necesidad de estos keepalives. Sin embargo, vale la pena señalar que:

• iOS 13.5 no se ha lanzado, y puede que no sea por algunas semanas
• Antes de ayer, la última versión beta de iOS 13.5 tenía una falla de seguridad importante , lo que sugiere que está ocurriendo un gran esfuerzo en los equipos de ingeniería de Apple
• Una vez que se lance, la mayoría de los usuarios de iOS tardarán meses en instalarla (inusualmente, la adopción equivalente de 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 cual la aplicación NHS COVID-19 no podrá realizar una transición automática en el futuro para usar el marco de Apple, o incluso la doble ejecución de ambos mecanismos

La aplicación será cada vez más efectiva a medida que más personas la utilicen, y el beneficio de la adopción masiva creará un efecto volante en este sentido. La aplicación australiana COVIDSafe tuvo problemas ya que no era compatible con la detección de dispositivos iOS de fondo desde un dispositivo Android, y no tenía este ingenioso mecanismo de mantenimiento de iOS a iOS.

Es importante reflexionar sobre qué circunstancias hacen uso de tecnología como esta apropiada. Si el rastreo de contactos es exitoso para salvar vidas, ¿qué criterios deben evaluarse para determinar si se aplica para enfermedades futuras? Una vez establecido el precedente, ¿existe un argumento de que esta tecnología podría usarse para combatir enfermedades infecciosas preexistentes ? Es previsible que diferentes sociedades evalúen las compensaciones de manera diferente.

Salvaguardas de privacidad

Si bien la redacción de un análisis detallado de las matemáticas detrás del protocolo está un poco fuera del alcance de esta publicación, analizamos las salvaguardas de privacidad. La aplicación parece cumplir estrictamente con el documento publicado por el NCSC . Podemos confirmar que no hay datos clave que abandonen el dispositivo del usuario hasta que notifiquen síntomas, y solo entonces las claves anónimas de los dispositivos que han estado cerca para abandonar el dispositivo. La primera mitad del código postal ingresado por el usuario se envía a la API como parte del servicio de registro.

En última instancia, el código sugiere que hay poco riesgo técnico de privacidad al usar la aplicación hasta el momento en que un usuario informa síntomas y se comunica con el NHS para organizar una prueba. En ese punto, el resultado de la prueba sería administrado por el NHS, aunque esto no es diferente con o sin la aplicación . Sin embargo, en el momento en que varios usuarios entran en contacto, informan síntomas y organizan pruebas utilizando el identificador que la aplicación les ha proporcionado , puede o no ser posible vincularlos de manera centralizada. Esa es una pregunta de fondo, y como NHSX declara en su informe de privacidad de la aplicación, el código es cierto a este respecto.

Protección contra informes falsos

Como el back-end del sistema no ha sido de código abierto, no es posible confirmarlo, pero parece que no se envían notificaciones push a otros dispositivos hasta que los ciudadanos den positivo por COVID-19. Una vez que un usuario informa síntomas, recibe un código de referencia que puede usarse para reservar una prueba. (Este código es el mismo que el linkingId que describimos en la sección de registro).