Android Developer Verification: F-Droid vede un rischio travestito da difesa

I gestori di F-Droid, store alternativo per Android dedicato alle app libere e open source, hanno scelto una parola pesante per descrivere la nuova verifica obbligatoria degli sviluppatori Android, annunciata da Google: malware. Non nel senso tecnico classico di codice progettato per rubare dati o prendere il controllo del dispositivo, ma come accusa politica e architetturale contro un componente che, secondo il progetto, potrebbe decidere quali applicazioni possono essere installate o eseguite sui dispositivi Android certificati.

Lo j’accuse pubblicato da F-Droid a inizio luglio 2026 ruota proprio attorno a questa provocazione: se un software lavora in background, arriva tramite un canale di sistema, non si può rimuovere facilmente e può bloccare programmi non approvati da un’autorità centrale, dove finisce la protezione e dove inizia il controllo?

Android, sideloading e il ruolo storico di F-Droid

Android ha costruito per anni una parte importante della sua identità sulla possibilità di installare applicazioni fuori dal Google Play Store, tramite file APK, repository indipendenti o store alternativi. F-Droid, attivo dal 2010, rappresenta una delle espressioni più note di questa tradizione: distribuisce software libero e open source per Android, ricompila molte app dai sorgenti e segnala agli utenti caratteristiche considerate indesiderate, come dipendenze proprietarie, tracciamento o funzioni anti-privacy.

Google presenta la nuova verifica degli sviluppatori come una risposta alla diffusione di frodi, app bancarie false e codice dannoso proveniente da fonti esterne. Secondo l’azienda, la quantità di malware rilevata da sorgenti esterne a Google Play sarebbe oltre 50 volte superiore rispetto allo store ufficiale.

Dal 30 settembre 2026 la verifica diventerà obbligatoria in Brasile, Indonesia, Singapore e Thailandia per le installazioni provenienti da alcuni store partecipanti, tra cui Google Play, Galaxy Store, HONOR App Market, OPPO App Market, Palm Store, V-Appstore e Xiaomi GetApps. La fase successiva prevede l’estensione globale nel 2027, anche in Italia.

F-Droid sottolinea che i primi quattro Paesi coinvolti sommano circa 580 milioni di persone e avverte che non sono ancora chiari tutti gli effetti pratici: cosa accadrà all’app F-Droid, alle applicazioni già installate tramite F-Droid, ai dati locali conservati da quelle app e alla telemetria inviata durante la verifica?

Che cos’è Android Developer Verification

Il programma Android Developer Verification introduce un requisito nuovo: per essere installate su dispositivi Android certificati, le app dovranno risultare associate a uno sviluppatore verificato. Google non dice di voler controllare preventivamente il contenuto di ogni applicazione distribuita fuori dal Play Store; sostiene invece di voler collegare app, identità dello sviluppatore e chiavi di firma, così da rendere più difficile “la vita” a un attore malevolo.

Il meccanismo tecnico si appoggia a un servizio di sistema che Google ha iniziato a distribuire nel giugno 2026 su gran parte dei dispositivi Android. F-Droid lo descrive come un processo installato tramite Play Protect, non disattivabile dall’utente comune e destinato ad attivarsi da remoto. Google, dal canto suo, parla di un nuovo servizio necessario per verificare la registrazione degli sviluppatori durante l’installazione delle app.

Chi distribuisce app soltanto fuori da Google Play deve usare la Android Developer Console, completare la procedura di identità e registrare i nomi dei pacchetti delle proprie app. La documentazione ufficiale indica due passaggi principali: verifica dei dati personali e registrazione dei nomi di pacchetto. Nel caso di un’organizzazione possono servire informazioni aggiuntive, come un numero identificativo e la verifica del sito web; in alcuni casi Google può chiedere anche un documento governativo.

Per gli sviluppatori professionali è prevista una distribuzione completa, con app e installazioni senza limiti dichiarati. Per studenti, hobbisti e sviluppatori che condividono app con poche persone è previsto un account a distribuzione limitata, gratuito, senza documento governativo e senza il pagamento di alcun canone, ma con un vincolo forte: installazione su un massimo di 20 dispositivi esplicitamente autorizzati dagli utenti finali. Va detto però che questa soluzione non risolve il problema per molti progetti open source piccoli, usati da comunità più ampie e senza struttura commerciale.

Perché F-Droid parla di malware

L’articolo di F-Droid usa volutamente un linguaggio duro. Definisce il servizio installato sui terminali Android come un “trojan horse” non per sostenere che rubi password o cifri file, ma per evidenziare una somiglianza funzionale con alcune caratteristiche del software indesiderato: installazione silenziosa, privilegi elevati, dipendenza da un comando remoto e impossibilità per l’utente medio di rimuoverlo o neutralizzarlo.

La sicurezza mobile ha sempre avuto una componente di fiducia delegata. Su Android, Play Protect analizza applicazioni installate da Google Play e da altre fonti, controlla comportamenti noti come pericolosi e può avvisare l’utente.

Nel 2026 Google ha anche presentato funzioni di Live Threat Detection basate su analisi comportamentale sul dispositivo, capaci di osservare segnali come uso anomalo dei permessi di accessibilità, cambio o occultamento dell’icona, avvio in background e overlay (sovrapposizione ad altre app) potenzialmente ingannevoli. Sono misure difensive comprensibili, specie contro truffe bancarie e malware che abusano degli SMS o dei servizi di accessibilità.

La verifica degli sviluppatori, però, non guarda al comportamento dell’app dopo l’installazione; interviene prima, sul diritto di distribuire e installare software. Per F-Droid, con Android Developer Verification, la domanda non è più “questa app è pericolosa?”, ma “questo sviluppatore è autorizzato a farla arrivare sul dispositivo?”

La preoccupazione di F-Droid è che se Google diventa l’autorità unica che collega identità, chiavi di firma e valuta la possibilità di installare il software sui dispositivi certificati, allora la capacità di bloccare app non dipende più soltanto da una scansione di sicurezza. Dipende anche da regole contrattuali, interpretazioni dei termini di servizio, pressioni normative locali e interessi commerciali.

Firma, package name e chiavi private: il lato tecnico della verifica

Android identifica un’app anche attraverso il suo package name, per esempio una stringa nel formato com.nomeazienda.app, e attraverso la firma digitale dell’APK. La firma digitale serve a dimostrare continuità tra versioni della stessa app: un aggiornamento viene accettato solo se risulta firmato con una chiave compatibile con quella usata in precedenza. Da anni questa struttura protegge gli utenti da aggiornamenti falsi installati sopra app legittime.

Con la verifica obbligatoria, Google aggiunge un ulteriore livello: lo sviluppatore deve provare il controllo dell’app fornendo un APK firmato con la propria chiave privata, così da collegare il pacchetto all’account verificato. Non significa, almeno secondo la documentazione pubblica, che la chiave privata sia consegnata a Google; tuttavia, il rapporto tra identità, nome del pacchetto e firma entra in un registro centrale controllato dall’azienda.

Google ha anche annunciato API pensate per automatizzare la registrazione in massa e controllare se un package name risulta già registrato: la Android Developer ID Status API e la Android Developer Console API. Le API supporteranno anche deleghe tramite OAuth, così da permettere a store terzi di svolgere alcune operazioni per conto degli sviluppatori.

Se il nuovo modello richiede una corrispondenza rigida tra sviluppatore verificato, nome pacchetto e chiave, alcuni flussi di pubblicazione potrebbero diventare più fragili o richiedere accordi espliciti.

Cosa succede agli utenti e agli store alternativi

“Potrò continuare a installare app da fuori Google Play?” Google risponde di sì e sostiene che il sideloading non sparirà. L’azienda di Mountain View specifica che le app non registrate potranno ancora essere installate tramite ADB o attraverso un flusso avanzato con controlli di sicurezza, pensato per resistere alle truffe basate su coercizione e guida passo passo della vittima.

F-Droid contesta proprio questa definizione. Se un utente deve passare attraverso un percorso speciale, avvisi aggiuntivi, controlli centralizzati o strumenti da sviluppatore, l’installazione diretta sparisce del tutto: chi sa usare adb dalla riga di comando non rappresenta l’utente medio; chi installa app open source da un repository alternativo non sempre vuole diventare un power user.

Ancora, F-Droid teme che i repository indipendenti finiscano ai margini se non potranno operare secondo il proprio modello di fiducia. La lettera aperta di Keep Android Open chiede a Google di ritirare l’obbligo di registrazione per la distribuzione di terze parti ed è firmata da 71 organizzazioni di 23 Paesi, tra cui gruppi legati al software libero, alla privacy, ai diritti digitali e alla tutela dei consumatori.

Il 30 settembre 2026 rappresenterà il primo banco di prova. Se il nuovo servizio si limiterà davvero a bloccare installazioni rischiose e a lasciare canali ragionevoli agli utenti esperti, la critica perderà parte della sua forza. Se invece app legittime, repository indipendenti e progetti open source incontreranno blocchi opachi, l’accusa di F-Droid apparirà meno provocatoria e più concreta.