Privacidad de plataforma y minimización

Una aplicación puede tener impecable cada diálogo de permiso de este nivel y ser, aun así, un desastre de privacidad. El permiso regula el acceso a un dato en un instante; no dice nada sobre cuánto tiempo lo conservas, con quién lo compartes, qué biblioteca de análisis lo reenvía a un tercero sin que tú lo sepas, ni qué se puede reconstruir cruzando lo que recoges con lo que recogen otros. Esa segunda mitad del problema no la gobierna el sistema operativo sino un entramado de declaraciones contractuales ante la tienda, arquitecturas de aislamiento en construcción y obligaciones legales que varían por jurisdicción. Es la parte del trabajo que no compila, que no se puede verificar con un test y que sin embargo determina si tu aplicación seguirá publicada dentro de un año. Y tiene una particularidad que conviene enunciar desde el principio: es la única parte donde la respuesta técnicamente correcta y la respuesta comercialmente conveniente coinciden casi siempre, porque el dato que no recoges no se filtra, no se declara, no se audita y no cuesta nada almacenar.

El manifiesto de datos: una declaración verificable

Toda aplicación publicada en Google Play debe declarar, en la sección de seguridad de los datos, qué información recoge, cuál comparte con terceros, con qué finalidad, si es obligatoria u opcional, si viaja cifrada y cómo puede el usuario solicitar su eliminación. Esa declaración se convierte en una ficha pública visible antes de instalar, y es la traducción a producto de la idea de consentimiento informado.

La propiedad crítica de ese documento es que no es una manifestación de intenciones sino una afirmación comprobable. Google ejecuta análisis estáticos y dinámicos sobre el paquete publicado, observa el tráfico saliente y compara lo que ve con lo que declaraste. Una divergencia se trata como incumplimiento de política, con consecuencias que van desde el bloqueo de la actualización hasta la retirada de la ficha.

La fuente número uno de divergencias no es la mala fe sino la ignorancia sobre el propio binario. Una biblioteca de análisis, una de publicidad, un recolector de errores o un motor de recomendación recogen datos por su cuenta, y esa recogida es tuya a todos los efectos declarativos. Nadie preguntará si sabías lo que hacía la dependencia que integraste; el paquete lleva tu firma.

Conviene además tratar el manifiesto de datos como código: revisarlo en cada actualización de dependencias, no solo cuando cambia una funcionalidad propia, y anotar junto a cada dependencia qué categoría de datos aporta a la declaración. Una entrada olvidada tras una actualización de biblioteca es indistinguible, desde fuera, de una ocultación deliberada.

Dos casillas de ese formulario merecen atención especial porque casi nadie las lee con cuidado y ambas cambian por completo la lectura que hace el usuario de tu ficha. La primera es la que distingue entre datos obligatorios y opcionales: marcar como opcional algo que en realidad bloquea la funcionalidad si se rechaza es una declaración falsa, aunque el diálogo técnico sea el mismo. La segunda es la del tratamiento efímero, que solo se puede marcar si el dato se procesa en memoria y se descarta sin persistirse en ningún sistema, ni siquiera en un registro de servidor.

Privacy Sandbox: desmontar el identificador transversal

Durante quince años, la publicidad móvil se construyó sobre un identificador estable y común a todas las aplicaciones del dispositivo, que permitía reconstruir el comportamiento completo de una persona cruzando datos de decenas de proveedores. La plataforma lleva varias versiones desactivando esa capacidad por etapas.

La primera etapa fue restringir el propio identificador: el usuario puede borrarlo, en cuyo caso todas las lecturas devuelven ceros, y desde la API 33 hay que declarar un permiso específico para leerlo. Construir una funcionalidad sobre un valor que puede ser una cadena de ceros en una fracción notable de los dispositivos es, sencillamente, mala ingeniería.

La segunda etapa es Privacy Sandbox, un conjunto de interfaces que persiguen resolver los casos de uso legítimos de la publicidad sin identificadores compartidos. Su pieza estructural es el entorno de ejecución para bibliotecas, que traslada los SDK de terceros a un proceso separado con sus propios permisos y sin acceso a los datos de la aplicación anfitriona. Sobre esa base se apoyan las interfaces de temas de interés, de audiencias protegidas y de informe de atribución, todas ellas diseñadas para devolver agregados o señales de baja resolución en lugar de identidades.

flowchart TD
A[Modelo antiguo] --> B[Identificador comun a todas las aplicaciones]
B --> C[Perfil unico reconstruido por terceros]
D[Modelo nuevo] --> E[SDK en proceso aislado]
D --> F[Temas de interes agregados]
D --> G[Informe de atribucion con ruido]
E --> H[Sin acceso a datos de la aplicacion]
F --> I[Sin identidad transversal]
G --> I

Vale la pena entender el mecanismo de cada pieza, aunque los nombres cambien. La interfaz de temas deriva en el dispositivo un puñado de categorías de interés a partir del uso, las rota periódicamente y entrega solo unas pocas por consulta, de modo que ningún observador puede reconstruir un perfil estable. La de audiencias protegidas mantiene la pertenencia a grupos dentro del terminal y ejecuta la subasta localmente, sin que el anunciante llegue a saber quién estaba en el grupo. Y la de informes de atribución sustituye el seguimiento de conversiones individuales por agregados con ruido calibrado y un presupuesto de privacidad que limita cuántas consultas puede hacer cada participante.

Ese último detalle —el presupuesto— es el concepto más interesante de todo el conjunto y el que menos se comenta, porque introduce en una API comercial una idea procedente de la privacidad diferencial: la cantidad de información que se puede extraer de una población está acotada por diseño, y una vez agotada la cuota no hay manera de obtener más consultando de otra forma. Es un cambio de naturaleza respecto al modelo anterior, donde la única cota era la capacidad de almacenamiento de quien recogía.

La lectura estratégica importa más que los detalles de cada interfaz, que seguirán cambiando. La dirección es la sustitución sistemática del dato individual por el agregado, del identificador por la señal ruidosa, y del acceso directo por la mediación del sistema. Cualquier arquitectura de producto que dependa de reconocer a la misma persona a través de aplicaciones distintas está apostando contra esa dirección.

Superficies que no parecen datos

Hay información sensible que no atraviesa ningún permiso y que la plataforma ha ido cerrando con mecanismos propios. La más instructiva es la lista de aplicaciones instaladas, que durante años fue libremente consultable y que resultó ser uno de los vectores de perfilado más potentes que existían: la combinación de aplicaciones de una persona revela religión, orientación, situación económica, estado de salud y afiliación política con una precisión incómoda.

Desde la API 30, una aplicación solo ve los paquetes que declara necesitar, mediante el elemento queries del manifiesto, o los que responden a los tipos de interacción que declara. El permiso que devuelve la visibilidad completa está restringido en la tienda a casos concretos como los gestores de aplicaciones o los antivirus.

<queries>
    <package android:name="com.example.socio" />
    <intent>
        <action android:name="android.intent.action.SEND" />
        <data android:mimeType="image/*" />
    </intent>
</queries>

La restricción tiene un efecto secundario que sorprende a quien la encuentra por primera vez: si tu aplicación abre otra mediante una acción concreta y no la ha declarado, la comprobación previa de que existe un destinatario devolverá que no hay ninguno, aunque la aplicación esté instalada. El síntoma es un botón que informa de que no hay ninguna aplicación capaz de abrir el fichero en un dispositivo donde evidentemente la hay, y la causa está a diez líneas del manifiesto.

En la misma familia de superficies invisibles entran los identificadores de hardware no reiniciables, hoy inaccesibles sin privilegios de sistema, y la resolución de nombres de red o los tiempos de respuesta, que permiten inferencias laterales. La regla que ordena todo el conjunto es que cualquier señal estable y común a varias aplicaciones acabará siendo tratada como identificador, con independencia de que se diseñara para eso.

El propio sistema ofrece la herramienta para mirarse por dentro: la interfaz de auditoría de acceso a datos permite registrar una devolución de llamada que se dispara cada vez que algún componente del proceso accede a un dato protegido, indicando la etiqueta de atribución responsable. Es el único mecanismo práctico para descubrir qué hacen realmente tus dependencias.

Para que esa etiqueta signifique algo hay que declararla previamente en el manifiesto y asociarla a un contexto derivado desde el que se ejecuta cada subsistema. Sin ese trabajo previo, la auditoría te dirá que tu aplicación accedió a la ubicación, que es exactamente lo que ya sabías; con él, te dirá qué parte de tu aplicación lo hizo, que es lo que necesitas para responder a una pregunta de cumplimiento o para explicar una anomalía en el panel de privacidad del usuario.

<attribution
    android:tag="analitica"
    android:label="@string/atribucion_analitica" />
<attribution
    android:tag="mapa"
    android:label="@string/atribucion_mapa" />

val gestor = getSystemService(AppOpsManager::class.java)
gestor?.setOnOpNotedCallback(
    mainExecutor,
    object : AppOpsManager.OnOpNotedCallback() {
        override fun onNoted(op: SyncNotedAppOp) = registrar(op.op, op.attributionTag)
        override fun onSelfNoted(op: SyncNotedAppOp) = registrar(op.op, op.attributionTag)
        override fun onAsyncNoted(op: AsyncNotedAppOp) = registrar(op.op, op.attributionTag)
    },
)

Minimizar: la única técnica que no caduca

Todo lo anterior son mecanismos, y los mecanismos cambian con cada versión. Hay un principio que no cambia nunca y que subsume a todos: recoge la menor cantidad de datos, con la menor precisión, durante el menor tiempo que permita cumplir la función. Cada una de las tres dimensiones se puede recorrer por separado y las tres reducen simultáneamente la superficie regulatoria, el coste de infraestructura y el daño potencial de una brecha.

Reducir la cantidad significa cuestionar cada campo del evento que registras. Reducir la precisión significa preguntarse si necesitas la coordenada o basta el código postal, si necesitas la fecha de nacimiento o basta el intervalo de edad, si necesitas el identificador o basta un contador. Y reducir el tiempo significa fijar una caducidad explícita para cada tabla, porque el dato que se conserva por si acaso es exactamente el que aparece en la filtración.

Existe además una obligación que muchos equipos descubren tarde: Google Play exige que las aplicaciones con cuentas de usuario ofrezcan una vía de eliminación de la cuenta y de los datos asociados, accesible desde dentro de la aplicación y también desde la web para quien ya la desinstaló. Implementar el borrado real, con propagación a copias y a sistemas analíticos, es un trabajo de arquitectura que conviene planificar y no improvisar bajo la presión de una fecha de cumplimiento.

La prueba de fuego de una arquitectura minimizada es sorprendentemente sencilla de formular y muy incómoda de superar: si mañana tuvieras que borrar por completo a un usuario concreto, ¿sabrías enumerar todos los lugares donde vive alguno de sus datos? La mayoría de los sistemas no lo sabe, y esa ignorancia no es un problema de documentación sino el síntoma de que la recogida creció sin gobierno. Un equipo que puede responder esa pregunta en cinco minutos tiene, casi por construcción, un sistema con menos datos, menos copias y menos integraciones opacas.

El último eslabón, y el que más se descuida, es la comunicación. Una política de privacidad de nueve mil palabras redactada para protegerte de un litigio no informa a nadie y no cuenta como consentimiento informado en ningún marco serio. Lo que sí funciona es la explicación de una frase, situada exactamente donde ocurre la recogida, escrita en el idioma del usuario y no en el del departamento jurídico. Ese texto breve es, en la práctica, la interfaz real de tu política de datos, y la parte extensa es su apéndice.