Android si riattiva 348 volte l'ora a schermo spento: cosa fa in background

Uno smartphone Android appoggiato sul tavolo, con schermo spento e nessuna applicazione aperta, non è affatto inattivo dal punto di vista della rete. Mantiene infatti attivi servizi di sincronizzazione, verifica degli aggiornamenti, gestisce notifiche push, aggiorna configurazioni e comunica periodicamente con le infrastrutture remote. Un nuovo test indipendente prova a quantificare quanto sia intenso questo traffico: su un Google Pixel 8 con configurazione standard, è stata rilevata una media di 348 comunicazioni verso infrastrutture Alphabet ogni ora, equivalenti a circa 8.362 nell’arco di una giornata.

Il report, aggiornato dopo alcune osservazioni critiche sulla metodologia, fotografa soprattutto la frequenza con cui Android contatta server Google. I payload protetti da TLS 1.3, invece, restano cifrati e non possono essere ricostruiti semplicemente osservando il traffico da un firewall.

Proprio qui sta la parte più interessante della ricerca: non tanto dimostrare che Android comunica con Google – circostanza già documentata dalla stessa azienda – quanto mettere a confronto configurazioni differenti sullo stesso tipo di hardware. Il divario tra Android standard, Android con alcune impostazioni di privacy disattivate e GrapheneOS offre infatti un’indicazione concreta dell’effetto prodotto dai servizi Google sul traffico in background.

Un Pixel 8 osservato per 72 ore senza toccarlo

Il test ha utilizzato Google Pixel 8 da 128 GB collegati a una rete Wi-Fi isolata: gli smartphone sono rimasti alimentati tramite USB Power Delivery, con display bloccato e senza interazione dell’utente, per 72 ore consecutive.

Il traffico non è stato analizzato attraverso un’app installata sul telefono. I ricercatori hanno preferito osservare ciò che attraversava il gateway: l’access point era collegato a un firewall pfSense, con acquisizione tramite tcpdump/libpcap e successiva analisi dei file di cattura mediante Wireshark e script Python.

Un gateway esterno è in grado di accertare i pacchetti che effettivamente lasciano l’interfaccia di rete. Gli autori definiscono “outbound request” tre categorie di eventi: un nuovo handshake TCP SYN, una query DNS univoca oppure una trasmissione su un socket diretto verso indirizzi appartenenti all’ASN 15169, uno degli Autonomous System utilizzati dall’infrastruttura Google.

Google Play Services pesa più di ogni altro componente

Secondo la classificazione proposta dagli autori, la quota più consistente proverrebbe da Google Play Services, con oltre 142 eventi l’ora e circa 7,8 MB al giorno. Seguono i servizi collegati alla localizzazione, con 84 eventi all’ora, e le funzioni di provisioning e configurazione del dispositivo, indicate a 48 eventi all’ora.

Google Foto risulterebbe associato a 28,5 comunicazioni orarie, Search e Assistant a 22, mentre Firebase Cloud Messaging si attesterebbe intorno alle 15. La parte attribuita a diagnostica e Crashlytics sarebbe molto più ridotta: circa 8 eventi all’ora.

La documentazione ufficiale di Google relativa all’Android Device Configuration Service spiega esplicitamente che i dispositivi Android inviano periodicamente informazioni ai server dell’azienda.

Tra i dati che Google dichiara di trattare figurano identificatori di dispositivo e account, caratteristiche hardware, versione del sistema operativo, versione dei componenti di sicurezza e informazioni relative alla connettività. La documentazione cita, tra gli esempi, IMEI, seriale del dispositivo, Android ID del Google Services Framework, indirizzi MAC, modello dello smartphone, stringa della build, indirizzo IP e informazioni sull’operatore SIM.

Google afferma che tali dati servono, tra le altre cose, a distribuire aggiornamenti compatibili, individuare attività sospette, gestire la sicurezza e ottimizzare il compromesso fra connettività e consumo energetico. Il Device Configuration Service, preso singolarmente, comunica a intervalli nell’ordine di alcuni giorni: non può quindi spiegare da solo le centinaia di eventi orari misurati dal test. Google Play Services comprende infatti molti altri sottosistemi e uno smartphone moderno mantiene parecchie attività asincrone anche quando l’utente non lo sta usando.

Perché anche la localizzazione può generare traffico con il GPS spento

Un altro punto sollevato dall’esperimento riguarda le reti Wi-Fi presenti nelle vicinanze: spegnere il GPS non equivale necessariamente a eliminare tutte le fonti utilizzabili per stimare una posizione.

Android dispone di funzioni dedicate alla scansione Wi-Fi e Bluetooth; Google descrive ufficialmente l’impiego di segnali provenienti da access point, reti cellulari, GPS e sensori per il servizio Precisione della localizzazione.

La documentazione di Google precisa inoltre che, quando tale funzione è attiva, sono raccolte periodicamente informazioni sui segnali wireless rilevati dal dispositivo allo scopo di alimentare il sistema di localizzazione crowdsourcing. Google dichiara di utilizzare a tale scopo identificatori temporanei casuali (che cambiano continuamente), non collegati direttamente a una persona o a uno specifico account.

Il socket che resta aperto per le notifiche push

Una parte del traffico periodico ha una spiegazione tecnica piuttosto semplice: Firebase Cloud Messaging (FCM): è il sistema utilizzato da moltissime applicazioni Android per ricevere notifiche anche quando non sono in primo piano.

Perché una notifica arrivi rapidamente, il dispositivo deve mantenere disponibile un canale verso l’infrastruttura Google. La documentazione Firebase indica le porte TCP 5228, 5229 e 5230, oltre alla 443; FCM utilizza normalmente la 5228 e Google raccomanda, negli ambienti protetti da firewall, di consentire il traffico verso gli indirizzi appartenenti proprio all’ASN 15169.

Il dominio mtalk.google.com compare inoltre nella documentazione ufficiale relativa alla configurazione dei firewall. Una connessione persistente verso tale servizio, quindi, non è di per sé un comportamento anomalo o nascosto: fa parte del meccanismo con cui le applicazioni ricevono notifiche push evitando che ciascuna di esse debba mantenere autonomamente una connessione permanente.

Bloccare indiscriminatamente mtalk.google.com con Pi-hole o AdGuard Home riduce certamente il traffico verso Google, ma può far sparire o ritardare le notifiche di applicazioni di messaggistica, sistemi di autenticazione, servizi bancari e numerose altre app.

Android con le opzioni privacy modificate: i contatti scendono a 194 l’ora

Il confronto interno allo studio diventa più interessante passando alle altre configurazioni. Con un Pixel ancora basato sul software Google, ma con le impostazioni di privacy considerate dal laboratorio disabilitate, il traffico scende da 348 a 194 eventi all’ora.

È una riduzione di circa il 44%. Il risultato suggerisce che intervenire sulle opzioni offerte dal sistema può diminuire sensibilmente alcune comunicazioni senza rinunciare all’infrastruttura Google. Non significa, però, trasformare Android standard in una piattaforma priva di servizi Google: Play Services continua a svolgere funzioni fondamentali e molte API utilizzate dalle applicazioni restano operative.

Disattivare alcune forme di raccolta dati è una misura molto meno invasiva rispetto alla rimozione completa dei componenti proprietari.

In pratica, su un Pixel significa intervenire nelle impostazioni dell’account e del sistema senza rimuovere Google Play Services: si può disattivare o limitare la memorizzazione delle attività di localizzazione nell’account Google, impedire l’invio facoltativo a Google di informazioni diagnostiche e sull’utilizzo del dispositivo e ridurre la personalizzazione pubblicitaria. Sono modifiche che incidono su alcune forme di raccolta dati, ma non eliminano i servizi che Android utilizza per notifiche push, aggiornamenti, provisioning, verifica delle applicazioni e altre funzioni di sistema.

Il risultato del test lo mostra bene: anche dopo avere spento queste opzioni, il Pixel continua a contattare endpoint come device-provisioning.googleapis.com, checkin.gstatic.com e play.googleapis.com. Gli autori rilevano quindi una riduzione sensibile del traffico, non la sua eliminazione.

GrapheneOS con Google Play sandboxed cambia completamente il risultato

Il progetto GrapheneOS consente di installare le versioni ufficiali di Google Play Services e Google Play Store, ma le esegue come normali applicazioni all’interno della sandbox standard di Android.

Sui dispositivi Android forniti dai produttori, Play Services integra funzionalità particolarmente profonde nel sistema.

GrapheneOS adotta una soluzione differente: Google Play non ottiene privilegi speciali e non agisce come backend generale dei servizi del sistema operativo. Le applicazioni Google funzionano grazie a un livello di compatibilità predisposto dal progetto e sottostanno alle normali regole di isolamento, ai permessi e ai profili utente.

Nel test, la configurazione con Sandboxed Google Play avrebbe prodotto soltanto 12 comunicazioni all’ora verso Alphabet: circa il 96,5% in meno rispetto alle 348 rilevate avvalendosi della configurazione standard.

Installando GrapheneOS senza Google Play Services, la misurazione riporta infine zero eventi all’ora verso infrastrutture Alphabet nel periodo osservato.

Va sottolineato bene, tuttavia, che la metrica riguarda esclusivamente le connessioni classificate come dirette a Google, in particolare verso ASN 15169. GrapheneOS possiede propri servizi e un proprio sistema di aggiornamento; il telefono può quindi collegarsi ad altri server anche quando non contiene software Google.

Bloccare i 42 endpoint con Pi-hole? Possibile, ma è una pessima scorciatoia

Gli autori dello studio hanno pubblicato anche una blocklist con 42 endpoint osservati nel corso dell’esperimento (“Pi-hole / DNS Blocklist“), utilizzabile con Pi-hole, AdGuard Home e strumenti simili.

Bloccare un dominio perché produce telemetria indesiderata può sembrare semplice; diversi endpoint Google svolgono però più funzioni contemporaneamente. Tagliare il traffico a livello DNS significa intervenire senza conoscere quale applicazione o quale funzione stia utilizzando in quel momento il servizio.

La stessa blocklist avverte che il blocco di mtalk.google.com interrompe FCM, mentre intervenire su play.googleapis.com può compromettere gli aggiornamenti dal Play Store. Gli autori segnalano inoltre possibili conseguenze sul provisioning e sui meccanismi di verifica richiesti da alcune applicazioni.

Un caso delicato riguarda Play Integrity API. L’API permette a uno sviluppatore di verificare, in momenti specifici, che una richiesta provenga dall’app prevista, installata attraverso Google Play e in esecuzione su un dispositivo che soddisfa determinati requisiti. Applicazioni finanziarie, videogiochi e servizi esposti ad abusi possono usare queste informazioni per decidere se consentire o limitare un’operazione.

L’uso di una blocklist aggressiva rischia di trasformare un intervento sulla privacy in un problema di affidabilità. Per chi vuole sperimentare, conviene quindi procedere per domini, osservare i log DNS e verificare quali funzioni smettono di funzionare; applicare in blocco decine di regole su uno smartphone principale è molto meno sensato.