Google ha deciso di spostare il baricentro della sicurezza Android dal perimetro dell’app store al sistema operativo. Dal prossimo anno, gli sviluppatori che distribuiscono app su dispositivi Android certificati dovranno verificare la propria identità anche se pubblicano tramite store alternativi o con sideloading. L’apertura rimane un principio cardine della piattaforma, ma l’anonimato non sarà più parte del pacchetto: l’obiettivo dichiarato è tagliare le gambe ai “bad actors” che sfruttano canali fuori dallo store ufficiale per diffondere malware, truffare gli utenti o esfiltrare dati personali.
La mossa nasce da un dato che a Mountain View considerano dirimente: secondo una rilevazione interna, le infezioni sono “oltre 50 volte” più frequenti quando le app arrivano da fonti internet-sideloaded rispetto a Google Play, dove la verifica dell’identità è già obbligatoria dal 2023. È un numero che mette in prospettiva anni di dibattito tra libertà di installazione e igiene dell’ecosistema, e che spiega la decisione di estendere un controllo d’identità a livello di device, indipendentemente dal canale di distribuzione.
Il rollout non sarà istantaneo né monolitico. Da ottobre 2025 gli sviluppatori interessati potranno aderire a un programma di early access per testare il processo e dare feedback. A marzo 2026 la verifica andrà in generale availability per tutti; da settembre 2026 diventerà requisito per qualsiasi app installata su Android in Brasile, Indonesia, Singapore e Thailandia; nel 2027 partirà la diffusione globale, a ondate. La scelta dei primi Paesi non è casuale: sono mercati dove la circolazione di APK via canali informali è elevata, e dove l’impatto sulla riduzione del rischio può essere misurato più rapidamente.
Sul piano operativo, a chi firma o pubblica un’app verranno richiesti nome legale, indirizzo, e-mail e numero di telefono. È un set di attributi che rende tracciabile la responsabilità editoriale del software e che, prevedibilmente, spingerà molti indie a costituire una persona giuridica per non esporre dati personali nelle interazioni professionali. Google prevede anche una tipologia di account separata per studenti e hobbisti, a riconoscere esigenze diverse rispetto agli sviluppatori commerciali.
L’impatto sulla superficie d’attacco dell’ecosistema è potenzialmente significativo. L’anello debole del modello “open install” non è la tecnologia del pacchetto in sé — la firma dell’APK e i controlli a runtime fanno il loro — quanto l’asimmetria informativa: l’utente non ha segnali robusti sull’affidabilità del soggetto che distribuisce. Una verifica d’identità centralizzata ribalta la dinamica: il rischio di throwaway identity si alza di costo e diventa meno scalabile. Resta aperto il tema di come questi attributi verranno esposti, conservati e difesi: chi sarà il provider KYC, quali garanzie avrà il dato, quali meccanismi di ricorso saranno offerti agli sviluppatori in caso di contestazioni? Sono aspetti non secondari, specie in giurisdizioni con normative severe su privacy e due process, e che meriteranno analisi quando Google pubblicherà i dettagli implementativi.
Il confronto con Apple è inevitabile. Nel mondo iOS, l’associazione stretta tra identità e distribuzione è la norma da sempre: senza un account sviluppatore verificato non si entra nel giardino, e il sideloading è stato storicamente assente. Il quadro europeo però ha introdotto una variabile: per rispettare il Digital Services Act, Apple ha richiesto agli sviluppatori dell’App Store UE di dichiarare lo status di “trader”, ossia il profilo commerciale con cui operano. È un precedente che lega compliance regolatoria e trasparenza dell’offerente, e che Google esplicitamente richiama come contesto affine. La differenza sostanziale, oggi, è che Android non chiude alla distribuzione alternativa: mantiene la porta del sideloading aperta, innestando però un livello di accountability ex ante.
Per il settore cybersecurity, il passaggio è interessante anche come esperimento di supply-chain governance. Finora, i meccanismi difensivi Android si concentravano su analisi del codice e telemetrie comportamentali post-distribuzione; con la verifica identitaria, l’asticella si sposta verso la prevention by provenance. In concreto, campagne di malvertising e dropper che fanno leva su siti esca e canali social per spingere APK artefatti dovranno affrontare un attrito maggiore: o investono in identità “pulite” — aumentando costi e rischio d’esposizione — o cercano di compromettere account legittimi, spostando il baricentro dell’attacco verso phishing e furto di credenziali degli sviluppatori. È un ribilanciamento che sposterà inevitabilmente il TTP mix degli attori criminali.
Gli sviluppatori dovranno prepararsi a un on-boarding più simile a quello di un prestatore di servizi fintech che a un semplice upload di binari. La frizione burocratica potrà essere contenuta se Google riuscirà a offrire un flusso KYC snello, interoperabile con provider terzi e con una segmentazione chiara tra uso pubblico degli attributi e loro conservazione. L’annuncio di un canale dedicato per studenti e hobbisti è un segnale di sensibilità verso la long tail dell’ecosistema, ma il vero banco di prova sarà il design di UX e policy di appeal in caso di errori di verifica o false positive.
Resta l’inevitabile tensione tra sicurezza e diritti civili. L’eliminazione dell’anonimato nello sviluppo abbassa il rischio sistemico, ma toglie anche una protezione a ricercatori, whistleblower e creator in contesti sensibili. Qui Google cammina su un crinale sottile: dovrà dimostrare che la trasparenza richiesta agli sviluppatori non si traduce in una doxxabilità di massa, e che la raccolta di dati personali non diventa un bersaglio appetibile quanto e più dei device che intende proteggere.
In controluce, il parallelo con Apple racconta due filosofie che si avvicinano: da un lato il modello walled garden che rafforza gli obblighi di trasparenza in Europa per via regolatoria, dall’altro Android che conserva l’apertura ma introduce una cintura di identità verificata per ridurre l’entropia del wild APK West. Se il risultato sarà una riduzione misurabile della prevalenza di app malevole installate fuori dallo store, lo scopriremo nelle curve dei prossimi report. Per ora, la traiettoria è chiara: il futuro della sicurezza mobile passa sempre più dall’affidabilità di chi pubblica, non solo da ciò che pubblica.