Verifica sviluppatori su Android: KDE sostiene Keep Android Open contro lo stop alle app fuori Play Store

La campagna Keep Android Open nasce come risposta diretta a un cambiamento annunciato da Google: dal 2026 l’installazione di app su dispositivi Android “certificati” sarà subordinata alla registrazione e verifica dell’identità dello sviluppatore, anche quando la distribuzione avviene fuori dal Play Store. La questione tocca un punto storico dell’identità di Android, presentato sin dalle origini come piattaforma in cui utenti e sviluppatori possono scegliere canali alternativi e utilizzare il sideloading (installazione manuale delle app tramite file APK).

Oggi questa scelta riguarda una base enorme: a gennaio 2026 Android vale circa il 70% della quota mondiale dei sistemi operativi mobile, con iOS al 29%, secondo StatCounter.

In questo contesto, KDE ha dichiarato pubblicamente il proprio sostegno alla campagna, ricordando che una parte delle sue applicazioni è disponibile anche su Android, tra cui KDE Connect, Itinerary, Tokodon e una versione in lavorazione di Krita. La presa di posizione è motivata dall’impatto potenziale della nuova policy su distribuzioni indipendenti e comunitarie, che includono progetti di software libero e repository alternativi.

Che cosa prevede la nuova verifica degli sviluppatori su Android

Google descrive l’iniziativa come un nuovo livello di sicurezza pensato per ridurre il raggio d’azione dei criminali informatici e impedire la rapida ripubblicazione di software malevolo dopo un blocco. Il meccanismo è indicato come Android Developer Verification e, nelle comunicazioni ufficiali, non riguarda una revisione tecnica del contenuto dell’app ma la conferma dell’identità di chi la distribuisce.

Il cambiamento più significativo riguarda l’estensione del controllo anche fuori dal Play Store: dal 2026 tutte le applicazioni, per poter essere installate sui dispositivi Android certificati, dovranno essere associate a sviluppatori verificati, cioè identificati e approvati da Google tramite procedure di controllo dell’identità e dell’affidabilità. In Italia le nuove regole entreranno in vigore dal 2027 e, nel frattempo, Google ha provato a gettare acqua sul fuoco spiegando che maker, studenti, hobbisti e sviluppatori che condividono app Android con cerchie ristrette di utenti potranno usare account limitati che non richiedono alcuna verifica dell’identità.

La campagna Keep Android Open sintetizza la registrazione come un processo che può includere il pagamento di una fee, l’accettazione di termini e condizioni, la presentazione di documenti d’identità e la richiesta di associare le app a identificativi dichiarati, con l’effetto pratico di rendere “non installabili” nuove app provenienti da sviluppatori che non completano il percorso entro le scadenze.

Perché la campagna Keep Android Open parla di “chiusura” dell’installazione indipendente

La lettera aperta pubblicata su keepandroidopen.org contesta il principio di spostare il potere di gatekeeping oltre il marketplace di Google, sostenendo che l’obbligo di registrazione centralizzata trasferisce a un soggetto unico la possibilità di condizionare canali terzi, come download diretti, store alternativi, distribuzioni enterprise e repository comunitari.

Il testo insiste sul rischio sistemico: se l’installazione dipende dall’associazione a un’identità verificata e a un registro controllato da un solo attore, la sospensione dell’account o il rifiuto della verifica può diventare un punto di fallimento unico per tutta la distribuzione al di fuori del Play Store.

Un ulteriore asse della critica riguarda privacy e sorveglianza: l’obbligo, anche per chi non usa servizi Google, di consegnare dati identificativi e di legare l’attività di sviluppo a un registro centralizzato crea un dataset trasversale sull’intera filiera di sviluppo Android.

La lettera aperta evidenzia anche l’impatto sui contesti più vulnerabili, per esempio progetti civici, attivisti, organizzazioni umanitarie o sviluppatori in aree soggette a sanzioni o restrizioni, dove l’accesso alle infrastrutture di registrazione potrebbe non essere garantito.

Il punto più delicato per F-Droid e i repository comunitari

Per comprendere perché la misura è percepita come “esistenziale” da parte di molti, è utile guardare alla catena di fiducia dei repository alternativi.

F-Droid descrive il proprio modello come costruito su review del codice, build server e firma dei pacchetti, con l’obiettivo di distribuire binari verificabili rispetto al sorgente. In particolare, il progetto sottolinea due modalità: firma con chiave del repository oppure, quando possibile, distribuzione con chiave originale dello sviluppatore grazie al concetto delle build riproducibili, che consentono a terze parti di ricostruire lo stesso output binario a partire dal sorgente.

L’obbligo di registrare centralmente gli sviluppatori e “rivendicare” identificativi applicativi rischia di introdurre un vincolo esterno: un repository può compilare e firmare in modo trasparente, ma l’installazione sul dispositivo potrebbe comunque essere negata se lo sviluppatore non è verificato secondo le regole di Google.

Inoltre F-Droid evidenzia un conflitto operativo: il progetto non può forzare gli autori a registrarsi presso Google e, allo stesso tempo, non può “prendere possesso” degli identificativi delle app al posto loro senza alterare la titolarità e la governance della distribuzione.

Android aveva già meccanismi di sicurezza senza registrazione centralizzata

Una parte rilevante del dibattito è tecnica: la lettera aperta insiste sul fatto che Android integra già controlli di integrità e mitigazioni antimalware che non richiedono un registro globale degli sviluppatori.

Alla base, la piattaforma impone la firma delle app: AOSP (Android Open Source Project) prevede che ogni app debba essere firmata e sottolinea come il package installer rifiuti pacchetti non firmati.

Sul piano crittografico, la famiglia degli “APK Signature Scheme” rafforza progressivamente le garanzie contro manomissioni e downgrade; per esempio APK Signature Scheme v3 aggiunge informazioni utili alla rotazione delle chiavi e alla compatibilità tra versioni, mentre lo schema v4 supporta firme streaming e si appoggia a strutture ancora più evolute.

Accanto all’integrità, esistono controlli di sicurezza “sul campo”: Google documenta che Play Protect esegue scansioni contro applicazioni potenzialmente dannose anche se installate da “altre origini”, non solo dal Play Store, e nelle comunicazioni più recenti parla di volumi di scanning molto elevati e di blocchi di malware distribuito fuori dallo store ufficiale. La critica, quindi, non nega l’esistenza del problema malware, ma contesta che l’unica risposta efficace sia vincolare l’installazione alla registrazione obbligatoria presso Google.

Il concetto di dispositivo certificato

Infine va considerato il concetto di “dispositivo certificato”, che di fatto si collega sia ai requisiti di compatibilità sia alla presenza di componenti proprietarie, cioè elementi software non aperti e controllati da un’azienda. Il programma AOSP spiega che il programma di compatibilità si basa su due pilastri: il CDD (Compatibility Definition Document), un documento che stabilisce le caratteristiche tecniche che un dispositivo deve rispettare, e il CTS (Compatibility Test Suite), una serie di test che verificano in modo automatico che tali requisiti siano effettivamente soddisfatti.

Di conseguenza, un dispositivo certificato è quello che rispetta le specifiche del CDD e supera con successo i test del CTS. Nella pratica, però, il termine “certified” è spesso usato anche per indicare i dispositivi che hanno la licenza ufficiale per includere e preinstallare i servizi Google, cioè i Google Mobile Services, un aspetto che chiarisce perché questa definizione venga applicata soprattutto ai dispositivi destinati al mercato di massa.

Come potrebbe essere applicata la regola a livello di sistema

Google afferma che il nuovo requisito è una “core OS feature” e che non può essere disattivato, ma allo stesso tempo dichiara che continueranno a esistere percorsi per utenti esperti e sviluppatori.

La pagina di supporto cita due vie: un flusso basato su avvisi e passaggi aggiuntivi e l’uso di Android Debug Bridge (ADB) come metodo standard per build, test e installazione di app non verificate o modificate sul proprio dispositivo.

Qui emerge un limite informativo importante: i dettagli di implementazione, per esempio quali componenti eseguano materialmente il controllo (package installer, Play Protect, moduli aggiornati via sistema Google, integrazione con servizi di certificazione), non sono descritti in modo pubblico. La campagna Keep Android Open insiste proprio su questo punto: finché il flusso “avanzato” non è documentato e verificabile, l’interpretazione prudente è prendere alla lettera la regola generale, cioè che le nuove installazioni di app non registrate verranno bloccate sui dispositivi interessati dall’operazione messa in campo da Mountain View.

Perché KDE entra nel dibattito e cosa significa per le sue app

La presa di posizione di KDE non è un gesto astratto: il progetto ha applicazioni che raggiungono utenti Android e che spesso vengono adottate anche da comunità tecniche sensibili al tema della libertà di installazione.

KDE è una comunità internazionale di sviluppatori e volontari che realizza software libero e open source. Il progetto è noto soprattutto per KDE Plasma, un ambiente desktop completo per sistemi Linux che offre interfaccia grafica, applicazioni e strumenti per la gestione del sistema. Oltre al desktop, KDE sviluppa numerosi programmi multipiattaforma, utilizzabili anche su Windows, macOS e dispositivi mobili, con l’obiettivo di offrire soluzioni potenti, personalizzabili e rispettose della privacy degli utenti.

Come osservato in apertura, alcune applicazioni KDE sono disponibili anche su Android, tra cui KDE Connect (per collegare smartphone e computer), Itinerary (per organizzare viaggi), Tokodon (client per il social network Mastodon) e una versione di Krita (programma di disegno digitale) attualmente in fase di sviluppo.

Nel messaggio pubblicato su KDE Discuss, l’organizzazione richiama espressamente il rischio che piattaforme indipendenti siano penalizzate e invita Google a rivedere l’impostazione, collegando l’iniziativa alla lettera aperta della campagna.

Per un progetto come KDE, che vive su più sistemi operativi e che ha interesse a mantenere canali di distribuzione diversificati, la preoccupazione è duplice: da un lato la continuità di installazione e aggiornamento per utenti che scelgono store alternativi, dall’altro l’effetto di lungo periodo sullo spazio di sperimentazione, per esempio nightly build, versioni di test e fork comunitari, che storicamente hanno potuto circolare come APK senza passaggi burocratici centralizzati.