Best practices voor unieke identifiers

Dit document biedt richtlijnen voor het selecteren van de juiste identifiers voor uw app op basis van uw use case.

Voor een algemene blik op Android-machtigingen, zie Machtigingenoverzicht. Voor specifieke best practices voor het werken met Android-machtigingen, zie Best practices voor app-machtigingen.

Best practices voor het werken met Android-identifiers

Wanneer u werkt met Android-identifiers, volgt u deze best practices:

1. Vermijd het gebruik van hardware-identifiers. In de meeste gevallen kunt u het gebruik van hardware-identifiers, zoals SSAID (Android ID), vermijden zonder de vereiste functionaliteit te beperken.

   Android 10 (API-niveau 29) voegt beperkingen toe voor niet-resettable identifiers, die zowel IMEI als serienummer omvatten. Uw app moet een app voor apparaat- of bestandseigenaar zijn, speciale machtigingen van de provider hebben of beschikken over de geprivilegieerde READ_PRIVILEGED_PHONE_STATE-toestemming om toegang te krijgen tot deze identificatiecodes.

2. Gebruik een reclame-ID alleen voor gebruikersprofilering of gebruik van advertenties. Respecteer bij het gebruik van een advertentie-ID altijd de selecties van gebruikers met betrekking tot het volgen van advertenties. Zorg er ook voor dat de identificatiecode niet kan worden gekoppeld aan persoonlijk identificeerbare informatie (PII) en voorkom dat advertentie-ID’s worden overbrugd.

3. Gebruik waar mogelijk een Firebase-installatie-ID (FID) of een privé opgeslagen GUID voor alle andere gebruikssituaties, behalve voor betalingsfraudepreventie en telefonie. Voor de overgrote meerderheid van de gevallen waarin geen gebruik wordt gemaakt van advertenties, zou een FID of GUID voldoende moeten zijn.

4. Gebruik API’s die geschikt zijn voor uw gebruikssituatie om het privacyrisico tot een minimum te beperken. Gebruik de DRM API voor de bescherming van hoogwaardige inhoud en de SafetyNet API’s voor de bescherming tegen misbruik. De SafetyNet API’s zijn de eenvoudigste manier om vast te stellen of een apparaat echt is zonder privacyrisico’s te lopen.

De resterende secties van deze handleiding gaan dieper in op deze regels in de context van het ontwikkelen van Android-apps.

Werken met reclame-ID’s

De reclame-ID is een door de gebruiker instelbare identificatiecode en is geschikt voor reclamegebruiksgevallen. Er zijn echter enkele belangrijke punten die u in gedachten moet houden wanneer u dezeID gebruikt:

Respecteer altijd de intentie van de gebruiker bij het resetten van de reclame-ID.Overbrug het resetten van de gebruiker niet door een andere identificatiecode of vingerafdruk te gebruiken om opeenvolgende reclame-ID’s aan elkaar te koppelen zonder toestemming van de gebruiker. In het inhoudsbeleid voor ontwikkelaars van Google Play staat het volgende:

“…een nieuwe reclame-identifier mag na het resetten niet worden gekoppeld aan een eerdere reclame-identifier of aan gegevens die zijn afgeleid van een eerdere reclame-identifier zonder de uitdrukkelijke toestemming van de gebruiker.”

Respecteer altijd de bijbehorende vlag voor gepersonaliseerde advertenties. Reclame-id’s kunnen zo worden geconfigureerd dat gebruikers de hoeveelheid tracking kunnen beperken die aan de id is gekoppeld. Gebruik altijd de AdvertisingIdClient.Info.isLimitAdTrackingEnabled()-methode om ervoor te zorgen dat u de wensen van uw gebruikers niet omzeilt. In het inhoudsbeleid van de GooglePlay-ontwikkelaar staat het volgende:

“…moet u zich houden aan de instelling van een gebruiker voor ‘Opt-out van op interesses gebaseerde advertenties’ of ‘Opt-out van advertentiepersonalisatie’. Als een gebruiker deze instelling heeft ingeschakeld, mag u de advertentie-id niet gebruiken voor het maken van gebruikersprofielen voor reclamedoeleinden of voor het targeten van gebruikers met gepersonaliseerde reclame. Toegestane activiteiten zijn onder andere contextuele reclame, frequentietoewijzing, conversietracking, rapportage en beveiligings- en fraudedetectie.”

Let op eventuele beleidsregels met betrekking tot privacy of beveiliging die zijn gekoppeld aan SDK’s die u gebruikt en die verband houden met het gebruik van advertentie-id.Als u bijvoorbeeld true doorgeeft aan de methodeenableAdvertisingIdCollection() van de Google Analytics SDK, moet u alle toepasselijke Analytics SDK-beleidslijnen doornemen en naleven.

Ook moet u zich ervan bewust zijn dat de Google Play Developer Content Policy vereist dat de Advertising ID “niet mag worden gekoppeld aan persoonlijk identificeerbare informatie of in verband mag worden gebracht met een persistente apparaatidentificatie (bijvoorbeeld: SSAID, MAC-adres, IMEI, enz…),).”

Als voorbeeld, stel dat u informatie wilt verzamelen om databasetabellen te vullen met de volgende kolommen:

In dit voorbeeld, zou de kolom ad_id via de kolom account_id in beide tabellen kunnen worden gekoppeld aan PII, wat een schending zou zijn van het ontwikkelaarsbeleid voor Google Play-inhoud, als u geen expliciete toestemming van uw gebruikers hebt gekregen.

Bedenk dat de links tussen adverteerders-ID en PII niet altijd zo expliciet zijn. Het is mogelijk “quasi-identifiers” te hebben die zowel in PII- als in Ad-ID-tabellen voorkomen, wat ook problemen oplevert. Stel bijvoorbeeld dat weTABLE-01 en TABLE-02 als volgt wijzigen:

In dit geval, met voldoende zeldzame klikgebeurtenissen is het nog steeds mogelijk om met behulp van de tijdstempel van de gebeurtenis en het apparaatmodel een verbinding tot stand te brengen tussen de adverteerders-ID TABLE-01 en de PII in TABLE-02.

Hoewel het vaak moeilijk is te garanderen dat er geen dergelijke quasi-identifiers in een dataset bestaan, kunt u de meest voor de hand liggende join-risico’s voorkomen door waar mogelijk unieke gegevens te generaliseren. In het voorgaande voorbeeld zou dit betekenen dat de nauwkeurigheid van de tijdstempel moet worden verminderd, zodat voor elke tijdstempel meerdere apparaten met hetzelfde model voorkomen.

Andere oplossingen zijn onder meer de volgende:

• Geen tabellen ontwerpen die PII expliciet koppelen aan reclame-ID’s. In het eerste voorbeeld hierboven zou dit betekenen dat de kolom account_id niet in TABLE-01 wordt opgenomen.

• Toegangscontrolelijsten voor gebruikers of rollen die toegang hebben tot zowel de belangrijkste reclame-ID-gegevens als PII, scheiden en bewaken. Door de mogelijkheid om beide bronnen tegelijk te benaderen (bijvoorbeeld door een join tussen tabellen uit te voeren) strikt te controleren en te auditen, vermindert u het risico van associatie tussen de reclame-ID en de PII. In het algemeen betekent toegangscontrole het volgende:

  1. Toegangscontrolelijsten (ACL’s) voor advertentie-ID-sleutelgegevens en PII-samenvoegen om het aantal personen of rollen dat in beide ACL’s voorkomt zo klein mogelijk te houden.
  2. Toegangslogging en -auditing implementeren om eventuele uitzonderingen op deze regel op te sporen en te beheren.

Voor meer informatie over het verantwoord werken met advertentie-ID’s, zie deAdvertisingIdClient API-referentie.

Werken met FID’s en GUID’s

De meest eenvoudige oplossing voor het identificeren van een app-instantie die op een apparaat draait, is het gebruik van een Firebase-installatie-ID (FID), en dit is de aanbevolen oplossing in de meerderheid van de niet-ads-gebruiksgevallen. Alleen de app-instantie waarvoor het werd verstrekt, heeft toegang tot deze identificatiecode, en het is (relatief) gemakkelijk te resetten omdat het alleen blijft bestaan zolang de app is geïnstalleerd.

Als gevolg hiervan bieden FID’s betere privacy-eigenschappen in vergelijking met niet-resetbare, apparaat-gedefinieerde hardware-ID’s. Zie voor meer informatie defirebase.installationsAPI reference.

In gevallen waarin een FID niet praktisch is, kunt u ook customglobally-unique ID’s (GUID’s) gebruiken om een app-instantie uniek te identificeren. De eenvoudigste manier om dit te doen is door uw eigen GUID te genereren met de volgende code:

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

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

Omdat de identifier globaal uniek is, kan deze worden gebruikt om een specifieke app-instantie te identificeren. Om problemen met het koppelen van de identifier tussen apps te voorkomen, moeten GUID’s in interne opslag worden opgeslagen in plaats van in externe (gedeelde) opslag. Zie voor meer informatie de overzichtspagina over gegevens- en bestandsopslag.

Werk niet met MAC-adressen

MAC-adressen zijn wereldwijd uniek, kunnen niet door de gebruiker worden gewijzigd en overleven fabrieksresets. Om deze redenen, en om de privacy van de gebruiker te beschermen, is op Android versies 6 en hoger, de toegang tot MAC-adressen beperkt tot systeem apps. Derden-apps kunnen geen toegang krijgen.

De beschikbaarheid van MAC-adressen verandert in Android 11

Op apps die zich richten op Android 11 en hoger, is de MAC-randomisering voor Passpoint-netwerken per Passpoint-profiel, waarbij een uniek MAC-adres wordt gegenereerd op basis van de volgende velden:

• Volledig gekwalificeerde domeinnaam (FQDN)
• Realm
• Credential, gebaseerd op de in het Passpoint-profiel gebruikte credential:
  • User-credential: gebruikersnaam
  • Certificaat-credential: cert en cert-type
  • SIM-credential: EAP type en IMSI

Daarnaast hebben apps die geen privileges hebben geen toegang tot het MAC adres van het apparaat; alleen netwerk interfaces met een IP adres zijn zichtbaar. Dit heeft gevolgen voor degetifaddrs()enNetworkInterface.getHardwareAddress()methoden, evenals voor het verzenden van RTM_GETLINK Netlink-berichten.

Hieronder volgt een lijst van de manieren waarop apps worden beïnvloed door deze wijziging:

• NetworkInterface.getHardwareAddress() retourneert null voor elke interface.
• Apps kunnen de bind() functie niet gebruiken op NETLINK_ROUTE sockets.
• Het ip commando geeft geen informatie over interfaces.
• Apps kunnen geen RTM_GETLINK berichten versturen.

Merk op dat de meeste ontwikkelaars de API’s op hoger niveau vanConnectivityManager zouden moeten gebruiken in plaats van API’s op lager niveau zoalsNetworkInterface,getifaddrs(), of Netlink sockets. Een app die bijvoorbeeld actuele informatie over de huidige routes nodig heeft, kan deze informatie krijgen door te luisteren naar netwerkwijzigingen met ConnectivityManager.registerNetworkCallback() en de bijbehorendeLinkProperties.getRoutes() van het netwerk aan te roepen.

Identifier-kenmerken

Het Android OS biedt een aantal ID’s met verschillende gedragskenmerken.Welke ID u moet gebruiken, hangt af van hoe de volgende kenmerken werken met uw gebruikssituatie. Deze kenmerken komen ook met privacy implicaties, echter, dus het is belangrijk om te begrijpen hoe deze kenmerken op elkaar inwerken.

Scope

Het bereik van de identifier legt uit welke systemen toegang hebben tot de identifier. Android-identifierbereik komt over het algemeen in drie smaken:

• Enkelvoudige app: De ID is intern aan de app en niet toegankelijk voor andere apps.
• Groep van apps: De ID is toegankelijk voor een vooraf gedefinieerde groep van gerelateerde apps.
• Apparaat: De ID is toegankelijk voor alle apps die op het apparaat zijn geïnstalleerd.

Hoe breder de reikwijdte die aan een identifier wordt toegekend, hoe groter het risico dat deze wordt gebruikt voor trackingdoeleinden. Omgekeerd, als een identifier alleen toegankelijk is voor een enkele app-instantie, kan deze niet worden gebruikt om een apparaat te volgen bij transacties in verschillende apps.

Herzetbaarheid en persistentie

Herzetbaarheid en persistentie bepalen de levensduur van de identifier en leggen uit hoe deze kan worden gereset. Veel voorkomende reset triggers zijn: in-app resets, resets via systeeminstellingen, resets bij lancering, en resets bij installatie. Android-identifiers kunnen verschillende levensduren hebben, maar de levensduur is meestal gerelateerd aan de manier waarop de ID wordt gereset:

• Session-only: Een nieuwe ID wordt gebruikt elke keer dat de gebruiker de app opnieuw start.
• Install-reset: Telkens wanneer de gebruiker de app verwijdert en opnieuw installeert, wordt een nieuw ID gebruikt.
• FDR-reset: Een nieuwe ID wordt gebruikt elke keer dat de gebruiker de fabriek reset van het apparaat.
• FDR-persistent: De ID overleeft fabrieksreset.

Resettability geeft gebruikers de mogelijkheid om een nieuwe ID te maken die los staat van alle bestaande profielinformatie. Hoe langer en betrouwbaarder een identificatiecode blijft bestaan, zoals een code die in de fabriek wordt teruggezet, des te groter is het risico dat de gebruiker op lange termijn kan worden gevolgd. Als de identifier wordt gereset bij het opnieuw installeren van een app, vermindert dit de persistentie en biedt het een middel om de ID te resetten, zelfs als er geen expliciete gebruikerscontrole is om het vanuit de app of de systeeminstellingen te resetten.

Uniqueness

Uniqueness bepaalt de waarschijnlijkheid van botsingen; dat wil zeggen, dat identieke identifiers bestaan binnen het geassocieerde bereik. Op het hoogste niveau heeft een globaal unieke identifier nooit een botsing, zelfs niet op andere apparaten of apps. Anders hangt het niveau van uniciteit af van de entropie van de identifier en de bron van willekeurigheid die gebruikt is om hem te maken. Bijvoorbeeld, de kans op een botsing is veel hoger voor willekeurige identifiers seeded met de kalenderdatum van installatie (zoals 2019-03-01) dan voor identifiers seeded met de Unixtimestamp van installatie (zoals 1551414181).

In het algemeen kunnen gebruikersaccount-identifiers als uniek worden beschouwd. Dat wil zeggen, elke apparaat/account combinatie heeft een unieke ID. Aan de andere kant, hoe minder uniek een identifier is binnen een populatie, hoe groter de privacybescherming, omdat het minder nuttig is voor het volgen van een individuele gebruiker.

Integriteitsbescherming en onweerlegbaarheid

U kunt een identifier gebruiken die moeilijk te spoofen of na te spelen is om te bewijzen dat het gekoppelde apparaat of account bepaalde eigenschappen heeft. U kunt bijvoorbeeld bewijzen dat het apparaat geen virtueel apparaat is dat door een spammer wordt gebruikt. Moeilijk te spoofen identifiers bieden ook onweerlegbaarheid. Als het apparaat een bericht ondertekent met een geheime sleutel, is het moeilijk te beweren dat het bericht door iemand anders is verzonden. Onweerlegbaarheid kan iets zijn wat een gebruiker wil, zoals bij de authenticatie van een betaling, of het kan een ongewenste eigenschap zijn, zoals wanneer ze een bericht versturen waar ze spijt van hebben.

Common use cases and the appropriate identifier to use

Dit gedeelte geeft alternatieven voor het gebruik van hardware-ID’s, zoals IMEI. Het gebruik van hardware-ID’s wordt ontmoedigd omdat de gebruiker ze niet kan resetten, en ze rescoped naar het apparaat. In veel gevallen zou een app-scoped identifier volstaan.

Track signed-out user preferences

In dit geval, slaat u per-apparaat staat op de server kant zonder een gebruikersaccount.

Gebruik: FID of GUID

Waarom deze aanbeveling?

Het bewaren van informatie via herinstallaties wordt niet aanbevolen omdat gebruikers mogelijk hun voorkeuren opnieuw willen instellen door de app opnieuw te installeren.

Traceer afgemelde gebruikersvoorkeuren tussen apps met dezelfde ondertekeningssleutel

In dit geval slaat u per-apparaattoestand op de server op en brengt u deze over tussen verschillende apps die zijn ondertekend met dezelfde sleutel op hetzelfde apparaat.

Gebruik: SSAID

Waarom deze aanbeveling?

In Android 8.0 (API-niveau 26) en hoger, SSAID biedt een identifier die gemeenschappelijk is tussen apps ondertekend door dezelfde ontwikkelaar signeer sleutel. Hiermee kunt u de status tussen deze apps delen zonder dat de gebruiker zich hoeft aan te melden bij een account.

Gedrag van uitgeschreven gebruikers volgen

In dit geval hebt u een profiel van een gebruiker gemaakt op basis van zijn gedrag in verschillende apps/sessies op hetzelfde apparaat.

Gebruik: Advertentie-ID

Waarom deze aanbeveling?

Gebruik van de Advertentie-ID is verplicht voor advertentiegebruik volgens de GooglePlay Developer Content Policy, omdat de gebruiker deze kan resetten.

Genereer afgemelde of anonieme gebruikersanalyses

In dit geval meet u gebruiksstatistieken en analyses voor afgemelde of anonieme gebruikers.

Gebruik: FID, of een GUID als een FID onvoldoende is

Waarom deze aanbeveling?

Een FID of GUID is beperkt tot de app die hem maakt, waardoor wordt voorkomen dat de identifier kan worden gebruikt om gebruikers in verschillende apps te volgen. Het is ook gemakkelijk te resetten, omdat de gebruiker app-gegevens kan wissen of de app opnieuw kan installeren. Het proces van het aanmaken van FID’s en GUID’s is rechttoe rechtaan:

• Halen van een FID: Zie de Firebase installatiegids.

• Een GUID maken: implementeer logica in uw app, zoals in het volgende codefragment wordt getoond:

  Kotlin

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

  Java

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

Ben u ervan bewust dat als u de gebruiker hebt verteld dat de gegevens die u verzamelt anoniem zijn, u ervoor moet zorgen dat u de identifier niet koppelt aanPII of andere identifiers die kunnen worden gekoppeld aan PII.

U kunt ook Google Analytics for MobileApps gebruiken, dat een oplossing biedt voor analytics per app.

Track signed-out user conversions

In dit geval volgt u conversies om te detecteren of uw marketingstrategie succesvol is.

Gebruik: Advertentie-ID

Waarom deze aanbeveling?

Dit is een advertentie-gerelateerde use-case waarvoor mogelijk een ID nodig is die beschikbaar is voor verschillende apps, dus het gebruik van een advertentie-ID is de meest geschikte oplossing.

Hanteer meerdere installaties op verschillende apparaten

In dit geval moet u de juiste instantie van de app identificeren wanneer deze op meerdere apparaten voor dezelfde gebruiker is geïnstalleerd.

Gebruik: FID of GUID

Waarom deze aanbeveling?

Een FID is expliciet voor dit doel ontworpen; de reikwijdte ervan is beperkt tot de app, zodat deze niet kan worden gebruikt om gebruikers over verschillende apps te volgen, en deze wordt gereset wanneer de app opnieuw wordt geïnstalleerd. In de zeldzame gevallen waarin een FID niet volstaat, kunt u ook een GUID gebruiken.

Functionaliteit koppelen aan abonnementen voor mobiele diensten

In dit geval moet u app-functionaliteit koppelen aan bepaalde abonnementen voor mobiele diensten op het apparaat. U kunt bijvoorbeeld de toegang tot bepaalde premium app-functies afhankelijk willen maken van de mobiele abonnementen van het apparaat via SIM.

Gebruik: Subscription IDAPI om SIM’s te identificeren die op het apparaat worden gebruikt.

De Subscription ID levert een indexwaarde (beginnend bij 1) voor de unieke identificatie van geïnstalleerde SIM’s (inclusief fysieke en elektronische) die op het apparaat worden gebruikt. Via deze ID kan uw app zijn functionaliteit koppelen aan verschillende abonnementsinformatie voor een bepaalde SIM. Deze waarde is stabiel voor een bepaalde SIM, tenzij het toestel in de fabriek wordt gereset. Het kan echter voorkomen dat dezelfde SIM op verschillende apparaten een verschillende Subscription ID heeft of dat verschillende SIM’s op verschillende apparaten dezelfde ID hebben. Als de Subscription ID niet voldoende uniek is, wordt aanbevolen om de Subscription ID aan te laten sluiten op de SSAID.

Waarom deze aanbeveling?

Sommige apps gebruiken momenteel wellicht de ICCID voor dit doeleinde. Omdat de ICCID wereldwijd uniek is en niet kan worden gereset, is de toegang sinds Android 10 beperkt tot apps met READ_PRIVILEGED_PHONE_STATEtoestemming. Vanaf Android 11 heeft Google de toegang tot de ICCID verder beperkt via de getIccId()API, ongeacht het doel-API-niveau van de app. Getroffen apps moeten migreren naar de Subscription ID in plaats daarvan.

Anti-fraude: Het afdwingen van gratis content limieten en het opsporen van Sybil-aanvallen

In dit geval wilt u het aantal gratis content, zoals artikelen, dat een gebruiker kan zien op een apparaat beperken.

Gebruik: FID of GUID. Op Android 8.0 (API-niveau 26) en hoger, SSAID is ook een optie, omdat het is scoped naar de app-signing key.

Waarom deze aanbeveling?

Het gebruik van een GUID of FID dwingt de gebruiker om de app opnieuw te installeren om de inhoudslimieten te omzeilen, dat is een voldoende last om de meeste mensen af te schrikken. Als dit niet voldoende bescherming is, Android biedt een DRMAPI, die kan worden gebruikt om de toegang tot inhoud te beperken, omvat een per-APK identifier, de Widevine ID.

Carrier functionaliteit

In dit geval, uw app is interactie met de telefoon van het apparaat en sms-functionaliteit met behulp van een carrier account.

Gebruik: IMEI, IMSI, en Line1

Waarom deze aanbeveling?

Het gebruik van hardware-identifiers is acceptabel als het nodig is voor carrier-gerelateerde functionaliteit. U kunt deze identifiers bijvoorbeeld gebruiken om te schakelen tussen mobiele carriers of SIM-slots, of om SMS-berichten via IP (voor Line1) af te leveren – SIM-gebaseerde gebruikersaccounts. Voor niet-geprivilegieerde apps raden we echter aan om een account sign-in te gebruiken om informatie over gebruikersapparaten server-side op te halen. Een van de redenen hiervoor is dat deze identifiers in Android 6.0 (API-niveau 23) en hoger alleen kunnen worden gebruikt via een runtime-toestemming. Gebruikers kunnen deze toestemming uitschakelen, dus uw app moet deze uitzonderingen netjes afhandelen.

Ontsporing van misbruik: Het identificeren van bots en DDoS-aanvallen

In dit geval probeert u meerdere nepapparaten te detecteren die uw backend-diensten aanvallen.

Gebruik: De SafetyNet API

Waarom deze aanbeveling?

Een identifier op zichzelf geeft weinig aan dat een apparaat echt is. U kunt controleren of een verzoek afkomstig is van een echt Android-toestel – in tegenstelling tot een simulator of andere code die een ander toestel nabootst – met de SafetyNet APIattest()-methode om de integriteit van een toestel dat een verzoek indient te controleren. Voor meer gedetailleerde informatie, zie de SafetyNet API documentatie.

Opsporing van fraude en misbruik: Detecting high-value stolen credentials

In dit geval probeert u te detecteren of een enkel apparaat meerdere malen wordt gebruikt met high-value, gestolen credentials, zoals om frauduleuze betalingen te doen.

Gebruik: Door zijn aard vereist fraudepreventie bedrijfseigen signalen die in de loop van de tijd kunnen veranderen en daarom buiten het bereik van dit document vallen. Merk echter op dat hardware-identifiers, zoals IMEI en IMSI, gemakkelijk kunnen worden gewijzigd op geëmuleerde of gewortelde apparaten, zodat ze geen betrouwbare indicatoren van fraude zijn.