Riflettere sul tema, necessariamente complesso, delle tecnologie digitali significa prendere in esame l'intreccio di relazioni tra mercato capitalistico, stati, “esperti”, utenti.
Si tratta di ragionare analiticamente e politicamente sulle implicazioni che queste tecnologie hanno sulla vita delle persone in termini di sicurezza, privacy, libertà e sui moti interni dell'economia capitalistica nel suo sforzo di mettere a valore non solo il capitale relazionale degli utenti - pensiamo a Google o Facebook - ma anche il lavoro volontario di molti programmatori e sviluppatori di software libero.
Più che di forze distinte e contrapposte si è di fronte a relazioni spurie, a contaminazioni e contraddizioni che rendono il quadro complesso e denso di sfumature.
Ciò che vorrei esaminare in questo testo sono le relazioni tra tecnologia, sapere e potere - con un'attenzione particolare al mondo del software libero - declinate nel contesto del capitalismo informazionale oligopolista e degli stati nella loro pulsione paranoide al controllo sociale.
Il pretesto è la scoperta di una falla di sicurezza in uno dei progetti FOSS (Free and Open Source Software) più largamente utilizzati dai server di tutto il mondo: OpenSSL. Heartbleed è il nome con cui è stato chiamato il bug che ha affetto questa libreria. Il momento di rottura, in cui il meccanismo si inceppa e sembra venire messo in discussione, è l'elemento esemplare che ci permette allora di vedere i nodi, le innervature, le reti di relazioni di cui è composto con maggiore chiarezza e nitidezza.

OpenSSL ovvero di comunicazioni (in)sicure

OpenSSL è una delle tante implementazioni del protocollo TLS (Transport Layer Security) che serve a cifrare le comunicazioni tra diverse macchine: ogni qual volta visitiamo una pagina web “https” stiamo utilizzando il protocollo TLS. Si tratta in sostanza di un insieme codificato di regole atte a garantire una comunicazione criptata tra due entità. OpenSSL è l'implementazione più diffusa, dal momento che viene utilizzata dal 66% dei server che costituiscono internet. Nello specifico, viene impiegata da siti e servizi web particolarmente diffusi (ad esempio Facebook, Twitter, Amazon, etc.).
Il progetto, nato nel 1998, è Free e Open Source e utilizza una licenza particolare e piuttosto problematica nel proprio rapporto con altre licenze di software libero più largamente utilizzate come GPL e LGPL. Nonostante sia largamente utilizzato, anche da parte di big corporations, il core team di sviluppo, al momento della scoperta della vulnerabilità, contava meno di una decina di persone di cui solo una lavorava a tempo pieno. Il metodo di reperimento dei fondi avviene, come per molti progetti FOSS, attraverso l'istituzione di una fondazione per raccogliere le donazioni della comunità. Le donazioni ricevute, fino all'annuncio di Heartbleed, erano di 2000$ l'anno. Il quadro, quindi, è quello di un progetto tanto fondamentale per le comunicazioni sicure in rete quanto scarsamente sostenuto, anche sul piano economico, dai suoi utilizzatori.

Per poter ragionare dell'impatto e delle implicazioni che il bug di OpenSSL ha avuto e sta avendo è necessario parlare delle sue caratteristiche tecniche e del processo che ha portato dalla sua scoperta al suo annuncio pubblico. Il primo elemento ci aiuta a comprendere l'entità della pericolosità del bug e a riflettere sul nesso tecnologie e potere, il secondo fornisce un inquadramento circa le relazioni e le dinamiche di sapere/potere tra big corporations e team che si occupano della revisione del codice alla ricerca di potenziali vulnerabilità. Entrambe impongono un ragionamento sulla tecnologia, nel suo incarnarsi in forme di assoggettamento e dominazione, e sulla funzione ambivalente della conoscenza nel suo istituire relazioni di potere: da un lato governamentale, che si sostanzia nella verticalità della distribuzione delle informazioni e del sapere tra “tecnici” e utenti; dall'altro di resistenza, nel momento in cui attiva processi di soggettivazione e di autonomia in opposizione alla pervasività delle forme di dominio.
Per comprendere la natura del bug possiamo utilizzare una metafora, perdendone in precisione dal punto di vista tecnico, ma guadagnandone in chiarezza. Immaginiamo, ad esempio, l'accedere alla nostra webmail come una forma di comunicazione cifrata tra noi ed il server che ospita il servizio. Il server gestisce la comunicazione con noi e con gli altri utenti (autenticazione, accesso ai servizi) immagazzinando alcune informazioni nella memoria RAM. Ogni qual volta eseguiamo qualche azione - come aprire una mail - interroghiamo il server che ci darà risposta anche utilizzando i dati presenti nella propria memoria RAM. La vulnerabilità heartbleed, spingendo oltre la metafora comunicativa, si manifesta nell'incomprensione da parte del server di una nostra richiesta: «server, restituisci la parola “mela” della lunghezza di 50 caratteri.» Il server restituirà la parola “mela” e i successivi 46 caratteri immagazzinati nella propria memoria che potrebbero essere, per esempio, le sessioni di autenticazione di altri utenti.
Questa falla potrebbe essere sfruttata per ottenere fino a 64 kilobytes per ogni singola richiesta malevola e, sebbene non si possa controllare quali dati estrarre dalla memoria, renderebbe di fatto insicure le comunicazioni con il server vittima: sarebbe possibile ottenere ad esempio username e password per accedere alla nostra webmail.
Questa descrizione risulta utile nella misura in cui ci permette di prendere coscienza del contrasto tra la fragilità reale del concetto di “sicurezza” applicato alle tecnologie e il discorso rassicurante che su queste viene veicolato. In questo senso, il cortocircuito tra pratiche (in)sicure e discorsi sulla sicurezza fa emergere la pervasività delle tecniche di potere nel loro articolarsi come dispositivo di assoggettamento e dominio diffuso. Centrale risulta il sapere tecnico nel legittimare la verità dei discorsi su sicurezza/insicurezza rivolti all'esterno - al mondo degli “utenti” - e allo stesso tempo nello strutturare dinamicamente i rapporti di potere all'interno del proprio campo. Ciò risulterà chiaro ripercorrendo i passaggi che hanno portato dalla scoperta della vulnerabilità al suo annuncio pubblico.
L'elemento che subito balza agli occhi è, appunto, il tempo intercorso tra questi due momenti: secondo l'accurata cronologia del Sydney Morning Herald, l'ingegnere di Google Neel Mehta scopre il bug circa il 21 marzo, mentre l'annuncio ufficiale arriva solo il 7 aprile. In mezzo, una serie di comunicazioni riservate tra tecnici di grandi aziende, ma anche di silenzi e di voti di segretezza.
Nello specifico, non appena la falla viene scoperta dall'ingegnere di Google Security, subito viene scritta una patch per correggerla e viene applicata a tutti i servizi di Google. In sostanza, quindi, Google provvede a correggere il proprio codice privatamente, comunicando solo il primo aprile con il core team di OpenSSL. Qualche giorno prima un'azienda che si occupa di gestire molti contenuti per conto terzi, CloudFlare, viene a conoscenza del bug - non è chiaro da chi siano stati informati - e lo corregge, anch'essa privatamente. Il team di OpenSSL decide di attendere almeno una settimana prima di rilasciare la propria patch pubblicamente. Parallelamente, il 3 aprile Codenomicon, un'azienda finlandese che si occupa di test sulla sicurezza, scopre in maniera indipendente la vulnerabilità. Immediatamente viene informato il National Cyber Security Centre Finland (NCSC-FI) ente governativo del paese scandinavo che si occupa di sicurezza in rete. Il giorno successivo iniziano a circolare le prime voci all'interno della comunità Open Source di un possibile bug in OpenSSL che non hanno però un seguito. Il 6 aprile i core team di diverse distribuzioni Linux sono informati della falla da uno sviluppatore di Red Hat (distribuzione di Linux a pagamento), sistema operativo per il quale lavora anche Mark Cox del team di OpenSSL che aveva provveduto ad avvertire la propria azienda quello stesso giorno. Il 7 aprile l'NCSC-FI comunica al team di OpenSSL che è stato riscontrato un bug nel loro software.
A questo punto, il team di sviluppo di OpenSSL decide di rilasciare immediatamente l'aggiornamento del software, valutando troppo rischiosa un'ulteriore attesa dal momento che il bug era stato segnalato in maniera indipendente già due volte in pochi giorni. Il 7 aprile, quindi, la vulnerabilità heartbleed diviene di pubblico dominio e l'assoluta maggioranza dei servizi basati su OpenSSL si trova a dover aggiornare in fretta i propri sistemi. Colossi come Amazon, Yahoo!, Twitter, Dropbox e molti altri si trovano a dover correre ai ripari: alcuni decidono di comunicare ai propri utenti ciò che è successo, altri non rilasciano alcuna dichiarazione ufficiale.
Quasi in ombra all'interno di questa situazione sono gli utenti, che venivano rassicurati fino al giorno prima della sicurezza delle loro comunicazioni private dai vari servizi. La maggior parte dell'utenza continuerà ad ignorare l'esistenza di heartbleed.
Oltre alle asimmetrie di sapere/potere tra le diverse corporations e al rapporto privilegiato tra fondazioni Open Source e aziende, ciò che più risulta evidente è l'assoggettamento degli utenti, resi docili dai discorsi dei “tecnici” - o stimolati da chi utilizza la paura per vendere rassicurazioni - e costretti a una fiducia cieca in chi “sa”. In questo caso, la verità costantemente riprodotta per mezzo del sapere tecnico sulla sicurezza, si trova repentinamente a cambiare di segno, rivelando le innervature che la informano.

In questo disegno complesso fatto di rapporti tra tecnologia, sapere e potere manca però un elemento: OpenSSL è un progetto Free e Open Source. Qualcuno avrebbe potuto leggere il codice e accorgersene prima, qualcuno avrebbe potuto impedire che la vulnerabilità fosse implementata nel software due anni fa, per un errore di programmazione. La domanda che dobbiamo farci, però, non è se il modello di sviluppo di software libero abbia fallito o meno, ma se sia sufficiente rendere il codice aperto e modificabile da chiunque.
Bisogna tenere conto di due elementi: l'architettura di OpenSSL è particolarmente complessa e solo per leggere il codice è necessaria una conoscenza approfondita della programmazione; chi ha scoperto la falla, in entrambi i casi, lavorava per un'azienda facendo revisione del codice. La prima discriminante quindi è all'interno del campo del sapere: di fatto, solo chi ha abbastanza conoscenza tecnica di un determinato codice potrà modificarlo efficacemente. Si tratta di un sapere che disciplina, che divide, che produce gerarchie. L'altro elemento ci ricorda che, all'interno dell'economia capitalistica, il tempo è una merce: un'azienda - o uno stato - che può pagare n programmatori facendoli lavorare full-time può determinare lo sviluppo di un software anche se questo è libero, così come può scoprire vulnerabilità dello stesso codice senza renderle pubbliche. Infine vi è un meccanismo di delega, di fiducia incondizionata al “tecnico”, che rende il rapporto con la tecnologia ancora più fragile, passivizzante.
Per immaginare scenari possibili e vie di fuga percorribili occorre ripensare il ruolo dei saperi all'interno di un ambito comunitario.
Non si tratta allora solamente di liberare codice: si tratta di creare le condizioni con le quali le persone possano collaborare. Si tratta di socializzare e condividere i saperi dando forma a comunità molteplici, cangianti. Si tratta di passare da una forma di sapere-segreto, di sapere disciplinare, a un'insieme di saperi condivisi, ibridi. Riflettere sulle ambivalenze della tecnologia e della conoscenza nella loro funzione disciplinante da un lato, di resistenza dall'altro, non è solo un esercizio analitico: ci permette di immaginare nuove pratiche liberanti e liberate.

Jacopo Anderlini