Android introduce la scansione locale delle immagini: perché fa discutere

Android sta preparando un’interfaccia che permette alle applicazioni di chiedere al sistema operativo di classificare contenuti potenzialmente sensibili direttamente sul dispositivo. La novità si chiama ContentSafetyManager e compare nella documentazione Android aggiornata ad agosto 2026. A prima vista potrebbe sembrare una semplice evoluzione delle funzioni di protezione già presenti nel sistema del robottino verde; guardando le API (Application Programming Interfaces) più da vicino, però, emerge un cambiamento molto più profondo.

La storia parte da Android System SafetyCore, componente del quale abbiamo già parlato e che è distribuito da Google sui dispositivi con Android 9 e versioni successive.

Il pacchetto, identificato come com.google.android.safetycore, ha attirato parecchie critiche quando molti utenti lo hanno trovato installato senza averlo richiesto esplicitamente. La descrizione “scansione dei contenuti” ha poi alimentato interpretazioni molto più estese rispetto al suo effettivo funzionamento.

ContentSafetyManager porta la classificazione dentro Android

Il passaggio interessante arriva con il nuovo pacchetto android.app.contentsafety. La documentazione Android include classi come ClassifiableContent, ContentClassificationResult e ContentSafetyManager: elementi che delineano una vera API attraverso la quale un’app installata può sottoporre un contenuto al servizio di sicurezza configurato sul dispositivo.

La classe centrale espone il metodo requestContentClassification(): l’applicazione prepara il contenuto, indica un Executor sul quale ricevere la risposta e registra un callback. Il servizio restituisce quindi uno dei quattro risultati previsti: TYPE_ALLOWED, TYPE_WARNING, TYPE_BLOCKED oppure TYPE_UNCLASSIFIED. L’ultimo valore entra in gioco anche quando il sistema non riesce a eseguire la classificazione o quando la funzione di sicurezza risulta disabilitata.

Non c’è quindi, almeno nell’API finora pubblicata, un risultato che classifichi in modo puntuale ciascun contenuto elaborato: il modello appare volutamente più generico.

La documentazione mostra però ancora l’indicazione API level 10000: Android usa questo valore nelle versioni di sviluppo della piattaforma, prima dell’assegnazione del livello API definitivo. Non significa quindi che qualsiasi applicazione presente oggi sul Play Store possa già sfruttare liberamente le nuove funzioni.

SafetyCore non legge automaticamente la galleria fotografica

Il sistema di classificazione non concede da solo l’accesso ai file dell’utente: un’app non può chiamare ContentSafetyManager e ottenere magicamente tutte le foto memorizzate sul telefono. Deve prima possedere una modalità legittima per accedere al contenuto che vuole sottoporre all’analisi.

Android ha progressivamente ristretto proprio questo genere di accessi. Lo Scoped Storage, il Photo Picker e i permessi granulari introdotti nelle versioni più recenti limitano la possibilità per un’app di attraversare indiscriminatamente lo spazio di archiviazione condiviso. Con il selettore fotografico, per esempio, l’utente può concedere accesso soltanto alle immagini scelte anziché all’intera libreria.

Da qui deriva un limite essenziale anche per l’eventuale abuso della nuova API. Un’app malevola che dispone già di ampi privilegi sui file potrebbe certamente tentare di classificare molti contenuti; ma il problema principale sarebbe a monte, cioè il fatto che quell’app possiede già l’accesso ai dati. ContentSafetyManager potrebbe facilitarne la categorizzazione locale, non aggirare il modello delle autorizzazioni Android.

Il vero problema per la privacy è ciò che accade dopo la classificazione

Google afferma in modo piuttosto netto che SafetyCore esegue la classificazione sul telefono e non invia ai server Google né il contenuto classificato né il risultato ottenuto: fotografie potenzialmente intime possono rimanere all’interno del dispositivo.

La proprietà “on-device“, però, non rende automaticamente innocua qualsiasi applicazione che utilizzi un classificatore. L’elaborazione locale protegge il percorso verso Google, non necessariamente il comportamento dell’app chiamante.

Se un software possiede accesso a un’immagine, nulla vieta tecnicamente che gestisca quel dato secondo le proprie autorizzazioni e le proprie logiche, nei limiti imposti dal sistema operativo e dalle policy dello store.

Bisognerà quindi capire quali applicazioni potranno richiamare realmente l’API, quali controlli accompagneranno le richieste, quali categorie saranno supportate e quanto risulteranno trasparenti le impostazioni per l’utente.

C’è poi il problema dei falsi positivi e dei falsi negativi. Google stessa avverte che il meccanismo basato su Sensitive Content Warnings può classificare erroneamente immagini innocue oppure non riconoscere materiale effettivamente sensibile. Qualunque meccanismo futuro utilizzi classificatori probabilistici dovrà tenerne conto: un valore TYPE_BLOCKED non equivale a una dimostrazione incontrovertibile sulla natura del file.

Il parallelo con Chat Control: il problema non è soltanto dove avviene la scansione

La presenza di un classificatore locale richiama inevitabilmente il dibattito europeo sul cosiddetto Chat Control. Il regolamento UE 2021/1232, entro condizioni molto precise, consente già ai fornitori di servizi di comunicazione di utilizzare volontariamente tecnologie per individuare materiale relativo ad abusi CSAM.

ContentSafetyManager non nasce come strumento Chat Control e oggi non esiste alcuna indicazione che Google intenda utilizzarlo per analizzare in massa fotografie o conversazioni.

L’aspetto da osservare è piuttosto tecnico: Android sta costruendo una infrastruttura standard per classificare contenuti direttamente sul dispositivo. In futuro un’app potrebbe consegnare un contenuto al sistema e ricevere semplicemente un risultato come allowed, warning o blocked, senza incorporare un proprio modello di riconoscimento.

È qui che emerge il tema del client-side scanning. Una scansione eseguita sul terminale di proprietà dell’utente finale non richiede di spezzare la crittografia end-to-end: il contenuto può essere analizzato quando è ancora in chiaro sul telefono, prima dell’invio oppure dopo la ricezione. Dal punto di vista della privacy, quindi, “elaborato localmente” non equivale automaticamente a “privo di conseguenze”. Tutto dipende da chi decide che cosa classificare, quali categorie utilizzare e soprattutto che cosa accade dopo un risultato positivo.

La preoccupazione più fondata riguarda il possibile ampliamento progressivo delle finalità. Oggi SafetyCore serve, tra le altre cose, a riconoscere immagini con possibile nudità in Google Messaggi e Google afferma che contenuti e risultati non raggiungono i propri server. Una API generalizzata rende però tecnicamente più semplice estendere in futuro la classificazione ad altre categorie. Non significa che una simile evoluzione sia prevista; significa che il sistema operativo dispone ora di una base tecnica che rende la domanda sulla governance molto meno teorica.