Desde el lanzamiento de la aplicación “Perú en tus Manos” (PETM), en Hiperderecho hemos hecho seguimiento a su desarrollo desde diferentes puntos de vista. Por un lado, se ha cubierto a nivel legal temas como la privacidad y la transparencia en la creación y despliegue de este tipo de tecnologías. También, aunque con menor detalle, hemos analizado críticamente las funciones técnicas de la aplicación y otros posibles desarrollos. En este artículo queremos profundizar aún más en este ámbito, principalmente para dejar en claro qué información de sus usuarios recoge esta aplicación, cómo lo hace y hacia dónde la envía.

El caso de PETM es interesante porque se presenta como una herramienta de información para los ciudadanos, pero también como un instrumento para que el gobierno pueda tomar decisiones. Para lograr ambos objetivos, la tecnología base con la que funciona este aplicativo es el GPS, que  ya hemos analizado en una publicación anterior, señalando sus ventajas y desventajas.

A diferencia de propuestas en otros países como Italia, India, Reino Unido o República Checa, la aplicación peruana no es de código abierto. Es decir, el Gobierno no ha puesto a disposición del público el código fuente que hace posible la aplicación, haciendo difícil entender de primera mano cómo funciona y poder colaborar con mejoras o notificar de errores en el código. A pesar de esta limitación, gracias a que PETM ha sido desarrollada también para Android de manera nativa, es posible entender hasta cierto punto cuál es su arquitectura e incluso ver parte de su código fuente. El procedimiento que seguimos para obtener estos datos fue obtener el archivo APK de la aplicación desde una de muchas páginas que ofrecen este servicio. Luego de un proceso de decompilación, haciendo uso de la herramienta apktool, fue posible acceder a archivos fundamentales para el desarrollo del aplicativo como es el MANIFEST y algunas clases que contienen parte del código fuente de la aplicación.

Entre los principales hallazgos, resalta el hecho de que la aplicación podría solicitar acceso a más información de la que finalmente envía al servidor. Es decir, datos como cuando encendemos el celular o cuando conectamos y desconectamos el cargador son declarados  por la aplicación, pero no se envían de regreso al Gobierno. Ya sea por acción u omisión, esto va en contra de lo señalado en la Política de Privacidad de la aplicación, podría impactar en el desempeño del equipo y confundir al usuario.

El Manifest

Toda aplicación Android debe tener un archivo Manifest. En este archivo, además de un identificador universal de la app (package name), se declaran los componentes de la aplicación, entre permisos, servicios, broadcast receivers, activities y content providers. La información en el Manifest también es la que decide si una aplicación es visible para el modelo y versión de sistema operativo del teléfono. El único requisito para poder instalar la aplicación del Play Store es que nuestro equipo móvil tenga una versión de OpenGL ES 2.0.

El objetivo de los permisos es proteger la privacidad de los usuarios. A través de estas solicitudes, las aplicaciones de Android solicitan al usuario permiso para acceder a datos confidenciales como ubicación, agenda, mensajes de texto, así como a ciertas características del sistema como la cámara e Internet. Los permisos que solicita PETM en su última versión son los siguientes:

FOREGROUND_SERVICE	Permite a una aplicación realizar servicios en primer plano, mostrando una notificación al usuario.
ACCESS_FINE_LOCATION ACCESS_COARSE_LOCATION ACCESS_BACKGROUND_LOCATION	Este conjunto de permisos permiten a la aplicación acceder a la ubicación del teléfono, sea que la aplicación esté siendo utilizada o no
ACCESS_NETWORK_STATE INTERNET	Permisos que le permiten a la aplicación acceder a información de red. INTERNET es un permiso que permite abrir conexiones de red.
READ_GSERVICES	Permiso que permite leer la configuración de Google Services en el teléfono
BLUETOOTH BLUETOOTH_ADMIN	Permite a la aplicación buscar y conectarse a otros teléfonos/dispositivos mediante Bluetooth
WAKE_LOCK	Permisos para mantener el CPU del teléfono encendido
com.google.android.c2dm.permission.RECEIVE	Otorga permisos a la app para registrarse y recibir mensajes de Google Cloud Messaging GCM
RECEIVE_BOOT_COMPLETED	Permite a la aplicación recibir el evento de cuando el teléfono termina su proceso de encendido

Un Broadcast Receiver es un componente que permite registrar eventos del sistema (como cuando se conecta el cargador, cuando se enciende el dispositivo, etc). Android notifica a todos los receptores registrados para un evento una vez que ocurre este evento. Para el caso de PETM tenemos los siguientes Broadcast Receiver.

MyNotificationPublisher	Es el encargado de notificar al usuario que cierta acción se está realizando desde la aplicación (Una notificación de uso de GPS, alerta, etc)
ACTION_POWER_CONNECTED ACTION_POWER_DISCONNECTED	Es el registro para recibir los eventos de cuando el celular ha sido conectado o desconectado a una fuente de energía
BATTERY_OKAY BATTERY_LOW	Es el registro para recibir los eventos de cuando el teléfono tiene batería buena o mala
DEVICE_STORAGE_LOW DEVICE_STORAGE_OK	Es el registro para recibir los eventos de cuando quede poco almacenamiento en el teléfono o cuando vuelva a un estado normal.

 

Otro componente importante en las aplicaciones son los servicios. Un Service es un componente que sirve para que una aplicación pueda realizar operaciones o instrucciones largas sin necesidad de interactuar con el usuario. Algunos servicios pueden ser asociados a recolectar información de ubicación, por ejemplo en PETM tenemos.

BackgroundLocationUpdateService	Es el servicio encargado de obtener la ubicación del teléfono en segundo plano y enviarla según el API/WebService seleccionado.
LocationUpdatesService	Es el servicio encargado de obtener la ubicación del teléfono en segundo plano y enviarla según el API/WebService seleccionado.
MyFirebaseMessagingService	Es un servicio que se encarga de intercambiar mensajes en primer o segundo plano con Firebase
AppMeasurementService AppMeasurementJobService (hay muchos receivers y services más involucrados)	Servicios necesarios para el uso de Google Firebase Analytics

¿Qué información recolecta PETM?

A pesar de los permisos, servicios y broadcast receivers descritos anteriormente, no toda la información que la aplicación recolecta es enviada al servidor central de PETM. Esto está descrito en las clases ApiClient.java y ServicesApiInterface.java luego del proceso de decompilación. Esto significa que, pese a que la aplicación ha solicitado permiso para acceder a toda esa información, no toda es transferida al Gobierno, al menos por el momento.

Algo importante respecto de la información que sí es enviada es que todas las solicitudes al servidor, necesitan agregar un header llamado device-key para obtener una respuesta adecuada.

Hablando de hacia dónde se dirige la información, se verifica que el URL del servidor es https://covid.kambiahora.com/ y no una dirección con un nombre de de dominio del Estado (*.gob.pe). Aunque la Política de Privacidad señala que los datos serán procesados por empresas como Google y Amazon Web Services, el nombre de dominio kambiahora.com está vinculado a la empresa Kambista S.A.C. En cualquier caso, las principales consultas a las que se hace llamado son las siguientes:

GET	alerts	No necesita parámetros
GET	quantities	Necesita un parámetro llamado date para obtener las cifras de casos positivos, muestras procesadas, personas recuperadas, personas hospitalizadas, personas en cuidados intensivos y el total de fallecidos.
GET	dates	No necesita parámetros y retorna información de las fechas donde existe información de las cifras.
GET	marks/check-version	Se requiere un parámetro llamado version y retorna un conjunto de puntos (latitud, longitud) de las posibles zonas de riesgo de acuerdo a la versión de la app que se esté ejecutando en el dispositivo.
GET	countries	Sin parámetros
GET	terms	Esta consulta requiere un parámetro llamado type y que devuelve información sobre los Términos y Condiciones o Políticas de Privacidad.
GET	versions/check?os=android	Esta consulta verifica si es necesario realizar una actualización a la app enviando un parámetro llamado code.
POST	location/save	Este método es el encargado de enviar información del dispositivo a los servidores. Los valores que envía son: un deviceId que identifica de manera única a un dispositivo Android, lat que hace referencia a la latitud, lon que hace referencia a la longitud, os que indica el sistema operativo que está enviando esa información y por último version para indicar la versión de la app ejecutándose en el teléfono. Este método se llama en un periodo de cada 5 a 10 minutos.
POST	user/register	Este método se utiliza para el registro de un usuario nuevo de la aplicación. Es ahí donde se registra el deviceId del dispositivo y es asociado al código de ubigeo (codeUbigeo), dígito de verificación del DNI (digitVerified), número del DNI (identityDocumentNumber), tipo de documento identityDocumentType, si es peruano o no (isPeruvian), y en caso no serlo, la nacionalidad (nationality) y por último el número de celular (phoneNumber).

¿Cómo está impactando esta aplicación en el uso del teléfono?

Decíamos que la aplicación pide muchos permisos, pero actualmente no está recopilando toda la información que podría recopilar. Como se mencionó en otro artículo, PETM actualmente no es más que una aplicación que principalmente reproduce contenido disponible en webs ya existentes del estado (triaje, estadísticas). No obstante, desde el Estado ya se anunció que pronto la aplicación tendrá más funcionalidades. En caso se otorguen los permisos necesarios para que la aplicación funcione como se promete, esta pasaría de mostrar contenido estático a hacer un seguimiento a la ubicación del teléfono de manera casi constante.

En términos de consumo de energía, esto significa que existirá un proceso en segundo plano ejecutándose y que se ve reflejado en el uso de la batería como lo explicamos en el artículo de cómo funcionan las aplicaciones de GPS. Esta funcionalidad no consume tanta batería como una aplicación de streaming como Netflix o Amazon Prime, pero es notorio su uso a comparación de otras aplicaciones con las que el usuario tiene poca interacción.

¿Qué ganamos haciendo todo esto?

Pese a las propuestas de Hiperderecho a la Secretaría de Gobierno Digital de disponer el código fuente de la aplicación PETM en un repositorio abierto, este despacho parece aún no haber tomado una decisión al respecto. Decidimos tomar el camino descrito al inicio de este artículo para entender cómo funciona por dentro la aplicación y qué información recolecta, con el objetivo de resolver dudas de los usuarios de la aplicación que en muchas ocasiones no entienden preguntas como: ¿Por qué no he recibido alertas si he pasado por una zona roja? ¿Por qué me siguen saliendo los mismos puntos de riesgo si la cantidad de infectados es mucho mayor a los puntos que veo en el mapa?¿Qué diferencia existe en llenar el triaje desde la aplicación versus llenarlo desde una laptop o el navegador de mi celular?

Esto no reemplaza la necesidad descrita en la solicitud a la Secretaría de Gobierno Digital porque, a pesar de las características que podemos extraer a partir de la decompilación del APK de PETM, aún existen partes de la aplicación que no es legible al 100% luego de ese proceso. Es necesario acceder a este tipo de solicitudes que más allá de generar confianza con los ciudadanos, permite a la comunidad de desarrolladores aportar con recomendaciones o mejoras en el código para un mejor funcionamiento.

Si, desde el gobierno, se considera que la aplicación PETM será una herramienta fundamental para la toma de decisiones no solo ahora sino cuando las personas gradualmente retomen sus actividades, se deben definir protocolos y procesos que van más allá de la tecnología. Al mismo tiempo, se necesita ser transparentes con estos protocolos con el objetivo de promover la discusión desde el punto de vista legal y tecnológico.

Foto: Andina