Quel falso senso di possesso. 

Sta facendo una certa impressione, in rete, la decisione di Google di imporre una disciplina di KYC agli sviluppatori. In termini pratici, questo significa che Google sta progressivamente richiedendo che chi distribuisce app per Android — non solo sul Google Play Store, ma sempre più anche fuori da esso — debba essere identificato in maniera verificabile, con nome legale, indirizzo, contatti reali, e in molti casi documenti ufficiali o dati aziendali.

Per le organizzazioni può essere richiesto anche un D-U-N-S number, cioè un identificativo formale d’impresa. Il punto che ha colpito molti non è semplicemente l’esistenza di controlli sul Play Store — che già da tempo richiede verifiche — ma il fatto che questa logica venga estesa sempre di più al concetto stesso di distribuzione software su Android certificato.

La timeline, infatti, è questa: Google ha avviato l’early access tra fine 2025, ha aperto la registrazione più ampia nel marzo 2026, e da settembre 2026 inizierà l’applicazione concreta nei primi paesi selezionati (Brasile, Singapore, Indonesia e Thailandia), con espansione globale prevista dal 2027 in poi.

In pratica, l’idea è che, progressivamente, per installare app su dispositivi Android certificati, queste app debbano risultare collegate a uno sviluppatore verificato.

È quindi partita la solita campagna di millennial bimbiminkia e farlocchi gen Z che, al grido di “il cellulare non è più tuo!”, si sono messi a fare le solite iniziative inutili che questo tipo di attivismo performativo produce regolarmente: raccolte firme, appelli pubblici, richieste all’Europa di intervenire, petizioni, indignazione seriale e tutta quella coreografia politica da social network il cui scopo reale, molto spesso, sembra meno quello di cambiare qualcosa e più quello di essere visti, notati, percepiti come ancora presenti nel dibattito.

Ovviamente, la risposta più ovvia è che a quello che dicono non credono nemmeno loro fino in fondo.

Perché il primo punto, quello più banale e più difficile da ignorare, è che si tratta sostanzialmente della stessa identica logica che Apple applica da sempre.

Apple, infatti, ha costruito il proprio ecosistema proprio sul principio opposto rispetto all’idea di apertura assoluta: controllo dell’App Store, identificazione rigorosa degli sviluppatori, approvazione centralizzata, possibilità di revoca, distribuzione regolata, e un modello in cui il dispositivo è tuo sul piano materiale, ma il sistema resta fortemente mediato da chi controlla la piattaforma.

Eppure non si ricorda una mobilitazione paragonabile.

Non si ricordano grandi petizioni popolari, né ondate di richieste all’Unione Europea per sanzionare Apple semplicemente perché Apple chiedeva da sempre esattamente quel livello di identificazione, controllo e gatekeeping che oggi viene improvvisamente descritto come una deriva intollerabile nel momento in cui Google adotta una traiettoria simile.

Questo, inevitabilmente, fa sorgere un dubbio piuttosto semplice: siamo davvero davanti a una battaglia di principio sulla libertà digitale, oppure alla solita indignazione selettiva, dove una misura diventa scandalosa solo quando arriva da un soggetto diverso da quello a cui ci si era già comodamente abituati?

Anche lo slogan secondo cui il cellulare “non sarebbe più tuo” è ridicolo per una ragione molto semplice: arriva con decenni di ritardo.

È una protesta tardiva, e proprio per questo suona più come posa che come presa di coscienza.

Sono anni — anzi, decenni — che i sistemi operativi proprietari non sono “tuoi” in alcun senso reale, se non quello estremamente limitato del possesso fisico dell’hardware su cui girano. E a dire il vero questo principio non riguarda solo gli smartphone, né solo Android o Apple: si applica normalmente a praticamente tutto il software proprietario moderno.

Il punto fondamentale è giuridico, non tecnologico.

La stragrande maggioranza degli utenti non ha mai davvero “comprato” il software che usa. Non Windows, non macOS, non iOS, non Android certificato, e nemmeno gran parte dei software commerciali tradizionali.

Quel software non è mai stato venduto nel senso classico del termine.

È stato ceduto in licenza.

E questa distinzione, che molti ignorano o fingono di ignorare, cambia tutto.

Ceduto in licenza significa precisamente che il prodotto non diventa vostro. Non ne acquisite la proprietà piena. Non possedete davvero il codice, né i diritti sostanziali su di esso. Il proprietario resta Microsoft, Apple, Google, Adobe, o chi per loro. Voi, in cambio di denaro — una tantum o tramite abbonamento — ottenete semplicemente il permesso di usare una copia, entro condizioni stabilite unilateralmente da chi detiene la proprietà.

In altre parole: pagate per l’uso, non per il possesso.

Questo significa che limitazioni, revoche, aggiornamenti forzati, restrizioni, modifiche contrattuali e controllo dell’ecosistema non sono una rivoluzione improvvisa del 2026.

Sono la normalità strutturale del software proprietario da oltre quarant’anni.

Di fatto, questo modello si consolida già dagli anni ’80, quando nascono le prime grandi licenze OEM e il software smette definitivamente di essere percepito come semplice prodotto accessorio dell’hardware, trasformandosi in business autonomo, formalizzato e legalmente blindato.

Da quel momento in poi, il paradigma cambia: non stai comprando davvero il software, stai comprando il diritto condizionato a usarlo.

Per cui sentirsi improvvisamente traditi oggi, come se fino a ieri il proprio telefono fosse stato uno spazio di piena sovranità individuale, richiede una certa dose di rimozione storica.

Il punto non è che “non è più tuo”.

Il punto, semmai, è che nella maggior parte dei casi non lo è mai stato davvero.

Non ricordo di avervi mai visti scandalizzati. Se lo scoprite solo ora, significa solo che siete una pila di ritardati. 

In questa situazione, il software che gira sui telefoni finirebbe di fatto per essere limitato a poche grandi aziende.

L’idea di fondo sarebbe semplice: concentrare il mercato nelle mani di soggetti grandi, ufficiali, identificabili, economicamente solidi, teoricamente più controllabili, e presumibilmente dotati di processi interni sufficienti a impedire infiltrazioni grossolane.

Secondo questa visione, se il software viene prodotto da aziende abbastanza grandi da essere sottoposte a controlli, audit, responsabilità legali e revisioni strutturate, allora il rischio dovrebbe diminuire. Non ci sarebbero “spie coreane” o qualche sviluppatore opaco che infila malware dentro una app apparentemente innocua, e anche se esistessero tentativi del genere, queste aziende avrebbero almeno gli strumenti — tecnici, organizzativi e finanziari — per fare code review, sicurezza interna, controlli di filiera e verifiche prima che il software finisca online.

Detta così, sembra quasi rassicurante.

Il problema è che questo ragionamento, appena lo si guarda un po’ più da vicino, comincia a scricchiolare.

Per esempio: davvero “grande azienda” significa automaticamente “buono”?

Non necessariamente.

Personalmente, non so davvero se userei con assoluta serenità un client di posta elettronica scritto da Palantir, o da una sua spin-off, o da un’azienda troppo intrecciata con apparati di intelligence, sorveglianza o interessi geopolitici poco trasparenti.

Perché a quel punto il problema non è più soltanto “può esserci malware?”, ma anche “di chi sono gli interessi di chi controlla il software che uso ogni giorno?”

E quindi il primo dogma — grande azienda uguale sicurezza uguale bene — comincia già a vacillare.

Essere grandi non significa necessariamente essere neutrali, benevoli o degni di fiducia. Significa, al massimo, essere più visibili. Ma visibile non è sinonimo di affidabile.

Anche il secondo argomento, cioè l’idea che le grandi aziende si facciano davvero tutto in casa perché “possono permetterselo”, secondo me merita una revisione piuttosto brutale.

La realtà è che moltissime grandi aziende fanno outsourcing.

Subappaltano codice. Esternalizzano sviluppo. Delegano moduli interi a contractor, società terze, team remoti, consulenze offshore, filiere opache e supply chain distribuite.

E nel momento in cui il codice viene spezzato, distribuito e affidato a una lunga catena di soggetti che lavorano al ribasso, il controllo reale tende inevitabilmente a diminuire.

Perché sulla carta puoi essere una multinazionale impeccabile.

Ma se parti del tuo software finiscono in mano a soggetti scelti principalmente sul criterio del costo, e magari affidati a intermediari che a loro volta subappaltano ancora, allora l’idea di una supply chain perfettamente blindata diventa molto più teorica che reale.

In altre parole: la dimensione aziendale non elimina automaticamente il problema della fiducia.

Lo sposta.

E spesso lo sposta soltanto più in alto, dentro strutture più complesse, più costose e più difficili da ispezionare davvero.

Anche il fatto che, se volessero, almeno POTREBBERO fare auditing e review del loro software è un argomento piuttosto fuorviante.

Perché nella realtà moltissime aziende non sviluppano dentro un laboratorio sterile, completamente autonomo, dove ogni singolo strumento è costruito, verificato e controllato internamente.

Sviluppano usando una quantità enorme di tool esterni.

Servizi di CI/CD. Pipeline automatiche. Framework. Librerie. Scanner. Tool di sicurezza. Plugin. Marketplace di automazione.

Un esempio enorme, quasi inevitabile, è GitHub.

GitHub non è semplicemente un posto dove carichi codice: è spesso l’intera infrastruttura operativa dentro cui quel codice viene testato, validato, compilato, distribuito e approvato.

Attraverso GitHub Actions, Pull Request automation, dependency checks, code scanning e workflow automatici, è possibile costruire sistemi sofisticatissimi che, almeno in teoria, dovrebbero controllare la qualità del codice, verificare vulnerabilità, impedire regressioni, e persino individuare comportamenti sospetti prima che qualcosa venga mergiato o distribuito.

A rigore di logica, tutto questo dovrebbe aumentare la sicurezza.

Il problema è che anche questi strumenti fanno parte della supply chain.

E se viene compromesso lo strumento che usi per controllare la sicurezza, allora il controllore diventa vettore di infezione.

È esattamente questo il motivo per cui alcuni attacchi recenti hanno spaventato così tanto il settore.

Uno dei casi più noti è stato il compromesso della supply chain legata a GitHub Actions, dove attaccanti sono riusciti a colpire componenti o dipendenze usate nei workflow automatici, trasformando strumenti di verifica e automazione in potenziali veicoli di esfiltrazione di segreti, token o codice malevolo.

Il caso più famoso non si chiamava “Morpheus”, ma uno degli esempi più citati è la compromissione di tj-actions/changed-files del 2025, in cui una GitHub Action molto diffusa è stata alterata per esfiltrare credenziali dai log di CI di migliaia di repository che la usavano. In pratica, aziende convinte di usare automazione per migliorare controllo e sicurezza si sono ritrovate con una componente trusted che poteva trasformare la pipeline in punto di esposizione.

Ed è proprio questo il punto.

Quando il software che controlla il tuo software viene compromesso, il problema diventa enormemente più grave.

Perché non stai più infettando soltanto un’applicazione finale.

Stai contaminando il processo stesso attraverso cui il software viene dichiarato “sicuro”.

In pratica: ogni volta che GitHub controllava la qualità del codice tramite quello strumento compromesso, rischiava di trasformare quel controllo in una possibile superficie d’attacco.

Un disastro, appunto.

Perché a quel punto non viene colpito solo il prodotto.

Viene colpita la fiducia nell’intero meccanismo di validazione.

Quindi no: l’idea che, se il software — cioè le vostre app — fosse prodotto soltanto da buoni, grandi, potentissimi, e quindi automaticamente sicurissimi pachidermi del mercato del software, allora tutto diventerebbe davvero più sicuro, secondo me non ha molto senso.

È una semplificazione quasi infantile.

Perché la dimensione aziendale, da sola, non elimina il problema della supply chain, non elimina la dipendenza da strumenti esterni, non elimina outsourcing, compromissioni, errori, incentivi distorti o infiltrazioni.

Al massimo cambia la scala del problema, e spesso ne aumenta l’impatto quando qualcosa va storto.

Un pachiderma può avere più soldi, più avvocati, più compliance e più auditing.

Ma può anche avere una filiera più lunga, più opaca, più burocratica, più frammentata e quindi, sotto certi aspetti, persino più difficile da controllare davvero.

Per questo l’idea “grande = sicuro” non regge automaticamente.

E così, Android cerca di mitigare.

Non necessariamente di risolvere, perché probabilmente non esiste una soluzione perfetta, ma di mitigare sì: ridurre superficie d’attacco, aumentare tracciabilità, rendere più costoso l’abuso, e soprattutto cercare di contenere quel caos strutturale che deriva da un ecosistema storicamente molto più aperto.

Il punto è che, quando si guarda al mercato reale, Apple — piaccia o no — rappresenta l’unico grande esempio industriale di ecosistema mobile fortemente controllato che, almeno sul piano della sicurezza del software scaricato attraverso il canale ufficiale, ha mostrato risultati percepiti come relativamente più stabili.

Non perfetti. Non immuni. Non moralmente superiori.

Ma, dal punto di vista di chi ragiona come piattaforma, abbastanza funzionanti da costituire un modello osservabile.

E quindi la traiettoria è abbastanza ovvia.

Se il sistema concorrente appare, almeno superficialmente, più efficace nel contenere certe categorie di rischio, è naturale che Google guardi in quella direzione.

Non perché Apple sia diventata improvvisamente il paradiso della libertà digitale.

Ma perché, sul piano puramente pragmatico della mitigazione, quello è il modello industriale già esistente che sembra aver prodotto risultati almeno parzialmente migliori rispetto al caos di un’apertura molto più estesa.

Su questo si aggiunge il problema del cosiddetto “layer 8”, cioè del fattore umano.

Perché non tutti gli attacchi alla supply chain passano necessariamente attraverso exploit tecnici sofisticati. A volte passano semplicemente attraverso esseri umani sotto pressione.

Anni fa, come si vide molto bene anche nel celebre caso legato all’ecosistema Node.js e alla libreria event-stream, lo sviluppatore o manutentore di un tool estremamente diffuso può ritrovarsi bersagliato da richieste continue di correggere bug, migliorare funzioni, sistemare problemi, rispondere a issue, subire lamentele, pressioni e, inevitabilmente, anche insulti.

Il suo software magari è diventato uno snodo fondamentale per migliaia o milioni di utenti, ma spesso dietro non c’è una grande azienda strutturata: c’è una persona, o pochissime persone.

E quando per mesi o anni ti arrivano addosso richieste, urgenze, critiche e aspettative, può facilmente nascere una sensazione molto semplice e molto umana: quella che fuori dalla porta ci sia una folla inferocita con fiaccole e forconi, pronta a linciarti se non sistemi tutto immediatamente.

Per chi non vive il settore, questa immagine rende bene il punto.

Non sei più soltanto uno sviluppatore.

Diventi quello che deve impedire alla folla di sfondare la porta.

Al punto che molti manutentori arrivano seriamente a pensare di mollare tutto, abbandonare il progetto, sparire, o cedere il controllo pur di liberarsi da quella pressione.

Ed è proprio lì che arriva il buon samaritano.

Il tizio che compare dicendo: “Ehi, ti do una mano. Ecco la patch che ti serve.”

In quel momento, non sembra un invasore.

Sembra uno che ti aiuta a tenere lontani i forconi.

Nel caso event-stream, il manutentore cedette spazio a un collaboratore apparentemente disponibile, che inizialmente sembrava semplicemente voler aiutare. Solo dopo emerse che quella fiducia aveva aperto la porta all’inserimento di codice malevolo destinato a compromettere utenti specifici.

Ed ecco che il software resta contaminato.

Non perché qualcuno abbia necessariamente sfondato il sistema con la forza, ma perché è entrato dalla porta principale, sfruttando stanchezza, pressione psicologica e fiducia.

Questo è il layer 8.

Il punto in cui la supply chain smette di essere solo una questione tecnica e diventa una questione profondamente umana.

Funzionerà?

No. Nel senso che non è una misura risolutiva, ma una misura di mitigazione.

E questa distinzione è fondamentale, perché mitigazione non significa che il problema è risolto. Significa, molto più modestamente, che si cerca di attenuarlo, ridurne frequenza, impatto o superficie d’attacco.

In pratica: non elimini il rischio, cerchi di renderlo più difficile, più costoso o meno devastante.

Apple, infatti, non è affatto invulnerabile ai problemi di assalto alla supply chain.

Al contrario.

Uno dei casi più celebri è stato XcodeGhost, emerso nel 2015.

In quel caso, alcuni sviluppatori cinesi scaricarono versioni compromesse di Xcode — cioè l’ambiente ufficiale di sviluppo Apple — da fonti non ufficiali, spesso perché i download dai server Apple erano lenti o difficili da raggiungere localmente.

Il risultato fu devastante proprio perché colpiva a monte.

Gli sviluppatori pensavano di usare lo strumento legittimo per creare app iOS sicure, ma in realtà stavano compilando software con una versione contaminata dell’IDE. Questo inseriva codice malevolo dentro applicazioni apparentemente normali, che poi venivano pubblicate sull’App Store ufficiale.

Quindi il malware non entrò aggirando Apple dall’esterno come farebbe un banale APK pirata.

Entrò passando attraverso la supply chain dello sviluppo.

App perfettamente “regolari”, firmate da sviluppatori apparentemente legittimi, finirono nello store ufficiale con componenti malevoli incorporati.

Tra le app colpite comparvero anche nomi molto noti sul mercato cinese, e milioni di utenti scaricarono software compromesso direttamente dall’ecosistema più controllato del settore.

Questo è il punto.

Anche un sistema rigidamente centralizzato come Apple può essere colpito, se l’attacco avviene abbastanza a monte da contaminare gli strumenti, i processi o i componenti di fiducia.

Per questo motivo, anche l’esempio Apple non dimostra che il controllo totale risolve il problema.

Dimostra semmai che nessuna supply chain è davvero immune.

Al massimo, alcune riescono a reagire meglio, più rapidamente, o con meno esposizione media.

Ma “più sicuro” non significa “sicuro”. Significa soltanto “meno vulnerabile in certe condizioni”.

Come vedete, il problema è complicato.

Non è semplicemente il solito bianco e nero che i bimbiminkia millennials e i farlocchi gen Z vogliono raccontare, riducendo tutto a slogan da social, petizioni isteriche o pose ideologiche.

Non siamo davanti a una favola infantile dove da una parte c’è “la libertà” e dall’altra “il controllo”.

Si tratta, invece, di un fenomeno molto più complesso, strutturale e destinato con ogni probabilità a crescere sia in pericolosità sia in diffusione.

Perché più il telefono diventa il centro della vita digitale — banca, identità, comunicazione, lavoro, pagamenti, documenti, immagini, audio, autenticazione — più diventa anche il bersaglio ideale.

E più cresce questo processo, più cresce il rischio che tutte quelle cose comode che facciamo su quello strano computer che continuiamo a chiamare “cellulare” diventino così esposte a spionaggio, manipolazione, compromissione o sorveglianza da rendere il prezzo psicologico della comodità sempre meno accettabile.

In altre parole: se il telefono diventa troppo invadente, troppo fragile o troppo compromesso, prima o poi qualcuno comincerà seriamente a chiedersi se valga ancora la pena concentrare tutto lì dentro.

E questo scenario, per certe aziende, fa molta paura.

Perché il vero incubo industriale non è semplicemente vendere qualche telefono in meno.

Il vero pericolo è che il concetto stesso di smartphone come oggetto monolitico, totalizzante, centralizzato e costosissimo inizi a disgregarsi.

Che il telefono torni progressivamente a essere soprattutto un nodo di connettività.

Un hub.

Un oggetto che connette, ma non incorpora necessariamente tutto.

E allora telecamere e macchine fotografiche potrebbero separarsi di nuovo, diventando moduli esterni intelligenti collegati quando servono. Microfono e altoparlanti potrebbero seguire la stessa strada, come in parte è già successo con auricolari e dispositivi wearable. Il display stesso potrebbe progressivamente spostarsi verso occhiali, visori o interfacce distribuite.

A quel punto, il “telefono” non sparirebbe necessariamente.

Ma potrebbe frammentarsi.

Diventare una piattaforma distribuita, meno glamour, meno centralizzata, e forse molto meno adatta a sostenere il modello del dispositivo-premium da mille, duemila o tremila euro come centro assoluto della vita digitale.

E questo, per colossi come Apple o Google, rappresenta un pericolo strategico enorme.

Perché significherebbe non solo cambiare prodotto.

Significherebbe rischiare di perdere la centralità economica e simbolica del dispositivo attuale.

Esistono già proposte, visioni e tecnologi che immaginano scenari di questo tipo: ecosistemi modulari, wearable-first, computing distribuito, post-smartphone.

Per ora restano spesso nicchie, esperimenti o visioni da futuristi.

Ma il fatto stesso che esistano mostra che il modello attuale non è inevitabile.

Ed è proprio per questo che aziende come Apple e Google hanno tutto l’interesse a impedire che la fiducia nel telefono collassi fino al punto da spingere il mercato verso una vera disgregazione del concetto di smartphone.

Faranno quindi di tutto per mantenere il dispositivo abbastanza sicuro, abbastanza affidabile e abbastanza centrale da evitare quella fuga.

Si spera.

O forse no.