Bonnes pratiques pour les identifiants uniques

Ce document fournit des conseils pour sélectionner les identifiants appropriés pour votre application en fonction de votre cas d'utilisation.

Pour obtenir un aperçu général des autorisations Android, consultez la section Autorisations présentation. Pour les bonnes pratiques pratiques d'utilisation des autorisations Android, consultez la section Bonnes pratiques pour les autorisations des applications pratiques.

Bonnes pratiques pour l'utilisation des identifiants Android

Pour protéger la confidentialité de vos utilisateurs, utilisez l'identifiant le plus restrictif répond au cas d'utilisation de votre application. Suivez plus particulièrement les bonnes pratiques suivantes :

1. Dans la mesure du possible, choisissez des identifiants réinitialisables par l'utilisateur. Votre application peut pour la plupart de ses cas d'utilisation, même lorsqu'elle utilise des identifiants autres que ID matériel non réinitialisables.

2. Évitez d'utiliser des identifiants matériels. Dans la plupart des cas d'utilisation, vous pouvez éviter à l'aide d'identifiants matériels tels que l'identifiant international du matériel mobile (code IMEI), sans limiter les fonctionnalités requises.

   Android 10 (niveau d'API 29) ajoute des restrictions pour les identifiants non réinitialisables. qui comprennent à la fois le code IMEI et le numéro de série. Votre application doit être un appareil ou propriétaire du profil application, faire appel à un opérateur spécial des autorisations ou si vous avez l’autorisation privilégiée READ_PRIVILEGED_PHONE_STATE afin d’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 que avec le consentement explicite de l'utilisateur.

4. Ne reliez pas 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 des fraudes au paiement la téléphonie. Pour la grande majorité des cas d'utilisation non publicitaires, un FID ou GUID devraient être suffisants.

6. Utilisez des API adaptées à votre cas d'utilisation pour minimiser les risques de confidentialité. Utilisez l'API DRM pour une protection de contenu à forte valeur ajoutée Les API Play Integrity pour la protection contre les abus. Les API Play Integrity sont le moyen le plus simple de déterminer si un appareil est authentique sans courir de risque de confidentialité.

Les autres sections de ce guide détaillent ces règles dans le contexte développer des applications Android.

Utiliser des identifiants publicitaires

L'identifiant publicitaire est adapté aux annonces et peut être réinitialisé par l'utilisateur. différents cas d'utilisation. Lorsque vous utilisez cette méthode, vous devez garder à l'esprit les points clés ID:

Respectez toujours l'intention de l'utilisateur de réinitialiser l'identifiant publicitaire. Ne pas associer les réinitialisations de l'utilisateur à l'aide d'un autre identifiant ou d'une autre empreinte digitale d'identifiants publicitaires ultérieurs ensemble, sans le consentement de l'utilisateur. Le Règlement sur le contenu pour les développeurs Google Play 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 d'annonces personnalisées associé. Les ID publicitaires sont configurables, car les utilisateurs peuvent limiter la quantité de suivi associée à l'ID. Utilisez toujours AdvertisingIdClient.Info.isLimitAdTrackingEnabled() pour vérifier que vous ne contournez pas souhaits. L'application Google Contenu Play pour les développeurs de Google stipule que suivantes:

"...vous devez respecter les règles définies par l'utilisateur concernant la désactivation de la publicité ciblée par centres d'intérêt. ou "Désactiver la personnalisation des annonces" . Si un utilisateur a activé ce paramètre, vous ne pouvez pas utiliser l'identifiant publicitaire pour créer des profils utilisateur pour à des fins publicitaires ou pour cibler des utilisateurs avec de la publicité personnalisée. La publicité contextuelle, la limitation de la fréquence d'exposition et les conversions font partie des activités autorisées. le suivi, le reporting, la sécurité et la détection des fraudes."

Tenez compte des règles de confidentialité ou de sécurité associées aux SDK que vous utilisez et qui concernent 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 applicables du SDK Analytics.

Sachez également que le Contenu pour les développeurs Google Play Règles que l'identifiant publicitaire "ne doit pas être associé à des identifiants informations ou associées à tout identifiant permanent de l'appareil (par exemple: SSAID, adresse MAC, code IMEI, etc.).

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

Dans cet exemple, la colonne ad_id pourrait être jointe aux informations d'identification personnelle via la colonne account_id dans les deux tables, ce qui constituerait une violation du Règlement sur le contenu pour les développeurs Google Play, si vous n'avez pas obtenu l'autorisation explicite de vos utilisateurs.

Sachez que les liens entre la référence annonceur et les informations permettant d'identifier personnellement l'utilisateur ne sont pas toujours explicite. Il est possible que des "quasi-identifiants" apparaissent à la fois dans les tables avec clé d'ID utilisateur et d'annonce, ce qui pose également problème. Par exemple, supposons que nous remplaçons TABLE-01 et TABLE-02 comme suit:

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

Bien qu'il soit souvent difficile de garantir qu'il n'existe pas de tels quasi-identifiants vous pouvez prévenir les risques de jointure les plus évidents en généralisant des données uniques lorsque cela est possible. Dans l'exemple précédent, cela signifie réduire la précision du code temporel afin que plusieurs appareils du même modèle apparaissent pour chaque code temporel.

Voici d'autres solutions:

• Ne pas concevoir de tables qui associent explicitement des informations personnelles à des identifiants publicitaires Dans le premier exemple ci-dessus, cela signifie que la colonne account_id ne doit pas être incluse dans TABLE-01.

• Séparer et surveiller les listes de contrôle d'accès pour les utilisateurs ou les rôles ayant 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 aux deux sources simultanément (par exemple, en effectuant une jointure entre les tables), vous réduisez le risque d'association entre l'identifiant publicitaire et les informations permettant d'identifier personnellement l'utilisateur. De manière générale, contrôler les accès implique d'effectuer les actions suivantes:

  1. Conserver les listes de contrôle d'accès (LCA) pour les informations permettant d'identifier personnellement l'utilisateur et celles associées à la référence annonceur disjoint pour minimiser le nombre d'individus ou de rôles appartenant à la fois les listes de contrôle d'accès.
  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 identifiants publicitaires, consultez les Documentation de référence de l'API AdvertisingIdClient

Utiliser les FID 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. Uniquement l'instance d'application pour laquelle qu'il a été provisionné peuvent accéder à cet identifiant, et qu'il est (relativement) facilement réinitialisable, car cela ne persiste que tant que l'application est installée.

Par conséquent, les FID offrent de meilleures propriétés de confidentialité que ID matériels de portée appareil non réinitialisables. Pour en savoir plus, consultez les firebase.installations Documentation de référence de l'API.

Lorsqu'un FID n'est pas pratique, vous pouvez aussi utiliser des des ID uniques globaux (GUID) 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();

Étant donné que 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 l'espace de stockage interne plutôt que dans l'espace de stockage externe (partagé). Pour plus consultez la page Stockage de données et de fichiers présentation.

Ne fonctionnent pas avec les adresses MAC

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

Modifications de la disponibilité des adresses MAC sous Android 11

Dans les applications ciblant Android 11 ou version ultérieure, la randomisation MAC pour les réseaux Passpoint est effectuée par profil Passpoint, ce qui génère une adresse MAC unique basée sur les champs suivants :

• Nom de domaine complet
• Domaine
• Identifiants, en fonction des identifiants utilisés dans le profil Passpoint :
  • Identifiants utilisateur: nom d'utilisateur
  • Identifiants de certificat : certificat et type de certificat
  • Identifiants de la carte 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 disposant 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 applications concernées par ce changement:

• NetworkInterface.getHardwareAddress() renvoie une valeur nulle 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 ConnectivityManager au lieu de des API de niveau inférieur comme NetworkInterface, getifaddrs(), ou Netlink. Par exemple, une application qui a besoin d'informations à jour sur les itinéraires actuels peut obtenir ces informations en écoutant les modifications de réseau à l'aide de ConnectivityManager.registerNetworkCallback() et en appelant l'LinkProperties.getRoutes() associé au réseau.

Caractéristiques de l'identifiant

L'OS Android propose un certain nombre d'ID ayant des caractéristiques de comportement différentes. L'identifiant à utiliser dépend du fonctionnement des caractéristiques suivantes votre cas d'utilisation. Toutefois, 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 explique quels systèmes peuvent accéder à l'identifiant. La portée 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 : toutes les applications installées sur l'appareil peuvent accéder à l'ID.

Plus le champ d'application d'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 une seule instance d'application, elle ne peut pas servir à suivre un appareil lors de transactions dans différentes applications.

Réinitialisation et persistance

La réinitialisabilité 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 démarrage et les réinitialisations lors de l'installation. La durée de vie des identifiants Android peut varier, mais elle est généralement liée à la façon dont l'ID est réinitialisé :

• Session uniquement : un nouvel ID est utilisé chaque fois que l'utilisateur redémarre l'application.
• Installation/réinitialisation: un nouvel ID est utilisé chaque fois que l'utilisateur effectue une désinstallation ou une réinstallation. l'application.
• Rétablir la configuration d'usine: un nouvel ID est utilisé chaque fois que l'utilisateur rétablit la configuration d'usine de l'appareil.
• Persistant après un rétablissement de la configuration d'usine : l'ID est conservé après un rétablissement de la configuration d'usine.

La réinitialisation permet aux utilisateurs de créer un ID dissocié à partir des informations de profil existantes. Plus un identifiant persiste longtemps et de manière fiable, comme celui qui persiste après une réinitialisation 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 aucun contrôle utilisateur explicite pour le réinitialiser depuis l'application ou les paramètres système.

unicité

L'unicité établit la probabilité de collision ; c'est-à-dire que le schéma existent dans le champ d'application associé. Au plus haut niveau, un identifiant unique ne présente jamais de collision, même sur d’autres appareils ou applications. Sinon, le niveau d'unicité dépend de l'entropie de l'identifiant la source du caractère aléatoire utilisée pour la créer. Par exemple, la probabilité qu'un le risque de collision est beaucoup plus élevé pour les identifiants aléatoires (comme 2019-03-01) que pour les identifiants alimentés par le package Unix Horodatage 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 dispose d'un ID unique. D'un autre côté, plus un identifiant est moins unique dans 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épudiabilité

Vous pouvez utiliser un identifiant difficile à falsifier ou à reproduire pour prouver que l'appareil ou le compte associé présente 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 à falsifier offrent également une non-répudiation. Si l'appareil signe un message avec une clé secrète, il est difficile de prétendre que l'appareil d'un tiers a envoyé le message. La non-répudiation peut être une fonctionnalité souhaitée par l'utilisateur, par exemple lors de l'authentification d'un paiement, ou une propriété indésirable, par exemple lorsqu'il envoie un message qu'il regrette.

Cas d'utilisation courants et identifiant approprié

Cette section présente des alternatives à l'utilisation d'identifiants matériels, tels que l'IMEI. En utilisant d'ID matériel est déconseillé, car l'utilisateur ne peut pas les réinitialiser, et ils sont limité à l'appareil. Dans de nombreux cas, un identifiant de portée application suffit.

Comptes

État de l'opérateur

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

Identifiant recommandé : IMEI, IMSI et Line1

Pourquoi cette recommandation ?

L'utilisation d'identifiants matériels est acceptable si elle est requise pour des fonctionnalités liées à l'opérateur. Par exemple, vous pouvez utiliser ces identifiants pour basculer entre des opérateurs mobiles ou des emplacements de carte SIM, ou pour envoyer des messages SMS via IP (pour Line1) : comptes utilisateur basés sur une carte SIM. Pour les applications non privilégiées, Recommander d'utiliser la connexion à un compte pour récupérer les informations provenant des appareils des utilisateurs côté serveur. Cela s'explique par le fait qu'Android 6.0 (niveau d'API 23) et ces identifiants ne peuvent être utilisés que via une autorisation d'exécution. Les utilisateurs peuvent désactiver cette autorisation pour que votre appli gère ces exceptions avec grâce.

État de l'abonnement mobile

Dans ce cas, vous devez associer la fonctionnalité de l'application à certains abonnements de services mobiles sur l'appareil. Par exemple, vous pouvez avoir besoin de vérifier l'accès à certaines fonctionnalités premium de l'application en fonction de l'appareil mobile abonnements via SIM.

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

L'ID d'abonnement fournit une valeur d'indice (à partir de 1) pour identifier de manière unique les SIM installées (y compris les physiques et les électroniques) utilisées sur l'appareil. Grâce à cet identifiant, votre application peut associer sa fonctionnalité à diverses des informations d'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. Cependant, il peut arriver que le même La carte SIM a un ID d'abonnement différent sur les différents appareils ou les différentes cartes SIM ont le même identifiant sur différents appareils.

Pourquoi cette recommandation ?

Certaines applications utilisent peut-être actuellement l'ID ICC à cette fin. L'ID ICC étant unique et non réinitialisable, l'accès a été limitée aux applications du READ_PRIVILEGED_PHONE_STATE autorisation 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 à la place.

Authentification unique

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

Identifiant qu'il est recommandé d'utiliser:comptes compatibles avec un responsable de compte, tels que Association du compte Google

Pourquoi cette recommandation ?

L'association du compte Google permet aux utilisateurs d'associer le compte Google existant d'un utilisateur à votre application. Vous bénéficiez ainsi d'un accès fluide et sécurisé à votre produits et services de votre organisation. Vous pouvez également Définir des champs d'application OAuth personnalisés de partager uniquement les données nécessaires, ce qui renforce la confiance des utilisateurs en définissant clairement 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 proposer des annonces plus pertinentes.

Identifiant recommandé:si votre application utilise un identifiant pour les annonces et les importations, ou publié 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 la solution la plus appropriée. L'utilisation de l'identifiant publicitaire est obligatoire pour dans certains cas d'utilisation publicitaires, Règlement relatif au contenu de Google Play pour les développeurs 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 les finalités publicitaires dans la section Sécurité des données de la page Contenu de l'application de la Play Console.

de 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é à utiliser : 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 identifiant 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 ID 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 de Google Play pour les développeurs

Conversions

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

Identifiant recommandé à utiliser : 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 identifiant 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 dans certains cas d'utilisation publicitaires, Règlement relatif au contenu de Google Play pour les développeurs 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 d'un utilisateur.

Identifiant recommandé à utiliser : identifiant publicitaire

Pourquoi cette recommandation ?

Il s'agit d'un cas d'utilisation lié aux annonces qui peut nécessiter un identifiant 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 sur le contenu pour les développeurs Google Play, car l'utilisateur peut le réinitialiser.

Solution d'analyse d'applications

Dans ce cas, votre application évalue le comportement de l'utilisateur pour vous aider à déterminer suivantes:

• Quels autres produits ou applications de votre organisation pourraient convenir à l'utilisateur.
• Comment maintenir l'intérêt des utilisateurs pour votre application.
• Mesurez les statistiques et les analyses d'utilisation pour les utilisateurs déconnectés ou anonymes.

Voici quelques solutions possibles :

• App set ID (ID du groupe d'applications) : cet ID vous permet d'analyser le comportement d'un utilisateur dans plusieurs applications appartenant à votre organisation, tant que vous n'utilisez pas les données utilisateur à des fins publicitaires. Si vous ciblez des appareils équipés de Google Play nous vous recommandons d'utiliser l'ID du groupe d'applications.
• ID Firebase (FID) : un FID est limité à l'application qui le crée, ce qui empêche l'utilisation de l'identifiant pour suivre les utilisateurs entre les applications. Il est également facilement réinitialisables, car l'utilisateur peut effacer les données de l'application ou la réinstaller. La le processus de création d’un FID est simple ; Voir les installations Firebase .

Développement d'application

Rapports d'erreur

Dans ce cas, votre application collecte des données concernant le moment et le motif des plantages appareils de l'utilisateur.

Identifiant recommandé à utiliser : 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 peut également être facilement réinitialisé, 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. Consultez le guide d'installation de Firebase. Un ID d'ensemble 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, afin d'améliorer la qualité de votre application.

Identifiant recommandé à utiliser : Firebase Performance Monitoring

Pourquoi cette recommandation ?

Firebase Performance Monitoring vous aide à vous concentrer sur les métriques les plus importantes et pour tester l'impact d'un changement récent dans votre application.

Test d'applications

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

Identifiant recommandé: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 facilement réinitialisable, 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 ; consultez les Guide d'installation de Firebase Un ID d'ensemble 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 inter-appareils

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

Identifiant recommandé : FID ou GUID

Pourquoi cette recommandation ?

Un FID est conçu explicitement à cette fin ; son champ d'application est limité de sorte qu'elle ne puisse pas être utilisée pour suivre les utilisateurs entre différentes applications. sont réinitialisés lors de la réinstallation de l'application. Dans les rares cas où un FID est insuffisant, vous pouvez également utiliser un GUID.

Sécurité

Détection des abus

Ici, vous essayez de détecter plusieurs faux appareils qui attaquent votre 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 bien d'un appareil Android authentique, et non d'un ou toute autre attaque par spoofing de code d'un autre appareil, utilisez la 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 publicitaires, conformément au Règlement sur le contenu pour les développeurs Google Play, 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 à des propriétés ou des contenus payants.

Identifiant recommandé à utiliser : l'utilisation d'un FID ou d'un GUID oblige l'utilisateur à réinstaller l'application pour contourner les limites de contenu, ce qui constitue un fardeau suffisant 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 sur les applications pour les utilisateurs non 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 est déconseillé de conserver les informations via des réinstallations, car les utilisateurs peuvent qui veulent réinitialiser leurs préférences en réinstallant l’application.