Best practices per gli identificatori unici

Questo documento fornisce una guida per selezionare gli identificatori appropriati per la tua applicazione in base al tuo caso d’uso.

Per uno sguardo generale ai permessi Android, vedi Permissionsoverview. Per le best practice specifiche per lavorare con i permessi Android, vedi Best practice per i permessi delle app.

Best practice per lavorare con gli identificatori Android

Quando lavori con gli identificatori Android, segui queste best practice:

1. Evitare di usare identificatori hardware. Nella maggior parte dei casi d’uso, è possibile evitare di utilizzare gli identificatori hardware, come SSAID (Android ID), senza limitare le funzionalità richieste.

   Android 10 (livello API 29) aggiunge restrizioni per gli identificatori non resettabili, che includono sia l’IMEI che il numero di serie. La tua app deve essere un’app proprietaria di un dispositivo o di un profilo, avere speciali autorizzazioni dell’operatore o avere l’autorizzazione privilegiata READ_PRIVILEGED_PHONE_STATE per poter accedere a questi identificatori.

2. Utilizzare un Advertising ID solo per i casi di utilizzo del profilo utente o degli annunci. Quando si utilizza un Advertising ID, rispettare sempre le scelte degli utenti riguardo all’adtracking. Inoltre, assicurati che l’identificatore non possa essere collegato a informazioni personali identificabili (PII), ed evita il bridging reset dell’Advertising ID.

3. Usa un Firebase installation ID (FID) o un GUID memorizzato privatamente quando possibile per tutti gli altri casi d’uso, eccetto per la prevenzione delle frodi di pagamento e la telefonia. Per la stragrande maggioranza dei casi d’uso non-ads, un FID o un GUID dovrebbe essere sufficiente.

4. Utilizza le API che sono appropriate per il tuo caso d’uso per minimizzare il rischio di privacy. Usate le API DRM per la protezione di contenuti di alto valore e le API SafetyNet per la protezione dagli abusi. Le API SafetyNet sono il modo più semplice per determinare se un dispositivo è autentico senza incorrere in rischi per la privacy.

Le restanti sezioni di questa guida elaborano queste regole nel contesto dello sviluppo di applicazioni Android.

Lavora con gli ID pubblicitari

L’ID pubblicitario è un identificatore resettabile dall’utente ed è appropriato per i casi di utilizzo degli annunci. Ci sono alcuni punti chiave da tenere a mente, tuttavia, quando si utilizza questo ID:

Rispetta sempre l’intenzione dell’utente nel reimpostare l’ID pubblicitario.Non superare le reimpostazioni dell’utente utilizzando un altro identificatore o impronta digitale per collegare insieme gli ID pubblicitari successivi senza il consenso dell’utente. La Google Play Developer ContentPolicy afferma quanto segue:

“…se reimpostato, un nuovo identificatore pubblicitario non deve essere collegato ad un precedente identificatore pubblicitario o a dati derivati da un precedente identificatore pubblicitario senza il consenso esplicito dell’utente.”

Rispettare sempre il flag di annunci personalizzati associato. Gli ID pubblicitari sono configurabili nel senso che gli utenti possono limitare la quantità di tracciamento associato all’ID. Usa sempre il metodo AdvertisingIdClient.Info.isLimitAdTrackingEnabled()per assicurarti di non eludere i desideri dei tuoi utenti. La GooglePlay Developer ContentPolicy afferma quanto segue:

“…è necessario rispettare l’impostazione ‘Opt out of interest-based advertising’ o ‘Opt out of Ads Personalization’ di un utente. Se un utente ha abilitato questa impostazione, non è possibile utilizzare l’identificatore pubblicitario per la creazione di profili utente per scopi pubblicitari o per indirizzare gli utenti con pubblicità personalizzata. Le attività consentite includono la pubblicità contestuale, il frequency capping, il conversiontracking, il reporting e la sicurezza e il rilevamento delle frodi.”

Siate consapevoli di qualsiasi politica sulla privacy o sulla sicurezza associata agli SDK che utilizzate e che sono collegati all’utilizzo dell’ID pubblicitario.Per esempio, se passi true nel metodoenableAdvertisingIdCollection()dall’SDK di Google Analytics, assicurati di rivedere e aderire a tutte le politiche dell’SDK di Analytics applicabili.

Inoltre, sii consapevole che la Google Play Developer ContentPolicy richiede che l’Advertising ID “non deve essere collegato a informazioni di identificazione personale o associato a qualsiasi identificatore di dispositivo persistente (per esempio:SSAID, indirizzo MAC, IMEI, ecc,).”

Come esempio, supponiamo di voler raccogliere informazioni per popolare tabelle di dati con le seguenti colonne:

In questo esempio, la colonna ad_id potrebbe essere unita al PII tramite la colonna account_id in entrambe le tabelle, il che sarebbe una violazione della Google Play DeveloperContent Policy, se non si ottiene un permesso esplicito dai propri utenti.

Tenete presente che i collegamenti tra Advertiser ID e PII non sono sempre così espliciti. È possibile avere “quasi-identificatori” che appaiono in entrambe le tabelle con chiave PII eAd ID, che causano anche problemi. Per esempio, supponiamo di cambiare TABLE-01 e TABLE-02 come segue:

In questo caso, con eventi click sufficientemente rari, è ancora possibile unire l’ID inserzionista TABLE-01 e il PII contenuto in TABLE-02 usando l’orario dell’evento e il modello del dispositivo.

Anche se è spesso difficile garantire che non esistano tali quasi-identificatori in un set di dati, è possibile prevenire i rischi più ovvi di join generalizzando i dati unici dove possibile. Nell’esempio precedente, questo significherebbe ridurre la precisione del timestamp in modo che più dispositivi con lo stesso modello appaiano per ogni timestamp.

Altre soluzioni includono le seguenti:

• Non progettare tabelle che collegano esplicitamente PII con ID pubblicitari. Nel primo esempio sopra, questo significherebbe non includere la colonna account_id in TABLE-01.

• Segregando e monitorando le liste di controllo degli accessi per gli utenti o i ruoli che hanno accesso sia ai dati chiave dell’Advertising ID che alle PII.Controllando strettamente e verificando la capacità di accedere ad entrambe le fonti contemporaneamente (per esempio, eseguendo un join tra tabelle), si riduce il rischio di associazione tra Advertising ID e PII. In generale, controllare l’accesso significa fare quanto segue:

  1. Mantenere le liste di controllo dell’accesso (ACL) per i dati chiave dell’ID pubblicitario e il PIIdisgiunti per ridurre al minimo il numero di individui o ruoli che sono in entrambe le ACL.
  2. Implementare la registrazione e l’auditing dell’accesso per rilevare e gestire qualsiasi eccezione a questa regola.

Per maggiori informazioni su come lavorare in modo responsabile con gli Advertising ID, vedi laAdvertisingIdClient API reference.

Lavora con i FID e i GUID

La soluzione più diretta per identificare un’istanza di app in esecuzione su un dispositivo è quella di usare un ID di installazione Firebase (FID), e questa è la soluzione raccomandata nella maggior parte dei casi di utilizzo non-Ads. Solo l’istanza dell’app per la quale è stato fornito può accedere a questo identificatore, ed è (relativamente) facilmente azzerabile perché persiste solo finché l’app è installata.

Come risultato, i FID forniscono migliori proprietà di privacy rispetto agli ID hardware non azzerabili e limitati al dispositivo. Per maggiori informazioni, vedere il riferimento all’APIfirebase.installations.

Nei casi in cui un FID non è pratico, è anche possibile utilizzare ID globali personalizzati (GUID) per identificare in modo univoco un’istanza dell’app. Il modo più semplice per farlo è generare il proprio GUID usando il seguente codice:

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

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

Perché l’identificatore è globalmente unico, può essere usato per identificare una specifica istanza dell’app. Per evitare preoccupazioni relative al collegamento dell’identificatore tra le app, memorizza i GUID nella memoria interna invece che in quella esterna (condivisa). Per maggiori informazioni, vedi la pagina di panoramica sull’archiviazione di dati e file.

Non lavorare con gli indirizzi MAC

Gli indirizzi MAC sono unici a livello globale, non sono reimpostabili dall’utente e sopravvivono ai reset di fabbrica. Per queste ragioni, per proteggere la privacy dell’utente, su Android versione 6 e superiore, l’accesso agli indirizzi MAC è limitato alle app di sistema. Le app di terze parti non possono accedervi.

La disponibilità dell’indirizzo MAC cambia in Android 11

Nelle applicazioni destinate ad Android 11 e superiori, la randomizzazione MAC per le reti Passpoint è per profilo Passpoint, generando un indirizzo MAC unico basato sui seguenti campi:

• Nome di dominio pienamente qualificato (FQDN)
• Realm
• Credenziale, basata sulla credenziale usata nel profilo Passpoint:
  • Credenziale utente: nome utente
  • Credenziale certificato: cert e tipo cert
  • Credenziale SIM: Tipo EAP e IMSI

Inoltre, le applicazioni non privilegiate non possono accedere all’indirizzo MAC del dispositivo; solo le interfacce di rete con un indirizzo IP sono visibili. Questo ha un impatto sui metodigetifaddrs()eNetworkInterface.getHardwareAddress(), così come sull’invio di messaggi RTM_GETLINK Netlink.

Di seguito è riportato un elenco dei modi in cui le app sono interessate da questo cambiamento:

• NetworkInterface.getHardwareAddress() restituisce null per ogni interfaccia.
• Le app non possono usare la funzione bind() su NETLINK_ROUTE socket.
• Il comando ip non restituisce informazioni sulle interfacce.
• Le applicazioni non possono inviare messaggi RTM_GETLINK.

Nota che la maggior parte degli sviluppatori dovrebbe usare le API di livello superiore diConnectivityManager piuttosto che API di livello inferiore comeNetworkInterface,getifaddrs(), o i socket Netlink. Per esempio, un’applicazione che ha bisogno di informazioni aggiornate sui percorsi correnti può ottenere queste informazioni ascoltando i cambiamenti della rete usando ConnectivityManager.registerNetworkCallback()e chiamando ilLinkProperties.getRoutes() associato alla rete.

Caratteristiche dell’identificatore

Il sistema operativo Android offre una serie di ID con diverse caratteristiche di comportamento.Quale ID si dovrebbe usare dipende da come le seguenti caratteristiche funzionano con il vostro caso d’uso. Queste caratteristiche hanno anche implicazioni sulla privacy, tuttavia, quindi è importante capire come queste caratteristiche interagiscono tra loro.

Scope

Lo scope dell’identificatore spiega quali sistemi possono accedere all’identificatore. L’ambito dell’identificatore Android è generalmente di tre tipi:

• App singola: L’ID è interno all’app e non accessibile ad altre app.
• Gruppo di app: L’ID è accessibile a un gruppo predefinito di app correlate.
• Dispositivo: L’ID è accessibile a tutte le app installate sul dispositivo.

Più ampio è l’ambito concesso a un identificatore, maggiore è il rischio che venga utilizzato per scopi di tracciamento. Al contrario, se un identificatore è accessibile solo da una singola istanza dell’app, non può essere utilizzato per tracciare un dispositivo attraverso le transazioni in diverse app.

Resettabilità e persistenza

Resettabilità e persistenza definiscono la durata dell’identificatore e spiegano come può essere resettato. I comuni trigger di reset includono: reset in-app, reset tramite le impostazioni di sistema, reset all’avvio e reset all’installazione. Gli identificatori Android possono avere una durata di vita variabile, ma la durata di vita è di solito legata a come l’ID viene resettato:

• Session-only: Un nuovo ID viene usato ogni volta che l’utente riavvia l’app.
• Install-reset: Un nuovo ID è usato ogni volta che l’utente disinstalla e reinstalla l’applicazione.
• FDR-reset: Un nuovo ID viene utilizzato ogni volta che l’utente resetta il dispositivo in fabbrica.
• FDR-persistent: L’ID sopravvive al reset di fabbrica.

La resettabilità dà agli utenti la possibilità di creare un nuovo ID che è dissociato da qualsiasi informazione di profilo esistente. Più a lungo, e in modo più affidabile, un identificatore persiste, come uno che persiste attraverso i reset di fabbrica, maggiore è il rischio che l’utente possa essere soggetto a tracciamento a lungo termine. Se l’identificatore viene resettato alla reinstallazione dell’app, questo riduce la persistenza e fornisce un mezzo per resettare l’ID, anche se non c’è un esplicito controllo dell’utente per resettarlo dall’interno dell’app o dalle Impostazioni di sistema.

Uniquità

L’unicità stabilisce la probabilità di collisioni; cioè, che esistano identificatori identici nell’ambito associato. Al livello più alto, un identificatore globalmente unico non ha mai una collisione, anche su altri dispositivi o applicazioni.Altrimenti, il livello di unicità dipende dall’entropia dell’identificatore e dalla fonte di casualità usata per crearlo. Per esempio, la possibilità di una collisione è molto più alta per identificatori casuali seminati con la data di calendario dell’installazione (come 2019-03-01) che per identificatori seminati con l’Unixtimestamp dell’installazione (come 1551414181).

In generale, gli identificatori di account utente possono essere considerati unici. Cioè, ogni combinazione dispositivo/account ha un ID unico. D’altra parte, meno unico è un identificatore all’interno di una popolazione, maggiore è la protezione della privacy perché è meno utile per tracciare un singolo utente.

Protezione dell’integrità e non ripudiabilità

È possibile usare un identificatore che è difficile da falsificare o riprodurre per provare che il dispositivo o l’account associato ha certe proprietà. Per esempio, si potrebbe dimostrare che il dispositivo non è un dispositivo virtuale usato da uno spammer. Se i dispositivi firmano un messaggio con una chiave segreta, è difficile sostenere che il dispositivo di qualcun altro ha inviato il messaggio. La non ripudiabilità potrebbe essere qualcosa che un utente vuole, come quando autentica un pagamento, o potrebbe essere una proprietà indesiderata, come quando invia un messaggio di cui si pente.

Casi d’uso comuni e l’identificatore appropriato da usare

Questa sezione fornisce alternative all’uso di ID hardware, come IMEI. L’uso degli ID hardware è sconsigliato perché l’utente non può resettarli, e sono limitati al dispositivo. In molti casi, sarebbe sufficiente un identificatore per app.

Traccia le preferenze dell’utente firmato

In questo caso, stai salvando lo stato per dispositivo sul lato server senza un account utente.

Usa: FID o GUID

Perché questa raccomandazione?

La persistenza delle informazioni attraverso le reinstallazioni non è raccomandata perché gli utenti potrebbero voler resettare le loro preferenze reinstallando l’app.

Traccia le preferenze degli utenti firmati tra le app con la stessa chiave di firma

In questo caso, stai salvando lo stato per dispositivo sul lato server e trasferendolo tra diverse app che sono firmate con la stessa chiave sullo stesso dispositivo.

Uso: SSAID

Perché questa raccomandazione?

In Android 8.0 (livello API 26) e superiore, SSAID fornisce un identificatore comune alle applicazioni firmate dalla stessa chiave di firma dello sviluppatore. Permette di condividere lo stato tra queste applicazioni senza richiedere all’utente di accedere ad un account.

Track signed-out user behavior

In questo caso, hai creato un profilo di un utente basato sul suo comportamento attraverso diverse app/sessioni sullo stesso dispositivo.

Uso: Advertising ID

Perché questa raccomandazione?

L’uso dell’Advertising ID è obbligatorio per i casi di uso pubblicitario secondo la GooglePlay Developer ContentPolicy perché l’utente può resettarlo.

Generare analisi per utenti firmati o anonimi

In questo caso, stai misurando statistiche di utilizzo e analisi per utenti firmati o anonimi.

Uso: FID, o un GUID se un FID è insufficiente

Perché questa raccomandazione?

Un FID o un GUID è limitato all’app che lo crea, il che impedisce che l’identificatore sia usato per tracciare gli utenti nelle varie app. È anche facilmente ripristinabile, poiché l’utente può cancellare i dati dell’app o reinstallare l’app. Il processo di creazione di FID e GUID è semplice:

• Recuperare un FID: vedi la guida alle installazioni di Firebase.

• Creazione di un GUID: Implementa la logica nella tua app, come mostrato nel seguente codenippet:

  Kotlin

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

  Java

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

Siate consapevoli che se avete detto all’utente che i dati che state raccogliendo sono anonimi, dovreste assicurarvi di non collegare l’identificatore a PII o ad altri identificatori che potrebbero essere collegati a PII.

Puoi anche usare Google Analytics per MobileApps, che offre una soluzione per l’analisi per applicazione.

Traccia le conversioni degli utenti firmati

In questo caso, stai monitorando le conversioni per rilevare se la tua strategia di marketing ha successo.

Uso: Advertising ID

Perché questa raccomandazione?

Questo è un caso d’uso legato agli annunci che potrebbe richiedere un ID che sia disponibile su diverse app, quindi l’uso di un Advertising ID è la soluzione più appropriata.

Gestire installazioni multiple su diversi dispositivi

In questo caso, è necessario identificare l’istanza corretta dell’app quando è installata su più dispositivi per lo stesso utente.

Uso: FID o GUID

Perché questa raccomandazione?

Un FID è progettato esplicitamente per questo scopo; la sua portata è limitata all’app in modo che non possa essere usata per tracciare gli utenti su diverse app, ed è ripristinata alla reinstallazione dell’app. Nei rari casi in cui un FID è insufficiente, puoi anche usare un GUID.

Associa funzionalità a sottoscrizioni di servizi mobili

In questo caso, hai bisogno di associare funzionalità di app a certe sottoscrizioni di servizi mobili sul dispositivo. Per esempio, potreste avere l’esigenza di verificare l’accesso a certe funzionalità premium dell’app in base agli abbonamenti mobili del dispositivo tramite SIM.

Uso: IDAPI di sottoscrizione per identificare le SIM utilizzate sul dispositivo.

L’ID di sottoscrizione fornisce un valore di indice (a partire da 1) per identificare univocamente le SIM installate (comprese quelle fisiche ed elettroniche) utilizzate sul dispositivo. Attraverso questo ID, l’applicazione può associare la sua funzionalità a varie informazioni di abbonamento per una data SIM. Questo valore è stabile per una data SIM a meno che il dispositivo non venga resettato di fabbrica. Tuttavia, ci possono essere casi in cui la stessa SIM ha un diverso Subscription ID su diversi dispositivi o diverse SIM hanno lo stesso ID su diversi dispositivi. se il Subscription ID non è sufficientemente unico si raccomanda di concatenare il Subscription ID con SSAID.

Perché questa raccomandazione?

Alcune app possono attualmente utilizzare l’ICCID per questo scopo. Poiché l’ID ICC è globalmente unico e non resettabile, l’accesso è stato limitato alle applicazioni con l’autorizzazione READ_PRIVILEGED_PHONE_STATEda Android 10. A partire da Android 11, Google ha ulteriormente limitato l’accesso all’ICCID attraverso il getIccId()API, indipendentemente dal livello API di destinazione dell’app. Le app interessate dovrebbero invece migrare verso l’utilizzo dell’ID di sottoscrizione.

Anti-frode: Applicare limiti ai contenuti gratuiti e rilevare attacchi Sybil

In questo caso, si vuole limitare il numero di contenuti gratuiti, come gli articoli, che un utente può vedere su un dispositivo.

Uso: FID o GUID. Su Android 8.0 (livello API 26) e superiore, SSAID è anche un’opzione, in quanto è limitato alla chiave di firma dell’app.

Perché questa raccomandazione?

L’utilizzo di un GUID o FID costringe l’utente a reinstallare l’app per aggirare i limiti di contenuto, che è un onere sufficiente a scoraggiare la maggior parte delle persone. Se questa non è una protezione sufficiente, Android fornisce un DRMAPI, che può essere usato per limitare l’accesso al contenuto, include un identificatore per-APK, il Widevine ID.

Funzionalità portante

In questo caso, la tua app sta interagendo con il telefono del dispositivo e la funzionalità di testo usando un account portante.

Utilizzare: IMEI, IMSI e Line1

Perché questa raccomandazione?

L’utilizzo di identificatori hardware è accettabile se è richiesto per funzionalità relative al carrier. Per esempio, potreste usare questi identificatori per passare da un vettore cellulare all’altro o da uno slot SIM all’altro, o per consegnare messaggi SMS su IP (per Line1) – account utente basati su SIM. Per le applicazioni non privilegiate, tuttavia, consigliamo di utilizzare un account sign-in per recuperare le informazioni del dispositivo dell’utente sul lato server. Una ragione per questo è che, in Android 6.0 (livello API 23) e superiori, questi identificatori possono essere utilizzati solo tramite un permesso di runtime. Gli utenti potrebbero disattivare questo permesso, quindi la vostra applicazione dovrebbe gestire queste eccezioni in modo grazioso.

Rilevamento degli abusi: Identificazione di bot e attacchi DDoS

In questo caso, stai cercando di rilevare più dispositivi falsi che attaccano i tuoi servizi di backend.

Uso: L’API SafetyNet

Perché questa raccomandazione?

Un identificatore da solo fa poco per indicare che un dispositivo è genuino. È possibile verificare che una richiesta provenga da un dispositivo Android autentico – al contrario di un emulatore o altro codice che spoofing un altro dispositivo – utilizzando il metodo dell’API SafetyNetattest()per verificare l’integrità di un dispositivo che effettua una richiesta. Per informazioni più dettagliate, vedere la documentazione dell’API SafetyNet.

Rilevamento di frodi e abusi: Rilevamento di credenziali rubate di alto valore

In questo caso, si sta cercando di rilevare se un singolo dispositivo viene utilizzato più volte con credenziali rubate di alto valore, ad esempio per effettuare pagamenti fraudolenti.

Uso: Per sua natura, la prevenzione delle frodi richiede segnali proprietari che possono cambiare nel tempo e sono quindi fuori dallo scopo di questo documento. Tuttavia, si noti che gli identificatori hardware, come IMEI e IMSI, possono essere facilmente modificati su dispositivi radicati o emulati, quindi non sono indicatori affidabili di frode.