La rete funziona. Sono i punti di controllo dei servizi che abbiamo imparato a ignorare.
I server sono ancora accesi. Il servizio è sparito.
Immagina di amministrare un servizio online. I server sono accesi, il software funziona, il database risponde, i log non mostrano anomalie. La tua infrastruttura è in salute.
Eppure, per chi prova a raggiungerti, il servizio non esiste più.
Non è un crash. Non è un bug. Non è neppure, necessariamente, un attacco ai server. È sufficiente che qualcuno interrompa un anello della catena che permette agli utenti di trovarti, autenticarsi o pagarti.
È da qui che vorrei partire, perché il titolo è deliberatamente provocatorio: Internet è rotto. Ma non nel senso che molti immaginano. TCP/IP continua a funzionare. I router instradano pacchetti, i protocolli aperti fanno il loro lavoro, le reti continuano a comunicare. Quello che si è progressivamente concentrato è il controllo sui servizi che abbiamo costruito sopra la rete.
Abbiamo investito decenni nel rendere questi servizi più disponibili, più veloci e più semplici da usare. Molto meno, a volte, nel chiederci chi sia in grado di interromperli senza toccare una riga del nostro codice.
Autistici/Inventati: quando l’interruttore non è nel datacenter
Nell’agosto del 2026 il caso del collettivo italiano Autistici/Inventati ha reso questa domanda tutt’altro che teorica.
Il 26 agosto 2026 l’Office of Foreign Assets Control (OFAC), l’agenzia del Tesoro statunitense che amministra le sanzioni economiche, ha inserito Autistici/Inventati in un provvedimento di designazione come Specially Designated Global Terrorist (SDGT). Secondo il governo statunitense, il collettivo avrebbe fornito servizi e infrastrutture tecnologiche a reti estremiste violente e a soggetti già sanzionati. Autistici/Inventati ha respinto queste accuse, rivendicando il proprio ruolo di fornitore di strumenti di comunicazione e autodifesa digitale.
Due cose vanno dette con precisione. La designazione OFAC è un atto di sanzioni, non equivale di per sé a una condanna pronunciata da un tribunale italiano. E la ricostruzione dei fatti tecnici non richiede che il lettore condivida le posizioni politiche di una delle parti.
Il 28 agosto il dominio autistici.org è risultato irraggiungibile. Il collettivo ha individuato il problema al livello della gestione del dominio e del DNS, indicando un intervento del registro .org, Public Interest Registry. Non stiamo parlando di macchine distrutte o di server incapaci di eseguire il loro software. Il nome attraverso cui gli utenti raggiungevano quei servizi non conduceva più alla destinazione attesa.
Nei giorni successivi sono emerse anche conseguenze sui canali finanziari, secondo la documentazione pubblicata dal collettivo e le ricostruzioni giornalistiche. Il 6 settembre Autistici/Inventati ha annunciato la decisione di cessare le attività, considerando non sostenibili i rischi legali e operativi per il gruppo e per i suoi utenti.
Questo non significa che un singolo operatore abbia preso tutte le decisioni, né che l’OFAC abbia ordinato direttamente al registro di disabilitare il dominio: non è una conclusione dimostrata dalle fonti esaminate. Significa, però, che un servizio digitale può perdere raggiungibilità e continuità per effetto di decisioni prese in livelli diversi dalla sua applicazione.
C’è un altro episodio di quei giorni, l’intrusione nella piattaforma Noblogs, che va tenuto distinto dal blocco del dominio: un incidente di sicurezza applicativa non è automaticamente lo stesso evento di un intervento sul DNS. Mescolarli farebbe perdere proprio il punto tecnico che ci interessa.
E allora la domanda non è soltanto «chi aveva ragione nel caso specifico?». È anche: quali dipendenze possono rendere inservibile il nostro sistema anche quando il sistema, da un punto di vista informatico, è ancora in grado di funzionare?
Non è TCP/IP a essere rotto
Internet nasce e si sviluppa come rete di reti. Protocolli e standard aperti permettono a sistemi indipendenti di comunicare senza dover appartenere tutti alla stessa organizzazione. Questa caratteristica non è un dettaglio filosofico: è una scelta architetturale.
Per inviare una mail, in linea di principio, non serve che mittente e destinatario abbiano un account sulla stessa piattaforma. Possono esistere fornitori differenti, infrastrutture differenti e software differenti, purché interoperabili.
Prova a trasferire questa logica su molti dei servizi che utilizziamo quotidianamente: messaggistica proprietaria, social network, identità digitale, distribuzione delle applicazioni. In parecchi casi il valore dell’ecosistema è concentrato all’interno di un operatore, e uscire significa perdere contatti, dati, reputazione, accesso o funzionalità.
Non è una diagnosi nuova né confinata agli ambienti hacker. Il documento RFC 9518, dedicato alla centralizzazione e decentralizzazione degli standard Internet, descrive proprio il rischio che funzioni inizialmente aperte si concentrino a livello di servizi e applicazioni. Anche Internet Society continua a ricordare il ruolo degli standard aperti nel permettere interoperabilità e innovazione senza dover chiedere il permesso a una singola piattaforma.
Attenzione, però: la centralizzazione non è nata solo dalla pigrizia degli utenti o dall’avidità dei fornitori. Ha risolto problemi reali.
Gestire un servizio per milioni di persone richiede affidabilità, moderazione, strumenti antispam, recupero degli account, assistenza, protezione dagli abusi e un’esperienza d’uso che non costringa ogni utente a diventare amministratore di sistema. Le piattaforme hanno reso possibili servizi che una moltitudine di piccoli nodi indipendenti avrebbe avuto difficoltà a offrire con la stessa immediatezza.
La comodità è reale. Anche il prezzo in controllo.
Il problema comincia quando trattiamo quella comodità come una proprietà gratuita dell’architettura, ignorando il costo di uscita.
Sei punti in cui qualcuno può spegnere il tuo servizio
Proviamo a osservare una tipica applicazione web non dal punto di vista del suo diagramma Kubernetes o del suo bilanciatore, ma da quello delle dipendenze che ne consentono l’esistenza pubblica.
Naming. DNS, registrar e registri dei domini: il tuo server può essere disponibile, ma gli utenti potrebbero non riuscire a trovarlo attraverso il nome consueto.
Identità. Single Sign-On, recupero credenziali e fornitori di autenticazione: un’interruzione o una revoca possono impedire l’accesso a un servizio anche se il backend è sano.
Compute e distribuzione. Cloud, hosting e CDN: guadagniamo scalabilità e protezione, ma concentriamo anche una parte del controllo operativo.
Discovery. Motori di ricerca, social graph e sistemi di raccomandazione: puoi restare online e diventare praticamente invisibile al tuo pubblico.
Distribuzione software. App store, repository e canali di aggiornamento: la possibilità di installare o aggiornare un client dipende spesso da regole e operatori esterni.
Pagamenti. Banche, intermediari e circuiti: un servizio commerciale può continuare a erogare software ma perdere la possibilità di incassare o pagare i fornitori.
Non sono tutti punti di controllo equivalenti. Non sottostanno alle stesse leggi, non hanno le stesse procedure, non presentano gli stessi rischi. E non è vero che ogni intervento sia arbitrario o illegittimo: contrastare frodi, attacchi e attività illecite fa parte delle responsabilità di molti operatori.
La questione, dal punto di vista dell’ingegneria, è un’altra: esiste un percorso di continuità quando una di queste dipendenze viene meno?
Se la risposta è «no», abbiamo un single point of failure che potrebbe non apparire in nessuno dei nostri dashboard.
Alta disponibilità non significa autonomia
Un’azienda può avere una soluzione multi-AZ, un database replicato, backup testati, monitoraggio H24 e deployment automatizzati. Tutto corretto. Tutto utile.
Ma può avere, contemporaneamente, un solo registrar da cui dipende la propria identità pubblica, un unico sistema di login difficilmente sostituibile, dati esportabili soltanto in formati proprietari o una relazione contrattuale che non ha un piano realistico di uscita.
La prima categoria di problemi è quella che normalmente affrontiamo con l’alta disponibilità: componenti guasti, indisponibilità di zona, errori di configurazione, incidenti infrastrutturali.
La seconda è una questione di sostituibilità. Se un fornitore smette di erogare il servizio, revoca l’accesso o decide di interrompere il rapporto, quanto tempo impieghiamo a tornare operativi altrove? E quali elementi possiamo effettivamente portare con noi?
Un backup del database non garantisce di poter esportare identità, relazioni sociali, chiavi, reputazione e canali di distribuzione. Un cluster ridondato non garantisce che l’utente possa raggiungere il dominio. Un sistema impeccabilmente automatizzato può automatizzare anche una dipendenza dalla quale non sappiamo uscire.
In altre parole: HA non equivale ad autonomia.
E no, la soluzione non è necessariamente «ospitiamo tutto in casa». Il self-hosting trasferisce responsabilità: patching, sicurezza, disponibilità, backup, incident response. Per un’organizzazione piccola può essere persino una scelta peggiore se fatta per ideologia anziché per requisiti.
La sovranità digitale, come la intendo qui, non è l’assenza assoluta di fornitori. È la capacità ragionevole e dimostrabile di cambiare fornitore, conservare i propri dati e continuare a operare.
Privacy, decentralizzazione e sovranità non sono sinonimi
Sono tre concetti che spesso utilizziamo come se fossero intercambiabili. Non lo sono.
La privacy riguarda chi può leggere, correlare o trattare informazioni su di noi. Un servizio centralizzato può offrire tecniche robuste di protezione dei dati, così come un servizio distribuito può esporre informazioni sensibili per progettazione o cattiva configurazione.
La decentralizzazione riguarda la distribuzione del controllo e della possibilità di interrompere il sistema. Ma un insieme di nodi non è automaticamente immune a concentrazioni di governance, infrastruttura o potere economico.
La sovranità, infine, riguarda la nostra capacità di decidere e agire: possediamo le chiavi necessarie? Possiamo esportare i dati? Possiamo cambiare software o intermediario? Possiamo farlo in tempi compatibili con la continuità del servizio?
A me interessa soprattutto questa terza proprietà, senza fingere che le altre due siano irrilevanti.
Perché c’è una differenza enorme tra sentirsi indipendenti quando tutto funziona ed esserlo davvero quando smette di funzionare qualcosa di importante.
Il test del «provider spento»
Vorrei chiudere questa prima parte con quattro domande, semplici da formulare e meno semplici da affrontare quando ci si mette davvero davanti all’architettura di un servizio:
- I miei dati sono esportabili? E non soltanto sulla carta: ho mai provato a ripristinarli altrove?
- Posso cambiare fornitore? Con quali tempi, costi e rinunce funzionali?
- Chi possiede le chiavi? Quelle che permettono di accedere ai dati, controllare l’identità e autorizzare le operazioni importanti.
- Il servizio sopravvive alla revoca? Non necessariamente senza interruzioni, ma con una strada concreta per tornare operativo.
Non è un test che passa solo chi usa Linux, né un test che fallisce automaticamente chi utilizza servizi cloud. È un modo per misurare le dipendenze invece di trasformarle in convinzioni.
Il titolo di questo articolo è una provocazione. La risposta, però, non può limitarsi a indignarsi per un incidente, rimpiangere un’Internet che non esiste più o ripetere che «bisognerebbe decentralizzare».
Le alternative ci sono. Sono eterogenee, talvolta scomode, non sempre mature e non tutte risolvono lo stesso problema. Per raccontarle seriamente bisogna riconoscerne anche i costi.
Nella seconda parte partiremo proprio da qui: cosa succede se rinunciamo all’idea che un solo provider debba controllare ogni strato della nostra vita digitale? E se, per alcune comunicazioni, Internet stessa non fosse nemmeno indispensabile?