Bonnes pratiques pour les identifiants uniques

Ce document vous aide à choisir les identifiants appropriés pour votre application en fonction de votre cas d'utilisation.

Pour une présentation générale des autorisations Android, consultez Présentation des autorisations. Pour connaître les bonnes pratiques spécifiques concernant l'utilisation des autorisations Android, consultez Bonnes pratiques pour les autorisations des applications.

Bonnes pratiques pour l'utilisation des identifiants Android

Pour protéger la confidentialité de vos utilisateurs, utilisez l'identifiant le plus restrictif adapté au cas d'utilisation de votre application. En particulier, suivez les bonnes pratiques suivantes :

1. Choisissez des identifiants réinitialisables par l'utilisateur autant que possible. Votre application peut atteindre la plupart de ses cas d'utilisation même lorsqu'elle utilise des identifiants autres que des identifiants matériels non réinitialisables.

2. Évitez d'utiliser des identifiants matériels. Dans la plupart des cas d'utilisation, vous pouvez éviter d'utiliser des identifiants matériels, tels que l'International Mobile Equipment Identity (IMEI), sans limiter les fonctionnalités requises.

   Android 10 (niveau d'API 29) ajoute des restrictions pour les identifiants non réinitialisables, qui incluent le code IMEI et le numéro de série. Votre application doit être une application propriétaire de l'appareil ou du profil, disposer d'autorisations spéciales de l'opérateur ou de l'autorisation privilégiée READ_PRIVILEGED_PHONE_STATE pour accéder à ces identifiants.

3. N'utilisez un identifiant publicitaire que pour le profilage des utilisateurs ou pour des cas d'utilisation d'annonces. Lorsque vous utilisez un identifiant publicitaire, respectez toujours les choix des utilisateurs concernant le suivi des annonces. Si vous devez associer l'identifiant publicitaire à des informations permettant d'identifier personnellement l'utilisateur, ne le faites qu'avec son consentement explicite.

4. Ne pas faire de lien entre les réinitialisations de l'identifiant publicitaire.

5. Utilisez un ID d'installation Firebase (FID) ou un GUID stocké de manière privée chaque fois que possible pour tous les autres cas d'utilisation, à l'exception de la prévention de la fraude liée aux paiements et de la téléphonie. Pour la grande majorité des cas d'utilisation autres que les annonces, un FID ou un GUID devrait suffire.

6. Utilisez les API adaptées à votre cas d'utilisation pour minimiser les risques liés à la confidentialité. Utilisez l'API DRM pour protéger les contenus à forte valeur ajoutée et les API Play Integrity pour vous protéger contre les abus. Les API Play Integrity sont le moyen le plus simple de déterminer si un appareil est authentique sans risque pour la confidentialité.

Les sections restantes de ce guide détaillent ces règles dans le contexte du développement d'applications Android.

Utiliser les identifiants publicitaires

L'identifiant publicitaire est un identifiant réinitialisable par l'utilisateur et adapté aux cas d'utilisation des annonces. Toutefois, vous devez tenir compte de certains points clés lorsque vous utilisez cet ID :

Respectez toujours l'intention de l'utilisateur lorsqu'il réinitialise l'identifiant publicitaire. Ne contournez pas les réinitialisations par les utilisateurs en utilisant un autre identifiant ou une empreinte digitale pour associer des ID publicitaires ultérieurs sans le consentement de l'utilisateur. Le Règlement Google Play pour les développeurs concernant le contenu stipule ce qui suit :

"...en cas de réinitialisation de l'identifiant publicitaire, celui-ci ne doit pas être associé à l'identifiant précédent ni à des données dérivées de ce dernier sans le consentement explicite de l'utilisateur."

Respectez toujours le signalement associé aux annonces personnalisées. Les ID publicitaires sont configurables, car les utilisateurs peuvent limiter la quantité de suivi associée à l'ID. Utilisez toujours la méthode AdvertisingIdClient.Info.isLimitAdTrackingEnabled() pour vous assurer de ne pas contourner les souhaits de vos utilisateurs. Le Règlement relatif au contenu pour les développeurs Google Play stipule ce qui suit :

"…vous devez respecter le paramètre "Désactiver les annonces par centres d'intérêt" ou "Désactiver la personnalisation des annonces" défini par l'utilisateur. Si ce paramètre est activé, vous ne devez pas utiliser l'identifiant publicitaire pour créer des profils utilisateur à des fins de publicité ni pour cibler des utilisateurs avec des annonces personnalisées. En revanche, la publicité contextuelle, la limitation du nombre d'expositions, le suivi des conversions, la création de rapports, la sécurité et la détection des fraudes font partie des activités autorisées."

Prenez connaissance des règles de confidentialité ou de sécurité associées aux SDK que vous utilisez et qui sont liées à l'utilisation de l'identifiant publicitaire. Par exemple, si vous transmettez true à la méthode enableAdvertisingIdCollection() du SDK Google Analytics, assurez-vous de consulter et de respecter toutes les Règles du SDK Analytics applicables.

Notez également que le Règlement relatif au contenu du programme Google Play pour les développeurs exige que l'identifiant publicitaire "ne doit pas être associé à des informations permettant d'identifier personnellement l'utilisateur ni à un identifiant permanent de l'appareil (par exemple, SSAID, adresse MAC, code IMEI, etc.)".

Par exemple, supposons que vous souhaitiez collecter des informations pour remplir des tables de base de données avec les colonnes suivantes :

Dans cet exemple, la colonne ad_id pourrait être associée aux informations permettant d'identifier personnellement l'utilisateur via la colonne account_id dans les deux tableaux, ce qui constituerait une violation du Règlement relatif au contenu du programme Google Play pour les développeurs si vous n'obteniez pas l'autorisation explicite de vos utilisateurs.

Gardez à l'esprit que les liens entre l'ID d'annonceur et les informations permettant d'identifier personnellement l'utilisateur ne sont pas toujours aussi explicites. Il est possible que des "quasi-identifiants" apparaissent à la fois dans les tables avec clés d'ID d'annonce et dans celles avec clés d'informations permettant d'identifier personnellement l'utilisateur, ce qui pose également problème. Par exemple, supposons que nous modifions TABLE-01 et TABLE-02 comme suit :

Dans ce cas, avec des événements de clic suffisamment rares, il est toujours possible de joindre l'ID d'annonceur TABLE-01 et les informations permettant d'identifier personnellement l'utilisateur contenues dans TABLE-02 à l'aide du code temporel de l'événement et du modèle de l'appareil.

Bien qu'il soit souvent difficile de garantir qu'aucun quasi-identifiant de ce type n'existe dans un ensemble de données, vous pouvez éviter les risques de jointure les plus évidents en généralisant les données uniques dans la mesure du possible. Dans l'exemple précédent, cela signifierait réduire la précision du code temporel afin que plusieurs appareils du même modèle s'affichent pour chaque code temporel.

Voici d'autres solutions :

• Ne pas concevoir de tables qui associent explicitement des informations permettant d'identifier personnellement l'utilisateur à des identifiants publicitaires. Dans le premier exemple ci-dessus, cela signifie ne pas inclure la colonne account_id dans TABLE-01.

• Séparer et surveiller les listes de contrôle des accès pour les utilisateurs ou les rôles qui ont accès à la fois aux données associées à l'identifiant publicitaire et aux informations permettant d'identifier personnellement l'utilisateur. En contrôlant et en auditant étroitement la possibilité d'accéder simultanément aux deux sources (par exemple, en effectuant une jointure entre les tables), vous réduisez le risque d'association entre l'ID d'annonceur et les informations permettant d'identifier personnellement l'utilisateur. En règle générale, contrôler l'accès signifie effectuer les opérations suivantes :

  1. Veillez à ce que les listes de contrôle d'accès (LCA) pour les données associées à l'ID d'annonceur et les informations permettant d'identifier personnellement l'utilisateur soient disjointes afin de minimiser le nombre de personnes ou de rôles présents dans les deux LCA.
  2. Implémentez la journalisation et l'audit des accès pour détecter et gérer les exceptions à cette règle.

Pour en savoir plus sur l'utilisation responsable des ID publicitaires, consultez la documentation de référence de l'API AdvertisingIdClient.

Utiliser les FIDs et les GUID

La solution la plus simple pour identifier une instance d'application exécutée sur un appareil consiste à utiliser un ID d'installation Firebase (FID). Il s'agit de la solution recommandée dans la majorité des cas d'utilisation autres que les annonces. Seule l'instance d'application pour laquelle il a été provisionné peut accéder à cet identifiant, et il est (relativement) facile à réinitialiser, car il ne persiste que tant que l'application est installée.

Par conséquent, les FID offrent de meilleures propriétés de confidentialité que les ID matériels non réinitialisables et limités à l'appareil. Pour en savoir plus, consultez la documentation de référence de l'API pour firebase.installations.

Si un FID n'est pas pratique, vous pouvez également utiliser des GUID (globally-unique IDs) personnalisés pour identifier de manière unique une instance d'application. Le moyen le plus simple de le faire est de générer votre propre GUID à l'aide du code suivant :

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

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

Comme l'identifiant est unique au niveau mondial, il peut être utilisé pour identifier une instance d'application spécifique. Pour éviter les problèmes liés à l'association de l'identifiant entre les applications, stockez les GUID dans le stockage interne plutôt que dans le stockage externe (partagé). Pour en savoir plus, consultez la page Présentation du stockage de données et de fichiers.

Ne pas utiliser les adresses MAC

Les adresses MAC sont uniques au niveau mondial, ne peuvent pas être réinitialisées par l'utilisateur et sont conservées après un rétablissement de la configuration d'usine. Pour ces raisons, afin de protéger la confidentialité des utilisateurs, l'accès aux adresses MAC est limité aux applications système sur les versions 6 et ultérieures d'Android. Les applications tierces ne peuvent pas y accéder.

Modifications de la disponibilité de l'adresse MAC dans Android 11

Dans les applications ciblant Android 11 et versions ultérieures, l'aléatorisation de l'adresse MAC pour les réseaux Passpoint s'effectue par profil Passpoint, ce qui génère une adresse MAC unique en fonction des champs suivants :

• Nom de domaine complet
• Domaine
• Identifiant, basé sur l'identifiant utilisé dans le profil Passpoint :
  • Identifiant utilisateur : nom d'utilisateur
  • Identifiant de certificat : certificat et type de certificat
  • Identifiants SIM : type EAP et IMSI

De plus, les applications non privilégiées ne peuvent pas accéder à l'adresse MAC de l'appareil. Seules les interfaces réseau dotées d'une adresse IP sont visibles. Cela a un impact sur les méthodes getifaddrs() et NetworkInterface.getHardwareAddress(), ainsi que sur l'envoi de messages Netlink RTM_GETLINK.

Voici une liste des conséquences de ce changement sur les applications :

• NetworkInterface.getHardwareAddress() renvoie la valeur "null" pour chaque interface.
• Les applications ne peuvent pas utiliser la fonction bind() sur les sockets NETLINK_ROUTE.
• La commande ip ne renvoie pas d'informations sur les interfaces.
• Les applications ne peuvent pas envoyer de messages RTM_GETLINK.

Notez que la plupart des développeurs doivent utiliser les API de niveau supérieur de ConnectivityManager plutôt que les API de niveau inférieur telles que NetworkInterface, getifaddrs() ou les sockets Netlink. Par exemple, une application qui a besoin d'informations à jour sur les itinéraires actuels peut les obtenir en écoutant les changements de réseau à l'aide de ConnectivityManager.registerNetworkCallback() et en appelant le LinkProperties.getRoutes() associé au réseau.

Caractéristiques des identifiants

L'OS Android propose plusieurs ID avec des caractéristiques de comportement différentes. L'ID à utiliser dépend de la façon dont les caractéristiques suivantes fonctionnent avec votre cas d'utilisation. Ces caractéristiques ont également des implications en termes de confidentialité. Il est donc important de comprendre comment elles interagissent entre elles.

Champ d'application

Le champ d'application de l'identifiant indique les systèmes pouvant y accéder. L'étendue de l'identifiant Android se présente généralement sous trois formes :

• Application unique : l'ID est interne à l'application et n'est pas accessible aux autres applications.
• Groupe d'applications : l'ID est accessible à un groupe prédéfini d'applications associées.
• Appareil : l'ID est accessible à toutes les applications installées sur l'appareil.

Plus le champ d'application accordé à un identifiant est large, plus le risque qu'il soit utilisé à des fins de suivi est élevé. À l'inverse, si un identifiant n'est accessible que par une seule instance d'application, il ne peut pas être utilisé pour suivre un appareil lors de transactions dans différentes applications.

Réinitialisation et persistance

La réinitialisation et la persistance définissent la durée de vie de l'identifiant et expliquent comment il peut être réinitialisé. Les déclencheurs de réinitialisation courants incluent les réinitialisations dans l'application, les réinitialisations via les paramètres système, les réinitialisations au lancement et les réinitialisations à l'installation. Les identifiants Android peuvent avoir des durées de vie variables, mais la durée de vie est généralement liée à la façon dont l'identifiant est réinitialisé :

• Session uniquement : un nouvel ID est utilisé chaque fois que l'utilisateur redémarre l'application.
• Réinitialisation de l'installation : un nouvel ID est utilisé chaque fois que l'utilisateur désinstalle et réinstalle l'application.
• Réinitialisation de la configuration d'usine : un nouvel ID est utilisé chaque fois que l'utilisateur rétablit la configuration d'usine de l'appareil.
• FDR-persistent : l'ID est conservé après le rétablissement de la configuration d'usine.

La réinitialisation permet aux utilisateurs de créer un ID dissocié des informations de profil existantes. Plus un identifiant persiste longtemps et de manière fiable (par exemple, un identifiant qui persiste après une réinitialisation des paramètres d'usine), plus le risque que l'utilisateur soit soumis à un suivi à long terme est élevé. Si l'identifiant est réinitialisé lors de la réinstallation de l'application, cela réduit la persistance et permet de réinitialiser l'ID, même s'il n'existe pas de contrôle utilisateur explicite pour le réinitialiser depuis l'application ou les paramètres système.

unicité

L'unicité établit la probabilité de collisions, c'est-à-dire que des identifiants identiques existent dans le champ d'application associé. Au niveau le plus élevé, un identifiant unique au niveau mondial n'entre jamais en conflit, même sur d'autres appareils ou applications. Sinon, le niveau d'unicité dépend de l'entropie de l'identifiant et de la source d'aléatoire utilisée pour le créer. Par exemple, le risque de collision est beaucoup plus élevé pour les identifiants aléatoires initialisés avec la date d'installation (par exemple, 2019-03-01) que pour les identifiants initialisés avec le code temporel Unix de l'installation (par exemple, 1551414181).

En général, les identifiants de compte utilisateur peuvent être considérés comme uniques. Autrement dit, chaque combinaison appareil/compte possède un ID unique. En revanche, moins un identifiant est unique au sein d'une population, plus la protection de la confidentialité est élevée, car il est moins utile pour suivre un utilisateur individuel.

Protection de l'intégrité et non-répudiation

Vous pouvez utiliser un identifiant difficile à usurper ou à rejouer pour prouver que l'appareil ou le compte associé possède certaines propriétés. Par exemple, vous pouvez prouver que l'appareil n'est pas un appareil virtuel utilisé par un spammeur. Les identifiants difficiles à usurper offrent également la non-répudiation. Si l'appareil signe un message avec une clé secrète, il est difficile d'affirmer qu'un autre appareil a envoyé le message. La non-répudiation peut être souhaitée par un utilisateur, par exemple lors de l'authentification d'un paiement, ou indésirable, par exemple lorsqu'il envoie un message qu'il regrette.

Cas d'utilisation courants et identifiant approprié à utiliser

Cette section propose des alternatives à l'utilisation d'identifiants matériels, tels que l'IMEI. L'utilisation d'ID matériels est déconseillée, car l'utilisateur ne peut pas les réinitialiser et qu'ils sont limités à l'appareil. Dans de nombreux cas, un identifiant limité à l'application suffirait.

Comptes

État du transporteur

Dans ce cas, votre application interagit avec les fonctionnalités de téléphone et d'envoi de messages de l'appareil à l'aide d'un compte d'opérateur.

Identifiants recommandés : IMEI, IMSI et Line1

Pourquoi cette recommandation ?

Il est acceptable d'utiliser des identifiants matériels si cela est nécessaire pour les fonctionnalités liées à l'opérateur. Par exemple, vous pouvez utiliser ces identifiants pour passer d'un opérateur mobile ou d'un emplacement SIM à un autre, ou pour envoyer des messages SMS sur IP (pour Line1) : comptes utilisateur basés sur la carte SIM. Toutefois, pour les applications non privilégiées, nous vous recommandons d'utiliser une connexion à un compte pour récupérer les informations sur l'appareil de l'utilisateur côté serveur. En effet, sous Android 6.0 (niveau d'API 23) et versions ultérieures, ces identifiants ne peuvent être utilisés qu'avec une autorisation d'exécution. Les utilisateurs peuvent désactiver cette autorisation. Votre application doit donc gérer ces exceptions de manière fluide.

État de l'abonnement mobile

Dans ce cas, vous devez associer les fonctionnalités de l'application à certains abonnements aux services mobiles sur l'appareil. Par exemple, vous pouvez être amené à vérifier l'accès à certaines fonctionnalités premium de l'application en fonction des abonnements mobiles de l'appareil via la carte SIM.

Identifiant recommandé : utilisez l'API Subscription ID pour identifier les cartes SIM utilisées sur l'appareil.

L'ID d'abonnement fournit une valeur d'index (à partir de 1) pour identifier de manière unique les cartes SIM installées (y compris physiques et électroniques) utilisées sur l'appareil. Grâce à cet ID, votre application peut associer sa fonctionnalité à diverses informations sur l'abonnement pour une carte SIM donnée. Cette valeur est stable pour une carte SIM donnée, sauf si la configuration d'usine de l'appareil est rétablie. Toutefois, il peut arriver que la même carte SIM ait un ID d'abonnement différent sur différents appareils ou que différentes cartes SIM aient le même ID sur différents appareils.

Pourquoi cette recommandation ?

Certaines applications peuvent actuellement utiliser l'ID ICC à cette fin. Étant donné que l'ICCID est unique au niveau mondial et ne peut pas être réinitialisé, l'accès a été limité aux applications disposant de l'autorisation READ_PRIVILEGED_PHONE_STATE depuis Android 10. À partir d'Android 11, Android a encore restreint l'accès à l'ICCID via l'API getIccId(), quel que soit le niveau d'API cible de l'application. Les applications concernées doivent migrer pour utiliser l'ID d'abonnement.

Authentification unique

Dans ce cas, votre application propose une expérience d'authentification unique, permettant aux utilisateurs d'associer un compte existant à votre organisation.

Identifiant recommandé à utiliser : comptes compatibles avec les responsables de compte, tels que l'association de compte Google

Pourquoi cette recommandation ?

L'association de compte Google permet aux utilisateurs d'associer un compte Google existant à votre application, ce qui leur offre un accès fluide et plus sécurisé aux produits et services de votre organisation. De plus, vous pouvez définir des champs d'application OAuth personnalisés pour ne partager que les données nécessaires. Vous renforcez ainsi la confiance des utilisateurs en définissant clairement comment leurs données sont utilisées.

Annonces

Ciblage

Dans ce cas, votre application crée un profil des centres d'intérêt d'un utilisateur pour lui montrer des annonces plus pertinentes.

Identifiant recommandé à utiliser : si votre application utilise un identifiant pour les annonces et qu'elle est importée ou publiée sur Google Play, cet identifiant doit être l'identifiant publicitaire.

Pourquoi cette recommandation ?

Il s'agit d'un cas d'utilisation lié aux annonces qui peut nécessiter un ID disponible dans les différentes applications de votre organisation. L'utilisation d'un identifiant publicitaire est donc la solution la plus appropriée. L'utilisation de l'identifiant publicitaire est obligatoire pour les cas d'utilisation publicitaires, conformément au Règlement Google Play pour les développeurs concernant le contenu, car l'utilisateur peut le réinitialiser.

Que vous partagiez ou non des données utilisateur dans votre application, si vous les collectez et les utilisez à des fins publicitaires, vous devez déclarer ces fins dans la section "Sécurité des données" de la page Contenu de l'application de la Play Console.

Mesure

Dans ce cas, votre application crée un profil d'utilisateur en fonction de son comportement dans les applications de votre organisation sur le même appareil.

Identifiant recommandé : identifiant publicitaire ou API Play Install Referrer

Pourquoi cette recommandation ?

Il s'agit d'un cas d'utilisation lié aux annonces qui peut nécessiter un ID disponible dans les différentes applications de votre organisation. L'utilisation d'un identifiant publicitaire est donc la solution la plus appropriée. Si vous utilisez un identifiant pour des cas d'utilisation publicitaires, il doit s'agir de l'identifiant publicitaire, car l'utilisateur peut le réinitialiser. Pour en savoir plus, consultez le Règlement relatif au contenu du programme pour les développeurs Google Play.

Conversions

Dans ce cas, vous suivez les conversions pour déterminer si votre stratégie marketing est efficace.

Identifiant recommandé : identifiant publicitaire ou API Play Install Referrer

Pourquoi cette recommandation ?

Il s'agit d'un cas d'utilisation lié aux annonces qui peut nécessiter un ID disponible dans les différentes applications de votre organisation. L'utilisation d'un identifiant publicitaire est donc la solution la plus appropriée. L'utilisation de l'identifiant publicitaire est obligatoire pour les cas d'utilisation publicitaires, conformément au Règlement Google Play pour les développeurs concernant le contenu, car l'utilisateur peut le réinitialiser.

Remarketing

Dans ce cas, votre application diffuse des annonces en fonction des centres d'intérêt précédents de l'utilisateur.

Identifiant recommandé : identifiant publicitaire

Pourquoi cette recommandation ?

Il s'agit d'un cas d'utilisation lié aux annonces qui peut nécessiter un ID disponible dans les différentes applications de votre organisation. L'utilisation d'un identifiant publicitaire est donc la solution la plus appropriée. L'utilisation de l'identifiant publicitaire est obligatoire pour les cas d'utilisation publicitaires, conformément au Règlement Google Play pour les développeurs concernant le contenu, car l'utilisateur peut le réinitialiser.

Solution d'analyse d'applications

Dans ce cas, votre application évalue le comportement d'un utilisateur pour vous aider à déterminer les éléments suivants :

• Quels autres produits ou applications de votre organisation pourraient convenir à l'utilisateur ?
• Découvrez comment inciter les utilisateurs à continuer d'utiliser votre application.
• Mesurez les statistiques d'utilisation et les données analytiques pour les utilisateurs déconnectés ou anonymes.

Voici quelques solutions possibles :

• ID de groupe d'applications : un ID de groupe d'applications vous permet d'analyser le comportement d'un utilisateur dans plusieurs applications appartenant à votre organisation, à condition de ne pas utiliser les données utilisateur à des fins publicitaires. Si vous ciblez des appareils fonctionnant avec les services Google Play, nous vous recommandons d'utiliser l'ID de groupe d'applications.
• ID Firebase (FID) : un FID est limité à l'application qui le crée, ce qui empêche l'identifiant d'être utilisé pour suivre les utilisateurs dans plusieurs applications. Il est également facile à réinitialiser, car l'utilisateur peut effacer les données de l'application ou la réinstaller. La création d'un FID est simple. Consultez le guide des installations Firebase.

Développement d'application

Rapports d'erreur

Dans ce cas, votre application collecte des données sur le moment et la raison de son plantage sur les appareils d'un utilisateur.

Identifiants recommandés : FID ou ID du groupe d'applications

Pourquoi cette recommandation ?

Un FID est limité à l'application qui le crée, ce qui empêche l'identifiant d'être utilisé pour suivre les utilisateurs dans plusieurs applications. Il est également facile à réinitialiser, car l'utilisateur peut effacer les données de l'application ou la réinstaller. Le processus de création d'un FID est simple. Pour en savoir plus, consultez le guide d'installation de Firebase. Un ID de groupe d'applications vous permet d'analyser le comportement d'un utilisateur dans plusieurs applications appartenant à votre organisation, à condition de ne pas utiliser les données utilisateur à des fins publicitaires.

Rapports sur les performances

Dans ce cas, votre application collecte des métriques de performances, telles que les temps de chargement et l'utilisation de la batterie, pour améliorer la qualité de votre application.

Identifiant recommandé : Firebase Performance Monitoring

Pourquoi cette recommandation ?

Firebase Performance Monitoring vous aide à vous concentrer sur les métriques qui comptent le plus pour vous et à tester l'impact d'une modification récente dans votre application.

Test d'applications

Dans ce cas, votre application évalue l'expérience d'un utilisateur avec votre application à des fins de test ou de débogage.

Identifiants recommandés : FID ou ID du groupe d'applications

Pourquoi cette recommandation ?

Un FID est limité à l'application qui le crée, ce qui empêche l'identifiant d'être utilisé pour suivre les utilisateurs dans plusieurs applications. Il est également facile à réinitialiser, car l'utilisateur peut effacer les données de l'application ou la réinstaller. Le processus de création d'un FID est simple. Pour en savoir plus, consultez le guide d'installation de Firebase. Un ID de groupe d'applications vous permet d'analyser le comportement d'un utilisateur dans plusieurs applications appartenant à votre organisation, à condition de ne pas utiliser les données utilisateur à des fins publicitaires.

Installation multi-appareil

Dans ce cas, votre application doit identifier la bonne instance de l'application lorsqu'elle est installée sur plusieurs appareils pour le même utilisateur.

Identifiant recommandé : FID ou GUID

Pourquoi cette recommandation ?

Un FID est conçu spécifiquement à cet effet. Sa portée est limitée à l'application afin qu'il ne puisse pas être utilisé pour suivre les utilisateurs dans différentes applications. Il est réinitialisé lors de la réinstallation de l'application. Dans les rares cas où un FID ne suffit pas, vous pouvez également utiliser un GUID.

Sécurité

Détection des utilisations abusives

Dans ce cas, vous essayez de détecter plusieurs faux appareils qui attaquent vos services de backend.

Identifiant recommandé à utiliser : jeton d'intégrité de l'API Google Play Integrity

Pourquoi cette recommandation ?

Pour vérifier qu'une requête provient d'un appareil Android authentique (et non d'un émulateur ou d'un autre code usurpant un autre appareil), utilisez l'API Google Play Integrity.

Fraude publicitaire

Dans ce cas, votre application vérifie que les impressions et les actions d'un utilisateur dans votre application sont authentiques et vérifiables.

Identifiant recommandé : identifiant publicitaire

Pourquoi cette recommandation ?

L'utilisation de l'identifiant publicitaire est obligatoire pour les cas d'utilisation publicitaire, conformément au Règlement de Google Play pour les développeurs concernant le contenu, car l'utilisateur peut le réinitialiser.

Gestion des droits numériques (DRM)

Dans ce cas, votre application souhaite protéger l'accès frauduleux à la propriété intellectuelle ou au contenu payant.

Identifiant recommandé : l'utilisation d'un FID ou d'un GUID oblige l'utilisateur à réinstaller l'application pour contourner les limites de contenu, ce qui est une contrainte suffisante pour dissuader la plupart des utilisateurs. Si cette protection n'est pas suffisante, Android fournit une API DRM qui peut être utilisée pour limiter l'accès au contenu. Elle inclut un identifiant par APK, l'ID Widevine.

Préférences utilisateur

Dans ce cas, votre application enregistre l'état de l'utilisateur par appareil, en particulier pour les utilisateurs qui ne sont pas connectés. Vous pouvez transférer cet état vers une autre application signée avec la même clé sur le même appareil.

Identifiant recommandé : FID ou GUID

Pourquoi cette recommandation ?

Il n'est pas recommandé de conserver les informations lors des réinstallations, car les utilisateurs peuvent souhaiter réinitialiser leurs préférences en réinstallant l'application.