Cómo te vigilan las aplicaciones: privacidad en Android e iPhone

Las aplicaciones no necesitan encender el micrófono a escondidas para analizar información sobre tus hábitos y luego usarla con sus propios fines. Basta con analizar tus acciones, los datos técnicos del dispositivo y la información a la que tú mismo les has dado acceso.

Está bien cuando los datos recopilados se usan solo para recomendaciones. Está mal cuando el desarrollador decide sacarse un extra y revender la información personal a una red publicitaria.

Analizamos cómo esos datos se convierten en un perfil de usuario y qué se puede limitar en los ajustes de Android e iOS.

Lo que tú mismo cuentas. La fuente más obvia es la información que el usuario deja voluntariamente en el servicio. El nombre, el teléfono, el correo electrónico, la fecha de nacimiento, la dirección de entrega, las búsquedas, las compras, los mensajes, los productos guardados en favoritos y cualquier formulario rellenado ya están dentro de la aplicación o en su servidor.

Acciones y datos técnicos. Prácticamente cualquier acción se puede convertir en un evento analítico: abrir la aplicación, entrar en una pantalla concreta, pulsar un botón, añadir un producto al carrito, ver un vídeo, contratar una suscripción o sufrir un error al pagar.

Para ello se integran sistemas analíticos en el código; por ejemplo, en el ecosistema Android es popular el paquete Google Analytics for Firebase. Registra los arranques, la duración de las sesiones, el modelo del dispositivo, el sistema operativo y algunas acciones dentro de la aplicación. Con eso basta para distinguir visitas recurrentes y analizar el comportamiento, aunque el usuario no esté registrado.

La telemetría no tiene por qué estar ligada a la publicidad. Los datos técnicos pueden servir para entender qué funciones se usan más, dónde abandonan los usuarios el proceso de compra o por qué una nueva versión de la aplicación funciona peor que la anterior.

Datos de sensores y de la memoria del dispositivo. Esta categoría la obtienen las aplicaciones a través del sistema de permisos. Existe tanto en iOS como en Android. Cuando el programa necesita la geolocalización del dispositivo, envía una orden al sistema operativo y el usuario ve la solicitud de acceso.

Hay muchísimas categorías de permisos. Una aplicación puede solicitar acceso a la cámara, al micrófono, a la actividad física, al escaneo de la red local, a los archivos del almacenamiento y un largo etcétera.

En Android, el sistema de permisos incluye también accesos que no requieren una autorización obligatoria por parte del usuario. Por ejemplo, para que el programa pueda conectarse a internet, al desarrollador le basta con declarar el permiso correspondiente en el código.

A veces las aplicaciones tienen una vía alternativa para obtener los datos que necesitan incluso si el usuario los deniega. Por ejemplo, se puede determinar la ubicación aproximada a través de la dirección IP.

El sistema de permisos. Aquí todo es sencillo. El sistema operativo cuenta con una API que gestiona el acceso a los datos protegidos. La aplicación solicita el permiso mediante un diálogo del sistema. La negativa del usuario limita el acceso y no se puede sortear sin vulnerar la plataforma.

Los permisos se dividen por recursos y por volumen de acceso. El acceso a la cámara permite hacer fotos, pero no abre automáticamente toda la fototeca. En los últimos años, iOS y Android han ido separando cada vez más los permisos. Por ejemplo, en lugar de la geolocalización precisa, en Android 12 y versiones posteriores se puede elegir la aproximada: el sistema calcula por su cuenta un punto en el mapa que ayuda a saber en qué zona de la ciudad estás, pero no revela más de la cuenta.

Por norma general, los permisos del sistema sí son necesarios para funciones concretas de la aplicación. Pero nada garantiza que el acceso se use de forma legítima. Una aplicación puede solicitar más datos de los necesarios, consultarlos con más frecuencia de la debida o usar la información obtenida para fines adicionales, como la analítica, la personalización o la publicidad.

Por cuenta propia o mediante SDK. Hoy los desarrolladores rara vez escriben sus propios sistemas de analítica y seguimiento. Es más fácil integrar un SDK, componentes de software ya listos.

Por ejemplo, el desarrollador añade Firebase Analytics y obtiene un sistema de analítica de producto. Integra Crashlytics y recibe informes de fallos. Un sistema como Adjust ayuda a saber de qué campaña publicitaria viene el usuario y si realizó la acción deseada tras la instalación. Todos estos datos pueden ir no solo al propietario de la aplicación, sino también al servidor del proveedor correspondiente.

Hasta qué punto puede ser detallado ese paquete de datos lo demuestra un experimento del desarrollador Timoféi Jiriánov. El juego móvil que probó envió nada más arrancar a la red publicitaria Unity Ads la versión del sistema operativo y el modelo del smartphone, el nivel de batería, el brillo y el volumen de la pantalla, el espacio libre de memoria, el operador de telefonía, el tipo de conexión a internet, la dirección IP, la geolocalización actual e incluso el marcador de consentimiento para el seguimiento publicitario, aunque el autor del experimento no había autorizado nada de eso.

Cómo se combinan los eventos en un perfil. Para vincular dos eventos hace falta un rasgo común. Por ejemplo, un identificador publicitario: en Android con los servicios de Google Play se usa el Google Advertising ID (AAID) y en el iPhone, el Identifier for Advertising (IDFA). El identificador no revela la identidad del usuario, pero permite unir distintas sesiones, aplicaciones e impresiones publicitarias en un mismo perfil.

Por ejemplo, el SDK ve que un usuario con un identificador concreto ha estado mirando un catálogo de zapatillas en una tienda online. Una hora después vuelve a aparecer en un juego y allí le muestran publicidad de esas mismas zapatillas.

Pero en realidad cualquier dato estable puede servir como identificador, como una dirección de correo electrónico. Incluso se puede aplicar un hash para anonimizarlo, pero luego usarlo para cruzarlo con datos de otras bases. Muchos SDK populares de analítica y publicidad también asignan a los usuarios identificadores propios.

Y aunque no se consiga crear un ID común, hay otra vía: el fingerprinting. La versión del sistema operativo, el modelo del dispositivo, la zona horaria, el nivel de batería y varias decenas de características más se combinan. Por separado, ningún parámetro es único, pero su combinación puede ser lo bastante rara como para distinguir a un usuario de otro. No es un método de perfilado tan preciso como el identificador publicitario, pero funciona.

¿Qué tiene de malo que una aplicación recopile información? Al fin y al cabo, el navegador sí necesita la geolocalización actual, la tienda online necesita la dirección de entrega y sus desarrolladores necesitan los datos sobre errores.

El principal riesgo está en cómo se usarán esos datos después. Se combinan con otra información, se ceden a socios o se venden a intermediarios de datos.

Primero, al propietario de la aplicación. En el escenario ideal, la información sobre el usuario se queda dentro de la empresa desarrolladora. Así funciona buena parte de la analítica de producto y la personalización: el historial de reproducción en un reproductor sirve para las recomendaciones, y el mapa de actividad en la interfaz, para mejorar la experiencia de usuario.

Pero cuantos más eventos dispersos se vinculan a una misma cuenta, más detallado se vuelve el perfil. Al final, la empresa puede determinar hábitos, intereses, lugares habituales y mucho más deducido de los patrones de comportamiento.

Después, a las plataformas analíticas y publicitarias. La aplicación puede usar SDK de terceros o enviar eventos a sus socios desde su propio servidor. No hace falta el perfil completo: a veces basta con el identificador del dispositivo y el nombre del evento.

Un ejemplo es la aplicación de seguimiento del ciclo menstrual Flo. Transfería a Google, AppsFlyer, Flurry y otras empresas analíticas y de marketing identificadores de dispositivos junto con eventos propios. Incluidos datos sensibles, como información sobre el embarazo. Es decir, el usuario compartía conscientemente datos médicos con el programa, pero no esperaba que acabaran siendo líneas en bases de datos de terceros para segmentar publicidad.

Luego, a agregadores e intermediarios de datos. Es un sector aparte que se dedica a recopilar, combinar y vender información. Un intermediario puede obtener datos de varias fuentes, cruzarlos entre sí y revenderlos a sus clientes.

La geolocalización móvil es especialmente valiosa. Así, el intermediario Mobilewalla reunió más de 500 millones de identificadores publicitarios únicos vinculados a una geolocalización precisa, formó con ellos una selección de mujeres que habían visitado centros de ayuda al embarazo y luego la ofreció a anunciantes interesados en una audiencia de embarazadas.

Y ni siquiera la supuesta anonimización de los identificadores salva siempre. Si un dispositivo pasa cada noche en una misma casa particular y los días laborables llega a una oficina concreta, el círculo de posibles propietarios se reduce drásticamente. A eso se puede añadir información de otras bases con el mismo identificador: preferencias de un marketplace, círculo de conocidos de una red social, historial de clics en anuncios desde un juego móvil. Y así los analistas acaban teniendo un mapa detallado de la vida de una persona.

Otro problema es que los datos se transmiten entre intermediarios y socios prácticamente sin control. Eliminar la cuenta en la aplicación de origen a menudo no basta: la analítica ya ha llegado a decenas de servidores de terceros y forma parte de selecciones para anunciantes.