Intervista a Giorgio Maone, autore di NoScript e FlashGot

Quest'oggi ho il grandissimo onore di intervistare uno dei programmatori più innovativi del panorama italiano. Un programmatore che è riuscito a realizzare due estensioni di Firefox che risultano nella top 5 delle più scaricate e usate dagli internettauti dell'intero globo. Una di queste estensioni ovvero NoScript è stata premiata e osannata da tutti i maggiori esperti di sicurezza.

Il nome di questo programmatore è Giorgio Maone, conosciuto nel settore anche per la "piccola" diatriba con Wladimir Palant, autore di Adblock Plus.  

Un programmatore davvero eclettico che vi sorprenderà per la sua preparazione e simpatia.

Be di melanzane al fuoco c'è ne sono molte in questa intervista (si lo so il detto è carne al fuoco però sono vegetariano quindi non rompete :D).

Buona lettura :)

I miei principali interessi professionali riguardano la sicurezza informatica e la realizzazione di software, sia enterprise che consumer: sono un hacker e uno sviluppatore. Mi piacerebbe dire un "artigiano", nel senso che per me il lavoro più stimolante è quello di cui posso curare tutte le fasi creative, dall'idea all'analisi, fino all'implementazione e all'ottimizzazione. Ovviamente questo approccio artigianale non è applicabile a tutti i progetti, sia per motivi di complessità che di organizzazione, e quindi la mia azienda, InformAction, fondata insieme ai miei più cari amici nel 1998, per la produzione di software adotta processi industriali, sebbene basati su metodologie agili.

Fortunatamente la vena artigiana trova sfogo nei miei "pet project", rilasciati con licenza open source e aperti a contributi comunitari, ma sempre e comunque sotto il mio controllo dittatoriale.

Quanto agli hobby, la musica sicuramente è al primo posto: suono diversi strumenti musicali e compongo.

Al compimento dei miei 11 anni, quando mio padre mi regalò un venerabile Commodore 64. Ho resistito da "commodoriano" e "amighista" puro per più di un decennio, e il mio ultimo Amiga (un 4000 "bummiato", come diciamo a Palermo dei motorini truccati, con processore 68060 a 50Mhz, 32MB di RAM,  audio a 24 bit Delfina e  video UGA Picasso IV) è ancora perfettamente funzionante nel mio studio.

Sarei tentato di dire Ruby, perché è tra i più "divertenti", è multi-paradigma e incoraggia soluzioni creative, ad es. basate sulla meta-programmazione. Tra l'altro l'ho conosciuto diversi anni prima della fama meritata con Rails, e nel 2002 scrissi "Il linguaggio Ruby: la via giapponese all'OOP", credo uno dei primissimi articoli stampati in Italia sull'argomento, pubblicato sul numero 99 di DEV (storica testata sulla programmazione edita Infomedia).

Tuttavia ritengo che ogni progetto meriti il linguaggio più adatto alle sue specificità, anche più di uno se necessario, altrimenti ti riduci a combattere contro i limiti degli strumenti che hai scelto, magari per motivi ideologici. Perciò utilizzo molto C++, Java e C#.

Ultimamente il linguaggio in cui scrivo più linee di codice, tuttavia, è sicuramente Javascript. Si tratta di un linguaggio decisamente sottovalutato, anch'esso multi-paradigma e molto "divertente", con un brillante futuro davanti, vista la sua centralità nelle applicazioni web-based (ancora più enfatizzata da HTML 5) e la rincorsa verso performance interessanti grazie alla rediviva guerra tra i browser.

Si è trattato di un ritorno di fiamma. Durante la prima guerra dei browser mi ero schierato con Netscape, soprattutto perché multipiattaforma, ma le ultime versioni prima della debacle, così come le prime beta open source della Mozilla Suite, erano decisamente troppo pesanti senza offrire alcuna reale innovazione, e non riuscirono a dissuadermi dal passare al "lato oscuro" di IE. Tuttavia ho continuato a seguire il lavoro della Mozilla Foundation con la coda dell'occhio, e quando ho potuto provare i primi rilasci "anteprima" di Firefox (allora Phoenix, poi Firebird), ho subito capito che qualcosa di grosso stava per succedere.

Entrambe, come spesso accade nel modo open-source, nascono da esigenze personali che poi si scoprono condivise da tante altre persone.

Nel caso di FlashGot, uno degli ostacoli principali che avevo incontrato nella transizione da IE a Firefox era stata l'impossibilità di interfacciarmi con un download manager esterno (all'epoca usavo FlashGet). Siccome tutti i download manager supportavano IE, ma nessuno aveva la stessa attenzione per Firefox, decisi di scrivere un "adattatore" che portasse il supporto allo stesso livello o addirittura lo migliorasse. Quando pubblicai FlashGot e cominciai a ricevere feedback, io per primo mi stupii di quanti utenti fossero nella mia stessa situazione, e aspettassero una soluzione del genere per chiudere definitivamente la "pratica IE".

NoScript nacque qualche mese dopo, in occasione del primo vero "spavento da 0 day" per gli utenti di Firefox. Mentre Mozilla lavorava febbrilmente a una patch e gli utenti (me incluso) si ritrovavano per le mani un browser vulnerabile, mi resi conto che c'era un modo per mitigare preventivamente la maggior parte delle situazioni del genere: nel 99% dei casi, disabilitare Javascript (o i contenuti attivi in generale) era un rimedio efficace, ma praticamente nessuno lo adottava perché molti siti visitati abitualmente avrebbero smesso di funzionare correttamente. Allora perché non dotarsi di un sistema rapido per abilitare i siti fidati che dipendono da Javascript e impedire agli altri di nuocere? Così, in soli 3 giorni, creai e pubblicai la prima versione di NoScript. Siccome fu quasi subito evidente, dai numerosi crash scatenati, che questa estensione esercitava moduli di Firefox, come lo ScriptSecurityManager, che non erano mai stati testati a sufficienza in condizioni realistiche, da un giorno all'altro a dovetti  applicarmi a modificare e migliorare il codice "core" del browser, riparando oscuri bug dimenticati dai tempi di Netscape e aprendo fronti nuovissimi, per di più in un'area delicata come quella della sicurezza. In brevissimo tempo mi ero ritrovato a mantenere un paio di software piuttosto popolari, a contribuire al codice del secondo browser più usato al mondo e a "sedere" nel Mozilla Security Group.

Certo che no, anche perché l'approccio da me proposto non era esattamente popolare, per quanto efficace e decisamente più usabile del classico quanto inutile consiglio "Disabilitare Javascript e visitare solo pagine fidate" che accompagna praticamente ogni advisory cadendo regolarmente nel vuoto.

Tuttavia negli anni NoScript si è evoluto molto, includendo misure pionieristiche contro le cosidette "minacce emergenti", come XSS, CSRF o Clickjacking, che vanno ben oltre il semplice blocco selettivo degli script e funzionano indipendentemente da esso. Quindi anche l'utente più impaziente e meno "tecnologico" potrebbe rinunciare a quest'ultimo ("Abilita script globalmente") e continuare a godere di un browser considerevolmente più sicuro degli "standard".

Inoltre NoScript ha goduto fin da subito della stima di tutti o quasi gli esperti di web security, da Mark Ranum (uno dei padri del firewall), a OWASP (il principale organismo internazionale che si occupa di WebAppSec) a Jeremiah Grossman e Robert "RSnake" Hansen, che hanno reso "popolari" XSS e CSRF e hanno inventato il "Clickjacking".

Si dice infine che l'imitazione è la più grande forma di adulazione: ebbene, il fatto che i filtri XSS lato client, che erano ritenuti impraticabili prima di venire introdotti da NoScript, siano stati più tardi adottati in Internet Explorer e Chrome, migliorando la sicurezza del web per centinaia di milioni di utenti, mi dà molta più soddisfazione di un "World Class Award" o di un "Reader's Choice Award" assegnato da una rivista :)

Non ci parliamo affatto. Del resto non è che prima i rapporti fossero idilliaci: Wladimir aveva già attaccato pubblicamente e ripetutamente NoScript molto prima dell'incidente in questione, mettendone in dubbio l'efficacia e l'utilità, specie se paragonata alla sua Adblock Plus (e venendo ripetutamente smentito dagli esperti e dalla storia: per dirne una, era stato tra i "lungimiranti" che avevano deriso l'idea di un filtro XSS lato client). Tra l'altro il Palant non era nuovo a montare accese polemiche con altri sviluppatori, che magari terminavano con la morte di un prodotto concorrente (è la sorte toccata ad Adblock "Classic", fagocitato da ABP). Ciononostante, quando me l'aveva chiesto, avevo sponsorizzato la sua candidatura all'ingresso nel Mozilla Security Group, che tuttavia non fu ritenuta opportuna dagli altri membri. Magari il sospetto di un inesistente boicottaggio da parte mia potrebbe averlo indotto, per vendetta, a fomentare (come egli stesso ha confessato) l'escalation condotta dal nuovo maintainer di EasyList (Ares2, subentrato al compianto Rick752) ai danni dei siti web di NoScript e FlashGot, i cui utenti alla fine erano  impossibilitati persino ad installare le estensioni stesse. Non nego che la mia reazione sia stata eccessiva e sconsiderata: anziché denunciare l'attacco pubblicamente, magari sul mio blog, ho fatto in modo che NoScript neutralizzasse EasyList limitatamente ai siti summenzionati, ripristinandone il corretto funzionamento, senza tuttavia impedire agli utenti di continuare a bloccare qualsivoglia contenuto con ABP anche su questi siti, se lo desideravano. Il problema etico più serio posto da tale approccio era l'oscurità: siccome volevo sperimentarne l'impatto effettivo ritardando il più possibile una controreazione di Ares2 (all'epoca non sapevo ancora che dietro di lui c'era Wladimir, e la guerra di nervi andava avanti da più di un mese), non avevo annunciato il cambiamento nelle note di rilascio e avevo moderatamente offuscato il codice preposto. Ciònononstante, prima ancora che da Ares2, la modifica era stata notata da alcuni utenti e segnalata sui forum di NoScript come malfunzionamento, e pertanto se ne stava già discutendo pubblicamente ed era pronta per il rilascio una versione che consentisse di abilitare o disabilitare questo comportamento esplicitamente al primo avvio, quando venni contattato privatamente da Wladimir che mi accusava di avere introdotto "malware" nella mia estensione. Gli spiegai che, come poteva facilmente verificare dalle discussioni sui forum, una versione "trasparente" ed eticamente inattaccabile stava per essere rilasciata, e la sua risposta mi sembrò conciliante. Si può immaginare la mia sorpresa quando, alla vigilia del rilascio, mi fu indicato il blog post, ripreso da Reddit, Slashdot, Ars Technica e compagnia twittante, con cui Wladimir innescava lo "scandalo" ormai ben noto: visto che era perfettamente al corrente dell'imminente soluzione del problema, e che egli stesso ammetteva di essere stato l'ispiratore della crociata di Ares2 fin dall'inizio, il tutto assumeva per me il sapore di una trappola ben congegnata ai danni di NoScript, senza nulla togliere ai miei gravi errori che ho avuto modo di espiare nei mesi successivi, dopo le mie scuse pubbliche, dedicandomi ad ABE.

Oggi di quella polemica, a parte un manipolo di irriducibili che mi considera ancora l'Anticristo, mi rimane il nono posto nella classifica de "Le 10 persone più pericolose di Internet", stilata per OWASP da Robert "RSnake" Hansen (che, come "ogni ricercatore di sicurezza sul pianeta o quasi" è un fedele utente di NoScript).

Chrome ha il grande vantaggio tecnologico di essere stato realizzato dal nulla, facendo tesoro sia degli errori che delle esperienze positive accumulate dai suoi predecessori (non a caso alcuni dei suoi sviluppatori provengono da Mozilla).

D'altro canto, pur essendo open source, si tratta di un browser che "serve" gli interessi aziendali di Google, i quali non necessariamente coincidono con quelli degli utenti (specialmente se si parla di privacy).

Ad ogni modo, un competitor in più nell'arena dei browser non può che essere salutare per tutti (come si è visto ad esempio dall'effetto che Firefox ha avuto su IE, uscito da una stagnazione durata quasi un decennio), e gli effetti del codice aperto sono "circolari" in tutti i sensi: si pensi ad esempio a JägerMonkey, il modulo di compilazione JIT a livello di metodo mutuato da Webkit, che Mozilla sta affiancando a SpiderMonkey (l'interprete storico) e TraceMonkey (il compilatore JIT basato su tracing e derivato da Adobe Tamarin) per ottenere le massime performance Javascript in tutte le condizioni.

In realtà sono stato contattato il primo aprile (!) del 2009 da Google stessa, affinché si potesse collaborare in questo senso. Purtroppo, forse a causa della data poco propizia, forse per altre ragioni legate alle priorità aziendali a cui accennavo prima, i presupposti tecnici ancora non si sono realizzati. Tuttavia non dispero, perché le discussioni con il team di sviluppo di Chrome e con i security engineers di Google proseguono.

Bah, era nato più che altro come un luogo dove riversare le annotazioni e le punzecchiature che mi capitava sempre più spesso di dover lasciare come commenti nei blog altrui. Comunque, per darti una risposta esauriente, 42.

Emigrare. No.

... intendo, possibilità di (soprav)vivere da impiegato (possibilmente sottopagato e sfruttato) scrivendo codice noioso ce ne sono anche in Italia. Ma se ti piace programmare e vuoi fare qualcosa di stimolante che lasci il segno, devi essere disposto non dico a emigrare "fisicamente" (anche se, purtroppo, ancora aiuta nonostante Internet), ma almeno a pensare su scala globale, perché l'Italia non è più un paese per persone creative, se lo è mai stato: "giovane" qui significa "manodopera a buon mercato", mentre altrove vuol dire "mente fresca e nuove idee". Il pantano che l'Italia è diventata premia la mediocrità, l'omologazione e la conservazione, a scapito dell'innovazione.

Nessuna sorpresa, credo: prevalentemente Ubuntu sul desktop e CentOS sul server (tranne che presso i clienti commerciali più grossi, dove domina RHEL).

Sono un ateo convinto e aborro qualsiasi tipo di fondamentalismo, quindi dovrei dire Torvalds.

Tuttavia trovo sacrosanti (!) i principi difesi dalla FSF, sebbene RMS spesso riesca a talebanizzarli oltre misura. Giusto per citare un caso che mi riguarda, di recente il buon Richard ha aperto una polemica su la "non-libertà" del codice JavaScript compresso e/o offuscato presente in molte applicazioni web (ad esempio GMail), e ha suggerito che i browser verificassero l'aderenza degli script ai canoni del FLOSS, e in caso contrario consentissero all'untente di rifiutarne l'esecuzione o di sostituirli con un surrogato accettabile. Cosa c'entro io? RMS ha suggerito che NoScript venisse modificato per servire allo scopo, e ne ha anche discusso con me che, sebbene perplesso, gli ho confermato la fattibilità tecnica della cosa. Dopo qualche tempo ho ricevuto una patch che implementava parte della funzionalità necessaria (sostituzione di script remoti con script locali scelti dall'utente), e l'ho incorporata in NoScript 1.9.9.41 (mai contrariare uno GNU pronto alla carica...)

Certo, non perdo occasione per salutare Francesco Libero detto Ciccio (mio figlio, che ha da poco compiuto un anno), anche se ce l'ho sempre intorno (il suo gioco preferito e "ruba mouse").