Il codice aperto può rendere un software più verificabile: permette a persone competenti di esaminarlo, discuterne il comportamento e proporre correzioni. Non garantisce però, da solo, sicurezza o riservatezza.

Nel video parto dalla reputazione di Linux e del software open source per spiegare i vantaggi della trasparenza. Il punto da mantenere è la possibilità di controllo; quello da evitare è trasformarla nella certezza che ogni problema venga scoperto subito.

La disponibilità del codice cambia ciò che possiamo verificare

Quando il sorgente è disponibile, una verifica può andare oltre le dichiarazioni del produttore. Chi ha le competenze può esaminare come vengono gestite operazioni, permessi e comunicazioni.

Questo non significa che ogni utente debba diventare revisore. Significa che il progetto può essere sottoposto anche a controlli esterni, con risultati discutibili pubblicamente.

Resta però una domanda importante: il programma distribuito corrisponde al codice esaminato? Dipendenze, processo di compilazione e configurazione fanno parte della valutazione. Per un servizio remoto, inoltre, non sempre possiamo osservare tutto ciò che avviene sul server.

Codice pubblico non significa codice già controllato

Nel video richiamo l'idea secondo cui molti osservatori rendono più facile trovare difetti. È un'aspirazione utile, non una legge che assicura la scoperta di ogni vulnerabilità.

Servono tempo, competenze e strumenti. Un progetto può essere molto usato e avere pochi manutentori; una parte complessa può ricevere meno attenzione di quella necessaria.

Anche dopo una segnalazione occorre sviluppare la correzione, distribuirla e installarla. L'apertura offre possibilità di collaborazione, ma non svolge automaticamente questo lavoro.

Heartbleed: una correzione possibile, una vulnerabilità reale

Il caso citato nel video è Heartbleed, non “Health Bleed”. Il bollettino OpenSSL del 7 aprile 2014 descriveva un errore nel controllo dei limiti che poteva esporre porzioni di memoria e indicava la versione corretta da adottare. Bollettino originale OpenSSL.

È un esempio di quanto sia importante poter analizzare e correggere una componente diffusa. È anche la dimostrazione che una libreria open source può contenere una vulnerabilità grave.

Non prova che una soluzione chiusa avrebbe necessariamente fatto peggio, né che basti pubblicare il codice per impedire problemi simili. Il confronto deve riguardare processi e risultati verificabili.

Software libero e raccolta dei dati sono questioni distinte

Nel parlato associo la libertà del software all'assenza di tracciamento. La licenza definisce libertà d'uso, studio, modifica e distribuzione; non garantisce di per sé che un programma non raccolga dati.

Per capire la riservatezza bisogna guardare al comportamento concreto, alle impostazioni e ai servizi coinvolti. Anche una distribuzione Linux può includere componenti con politiche differenti.

Allo stesso modo, “sicurezza”, “privacy” e “anonimato” non sono sinonimi. Proteggere un contenuto non equivale necessariamente a nascondere ogni informazione sulla comunicazione.

Protocolli pubblici e fiducia: l'esempio di Signal

Cito Signal perché pubblica specifiche tecniche e librerie relative ai propri protocolli. Questo permette alla discussione sulla sicurezza di avere oggetti concreti da esaminare. Documentazione Signal.

La disponibilità delle specifiche non autorizza una classifica assoluta di tutte le app di messaggistica. La scelta dipende anche dalle esigenze e dal modo in cui viene usato il dispositivo.

Nel video menziono inoltre Session dicendo che richiederebbe un server personale. È inesatto per il normale utilizzo dell'app: Session usa una propria rete decentralizzata. FAQ ufficiali Session.

Gestire i propri dati aumenta anche le responsabilità

Nextcloud è l'esempio con cui introduco la possibilità di gestire un archivio su un'infrastruttura scelta da noi. Il vantaggio potenziale è avere maggiore controllo su dove risiedono i dati e su chi amministra il servizio.

Non è però una scorciatoia verso la sicurezza. Aggiornamenti, accessi, copie di recupero e configurazione diventano responsabilità da organizzare. Un server personale trascurato può offrire una protezione peggiore di un servizio gestito correttamente.

Come valuterei un progetto concreto

Oltre alla licenza, guarderei alla manutenzione, alla documentazione e al modo in cui vengono gestite le segnalazioni. Verificherei poi quali dati sono necessari e quali funzioni si possono disattivare.

Anche per le mie applicazioni pubblicate su GitHub, che richiamo nel video, il codice deve essere un punto di partenza per il confronto, non una richiesta di fiducia automatica.

Preferisco il software aperto per le possibilità che offre. La conclusione più solida è che rende possibili controlli e interventi ulteriori: la sicurezza dipende da quanto bene queste possibilità vengono esercitate.