Cómo funciona la Corona-Warn-App

El 16 de junio de 2020 Alemania publicó la Corona-Warn-App, su aplicación oficial de rastreo de contactos de COVID-19. En veinticuatro horas se había descargado millones de veces, lo que la convirtió en una de las aplicaciones públicas de adopción más rápida de la historia europea.

Como empresa de software con un pie en el mercado alemán, seguimos el desarrollo de cerca, en parte por curiosidad profesional y en parte porque es un caso de estudio de cómo se publica una aplicación sensible a la privacidad bajo un escrutinio público enorme. Esto es lo que hace la aplicación, cómo funciona por dentro y por qué importan las decisiones de arquitectura.

Qué hace la Corona-Warn-App

El propósito es sencillo: si pasó un tiempo relevante cerca de alguien que después da positivo por SARS-CoV-2, la aplicación le avisa para que pueda hacerse una prueba y aislarse antes de contagiar a otros sin saberlo.

Lo difícil es hacerlo sin construir una base de datos central de quién se encontró con quién.

La arquitectura: descentralizada por diseño

Alemania consideró al principio un modelo centralizado, en el que los datos de encuentros se subirían a un servidor del Estado. Tras un debate público con investigadores de privacidad, en abril de 2020 el gobierno federal cambió a un enfoque descentralizado basado en el marco Exposure Notification de Apple y Google. Es la decisión más importante de todo el asunto.

El flujo, en términos llanos:

1. Su teléfono emite identificadores aleatorios. Mediante Bluetooth de baja energía, la aplicación difunde identificadores generados al azar y de vida corta, que cambian cada pocos minutos. No contienen ningún dato personal.
2. Su teléfono anota los identificadores que oye. Los teléfonos cercanos que usan la aplicación guardan localmente los identificadores aleatorios ajenos, junto con la intensidad de señal y la duración, durante 14 días.
3. Un positivo se verifica. Si da positivo, puede compartir el resultado en la aplicación. Un paso de verificación — un código QR del laboratorio o un TAN de una línea telefónica — garantiza que solo se suban resultados auténticos.
4. De su teléfono solo salen las claves. La aplicación sube las claves de las que se derivaron sus identificadores aleatorios recientes. Ni ubicación, ni agenda, ni nombre.
5. Cada teléfono comprueba en local. Cada aplicación descarga con regularidad la lista de claves publicadas y la compara con los identificadores que anotó. La comparación ocurre en su dispositivo, no en un servidor.
6. El riesgo se calcula en su dispositivo. A partir de proximidad y duración, la aplicación estima su riesgo de exposición y muestra un aviso si supera un umbral.

El servidor nunca llega a saber quién se encontró con quién. Ese es el punto.

Por qué importa el código abierto

SAP y Deutsche Telekom construyeron la aplicación por encargo del gobierno federal, y todo el código fuente — aplicaciones móviles, backend, servidor de verificación — se publicó en GitHub antes del lanzamiento.

Para quien desarrolla es notable. Miles de personas revisaron el código, abrieron incidencias y enviaron correcciones antes de que el público la instalara. Para el público significó que las promesas de privacidad se podían verificar de forma independiente en lugar de creerlas. La adopción de una aplicación voluntaria depende de la confianza, y el código abierto es la manera más creíble de ganarla.

Límites que conviene conocer

La aplicación no es una solución mágica.

• El Bluetooth es una aproximación, no una medida. La intensidad de señal a través de una pared o de un bolso es imprecisa, así que hay tanto falsos positivos como falsos negativos.
• Necesita adopción. El beneficio crece con el cuadrado de la base de usuarios; un aviso solo salta si ambas personas usan la aplicación.
• Los resultados hay que conectarlos. Un positivo solo ayuda si el laboratorio o el centro de pruebas consigue entregarlo en la aplicación con un código QR verificado, y eso exige trabajo de integración del lado del laboratorio. Esperamos que se convierta en un tema importante a medida que crezca el dispositivo de pruebas.

Qué pueden aprender los equipos de software

Tres lecciones que nos llevamos a nuestros proyectos:

1. La privacidad es una decisión de arquitectura, no un documento de políticas. El modelo descentralizado hace el abuso técnicamente imposible, no meramente prohibido.
2. La transparencia gana al marketing. Publicar el código hizo más por la adopción que cualquier campaña.
3. La integración es donde el software de salud pública vive o muere. La aplicación vale lo que valgan las cadenas de datos que la alimentan.

Volveremos sobre este último punto. En Daleenda ya estamos mirando qué hace falta para que una instalación de pruebas se enchufe a este ecosistema — y la respuesta es que las herramientas apenas existen todavía.