Bonnes pratiques pour les identificateurs uniques

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

Pour un aperçu général des permissions Android, voir Aperçu des permissions. Pour des meilleures pratiques spécifiques pour travailler avec les permissions Android, voir Bonnes pratiques des permissions d’applications.

Bonnes pratiques pour travailler avec les identifiants Android

Lorsque vous travaillez avec des identifiants Android, suivez ces bonnes pratiques :

1. É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 SSAID (Android ID), sans limiter les fonctionnalités requises.

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

2. N’utilisez un identifiant publicitaire que pour des cas d’utilisation de profilage d’utilisateur ou de publicités. Lors de l’utilisation d’un identifiant publicitaire, respectez toujours les choix des utilisateurs concernant le suivi publicitaire. En outre,assurez-vous que l’identifiant ne peut pas être relié à des informations personnellement identifiables (PII), et évitez de ponter les réinitialisations d’ID publicitaires.

3. 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 au paiement et de la téléphonie. Pour la grande majorité des cas d’utilisation non publicitaires, un FID ou un GUID devrait être suffisant.

4. Utiliser les API qui sont appropriées pour votre cas d’utilisation afin de minimiser le risque de confidentialité. Utilisez l’API DRM pour la protection des contenus de grande valeur et les API SafetyNet pour la protection contre les abus. Les API SafetyNet sont le moyen le plus simple de déterminer si un appareil est authentique sans encourir de risque pour la vie privée.

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

Travailler avec des identifiants publicitaires

L’identifiant publicitaire est un identifiant réinitialisable par l’utilisateur et est approprié pour les cas d’utilisation publicitaire. Il y a cependant quelques points clés à garder à l’esprit lorsque vous utilisez cet ID :

Respectez toujours l’intention de l’utilisateur en réinitialisant l’ID publicitaire.Ne palliez pas les réinitialisations de l’utilisateur en utilisant un autre identifiant ou une empreinte digitale pour relier des ID publicitaires successifs sans le consentement de l’utilisateur. Le Google Play Developer ContentPolicy stipule ce qui suit:

« …s’il est réinitialisé, un nouvel identifiant publicitaire ne doit pas être relié à un précédent identifiant publicitaire ou à des données dérivées d’un précédent identifiant publicitaire sans le consentement explicite de l’utilisateur. »

Toujours respecter le drapeau de publicités personnalisées associé. Les identifiants publicitaires sontconfigurables dans la mesure où les utilisateurs peuvent limiter la quantité de suivi associée à l’identifiant. Utilisez toujours la méthode AdvertisingIdClient.Info.isLimitAdTrackingEnabled()pour vous assurer que vous ne contournez pas les souhaits de vos utilisateurs. La politique de contenu pour les développeurs de GooglePlay stipule ce qui suit:

« …vous devez respecter le paramètre de l’utilisateur « Désactiver la publicité basée sur les intérêts » 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 d’utilisateurs à des fins publicitaires ou pour cibler les utilisateurs avec des publicités personnalisées.Les activités autorisées comprennent la publicité contextuelle, le plafonnement de la fréquence, le suivi des conversions, la création de rapports et la sécurité et la détection des fraudes. »

Soyez attentif aux politiques 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 passez true dans la méthodeenableAdvertisingIdCollection() à partir du SDK Google Analytics, assurez-vous d’examiner et d’adhérer à toutes les politiques SDK Analytics applicables.

Sachez également que la Google Play Developer ContentPolicy exige que l’ID publicitaire « ne doit pas être connecté à des informations personnellement identifiables ou associé à un identifiant d’appareil persistant (par exemple:SSAID, adresse MAC, IMEI, etc,). »

À titre d’exemple, supposons que vous souhaitiez collecter des informations pour alimenter des tables de données avec les colonnes suivantes :

Dans cet exemple, la colonne ad_id pourrait être jointe aux DPI via la colonne account_id dans les deux tables, ce qui constituerait une violation de la politique de contenu pour développeurs de Google Play, si vous n’obtenez pas l’autorisation explicite de vos utilisateurs.

N’oubliez pas que les liens entre l’ID de l’annonceur et les DPI ne sont pas toujours aussi explicites. Il est possible d’avoir des « quasi-identifiants » qui apparaissent à la fois dans les tables clés PII etAd ID, ce qui pose également des problèmes. Par exemple, supposons que nous modifionsTABLE-01 et TABLE-02 comme suit :

Dans ce cas, avec des événements de clics suffisamment rares, il est toujours possible de faire une jointure entre l’ID de l’annonceur TABLE-01 et les DPI contenus dans TABLE-02 en utilisant l’horodatage de l’événement et le modèle de l’appareil.

Bien qu’il soit souvent difficile de garantir l’absence de tels quasi-identifiants dans un ensemble de données, vous pouvez prévenir les risques de jointure les plus évidents en généralisant les données uniques lorsque cela est possible. Dans l’exemple précédent, cela signifierait réduire la précision de l’horodatage de sorte que plusieurs appareils avec le même modèleapparaissent pour chaque horodatage.

Les autres solutions comprennent les suivantes :

• Ne pas concevoir de tables qui relient explicitement les IPI aux identifiants publicitaires. Dans le premier exemple ci-dessus, cela signifierait ne pas inclure la colonne account_id dans TABLE-01.

• Ségrégation et surveillance des listes de contrôle d’accès pour les utilisateurs ou les rôles qui ont accès à la fois aux données clés de l’ID publicitaire et aux IIP.En contrôlant et en auditant étroitement la capacité 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’ID publicitaire et les IIP. De manière générale, contrôler l’accès signifie faire ce qui suit :

  1. Maintenir des listes de contrôle d’accès (ACL) pour les données clés de l’ID de l’annonceur et les DPIdisjointes afin de minimiser le nombre d’individus ou de rôles qui se trouvent dans les deuxACL.
  2. Mettre en place une journalisation et un audit de l’accès pour détecter et gérer toute exception à cette règle.

Pour plus d’informations sur le travail responsable avec les ID publicitaires, consultez la référenceAdvertisingIdClient de l’API.

Travailler avec les FID et les GUID

La solution la plus simple pour identifier une instance d’app s’exécutant sur un appareil est d’utiliser un ID d’installation Firebase (FID), et c’est la solution recommandée dans la majorité des cas d’utilisation non publicitaires. Seule l’instance d’app pour laquelle il a été provisionné peut accéder à cet identifiant, et il est (relativement) facilement réinitialisable car il ne persiste que tant que l’app est installée.

En conséquence, les FID offrent de meilleures propriétés de confidentialité par rapport aux identifiants matériels non réinitialisables et adaptés aux appareils. Pour plus d’informations, consultez la référence de l’APIfirebase.installations.

Dans les cas où un FID n’est pas pratique, vous pouvez également utiliser des identifiants uniques mondiaux (GUID) personnalisés pour identifier de manière unique une instance d’application. La façon la plus simple de le faire est de générer votre propre GUID en utilisant le code suivant:

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

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

Parce 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 à la liaison de l’identifiant entre les apps,stockez les GUID dans le stockage interne plutôt que dans le stockage externe (partagé). Pour plus d’informations, consultez la page Aperçu du stockage des données et des fichiers.

Ne pas travailler avec les adresses MAC

Les adresses MAC sont uniques au monde, non réinitialisables par l’utilisateur et survivent aux réinitialisations d’usine. Pour ces raisons, afin de protéger la vie privée des utilisateurs, sur les versions 6 et plus d’Android, l’accès aux adresses MAC est limité aux apps système. Les apps tierces ne peuvent pas y accéder.

La disponibilité des adresses MAC change dans Android 11

Sur les apps ciblant Android 11 et plus, la randomisation MAC pour les réseaux Passpoint est par profil Passpoint, générant une adresse MAC unique basée sur les champs suivants :

• Nom de domaine entièrement qualifié (FQDN)
• Realm
• Crédentiel, basé sur le crédentiel utilisé dans le profil Passpoint :
  • Crédentiel utilisateur : nom d’utilisateur
  • Crédentiel certificat : cert et type de cert
  • Crédentiel SIM : Type EAP et IMSI

En outre, les applications non privilégiées ne peuvent pas accéder à l’adresse MAC du périphérique ; seules les interfaces réseau avec une adresse IP sont visibles. Cela a un impact sur les méthodesgetifaddrs()etNetworkInterface.getHardwareAddress(), ainsi que sur l’envoi de messages RTM_GETLINK Netlink.

Voici une liste des façons dont les apps sont affectées par ce changement :

• NetworkInterface.getHardwareAddress() renvoie null pour chaque interface.
• Les apps 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 devraient utiliser les API de plus haut niveau deConnectivityManager plutôt que des API de plus bas niveau commeNetworkInterface, getifaddrs(), ou les sockets Netlink. Par exemple, une application qui a besoin d’informations à jour sur les itinéraires en cours peut obtenir ces informations en écoutant les changements de réseau à l’aide de ConnectivityManager.registerNetworkCallback()et en appelant leLinkProperties.getRoutes() associé au réseau.

Caractéristiques de l’identifiant

Le système d’exploitation Android offre un certain nombre d’identifiants avec différentes caractéristiques de comportement.L’identifiant que vous devez 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 matière de confidentialité, cependant, il est donc important de comprendre comment ces caractéristiques interagissent les unes avec les autres.

Scope

La portée de l’identifiant explique quels systèmes peuvent accéder à l’identifiant. La portée de l’identifiant Android se décline généralement en trois saveurs :

• Application unique : L’identifiant est interne à l’app et n’est pas accessible aux autres apps.
• Groupe d’apps : L’identifiant est accessible à un groupe prédéfini d’apps liées.
• Appareil : L’identifiant est accessible à toutes les apps installées sur l’appareil.

Plus la portée accordée à un identifiant est large, plus le risque qu’il soit utilisé à des fins de traçage est important. Inversement, si un identifiant ne peut être consulté que par une seule instance d’app, il ne peut pas être utilisé pour suivre un appareil à travers des transactions dans différentes apps.

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 comprennent : les réinitialisations in-app, 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 seulement : Un nouvel identifiant est utilisé chaque fois que l’utilisateur redémarre l’application.
• Install-reset : Un nouvel ID est utilisé chaque fois que l’utilisateur désinstalle et réinstalle l’app.
• FDR-reset : Un nouvel ID est utilisé chaque fois que l’utilisateur réinitialise l’appareil en usine.
• FDR-persistant : L’ID survit à la réinitialisation en usine.

La réinitialisation donne aux utilisateurs la possibilité de créer un nouvel ID dissocié de toute information de profil existante. Plus un identifiant persiste longtemps, et de manière fiable, comme un identifiant qui persiste à travers les réinitialisations d’usine, plus le risque que l’utilisateur soit soumis à un suivi à long terme est important. Si l’identifiant est réinitialisé lors de la réinstallation de l’app, cela réduit la persistance et fournit un moyen pour l’ID d’être réinitialisé, même s’il n’y a pas de contrôle explicite de l’utilisateur pour le réinitialiser à partir de l’app ou des paramètres du système.

Unicité

L’unicité établit la probabilité de collisions, c’est-à-dire que des identifiants identiques existent dans la portée associée. Au niveau le plus élevé, un identifiant globalement unique n’a jamais de collision, même sur d’autres appareils ou apps.Sinon, le niveau d’unicité dépend de l’entropie de l’identifiant et de la source d’aléa utilisée pour le créer. Par exemple, le risque d’acollision est beaucoup plus élevé pour les identifiants aléatoires ensemencés avec la date calendaire de l’installation (comme 2019-03-01) que pour les identifiants ensemencés avec l’Unixtimestamp de l’installation (comme 1551414181).

En général, les identifiants de compte utilisateur peuvent être considérés comme uniques. C’est-à-dire que chaque combinaison périphérique/compte possède un identifiant unique. D’autre part, moins un identifiant est unique au sein d’une population, plus la protection de la vie privée est importante 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 à usurper ou à rejouer pour prouver que le dispositif ou le compte associé possède certaines propriétés. Par exemple, vous pouvez prouver que le dispositif n’est pas un dispositif virtuel utilisé par un spammeur.Les identifiants difficiles à usurper offrent également une non-répudiabilité. Si le dispositif signe un message avec une clé secrète, il est difficile de prétendre que le dispositif de quelqu’un d’autre a envoyé le message. La non-répudiabilité pourrait être quelque chose qu’un utilisateur veut, comme lors de l’authentification d’un paiement, ou ce pourrait être une propriété indésirable, comme lorsqu’ils envoient un message qu’ils regrettent.

Cas d’utilisation communs et l’identifiant approprié à utiliser

Cette section fournit des alternatives à l’utilisation des identifiants matériels, tels que l’IMEI. L’utilisation des identifiants matériels est déconseillée parce que l’utilisateur ne peut pas les réinitialiser et qu’ils sont rescopés à l’appareil. Dans de nombreux cas, un identifiant scopé à l’app suffirait.

Suivre les préférences des utilisateurs signés

Dans ce cas, vous sauvegardez l’état par appareil du côté serveur sans compte utilisateur.

Utiliser : FID ou GUID

Pourquoi cette recommandation ?

Perserver les informations à travers les réinstallations n’est pas recommandé parce que les utilisateurs peuvent vouloir réinitialiser leurs préférences en réinstallant l’app.

Suivre les préférences des utilisateurs signés entre les apps avec la même clé de signature

Dans ce cas, vous enregistrez l’état par appareil du côté du serveur et le transférez entre différentes apps qui sont signées avec la même clé sur le même appareil.

Utilisation : SSAID

Pourquoi cette recommandation ?

Dans Android 8.0 (niveau 26 de l’API) et plus, SSAID fournit un identifiant qui est commun entre les apps signées par la même clé de signature du développeur. Il permet de partager l’état entre ces apps sans exiger de l’utilisateur qu’il se connecte à un compte.

Suivre le comportement des utilisateurs signés

Dans ce cas, vous avez créé un profil d’un utilisateur basé sur son comportement à travers différentes apps/sessions sur le même appareil.

Utilisation : Advertising ID

Pourquoi cette recommandation ?

L’utilisation de l’Advertising ID est obligatoire pour les cas d’utilisation de la publicité selon la GooglePlay Developer ContentPolicy car l’utilisateur peut le réinitialiser.

Générer des analyses d’utilisateurs signés ou anonymes

Dans ce cas, vous mesurez les statistiques d’utilisation et les analyses pour les utilisateurs signés ou anonymes.

Utilisation : FID, ou un GUID si un FID est insuffisant

Pourquoi cette recommandation ?

Un FID ou un GUID est scopé à l’app qui le crée, ce qui empêche l’identifiant d’être utilisé pour suivre les utilisateurs entre les apps. Il est également facilement réinitialisable, car l’utilisateur peut effacer les données de l’app ou réinstaller l’app. Le processus de création des FID et des GUID est simple :

• Retrouver un FID : voir le guide des installations Firebase.

• Création d’un GUID : Implémentez une logique dans votre application, comme indiqué dans le code suivant :

  Kotlin

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

  Java

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

Sachez que si vous avez dit à l’utilisateur que les données que vous collectez sontanonymes, vous devez vous assurer que vous ne connectez pas l’identifiant auxPII ou à d’autres identifiants qui pourraient être liés aux PII.

Vous pouvez également utiliser Google Analytics for MobileApps, qui offre une solution pour l’analyse par application.

Suivre les conversions d’utilisateurs signés

Dans ce cas, vous suivez les conversions pour détecter si votre stratégie marketing est réussie.

Utilisation : Advertising ID

Pourquoi cette recommandation ?

Il s’agit d’un cas d’utilisation lié aux publicités qui pourrait nécessiter un ID qui est disponible à travers différentes applications, donc l’utilisation d’un Advertising ID est la solution la plus appropriée.

Gérer les installations multiples sur différents appareils

Dans ce cas, vous devez identifier la bonne instance de l’application lorsqu’elle est sinstallée sur plusieurs appareils pour le même utilisateur.

Utilisation : FID ou GUID

Pourquoi cette recommandation ?

Un FID est conçu explicitement à cette fin ; sa portée est limitée à l’app de sorte qu’il ne peut pas être utilisé pour suivre les utilisateurs à travers différentes apps, et il est réinitialisé lors de la réinstallation de l’app. Dans les rares cas où un FID estinsuffisant, vous pouvez également utiliser un GUID.

Associer une fonctionnalité à des abonnements de services mobiles

Dans ce cas, vous devez associer une fonctionnalité de l’app à 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’app en fonction des abonnements mobiles de l’appareil via la carte SIM.

Utilisation : IDAPI d’abonnement pour identifier les cartes SIM qui sont utilisées sur l’appareil.

L’ID d’abonnement fournit une valeur d’index (commençant à 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 d’abonnement pour un SIM donné. Cette valeur est stable pour une carte SIM donnée, sauf si l’appareil est réinitialisé en usine. Cependant, il peut y avoir des cas où le mêmeSIM a un ID d’abonnement différent sur différents appareils ou différents SIM ont le même ID sur différents appareils.Si l’ID d’abonnement n’est pas suffisammentunique, il est recommandé de concaténer l’ID d’abonnement avec le SSAID.

Pourquoi cette recommandation ?

Certaines apps peuvent actuellement utiliser l’ICCID à cette fin. Parce que l’ID ICC est globalement unique et non réinitialisable, l’accès a été restreint aux apps avec la READ_PRIVILEGED_PHONE_STATEpermission depuis Android 10. À partir d’Android 11, Google a restreint davantage l’accès à l’ICCID par l’intermédiaire de l’API getIccId(), quel que soit le niveau d’API cible de l’application. Les applications concernées doivent migrer vers l’ID d’abonnement à la place.

Anti-fraude : Faire respecter les limites de contenu gratuit et détecter les attaques Sybil

Dans ce cas, vous voulez limiter le nombre de contenu gratuit, comme les articles,qu’un utilisateur peut voir sur un appareil.

Utilisation : FID ou GUID. Sur Android 8.0 (niveau 26 de l’API) et plus, SSAID est également une option, car il est scopé à la clé de signature de l’app.

Pourquoi cette recommandation ?

L’utilisation d’un GUID ou d’un FID oblige l’utilisateur à réinstaller l’app afin de contourner les limites de contenu, ce qui est une charge suffisante pour dissuader la plupart des gens. Si ce n’est pas une protection suffisante, Android fournit une DRMAPI, qui peut être utilisée pour limiter l’accès au contenu, comprend un identifiant par APK, le Widevine ID.

Fonctionnalité de l’opérateur

Dans ce cas, votre app interagit avec le téléphone de l’appareil et la fonctionnalité de texto en utilisant un compte d’opérateur.

Utilisation : IMEI, IMSI et Line1

Pourquoi cette recommandation ?

L’exploitation des identifiants matériels est acceptable si elle est nécessaire pour la fonctionnalité liée à l’opérateur. Par exemple, vous pourriez utiliser ces identifiants pour commuter entre les opérateurs cellulaires ou les emplacements SIM, ou pour délivrer des messages SMS sur IP (pour la ligne1) – comptes utilisateurs basés sur la SIM. Pour les applications non privilégiées, cependant, nous recommandons d’utiliser une ouverture de session de compte pour récupérer les informations du dispositif de l’utilisateur côté serveur. L’une des raisons en est que, dans Android 6.0 (niveau 23 de l’API) et plus, ces identifiants ne peuvent être utilisés que par le biais d’une autorisation d’exécution. Les utilisateurs peuvent désactiver cette permission, votre application doit donc gérer ces exceptions de manière gracieuse.

Détection des abus : Identifier les bots et les attaques DDoS

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

Utilisation : l’API SafetyNet

Pourquoi cette recommandation ?

Un identifiant isolé ne fait pas grand-chose pour indiquer qu’un appareil est authentique. Vous pouvez vérifier qu’une requête provient d’un véritable appareil Android – par opposition à un émulateur ou à un autre code usurpant un autre appareil – en utilisant la méthodeattest()de l’API SafetyNet pour vérifier l’intégrité d’un appareil effectuant une requête. Pour des informations plus détaillées, consultez la documentation de l’API SafetyNet.

Détection des fraudes et des abus : Détection d’informations d’identification volées de grande valeur

Dans ce cas, vous essayez de détecter si un seul dispositif est utilisé plusieurs fois avec des informations d’identification volées de grande valeur, par exemple pour effectuer des paiements frauduleux.

Utilisation : De par sa nature, la prévention de la fraude nécessite des signaux propriétaires qui peuvent changer au fil du temps et sont donc hors de portée de ce document. Cependant, notez que les identifiants matériels, tels que IMEI et IMSI, peuvent facilement être modifiés sur des appareils enracinés ou émulés, ils ne sont donc pas des indicateurs fiables de fraude.