Come scoprire cosa raccolgono i tuoi SDK

Ogni requisito degli store sui dati si riduce a un unico elenco, e quasi nessuno lo mette per iscritto. La tua informativa sulla privacy, il tuo modulo Data safety e le tue risposte App Privacy sono tre versioni dello stesso elenco: farlo una volta, per bene, è tutto il lavoro.

Entrambi gli store sono espliciti sul fatto che il comportamento degli SDK conta come tuo. Google Play dice che la raccolta di dati “includes data collected and handled through any third-party libraries or SDKs used in their apps” («include i dati raccolti e gestiti tramite librerie o SDK di terze parti usati nelle loro app»). Apple ti chiede di identificare i dati che “you or your third-party partners collect” («tu o i tuoi partner di terze parti raccogliete»).

Passo 1: trova ogni SDK

Leggi i file, non affidarti alla memoria:

Piattaforma	File
Android	build.gradle / build.gradle.kts, libs.versions.toml, AndroidManifest.xml (permessi, meta-data)
iOS	Podfile, Package.swift, *.pbxproj, Info.plist (stringhe di utilizzo), *.entitlements
Flutter	pubspec.yaml
React Native / Expo	package.json, app.json

Includi le dipendenze transitive che non hai scelto tu: un SDK che si porta dietro una libreria pubblicitaria raccoglie ciò che raccoglie quella libreria.

Passo 2: leggi l’informativa di ciascun fornitore

La maggior parte dei fornitori seri pubblica una pagina che dice esattamente cosa invia il loro SDK, perché i loro clienti ne hanno bisogno per questi stessi moduli. Quella pagina, non un post di blog né una risposta su un forum, è la tua fonte.

Firebase è l’esempio pratico, perché Google pubblica una suddivisione per prodotto mappata sulle categorie App Privacy di Apple:

Prodotto Firebase	Cosa raccoglie, secondo la documentazione di Google
Analytics	App instance ID, proprietà utente, eventi, indirizzo IP
Crashlytics	Stack trace e stato dell’applicazione al momento del crash, informazioni su dispositivo e sistema operativo, più eventuali chiavi personalizzate, log e ID utente che alleghi tu
Cloud Messaging	Il token push associato a un ID di installazione dell’app; modello del dispositivo, lingua, fuso orario, versione del sistema operativo, identificatore e versione dell’app
Authentication	Identificatori che genera, più indirizzi email, numeri di telefono e nomi visualizzati dai provider di accesso che abiliti
Performance Monitoring	Metriche di prestazione come tempo di avvio e latenza di rete, informazioni su dispositivo e sistema operativo, indirizzo IP per la segmentazione geografica
Remote Config	Codice paese e lingua, fuso orario, versione del sistema operativo, identificatori dell’app e del bundle

Rileggi quella tabella se usi Crashlytics: l’ultima colonna dipende in parte da te. Le chiavi personalizzate e gli ID utente che alleghi ai report di crash sono dati che hai scelto di inviare, e vanno nella tua informativa con parole tue.

Altri fornitori con informative pubblicate da consultare direttamente: reti pubblicitarie (AdMob, AppLovin, Unity, ironSource), strumenti di attribuzione (AppsFlyer, Adjust), segnalazione degli errori (Sentry, Bugsnag), acquisti (RevenueCat, Adapty) e provider di autenticazione.

Passo 3: quando il fornitore non pubblica nulla

Capita, soprattutto con le librerie più piccole. In quel caso:

• Leggi il traffico di rete. Fai passare l’app attraverso un proxy e guarda cosa invia l’SDK. È l’unico metodo che non si può contestare, e risolve la questione in un pomeriggio.
• Leggi il codice sorgente, se è aperto.
• Chiedi al fornitore per iscritto e conserva la risposta.
• Valuta di rimuoverlo. Una dipendenza il cui comportamento sui dati nessuno vuole dichiarare è un rischio che ti porti dietro per comodità di qualcun altro.

Passo 4: trasforma l’elenco nei tre documenti

Un elenco, tre versioni, in quest’ordine:

1. L’informativa sulla privacy: categorie, finalità, terze parti nominate, conservazione, contatto.
2. Il modulo Data safety in Play Console: gli stessi fatti come caselle da spuntare.
3. App Privacy in App Store Connect: di nuovo gli stessi fatti, con le categorie di Apple.

Compilali a partire dall’elenco, mai l’uno dall’altro. Dove due non coincidono, lo store crede all’SDK: Google Play afferma che “when Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action” («quando Google rileva una discrepanza tra il comportamento della tua app e la tua dichiarazione, potremmo intraprendere le azioni appropriate, comprese misure di applicazione delle norme»).

Mantenerlo vero

L’evento che li invalida tutti e tre è sempre lo stesso: è cambiata una dipendenza. Metti una riga nella checklist di rilascio (è cambiata qualche dipendenza in questa release? se sì, ricontrolla l’informativa ed entrambi i moduli), perché entrambi gli store richiedono che restino accurati, non solo che lo fossero al lancio.

Cosa fa AppFoyer

Questo metodo è ciò che il nostro agente automatizza. Punta un agente di programmazione sul repository: legge quei file delle dipendenze, confronta ciò che trova con una mappa di SDK noti e redige l’informativa sulla privacy nominando le terze parti che ha trovato, indicando il file e la riga da cui viene ogni fatto, così puoi verificarlo invece di fidarti. Senza un agente, un breve modulo pone le stesse domande.

Ciò che produce è una bozza che rivedi tu. Non può vedere una libreria che non riconosce, e non pubblica mai nulla senza il tuo clic.

Le fonti ufficiali

• Privacy and security in Firebase e App Store data collection — Google. La tabella sopra viene da queste pagine; sono loro l’autorità, non questa.
• Provide information for Google Play’s Data safety section — Guida di Google Play Console
• App privacy details on the App Store — Apple