Bedste praksis for unikke identifikatorer

Dette dokument indeholder vejledning til valg af passende identifikatorer til din app baseret på dit brugsscenarie.

For en generel gennemgang af Android-tilladelser, se Oversigt over tilladelser. For specifikke bedste praksis for arbejde med Android-tilladelser, se Bedste praksis for apptilladelser.

Bedste praksis for arbejde med Android-identifikatorer

Når du arbejder med Android-identifikatorer, skal du følge disse bedste praksis:

1. Undgå at bruge hardware-identifikatorer. I de fleste tilfælde kan du undgå at bruge hardwareidentifikatorer, f.eks. SSAID (Android ID), uden at begrænse den nødvendige funktionalitet.

   Android 10 (API-niveau 29) tilføjer restriktioner for ikke-fornybare identifikatorer, som omfatter både IMEI- og serienummer. Din app skal være en app, der ejer en enhed eller en profil, have særlige tilladelser fra en operatør eller have den privilegerede tilladelse READ_PRIVILEGED_PHONE_STATE for at få adgang til disse identifikatorer.

2. Brug kun et reklame-id til brug for brugerprofilering eller annoncer. Når du bruger et reklame-id, skal du altid respektere brugernes valg med hensyn til adtracking. Sørg også for, at identifikatoren ikke kan forbindes med personligt identificerbare oplysninger (PII), og undgå at overbrygge nulstilling af reklame-id.

3. Brug et Firebase-installations-id (FID) eller et privat gemt GUID, når det er muligt, til alle andre anvendelsestilfælde, undtagen til forebyggelse af betalingssvindel og telefoni. I langt de fleste tilfælde, hvor der ikke er tale om annoncering, bør et FID eller GUID være tilstrækkeligt.

4. Brug API’er, der er egnede til dit brugsscenarie, for at minimere risikoen for privatlivets fred. Brug DRM-API’en til beskyttelse af indhold af høj værdi og SafetyNet-API’erne til beskyttelse mod misbrug. SafetyNet API’erne er den nemmeste måde at afgøre, om en enhed er ægte uden at løbe en risiko for privatlivets fred.

De resterende afsnit i denne vejledning uddyber disse regler i forbindelse med udvikling af Android-apps.

Arbejd med reklame-id’er

Reklame-id’et er en identifikator, der kan genindstilles af brugeren, og er velegnet til brug i forbindelse med reklamer. Der er dog nogle vigtige punkter, som du skal være opmærksom på, når du bruger detteID:

Respekter altid brugerens hensigt med at nulstille reklame-ID’et.Brug ikke brugernes nulstilling ved at bruge en anden identifikator eller et fingeraftryk til at sammenkoble efterfølgende reklame-ID’er uden brugerens samtykke. I Google Play Developer ContentPolicy står der følgende:

“…hvis den nulstilles, må en ny reklameidentifikator ikke forbindes med en tidligere reklameidentifikator eller data afledt af en tidligere reklameidentifikator uden brugerens udtrykkelige samtykke.”

Respekter altid det tilknyttede Flag for personaliserede annoncer. Reklame-id’er erkonfigurerbare, idet brugerne kan begrænse mængden af sporing, der er knyttet til id’et. Brug altid AdvertisingIdClient.Info.isLimitAdTrackingEnabled()metoden for at sikre, at du ikke omgår dine brugeres ønsker. I GooglePlay Developer ContentPolicy står der følgende:

“…du skal overholde en brugers indstilling ‘Fravalg af interessebaseret annoncering’ eller ‘Fravalg af personalisering af annoncer’. Hvis en bruger har aktiveret denne indstilling, må du ikke bruge reklameidentifikatoren til at oprette brugerprofiler til reklameformål eller til at målrette brugere med personliggjort reklame.Tilladte aktiviteter omfatter kontekstuel reklame, frekvensbegrænsning, konverteringssporing, rapportering og sikkerheds- og bedrageridetektion.”

Vær opmærksom på eventuelle politikker om beskyttelse af personlige oplysninger eller sikkerhed i forbindelse med SDK’er, du bruger, som er relateret til brug af reklame-id.Hvis du f.eks. indsætter i enableAdvertisingIdCollection()metoden fra Google Analytics SDK, skal du sørge for at gennemgå og overholde alle gældende Analytics SDK-politikker.

Du skal også være opmærksom på, at Google Play Developer ContentPolicy kræver, at reklame-id’et “ikke må forbindes med personligt identificerbare oplysninger eller være forbundet med en vedvarende enhedsidentifikator (f.eks. SSAID, MAC-adresse, IMEI osv.),).”

Som et eksempel kan du antage, at du ønsker at indsamle oplysninger til at udfylde databasetabeller med følgende kolonner:

I dette eksempel, ad_id-kolonnen kunne sammenkædes med PII via account_id-kolonnen i begge tabeller, hvilket ville være en overtrædelse af Google Play DeveloperContent Policy, hvis du ikke har fået udtrykkelig tilladelse fra dine brugere.

Husk, at forbindelser mellem annoncør-ID og PII ikke altid er så eksplicitte. Det er muligt at have “kvasi-identifikatorer”, der vises i både PII- og Annoncør-ID-tabeller med nøgle, hvilket også skaber problemer. Lad os f.eks. antage, at vi ændrerTABLE-01 og TABLE-02 på følgende måde:

I dette tilfælde, med tilstrækkeligt sjældne klikbegivenheder er det stadig muligt at sammenføje annoncør-id’et TABLE-01 og PII’en i TABLE-02 ved hjælp af begivenhedens tidsstempel og enhedsmodellen.

Og selv om det ofte er vanskeligt at garantere, at der ikke findes sådanne kvasi-identifikatorer i et datasæt, kan man forhindre de mest åbenlyse risici ved at generalisere unikke data, hvor det er muligt. I det foregående eksempel ville dette betyde at reducere nøjagtigheden af tidsstemplet, så flere enheder med samme model optræder for hvert tidsstempel.

Andre løsninger omfatter følgende:

• Ingen tabeller, der eksplicit forbinder PII med reklame-id’er, må udformes. I det første eksempel ovenfor ville det betyde, at man ikke medtager kolonnen account_id i TABLE-01.

• Segregering og overvågning af adgangskontrollister for brugere eller roller, der har adgang til både reklameid-nøgledata og PII.Ved at kontrollere og auditere muligheden for at få adgang til begge kilder samtidigt (f.eks. ved at udføre et join mellem tabeller) reducerer du risikoen for tilknytning mellem reklameid og PII. Generelt betyder adgangskontrol følgende:

  1. Hold adgangskontrollister (ACL’er) for Annoncør-id-nøgledata og PII adskilt for at minimere antallet af personer eller roller, der er i begge ACL’er.
  2. Indsæt adgangslogning og auditering for at opdage og administrere eventuelle undtagelser til denne regel.

For yderligere oplysninger om at arbejde ansvarligt med reklame-id’er henvises tilAdvertisingIdClient API-referencen.

Arbejd med FID’er og GUID’er

Den mest enkle løsning til identifikation af en appinstans, der kører på en enhed, er at bruge et Firebase-installations-id (FID), og dette er den anbefalede løsning i de fleste tilfælde, hvor der ikke anvendes reklamer. Kun den appinstans, som den blev leveret til, kan få adgang til denne identifikator, og den kan (relativt) let ændres, fordi den kun eksisterer, så længe appen er installeret.

Som følge heraf giver FID’er bedre fortrolighedsegenskaber sammenlignet med hardware-id’er, der kan nulstilles, og som er begrænset til enheden. Du kan finde flere oplysninger i firebase.installationsAPI-referencen.

I tilfælde, hvor et FID ikke er praktisk, kan du også bruge bruger tilpassede globale unikke ID’er (GUID’er) til at identificere en appinstans entydigt. Den enkleste måde at gøre det på er ved at generere dit eget GUID ved hjælp af følgende kode:

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

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

Da identifikatoren er globalt unik, kan den bruges til at identificere en bestemt appinstans. For at undgå problemer i forbindelse med sammenkobling af identifikatoren på tværs af apps skal GUID’er gemmes i internt lager i stedet for eksternt (delt) lager. Du kan finde flere oplysninger på siden Oversigt over data- og filopbevaring.

Arbejd ikke med MAC-adresser

MAC-adresser er globalt unikke, kan ikke genindstilles af brugeren og overlever fabriksindstillinger. Af disse grunde er adgangen til MAC-adresser på Android-versioner 6 og højere begrænset til systemapps for at beskytte brugernes privatliv på Android-versioner 6 og højere. Tredjepartsapps kan ikke få adgang til dem.

MAC-adressetilgængelighed ændres i Android 11

På apps, der er rettet mod Android 11 og højere, er MAC-randomisering for Passpointnetværk pr. Passpoint-profil, der genererer en unik MAC-adresse baseret på følgende felter:

• Fuldt kvalificeret domænenavn (FQDN)
• Realm
• Credential, baseret på den legitimationsoplysninger, der anvendes i Passpoint-profilen:
  • User credential: brugernavn
  • Certificate credential: cert og cert type
  • SIM credential: cert og cert type
  • SIM credential: brugernavn
  • Certificate credential: cert og cert type
  • SIM credential: cert og cert type: EAP-type og IMSI

Dertil kommer, at ikke-privilegerede apps ikke kan få adgang til enhedens MAC-adresse; kun netværksgrænseflader med en IP-adresse er synlige. Dette påvirker metodernegetifaddrs()ogNetworkInterface.getHardwareAddress() samt afsendelse af RTM_GETLINK Netlink-meddelelser.

Der følger en liste over de måder, som apps påvirkes af denne ændring:

• NetworkInterface.getHardwareAddress() returnerer null for alle grænseflader.
• Apps kan ikke bruge bind()-funktionen på NETLINK_ROUTE-socket’er.
• Kommandoen ip returnerer ikke oplysninger om grænseflader.
• Apps kan ikke sende RTM_GETLINK-meddelelser.

Bemærk, at de fleste udviklere bør bruge de højere API’er iConnectivityManager frem for API’er på lavere niveau somNetworkInterface,getifaddrs() eller Netlink-socket’er. En app, der f.eks. har brug for opdaterede oplysninger om de aktuelle ruter, kan få disse oplysninger ved at lytte efter netværksændringer ved hjælp af ConnectivityManager.registerNetworkCallback() og kalde netværkets tilknyttedeLinkProperties.getRoutes().

Identifikatorkarakteristika

Android OS tilbyder en række ID’er med forskellige adfærdskarakteristika.Hvilket ID du skal bruge afhænger af, hvordan følgende karakteristika fungerer i forhold til dit brugsscenarie. Disse egenskaber har dog også konsekvenser for privatlivets fred, så det er vigtigt at forstå, hvordan disse egenskaber interagerer med hinanden.

Spændvidde

Identifikatorens spændvidde forklarer, hvilke systemer der kan få adgang til identifikatoren. Androididentifikatorområde findes generelt i tre varianter:

• Enkelt app:
• Gruppe af apps: ID’et er tilgængeligt for en foruddefineret gruppe af relaterede apps.
• Enhed:

Jo større anvendelsesområde en identifikator får, desto større er risikoen for, at den anvendes til sporingsformål. Omvendt, hvis en identifikator kun kan tilgås af en enkelt appinstans, kan den ikke bruges til at spore en enhed på tværs af transaktioner i forskellige apps.

Resettabilitet og persistens

Resettabilitet og persistens definerer identifikatorens levetid og forklarer, hvordan den kan nulstilles. Almindelige udløsere for nulstilling omfatter: nulstilling i appen, nulstilling viaSystemindstillinger, nulstilling ved start og nulstilling ved installation. Androididentifikatorer kan have forskellige levetider, men levetiden er normalt relateret til, hvordan identifikatoren nulstilles:

• Session-only:
• nulstilling ved installation: Et nyt id bruges, hver gang brugeren genstarter appen:
• FDR-reset: Et nyt ID bruges, hver gang brugeren afinstallerer og geninstallerer appen.
• FDR-reset: Et nyt ID bruges hver gang brugeren afinstallerer og geninstallerer appen:
• FDR-persistent: Et nyt ID bruges, hver gang brugeren nulstiller enheden fra fabrikken.
• FDR-persistent: Et nyt ID bruges, hver gang brugeren nulstiller enheden fra fabrikken:

Resetabilitet giver brugerne mulighed for at oprette et nyt ID, som er adskilt fra alle eksisterende profiloplysninger. Jo længere og mere pålideligt en identifikator består, f.eks. en identifikator, der består på tværs af fabriksnulstillinger, jo større er risikoen for, at brugeren kan blive udsat for langtidssporing. Hvis identifikatoren nulstilles ved geninstallation af appen, reduceres persistensen og giver mulighed for at nulstille ID’et, selv om der ikke er nogen eksplicit brugerkontrol til at nulstille det fra appen eller systemindstillingerne.

Uniqueness

Uniqueness fastslår sandsynligheden for kollisioner, dvs. at der findes identiske identifikatorer inden for det tilknyttede anvendelsesområde. På det højeste niveau har en globalt unik identifikator aldrig en kollision, selv på andre enheder eller apps.Ellers afhænger niveauet af entropien af identifikatoren og den kilde til tilfældighed, der er anvendt til at oprette den. F.eks. er chancen for en kollision meget større for tilfældige identifikatorer, der er sat med kalenderdatoen for installationen (f.eks. 2019-03-01), end for identifikatorer, der er sat med Unixtimestampen for installationen (f.eks. 1551414181).

Generelt kan identifikatorer for brugerkonti betragtes som unikke. Det vil sige, at hver enhed/kontokombination har et unikt ID. På den anden side, jo mindre unik en identifikator er inden for en population, jo større er beskyttelsen af privatlivets fred, fordi den er mindre nyttig til at spore en individuel bruger.

Integritetsbeskyttelse og ikke-afviselighed

Du kan bruge en identifikator, der er vanskelig at forfalske eller genafspille, til at bevise, at den tilknyttede enhed eller konto har visse egenskaber. Du kan f.eks. bevise, at enheden ikke er en virtuel enhed, der bruges af en spammer.Identifikatorer, der er vanskelige at forfalske, giver også mulighed for ikke-afviselighed. Hvis enhederne signerer en meddelelse med en hemmelig nøgle, er det vanskeligt at hævde, at det er en anden enheds enhed, der har sendt meddelelsen. Ikke-afviselighed kan være noget, som en bruger ønsker, f.eks. ved autentificering af en betaling, eller det kan være en uønsket egenskab, f.eks. når de sender en meddelelse, som de fortryder.

Fælles anvendelsestilfælde og den passende identifikator til brug

Dette afsnit indeholder alternativer til brug af hardware-id’er, f.eks. IMEI. Det frarådes at bruge hardware-id’er, fordi brugeren ikke kan nulstille dem, og de er reskoperet til enheden. I mange tilfælde er det tilstrækkeligt med en identifikator, der er knyttet til en app.

Spore afmeldte brugerpræferencer

I dette tilfælde gemmer du tilstand pr. enhed på serversiden uden en brugerkonto.

Brug:

Hvorfor denne anbefaling?

Det anbefales ikke at bevare oplysninger gennem geninstallationer, da brugere måske ønsker at nulstille deres præferencer ved at geninstallere appen.

Spore udmeldte brugerpræferencer mellem apps med samme signeringsnøgle

I dette tilfælde gemmer du tilstand pr. enhed på serversiden og overfører den mellem forskellige apps, der er signeret med den samme nøgle på den samme enhed.

Brug: SSAID

Hvorfor denne anbefaling?

I Android 8.0 (API-niveau 26) og højere giver SSAID en identifikator, der er fælles for apps, der er signeret med den samme udviklersigneringsnøgle. Det giver dig mulighed for at dele tilstand mellem disse apps uden at brugeren skal logge på en konto.

Spore en udmeldt brugers adfærd

I dette tilfælde har du oprettet en profil for en bruger baseret på dennes adfærd på tværs af forskellige apps/sessioner på den samme enhed.

Brug:

Hvorfor denne anbefaling?

Brug af reklame-id’et er obligatorisk i forbindelse med brug af reklamer i henhold til GooglePlay Developer ContentPolicy, fordi brugeren kan nulstille det.

Generer analyser af afmeldte eller anonyme brugere

I dette tilfælde måler du brugsstatistikker og analyser for afmeldte eller anonyme brugere.

Brug: Brug: Du måler brugsstatistik og analyser for afmeldte eller anonyme brugere.

Brug: Du måler brugsstatistik og analyser af afmeldte eller anonyme brugere: FID eller et GUID, hvis et FID er utilstrækkeligt

Hvorfor denne anbefaling?

Et FID eller GUID er begrænset til den app, der opretter det, hvilket forhindrer, at identifikatoren kan bruges til at spore brugere på tværs af apps. Den kan også let ændres, da brugeren kan slette appdata eller geninstallere appen. Processen for oprettelse af FID’er og GUID’er er ligetil:

• Hentning af et FID: Se Firebase-installationsvejledningen.

• Opretning af et GUID: Implementer logik i din app, som vist i følgende kodeudkast:

  Kotlin

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

  Java

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

Vær opmærksom på, at hvis du har fortalt brugeren, at de data, du indsamler, er anonyme, skal du sikre dig, at du ikke forbinder identifikatoren medPII eller andre identifikatorer, der kan være knyttet til PII.

Du kan også bruge Google Analytics for MobileApps, som tilbyder en løsning til analyse pr. app.

Spore konverteringer af udmeldte brugere

I dette tilfælde sporer du konverteringer for at opdage, om din markedsføringsstrategi er vellykket.

Brug:

Hvorfor denne anbefaling?

Dette er en annoncerelateret brugssituation, som kan kræve et ID, der er tilgængeligt på tværs af forskellige apps, så brug af et reklame-ID er den mest hensigtsmæssige løsning.

Håndtering af flere installationer på tværs af forskellige enheder

I dette tilfælde skal du identificere den korrekte instans af appen, når den er installeret på flere enheder for den samme bruger.

Brug: Brug af reklame-ID

Håndtering af flere installationer på tværs af forskellige enheder

I dette tilfælde skal du identificere den korrekte instans af appen, når den er installeret på flere enheder for den samme bruger: FID eller GUID

Hvorfor denne anbefaling?

Et FID er designet udtrykkeligt til dette formål; dets anvendelsesområde er begrænset til appen, så det ikke kan bruges til at spore brugere på tværs af forskellige apps, og det nulstilles ved geninstallation af appen. I de sjældne tilfælde, hvor et FID er utilstrækkeligt, kan du også bruge et GUID.

Associere funktionalitet med mobiltjenesteabonnementer

I dette tilfælde skal du associere appfunktionalitet med visse mobiltjenesteabonnementer på enheden. Du kan f.eks. have et krav om at verificere adgangen til visse premium-appfunktioner baseret på enhedens mobilabonnementer via SIM.

Brug: Subscription IDAPI til at identificere SIM-kort, der bruges på enheden.

Subscription ID giver en indeksværdi (startende ved 1) til entydig identifikation af installerede SIM-kort (herunder fysiske og elektroniske), der bruges på enheden. Ved hjælp af dette ID kan din app tilknytte sin funktionalitet til forskellige abonnementsoplysninger for et givet SIM-kort. Denne værdi er stabil for et givet SIM-kort, medmindre enheden nulstilles fra fabrikken. Der kan dog være tilfælde, hvor det samme SIM-kort har et andet abonnements-id på forskellige enheder, eller hvor forskellige SIM-kort har det samme ID på forskellige enheder. Hvis abonnements-id’et ikke er tilstrækkeligt unikt, anbefales det at sammenkæde abonnements-id’et med SSAID.

Hvorfor denne anbefaling?

Nogle apps bruger muligvis ICCID til dette formål i øjeblikket. Da ICC-id’et er globalt unikt og ikke kan nulstilles, har adgangen været begrænset til apps med READ_PRIVILEGED_PHONE_STATEtilladelse siden Android 10. Fra og med Android 11 har Google yderligere begrænset adgangen til ICCID via getIccId()API’et, uanset appens mål-API-niveau. Berørte apps bør overgå til at bruge Subscription ID i stedet.

Antibedrageri: Håndhævelse af grænser for gratis indhold og registrering af Sybil-angreb

I dette tilfælde ønsker du at begrænse antallet af gratis indhold, f.eks. artikler, som en bruger kan se på en enhed.

Brug: FID eller GUID. På Android 8.0 (API-niveau 26) og højere er SSAID også en mulighed, da det er begrænset til app-signeringsnøglen.

Hvorfor denne anbefaling?

Ved anvendelse af GUID eller FID tvinges brugeren til at geninstallere appen for at omgå indholdsbegrænsningerne, hvilket er en tilstrækkelig byrde til at afskrække de fleste mennesker. Hvis dette ikke er tilstrækkelig beskyttelse, indeholder Android en DRMAPI, som kan bruges til at begrænse adgangen til indhold, herunder en per-APK-identifikator, Widevine ID.

Bærerfunktionalitet

I dette tilfælde interagerer din app med enhedens telefon- og sms-funktionalitet ved hjælp af en bærerkonto.

Brug: IMEI, IMSI og Line1

Hvorfor denne anbefaling?

Det er acceptabelt at anvende hardwareidentifikatorer, hvis det er nødvendigt for udbyderrelateret funktionalitet. Du kan f.eks. bruge disse identifikatorer til at skifte mellem mobiloperatører eller SIM-slots eller til at levere SMS-beskeder overIP (for Line1) – SIM-baserede brugerkonti. For ikke-privilegerede apps anbefaler vi dog, at du bruger en kontotilmelding til at hente oplysninger om brugerens enhed på serversiden. En af grundene hertil er, at disse identifikatorer i Android 6.0 (API-niveau 23) og højere kun kan bruges via en runtime-tilladelse. Brugere kan slå denne tilladelse fra, så din app bør håndtere disse undtagelser på en elegant måde.

Misbrugsdetektion: Identifikation af bots og DDoS-angreb

I dette tilfælde forsøger du at opdage flere falske enheder, der angriber dine backend-tjenester.

Anvendelse: SafetyNet API

Hvorfor denne anbefaling?

En identifikator i sig selv indikerer kun i ringe grad, at en enhed er ægte. Du kan verificere, at en anmodning kommer fra en ægte Android-enhed – i modsætning til en emulator eller anden kode, der forfalsker en anden enhed – ved hjælp af SafetyNet API’etsattest()metode til at verificere integriteten af en enhed, der foretager en anmodning. Du kan finde mere detaljerede oplysninger i dokumentationen til SafetyNet API.

Detektion af svindel og misbrug: I dette tilfælde forsøger du at opdage, om en enkelt enhed bruges flere gange med stjålne legitimationsoplysninger af høj værdi, f.eks. til at foretage svigagtige betalinger.

Anvendelse: Forebyggelse af svig kræver i sagens natur proprietære signaler, der kan ændre sig over tid, og som derfor ikke er omfattet af dette dokument. Bemærk dog, at hardwareidentifikatorer, såsom IMEI og IMSI, let kan ændres på rooterede eller emulerede enheder, så de er ikke pålidelige indikatorer for svig.