Recomendaciones para identificadores únicos

En este documento se brinda orientación sobre cómo seleccionar los identificadores adecuados para tu app en función de tu caso práctico.

Para obtener un panorama general sobre los permisos de Android, consulta la Descripción general de permisos. Si quieres obtener las prácticas recomendadas específicas para trabajar con permisos de Android, consulta Prácticas recomendadas de permisos de la app.

Recomendaciones para trabajar con identificadores de Android

Cuando trabajes con identificadores de Android, sigue las recomendaciones que se muestran a continuación:

  1. Evita usar identificadores de hardware. En la mayoría de los casos prácticos, puedes evitar el uso de identificadores de hardware, como SSAID (ID de Android), sin limitar la funcionalidad requerida.

    Android 10 (API nivel 29) agrega restricciones para identificadores que no se pueden restablecer, incluido el IMEI y el número de serie. Tu app debe ser una app del propietario del perfil o del dispositivo, tener permisos especiales del proveedor o tener el permiso con privilegios de READ_PRIVILEGED_PHONE_STATE a fin de acceder a estos identificadores.

  2. Solo usa un ID de publicidad para casos prácticos de anuncios o generación de perfiles. Cuando uses un ID de publicidad, siempre respeta las selecciones de los usuarios respecto del seguimiento de anuncios. Además, asegúrate de que el identificador no pueda vincularse con información de identificación personal (PII) y no vincules los ID de publicidad que se restablecieron.

  3. Usa un ID de instancia o un GUID almacenado de forma privada cuando sea posible para todos los demás casos prácticos, salvo para la prevención de pagos fraudulentos y la telefonía. Para la mayoría de los casos prácticos que no incluyan anuncios, bastará con un ID de instancia o un GUID.

  4. Usa las API que sean apropiadas para tu caso práctico a fin de minimizar los riesgos de privacidad. Usa la API de DRM para proteger contenido valioso y las API de SafetyNet para protegerte contra abusos. Las API de SafetyNet son la forma más fácil de determinar si un dispositivo es genuino sin incurrir en riesgos de privacidad.

En las secciones restantes de la guía, se abordan estas reglas en mayor profundidad en el contexto del desarrollo de apps para Android.

Cómo trabajar con los ID de publicidad

El ID de publicidad es un identificador que el usuario puede restablecer y es adecuado para los casos prácticos de anuncios. Sin embargo, hay algunas consideraciones importantes para tener en cuenta cuando uses este ID:

Respeta siempre la intención del usuario que restablece un ID de publicidad. No vincules un identificador restablecido con otro identificador o huella digital que permita vincular los ID de publicidad posteriores sin el consentimiento del usuario. La Política de contenido para desarrolladores de Google Play establece lo siguiente:

"… ante un restablecimiento, no se debe vincular un nuevo identificador de publicidad a uno anterior ni a datos derivados de un identificador de publicidad previo sin el consentimiento explícito del usuario".

Respeta siempre el indicador de anuncios personalizados asociado. Los ID de publicidad son configurables en el sentido de que los usuarios pueden limitar la cantidad de seguimiento asociada con el ID. Usa siempre el método AdvertisingIdClient.Info.isLimitAdTrackingEnabled() para asegurarte de no incumplir los deseos de los usuarios. La Política de contenido para desarrolladores de Google Play establece lo siguiente:

"… se debe respetar lo que haya seleccionado el usuario en las opciones 'Inhabilitar publicidad basada en intereses' o 'Cancelar Personalización de anuncios'. Si un usuario habilitó estas opciones, no podrás usar el identificador de publicidad para crear perfiles de usuario con fines publicitarios ni para identificar usuarios mediante publicidad personalizada. Las actividades permitidas incluyen la publicidad contextual, la limitación de frecuencia, el seguimiento de conversiones, los informes y la seguridad, y la detección de fraudes".

Ten en cuenta todas las políticas de privacidad o seguridad asociadas con los SDK que uses y que estén relacionadas con el uso de ID de publicidad. Por ejemplo, si pasas true en el método enableAdvertisingIdCollection() desde el SDK de Google Analytics, asegúrate de revisar todas las políticas del SDK de Analytics correspondientes y de cumplir con ellas.

Además, ten en cuenta que la Política de contenido para desarrolladores de Google Play establece que el ID de publicidad "no puede vincularse a información de identificación personal ni asociarse con ningún identificador de dispositivo persistente (por ejemplo, SSAID, dirección MAC, IMEI, etc.)".

A modo de ejemplo, supongamos que deseas recopilar información para completar tablas de una base de datos con las siguientes columnas:

TABLA-01
timestamp ad_id account_id clickid
TABLA-02
account_id name dob country

En este ejemplo, la columna ad_id podría vincularse a PII por medio de la columna account_id en ambas tablas, lo que supondría el incumplimiento de la Política de Contenido para Desarrolladores de Google Play si no obtuviste el permiso expreso de tus usuarios.

Recuerda que los vínculos entre el ID de publicidad y la PII no siempre son tan explícitos. Es posible que haya "cuasi identificadores" que aparecen tanto en las tablas de PII como en las de ID de publicidad protegidos con claves, lo cual causa problemas. Por ejemplo, supongamos que cambiamos la TABLA-01 y la TABLA-02 de la siguiente manera:

TABLA-01
timestamp ad_id clickid dev_model
TABLA-02
timestamp demo account_id dev_model name

En este caso, con eventos de clic lo suficientemente infrecuentes, aún es posible establecer un vínculo entre la TABLA-01 del ID de publicidad y la PII de la TABLA-02 por medio de la marca de tiempo del evento y el modelo del dispositivo.

Si bien, a veces, es difícil garantizar que no existan tales cuasi identificadores en un conjunto de datos, puedes evitar los riesgos de vinculación más evidentes si generalizas los datos únicos siempre que sea posible. En el ejemplo anterior, esta acción implicaría reducir la precisión de la marca de tiempo de modo que aparezcan varios dispositivos del mismo modelo para cada marca de tiempo.

A continuación, se muestran soluciones alternativas:

  • No diseñes tablas que vinculen explícitamente la PII con los ID de publicidad. En el primer ejemplo que se muestra más arriba, esta acción significaría no incluir la columna account_id en la TABLA-01.

  • Separa y supervisa las listas de control de acceso para usuarios o funciones con acceso a la PII y al ID de publicidad protegido con clave. Al realizar auditorías y controlar estrictamente el acceso a ambas fuentes de manera simultánea (por ejemplo, uniendo las tablas), puedes reducir el riesgo de asociación entre el ID de publicidad y la PII. Básicamente, controlar el acceso implica lo siguiente:

    1. Mantener listas de control de acceso (ACL) para la desvinculación de los datos del ID de publicidad protegidos con claves y la PII, a fin de minimizar la cantidad de personas o funciones que se repitan en ambas ACL.
    2. Implementar registros y auditorías de acceso para detectar y administrar las excepciones a esta regla.

Para obtener más información sobre cómo trabajar de manera responsable con los ID de publicidad, consulta la referencia de la API de AdvertisingIdClient.

Cómo trabajar con los ID de instancia y GUID

La solución más sencilla para identificar una instancia de app que se ejecuta en un dispositivo es usar un ID de instancia, y esta es la solución recomendada en la mayoría de los casos prácticos que no incluyen anuncios. Solo la instancia de app para la cual se proporcionó puede acceder a este identificador, y es (relativamente) fácil de restablecer, ya que solo persiste mientras la app esté instalada.

En consecuencia, los ID de instancia ofrecen mejores propiedades de privacidad en comparación con los ID de hardware específicos del ámbito del dispositivo, que no se pueden restablecer. Para obtener más información, consulta la referencia de la API de FirebaseInstanceId.

En los casos en que un ID de instancia no resulta práctico, puedes usar los ID únicos globales (GUID) personalizados para identificar de forma exclusiva una instancia de app. La forma más sencilla de hacerlo es generar tu propio GUID con el siguiente código:

Kotlin

    var uniqueID = UUID.randomUUID().toString()

Java

    String uniqueID = UUID.randomUUID().toString();

Como el identificador es único a nivel global, puede usarse para identificar una instancia de app específica. Para evitar los problemas derivados de vincular el identificador entre apps, guarda los GUID en el almacenamiento interno, en lugar del externo (compartido). Para obtener más información, consulta la página Descripción general del almacenamiento de datos y archivos.

No trabajes con direcciones MAC

Las direcciones MAC son únicas a nivel mundial, se conservan tras el restablecimiento de la configuración de fábrica y no permiten que el usuario las restablezca. Por estos motivos, generalmente no se recomienda usar direcciones MAC para ninguna forma de identificación. Los dispositivos que ejecutan Android 10 (API nivel 29) y versiones posteriores, informan direcciones MAC aleatorias a todas las apps que no son apps del propietario del dispositivo.

Entre las versiones Android 6.0 (API nivel 23) y Android 9 (API nivel 28), las direcciones MAC en dispositivos locales, como Wi-Fi y Bluetooth, no están disponibles por medio de API de terceros. Los métodos WifiInfo.getMacAddress() y BluetoothAdapter.getDefaultAdapter().getAddress() mostrarán 02:00:00:00:00:00.

Asimismo, entre las versiones Android 6.0 y Android 9, debes tener los siguientes permisos para acceder a direcciones MAC de dispositivos externos cercanos y disponibles por medio de búsqueda de Bluetooth y Wi-Fi:

Método/propiedad Permisos necesarios
WifiManager.getScanResults() ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION
BluetoothDevice.ACTION_FOUND ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION
BluetoothLeScanner.startScan(ScanCallback) ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION

Características de los identificadores

El SO Android ofrece varios ID con diferentes características de comportamiento. El ID que debes usar dependerá del funcionamiento de las siguientes características con tu caso práctico. Sin embargo, estas características tienen consecuencias en la privacidad, por lo tanto es importante que comprendas cómo interactúan entre ellas.

Ámbito

El ámbito del identificador explica los sistemas que pueden acceder al identificador. Por lo general, el ámbito de los identificadores de Android tiene tres variantes:

  • Una sola app: El ID reside en la app, y otras apps no pueden acceder a él.
  • Grupo de apps: Un grupo predefinido de apps relacionadas puede acceder al ID.
  • Dispositivo: Todas las apps instaladas en el dispositivo pueden acceder al ID.

Cuanto más amplio sea el ámbito otorgado a un identificador, mayor será el riesgo de que se use con propósitos de seguimiento. Por el contrario, si una sola instancia de app puede acceder al identificador, este no se podrá usar para realizar un seguimiento del dispositivo en transacciones de diferentes apps.

Capacidad de restablecimiento y persistencia

La capacidad de restablecimiento y la persistencia definen la vida útil del identificador y explican cómo se puede restablecer este. Los activadores de restablecimiento más comunes ocurren cuando se restablece dentro de la app, a través de configuraciones del sistema, durante el inicio y la instalación. La vida útil de los identificadores de Android puede variar, pero generalmente está relacionada con la forma en que se restablece el ID:

  • Solo por sesión: Se usa un ID nuevo cada vez que se reinicia la app.
  • Restablecimiento en instalación: Se usa un ID nuevo cada vez que el usuario desinstala y reinstala la app.
  • Restablecimiento de la configuración de fábrica: Se usa un ID nuevo cada vez que el usuario restablece la configuración de fábrica del dispositivo.
  • Conservación tras restablecimiento de la configuración de fábrica: El ID se mantiene después de restablecer la configuración de fábrica.

La capacidad de restablecimiento permite a los usuarios crear un nuevo ID que no esté relacionado con información del perfil existente. Cuanto mayores sean el tiempo y el grado de confiabilidad en términos de permanencia de un identificador (p. ej., luego de restablecer varias veces la configuración de fábrica), mayor será el riesgo de que el usuario pueda estar sujeto a un seguimiento a largo plazo. Si se restablece el identificador después de la reinstalación de la app, se reduce la persistencia y se proporciona un método para restablecer el ID, aunque el usuario no controle el restablecimiento de forma explícita desde la app o la configuración del sistema.

Exclusividad

La exclusividad establece la probabilidad de colisión, es decir, de que existan dos identificadores idénticos en el ámbito asociado. En el nivel más alto, un identificador único global nunca experimentará una colisión, ni siquiera en otros dispositivos o apps. En los demás casos, el nivel de exclusividad depende de la entropía del identificador y de la fuente de aleatoriedad usada para crearlo. Por ejemplo, las probabilidades de que se produzca una colisión son mucho más altas para identificadores aleatorios propagados con la fecha de instalación (p. ej., 2019-03-01) que para los identificadores propagados con la marca de tiempo de instalación de Unix (p. ej., 1551414181).

En general, los identificadores de cuenta de usuario se pueden considerar únicos. Es decir, cada combinación de dispositivo y cuenta tiene un ID único. Por otro lado, cuanto menos exclusivo sea un identificador en una población, mayor será la protección de la privacidad, ya que es menos útil para el seguimiento de un usuario individual.

Protección de la integridad y carácter no repudiable

Puedes usar un identificador que sea difícil de falsificar o reproducir para probar que la cuenta o el dispositivo asociado tienen ciertas propiedades. Por ejemplo, puedes probar que el dispositivo no es un dispositivo virtual manipulado por un generador de spam. Los identificadores difíciles de falsificar también conllevan un carácter no repudiable. Si el dispositivo firma un mensaje con una clave secreta, es difícil aseverar que fue otra persona quién lo envió. El carácter no repudiable podría resultar atractivo para un usuario (por ejemplo, para la autenticación de un pago) o podría ser una característica no deseada (como en el caso de que un usuario envíe un mensaje y, luego, se arrepienta).

Casos prácticos y el identificador adecuado que debe usarse

En esta sección, se proporcionan alternativas para evitar el uso de los ID de hardware, como el IMEI. No se recomienda usarlos, ya que el usuario no puede restablecerlos y su ámbito es limitado. En muchos casos, un identificador que funcione en el ámbito de la app sería suficiente.

Seguimiento de las preferencias de usuarios que salieron de la cuenta

En este caso, se guarda el estado de cada dispositivo en el servidor sin una cuenta de usuario.

Usa: GUID o ID de instancia

¿Por qué se brinda esta recomendación?

No se recomienda conservar la información luego de cada reinstalación porque es posible que los usuarios quieran restablecer sus preferencias al reinstalar la app.

Seguimiento de las preferencias de usuarios que salieron de la cuenta entre apps con la misma clave de acceso

En este caso, se guarda el estado de cada dispositivo en el servidor y se transfiere entre diferentes apps a las que se accedió con la misma clave en el mismo dispositivo.

Usa: SSAID

¿Por qué se brinda esta recomendación?

En Android 8.0 (con nivel de API 26) y versiones posteriores, SSAID proporciona un identificador que es común entre apps a las que se accedió con la misma clave de acceso de desarrollador. De esta manera, se puede compartir el estado entre esas app sin que el usuario deba acceder a una cuenta.

Seguimiento del comportamiento de usuarios que salieron de la cuenta

En este caso, se creó un perfil de un usuario basado en su comportamiento en diferentes apps o sesiones en el mismo dispositivo.

Usa: ID de publicidad

¿Por qué se brinda esta recomendación?

El uso del ID de publicidad es obligatorio para los casos prácticos de publicidad según la Política de contenido para desarrolladores de Google Play porque el usuario puede restablecerlo.

Generación de estadísticas de usuarios anónimos o que salieron de la cuenta

En este caso, se miden las estadísticas de uso de los usuarios anónimos o que salieron de la cuenta.

Usa: ID de instancia o un GUID, en caso de que un ID de instancia no sea suficiente

¿Por qué se brinda esta recomendación?

Un ID de instancia o un GUID se limita al ámbito de la app que lo crea, lo cual evita que se use para el seguimiento de usuarios en las apps. Puede restablecerse fácilmente cuando el usuario borra los datos de la app o la reinstala. El proceso de creación de ID de instancia y GUID es sencillo:

  • Creación de un ID de instancia: Consulta la guía de Firebase Cloud Messaging.

  • Creación de un GUID: Implementa la lógica en tu app, como se muestra en el siguiente fragmento de código:

    Kotlin

        val uniqueID: String = UUID.randomUUID().toString()

    Java

        String uniqueID = UUID.randomUUID().toString();

Ten en cuenta que, si indicas al usuario que los datos que recopilas son anónimos, debes asegurarte de no vincular el identificador con PII ni con otros identificadores que puedan estar vinculados con PII.

También puedes usar Google Analytics para apps para dispositivos móviles, que ofrece una solución para estadísticas por app.

Seguimiento de conversiones de usuarios que salieron de la cuenta

En este caso, se realiza un seguimiento de las conversiones para detectar si tu estrategia de marketing funciona correctamente.

Usa: ID de publicidad

¿Por qué se brinda esta recomendación?

Este es un caso práctico relacionado con anuncios que puede requerir un ID disponible en diferentes apps. Por lo tanto, usar un ID de publicidad es la solución más adecuada.

Manejo de varias instalaciones en diferentes dispositivos

En este caso, debes identificar la instancia correcta de la app cuando se instala en varios dispositivos para el mismo usuario.

Usa: GUID o ID de instancia

¿Por qué se brinda esta recomendación?

El ID de instancia se diseñó explícitamente para este fin; su ámbito se limita a la app, por lo que no se puede usar para realizar un seguimiento de usuarios en diferentes apps y se restablece con la reinstalación. En los casos poco comunes en los cuales un ID de instancia no sea suficiente, también puedes usar un GUID.

Acciones para prevenir el fraude: aplicación de límites de contenido gratuito y detección de ataques de Sybil

En este caso, quieres limitar la cantidad de contenido gratuito, como los artículos que un usuario puede ver en un dispositivo.

Usa: ID de instancia o GUID. En Android 8.0 (con nivel de API 26) y versiones posteriores, también se puede usar SSAID, ya que se incluye en el ámbito de la clave de firma de la app.

¿Por qué se brinda esta recomendación?

Al usar un GUID o un ID de instancia, se obliga al usuario a reinstalar la app para eludir los límites de contenido, lo que normalmente desalienta a la mayoría de las personas. Si crees que esta protección no alcanza, Android proporciona una API de DRM, que se puede usar para limitar el acceso a contenido mediante un identificador para cada APK, el ID de Widevine.

Funcionalidad de proveedor

En este caso, tu app interactúa con la funcionalidad de teléfono y mensajería del dispositivo mediante una cuenta de proveedor.

Usa: IMEI, IMSI y Line1

¿Por qué se brinda esta recomendación?

El uso de identificadores de hardware es aceptable si se requieren para la funcionalidad de telefonía y proveedores. Por ejemplo, puedes usarlos para cambiar de proveedor de servicios móviles o de ranura de SIM, o para entregar mensajes SMS por IP (para Line1) a cuentas de usuario basadas en SIM. En el caso de las apps que no tienen privilegios, se recomienda implementar el acceso con una cuenta para recuperar información en el servidor. Uno de los motivos es que, en Android 6.0 (con nivel de API 23) y versiones posteriores, estos identificadores solo se puede usar con un permiso de tiempo de ejecución. Los usuarios pueden desactivar este permiso, de manera que tu app debe manejar estas excepciones adecuadamente.

Detección de abuso: cómo identificar ataques de bots y DSD

En este caso, se intentan detectar varios dispositivos falsos que atacan tus servicios de backend.

Usa: La API de SafetyNet

¿Por qué se brinda esta recomendación?

Un identificador aislado no logra indicar con precisión que un dispositivo es genuino. Puedes verificar si una solicitud proviene de un dispositivo Android genuino (en lugar de un emulador, o bien otro dispositivo de falsificación de identidad) por medio del método attest() de la API de SafetyNet para verificar la integridad del dispositivo que realiza la solicitud. Para obtener más información, consulta la documentación sobre la API de SafetyNet.

Detección de fraude y abuso: cómo detectar credenciales valiosas robadas

En este caso, se intenta detectar si un solo dispositivo se usa varias veces con credenciales valiosas robadas, por ejemplo, con el fin de realizar pagos fraudulentos.

Usa: Por naturaleza, la prevención de fraudes requiere marcas de propiedad que pueden cambiar a lo largo del tiempo y, por lo tanto, no se abordan en este documento. Sin embargo, ten en cuenta que los identificadores de hardware, como IMEI o IMSI, pueden modificarse fácilmente en dispositivos emulados o con derechos de administrador, por lo que no son indicadores de fraude confiables.