Clicca ‘invia’.

Stai lavorando ad un documento di Microsoft Word, o compilando un complicatissimo foglio di calcolo con Excel, quando all’improvviso il programma si blocca. Un blocco quasi sempre irreversibile: tecnicamente il programma è andato in crash — «è crashato», per usare un inglesismo. Quasi sempre la causa di ciò sta in un errore di programmazione: qualche riga di codice non corretta o un conflitto generato con pezzi di software di terze parti. All’utente però raramente interessa il vero motivo del crash, troppo impegnato com’è ad imprecare per il lavoro perso o a sperare in quella funzione che, alla riapertura del programma crashato, dovrebbe ripristinare il file cui stava lavorando — almeno fino al momento in cui qualcosa non ha funzionato correttamente.

Non si è ancora finito di imprecare e una finestrella ci chiede se vogliamo inviare una segnalazione del malfunzionamento al produttore del programma. Antesignana di queste finestre di dialogo è stata la Microsoft, che le ha introdotte per la prima volta nel 2001 con il sistema operativo. Da allora, praticamente ogni software prevede la possibilità di mandare un feedback alla casa di produzione — «inviare una segnalazione», questa la formula utilizzata più spesso — per avvisare di un malfunzionamento e permettere di analizzare l’accaduto.

Non so voi, ma io quasi mai accetto di mandare la segnalazione. Non temo chi possa leggere il contenuto del file cui sto lavorando, né che qualcuno possa contestarmi che la copia del programma su cui sto lavorando non è originale (cosa che in effetti, non vi sembri una precisazione non richiesta, non è mai accaduta). Piuttosto, non ho mai pensato che dall’altra parte dello schermo ci fosse qualcuno realmente disposto ad interessarsi dell’errore. Ma mi sbagliavo.

Come racconta Lidia Jean Knott in un lungo articolo pubblicato da The Awl, qualcuno dall’altra parte c’è. E bisogna ringraziare Kirk Glerum per questo. Esperto di computer e tecnologie fin da quando vide un calcolatore negli anni 70, Glerum prima di essere un felice pensionato con l’hobby di smanettare sui computer è stato un consulente tecnico della Microsoft con una particolare fissa per la reportistica. La prima volta che ha proposto all’azienda di adottare un sistema che ricevesse le segnalazioni degli errori inviate dagli utenti è stato verso la fine degli Anni Novanta, un periodo in cui — ricorda Knott — «la Microsoft aveva una terribile reputazione per essere inaffidabile e i suoi prodotti pieni di errori». Eric Le Vine, allora capo del progetto di Error Reporting di Microsoft, all’inizio era molto dubbioso dell’idea di Glerum per due motivi. Primo, Glerum era sempre sembrato un tizio piuttosto stravagante («Una volta ad Halloween si è rasato il capo e presentato in ufficio con i tasti di una tastiera incollati alla testa», ha raccontato a Knott) e alle sue idee veniva probabilmente fatta una tara; secondo, e industrialmente più importante: la procedura avrebbe fatto crollare tutti i loro server in un attimo.

Il programma di Error Reporting nonostante tutto riuscì a partire e i risultati furono subito sorprendenti. Le Vine ha raccontato a Knott che nei primi tre anni di attività la funzione riuscì ad eliminare il novantacinque percento dei crash capitati ai programmi della suite di Microsoft Office (tra le più colpite da improvvisi blackout). Un risultato che fece ricredere tutti — e Le Vine in primis — sull’intuizione di Glerum e sulla bontà del progetto. Anche se rimaneva un ostacolo da superare: la riluttanza degli utenti ad inviare segnalazioni. Sebbene Glerum abbia raccontato a Knott che lui e il suo team volevano a tutti i costi che gli utenti inviassero le loro segnalazioni, non era certo possibile obbligarli. Bisognava, piuttosto, cercare di rendere questi messaggi «i più umani possibili», introducendo elementi di cortesia come l’espressione «siamo spiacenti» e «per favore».

report_1

Ma come funziona esattamente la reportistica dei crash? Scrive Lidia Knott che quando un programma crasha, il sistema operativo raccoglie una serie di informazioni come il nome dell’applicazione che si è bloccata, quello delle altre applicazioni in esecuzione in quel momento più altre informazioni personali come ad esempio il nome del documento sul quale si stava lavorando. A questo punto i dati raccolti vengono inviati ai server di Microsoft e lì processati secondo i Principi di Pareto. Questi principi — teorizzati la prima volta nel 1897 da Vilfredo Pareto, un economista e sociologo italiano — affermano che la maggior parte degli effetti è dovuta ad un numero ristretto di cause, con una suddivisione in percentuale all’incirca dell’80 su 20 (l’80 percento delle degli effetti è dovuto ad un 20 percento di cause). Arrivati alla Microsoft, i report sono quindi raggruppati e smistati agli sviluppatori, che iniziano ad analizzarli concentrandosi su quelli più frequenti: risolvendo questi per primi c’è una buona possibilità di risolvere la maggior parte di essi.

Stando ad alcuni ex dipendenti Microsoft interpellati da Knott, gli sviluppatori ricevevano una mail contenente i 10 più comuni crash che si erano verificati sui programmi cui avevano lavorato. Questa mail era soprannominata internamente «il muro della vergogna» e tutti gli errori in essa contenuti erano accompagnati da un documento utile agli sviluppatori per correggerli. Spiega Knott che questo documento «conteneva centinaia di campi che dettagliavano il modo con cui il crash era avvenuto, quante volte e quale sia stato il suo impatto. C’erano anche note con le quali gli sviluppatori indicavano eventuali tentativi già fatti per correggere questi errori o le loro impressioni su quali potessero essere le cause». Non è chiaro se la procedura interna sia ancora questa, ma dal momento che queste finestre di dialogo esistono ancora, tutto fa supporre che non sia cambiato molto.

Il sistema sembrerebbe funzionare, ma rimane un piccolo problema: quello della privacy. La Microsoft ha sempre promesso di mantenere riservati i dati ricevuti. Ma, sempre secondo un ex dipendente sentito in forma anonima da Knott, «se un utente sta lavorando ad un documento dal titolo particolarmente sensibile, potrebbe prendere in considerazione di non inviare il report». Questo perché i report inviati a Seattle contengono una discreta quantità di informazioni e, transitando nella rete, fanno gola a molti. È quanto ad esempio ha denunciato il settimanale tedesco Der Spiegel in una sua inchiesta del dicembre 2013, in cui spiegava che alcuni personaggi della NSA erano riusciti ad intercettare alcune di queste segnalazioni per cercare di ‘entrare’ nei computer delle persone. In pratica, una volta che l’unità di intelligence TAO (Tailored Access Operations) aveva individuato e schedato come obbiettivo una persona e immesso un identificatore del suo computer (l’indirizzo IP, ad esempio) nel suo database, grazie al potente software Xkeyscope riceveva una segnalazione ogni volta che questa macchina andava in crash. Di per sé questi messaggi di errore e di richiesta di inviare report erano (e sono) una pratica lecita per ottenere quello che viene definito un «accesso passivo» alla macchina di un utente (vengono catturati e salvati solo i dati in uscita dalla macchina). Il problema è che il loro contenuto consentiva di venire a conoscenza anche di alcuni problemi di cui era affetto un computer, compresi eventuali buchi nella sicurezza che potevano essere sfruttati per installare software di spia o altri malware.
Non solo. Secondo l’inchiesta dello Spiegel, gli agenti della NSA si erano presi la soddisfazione di «farsi una risata alle spalle della Microsoft». Come? Truccando il messaggio di errore, sostituivano la parte in cui l’azienda di Seattle prometteva di trattare in maniera confidenziale i dati ricevuti con: «Le informazioni che stai inviando potrebbero essere intercettate da un sistema di intelligente che le raccoglie per servirsi meglio della mostra macchina».

report_2

Rimane un’ultima questione, probabilmente sacrificata dalla Microsoft sull’altare dell’efficienza dei propri programmi. Come ha dichiarato un ex dipendente di Microsoft a Knott, queste finestre appaiono uguali sia quando a crashare è un programma di Microsoft che quando è invece di un altro produttore, dando all’utente l’impressione che ad essere responsabile del malfunzionamento sia sempre l’azienda di Seattle.