Bästa praxis för unika identifierare

Det här dokumentet ger vägledning om hur du väljer lämpliga identifierare för din app baserat på ditt användningsfall.

För en allmän titt på Android-behörigheter, se Översikt över behörigheter. För specifika bästa praxis för arbete med Android-behörigheter, se Bästa praxis för appbehörigheter.

Bästa praxis för arbete med Android-identifierare

När du arbetar med Android-identifierare ska du följa dessa bästa praxis:

1. Undervik att använda hårdvaruidentifierare. I de flesta användningsfall kan du undvika att använda maskinvaruidentifierare, t.ex. SSAID (Android ID), utan att begränsa den funktionalitet som krävs.

   Android 10 (API-nivå 29) lägger till begränsningar för icke återställbara identifierare, som inkluderar både IMEI och serienummer. Din app måste vara en app som äger en enhet eller en profil, ha särskilda operatörsrättigheter eller ha privilegierad behörighet READ_PRIVILEGED_PHONE_STATE för att få tillgång till dessa identifierare.

2. Använd endast ett reklam-ID för användarprofilering eller annonser. När du använder ett reklam-ID ska du alltid respektera användarnas val när det gäller spårning av annonser. Se också till att identifieraren inte kan kopplas till personligt identifierbar information (PII) och undvik att överbrygga återställningar av reklam-ID.

3. Använd ett Firebase-installations-ID (FID) eller ett privat lagrat GUID när det är möjligt för alla andra användningsfall, utom för förebyggande av betalningsbedrägerier och telefoni. För de allra flesta användningsfall som inte är reklam bör ett FID eller GUID vara tillräckligt.

4. Använd API:er som är lämpliga för ditt användningsfall för att minimera riskerna för privatlivet. Använd DRM API för skydd av innehåll av högt värde och SafetyNet API för skydd mot missbruk. SafetyNet API:erna är det enklaste sättet att avgöra om en enhet är äkta utan att det innebär en integritetsrisk.

De återstående avsnitten i den här guiden beskriver dessa regler i samband med utveckling av Android-appar.

Arbeta med annonserings-id

Reklam-id:et är en identifierare som kan återställas av användaren och lämpar sig för användningsfall som rör annonser. Det finns dock några viktiga punkter att tänka på när du använder detta ID:

Respektera alltid användarens avsikt med att återställa reklam-ID:

Överbrygg inte användarens återställning genom att använda en annan identifierare eller ett annat fingeravtryck för att koppla samman efterföljande reklam-ID:

utan användarens samtycke. I Google Play Developer ContentPolicy anges följande:

”…om den återställs får en ny annonseringsidentifierare inte kopplas till en tidigare annonseringsidentifierare eller data som härrör från en tidigare annonseringsidentifierare utan användarens uttryckliga samtycke.”

Respektera alltid den tillhörande flaggan för personaliserade annonser. Reklam-ID:n är konfigurerbara på så sätt att användarna kan begränsa mängden spårning som är kopplad till ID:n. Använd alltid AdvertisingIdClient.Info.isLimitAdTrackingEnabled()metoden för att se till att du inte kringgår användarnas önskemål. I GooglePlay Developer ContentPolicy står följande:

”…du måste följa en användares inställning ’Opt out of interest-based advertising’ eller ’Opt out of Ads Personalization’. Om en användare har aktiverat den här inställningen får du inte använda annonseringsidentifieraren för att skapa användarprofiler i reklamsyfte eller för att rikta in dig på användare med personlig annonsering.Tillåtna aktiviteter inkluderar kontextuell annonsering, frekvensbegränsning, konverteringsspårning, rapportering samt säkerhets- och bedrägeriupptäckt.”

Var uppmärksam på alla sekretess- eller säkerhetspolicyer som är kopplade till SDK:er som du använder och som är relaterade till användning av annonseringsidentifierare.Om du till exempel skickar tillenableAdvertisingIdCollection()metoden från Google Analytics SDK, se till att du granskar och följer alla tillämpliga policyer för Analytics SDK.

Visa också att Google Play Developer ContentPolicy kräver att Advertising ID ”inte får kopplas till personligt identifierbar information eller förknippas med någon bestående enhetsidentifierare (till exempel:SSAID, MAC-adress, IMEI, etc.),).”

Såsom exempel kan vi anta att du vill samla in information för att fylla databastabeller med följande kolumner:

I detta exempel, kan kolumnen ad_id kopplas samman med PII via kolumnen account_id i båda tabellerna, vilket skulle vara ett brott mot Google Play DeveloperContent Policy om du inte har fått uttryckligt tillstånd från dina användare.

Håll i minnet att kopplingar mellan Annonsör-ID och PII inte alltid är så tydliga. Det är möjligt att ha ”kvasi-identifierare” som förekommer i både PII- och annonsörs-ID-tabeller med nycklar, vilket också orsakar problem. Anta till exempel att vi ändrarTABLE-01 och TABLE-02 på följande sätt:

I detta fall, med tillräckligt sällsynta klickhändelser är det fortfarande möjligt att koppla ihop annonsörs-ID TABLE-01 och PII i TABLE-02 med hjälp av händelsens tidsstämpel och enhetsmodellen.

Och även om det ofta är svårt att garantera att det inte finns några sådana kvasi-identifierare i en datamängd, kan man förhindra de mest uppenbara riskerna för sammanfogning genom att generalisera unika uppgifter där det är möjligt. I det föregående exemplet skulle detta innebära att minska noggrannheten hos tidsstämpeln så att flera enheter med samma modell visas för varje tidsstämpel.

Andra lösningar inkluderar följande:

• Inte utforma tabeller som uttryckligen kopplar samman PII med reklam-ID. I det första exemplet ovan skulle detta innebära att inte inkludera kolumnen account_id i TABLE-01.

• Segregera och övervaka åtkomstkontrolllistor för användare eller roller som har åtkomst till både nyckeluppgifter för reklam-ID och PII.Genom att noggrant kontrollera och granska möjligheten att få åtkomst till båda källorna samtidigt (t.ex. genom att utföra en sammanfogning mellan tabeller) minskar du risken för koppling mellan reklam-ID och PII. Generellt sett innebär åtkomstkontroll följande:

  1. Håller åtkomstkontrolllistor (ACL:er) för annonsörsidentitets nyckeldata och PII isär för att minimera antalet individer eller roller som finns i båda ACL:erna.
  2. Inför åtkomstloggning och granskning för att upptäcka och hantera eventuella undantag från denna regel.

För mer information om hur man arbetar ansvarsfullt med reklam-ID:n, se AdvertisingIdClient API-referensen.

Arbeta med FID:er och GUID:er

Den enklaste lösningen för att identifiera en app-instans som körs på en enhet är att använda ett Firebase-installations-ID (FID), och det här är den rekommenderade lösningen i majoriteten av de fall där det inte är fråga om reklam. Endast den appinstans för vilken den har tillhandahållits kan få tillgång till denna identifierare, och den är (relativt) lätt att återställa eftersom den bara finns kvar så länge appen är installerad.

Som ett resultat av detta ger FID bättre integritetsegenskaper jämfört med ickeåterställningsbara hårdvaru-ID:n med enhetsbegränsning. Mer information finns i firebase.installationsAPI-referensen.

I de fall då ett FID inte är praktiskt kan du också använda anpassade globalt unika ID:n (GUID:er) för att unikt identifiera en appinstans. Det enklaste sättet att göra det är att generera ett eget GUID med hjälp av följande kod:

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

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

Då identifikatorn är globalt unik kan den användas för att identifiera en specifik appinstans. För att undvika problem med att länka identifieraren mellan olika appar kan du lagra GUID:er i intern lagring i stället för extern (delad) lagring. Mer information finns på sidan Översikt över data- och fillagring.

Arbeta inte med MAC-adresser

MAC-adresser är globalt unika, kan inte återställas av användaren och överlever fabriksåterställningar. Av dessa skäl och för att skydda användarens integritet är åtkomsten till MAC-adresser begränsad till systemprogram på Android-versioner 6 och högre. Tredjepartsappar kan inte komma åt dem.

MAC-adresstillgänglighet ändras i Android 11

På appar som riktar sig till Android 11 och högre är MAC-randomisering för Passpointnätverk per Passpoint-profil, vilket genererar en unik MAC-adress baserad på följande fält:

• Fullt kvalificerat domännamn (FQDN)
• Realm
• Credential, baserat på den autentisering som används i Passpoint-profilen:
  • User credential: användarnamn
  • Certificate credential: cert and cert type
  • SIM credential: EAP-typ och IMSI

Det går dessutom inte att få åtkomst till enhetens MAC-adress för icke-priviligierade appar; endast nätverksgränssnitt med en IP-adress är synliga. Detta påverkar metodernagetifaddrs()ochNetworkInterface.getHardwareAddress() samt sändning av RTM_GETLINK Netlink-meddelanden.

Nedan följer en lista över hur appar påverkas av den här ändringen:

• NetworkInterface.getHardwareAddress() returnerar null för varje gränssnitt.
• Appar kan inte använda bind()-funktionen på NETLINK_ROUTE sockets.
• Kommandot ip returnerar inte information om gränssnitt.
• Appar kan inte skicka RTM_GETLINK meddelanden.

Notera att de flesta utvecklare bör använda de högre API:erna iConnectivityManager snarare än API:er på lägre nivå somNetworkInterface,getifaddrs() eller Netlink sockets. Till exempel kan en app som behöver aktuell information om aktuella rutter få denna information genom att lyssna på nätverksförändringar med hjälp av ConnectivityManager.registerNetworkCallback() och anropa nätverkets associeradeLinkProperties.getRoutes().

Identifieringskännetecken

Android OS erbjuder ett antal ID:n med olika beteendekännetecken.Vilket ID du ska använda beror på hur följande kännetecken fungerar i ditt användningsfall. De här egenskaperna har dock också konsekvenser för privatlivet, så det är viktigt att förstå hur de här egenskaperna interagerar med varandra.

Räckvidd

Identifieringens räckvidd förklarar vilka system som kan få tillgång till identifieraren. Androididentifier scope finns i allmänhet i tre varianter:

• Enkel app:
• Grupp av appar: ID:t är tillgängligt för en fördefinierad grupp av relaterade appar.
• Enhet:

Ju större räckvidd en identifierare har, desto större är risken för att den används i spårningssyfte. Omvänt gäller att om en identifierare endast kan nås av en enda appinstans kan den inte användas för att spåra en enhet över transaktioner i olika appar.

Återställbarhet och beständighet

Återställbarhet och beständighet definierar identifierarens livslängd och förklarar hur den kan återställas. Vanliga utlösare för återställning är: återställning i appen, återställning via systeminställningar, återställning vid start och återställning vid installation. Androididentifierare kan ha olika livslängd, men livslängden är vanligtvis relaterad till hur identifieraren återställs:

• Session-only: Ett nytt ID används varje gång användaren startar om appen.
• Återställning vid installation:
• FDR-reset: Ett nytt ID används varje gång användaren avinstallerar och installerar appen på nytt: Ett nytt ID används varje gång användaren återställer enheten från fabrik.
• FDR-persistent: Ett nytt ID används varje gång användaren återställer enheten från fabrik: ID överlever fabriksåterställning.

Återställbarhet ger användaren möjlighet att skapa ett nytt ID som är frikopplat från all befintlig profilinformation. Ju längre och mer tillförlitligt en identitetsbeteckning finns kvar, t.ex. en identitetsbeteckning som finns kvar även efter fabriksåterställning, desto större är risken för att användaren kan bli föremål för långsiktig spårning. Om identitetsbeteckningen återställs vid ominstallation av appen minskar detta persistensen och ger ett sätt att återställa identitetsbeteckningen, även om det inte finns någon uttrycklig användarkontroll för att återställa den från appen eller systeminställningarna.

Uniqueness

Uniqueness fastställer sannolikheten för kollisioner, det vill säga att identiska identitetsbeteckningar existerar inom den associerade räckvidden. På den högsta nivån har en globalt unik identifierare aldrig någon kollision, inte ens på andra enheter eller i andra appar.Annars beror graden av unikhet på identifierarens entropi och den slumpkälla som används för att skapa den. Till exempel är risken för en kollision mycket större för slumpmässiga identifierare som är seedade med kalenderdatumet för installationen (t.ex. 2019-03-01) än för identifierare som är seedade med Unixtimestampen för installationen (t.ex. 1551414181).

I allmänhet kan identifierare för användarkonton anses vara unika. Det vill säga, varje kombination av enhet och konto har ett unikt ID. Å andra sidan, ju mindre unik en identifierare är inom en population, desto större är integritetsskyddet eftersom den är mindre användbar för att spåra en enskild användare.

Integritetsskydd och oförstörbarhet

Du kan använda en identifierare som är svår att förfalska eller spela upp igen för att bevisa att den associerade enheten eller kontot har vissa egenskaper. Du kan till exempel bevisa att enheten inte är en virtuell enhet som används av en skräppostare.Identifier som är svåra att förfalska ger också möjlighet att inte avvisa. Om enheterna signerar ett meddelande med en hemlig nyckel är det svårt att hävda att någon annans enhet har skickat meddelandet. Icke-avvisbarhet kan vara något som en användare vill ha, t.ex. vid autentisering av en betalning, eller så kan det vara en oönskad egenskap, t.ex. när de skickar ett meddelande som de ångrar.

Gemensamma användningsfall och lämplig identifierare att använda

I det här avsnittet finns alternativ till att använda hårdvaru-ID:n, t.ex. Det avråds från att använda hårdvaru-ID:n eftersom användaren inte kan återställa dem och de är reskopierade till enheten. I många fall räcker det med en identifierare för en app.

Spåra utskrivna användarpreferenser

I det här fallet sparar du tillstånd per enhet på serversidan utan ett användarkonto.

Användning:

Varför den här rekommendationen?

Det är inte rekommenderat att behålla information genom ominstallationer eftersom användare kanske vill återställa sina inställningar genom att ominstallera appen.

Spåra avregistrerade användarpreferenser mellan appar med samma signeringsnyckel

I det här fallet sparar du tillstånd för varje enhet på serverns sida och överför det mellan olika appar som är signerade med samma nyckel på samma enhet.

Användning: SSAID

Varför den här rekommendationen?

I Android 8.0 (API-nivå 26) och senare ger SSAID en identifierare som är gemensam för appar som är signerade med samma signeringsnyckel från samma utvecklare. Den gör det möjligt att dela tillstånd mellan dessa appar utan att användaren behöver logga in på ett konto.

Spåra utskrivna användares beteende

I det här fallet har du skapat en profil för en användare baserat på deras beteende i olika appar/sessioner på samma enhet.

Användning:

Varför denna rekommendation?

Användning av reklam-ID är obligatoriskt för reklamanvändning enligt GooglePlay Developer ContentPolicy eftersom användaren kan återställa det.

Generera analys av avregistrerade eller anonyma användare

I det här fallet mäter du användningsstatistik och analys för avregistrerade eller anonyma användare.

Användning: Användning av reklam-ID

Varför denna rekommendation? FID, eller en GUID om en FID är otillräcklig

Varför denna rekommendation?

En FID eller GUID är begränsad till den app som skapar den, vilket förhindrar att identifieraren används för att spåra användare i olika appar. Den är också lätt att återställa, eftersom användaren kan rensa appdata eller installera om appen. Processen för att skapa FID och GUID är enkel:

• Hämtning av en FID: Se Firebase installationsguide.

• Skapa en GUID: Implementera logik i din app, som visas i följande kodutdrag:

  Kotlin

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

  Java

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

Var medveten om att om du har berättat för användaren att de uppgifter du samlar in är anonyma bör du se till att du inte kopplar identifieraren till PII eller andra identifierare som kan kopplas till PII.

Du kan också använda Google Analytics for MobileApps, som erbjuder en lösning för analys per app.

Spåra konverteringar av utskrivna användare

I det här fallet spårar du konverteringar för att upptäcka om din marknadsföringsstrategi är framgångsrik.

Användning:

Varför denna rekommendation?

Detta är ett annonsrelaterat användningsfall som kan kräva ett ID som är tillgängligt i olika appar, så att använda ett reklam-ID är den lämpligaste lösningen.

Hantera flera installationer på olika enheter

I det här fallet måste du identifiera rätt instans av appen när den är installerad på flera olika enheter för samma användare.

Användning: FID eller GUID

Varför denna rekommendation?

En FID är utformad uttryckligen för detta ändamål; dess räckvidd är begränsad till appen så att den inte kan användas för att spåra användare i olika appar, och den återställs vid ominstallation av appen. I de sällsynta fall där ett FID inte räcker till kan du också använda ett GUID.

Associera funktionalitet med mobiltjänstabonnemang

I det här fallet måste du associera appfunktionalitet med vissa mobiltjänstabonnemang på enheten. Du kan till exempel ha ett krav på att verifiera tillgången till vissa premiumfunktioner i appen baserat på enhetens mobilabonnemang via SIM.

Användning: Subscription IDAPI för att identifiera SIM-kort som används på enheten.

Subscription ID ger ett indexvärde (med början vid 1) för att entydigt identifiera installerade SIM-kort (inklusive fysiska och elektroniska) som används på enheten. Med hjälp av detta ID kan din app associera sin funktionalitet med olika abonnemangsinformation för ett visst SIM-kort. Detta värde är stabilt för ett visst SIM-kort såvida inte enheten fabriksåterställs. Det kan dock förekomma fall där samma SIM-kort har ett annat abonnemangs-ID på olika enheter eller där olika SIM-kort har samma ID på olika enheter. Om abonnemangs-ID:t inte är tillräckligt unikt rekommenderas att abonnemangs-ID:t konkateneras med SSAID.

Varför denna rekommendation?

Vissa appar kan för närvarande använda ICCID för detta ändamål. Eftersom ICC-ID är globalt unikt och inte kan återställas har åtkomsten varit begränsad till appar med READ_PRIVILEGED_PHONE_STATEtillstånd sedan Android 10. Från och med Android 11 har Google ytterligare begränsat åtkomsten till ICCID via getIccId()API, oavsett appens mål-API-nivå. De appar som berörs bör övergå till att använda abonnemangs-ID i stället.

Antibedrägeri: Genomföra gränser för gratis innehåll och upptäcka Sybil-attacker

I det här fallet vill du begränsa antalet gratis innehåll, t.ex. artiklar, som en användare kan se på en enhet.

Användning: Använd FID eller GUID. På Android 8.0 (API-nivå 26) och högre är SSAID också ett alternativ, eftersom den är begränsad till nyckeln för signering av appen.

Varför den här rekommendationen?

Användning av GUID eller FID tvingar användaren att installera appen på nytt för att kringgå innehållsbegränsningarna, vilket är en tillräcklig börda för att avskräcka de flesta människor. Om detta inte är ett tillräckligt skydd tillhandahåller Android ett DRMAPI, som kan användas för att begränsa tillgången till innehåll, inklusive en identifierare per APK, Widevine ID.

Bärariefunktionalitet

I det här fallet interagerar appen med enhetens telefon- och sms-funktionalitet med hjälp av ett operatörskonto.

Användning: IMEI, IMSI och Line1

Varför denna rekommendation?

Hantering av hårdvaruidentifierare är acceptabelt om det krävs för operatörsrelaterad funktionalitet. Du kan till exempel använda dessa identifierare för att växla mellan mobiloperatörer eller SIM-kortplatser, eller för att leverera SMS-meddelanden via IP (för Line1) – SIM-baserade användarkonton. För icke-priviligierade appar rekommenderar vi dock att du använder en konto-inloggning för att hämta information om användarens enhet på serversidan. En anledning till detta är att i Android 6.0 (API-nivå 23) och högre kan dessa identifierare endast användas via ett körtidstillstånd. Användare kan stänga av detta tillstånd, så din app bör hantera dessa undantag på ett elegant sätt.

Missbruksdetektering: Identifiera robotar och DDoS-attacker

I det här fallet försöker du upptäcka flera falska enheter som attackerar dina backend-tjänster.

Användning: SafetyNet API

Varför den här rekommendationen?

En identifierare i sig själv ger inte mycket för att visa att en enhet är äkta. Du kan kontrollera att en begäran kommer från en äkta Android-enhet – till skillnad från en emulator eller annan kod som förfalskar en annan enhet – genom att använda SafetyNet API:s attest()metod för att kontrollera integriteten hos en enhet som gör en begäran. Mer detaljerad information finns i dokumentationen till SafetyNet API.

Detektering av bedrägerier och missbruk: I det här fallet försöker du upptäcka om en enda enhet används flera gånger med stulna autentiseringsuppgifter av högt värde, t.ex. för att göra bedrägliga betalningar.

Användning: För att förebygga bedrägerier krävs till sin natur proprietära signaler som kan förändras med tiden och som därför inte omfattas av det här dokumentet. Observera dock att hårdvaruidentifierare, såsom IMEI och IMSI, lätt kan ändras på rotade eller emulerade enheter, så de är inte tillförlitliga indikatorer på bedrägeri.