Consentimiento en apps nativas: un único registro para web y móvil
Publicado el
Un usuario que rechaza el marketing en tu web y abre tu app no debería tener que contestar otra vez, ni mucho menos ser rastreado igualmente. Qué cambia cuando el consentimiento pasa del navegador a iOS y Android, y qué no.
La mayoría de las implantaciones de consentimiento se construyeron para el navegador: un banner, una cookie que guarda la elección y scripts que la esperan. Luego la empresa lanza una app y el consentimiento se rehace desde cero: un segundo juego de interruptores, un segundo sitio donde guardarlo, una segunda respuesta a «¿qué aceptó esta persona?». En pocas semanas las dos dejan de coincidir.
La solución no es un banner móvil mejor. Es un único registro por persona, escrito desde la superficie que esté usando en cada momento.
El mismo contrato, otro entorno
Los SDK de iOS, Android y Flutter replican el SDK de JavaScript método a método: getPurposes para el texto publicado exacto, recordConsent para escribir una decisión, getConsentState para leerla y gate() para retener un SDK —una librería de analítica o de atribución— hasta que se conceda el propósito correspondiente. Una decisión registrada en la app acaba en la misma bóveda, bajo el mismo sujeto, que una registrada en la web.
Qué cambia de verdad en una app
- No hay cabecera Origin. Las claves de navegador se protegen con una lista de dominios permitidos; una app no puede presentar ninguno. La clave
pk_de la app necesita Permitir apps nativas activado; si no, todas las llamadas devuelven 403. El ajuste es por clave, así que tu clave web conserva su comprobación de Origin. - La clave viaja dentro del binario. Cualquiera puede extraerla. Por eso en una app solo van claves
pk_—nuncask_— y por eso unapk_por sí sola solo llega a identificadores anónimos de dispositivo. - Los usuarios con sesión necesitan un token de identidad. Para leer o escribir el consentimiento de
email:…o de tu propio id de usuario, la app envía un token de corta duración que firma tu backend; así una clave extraída no sirve para consultar las elecciones de otra persona. Consulta identificar usuarios con sesión. - De anónimo a identificado es una fusión. Lo que se eligió en un dispositivo antes de iniciar sesión pasa a la cuenta; no se pregunta dos veces. Consulta de anónimo a identificado.
La prueba funciona sin conexión, en el propio dispositivo
Cada decisión vuelve con un recibo firmado con Ed25519. Los SDK nativos lo verifican en el dispositivo —CryptoKit en plataformas Apple, Google Tink en Android— con las claves públicas de /.well-known/jwks.json. La app puede enseñar a un usuario su propio historial de consentimiento y demostrar que cada entrada es auténtica sin fiarse del camino de red por el que llegó. Más en qué demuestra realmente un recibo de consentimiento firmado.
En qué punto está hoy
Los SDK móviles están en acceso anticipado: con el código completo y probado, a la espera de publicarse en SPM, Maven Central y pub.dev. Si preparas un lanzamiento de app que necesita consentimiento, escríbenos y te lo dejamos listo; mientras tanto, los mismos flujos están disponibles directamente en la API REST, que es lo que los SDK llaman por debajo.