Cele mai bune practici pentru identificatori unici

Acest document oferă îndrumări pentru selectarea identificatorilor adecvați pentru aplicația dvs. în funcție de cazul de utilizare.

Pentru o privire generală asupra permisiunilor Android, consultați Privire generală asupra permisiunilor. Pentru cele mai bune practici specifice pentru lucrul cu permisiunile Android, consultați cele mai bune practici privind permisiunile aplicațiilor.

Bune practici pentru lucrul cu identificatorii Android

Când lucrați cu identificatorii Android, urmați aceste bune practici:

1. Evitați utilizarea identificatorilor hardware. În cele mai multe cazuri de utilizare, puteți evitautilizarea identificatorilor hardware, cum ar fi SSAID (Android ID), fără a limitafuncționalitatea necesară.

   Android 10 (nivel API 29) adaugă restricții pentru identificatorii nerestaurabili,care includ atât IMEI, cât și numărul de serie. Aplicația dvs. trebuie să fie o aplicație proprietară a dispozitivului sau a profilului, să aibă permisiuni speciale ale operatorului sau să aibă permisiunea privilegiată READ_PRIVILEGED_PHONE_STATE pentru a accesa acești identificatori.

2. Utilizați un ID de publicitate numai pentru profilarea utilizatorilor sau pentru cazuri de utilizare a reclamelor. Atunci când folosiți un ID de publicitate,respectați întotdeauna selecțiile utilizatorilor în ceea ce privește urmărirea reclamelor. De asemenea,asigurați-vă că identificatorul nu poate fi conectat la informații personale identificabile (PII) și evitați resetarea ID-ului de publicitate de tip punte.

3. Utilizați un ID de instalare Firebase (FID) sau un GUID stocat privat ori de câte ori este posibil pentru toate celelalte cazuri de utilizare, cu excepția prevenirii fraudelor de plată și a telefoniei. Pentru marea majoritate a cazurilor de utilizare care nu sunt legate de publicitate, un FID sau un GUIDar trebui să fie suficient.

4. Utilizați API-uri care sunt adecvate pentru cazul dumneavoastră de utilizare pentru a minimiza riscul de confidențialitate. Utilizați API DRM pentru protecția conținutului de mare valoare și API-urile SafetyNet pentru protecția împotriva abuzurilor. API-urile SafetyNet sunt cel mai simplu mod de a determina dacă un dispozitiv este autentic fără a suporta riscuri de confidențialitate.

Celelalte secțiuni ale acestui ghid detaliază aceste reguli în contextuldezvoltării aplicațiilor Android.

Lucrați cu ID-uri de publicitate

Identificatorul de publicitate este un identificator care poate fi resetat de utilizator și este adecvat pentru cazurile de utilizare a publicității. Cu toate acestea, există câteva puncte cheie de care trebuie să țineți cont atunci când folosiți acest ID:

Respectați întotdeauna intenția utilizatorului de a reseta ID-ul de publicitate.Nu faceți o punte peste resetarea utilizatorului folosind un alt identificator sau amprentă digitală pentru a lega între ele ID-uri de publicitate subsecvente fără consimțământul utilizatorului. Google Play Developer ContentPolicy (Politica de conținut pentru dezvoltatori Google Play) prevede următoarele:

„…dacă este resetat, un nou identificator de publicitate nu trebuie să fie conectat la un identificator de publicitate anterior sau la date derivate dintr-un identificator de publicitate anterior fără consimțământul explicit al utilizatorului.”

Respectați întotdeauna steagul de anunțuri personalizate asociat. Identificatorii de publicitate suntconfigurabili în sensul că utilizatorii pot limita cantitatea de urmărire asociată cu identificatorul. Folosiți întotdeauna metoda AdvertisingIdClient.Info.isLimitAdTrackingEnabled()pentru a vă asigura că nu ocoliți dorințele utilizatorilor. Politica de conținut pentru dezvoltatorii GooglePlay afirmă următoarele:

„…trebuie să respectați setarea unui utilizator „Opt out of interest-based advertising” sau „Opt out of Ads Personalization”. Dacă un utilizator a activat această setare,nu puteți utiliza identificatorul de publicitate pentru a crea profiluri de utilizator în scopuri publicitare sau pentru a direcționa utilizatorii cu publicitate personalizată. activitățile permise includ publicitatea contextuală, plafonarea frecvenței, urmărirea conversiilor, raportarea și detectarea securității și a fraudelor.”

Cunoașteți orice politici de confidențialitate sau de securitate asociate cu SDK-urile pe care le utilizați și care sunt legate de utilizarea identificatorului de publicitate.De exemplu, dacă treceți true în metodaenableAdvertisingIdCollection() din Google Analytics SDK, asigurați-vă că analizați și respectați toate politicile aplicabile ale Analytics SDK.

De asemenea, fiți conștienți de faptul că Google Play Developer ContentPolicy (Politica de conținut pentru dezvoltatori Google Play) cere ca ID-ul de publicitate „să nu fie conectat la informații care permit identificarea personală sau asociat cu orice identificator persistent al dispozitivului (de exemplu:SSAID, adresa MAC, IMEI, etc.,).”

Ca exemplu, să presupunem că doriți să colectați informații pentru a popula tabele de baze de date cu următoarele coloane:

În acest exemplu, coloana ar putea fi alăturată la PII prin intermediul coloanei account_id din ambele tabele, ceea ce ar constitui o încălcare a Politicii de conținut pentru dezvoltatorii Google Play, dacă nu ați obținut permisiunea explicită din partea utilizatorilor dumneavoastră.

Rețineți că legăturile dintre Advertiser ID și PII nu sunt întotdeauna acest lucruexplicite. Este posibil să aveți „cvasi-identificatori” care apar atât în tabelele cu chei PII, cât și în cele cu chei pentru ID-ul reclamantului, ceea ce cauzează, de asemenea, probleme. De exemplu, să presupunem că modificăm TABELUL-01 și TABELUL-02 după cum urmează:

În acest caz, cu evenimente de clic suficient de rare, este încă posibil să se facă o îmbinare între ID-ul advertiserului TABLE-01 și informațiile personale de identificare conținute în TABLE-02 folosind data și ora evenimentului și modelul dispozitivului.

Deși este adesea dificil de garantat că nu există astfel de cvasi-identificatori într-un set de date, puteți preveni cele mai evidente riscuri de îmbinare prin generalizarea datelor unice atunci când este posibil. În exemplul precedent, acest lucru ar însemna să se reducă acuratețea marcajului temporal, astfel încât mai multe dispozitive cu același model să apară pentru fiecare marcaj temporal.

Alte soluții includ următoarele:

• Nu conceperea de tabele care să lege în mod explicit IDP cu ID-uri de publicitate. În primul exemplu de mai sus, acest lucru ar însemna să nu se includă coloana account_idîn TABLE-01.

• Segregarea și monitorizarea listelor de control al accesului pentru utilizatorii sau rolurile care au acces atât la datele cu cheie ale ID-ului de publicitate, cât și la PII.Prin controlul și auditarea strictă a capacității de a accesa ambele surse simultan (de exemplu, prin efectuarea unei îmbinări între tabele), reduceți riscul de asociere între ID-ul de publicitate și PII. În general, a controla accesul înseamnă a face următoarele:

  1. Păstrați listele de control al accesului (ACL) pentru datele cu cheie ale ID-ului de reclamant și PIIdisjuncte pentru a minimiza numărul de persoane sau roluri care se află în ambeleACL.
  2. Implementați jurnalizarea și auditul accesului pentru a detecta și gestiona orice excepție de la această regulă.

Pentru mai multe informații despre lucrul responsabil cu ID-urile de publicitate, consultați referințaAdvertisingIdClient API.

Lucrați cu FID-uri și GUID-uri

Soluția cea mai simplă pentru identificarea unei instanțe de aplicație care rulează pe un dispozitiv este utilizarea unui ID de instalare Firebase (FID), iar aceasta este soluția recomandată în majoritatea cazurilor de utilizare care nu sunt legate de publicitate. Numai instanța aplicației pentru care a fost furnizată poate accesa acest identificator, iar acesta este (relativ) ușor de resetat, deoarece persistă doar atâta timp cât aplicația este instalată.

Ca urmare, FID-urile oferă proprietăți de confidențialitate mai bune în comparație cu ID-urile hardware care nu pot fi resetate și care sunt limitate la dispozitiv. Pentru mai multe informații, consultați referințafirebase.installationsAPI.

În cazurile în care un FID nu este practic, puteți utiliza, de asemenea, ID-uri personalizate unice la nivel global (GUID-uri) pentru a identifica în mod unic o instanță de aplicație. Cel mai simplu mod de a face acest lucru este prin generarea propriului GUID folosind următorul cod:

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

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

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

Pentru că identificatorul este unic la nivel global, acesta poate fi folosit pentru a identifica o instanță de aplicație specifică. Pentru a evita preocupările legate de legarea identificatorului între aplicații,stocați GUID-urile în memoria internă în loc de memoria externă (partajată). Pentru mai multeinformații, consultați pagina de prezentare generală a stocării datelor și a fișierelor.

Nu lucrați cu adrese MAC

Adresele MAC sunt unice la nivel global, nu pot fi resetate de utilizator și supraviețuiesc resetărilor din fabrică. Din aceste motive, pentru a proteja confidențialitatea utilizatorului, pe versiunile Android 6 șimai sus, accesul la adresele MAC este restricționat la aplicațiile de sistem. Aplicațiile terților nu le pot accesa.

Disponibilitatea adreselor MAC se modifică în Android 11

În aplicațiile care vizează Android 11 și versiunile superioare, randomizarea MAC pentru rețelele Passpoint este per profil Passpoint, generând o adresă MAC unică pe baza următoarelor câmpuri:

• Fully-qualified domain name (FQDN)
• Realm
• Credențial, pe baza credențialului utilizat în profilul Passpoint:
  • Credențial utilizator: nume utilizator
  • Credențial certificat: cert și tip cert
  • Credențial SIM: EAP type and IMSI

În plus, aplicațiile neprivilegiate nu pot accesa adresa MAC a dispozitivului; sunt vizibile doar interfețele de rețea cu o adresă IP. Acest lucru are un impact asupra metodelorgetifaddrs()șiNetworkInterface.getHardwareAddress(), precum și asupra trimiterii de mesaje RTM_GETLINK Netlink.

Următoarea este o listă a modurilor în care aplicațiile sunt afectate de această modificare:

• NetworkInterface.getHardwareAddress() returnează null pentru fiecare interfață.
• Aplicațiile nu pot utiliza funcția bind() pe socluri NETLINK_ROUTE.
• Comanda ip nu returnează informații despre interfețe.
• Aplicațiile nu pot trimite mesaje RTM_GETLINK.

Rețineți că majoritatea dezvoltatorilor ar trebui să utilizeze API-urile de nivel superior dinConnectivityManager mai degrabă decât API-urile de nivel inferior, cum ar fiNetworkInterface,getifaddrs(), sau sockets Netlink. De exemplu, o aplicație care are nevoie de informații actualizate despre rutele curente poate obține aceste informații ascultând modificările de rețea folosind ConnectivityManager.registerNetworkCallback()și apelând rețeaua asociatăLinkProperties.getRoutes().

Caracteristicile identificatorului

Sistemul de operare Android oferă un număr de ID-uri cu caracteristici de comportament diferite.Care ID ar trebui să utilizați depinde de modul în care următoarele caracteristici funcționează cu cazul dumneavoastră de utilizare. Totuși, aceste caracteristici au și implicații asupra confidențialității, așa că este important să înțelegeți modul în care aceste caracteristici interacționează între ele.

Scopul

Scopul identificatorului explică ce sisteme pot accesa identificatorul. Androididentifier scope vine în general în trei variante:

• Single app: Identificatorul este intern pentru aplicație și nu este accesibil altor aplicații.
• Grup de aplicații: Identificatorul este accesibil unui grup predefinit de aplicații conexe.
• Dispozitiv: ID-ul este accesibil tuturor aplicațiilor instalate pe dispozitiv.

Cu cât este mai larg domeniul de aplicare acordat unui identificator, cu atât este mai mare riscul ca acesta să fie utilizat în scopuri de urmărire. Invers, dacă un identificator poate fi accesat doar de o singură instanță a unei aplicații, acesta nu poate fi utilizat pentru a urmări un dispozitiv de-a lungul tranzacțiilor în diferite aplicații.

Reîntregirea și persistența

Reîntregirea și persistența definesc durata de viață a identificatorului și explicămodul în care acesta poate fi resetat. Declanșatorii comuni de resetare includ: resetarea în aplicație, resetarea prinSystem Settings, resetarea la lansare și resetarea la instalare. Identificatorii Android pot avea durate de viață diferite, dar durata de viață este de obicei legată de modul în care este resetat identificatorul:

• Numai pentru sesiune: Un nou ID este folosit de fiecare dată când utilizatorul repornește aplicația.
• Install-reset: Un nou ID este utilizat de fiecare dată când utilizatorul dezinstalează și reinstalează aplicația.
• FDR-reset: Un nou ID este utilizat de fiecare dată când utilizatorul resetează dispozitivul din fabrică.
• FDR-persistent: ID-ul supraviețuiește resetării din fabrică.

Resetabilitatea oferă utilizatorilor posibilitatea de a crea un nou ID care este disociat de orice informații de profil existente. Cu cât un identificator persistă mai mult timp și cu cât este mai fiabil, cum ar fi un identificator care supraviețuiește resetărilor din fabrică, cu atât este mai mare riscul ca utilizatorul să fie supus unei urmăriri pe termen lung. În cazul în care identificatorul este resetat la reinstalarea aplicației, acest lucru reduce persistența și oferă un mijloc de resetare a ID-ului, chiar dacă nu există un control explicit al utilizatorului pentru a-l reseta din cadrul aplicației sau al setărilor de sistem.

Uniqueness

Uniqueness stabilește probabilitatea de coliziuni; adică faptul că există identificatori identici în cadrul domeniului asociat. La cel mai înalt nivel, un identificator unic la nivel global nu are niciodată o coliziune, chiar și pe alte dispozitive sau aplicații. în caz contrar, nivelul de unicitate depinde de entropia identificatorului și de sursa de aleatorism utilizată pentru a-l crea. De exemplu, șansa unei coliziuni este mult mai mare pentru identificatorii aleatori semănați cu data calendaristică a instalării (cum ar fi 2019-03-01) decât pentru identificatorii semănați cu Unixtimpul de instalare (cum ar fi 1551414181).

În general, identificatorii conturilor de utilizator pot fi considerați unici. Adică, fiecare combinație dispozitiv/cont are un identificator unic. Pe de altă parte, cu cât un identificator este mai puțin unic în cadrul unei populații, cu atât mai mare este protecția vieții private, deoarece este mai puțin util pentru urmărirea unui utilizator individual.

Protecție de integritate și non-repudiabilitate

Puteți utiliza un identificator care este dificil de falsificat sau de reprodus pentru a dovedi că dispozitivul sau contul asociat are anumite proprietăți. De exemplu, ați putea dovedi că dispozitivul nu este un dispozitiv virtual folosit de un spammer.Identificatorii greu de falsificat asigură, de asemenea, non-repudiabilitatea. Dacă dispozitivele semnează un mesaj cu o cheie secretă, este dificil de susținut că dispozitivul altcuiva a trimis mesajul. Non-repudiabilitatea ar putea fi ceva ce un utilizator dorește, cum ar fi atunci când autentifică o plată, sau ar putea fi o proprietate nedorită, cum ar fi atunci când trimite un mesaj pe care îl regretă.

Cazuri comune de utilizare și identificatorul adecvat de utilizat

Această secțiune oferă alternative la utilizarea identificatorilor hardware, cum ar fi IMEI. Utilizarea ID-urilor hardware este descurajată deoarece utilizatorul nu le poate reseta, iar acestea sunt rescoase la dispozitiv. În multe cazuri, ar fi suficient un identificator de aplicație.

Să urmăriți preferințele utilizatorului care nu a semnat

În acest caz, salvați starea pentru fiecare dispozitiv în parte, pe server, fără un cont de utilizator.

Utilizați: FID sau GUID

De ce această recomandare?

Nu se recomandă păstrarea informațiilor prin reinstalări, deoarece utilizatorii ar putea dori să își reseteze preferințele prin reinstalarea aplicației.

Să urmăriți preferințele utilizatorilor care nu au semnat între aplicații cu aceeași cheie de semnare

În acest caz, salvați starea per-dispozitiv pe partea serverului și o transferați între diferite aplicații care sunt semnate cu aceeași cheie pe același dispozitiv.

Utilizare: SSAID

De ce această recomandare?

În Android 8.0 (nivel API 26) și ulterior, SSAID oferă un identificator careeste comun între aplicațiile semnate cu aceeași cheie de semnare a dezvoltatorului. Acesta vă permite să partajați starea între aceste aplicații fără a cere utilizatorului să se conecteze la un cont.

Să urmăriți comportamentul unui utilizator care a ieșit din joc

În acest caz, ați creat un profil al unui utilizator pe baza comportamentului său în diferite aplicații/sesiuni pe același dispozitiv.

Utilizați: Advertising ID

De ce această recomandare?

Utilizarea Advertising ID este obligatorie pentru cazurile de utilizare a publicității conform GooglePlay Developer ContentPolicy, deoarece utilizatorul o poate reseta.

Generate signed-out or anonymous user analytics

În acest caz, măsurați statisticile de utilizare și analizele pentru utilizatorii semnalizați sau anonimi.

Utilizare: FID, sau un GUID dacă un FID este insuficient

De ce această recomandare?

Un FID sau un GUID este atribuit aplicației care îl creează, ceea ce previne ca identificatorul să fie folosit pentru a urmări utilizatorii între aplicații. De asemenea, este ușor de resetat, deoarece utilizatorul poate șterge datele aplicației sau reinstala aplicația. Procesul de creare a FID-urilor și GUID-urilor este simplu:

• Retragerea unui FID: Consultați ghidul de instalare Firebase.

• Crearea unui GUID: Implementați logica în aplicația dumneavoastră, așa cum se arată în următorul fragment de cod:

  Kotlin

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

  Java

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

Să știți că, dacă i-ați spus utilizatorului că datele pe care le colectați suntanonime, trebuie să vă asigurați că nu conectați identificatorul la PII sau la alți identificatori care ar putea fi legați de PII.

Puteți utiliza, de asemenea, Google Analytics for MobileApps, care oferă o soluție pentru analiza per-aplicație.

Să urmăriți conversiile utilizatorilor care au semnat

În acest caz, urmăriți conversiile pentru a detecta dacă strategia dvs. de marketing are succes.

Utilizați: Advertising ID

De ce această recomandare?

Acesta este un caz de utilizare legat de reclame care ar putea necesita un ID care să fie disponibil în diferite aplicații, astfel încât utilizarea unui Advertising ID este cea mai potrivită soluție.

Gestionați instalările multiple pe diferite dispozitive

În acest caz, trebuie să identificați instanța corectă a aplicației atunci când aceasta este instalată pe mai multe dispozitive pentru același utilizator.

Utilizare: Advertising ID: FID sau GUID

De ce această recomandare?

Un FID este conceput în mod explicit în acest scop; domeniul său de aplicare este limitat la aplicație, astfel încât nu poate fi folosit pentru a urmări utilizatorii în diferite aplicații, și este resetat la reinstalarea aplicației. În rarele cazuri în care un FID esteinsuficient, puteți utiliza și un GUID.

Asocierea funcționalității cu abonamente de servicii mobile

În acest caz, trebuie să asociați funcționalitatea aplicației cu anumite abonamente de servicii mobile de pe dispozitiv. De exemplu, este posibil să aveți cerința de averifica accesul la anumite caracteristici premium ale aplicației pe baza abonamentelor de servicii mobile ale dispozitivului prin intermediul SIM.

Utilizați: Subscription IDAPI pentru aidentifica SIM-urile care sunt utilizate pe dispozitiv.

The Subscription ID oferă o valoare de index (începând cu 1) pentru a identifica în mod unic SIM-urile instalate (inclusiv cele fizice și electronice) utilizate pe dispozitiv. Prin intermediul acestui ID, aplicația dvs. își poate asocia funcționalitatea cu diverse informații de abonament pentru un anumit SIM. Această valoare este stabilă pentru un anumit SIM, cu excepția cazului în care dispozitivul este resetat din fabrică. Cu toate acestea, pot exista cazuri în care același SIM are un ID de abonament diferit pe dispozitive diferite sau SIM-uri diferite au același ID pe dispozitive diferite. în cazul în care ID-ul de abonament nu este suficient de unic, se recomandă concatenarea ID-ului de abonament cu SSAID.

De ce această recomandare?

Este posibil ca unele aplicații să utilizeze în prezent ICCID în acest scop. Deoarece ID-ul ICC este unic la nivel global și nu poate fi resetat, accesul a fost restricționat pentru aplicațiile cu permisiunea READ_PRIVILEGED_PHONE_STATEde la Android 10. Începând cu Android 11, Google a restricționat și mai multaccesul la ICCID prin getIccId()API, indiferent de nivelul API țintă al aplicației. Aplicațiile afectate ar trebui să migreze pentru a utiliza în schimb ID-ul de abonament.

Antifraudă: Impunerea limitelor de conținut gratuit și detectarea atacurilor Sybil

În acest caz, doriți să limitați numărul de conținut gratuit, cum ar fi articolele,pe care un utilizator le poate vedea pe un dispozitiv.

Utilizare: FID sau GUID. Pe Android 8.0 (nivel API 26) și mai sus, SSAID este, de asemenea, o opțiune, deoarece are ca domeniu de aplicare cheia de semnare a aplicației.

De ce această recomandare?

Utilizarea unui GUID sau FID forțează utilizatorul să reinstaleze aplicația pentru a ocoli limitele de conținut, ceea ce reprezintă o povară suficientă pentru a-i descuraja pe cei mai mulți oameni. Dacă aceasta nu este o protecție suficientă, Android oferă un DRMAPI, care poate fi utilizat pentru a limita accesul la conținut, include un identificator per-APK, ID-ul Widevine.

Funcționalitatea operatorului

În acest caz, aplicația dvs. interacționează cu telefonul dispozitivului și cu funcționalitatea de trimitere de mesaje text utilizând un cont de operator.

Utilizați: IMEI, IMSI și Line1

De ce această recomandare?

Utilizarea identificatorilor hardware este acceptabilă dacă este necesară pentru funcționalitatea legată de operator. De exemplu, ați putea utiliza acești identificatori pentru a comuta între operatorii de telefonie mobilă sau sloturile SIM, sau pentru a livra mesaje SMS prin IP (pentru Line1) – conturi de utilizator bazate pe SIM. Cu toate acestea, pentru aplicațiile neprivilegiate, am recomandat utilizarea unui cont de autentificare pentru a prelua informațiile despre dispozitivul utilizatorului pe partea de server. Unul dintre motive este faptul că, în Android 6.0 (nivel API 23) și mai sus, acești identificatori pot fi utilizați numai prin intermediul unei permisiuni de execuție. Este posibil ca utilizatorii să dezactiveze această permisiune, astfel încât aplicația dvs. ar trebui să gestioneze aceste excepții în mod grațios.

Detectarea abuzurilor: Identificarea roboților și a atacurilor DDoS

În acest caz, încercați să detectați mai multe dispozitive false care vă atacă serviciile backend.

Utilizare: API-ul SafetyNet

De ce această recomandare?

Un identificator în mod izolat nu prea indică faptul că un dispozitiv este autentic. Puteți verifica dacă o cerere provine de la un dispozitiv Android autentic – spre deosebire de un emulator sau alt cod care falsifică un alt dispozitiv – utilizând metoda SafetyNet APIattest() pentru a verifica integritatea unui dispozitiv care face o cerere. Pentru informații mai detaliate, consultați documentația SafetyNet API.

Detectarea fraudei și a abuzurilor: Detectarea acreditărilor furate de mare valoare

În acest caz, încercați să detectați dacă un singur dispozitiv este utilizat de mai multe ori cu acreditări furate, de mare valoare, cum ar fi pentru a face plăți frauduloase.

Utilizare: Prin natura sa, prevenirea fraudei necesită semnale de proprietate care se pot schimba în timp și, prin urmare, nu intră în domeniul de aplicare al acestui document. Cu toate acestea, rețineți că identificatorii hardware, cum ar fi IMEI și IMSI, pot fi modificați cu ușurință pe dispozitive cu rădăcini sau emulate, astfel încât aceștia nu sunt indicatori fiabili de fraudă.

.