Mejores prácticas para los identificadores únicos

Este documento proporciona una guía para seleccionar los identificadores apropiados para su aplicación en función de su caso de uso.

Para una visión general de los permisos de Android, consulte Permissionsoverview. Para conocer las mejores prácticas específicas para trabajar con los permisos de Android, consulte App permissions bestpractices.

Mejores prácticas para trabajar con identificadores de Android

Cuando trabaje con identificadores de Android, siga estas mejores prácticas:

1. Evite utilizar identificadores de hardware. En la mayoría de los casos de uso, puede evitar el uso de identificadores de hardware, como SSAID (Android ID), sin limitar la funcionalidad requerida.

   Android 10 (nivel de API 29) añade restricciones para los identificadores no restaurables, que incluyen tanto el IMEI como el número de serie. Tu aplicación debe ser propietaria de un dispositivo o de un perfil, tener permisos especiales del operador o tener el permiso privilegiado READ_PRIVILEGED_PHONE_STATE para poder acceder a estos identificadores.

2. Utiliza un ID de publicidad solo para casos de uso de perfiles de usuario o de anuncios. Cuando utilices un identificador de publicidad, respeta siempre las selecciones de los usuarios con respecto al seguimiento de anuncios. Además, asegúrese de que el identificador no pueda conectarse a información personal identificable (PII) y evite los restablecimientos de ID de publicidad de puente.

3. Utilice un ID de instalación de Firebase (FID) o un GUID almacenado de forma privada siempre que sea posible para todos los demás casos de uso, excepto para la prevención de fraudes de pago y la telefonía. Para la gran mayoría de los casos de uso no publicitarios, un FID o GUID debería ser suficiente.

4. Utilice las APIs que sean apropiadas para su caso de uso para minimizar el riesgo de privacidad. Utilice la API de DRM para la protección de contenidos de alto valor y las API de SafetyNet para la protección contra el abuso. Las APIs de SafetyNet son la forma más fácil de determinar si un dispositivo es genuino sin incurrir en riesgo de privacidad.

Las secciones restantes de esta guía desarrollan estas reglas en el contexto del desarrollo de aplicaciones Android.

Trabaja con IDs de publicidad

El ID de publicidad es un identificador reajustable por el usuario y es apropiado para casos de uso de publicidad. Sin embargo, hay algunos puntos clave que debes tener en cuenta cuando utilices este ID:

Respeta siempre la intención del usuario al restablecer el ID de publicidad.No puentees los restablecimientos del usuario utilizando otro identificador o huella dactilar para vincular IDs de publicidad posteriores sin el consentimiento del usuario. La política de contenido para desarrolladores de Google Play establece lo siguiente:

«…si se restablece, un nuevo identificador de publicidad no debe conectarse a un identificador de publicidad anterior o a datos derivados de un identificador de publicidad anterior sin el consentimiento explícito del usuario».

Respeta siempre el indicador de anuncios personalizados asociado. Los identificadores publicitarios sonconfigurables en el sentido de que los usuarios pueden limitar la cantidad de seguimiento asociada alID. Utilice siempre el método AdvertisingIdClient.Info.isLimitAdTrackingEnabled() para asegurarse de que no está eludiendo los deseos de sus usuarios. La política de contenido para desarrolladores de GooglePlay establece lo siguiente:

«…debes respetar la configuración de «Exclusión de la publicidad basada en intereses» o «Exclusión de la personalización de anuncios» del usuario. Si un usuario ha habilitado esta configuración, no podrá utilizar el identificador de publicidad para crear perfiles de usuario con fines publicitarios o para dirigirse a los usuarios con publicidad personalizada.Las actividades permitidas incluyen la publicidad contextual, la limitación de la frecuencia, el seguimiento de la conversión, la elaboración de informes y la seguridad y la detección de fraudes.»

Tenga en cuenta las políticas de privacidad o seguridad asociadas a los SDK que utilice y que estén relacionadas con el uso del identificador de publicidad.Por ejemplo, si pasas true al métodoenableAdvertisingIdCollection() desde el SDK de Google Analytics, asegúrate de revisar y cumplir todas las políticas aplicables del SDK de Analytics.

Además, ten en cuenta que la política de contenido para desarrolladores de Google Play requiere que el ID de publicidad «no se conecte con información de identificación personal ni se asocie con ningún identificador de dispositivo persistente (por ejemplo: SSAID, dirección MAC, IMEI, etc.,).»

Como ejemplo, suponga que desea recopilar información para rellenar tablas de base de datos con las siguientes columnas:

En este ejemplo, la columna ad_id podría unirse a PII a través de la columna account_id en ambas tablas, lo que supondría una violación de la política de contenidos de Google Play para desarrolladores, si no obtienes el permiso explícito de tus usuarios.

Tenga en cuenta que los vínculos entre el ID del anunciante y la PII no siempre son así de explícitos. Es posible tener «cuasi-identificadores» que aparezcan tanto en la PII como en las tablas con clave de ID de anunciante, lo que también causa problemas. Por ejemplo, supongamos que cambiamosTABLE-01 y TABLE-02 de la siguiente manera

En este caso, con eventos de clic suficientemente raros, todavía es posible unir el ID del anunciante de la TABLA-01 y la PII contenida en la TABLA-02 utilizando la fecha del evento y el modelo del dispositivo.

Aunque a menudo es difícil garantizar que no existan tales cuasi-identificadores en un conjunto de datos, se pueden evitar los riesgos de unión más obvios generalizando los datos únicos siempre que sea posible. En el ejemplo anterior, esto significaría reducir la precisión de la marca de tiempo para que aparezcan múltiples dispositivos con el mismo modelo para cada marca de tiempo.

Otras soluciones incluyen las siguientes:

• No diseñar tablas que vinculen explícitamente la IIP con los identificadores de publicidad. En el primer ejemplo anterior, esto significaría no incluir la columna account_id en TABLE-01.

• Segregar y supervisar las listas de control de acceso para los usuarios o roles que tienen acceso tanto a los datos clave del ID de publicidad como a la IIP.Al controlar y auditar estrictamente la capacidad de acceder a ambas fuentes simultáneamente (por ejemplo, realizando una unión entre tablas), se reduce el riesgo de asociación entre el ID de publicidad y la IIP. En general, controlar el acceso significa hacer lo siguiente:

  1. Mantener las listas de control de acceso (ACL) para los datos clave del ID del anunciante y la IIP desunidas para minimizar el número de individuos o funciones que están en ambas ACL.
  2. Implementar el registro de acceso y la auditoría para detectar y gestionar cualquier excepción a esta regla.

Para obtener más información sobre cómo trabajar de forma responsable con los ID de publicidad, consulte la referencia de la APIAdvertisingIdClient.

Trabajar con FIDs y GUIDs

La solución más directa para identificar una instancia de aplicación que se ejecuta en un dispositivo es utilizar un ID de instalación de Firebase (FID), y esta es la solución recomendada en la mayoría de los casos de uso que no son de publicidad. Sólo la instancia de la aplicación para la que se aprovisionó puede acceder a este identificador, y es (relativamente) fácil de restablecer porque sólo persiste mientras la aplicación está instalada.

Como resultado, los FID proporcionan mejores propiedades de privacidad en comparación con los ID de hardware no restaurables y con alcance de dispositivo. Para obtener más información, consulte la referencia de la API.

En los casos en que un FID no es práctico, también puede utilizar IDs personalizados y únicos a nivel mundial (GUIDs) para identificar de forma única una instancia de la aplicación. La forma más sencilla de hacerlo es generando tu propio GUID utilizando el siguiente código:

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

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

Como el identificador es globalmente único, puede utilizarse para identificar una instancia específica de la app. Para evitar problemas relacionados con la vinculación del identificador entre aplicaciones, almacene los GUIDs en el almacenamiento interno en lugar del almacenamiento externo (compartido). Para obtener más información, consulte la página de visión general de almacenamiento de datos y archivos.

No trabajar con direcciones MAC

Las direcciones MAC son globalmente únicas, no son reajustables por el usuario y sobreviven a los reinicios de fábrica. Por estas razones, para proteger la privacidad del usuario, en las versiones de Android 6 y superiores, el acceso a las direcciones MAC está restringido a las aplicaciones del sistema. Las aplicaciones de terceros no pueden acceder a ellas.

La disponibilidad de las direcciones MAC cambia en Android 11

En las aplicaciones orientadas a Android 11 y superiores, la aleatorización de la MAC para las redes Passpoint es por perfil Passpoint, generando una dirección MAC única basada en los siguientes campos:

• Nombre de dominio totalmente calificado (FQDN)
• Realización
• Credencial, basada en la credencial utilizada en el perfil Passpoint:
  • Credencial de usuario: nombre de usuario
  • Credencial de certificado: cert y tipo de cert
  • Credencial SIM: EAP type and IMSI

Además, las aplicaciones sin privilegios no pueden acceder a la dirección MAC del dispositivo; sólo son visibles las interfaces de red con una dirección IP. Esto afecta a los métodosgetifaddrs()yNetworkInterface.getHardwareAddress(), así como al envío de mensajes RTM_GETLINK Netlink.

La siguiente es una lista de las formas en que las apps se ven afectadas por este cambio:

• NetworkInterface.getHardwareAddress() devuelve null para cada interfaz.
• Las apps no pueden utilizar la función bind() en NETLINK_ROUTE sockets.
• El comando ip no devuelve información sobre las interfaces.
• Las aplicaciones no pueden enviar mensajes RTM_GETLINK.

Tenga en cuenta que la mayoría de los desarrolladores deberían utilizar las APIs de nivel superior deConnectivityManager en lugar de las APIs de nivel inferior comoNetworkInterface,getifaddrs(), o los sockets Netlink. Por ejemplo, una aplicación que necesita información actualizada sobre las rutas actuales puede obtener esta información escuchando los cambios en la red utilizando ConnectivityManager.registerNetworkCallback()y llamando a la red asociadaLinkProperties.getRoutes().

Características de los identificadores

El sistema operativo Android ofrece una serie de identificadores con diferentes características de comportamiento. Estas características también vienen con implicaciones de privacidad, sin embargo, por lo que es importante entender cómo estas características interactúan entre sí.

Alcance

El alcance del identificador explica qué sistemas pueden acceder al identificador. El ámbito de Androididentifier generalmente viene en tres sabores:

• Aplicación única: El identificador es interno a la app y no es accesible a otras apps.
• Grupo de apps: El identificador es accesible a un grupo predefinido de apps relacionadas.
• Dispositivo: El identificador es accesible a todas las apps instaladas en el dispositivo.

Cuanto más amplio sea el alcance concedido a un identificador, mayor será el riesgo de que se utilice con fines de seguimiento. Por el contrario, si sólo se puede acceder a un identificador a través de una única instancia de la aplicación, no se puede utilizar para rastrear un dispositivo a través de transacciones en diferentes aplicaciones.

Restablecimiento y persistencia

El restablecimiento y la persistencia definen la vida útil del identificador y explican cómo se puede restablecer. Los desencadenantes más comunes de los reinicios son: los reinicios dentro de la aplicación, los reinicios a través de los Ajustes del Sistema, los reinicios en el lanzamiento y los reinicios en la instalación. Los identificadores de Android pueden tener diferentes duraciones, pero la duración suele estar relacionada con la forma en que se restablece el identificador:

• Sólo sesión: Se utiliza un nuevo ID cada vez que el usuario reinicia la aplicación.
• Install-reset: Se utiliza un nuevo ID cada vez que el usuario desinstala y reinstala la aplicación.
• FDR-reset: Se utiliza un nuevo ID cada vez que el usuario restablece el dispositivo de fábrica.
• FDR-persistente: El ID sobrevive al restablecimiento de fábrica.

La capacidad de restablecimiento ofrece a los usuarios la posibilidad de crear un nuevo ID que se desvincula de cualquier información de perfil existente. Cuanto más tiempo y de forma más fiable persista un identificador, como uno que persiste a través de los restablecimientos de fábrica, mayor es el riesgo de que el usuario pueda ser objeto de seguimiento a largo plazo. Si el identificador se restablece al reinstalar la aplicación, se reduce la persistencia y se proporciona un medio para restablecer el identificador, incluso si no hay un control explícito del usuario para restablecerlo desde la aplicación o la configuración del sistema.

Unicidad

La unicidad establece la probabilidad de colisiones; es decir, que existan identificadores idénticos dentro del ámbito asociado. En el nivel más alto, un identificador globalmente único nunca tiene una colisión, incluso en otros dispositivos o aplicaciones.De lo contrario, el nivel de singularidad depende de la entropía del identificador y de la fuente de aleatoriedad utilizada para crearlo. Por ejemplo, la probabilidad de una colisión es mucho mayor para los identificadores aleatorios sembrados con la fecha de calendario de la instalación (como 2019-03-01) que para los identificadores sembrados con la Unixtimestamp de la instalación (como 1551414181).

En general, los identificadores de cuentas de usuario pueden considerarse únicos. Es decir, cada combinación dispositivo/cuenta tiene un identificador único. Por otra parte, cuanto menos único sea un identificador dentro de 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 no repudiabilidad

Se puede utilizar un identificador que sea difícil de falsificar o reproducir para demostrar que el dispositivo o la cuenta asociada tiene ciertas propiedades. Por ejemplo, puedes demostrar que el dispositivo no es un dispositivo virtual utilizado por un spammer. Si el dispositivo firma un mensaje con una clave secreta, es difícil afirmar que el mensaje lo ha enviado otro dispositivo. La no repudiabilidad podría ser algo que un usuario desea, como cuando autentifica un pago, o podría ser una propiedad no deseada, como cuando envía un mensaje del que se arrepiente.

Casos de uso comunes y el identificador apropiado a utilizar

Esta sección proporciona alternativas al uso de identificadores de hardware, como el IMEI. Se desaconseja el uso de identificadores de hardware porque el usuario no puede restablecerlos, y están restringidos al dispositivo. En muchos casos, un identificador de la aplicación sería suficiente.

Rastrear las preferencias del usuario que ha firmado

En este caso, estás guardando el estado por dispositivo en el lado del servidor sin una cuenta de usuario.

Uso: FID o GUID

¿Por qué esta recomendación?

No se recomienda conservar la información a través de las reinstalaciones porque los usuarios pueden querer restablecer sus preferencias al reinstalar la aplicación.

Rastrea las preferencias de los usuarios firmados entre aplicaciones con la misma clave de firma

En este caso, estás guardando el estado por dispositivo en el lado del servidor y transfiriéndolo entre diferentes aplicaciones que están firmadas con la misma clave en el mismo dispositivo.

Uso: SSAID

¿Por qué esta recomendación?

En Android 8.0 (nivel de API 26) y superior, SSAID proporciona un identificador que es común entre las aplicaciones firmadas por la misma clave de firma del desarrollador. Permite compartir el estado entre estas aplicaciones sin necesidad de que el usuario se registre en una cuenta.

Rastrea el comportamiento de los usuarios que han firmado

En este caso, has creado un perfil de un usuario basado en su comportamiento en diferentes aplicaciones/sesiones en el mismo dispositivo.

Uso: ID de publicidad

¿Por qué esta recomendación?

El uso del ID de publicidad es obligatorio para los casos de uso publicitario según la GooglePlay Developer ContentPolicy porque el usuario puede restablecerlo.

Generar análisis de usuarios desconectados o anónimos

En este caso, estás midiendo las estadísticas de uso y los análisis de usuarios desconectados o anónimos.

Uso: FID, o un GUID si un FID es insuficiente

¿Por qué esta recomendación?

Un FID o un GUID se circunscribe a la aplicación que lo crea, lo que impide que el identificador se utilice para rastrear a los usuarios entre aplicaciones. También es fácilmente reajustable, ya que el usuario puede borrar los datos de la aplicación o reinstalarla. El proceso de creación de FIDs y GUIDs es sencillo:

• Recuperación de un FID: Ver la guía de instalaciones de Firebase.

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

  Kotlin

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

  Java

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

Tenga en cuenta que si le ha dicho al usuario que los datos que está recopilando sonanónimos, debe asegurarse de que no está conectando el identificador aPII u otros identificadores que podrían estar vinculados a PII.

También puedes utilizar Google Analytics for MobileApps, que ofrece una solución para la analítica por aplicación.

Rastrear las conversiones de los usuarios registrados

En este caso, estás rastreando las conversiones para detectar si tu estrategia de marketing tiene éxito.

Uso: Advertising ID

¿Por qué esta recomendación?

Este es un caso de uso relacionado con la publicidad que podría requerir un ID que esté disponible en diferentes aplicaciones, por lo que el uso de un ID de publicidad es la solución más apropiada.

Manejar múltiples instalaciones en diferentes dispositivos

En este caso, necesitas identificar la instancia correcta de la aplicación cuando se instala en múltiples dispositivos para el mismo usuario.

Uso: FID o GUID

¿Por qué esta recomendación?

Un FID está diseñado explícitamente para este propósito; su alcance se limita a la aplicación para que no pueda ser utilizado para rastrear a los usuarios a través de diferentes aplicaciones, y se restablece al reinstalar la aplicación. En los raros casos en los que un FID es insuficiente, también puede utilizar un GUID.

Asociar la funcionalidad con las suscripciones de servicios móviles

En este caso, necesita asociar la funcionalidad de la aplicación con ciertas suscripciones de servicios móviles en el dispositivo. Por ejemplo, puede tener un requisito para verificar el acceso a ciertas características de la aplicación premium basado en las suscripciones móviles del dispositivo a través de la SIM.

Use: Subscription IDAPI para identificar las SIMs que se utilizan en el dispositivo.

El ID de la suscripción proporciona un valor de índice (a partir de 1) para identificar de forma única las SIMs instaladas (incluyendo físicas y electrónicas) utilizadas en el dispositivo. A través de este ID, su aplicación puede asociar su funcionalidad con la información de varias suscripciones para una determinada SIM. Este valor es estable para una determinada SIM a menos que el dispositivo se restablezca de fábrica. Sin embargo, puede haber casos en los que la misma SIM tenga un ID de suscripción diferente en diferentes dispositivos o que diferentes SIMs tengan el mismo ID en diferentes dispositivos. si el ID de suscripción no es suficientemente único, se recomienda concatenar el ID de suscripción con el SSAID.

¿Por qué esta recomendación?

Algunas aplicaciones pueden estar utilizando actualmente el ICCID para este propósito. Debido a que el ICCID es único a nivel mundial y no se puede restablecer, el acceso ha sido restringido a las aplicaciones con el READ_PRIVILEGED_PHONE_STATEpermiso desde Android 10. A partir de Android 11, Google restringió aún más el acceso al ICCID a través de la API getIccId(), independientemente del nivel de la API de destino de la aplicación. Las aplicaciones afectadas deben migrar para utilizar el ID de suscripción en su lugar.

Antifraude: Enforcing free content limits and detecting Sybil attacks

En este caso, se quiere limitar el número de contenidos gratuitos, como artículos,que un usuario puede ver en un dispositivo.

Uso: FID o GUID. En Android 8.0 (nivel de API 26) y superior, el SSAID también es una opción, ya que se limita a la clave de firma de la aplicación.

¿Por qué esta recomendación?

Usar un GUID o FID obliga al usuario a reinstalar la aplicación para eludir los límites de contenido, lo cual es una carga suficiente para disuadir a la mayoría de la gente. Si esto no es suficiente protección, Android proporciona un DRMAPI, que se puede utilizar para limitar el acceso al contenido, incluye un identificador por APK, el Widevine ID.

Funcionalidad del operador

En este caso, su aplicación está interactuando con el teléfono del dispositivo y la funcionalidad de mensajes de texto utilizando una cuenta de operador.

Utilizar: IMEI, IMSI y Línea1

¿Por qué esta recomendación?

Utilizar identificadores de hardware es aceptable si es necesario para la funcionalidad relacionada con el operador. Por ejemplo, podría utilizar estos identificadores para cambiar de operador celular o ranuras SIM, o para entregar mensajes SMS a través de IP (para Line1) – cuentas de usuario basadas en SIM. Sin embargo, en el caso de las aplicaciones sin privilegios, recomendamos utilizar un inicio de sesión de cuenta para recuperar la información del dispositivo del usuario en el lado del servidor. Una de las razones es que, en Android 6.0 (nivel 23 de la API) y superiores, estos identificadores sólo pueden utilizarse mediante un permiso de ejecución. Los usuarios pueden desactivar este permiso, por lo que su aplicación debe manejar estas excepciones con elegancia.

Detección de abusos: Identificación de bots y ataques DDoS

En este caso, estás tratando de detectar múltiples dispositivos falsos que atacan tus servicios de backend.

Uso: La API de SafetyNet

¿Por qué esta recomendación?

Un identificador aislado hace poco para indicar que un dispositivo es genuino. Puedes verificar que una solicitud proviene de un dispositivo Android genuino -en contraposición a un simulador u otro código que suplante a otro dispositivo- utilizando el método de la API SafetyNet para verificar la integridad de un dispositivo que realiza una solicitud. Para obtener información más detallada, consulte la documentación de la API de SafetyNet.

Detección de fraudes y abusos: Detección de credenciales robadas de alto valor

En este caso, se trata de detectar si un mismo dispositivo se está utilizando varias veces con credenciales robadas de alto valor, como por ejemplo para realizar pagos fraudulentos.

Uso: Por su naturaleza, la prevención del fraude requiere señales propietarias que pueden cambiar con el tiempo y, por tanto, están fuera del alcance de este documento. Sin embargo, hay que tener en cuenta que los identificadores de hardware, como el IMEI y el IMSI, pueden modificarse fácilmente en los dispositivos con raíz o emulados, por lo que no son indicadores fiables de fraude.