Best practice per gli identificatori univoci

Questo documento fornisce indicazioni per la selezione di identificatori appropriati per la tua app in base al tuo caso d'uso.

Per una panoramica generale delle autorizzazioni Android, vedi Panoramica delle autorizzazioni. Per best practice specifiche per l'utilizzo delle autorizzazioni Android, vedi Best practice per le autorizzazioni app.

Best practice per l'uso degli identificatori Android

Per proteggere la privacy dei tuoi utenti, utilizza l'identificatore più restrittivo chesoddisfa il caso d'uso della tua app. In particolare, segui queste best practice:

1. Scegli identificatori reimpostabili dall'utente, se possibile. La tua app può realizzare la maggior parte dei suoi casi d'uso anche se utilizza identificatori diversi dagli ID hardware non reimpostabili.

2. Evita di utilizzare identificatori hardware. Nella maggior parte dei casi, puoi evitare di utilizzare identificatori hardware, come l'International Mobile Equipment Identity (IMEI), senza limitare la funzionalità richiesta.

   Android 10 (livello API 29) aggiunge limitazioni per gli identificatori non reimpostabili, che includono sia il codice IMEI sia il numero di serie. Per poter accedere a questi identificatori, la tua app deve essere un'app di proprietà del dispositivo o del profilo, avere autorizzazioni speciali dell'operatore o disporre dell'autorizzazione privilegiata READ_PRIVILEGED_PHONE_STATE.

3. Utilizza un ID pubblicità solo per i casi d'uso di profilazione degli utenti o di annunci. Quando utilizzi un ID pubblicità, rispetta sempre le selezioni degli utenti in merito al monitoraggio degli annunci. Se devi collegare l'identificatore pubblicità a informazioni che consentono l'identificazione personale, fallo solo con il consenso esplicito dell'utente.

4. Non eseguire il bridge delle reimpostazioni dell'ID pubblicità.

5. Utilizza un ID installazione Firebase (FID) o un GUID archiviato in privato, se possibile, per tutti gli altri casi d'uso, ad eccezione della prevenzione delle frodi relative ai pagamenti e della telefonia. Per la maggior parte dei casi d'uso non pubblicitari, un FID o un GUID dovrebbe essere sufficiente.

6. Utilizza le API appropriate per il tuo caso d'uso per ridurre al minimo i rischi per la privacy. Utilizza l'API DRM per la protezione di contenuti di alto valore e le API Play Integrity per la protezione da abusi. Le API Play Integrity sono il modo più semplice per determinare se un dispositivo è originale senza incorrere in rischi per la privacy.

Le sezioni rimanenti di questa guida illustrano queste regole nel contesto dello sviluppo di app per Android.

Utilizza gli ID pubblicità

L'ID pubblicità è un identificatore reimpostabile dall'utente ed è appropriato per i casi d'uso degli annunci. Tuttavia, quando utilizzi questo ID, tieni presente alcuni punti chiave:

Rispetta sempre l'intenzione dell'utente di reimpostare l'ID pubblicità. Non eseguire il bridging delle reimpostazioni utente utilizzando un altro identificatore o un'altra impronta per collegare ID pubblicità successivi senza il consenso dell'utente. Le Norme relative ai contenuti per gli sviluppatori di Google Play stabiliscono quanto segue:

"…in caso di reimpostazione, il nuovo identificatore pubblicità non deve essere collegato a un identificatore pubblicità precedente o a dati derivanti da un identificatore pubblicità precedente senza l'esplicito consenso dell'utente".

Rispetta sempre il flag degli annunci personalizzati associato. Gli ID pubblicità sono configurabili in quanto gli utenti possono limitare la quantità di monitoraggio associata all'ID. Utilizza sempre il metodo AdvertisingIdClient.Info.isLimitAdTrackingEnabled() per assicurarti di non aggirare le preferenze degli utenti. Le Norme relative ai contenuti per gli sviluppatori di Google Play prevedono quanto segue:

"…devi rispettare l'impostazione di disattivazione della pubblicità basata sugli interessi o della personalizzazione degli annunci configurata dall'utente. Se un utente ha attivato questa impostazione, non puoi utilizzare l'identificatore pubblicità per creare profili degli utenti per scopi pubblicitari o per eseguire il targeting degli utenti con pubblicità personalizzata. Sono ammessi, ad esempio, pubblicità contestuale, quota limite, monitoraggio delle conversioni, creazione di report e rilevamento di problemi di sicurezza e di attività fraudolente."

Tieni presente le norme sulla privacy o sulla sicurezza associate agli SDK che utilizzi e relative all'utilizzo dell'ID pubblicità. Ad esempio, se passi true al metodo enableAdvertisingIdCollection() dell'SDK Google Analytics, assicurati di rivedere e rispettare tutte le norme dell'SDK Analytics applicabili.

Inoltre, tieni presente che le Norme relative ai contenuti per gli sviluppatori di Google Play richiedono che l'ID pubblicità "non sia collegato a informazioni che consentono l'identificazione personale o associato a un identificatore del dispositivo persistente (ad esempio SSAID, indirizzo MAC, IMEI e così via)".

Ad esempio, supponiamo che tu voglia raccogliere informazioni per compilare le tabelle del database con le seguenti colonne:

In questo esempio, la colonna ad_id potrebbe essere unita alle PII tramite la colonna account_id in entrambe le tabelle. Se non ricevessi l'autorizzazione esplicita dagli utenti, questa sarebbe una violazione delle Norme relative ai contenuti per gli sviluppatori di Google Play.

Tieni presente che i link tra ID inserzionista e PII non sono sempre così espliciti. È possibile che vengano visualizzati "quasi-identificatori" sia nelle tabelle con chiave PII sia nelle tabelle con chiave ID annuncio, che causano anche problemi. Ad esempio, supponiamo di aver modificato TABLE-01 e TABLE-02 come segue:

In questo caso, con eventi di clic sufficientemente rari, è comunque possibile eseguire il join tra l'ID inserzionista TABLE-01 e le PII contenute in TABLE-02 utilizzando il timestamp dell'evento e il modello del dispositivo.

Sebbene sia spesso difficile garantire che non esistano quasi identificatori di questo tipo in un set di dati, puoi evitare i rischi di unione più evidenti generalizzando i dati univoci, se possibile. Nell'esempio precedente, ciò significherebbe ridurre la precisione del timestamp in modo che per ogni timestamp vengano visualizzati più dispositivi con lo stesso modello.

Altre soluzioni includono:

• Non progettare tabelle che colleghino esplicitamente le PII agli ID pubblicità. Nel primo esempio riportato sopra, ciò significa non includere la colonna account_id nella TABELLA-01.

• Separazione e monitoraggio degli elenchi di controllo dell'accesso per gli utenti o i ruoli che hanno accesso sia ai dati con chiave ID pubblicità sia alle PII. Controllando e verificando rigorosamente la possibilità di accedere contemporaneamente a entrambe le origini (ad esempio, eseguendo un join tra tabelle), riduci il rischio di associazione tra l'ID pubblicità e le PII. In generale, controllare l'accesso significa fare quanto segue:

  1. Mantieni disgiunti gli elenchi di controllo dell'accesso (ACL) per i dati con chiave ID inserzionista e le PII per ridurre al minimo il numero di persone o ruoli presenti in entrambi gli ACL.
  2. Implementa il logging e il controllo dell'accesso per rilevare e gestire eventuali eccezioni a questa regola.

Per saperne di più su come lavorare in modo responsabile con gli ID pubblicità, consulta il riferimento dell'API AdvertisingIdClient.

Utilizzo di FID e GUID

La soluzione più semplice per identificare un'istanza di app in esecuzione su un dispositivo è utilizzare un ID installazione Firebase (FID). Si tratta della soluzione consigliata nella maggior parte dei casi d'uso non pubblicitari. Solo l'istanza dell'app per la quale è stato eseguito il provisioning può accedere a questo identificatore ed è (relativamente) facile da reimpostare perché persiste solo finché l'app è installata.

Di conseguenza, i FID offrono migliori proprietà della privacy rispetto agli ID hardware non reimpostabili con ambito dispositivo. Per ulteriori informazioni, consulta il riferimento all'API firebase.installations.

Nei casi in cui un FID non sia pratico, puoi anche utilizzare ID personalizzati (GUID) univoci a livello globale per identificare in modo univoco un'istanza di app. Il modo più semplice per farlo è generare il tuo GUID utilizzando il seguente codice:

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

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

Poiché l'identificatore è univoco a livello globale, può essere utilizzato per identificare una specifica istanza dell'app. Per evitare problemi relativi al collegamento dell'identificatore tra le app, memorizza i GUID nello spazio di archiviazione interno anziché in quello esterno (condiviso). Per ulteriori informazioni, consulta la pagina Panoramica dell'archiviazione di dati e file.

Non funzionano con gli indirizzi MAC

Gli indirizzi MAC sono univoci a livello globale, non possono essere reimpostati dall'utente e rimangono invariati anche dopo il ripristino dei dati di fabbrica. Per questi motivi, per proteggere la privacy degli utenti, nelle versioni di Android 6 e superiori l'accesso agli indirizzi MAC è limitato alle app di sistema. Le app di terze parti non possono accedervi.

Modifiche alla disponibilità dell'indirizzo MAC in Android 11

Nelle app destinate ad Android 11 e versioni successive, la randomizzazione dell'indirizzo MAC per le reti Passpoint avviene in base al profilo Passpoint, generando un indirizzo MAC univoco in base ai seguenti campi:

• Nome di dominio completo (FQDN)
• Realm
• Autenticazione, in base alle credenziali utilizzate nel profilo Passpoint:
  • Credenziale utente: nome utente
  • Credenziale del certificato: tipo di certificato e certificato
  • Scheda SIM: tipo EAP e IMSI

Inoltre, le app non privilegiate non possono accedere all'indirizzo MAC del dispositivo; sono visibili solo le interfacce di rete con un indirizzo IP. Ciò influisce sui metodi getifaddrs() e NetworkInterface.getHardwareAddress() nonché sull'invio di messaggi RTM_GETLINK Netlink.

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

• NetworkInterface.getHardwareAddress() restituisce un valore nullo per ogni interfaccia.
• Le app non possono utilizzare la funzione bind() sulle socket NETLINK_ROUTE.
• Il comando ip non restituisce informazioni sulle interfacce.
• Le app non possono inviare messaggi RTM_GETLINK.

Tieni presente che la maggior parte degli sviluppatori dovrebbe utilizzare le API di livello superiore di ConnectivityManager anziché quelle di livello inferiore come NetworkInterface, getifaddrs() o le socket Netlink. Ad esempio, un'app che ha bisogno di informazioni aggiornate sulle route attuali può ottenere queste informazioni ascoltando le modifiche di rete utilizzando ConnectivityManager.registerNetworkCallback() e chiamando il LinkProperties.getRoutes() associato della rete.

Caratteristiche degli identificatori

Il sistema operativo Android offre una serie di ID con caratteristiche di comportamento diverse. L'ID da utilizzare dipende dal modo in cui le seguenti caratteristiche funzionano con il tuo caso d'uso. Tuttavia, queste caratteristiche comportano anche implicazioni per la privacy, pertanto è importante capire in che modo interagiscono tra loro.

Ambito

L'ambito dell'identificatore spiega quali sistemi possono accedere all'identificatore. L'ambito identificativo Android è generalmente disponibile in tre versioni:

• 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 monitoraggio. Al contrario, se un identificatore è accessibile solo da una singola istanza dell'app, non può essere utilizzato per monitorare un dispositivo nelle transazioni in app diverse.

Ripristino e persistenza

La reimpostazione e la persistenza definiscono la durata dell'identificatore e spiegano come può essere reimpostato. Gli attivatori di reimpostazione più comuni sono: reimpostazione in-app, reimpostazione tramite Impostazioni di sistema, reimpostazione all'avvio e reimpostazione all'installazione. Gli identificatori Android possono avere diverse durate, ma di solito sono correlate al modo in cui l'ID viene reimpostato:

• Solo sessione: ogni volta che l'utente riavvia l'app viene utilizzato un nuovo ID.
• Installazione-reimpostazione: viene utilizzato un nuovo ID ogni volta che l'utente disinstalla e reinstalla l'app.
• Ripristino dei dati di fabbrica: viene utilizzato un nuovo ID ogni volta che l'utente ripristina i dati di fabbrica del dispositivo.
• FDR-persistent: l'ID persiste dopo il ripristino dei dati di fabbrica.

La reimpostabilità offre agli utenti la possibilità di creare un nuovo ID non associato alle informazioni del profilo esistenti. Più a lungo e in modo più affidabile un identificatore persiste, ad esempio uno che persiste dopo il ripristino dei dati di fabbrica, maggiore è il rischio che l'utente possa essere sottoposto a monitoraggio a lungo termine. Se l'identificatore viene reimpostato al momento della reinstallazione dell'app, la persistenza viene ridotta e viene fornito un mezzo per reimpostare l'ID, anche se non esiste un controllo esplicito da parte dell'utente per reimpostarlo dall'app o dalle Impostazioni di sistema.

Unicità

L'unicità stabilisce la probabilità di collisioni, ovvero che esistono identificatori identici all'interno dell'ambito associato. A livello più alto, un identificatore univoco a livello mondiale non ha mai collisioni, nemmeno su altri dispositivi o app. In caso contrario, il livello di unicità dipende dall'entropia dell'identificatore e dalla fonte di casualità utilizzata per crearlo. Ad esempio, la probabilità di collisione è molto più elevata per gli identificatori casuali con data di installazione nel calendario (ad esempio 2019-03-01) rispetto agli identificatori generati con il timestamp dell'installazione Unix (ad esempio 1551414181).

In generale, gli identificatori degli account utente possono essere considerati univoci. In altre parole, ogni combinazione di dispositivo/account ha un ID univoco. D'altra parte, meno un identificativo è univoco all'interno di una popolazione, maggiore è la protezione della privacy perché è meno utile per monitorare un singolo utente.

Protezione dell'integrità e non ripudibilità

Puoi utilizzare un identificatore difficile da falsificare o riprodurre per dimostrare che il dispositivo o l'account associato ha determinate proprietà. Ad esempio, potresti dimostrare che il dispositivo non è un dispositivo virtuale utilizzato da uno spammer. Gli identificatori difficili da falsificare offrono anche non ripudio. Se il dispositivo firma un messaggio con una chiave segreta, è difficile affermare che il messaggio sia stato inviato dal dispositivo di qualcun altro. La non riproducibilità potrebbe essere un aspetto auspicato da un utente, ad esempio durante l'autenticazione di un pagamento, oppure una proprietà indesiderata, ad esempio quando invia un messaggio di cui ne penti il pentimento.

Casi d'uso comuni e identificatore appropriato da utilizzare

Questa sezione offre alternative all'utilizzo di ID hardware, ad esempio IMEI. L'utilizzo degli ID hardware è sconsigliato perché l'utente non può reimpostarli e sono limitati al dispositivo. In molti casi, è sufficiente un identificatore basato sull'app.

Account

Stato dell'operatore

In questo caso, l'app interagisce con la funzionalità di chiamate e messaggi del dispositivo utilizzando un account dell'operatore.

Identificatore consigliato da utilizzare: IMEI, IMSI e Line1

Perché questo consiglio?

L'utilizzo di identificatori hardware è accettabile se necessario per la funzionalità correlata all'operatore. Ad esempio, puoi utilizzare questi identificatori per cambiare operatore di telefonia cellulare o slot SIM oppure per inviare messaggi SMS tramite IP (per Line1) - account utente basati su SIM. Per le app senza privilegi, tuttavia, consigliamo di utilizzare un accesso all'account per recuperare le informazioni sul dispositivo dell'utente sul lato server. Uno dei motivi è che, in Android 6.0 (livello API 23) e versioni successive, questi identificatori possono essere utilizzati solo tramite un'autorizzazione di runtime. Gli utenti potrebbero disattivare questa autorizzazione, pertanto la tua app deve gestire queste eccezioni in modo corretto.

Stato dell'abbonamento mobile

In questo caso, devi associare la funzionalità dell'app a determinati abbonamenti ai servizi di telefonia mobile sul dispositivo. Ad esempio, potresti avere l'obbligo di verificare l'accesso a determinate funzionalità dell'app premium in base agli abbonamenti di telefonia mobile del dispositivo tramite SIM.

Identificatore consigliato da utilizzare: API Subscription ID per identificare le SIM utilizzate sul dispositivo.

L'ID abbonamento fornisce un valore di indice (a partire da 1) per identificare in modo univoco le SIM installate (incluse quelle fisiche ed elettroniche) utilizzate sul dispositivo. Tramite questo ID, la tua app può associare le sue funzionalità a varie informazioni sull'abbonamento per una determinata SIM. Questo valore è stabile per una determinata SIM a meno che non venga eseguito il ripristino dei dati di fabbrica del dispositivo. Tuttavia, potrebbero verificarsi casi in cui la stessa SIM abbia un ID abbonamento diverso su dispositivi diversi o in cui SIM diverse abbiano lo stesso ID su dispositivi diversi.

Perché questo consiglio?

Al momento alcune app potrebbero utilizzare l'ID ICC a questo scopo. Poiché l'ID ICC è univoco a livello globale e non può essere reimpostato, l'accesso è stato limitato alle app con l'autorizzazione READ_PRIVILEGED_PHONE_STATE da Android 10. A partire da Android 11, Android ha ulteriormente limitato l'accesso all'ICCID tramite l'API getIccId(), indipendentemente dal livello API target dell'app. Le app interessate devono eseguire la migrazione per utilizzare l'ID abbonamento.

Single Sign-On

In questo caso, l'app offre un'esperienza Single Sign-On, che consente agli utenti di associare un account esistente alla tua organizzazione.

Identificatore consigliato da utilizzare: account compatibili con gli account manager, ad esempio il collegamento dell'Account Google

Perché questo consiglio?

Il collegamento dell'Account Google consente agli utenti di associare l'Account Google esistente di un utente alla tua app, fornendo un accesso più semplice e sicuro ai prodotti e ai servizi della tua organizzazione. Inoltre, puoi definire ambiti OAuth personalizzati per condividere solo i dati necessari, aumentando la fiducia degli utenti definendo chiaramente come vengono utilizzati i loro dati.

Annunci

Targeting

In questo caso, la tua app crea un profilo degli interessi di un utente per mostrargli annunci più pertinenti.

Identificatore consigliato da utilizzare: se la tua app utilizza un ID per gli annunci e viene caricata o pubblicata su Google Play, questo ID deve essere l'ID pubblicità.

Perché questo consiglio?

Si tratta di un caso d'uso relativo agli annunci che potrebbe richiedere un ID disponibile nelle diverse app della tua organizzazione, per cui l'utilizzo di un ID pubblicità è la soluzione più appropriata. L'utilizzo dell'ID pubblicità è obbligatorio per i casi d'uso pubblicitari, ai sensi delle Norme relative ai contenuti per gli sviluppatori di Google Play, poiché l'utente può reimpostarlo.

Indipendentemente dal fatto che tu condivida i dati utente nella tua app, se li raccogli e li utilizzi per finalità pubblicitarie, devi dichiarare le finalità pubblicitarie nella sezione Sicurezza dei dati della pagina Contenuti app in Play Console.

Misurazione

In questo caso, la tua app crea un profilo di un utente in base al suo comportamento nelle app della tua organizzazione sullo stesso dispositivo.

Identificatore consigliato da utilizzare: ID pubblicità o API referrer di installazioni di Google Play

Perché questo consiglio?

Questo è un caso d'uso correlato agli annunci che potrebbe richiedere un ID disponibile nelle diverse app della tua organizzazione, pertanto l'utilizzo di un ID pubblicità è la soluzione più appropriata. Se utilizzi un ID per i casi d'uso pubblicitari, questo ID deve essere l'ID pubblicità perché l'utente può reimpostarlo. Scopri di più nelle Norme relative ai contenuti degli sviluppatori di Google Play.

Conversioni

In questo caso, stai monitorando le conversioni per capire se la tua strategia di marketing ha esito positivo.

Identificatore consigliato da utilizzare: ID pubblicità o API referrer di installazioni di Google Play

Perché questo consiglio?

Si tratta di un caso d'uso relativo agli annunci che potrebbe richiedere un ID disponibile nelle diverse app della tua organizzazione, per cui l'utilizzo di un ID pubblicità è la soluzione più appropriata. L'utilizzo dell'ID pubblicità è obbligatorio per i casi d'uso di pubblicità, in base alle Norme relative ai contenuti per gli sviluppatori di Google Play, perché l'utente può reimpostarlo.

Remarketing

In questo caso, la tua app mostra annunci basati sugli interessi precedenti dell'utente.

Identificatore consigliato da utilizzare: ID pubblicità

Perché questo consiglio?

Si tratta di un caso d'uso relativo agli annunci che potrebbe richiedere un ID disponibile nelle diverse app della tua organizzazione, per cui l'utilizzo di un ID pubblicità è la soluzione più appropriata. L'utilizzo dell'ID pubblicità è obbligatorio per i casi d'uso pubblicitari, ai sensi delle Norme relative ai contenuti per gli sviluppatori di Google Play, poiché l'utente può reimpostarlo.

Analisi dati delle app

In questo caso, la tua app valuta il comportamento di un utente per aiutarti a determinare quanto segue:

• Quali altri prodotti o app della tua organizzazione potrebbero essere adatti all'utente.
• Come mantenere gli utenti interessati a utilizzare la tua app.
• Misurare statistiche e analisi sull'utilizzo per gli utenti anonimi o che non hanno eseguito l'accesso.

Ecco alcune possibili soluzioni:

• ID set di app:un ID set di app ti consente di analizzare il comportamento di un utente su più app di proprietà della tua organizzazione, a condizione che tu non utilizzi i dati utente per scopi pubblicitari. Se scegli come target i dispositivi con i servizi Google Play, ti consigliamo di utilizzare l'ID set di app.
• ID Firebase (FID): un FID è limitato all'app che lo crea, il che impedisce l'utilizzo dell'identificatore per monitorare gli utenti nelle app. Inoltre, è facilmente reimpostabile, poiché l'utente può cancellare i dati dell'app o reinstallare l'app. La procedura di creazione di un FID è semplice; consulta la guida all'installazione di Firebase.

Sviluppo di app

Report sugli arresti anomali

In questo caso, l'app raccoglie dati su quando e perché si arresta in modo anomalo sui dispositivi di un utente.

Identificatore consigliato da utilizzare:FID o ID set di app

Perché questo consiglio?

L'ambito di un FID è limitato all'app che lo crea, il che impedisce l'utilizzo dell'identificatore per monitorare gli utenti nelle app. Inoltre, può essere reimpostato facilmente, poiché l'utente può cancellare i dati dell'app o reinstallarla. La procedura per creare un FID è semplice; consulta la guida alle installazioni di Firebase. Un ID set di app ti consente di analizzare il comportamento di un utente su più app di proprietà della tua organizzazione, a condizione che i dati utente non vengano utilizzati a scopi pubblicitari.

Report sul rendimento

In questo caso, l'app raccoglie metriche sul rendimento, come i tempi di caricamento e l'utilizzo della batteria, per contribuire a migliorare la qualità dell'app.

Identificatore consigliato da utilizzare: Firebase Performance Monitoring

Perché questo consiglio?

Firebase Performance Monitoring ti permette di concentrarti sulle metriche che ti interessano di più e di verificare l'impatto di una modifica recente nella tua app.

Test delle app

In questo caso, la tua app valuta l'esperienza di un utente con la tua app a scopo di test o debug.

Identificatore consigliato da utilizzare:FID o ID set di app

Perché questo consiglio?

Un FID ha come ambito l'app che lo crea, il che impedisce l'utilizzo dell'identificatore per monitorare gli utenti nelle app. Inoltre, può essere reimpostato facilmente, poiché l'utente può cancellare i dati dell'app o reinstallarla. La procedura per creare un FID è semplice; consulta la guida alle installazioni di Firebase. Un ID set di app ti consente di analizzare il comportamento di un utente su più app di proprietà della tua organizzazione, a condizione che tu non utilizzi i dati utente a fini pubblicitari.

Installazione cross-device

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

Identificatore consigliato da utilizzare:FID o GUID

Perché questo consiglio?

Un FID è progettato espressamente per questo scopo. Il suo ambito è limitato all'app, quindi non può essere utilizzato per monitorare gli utenti in diverse app. Inoltre, viene reimpostato al momento della reinstallazione dell'app. Nei rari casi in cui un FID sia insufficiente, puoi usare anche un GUID.

Sicurezza

Rilevamento di comportamenti illeciti

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

Identificatore consigliato da utilizzare: il token di integrità dell'API Google Play Integrity

Perché questo consiglio?

Per verificare che una richiesta provenga da un dispositivo Android originale, anziché da un emulatore o da un altro codice che simula un altro dispositivo, utilizza l'API Google Play Integrity.

Frode pubblicitaria

In questo caso, la tua app controlla che le impressioni e le azioni di un utente nella tua app siano autentiche e verificabili.

Identificatore consigliato da utilizzare:ID pubblicità

Perché questo consiglio?

L'utilizzo dell'ID pubblicità è obbligatorio per i casi d'uso pubblicitari, ai sensi delle Norme relative ai contenuti per gli sviluppatori di Google Play, poiché l'utente può reimpostarlo.

Gestione dei diritti digitali (DRM)

In questo caso, la tua app vuole proteggere l'accesso fraudolento alla proprietà intellettuale o ai contenuti a pagamento.

Identificatore consigliato da utilizzare: l'utilizzo di un FID o GUID costringe l'utente a reinstallare l'app per aggirare i limiti di contenuti, un onere sufficiente per scoraggiare la maggior parte delle persone. Se questa protezione non è sufficiente, Android fornisce un'API DRM, che può essere utilizzata per limitare l'accesso ai contenuti, e include un identificatore per APK, l'ID Widevine.

Preferenze utente

In questo caso, la tua app salva lo stato utente per dispositivo, in particolare per gli utenti che non hanno eseguito l'accesso. Potresti trasferire questo stato a un'altra app firmata con la stessa chiave sullo stesso dispositivo.

Identificatore consigliato da utilizzare:FID o GUID

Perché questo consiglio?

La persistenza delle informazioni tramite le reinstallazioni non è consigliata perché gli utenti potrebbero voler reimpostare le preferenze reinstallando l'app.