Cette page a été traduite par l'API Cloud Translation.

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 en particulier les bonnes pratiques suivantes:

Dans la mesure du possible, choisissez des identifiants réinitialisables par l'utilisateur. Votre application peut traiter la plupart de ses cas d'utilisation, même lorsqu'elle utilise des identifiants autres que des identifiants matériels non réinitialisables.
É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, y compris 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 disposer de l'autorisation privilégiée READ_PRIVILEGED_PHONE_STATE pour accéder à ces identifiants.
N'utilisez un identifiant publicitaire que pour le profilage des utilisateurs ou pour les cas d'utilisation d'annonces. Quand ? À l'aide d'un identifiant publicitaire, respectez toujours les utilisateurs sélections concernant 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.
Ne reliez pas les réinitialisations de l'identifiant publicitaire.
Utilisez un ID d'installation Firebase (FID) ou un GUID stocké de manière privée dans la mesure du possible pour tous les autres cas d'utilisation, à l'exception de la prévention de la fraude 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.
Utilisez des API adaptées à votre cas d'utilisation afin de réduire au maximum la confidentialité les risques. 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 Contenu pour les développeurs Google Play de Google stipule que suivantes:

"...en cas de réinitialisation, aucun nouvel identifiant publicitaire ne doit être associé Identifiant publicitaire précédent ou données dérivées d'une précédente publicité sans le consentement explicite de l'utilisateur."

Respectez toujours le signalement d'annonces personnalisées associé. Les identifiants publicitaires sont configurable dans la mesure où les utilisateurs peuvent limiter le volume de suivi associé au 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 des applications Google Play pour les développeurs 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 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. 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."

Tenez compte des règles de confidentialité ou de sécurité liées aux SDK que vous utilisez et qui sont liées à l'utilisation de l'identifiant publicitaire. Par exemple, si vous transmettez true au enableAdvertisingIdCollection() du SDK Google Analytics, veillez à consulter et à respecter SDK Analytics applicable règles.

Sachez également que le Règlement sur le contenu des applications de développeur Google Play exige que l'identifiant publicitaire "ne soit pas 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 renseigner les tables de base de données avec les colonnes suivantes :

TABLE-01
`timestamp`	`ad_id`	`account_id`	`clickid`
TABLEAU-02
`account_id`	`name`	`dob`	`country`

Dans cet exemple, la colonne ad_id peut être jointe aux informations permettant d'identifier personnellement l'utilisateur via account_id dans les deux tableaux, ce qui serait contraire aux Règles pour les développeurs Google Play Règlement relatif au contenu, si vous n'ont pas obtenu une autorisation explicite de la part de vos utilisateurs.

N'oubliez pas que les liens entre l'ID de l'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é 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:

TABLE-01
`timestamp`	`ad_id`	`clickid`	`dev_model`
TABLE-02
`timestamp`	`demo`	`account_id`	`dev_model`	`name`

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 signifierait réduire la précision du code temporel afin que plusieurs appareils du même modèle pour chaque code temporel.

Voici d'autres solutions :

Ne pas concevoir de tables qui associent explicitement des informations personnelles à des identifiants publicitaires Dans dans le premier exemple ci-dessus, la colonne account_id n'est pas incluse. dans TABLE-01.
Ségrégation et surveillance des listes de contrôle des 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 capacité à accéder aux deux sources simultanément (par exemple, en effectuant une jointure entre des tables), vous réduisez le risque d'association entre l'identifiant publicitaire et les informations permettant d'identifier personnellement l'utilisateur. En règle générale, le contrôle des accès implique les opérations suivantes :
1. Maintenez les listes de contrôle d'accès (LCA) pour les données associées à l'identifiant de l'annonceur et les informations permettant d'identifier personnellement l'utilisateur distinctes pour réduire le nombre d'individus ou de rôles figurant dans les deux LCA.
2. Mettre en œuvre la journalisation des accès et l'audit 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 la documentation de référence de l'API firebase.installations.

Dans les cas où un FID n'est pas pratique, vous pouvez également utiliser des GUID (Globally Unique Identifiers) 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 :

Kotlin

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

Java

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

Étant donné que l'identifiant est unique, il peut être utilisé pour identifier Compute Engine. 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 niveau mondial, ne peuvent pas être réinitialisées par l'utilisateur et sont conservées en usine est réinitialisée. 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 Passpoint par profil Passpoint, générant une adresse MAC unique en fonction du les champs suivants:

Nom de domaine complet
Domaine
Identifiants basés sur ceux utilisés dans le profil Passpoint: <ph type="x-smartling-placeholder">
- 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. uniquement les interfaces réseau avec 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.

Vous trouverez ci-dessous une liste des conséquences de ce changement sur les applications :

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 indique les systèmes pouvant y accéder. Android le champ d'application de l'identifiant se présente généralement sous trois formes:

Une seule application: l'ID est interne à l'application et les autres applications ne peuvent pas y accéder.
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 que par une seule instance d'application, il ne peut pas être utilisé pour suivre un appareil dans plusieurs 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 le réinitialiser. Les déclencheurs de réinitialisation courants incluent: les réinitialisations dans l'application, les réinitialisations via Paramètres système, réinitialisés au lancement et réinitialisés lors de l'installation. Android les identifiants peuvent avoir des durées de vie variables, mais celles-ci sont généralement liées à 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.
FDR-persistent: l'ID persiste après le 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 et de la source de hasard utilisée pour le créer. Par exemple, le risque de collision est beaucoup plus élevé pour les identifiants aléatoires générés à partir de la date calendaire d'installation (par exemple, 2019-03-01) que pour les identifiants générés à partir du 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 la combinaison appareil/compte possède un identifiant unique. En revanche, moins les tests d'un identifiant au sein d'une population, plus la protection de la confidentialité est efficace, il est moins utile pour suivre un utilisateur individuel.

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

Vous pouvez utiliser un identifiant difficile à falsifier 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 à falsifier offrent également une non-répudiabilité. Si l'appareil signe un message avec une clé secrète, il est difficile d'affirmer que quelqu'un d'autre appareil 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 propose des alternatives à l'utilisation d'ID matériel, tels que le code 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 le téléphone de l'appareil et envoie des messages à l'aide d'un compte d'opérateur.

Identifiant qu'il est recommandé d'utiliser:code IMEI, IMSI et ligne 1

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. Toutefois, pour les applications non privilégiées, nous vous recommandons d'utiliser une connexion de compte pour récupérer les informations sur l'appareil de l'utilisateur 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. Votre application doit donc gérer ces exceptions de manière élégante.

État de l'abonnement mobile

Dans ce cas, vous devez associer les fonctionnalités de l'application à certains de services sur l'appareil. Par exemple, vous devrez peut-être valider l'accès à certaines fonctionnalités d'application premium en fonction des abonnements mobiles de l'appareil via la carte SIM.

Identifiant qu'il est recommandé d'utiliser:ID d'abonnement de l'API pour identifier les cartes 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 ID, votre application peut associer ses fonctionnalités à diverses 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. Toutefois, il est possible 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 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 restreint l'accès à l'ICCID via 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 offre une expérience d'authentification unique, ce qui permet aux utilisateurs associer un compte existant à votre organisation.

Identifiant recommandé à utiliser : comptes compatibles avec le gestionnaire de comptes, tels que l'association de comptes Google

Pourquoi cette recommandation ?

L'association de comptes Google permet aux utilisateurs d'associer leur compte Google existant à votre application, ce qui leur permet d'accéder facilement et de manière plus sécurisée aux 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 des utilisateurs pour leur montrer 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 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.

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 ID disponible. dans les différentes applications de votre organisation. L'utilisation d'un identifiant publicitaire la solution la plus appropriée. Si vous utilisez un identifiant à des fins publicitaires, doit correspondre à 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é:API d'identifiant publicitaire ou de provenance des installations Google Play

Pourquoi cette recommandation ?

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 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.

Solution d'analyse d'applications

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

Parmi les autres produits ou applications de votre organisation, lesquels pourraient convenir au 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 des services Google Play, nous vous recommandons d'utiliser l'ID de l'ensemble 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 de pour suivre les utilisateurs dans les 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 de groupe d'applications vous permet d'analyser le comportement d'un utilisateur dans plusieurs applications qui la propriété de votre organisation, tant que vous n'utilisez pas les données utilisateur à des fins publicitaires. objectifs.

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 sa qualité.

Identifiant recommandé à utiliser : Firebase Performance Monitoring

Pourquoi cette recommandation ?

Firebase Performance Monitoring vous aide à vous concentrer sur les métriques qui vous intéressent le plus et à tester l'impact d'un changement récent 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.

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-appareil

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 qu'il est recommandé d'utiliser:le 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 (plutôt que d'un émulateur ou d'un autre code usurpant l'identité d'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'identifiant publicitaire est obligatoire pour les cas d'utilisation publicitaires, conformément aux Règlement relatif au contenu de Google Play pour les développeurs 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 aux contenus payants.

Identifiant qu'il est recommandé d'utiliser:l'utilisation d'un FID ou d'un GUID oblige l'utilisateur à réinstaller l'application pour contourner les limites de contenu, pour dissuader la plupart des gens. 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 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.