La vita nel codice

Read time: 8 mins

La parola "software" è abbastanza comunemente associata a schermi pieni di caratteri, macchinari, sequenze incomprensibili ma quasi mai a concetti come la vita o l’ambiente. Eppure ciò sarebbe, probabilmente, più corretto , secondo il professor David Berry, recente autore del libro Life in Code and Software: Mediated life in a complex computational ecology. Perché il software è intorno a noi ed è parte dell’ambiente in cui viviamo, al pari dell’aria o dall’acqua.
E perché al software abbiamo cominciato ad adattarci, cercando il miglior compromesso fra opportunità e minacce.

Non si direbbe niente di particolarmente innovativo evidenziando che l’Information Technology ha introdotto dei cambiamenti sociali difficilmente pensabili, anche solo una trentina d’anni fa. La gestione di identità multiple in rete e le nuove forme di conoscenza e politica distribuite sono argomenti che, parlando di social media, emergono anche nei discorsi fra amici senza alcun bisogno di scomodare dotti dibattiti accademici. D’altronde c’è qualcosa su cui raramente si riflette: che, in tutte queste esperienze, è il codice il mediatore fra le azioni e le emozioni degli esseri umani. Il software, quindi, pur essendo evidentemente immateriale, manifesta sempre di più delle conseguenze tangibili su di noi: un sito web con contenuti che ci rendono tristi o felici, una barra di un parcheggio che ci fa entrare o no, un robot che opera direttamente sulle nostre carni. Per cui un rischio o un’opportunità nell’ambiente software dovrebbero far scattare in noi valutazioni simili a quelle che facciamo in presenza di condizioni meteo favorevoli o sfavorevoli oppure quando dobbiamo scegliere fra camminare a piedi in un prato fiorito o in un quartiere malfamato. 

Come un ecosistema vivo, l’ambiente software ha ormai caratteristiche che vanno ben oltre il nostro controllo, per cui il singolo non può gestire il flusso completo degli eventi ma solo imparare a reagire di fronte a alcuni stimoli. Nei primi anni ’90 era normale aprire la propria applicazione (se non scriversela da zero, ad esempio in C o in PASCAL) controllando in modo quasi totale il comportamento della macchina, se si esclude il flusso fisico dei segnali elettrici al suo interno. Il software non era un ambiente ma uno strumento, chiuso sull’utilizzatore, nel senso che da questo riceveva comandi e solo a questo forniva dei risultati. Il web, però, ha cambiato completamente le cose. Non solo perché, lavorando in rete, utilizzatore e destinatario potevano essere distinti ma anche perché il secondo poteva ricevere dei risultati a dispetto della volontà del primo.

Il meccanismo con cui questo comportamento ha cominciato a far capolino sono stati, più che i bugs (involontari) o gli easter eggs (divertenti giochini e niente di più) i meccanismi di gestione dello stato nel protocollo HTTP, detti web beacons. Essi erano stati inseriti come aree di appoggio per alcuni dati di sessione e potevano servire, ad esempio, per evitare nuove richieste di credenziali a utenti già autenticati che chiedevano nuove pagine. A causa, però, della loro capacità di conservare dati, il loro utilizzo proprio è stato quasi superato dall’impiego come agenti – più o meno occulti – di raccolta dati e tracciamento automatizzato. Il loro offuscamento – termine tecnico che allude alla presenza in una forma tale da limitarne o impedirne la comprensibilità anche per un programmatore – è cominciato associandoli a immagini di 1 pixel per 1 pixel, per farli richiamare nella pagina solo al momento dell’esecuzione rimanendo, quindi, quasi invisibili agli utenti meno smaliziati. E’ poi arrivato a soluzioni più complesse, basate su codice lato server o misto client-server, varie scatole cinesi di proxy e via dicendo in un’escalation di sofisticazioni senza limiti.

Il risultato finale è che, a oggi, nel sorgente di molte pagine che riteniamo insospettabili e che visitiamo quotidianamente, esiste una porzione importante di codice criptico che, se la analizzassimo a fondo, si rivelerebbe fatta solo per spiarci. “Quando apro il sito del New York Times, i miei dati vengono mandati ad almeno 10 compagnie diverse, fra cui Microsoft e Google”, ha osservato a tal proposito Madrigal in I’m being followed: how Google – and 104 other companies – are tracking me on the webIn tutto questo sono probabilmente evidenti le implicazioni economiche (chi riceve i log può utilizzarli per restituire all’utente messaggi pubblicitari ad altissima efficacia oppure venderli ad altre aziende) ma forse non è ancora abbastanza chiara la natura della cosa di cui stiamo parlando: quella di minaccia di un ambiente (il software, appunto) in cui siamo immersi.

Qualcuno potrebbe obiettare che in gioco c’è solo la privacy (un valore peraltro non marginale e su cui c’è un forte dibattito a livello legislativo ed etico in corso), o che, comunque, il massimo danno collegato è la sola copia di informazioni marginali della sessione HTTP. Sarebbe, però, solo una valutazione assolutamente superficiale, non solo perché esiste tutto il mondo dei virus informatici, il cui effetto può andare dalla distruzione d’interi gigabyte di informazioni al rendere programmi installati completamente inutilizzabili. Ma anche perché è già stato inventato un virus capace di mettere in ginocchio anche il programma di arricchimento nucleare di un intero paese.

Il suo nome è Stuxnet e, per molti, è diventato il virus per antonomasia nonché il primo vero atto di inizio della nuova era delle cyberwars.(Cherry, How Stuxnet is rewriting the cyberterrorims playbook). Questo worm è stato realizzato per copiare se stesso di computer in computer e non compiere alcuna operazione se non in presenza di determinate condizioni di attivazione (fra cui il sistema operativo Windows accoppiato al Programmable Logic Controller Siemens S7-300) riscontrabili solo negli impianti iraniani di arricchimento dell’uranio che si volevano attaccare. Una volta attivatosi, il virus è stato concepito per portare le macchine vittima al guasto senza essere intercettato dai sistemi di sicurezza interni e, a fine lavoro, cancellarsi. Stuxnet ha rappresentato un caso completamente nuovo per molti aspetti. Intanto per la raffinatezza del codice, per qualche tempo presente anche su alcune reti peer to peer e quindi oggetto di analisi da parte di professionisti e di curiosi; un vero e proprio drone digitale che ha richiesto, per Zetter, un lavoro di vari mesi di un team di non meno di trenta persone. Poi per la sua capacità di sfruttamento di punti deboli di prodotti commerciali fino ad allora non noti e mai resi pubblici dalle case costruttrici. Ha compiuto il suo lavoro, infatti, imprimendo alle centrifughe una serie di accelerazioni e decelerazioni a frequenze precise fino alla terza cifra decimale, distribuite in un intervallo di tempo di quasi un mese. Segno di una modalità di azione sperimentata prima a fondo e di un’origine quasi sicuramente militare (Nate Anderson in Confirmed: US and Israel created Stuxnet, lost control of it). Il tutto unito a una capacità di lavorare nell’ombra, dietro le interfacce che gli iraniani sfruttavano quotidianamente credendole del tutto affidabili, tipica di tutti i virus ma qui a un ordine di efficacia e complessità con rari precedenti. 

Tutto questo fa capire che il software che ci circonda è un qualcosa di ben lontano da un esecutore passivo che si raffronta solo con noi ma è, al contrario, un vero e proprio sistema complesso, con una pluralità di nodi variamente interconnessi fra loro. Dovremmo, però, concludere che questa vita per certi versi autonoma del software è sempre e comunque un qualcosa che prescinde dalla nostra volontà? Anche questo sarebbe inesatto e lifestream è la parola chiave. Il termine è stato inventato negli anni ’90 da David Gelernter ed Eric Freeman per indicare un flusso ordinato di documenti riferiti alla vita di un individuo: una sorta di diario digitale, insomma. Costituiscono dei lifestream i nostri profili sui social media, che riempiamo volontariamente per scopi di visibilità o riconoscimento sociale. Ma lo sono anche tutti i dati biologici, tipicamente provenienti da sensori installati sul corpo, che alcune persone mettono a disposizione di aziende, centri di ricerca o addirittura di internet in modo indifferenziato. Nella speranza che possano essere utili a curare le loro patologie o altri pazienti affetti da mali simili. Lo sono, infine, tutti i dati raccolti in automatico dagli operatori telefonici dalle mobile APPS e dalle loro interazioni con le varie antenne coinvolte nelle conversazioni. 

I lifestream sono importanti non solo per la prevalenza dell’elemento volontario nell’interazione col software (che dà un riconoscimento a questo come interlocutore diffuso, ossia come ambiente) ma anche perché hanno aperto un’altra porta: quella della riflessività, ossia della capacità dell’ambiente software di farci capire meglio noi stessi studiandolo. I lifestream – che siano originati da social media, da APPS o da semplici programmi standalone – hanno dato origine, infatti, ai cosiddetti activity streams, enormi elenchi di proposizioni nella forma tempo, attore, verbo, oggetto (ad esempio: alla data x, Mario carica una foto). Archivi che possono essere analizzati in modo automatizzato, con gli approcci delle network sciences, e che sono capaci di evidenziare dei pattern di comportamenti o delle correlazioni non preventivabili a priori. Fornendo del vero e proprio oro nascosto (data mining, con il verbo che è lo stesso usato per descrivere l’azione dei minatori) per supportare la comprensione dei comportamenti dei cittadini o dei turisti, la pianificazione urbana e via dicendo. O anche “solo” per realizzare nuove forme d’arte come afferma Mauro Martino del Massachusetts Institute of Technology durante i suoi workshop. In cui stupisce con le sue rappresentazioni di città multicolori che pulsano delle attività che le persone compiono guidando, telefonando, incontrandosi e così via.

Forse non ce ne siamo accorti, dunque. Ma il software ha ormai più a che fare con la complessità di un ambiente che vive che con la banale esecuzione in forma ordinata di semplici comandi. E, come ogni altro ambiente, ha i suoi pericoli e le sue meraviglie nascoste nonché una sua capacità di agire sul piano fisico e di comprendere i mondi che lo circondano. 

Non possiamo vedere in lui, ancora, una vera e propria volontà autonoma. Ma l’impressione è che, nel futuro, la parola codice sarà sempre di più associata alla biologia e alla sociologia e sempre meno all’informatica.

altri articoli

La gestione dei rischi idraulici nel bacino del Po

Nel corso degli anni, il Po è stato protagonista di alluvioni catastrofiche, tanto che l'eventuale collasso di un suo argine è considerato l’evento di calamità naturale più grave in Italia dopo l’eruzione del Vesuvio. Armando Brath, professore di Costruzioni idrauliche all’Università di Bologna e presidente dell'Associazione Idrotecnica Italiana, spiega le ragioni del rischio, come gli argini fragili, ragionando sulla necessità di sviluppare una capacità di visione di insieme dei fenomeni e dei problemi: come diceva Einstein, infatti, "i problemi attuali non si possono risolvere perseverando con la stessa mentalità che ha contribuito a generarli". L'articolo è una anticipazione del numero speciale 505 di Italia Nostra dedicato al Po.

Crediti: Frittoli, Edoardo (2015-11-13). "13 novembre 1951. La catastrofe del Polesine". Panorama

I rischi idraulici possono ascriversi a tre categorie generali: il rischio di siccità, che può compromettere gli usi delle acque (potabile, irriguo, industria, energia), il rischio alluvionale e idrogeologico, che riguarda la difesa dalle acque in relazione a fenomeni quali piene e frane, e il rischio ambientale, legato alla tutela della qualità delle acque e degli habitat dall’inquinamento.