Autistici/Inventati e i rischi della black box sistemistica

Una vicenda che va separata dalle semplificazioni

C’è una questione, nella vicenda di Autistici/Inventati, che trovo tecnicamente molto più interessante della contrapposizione immediata fra chi legge le sanzioni statunitensi come la prova che l’organizzazione abbia favorito il terrorismo e chi, all’estremo opposto, considera qualsiasi domanda sui meccanismi di controllo del provider come un attacco alla privacy, perché entrambe le letture rischiano di saltare proprio il problema sistemistico che dovrebbe interessare chi progetta infrastrutture. Il 26 agosto 2026 l’OFAC (Office of Foreign Assets Control) del Dipartimento del Tesoro statunitense ha inserito Autistici Inventati nella SDN List con designazione SDGT, Specially Designated Global Terrorist, sostenendo che l’organizzazione avesse fornito supporto materiale o tecnologico e servizi a soggetti ed attività che Washington riconduce al terrorismo; il Tesoro statunitense descrive A/I come fornitore di hosting, email cifrata, chat, videoconferenza ed architettura digitale utilizzati anche da gruppi estremisti violenti e cita espressamente il PKK fra le organizzazioni sanzionate che avrebbero utilizzato i servizi. A/I respinge questa ricostruzione e sostiene di non avere ricevuto, prima della designazione, richieste di informazioni, ordini di rimozione oppure comunicazioni investigative relative ai soggetti alla base del provvedimento. Queste due affermazioni vanno tenute separate con una certa disciplina, perché la designazione OFAC è un provvedimento amministrativo statunitense con conseguenze economiche molto pesanti ma NON equivale ad una condanna penale italiana, mentre il fatto che un servizio informatico sia stato utilizzato da soggetti designati o indagati non dimostra automaticamente la consapevole collaborazione del gestore.

La misura ha avuto comunque effetti reali quasi immediati, perché il dominio autistici.org è diventato irraggiungibile a livello DNS, A/I ha attribuito l’intervento al registry del dominio .org, Public Interest Registry, il conto PayPal destinato alle donazioni è stato chiuso ed anche Banca Etica, che aveva il collettivo fra i propri clienti dal 2018, ha sospeso temporaneamente l’operatività del conto spiegando pubblicamente di avere dovuto innalzare drasticamente il profilo di rischio per la possibile esposizione a sanzioni secondarie. L’8 settembre A/I ha promosso un ricorso d’urgenza contro la banca e, nel frattempo, il collettivo aveva già annunciato la cessazione delle attività e la progressiva chiusura dei servizi, pubblicando indicazioni per permettere agli utenti di esportare posta, siti, blog e mailing list. Questo particolare conta molto dal punto di vista dell’ingegneria dei sistemi, perché una infrastruttura può essere tecnicamente ridondata, distribuita e capace di sopravvivere alla perdita di singoli server, ma essere ugualmente resa inoperativa da un evento che colpisce domini, pagamenti, rapporti bancari, fornitori oppure persone, cioè componenti che spesso non compaiono nei diagrammi dell’alta disponibilità ma fanno parte ugualmente del sistema reale.

Venticinque anni di infrastruttura indipendente, non qualche server improvvisato

Autistici/Inventati nasce nel 2001 dall’incontro di persone e collettivi attivi sui temi della tecnologia, della privacy, dei diritti digitali e dell’attivismo politico, offrendo negli anni email, siti web, mailing list, blog, messaggistica, videoconferenza ed altri servizi non commerciali finanziati attraverso donazioni, con richieste di accesso trattate manualmente e con una esplicita selezione basata sull’affinità con il progetto. È importante sottolinearlo perché A/I non è mai stato, nella propria stessa descrizione, un provider generalista che accetta automaticamente chiunque compili un modulo, ma una infrastruttura politica e tecnica autogestita che decide a chi offrire i propri strumenti, e proprio questa caratteristica rende ancora più interessante la domanda su come venissero separati il diritto alla riservatezza, la selezione iniziale degli utenti e la gestione successiva degli abusi.

La qualità tecnica del progetto emerge molto chiaramente dall’Orange Book e soprattutto dall’Orange Book 2 del 2022, che documenta l’architettura adottata a partire dal 2019 e descrive un sistema distribuito con livello pubblico e livello interno, reverse proxy facilmente sostituibili, dati degli utenti partizionati fra più server, comunicazioni interne protette, containerizzazione, separazione UNIX dei servizi, autenticazione centralizzata ridondata, Infrastructure as Code, Continuous Integration, monitoraggio, raccolta centralizzata dei log ed automazione delle operazioni. Non siamo quindi davanti ad una infrastruttura che abbia scelto di non sapere nulla di se stessa, anzi leggendo la documentazione emerge quasi il contrario, perché gli amministratori hanno costruito un sistema con metriche, alert, logging strutturato, Elasticsearch, Kibana, rate limiting, test di integrazione e procedure di riconciliazione dello stato. Questa è la prima correzione che considero indispensabile rispetto ad una lettura troppo semplice del caso, perché definire A/I una black box priva di osservabilità sarebbe tecnicamente falso.

Il punto interessante si trova altrove, cioè nel TIPO DI INFORMAZIONE che l’infrastruttura ha deliberatamente scelto di non registrare oppure di conservare soltanto per periodi molto brevi. L’Orange Book 2 tratta i log quasi come materiale radioattivo, descrivendo una strategia nella quale le informazioni problematiche, quando possibile, non vengono inserite nei log, altre vengono eliminate prima della scrittura su disco ed i dati più vecchi vengono cancellati dopo un intervallo relativamente breve. La documentazione afferma esplicitamente che gli indirizzi IP non vengono normalmente conservati nei log persistenti e precisa però che alcuni meccanismi, come quelli di rate limiting, possono conoscerli temporaneamente in memoria senza poterli correlare alle richieste degli utenti dopo il fatto. Qui non c’è incompetenza e nemmeno assenza di monitoraggio, c’è una decisione architetturale consapevole nella quale la privacy degli utenti viene considerata parte del threat model e quindi la riduzione del dato diventa essa stessa una misura di sicurezza.

La black box di cui parlo non è il blackbox monitoring dell’Orange Book

Uso l’espressione black box sistemistica con un significato volutamente diverso dal blackbox monitoring documentato dallo stesso Orange Book, perché nel linguaggio dell’osservabilità il blackbox monitoring è una pratica normalissima nella quale si verifica un servizio dall’esterno, per esempio controllando se una pagina risponde oppure se una porta è raggiungibile, senza preoccuparsi dei dettagli interni. Io mi riferisco invece ad una condizione di OPACITÀ OPERATIVA DELIBERATA nella quale alcune informazioni potenzialmente utili per comprendere un abuso non esistono più, oppure non sono mai state raccolte, proprio perché il sistema è stato progettato per non possederle.

Una scelta di questo tipo non è automaticamente sbagliata, ed anzi spesso è precisamente ciò che vogliamo ottenere. Se non memorizzo per anni gli indirizzi IP dei miei utenti, un attaccante che compromette il server non potrà rubare un archivio che non esiste; se separo il frontend dai dati, il sequestro di una macchina pubblica non espone automaticamente le caselle di posta; se limito l’accesso amministrativo ed uso credenziali diverse per ogni componente, riduco la superficie disponibile a chi compromette un singolo servizio. Questa è buona sicurezza, non oscurantismo. Ma ogni volta che elimino un’informazione devo contemporaneamente sapere QUALI DOMANDE NON POTRÒ PIÙ FARE quando qualcosa andrà storto, perché la minimizzazione dei dati non cancella soltanto il rischio di abuso di quei dati, cancella anche le future possibilità investigative che dipendevano da essi.

Il problema sistemistico nasce proprio qui e può essere formulato in maniera quasi banale, perché ogni controllo richiede un osservabile, ogni osservabile richiede qualche forma di informazione e quindi un’architettura che riduce l’informazione deve ridefinire anche i propri controlli. Se decido che non voglio sapere chi ha inviato una certa richiesta HTTP, posso ancora sapere quante richieste sta ricevendo il servizio, quale endpoint sta restituendo errori, quanta banda viene consumata ed eventualmente bloccare un comportamento anomalo in tempo reale, ma potrei non essere più in grado, una settimana dopo, di correlare quell’evento ad una specifica sorgente. Non è necessariamente un problema, purché quella perdita sia stata prevista e siano state progettate misure alternative compatibili con il rischio che vogliamo gestire.

Proteggere il contenuto non significa rinunciare a governare il servizio

La distinzione diventa molto più chiara prendendo un servizio di posta ipoteticamente dotato di cifratura end-to-end, nel quale le chiavi private rimangono sui dispositivi degli utenti e quindi il provider non possiede tecnicamente la capacità di leggere il contenuto dei messaggi. Questa impossibilità può essere una proprietà di sicurezza fondamentale, ma non impedisce al gestore di applicare rate limit, controllare il volume delle connessioni, riconoscere campagne automatizzate, impedire registrazioni abusive, gestire segnalazioni, sospendere un account oppure conservare per un intervallo strettamente necessario alcuni indicatori operativi che non rivelino il contenuto della corrispondenza. Il provider non deve trasformarsi nel lettore universale delle comunicazioni per conservare una capacità di governo dell’infrastruttura.

Lo stesso principio vale per i contenuti pubblici, nei quali il modello cambia ancora perché una pagina web accessibile a chiunque non possiede tecnicamente la stessa aspettativa di segretezza di una comunicazione privata cifrata. Se emerge una segnalazione circostanziata relativa ad una pagina pubblica, il provider può verificarla esattamente come potrebbe farlo qualsiasi utente di Internet, senza aprire una backdoor nella posta elettronica e senza trasformare il proprio logging in sorveglianza permanente. Ed è importante correggere anche qui una semplificazione che circola facilmente, perché dalla documentazione di A/I non emerge che tutto il suo web hosting fosse limitato esclusivamente a file statici senza supporto applicativo, l’Orange Book 2 documenta infatti account DAV, siti web e database MySQL destinati al web hosting, mentre l’esempio dettagliato di sito statico riguarda il sito principale dell’infrastruttura. Questo dettaglio non cambia il ragionamento generale, ma evita di costruire una valutazione tecnica su una caratteristica che la documentazione pubblica non supporta.

Sicurezza del sistema operativo, sicurezza applicativa, privacy, moderazione dei contenuti, prevenzione degli abusi ed incident response sono quindi problemi diversi che si intersecano senza coincidere. Posso avere server perfettamente patchati ed una pessima gestione delle segnalazioni, oppure una moderazione rigidissima ed una infrastruttura vulnerabile ad una banale escalation di privilegi, posso proteggere meravigliosamente la riservatezza della posta e non avere un piano per la perdita del dominio, oppure conservare ogni log possibile e scoprire ugualmente di non avere registrato proprio l’informazione necessaria per capire l’incidente. La sicurezza complessiva nasce dal modo in cui questi domini vengono combinati, non dalla perfezione di uno solo.

Autistici/Inventati aveva davvero rinunciato ai controlli? La documentazione dice di no

È proprio qui che un’analisi rigorosa deve fermare una tentazione molto forte, quella di usare la vicenda come prova che A/I avesse deliberatamente costruito un sistema nel quale gli amministratori non potessero fare nulla contro gli abusi. La documentazione pubblica non autorizza questa conclusione, perché la policy vietava diverse categorie di utilizzo, consentiva la sospensione o cancellazione immediata degli account in caso di abuso ed attribuiva ad A/I la possibilità di condurre indagini quando necessario per difendersi da contestazioni di terzi. Lo stesso sito descriveva le richieste di accesso ai servizi come manuali e dialogiche, non automatiche, mentre l’Orange Book mostra strumenti di monitoraggio, logging centralizzato, rate limiting ed autenticazione capaci di applicare controlli operativi.

Quello che la documentazione pubblica NON consente di stabilire, almeno con sufficiente certezza, è quanto fossero mature le procedure specifiche per gli abusi più gravi, quale fosse il volume delle segnalazioni ricevute, quanto tempo richiedesse normalmente l’intervento, quali criteri facessero scattare una escalation, se esistesse una revisione periodica dei contenuti pubblici segnalati e soprattutto se i servizi citati dalle autorità statunitensi fossero mai stati oggetto di comunicazioni specifiche alle quali A/I avrebbe potuto reagire. Il collettivo afferma di non avere ricevuto richieste o ordini preventivi connessi ai fatti alla base della designazione, ma questa rimane una affermazione della parte interessata finché non viene corroborata da documentazione indipendente, esattamente come le accuse statunitensi rimangono accuse amministrative e non devono essere trasformate da chi scrive in una sentenza penale che non esiste.

È quindi possibile formulare una domanda tecnica molto seria senza trasformarla in un’accusa: IL MODELLO DI PRIVACY DI A/I DISPONEVA DI CONTROLLI ABBASTANZA PROPORZIONATI AL TIPO DI RISCHIO CHE POTEVA EMERGERE DAI SUOI SERVIZI? Per rispondere servirebbero dati che oggi non abbiamo, e questo limite conoscitivo fa parte dell’analisi invece di essere un buco da riempire con supposizioni.

Il barista in buona fede e la differenza fra colpa e rischio gestionale

Per spiegare il punto trovo utile un’analogia con qualcosa che nel diritto amministrativo italiano esiste da molto prima di Internet, cioè l’articolo 100 del TULPS, che permette al Questore di sospendere la licenza di un esercizio nel quale siano avvenuti gravi disordini, che sia abituale ritrovo di persone pregiudicate o pericolose oppure che costituisca un pericolo per l’ordine pubblico e la sicurezza dei cittadini. La giurisprudenza e la stessa prassi amministrativa insistono sul carattere preventivo della misura, che può quindi operare indipendentemente dalla responsabilità personale dell’esercente, perché lo scopo non è necessariamente punire il barista ma interrompere una situazione considerata pericolosa.

L’analogia con un provider informatico è naturalmente imperfetta e non deve essere forzata, perché cambiano la natura del servizio, i diritti fondamentali coinvolti, le norme applicabili, la possibilità di leggere ciò che accade ed il rapporto fra utenti e gestore, ma serve a separare due concetti che spesso vengono confusi, RESPONSABILITÀ PENALE e RESPONSABILITÀ GESTIONALE DEL RISCHIO. Un barista può essere perfettamente in buona fede e subire ugualmente le conseguenze preventive di una situazione che si è sviluppata nel proprio locale, così come un amministratore di sistemi può non avere alcuna intenzione di favorire un abuso e trovarsi ugualmente davanti alla necessità di dimostrare che il proprio servizio disponeva di procedure ragionevoli per affrontarlo.

Questo non autorizza a trasformare il provider in un investigatore privato e soprattutto non autorizza la sorveglianza indiscriminata delle comunicazioni, perché una piattaforma di posta elettronica non è un locale pubblico nel quale un gestore vede fisicamente chi entra ed esce. Richiama però un principio di prudenza che considero valido per qualunque sistema complesso, cioè che NON POSSIAMO CONSIDERARE RISOLTO UN RISCHIO SOLTANTO PERCHÉ ABBIAMO PROGETTATO L’ARCHITETTURA IN MODO DA NON POTERLO OSSERVARE DIRETTAMENTE.

La buona fede dei progettisti e il rischio di una virtù portata troppo lontano

È soprattutto il lato umano di questa vicenda ad interessarmi, perché capisco perfettamente la mentalità di chi, dopo avere osservato per anni la commercializzazione dei dati personali, le violazioni di enormi archivi, la sorveglianza commerciale e la progressiva concentrazione del potere digitale, decide di costruire una infrastruttura nella quale determinate informazioni NON POSSANO essere accumulate. Una scelta del genere richiede competenza e spesso richiede anche più lavoro rispetto alla soluzione comoda nella quale si registra tutto per sempre, e sarebbe ingeneroso ignorare il valore tecnico e politico di un progetto portato avanti per venticinque anni da volontari proprio per offrire strumenti non commerciali di comunicazione.

Ma esiste un rischio tipico dei progetti costruiti attorno ad un principio etico molto forte, perché il principio può progressivamente diventare non soltanto un requisito ma la lente attraverso la quale giudichiamo qualsiasi altra esigenza. Chi ha costruito un sistema per impedire la sorveglianza può percepire ogni richiesta di maggiore osservabilità come un cedimento, mentre chi si occupa di sicurezza pubblica può compiere l’errore esattamente opposto e considerare sospetta ogni tecnologia che impedisca l’identificazione retrospettiva degli utenti. Entrambe le posizioni diventano pericolose quando smettono di ragionare in termini di threat model, proporzionalità e controlli alternativi.

La domanda corretta non è quindi «dobbiamo conservare gli IP oppure no?», perché un indirizzo IP può essere indispensabile per una funzione e completamente inutile per un’altra, la domanda è «quale minaccia stiamo cercando di gestire, quale informazione sarebbe necessaria per rilevarla, per quanto tempo dovremmo conservarla, chi dovrebbe poterla vedere e quale rischio aggiuntivo introduciamo proprio conservandola?». Questa è ingegneria della sicurezza, ed impedisce sia il riflesso del LOGGHIAMO TUTTO, sia quello del NON VOGLIO SAPERE NULLA.

Il controllo non deve necessariamente conoscere il contenuto

Una architettura seria orientata alla privacy può mantenere una capacità di contrasto agli abusi senza introdurre una porta di servizio attraverso la quale gli amministratori leggano arbitrariamente le comunicazioni. Può applicare limiti di frequenza e volume, rilevare anomalie attraverso metriche aggregate, mantenere contatori effimeri, usare sistemi anti-automazione nelle procedure di registrazione, limitare le autorizzazioni degli account, ricevere segnalazioni strutturate, verificare i contenuti pubblici quando esista un motivo concreto, distinguere gli incidenti ordinari dalle minacce credibili ed imminenti e documentare le decisioni amministrative senza costruire un archivio permanente della vita degli utenti.

La cosa interessante è che l’Orange Book 2 mostra già una parte di questa filosofia quando spiega che il rate limiting può conoscere l’IP in memoria pur senza conservarlo stabilmente nei log, perché questo è esattamente il tipo di separazione che considero corretta, il controllo operativo utilizza temporaneamente l’informazione necessaria alla propria funzione ma l’infrastruttura evita di trasformare quella informazione in una cronologia persistente e correlabile. Il problema diventa quindi capire se meccanismi equivalenti esistano per tutte le categorie di rischio realmente importanti e se il progetto abbia definito cosa fare quando l’indicatore tecnico non basta, per esempio davanti ad una segnalazione credibile relativa ad un contenuto pubblico oppure ad un account.

Nessuna di queste misure garantisce di scoprire ogni abuso, perché una organizzazione criminale che utilizza comunicazioni cifrate, non genera anomalie tecniche e non viene segnalata può rimanere invisibile al provider, esattamente come potrebbe farlo utilizzando molti altri strumenti di comunicazione. La sicurezza assoluta non esiste e pretendere che un provider sappia sempre chi siano realmente i propri utenti significherebbe distruggere molti degli strumenti che proteggono giornalisti, dissidenti, vittime di violenza, ricercatori e normali cittadini. Il discrimine sta altrove, cioè nel poter dimostrare che il rischio è stato considerato, che esistono procedure proporzionate e che ciò che il sistema ha deciso di non conoscere NON rende impossibile ogni forma di intervento quando emergono informazioni attendibili.

Quando il problema non è più informatico: dominio, banca e dipendenze invisibili

La vicenda A/I offre una seconda lezione che considero altrettanto importante, perché mostra quanto sia riduttivo progettare la resilienza contando soltanto server, replica, backup, failover e gruppi di continuità. L’Orange Book nasce anche dall’esperienza di sequestri, compromissioni e necessità di distribuire i dati in modo che la perdita di una macchina non comprometta tutti gli utenti, ed è un modello tecnicamente sensato, ma nel 2026 l’effetto operativo più grave non è arrivato dalla distruzione dei server, è arrivato da dipendenze giuridiche e commerciali esterne all’infrastruttura.

Il dominio autistici.org è diventato irraggiungibile senza che fosse necessario penetrare un server, PayPal ha interrotto il rapporto e Banca Etica ha sospeso l’operatività del conto spiegando che continuare la relazione avrebbe potuto esporre l’istituto al rischio di sanzioni secondarie capaci di compromettere servizi essenziali per tutti i suoi clienti. OFAC aveva contemporaneamente emesso la General License 36 proprio per autorizzare il wind-down di determinate transazioni con A/I entro un periodo definito, un dettaglio che mostra quanto rapidamente una questione geopolitica possa trasformarsi in un problema di continuità operativa.

Qui entra in gioco anche il de-risking, cioè la scelta di interrompere una relazione non perché ogni singola operazione sia certamente vietata ma perché il rischio legale, finanziario o reputazionale viene considerato troppo elevato, e l’overcompliance, nella quale aziende e intermediari applicano restrizioni più ampie di quelle strettamente necessarie per ridurre il rischio di violare un regime sanzionatorio. Il rapporto delle Nazioni Unite A/HRC/51/33 del 2022 è dedicato proprio alle sanzioni secondarie ed agli effetti dell’overcompliance, osservando come il timore delle conseguenze possa scoraggiare perfino transazioni altrimenti consentite. Non serve quindi che un hard disk venga sequestrato perché un servizio scompaia, basta talvolta che le componenti esterne dalle quali dipende decidano che mantenerlo in vita sia diventato troppo rischioso.

Il disaster recovery deve contemplare anche la morte giuridica del provider

Da sistemista, questo è forse uno dei punti che mi lascia più materiale su cui riflettere, perché normalmente un piano di disaster recovery considera incendio, guasto, perdita di un datacenter, attacco ransomware, errore umano, corruzione dei dati e magari compromissione delle credenziali, ma raramente contempla uno scenario molto più strano, il provider continua tecnicamente ad esistere mentre diventa improvvisamente quasi impossibile pagare fornitori, mantenere domini, ricevere donazioni oppure consentire a terzi di avere rapporti con lui.

A/I ha pubblicato procedure per esportare i dati e, dopo la decisione di cessare le attività, ha cercato di accompagnare gli utenti verso la migrazione, mentre Noblogs è stato per un periodo reso disponibile in sola lettura dopo un distinto incidente di sicurezza. Come principio generale, però, un servizio che vuole sopravvivere nel tempo dovrebbe progettare anche la possibilità che L’ORGANIZZAZIONE CHE LO GESTISCE SMETTA DI ESSERE OPERATIVA, prevedendo formati di esportazione standard, identità non eccessivamente dipendenti da un singolo dominio, procedure documentate di migrazione, backup realmente controllabili dagli utenti e magari meccanismi che consentano ad un nuovo soggetto giuridicamente indipendente di offrire servizi compatibili senza dover ricevere automaticamente dati, beni oppure credenziali dal precedente gestore.

Naturalmente, quando esistono sanzioni, una simile continuità non può diventare uno stratagemma per aggirarle e deve essere valutata da specialisti del diritto applicabile, ma sul piano architetturale la lezione rimane valida, perché un servizio resiliente dovrebbe rendere gli utenti meno dipendenti possibile dalla sopravvivenza del gestore. Il backup più importante, in questo scenario, non è quello del server ma quello della CAPACITÀ DELL’UTENTE DI ANDARSENE.

Privacy e anonimato sono diritti da proteggere, non difetti da correggere

Tutto questo ragionamento avrebbe un difetto grave se facesse passare l’idea che cifratura ed anonimato siano anomalie da tollerare soltanto finché non disturbano le indagini, perché il rapporto del Relatore speciale ONU David Kaye del 2015 ricorda esattamente il contrario, cioè che cifratura ed anonimato forniscono agli individui uno spazio necessario per esercitare libertà di opinione, espressione e privacy e meritano quindi una protezione forte, mentre eventuali limitazioni devono rispettare legalità, necessità e proporzionalità.

Per questo l’obiettivo ingegneristico non può essere creare un provider onnisciente, perché il provider onnisciente è esso stesso una minaccia, diventa un enorme punto di concentrazione di dati, una preda formidabile per gli attaccanti ed uno strumento potenzialmente utilizzabile da governi, aziende oppure amministratori infedeli. La domanda progettuale corretta è molto più difficile ed anche molto più interessante, cioè COME POSSO CONSERVARE LA MINIMA INFORMAZIONE NECESSARIA PER GOVERNARE IL SERVIZIO SENZA CREARE LA MASSIMA INFORMAZIONE POSSIBILE SULLA PERSONA CHE LO USA?

Questa domanda non produce una risposta uguale per tutti. Un servizio di posta, un blog pubblico, una piattaforma di chat, un cloud storage ed un reverse proxy hanno superfici di rischio differenti, ed anche dentro lo stesso servizio una metrica aggregata, un log applicativo, un indirizzo IP, il contenuto di un messaggio ed una segnalazione ricevuta da terzi hanno funzioni completamente diverse. La minimizzazione seria non consiste nel cancellare tutto, consiste nel sapere perché ogni dato esiste e distruggerlo quando la sua funzione finisce.

La responsabilità di chi progetta sistemi destinati a durare

Chi costruisce un’infrastruttura destinata a migliaia di persone non può quindi limitarsi a chiedersi se il sistema funzioni nelle condizioni normali, deve immaginare che cosa succederà quando verrà abusato, sequestrato, sanzionato, denunciato, compromesso, abbandonato oppure semplicemente frainteso da un soggetto esterno molto più potente. Deve sapere quali comportamenti può rilevare e quali ha deliberatamente reso invisibili, quali informazioni può fornire a seguito di una richiesta legalmente valida e quali non potrà fornire perché non le ha mai possedute, deve sapere che cosa accade quando una segnalazione riguarda un contenuto pubblico, chi prende la decisione, quanto tempo ha per farlo, come viene documentata e come si impedisce che quella procedura venga utilizzata per censurare arbitrariamente utenti legittimi.

Questa è la parte nella quale tecnica ed organizzazione smettono di essere separabili, perché firewall, crittografia, logging e rate limiting non decidono da soli che cosa sia un abuso, mentre una policy scritta perfettamente ma priva degli strumenti tecnici necessari per essere applicata rimane soltanto un testo. Servono un threat model, procedure di escalation, ruoli, revisione periodica, audit, canali per le segnalazioni e soprattutto una documentazione capace di dimostrare le ragioni delle scelte, inclusa quella di NON raccogliere determinati dati.

Ed è proprio per i progetti con forti convinzioni etiche che questa disciplina diventa ancora più importante, perché quando lavoriamo per difendere un diritto possiamo finire inconsapevolmente per identificare la bontà dell’obiettivo con la correttezza di qualsiasi architettura scelta per perseguirlo. Ma una finalità meritoria non rende automaticamente perfetta la soluzione tecnica, esattamente come una architettura tecnicamente brillante non garantisce che tutti i suoi utilizzi saranno meritori.

La lezione di A/I non è che la privacy sia andata troppo lontano

Non sappiamo, sulla base delle informazioni pubbliche che ho potuto verificare, se Autistici/Inventati abbia effettivamente sottovalutato la gestione degli abusi e sarebbe scorretto affermarlo come fatto, sappiamo invece che possedeva policy di utilizzo, possibilità di sospensione degli account, monitoraggio, logging strutturato e sistemi operativi di controllo, sappiamo che minimizzava deliberatamente dati sensibili come gli indirizzi IP persistenti e sappiamo che il governo statunitense gli ha attribuito la fornitura di servizi e supporto tecnologico a soggetti che considera terroristi, mentre il collettivo respinge la ricostruzione e sostiene di non essere stato preventivamente coinvolto attraverso richieste o ordini relativi ai casi contestati. Tutto il resto deve essere dimostrato, non immaginato.

La lezione che ricavo dalla vicenda è quindi più generale e, proprio per questo, più utile, perché POSSIAMO PROGETTARE UN SISTEMA CHE NON SAPPIA MOLTE COSE DEI PROPRI UTENTI E DOBBIAMO SPESSO FARLO, ma non possiamo smettere di sapere quali rischi quella scelta rende più difficili da rilevare. Se elimino un dato devo sapere quale controllo perdo, se rendo impossibile una correlazione devo sapere quale incidente non potrò ricostruire, se non voglio ispezionare un contenuto devo progettare modalità alternative per reagire alle segnalazioni ed alle anomalie, e se una funzione non può essere svolta senza distruggere la privacy devo dichiarare esplicitamente che quel rischio rimane residuo invece di fingere che non esista.

È questa la black box sistemistica che mi preoccupa, non la crittografia e non l’anonimato, ma il momento nel quale una proprietà progettata per proteggere le persone diventa anche una zona che nessuno ha più il compito di governare. Non ho elementi per dire che Autistici/Inventati sia arrivata a quel punto, e proprio la documentazione tecnica pubblica mostra diversi segnali contrari ad una simile semplificazione, però il caso rende visibile il confine e ci obbliga a discuterlo.

Un buon amministratore non vede tutto, sa perché alcune cose non deve vederle

Forse la morale tecnica più importante è proprio questa, perché un buon amministratore di sistemi non è quello che riesce a vedere tutto ed accumula ogni log possibile, e non è neppure quello che considera la propria ignoranza una garanzia sufficiente di sicurezza. È quello che sa spiegare con precisione quali informazioni il sistema deve conoscere, quali NON DEVE conoscere, per quanto tempo possono esistere, quali soggetti possono accedervi, quale minaccia permette di contrastare ciascuna di esse e quali rischi rimangono inevitabilmente fuori dal perimetro.

La privacy è una responsabilità progettuale, ma lo è anche la resilienza, lo è l’incident response, lo è la gestione degli abusi e lo è la possibilità per gli utenti di sopravvivere alla scomparsa del provider. Portare una sola di queste virtù fino al punto di cancellare tutte le altre non produce necessariamente un sistema più etico, può semplicemente produrre un sistema più fragile.

Ed è qui che il caso Autistici/Inventati diventa interessante anche al di là di Autistici/Inventati, perché chi progetta con le migliori intenzioni può ugualmente non prevedere una minaccia, chi costruisce per difendere un diritto può trovarsi esposto da una dipendenza che non considerava parte dell’infrastruttura e chi decide correttamente di non raccogliere un dato può scoprire anni dopo che proprio quella scelta aveva un costo operativo che nessuno aveva formalizzato. Non significa che la scelta fosse sbagliata, significa che doveva avere un prezzo conosciuto.

In ingegneria dei sistemi questa è forse una delle differenze fondamentali fra una convinzione ed una architettura, perché la convinzione può permettersi di essere assoluta mentre l’architettura deve convivere con i compromessi, ed il compito del progettista non è farli sparire ma renderli visibili, misurabili e governabili. La riservatezza degli utenti è una responsabilità, ma lo è anche la sicurezza dell’infrastruttura che abbiamo scelto di mettere nelle loro mani!

Nota sull’analisi

Questo articolo esamina il caso come problema tecnico di architettura, osservabilità, privacy, incident response e continuità operativa, non attribuisce agli amministratori di Autistici/Inventati responsabilità penali o consapevole collaborazione con organizzazioni terroristiche e distingue espressamente le accuse formulate dal Dipartimento del Tesoro statunitense dalle posizioni del collettivo e dai fatti indipendentemente documentabili.