LaunchLint Academy
La risposta breve
- Data Safety descrive quali dati l’app raccoglie o condivide, perché e con quali pratiche di sicurezza e cancellazione. Anche senza raccolta bisogna compilare il modulo e collegare una informativa sulla privacy.
- package.json, configurazione e permessi sono segnali, non una dichiarazione completa. SDK, backend, consenso e trasmissioni reali vanno verificati.
- Crea una scheda per SDK ed endpoint, classifica collected e shared secondo Google e ricontrolla Play Console a ogni cambiamento rilevante.
1. Versione e dati coperti
Google richiede il modulo per app pubblicate in closed, open e production; solo internal testing è esente. La dichiarazione vale per il package e deve rappresentare gli artefatti attivi. Una vecchia versione distribuita può contenere SDK diversi.
La raccolta implica in genere trasferimento fuori dal dispositivo. L’elaborazione solo locale può essere esclusa. Un permesso non prova raccolta e l’assenza di permessi sensibili non prova assenza di telemetria, IP o identificatori.
3. Inventariare SDK Expo e dipendenze native
Expo astrae il progetto nativo senza eliminare la responsabilità. Analytics, crash, push, auth, mappe, ads, pagamenti e social login possono trasmettere dati. Verifica dipendenze dirette e transitive, produzione, moduli opzionali e inizializzazione prima del consenso.
Google rende il developer responsabile del codice terzo. Documentazione e Play SDK Index aiutano, ma decide la tua configurazione.
{
"sdk": "example-analytics",
"enabledInProduction": true,
"dataTypes": ["Device identifiers", "App interactions"],
"transmittedOffDevice": true,
"purpose": ["Analytics"],
"requiredOrOptional": "optional after consent",
"encryptedInTransit": true,
"deletionPath": "privacy@example.com"
}- package.json e lockfile
- Plugin app config
- Manifest e permessi
- Inizializzazione e consent
- Endpoint e upload
- Cancellazione e opt-out
- Variabili release
4. Scopo, scelta, cifratura e cancellazione
Seleziona solo gli scopi realmente usati. Optional richiede che l’utente possa evitare la raccolta; un toggle dopo l’inizializzazione non annulla il trasferimento precedente.
Dichiara cifratura solo se copre tutti i dati trasmessi. Controlla endpoint vecchi, upload, WebView e SDK. Distingui account, profilo, backup, conservazione legale e copie terze.
- Scopo per tipo e destinatario
- Required o optional testato
- TLS ovunque
- Conservazione nell’informativa sulla privacy
- Cancellazione in-app e web
- Abbonamenti e retention spiegati
5. La cancellazione account è prove
Se l’app crea account, Google richiede un percorso in-app e una risorsa web per chiedere cancellazione di account e dati. Il link può essere pubblico e deve portare al processo, non alla homepage.
Prova identificazione, conferma, tempi, stato e richieste incomplete senza sessione developer. Indica dati conservati legittimamente. Disattivare o disinstallare non equivale a cancellare.
6. Validare contro build e runtime
L’analisi statica priorizza domande senza sostituire l’osservazione. Installa il build production su un device pulito e prova primo avvio, consent, login, funzione, upload, acquisto, push e cancellazione. Registra servizi e destinazioni rete.
Confronta file del progetto, trasmissione, backend, documentazione SDK, informativa sulla privacy e modulo. Non indovinare i casi ambigui: chiedi e documenta la decisione.
- Inventario production congelato
- Consent prima dello SDK opzionale
- Tipi e scopi allineati
- Eccezioni documentate
- Cifratura e cancellazione testate
- informativa sulla privacy aggiornata
- Draft rivisto
- Responsabile e data
7. Mantenere Data Safety a ogni release
Nuovi analytics, auth, ads, upload o scopi backend possono cambiare le risposte. Inserisci la verifica nella Definition of Done e checklist release. Il diff di package.json è un buon segnale, ma anche una modifica server-side senza cambi mobile può alterare trattamento e finalità.
LaunchLint trova SDK, plugin, permessi, endpoint e segnali di cancellazione con prove di file, ma non esegue codice né osserva trasferimenti. La dichiarazione finale combina file del progetto, runtime, backend e console. Conserva copia del modulo, build verificato, data e responsabile per confrontare la release successiva.
Mantieni un registro decisionale per ogni risposta delicata: fonte consultata, owner del servizio, finalità confermata, retention e prova di cancellazione. Quando un provider modifica il proprio trattamento, puoi individuare subito le risposte da riaprire. Fai rivedere il draft sia a chi conosce il backend sia a chi conosce il percorso utente; una sola prospettiva può ignorare trasferimenti indiretti, feature flag o comportamenti disponibili soltanto in alcune regioni.
Controllo modifiche:
- SDK aggiunto, rimosso o aggiornato
- Nuovo scopo per dati esistenti
- Nuovo endpoint o provider
- Consent spostato o cambiato
- Retention o cancellazione diversa
- Nuova audience o regione
- Nuovo flusso upload
- Revisione del draft
Domande frequenti
Un’app senza raccolta deve compilare Data Safety?
Sì sui track rilevanti. Deve anche collegare una informativa sulla privacy e verificare gli SDK.
package.json può generare il modulo?
No. Non conosce completamente runtime, backend, scopi, consenso, retention, cancellazione, configurazione remota o differenze regionali del comportamento pubblicato. Serve inoltre una verifica del traffico reale, dei servizi backend e della documentazione aggiornata di ogni provider.
Un service provider è sempre sharing?
Non necessariamente; Google prevede eccezioni secondo rapporto e uso reale. Documenta la decisione.
Quando aggiornare?
Quando cambiano tipi, scopi, destinatari, SDK, consenso, sicurezza o cancellazione.