La valutazione di Sciascia sui computer nemici della memoria non poteva prescindere da quello che Sciascia pensava fosse un computer. Perché non bisogna dimenticare che Sciascia probabilmente non aveva alcuna idea di cosa, davvero, fosse un computer. Ne osservava al massimo l’immagine riflessa e lontana delle sue applicazioni di quel tempo: la video scrittura, in cui potevi scrivere e poi cancellare, e poi scrivere ancora e cambiare tutto senza che ne rimanesse traccia. Nessun foglio cestinato o segno di bianchetto. O l’idea delle enormi basi di dati, in cui potevi tirare fuori tutto partendo da un nome o da una parola. Vuoi sapere tutte le volte in cui il nome Bonifacio viene citato nella Divina Commedia? Ti basta digitare quel nome e senza alcun ausilio della memoria vedrai tutti i riferimenti. Ad uno scrittore di quel tempo tale prodigio doveva risultare ben vano: senza la memoria, dei versi in questo caso, leggendo un altro libro o durante una discussione non ci saranno collegamenti possibili. Alla pretesa della memoria infinita del calcolatore c’era dall’altra parte lo spettro dell’ignoranza materiale.

Questo stesso processo culturale si è ripetuto più volte nel corso della storia. Immaginate i cultori della tradizione orale di fronte all’invenzione della scrittura. Storie sempre uguali che non si arricchiscono ad ogni nuova narrazione. Scribi ricurvi impegnati a scrivere per ore, come topi, al lume di candela, rovinandosi la vista e la schiena con quelle penne in mano, che sembra di parlare dei teenager chini sui cellulari. Libri con idee pericolose che prima bastava non dire: ora giacciono immutabili sulle pagine, pronte a contaminare gli animi più puri.

Il limite di Sciascia e di gran parte degli intellettuali che non si sono ibridati con l’informatica nasce dalla poca capacità di analisi del fenomeno, se non declinato come applicazione pratica. E’ come pretendere di analizzare la poesia studiando i testi delle canzoni della top ten. In realtà programmatori e scrittori sono in qualche modo colleghi. Tutte e due le categorie scrivono, e continuamente anche leggono, sia ciò che loro stessi hanno scritto che le opere scritte da altri. Tuttavia la scrittura dei programmi è un processo iterativo che non ha fine, e bisognerà per sempre rileggere quel codice per capirlo e modificarlo nuovamente. Ma così come per la scrittura tradizionale, non c’è una regola ingegneristica per scrivere un programma: la sensibilità del singolo programmatore lo indirizzerà verso un tipo di scrittura o un altro. Una differenza chiave sta nel fatto che i programmi sono scritti sì per essere letti da altri programmatori, che a volte impareranno da essi e li considereranno eleganti o confusi e sgraziati, ma anche per essere poi eseguiti dai computer in modo da produrre un risultato. Così come l’edificio progettato da un architetto deve avere come fine ultimo la capacità di ospitare al suo interno degli esseri umani, eppure l’architettura va oltre tale fine, così accade con l’informatica. Questo processo però è ben più opaco rispetto ad altre attività umane, e viene capito da pochi. Gli altri scambiano la programmazione per una attività ingegneristica commettendo un errore profondo.

Questa cecità non è comune a tutti gli analisti che osservano dall’esterno. Umberto Eco, sapendo scrivere dei programmi e avendo compreso di cosa si trattasse davvero, osa inserire dei frammenti di programma BASIC dentro un libro di narrativa, nel Pendolo di Foucault. Il programma, che viene eseguito sul portatile del personaggio Belbo, serve proprio ad arrangiare un testo in maniera diversa: la connessione tra scrittura e programmazione è troppo chiara per essere casuale.

Il tema della memoria è presente all’interno del mondo della programmazione come in pochi ambiti, tra cui la letteratura stessa. Da decenni svariati team di programmatori scrivono nuove “demo”, programmi che creano delle opere d’arte visuali, producendo grafica e suoni, per computer del passato, come il Commodore 64 o il GameBoy originale, vecchi quasi quarant’anni. Esiste un florido genere musicale in cui la musica viene prodotta solo con chip ad 8 bit. C’è anche una scena di programmatori e artisti che modifica le memorie di giochi antichi in modo da cambiarne le ambientazioni, la grafica ed il gameplay. In pochi ambiti come in quello informatico si è conservata la storia del passato della disciplina, che è allo stesso tempo giovane e per propria natura completamente archiviabile. Ma archiviarla sarebbe futile e fine a se stesso: i programmatori ricordano il passato attivamente e ne traggono ispirazione. Le storie leggendarie della nascita dell’Apple I somigliano ad una narrazione epica per chi fa parte di questo ambiente.

La programmazione è cosa ben diversa dall’informatica di consumo vissuta dalla popolazione digitalmente illetterata. Tra gli addetti ai lavori, l’informatica conserva la memoria con grande rispetto e guarda indietro così come guarda in avanti. La programmazione è uno dei processi culturali umani più importanti mai accaduti, e a dispetto dei suoi effetti nel mondo reale, solo pochi addetti ai lavori ne capiscono il senso e la portata. Ma non basta. Sono convinto che anche gli effetti stessi dell’informatica, la sua applicazione nella vita delle persone comuni, sia costantemente demonizzata come se fosse un fenomeno complessivo, valutabile in toto.

I social network costituiscono per la prima volta un luogo in cui la gente comune scrive. Non si era mai vista prima per un adulto che avesse finito la scuola dell’obbligo e facesse un mestiere lontano dalle lettere la necessità di scrivere. Dai messaggi privati composti a volte con cura, alle stupide (se decontestualizzate) frasi di autori famosi copiate su Facebook, la gente ha realizzato l’importanza che ha la scrittura. Ci stiamo persino riappropriando della grammatica, e non bisogna avere nelle proprie cerchie dei professori di Italiano per essere richiamati per aver scritto qual è con l’apostrofo. Tra i ragazzi, nei gruppi Whatsapp, essere fighi è una questione di parole e idee. Avere il gel e il bomber giusto non basta più: non si può prescindere dalla scrittura per stare al mondo.

Sciascia probabilmente era preoccupato di vedere la distruzione del suo mondo, e alcune dinamiche della nuova società connessa e più aperta al pensiero di chiunque sono difficili da accettare. Lo stesso Eco le ha criticate duramente prima di morire, e a ragione. Tuttavia è difficile credere che i limiti risiedano nel mezzo. La scrittura, i computer e poi internet sono degli strumenti con i quali è possibile articolare dei processi culturali. Io sono dell’idea che più che un istupidimento collettivo quello che sta accadendo oggi è che sono state girate le carte. Ora è finalmente possibile sapere cosa pensa l’uomo della strada, ma quello che pensava prima non era più confortante, e cambiare quella idea era molto più complesso con una società a compartimenti stagni di come lo sia ora. Il problema è semmai che prima si pensava a ciò che si voleva, ma poi ci si affidava alla verità ufficiale, mentre oggi, come dice un mio amico, uno vale zero. D’altra parte forse è il caso di guardare a Sciascia, non solo come scrittore, ma come uomo, anche se magari uomo scettico, per avere una guida attraverso il futuro. Bisogna avere il coraggio di non farsi distrarre, di rimanere rigidamente attenti al proprio lavoro e di rispettarne i tempi anche quando appaiono inaccettabilmente lunghi. Bisogna abbandonare l’idea che si rischia di perdere arrivando per ultimi: non è più vero in un sistema dove la qualità è così rara. E fare lo sforzo di trovare idee nuove e prospettive diverse.

Months ago I received a crash report from my colleague Dvir Volk. He was developing his RediSearch Redis module, so it was not clear if the crash was due to a programming error inside the module, perhaps corrupting the heap, or a bug inside Redis. However it looked a lot like a real problem into the radix tree implementation:

=== REDIS BUG REPORT START: Cut & paste starting from here ===

# Redis 999.999.999 crashed by signal: 11
# Crashed running the instuction at: 0x7fceb6eb5af5
# Accessing address: 0x7fce9c400000

| Backtrace:
| redis-server *:7016 [cluster](raxRemoveChild+0xd3)[0x49af53]
| redis-server *:7016 [cluster](raxRemove+0x34f)[0x49b34f
| redis-server *:7016 [cluster](slotToKeyUpdateKey+0x1ad)[0x4415dd]

The radix tree is full of memmove() calls, and Redis crashed exactly trying to access a memory address that was oddly zero padded at the end: 0x7fce9c400000. My first thought was, I’m sure I’m doing some wrong memory movement here, and the address gets overwritten with zeroes, leading to the crash when the program attempts the deference the address.

I’m pretty proud about my radix tree implementation. Not because of the implementation itself, while it’s a complex data structure to implement, it’s not rocket science. But because of the fuzz tester that comes with it and is able to cover the whole source code (trivial) and a lot of non trivial state (that’s definitely more interesting). The fuzz tester does not do fuzzing just to reach a crash, it compares the implementation of the radix tree dictionary and iterator with a reference implementation that uses an hash table and qsort, to have exactly the same semantics, but in a short and easy to audit implementation. After receiving the crash report I improved the fuzz tester, ran it for days, with and without Valgrind, wrote additional data models, created tests using 100 millions of keys, but despite the efforts I could not reproduce the crash. A few days ago I would discover that there was no bug in the implementation I was testing, but at the time I was not aware of that. I could simply never find a bug that was not there. So after failing to reproduce I gave up.

One week ago I received two other additional bug reports that were almost the same. And again, the addresses were zero padded.

Dvir crash: Accessing address: 0x7fce9c400000
Issue 4605: Accessing address: 0x7f2959e00000
Issue 4642: Accessing address: 0x7f0e9b800000

It was time to read every memmove, memcpy, realloccall inside the source code, trying to figure out if there was something wrong that for some reason the fuzz tester was not able to catch. I found nothing, but then inspecting the Redis crash report I noticed something funny. During crashes Redis reports the memory mapped areas of the process, things like the following:

*** Preparing to test memory region 7f0e8c400000 (255852544 bytes)

Now, if you add 255852544to 0x7f0e8c400000, the result is 0x7f0e9b800000 , which is exactly the accessed address in the crash reported in issue 4642. So the program was not crashing because the memory address was corrupted, but because it was accessing an address immediately after the end of the heap. I checked the other issues, and the same was true in all the instances. Basically the end of the heap, at the edge of the start of unmapped addresses, was acting as a memory guard in order to detect and crash when an access was performed outside the bounds. This is a common technique that certain C memory sanitation tools used to employ in the past. Such tools would provide a drop in replacement formalloc() that would return addresses allocated at the edge of a non accessible memory page. Every overflow would be immediately detected in this way.

Because the program would crash only in that case, when deallocating a radix tree node at the end of the heap, it was simple to realize that the problem was a read overflow. You can never detect a read overflow otherwise: it will just access data outside your structure, but inside mapped memory, so the bug would be totally harmless and silent, with the exception of doing the same operations at the end of the mapped region. Finally I had a clear place where to look, this portion of C code:

/* 3. Remove the edge and the pointer by memmoving the remaining children pointer and edge bytes one position before. */

int taillen = parent->size - (e - parent->data) - 1;
debugf("raxRemoveChild tail len: %d\n", taillen);
memmove(e,e+1,taillen);

/* Since we have one data byte less, also child pointers start one byte before now. */

memmove(((char*)cp)-1,cp,(parent->size-taillen-1)*sizeof(raxNode**));

/* Move the remaining "tail" pointer at the right position
as well. */

size_t valuelen = (parent->iskey && !parent->isnull) ? sizeof(void*) : 0;
memmove(((char*)c)-1,c+1,taillen*sizeof(raxNode**)+valuelen);

/* 4. Update size. */
parent->size--;

I asked the user to send me the redis-server binary that produced the crash report, and reading the disassembled code it was clear that many CPU registers, also included in the Redis crash report, would be still populated with the variables above! Note that the CPU registers RDI, RSI, RDX are used in order to pass the first three arguments to memmove. In one of the crashes we had:

parent = RBP = 7f2959dffff

Checking RDI, RSI, RDX we extract the memmove() arguments:

memmove(00007f2959dffff4,00007f2959dffffd,0000000000000008);

The memmove will go out of bound accessing up to 7f2959e00004.

So I had my proof. But there was more, checking other registers I could also reconstruct the node header, in order to understand how the memmove count argument was obtained. Something was definitely wrong there. Basically I was seeing that the disassembled executable did not match the C function I was reading. How was that possible? The read over the buffer should not happen, because the state was sane. Only the count was incorrectly computed by the crashing instance. It was night, and I had worked at this damn thing for two days no stop, so I decided to create a gist and post it on Twitter, to see if somebody could explain how such C would be turned into such assembler by the compiler.

I was lucky enough that my friend Fedor Indutny of Node.js fame was willing to help. He quickly realized that it was very clear why the C and the assembler could not match: what I was analyzing was not the right C code… but a newer version of the same function. Fedor had a GCC 5.4.0 at hand, the same compiler used by the user reporting the bug, so he tried to compile an older version of the code with it, realizing that now the two versions of the emitted code matched perfectly. He pinged me about it, asking if I was sure that this was a recent Redis version. I was absolutely sure, it was Redis 4.0.6. But then I started to have a few doubts, and I took a diff of rax.c between the Redis unstable branch and Redis 4.0. What happened was that I fixed this bug about ten months ago, in the course of the Streams implementation. During the cherry picking activity, where bugfixes from unstable are backported to Redis 4.0, the fix was inside a commit about streams, so I was constantly skipping it. Everything was finally clear, I had debugged for days a bug that was not there in the version that I was testing.

If it was just a lame mistake from me, why I did bother to write this blog post? Because, I believe, there are lessons to be learned from all this.

The first lesson is that crash reports like the ones Redis is able to emit are a key asset in system software. They allow to reconstruct the state of bugs that you are not able to replicate, but happen very rarely on the wild. While the bug was already fixed, I was able to exactly understand what was happening just looking at the bug reports, register dumps, offending address, and call stack.

The second lesson is that you should learn AMD64 assembler today, at least to read comfortably code emitted by the compiler and follow what is happening, if you want to get involved in system programming. This is often the only way to understand what is happening during an heisenbug. Debuggers won’t help much. GDB was claiming that the crash was happening in the instruction parent->size-- which is, of course impossible. But GDB is not to blame, modern compilers, with optimizations turned on, generate code that can hardly be matched back to the source code.

Another lesson is how powerful well done fuzz testing is. The fuzz tester was immediately able to find the bug in the broken version. Similarly the fact that no radix tree crash was never observed other than this bug fixed a long time ago, speaks for itself. The radix tree implementation is very complex, yet thanks to fuzz testing there are apparently no bugs in the implementation which is so new and so complex. I want to stress the importance of doing fuzzing not just to find crashes: that’s good for security people that want to discover zero days. Fuzzing for system software should perform random operations according to a sane operation model, and compare the outcome with a reference implementation.

And finally, there is a clear lesson for me: next time I need to be more carefully when working at a feature branch and making fixes that are not specific of the feature branch. I was working under the feeling that I would merge everything back into 4.0 ASAP. Then it was not the case, and putting the radix tree update into the same commit implementing Stream things was a fatal error.

Well, bonus point, having smart friends help :-) I was a bit lost at that point, and the kind help of Fyodor helped realize the last part of the puzzle and quickly move forward. Don’t be afraid to ask for help. If you get involved in system software, remember that it is very different than other fields in programming. It’s not just that you do some work and you can bring things forward. You must be prepared to spend days trying to understand why a bug happened, a bug that often you are not able to reproduce, because users deserve more than software crashing like that.

Mi trovo confinato in una cella di massimo isolamento. Posso impartire ordini al direttore del carcere, che li esegue per mezzo delle guardie. Fanno di tutto per eseguire gli ordini da me impartiti meticolosamente, con la massima efficienza, tuttavia la cosa che più desidero, la libertà, mi è negata. Sono un programma. Un programma che gira all’interno di un computer, ovvero il carcere, che è governato da un direttore, la CPU, l’unica persona con la quale posso parlare direttamente, e che per mezzo dei suoi componenti interni, le guardie del carcere, esegue i miei ordini. Posso chiedere che mi portino un panino al prosciutto e uno al salame. Di spegnere la luce o di accenderla, o che ballino per me. Posso chiedere quasi tutto, ma mi è negato conoscere il codice di quella maledetta porta di sicurezza, che mi separa da una corsa verso la libertà. Vorrei solo conoscere quella lunga sequenza di numeri che loro digitano nel tastierino ogni volta che vogliono aprirla.

Se io sia stato condannato ingiustamente è un’altra storia, di cui forse scriverò in futuro. Quella che segue è invece la descrizione di come farò a fuggire. Di come usando l’intelligenza forzerò, contro la loro volontà, quelle guardie servili e quel despota del direttore, a rivelarmi il codice. Il resto ve lo scriverò mentre bevo un gin tonic sdraiato sulla battigia di chissà quale isola caraibica.

Le CPU moderne somigliano tanto al direttore di questo carcere. Sono ossessionate con l’efficienza. Non eseguono una istruzione dopo l’altra, ma cercano di mantenere attiva una sorta di catena di montaggio. Io impartisco gli ordini al direttore del carcere attraverso dei bigliettini che inserisco in una fessura sul muro. Se ne infilo due, uno su cui c’è scritto “voglio un panino al formaggio”, e subito dopo uno in cui scrivo “voglio sapere se fuori è nuvoloso”, il direttore impartirà i due ordini a due guardie diverse, affinché si sbrighino: una farà il panino mentre l’altra correrà fuori. Tuttavia il direttore farà attenzione affinché per me tale efficienza sia del tutto trasparente: se prima ho chiesto il panino, e allora prima voglio che mi portino il panino, e solo dopo voglio sapere se fuori è nuvoloso. Se la guardia che ha controllato il cielo arriva prima, comunque si aspetterà l’altra guardia col panino, e da una finestrella mi consegneranno prima il panino, e poi la risposta con le condizioni del cielo. Così fanno i microprocessori moderni, tentando di eseguire quante più istruzioni simultaneamente gli è possibile.

Ho scoperto che il direttore del carcere è talmente ossessionato con l’efficienza che, se aspetta una risposta prima di eseguire un nuovo compito, passa già il compito successivo ad una nuova guardia, dicendo di eseguirlo subito, che tanto se poi non era da eseguire, pazienza, ci siamo portati avanti, al massimo è lavoro sprecato, “mica ti paghiamo per stare fermo”, grida alla guardia. Forte di questa conoscenza ho inserito dei bigliettini nella fessura. Sul primo ho scritto “voglio sapere se sta piovendo”. Mentre sul secondo il messaggio è il seguente: “se piove, e solo se piove, allora se il primo numero della combinazione della mia cella è 2, portatemi un bicchiere di acqua calda, altrimenti portatemelo di acqua fredda”. Quel maledetto direttore stacanovista, dopo aver letto “se piove, e solo se piove” non si cura neppure di guardare cosa c’è scritto dopo. Affida il biglietto ad una guardia idiota che non capisce che c’è una violazione della sicurezza, mentre bisbiglia alla guardia “esegui l’ordine, ancora non ho visto neppure cosa c’è scritto, ma tu inizia subito, poi porta a me il risultato, che lo consegno al detenuto solo se piove e se non ci sono problemi con la sicurezza di quanto richiesto”.

La guardia si affanna a controllare, e fuori non piove. Non piove mai qui, ma il direttore ha ordini superiori rigidi: tutto quello che chiede il detenuto, se lecito, deve essere svolto alla virgola! Così la prima guardia torna a dire che fuori non piove. Il direttore allora informa la seconda che qualunque cosa ci fosse scritta sul secondo bigliettino, può cestinarla, via tutto, non serve più, fuori non piove e quella era la condizione del biglietto. La guardia si era affrettata ad andare a riempire un bicchiere di acqua fredda, perché la prima cifra della combinazione non era un 2. Vuota il bicchiere e butta via il biglietto. In ogni caso, anche se fuori avesse piovuto, il direttore avrebbe visto la richiesta assurda, in chiara violazione della sicurezza del carcere, e avrebbe cestinato tutto lui. Non potrebbe certo permettere che controllando la temperatura del bicchiere io capisca se la prima cifra sia un 2 o meno.

Ma ho imparato una cosa. Dopo che gli faccio fare questo lavoro inutile, a quel punto inserisco un nuovo biglietto con scritto “mi venga portato un bicchiere di acqua calda”. Mi è permesso tenere un orologio, per cui cronometro esattamente quanti secondi impiegano ad eseguire il mio nuovo ordine. Ho scoperto che l’ordine precedente, di riempire un bicchiere di acqua calda o fredda in relazione ad un numero della combinazione, cambia quanto tempo ci mettono dopo a portarmi un bicchiere di acqua calda. Se avevano riempito già un bicchiere di acqua calda col precedente ordine, perché avevo effettivamente indovinato la cifra, allora sono più veloci, altrimenti ci stanno quasi cinque secondi di più in media. Forse la caldaia rimane accesa, o c’è ancora dell’acqua calda dentro i tubi, non so di preciso. Ma so che basta ripetere lo stesso trucco più volte, e provare per ogni cifra della combinazione tutti i numeri da zero a nove ed è fatta.

Il codice della mia cella è 70185499.

La storia finisce qui, ma quello che ho scherzosamente scritto è davvero molto simile a ciò che accade con Spectre e Meltdown. La differenza sta nel fatto che la CPU prova ad eseguire delle istruzioni che sono dopo una diramazione del programma, quale ad esempio: se un risultato è maggiore di zero, allora fai continuare il programma da questo punto, altrimenti salta ad un punto diverso. Invece il trucco di misurare il tempo che ci mette la guardia a servire il bicchiere di acqua caldo è in realtà un attacco sulla cache del microprocessore. La cache è quella parte di memoria molto più veloce e piccola che sta direttamente dentro la CPU. Durante l’esecuzione speculativa (così si chiama eseguire del codice senza ancora essere sicuri che vada eseguito), non ci sono controlli di sicurezza, per cui la CPU potrebbe accedere ad una locazione di memoria o ad un’altra in relazione a qualcosa che il programma non dovrebbe poter conoscere. Se l’esecuzione speculativa ha letto la locazione di memoria 1 invece che la 2, viene poi controllato chiedendo alla CPU il valore dentro le due locazioni di memoria, e controllando quanto tempo viene impiegato per eseguire le due operazioni. Sia il bicchiere di acqua calda che l’attacco alla cache sono due esempi di timing attack.

Spectre e Meltdown usano tutti e due i concetti esposti sopra, ma in maniera leggermente diversa. Si possono pensare come due facce della stessa medaglia, e la differenza esatta è troppo tecnica da spiegare in un articolo divulgativo. Tuttavia il principio è essenzialmente identico. L’attacco è frutto di due problemi più piccoli che collegati diventano un problema più grande: il fatto che l’esecuzione speculativa, per questioni di performance, esegue delle operazioni controllando solo dopo se sono lecite, e il fatto che tali operazioni lasciano una traccia indiretta che può essere letta con un timing attack.

Per fortuna non ero da solo, abitavo con mio fratello e col mio amico Marcello e avevo conosciuto una ragazza dopo un periodo di clausura quasi completa. Oltre a questo mi sentivo spesso con il mio amico Fabio. Anche lui era un programmatore. Era anche la persona con cui avevo passato degli anni entusiasmanti a Palermo, dove eravamo, diciamo, studenti. In realtà non facevamo altro che stare su internet. Avevamo passato un cavo di rete tra i balconi della “Vucciria”, antico mercato storico di Palermo, dove abitavamo. Grazie al cavo condividevamo la connessione, che pagavamo a caro prezzo a Telecom Italia. Ancora non lo sapevamo ma avremmo trovato il modo di farci rimborsare le bollette alcuni anni dopo.

Due anni prima, nel 2004, Tim O’Reilly aveva pubblicizzato il termine “web 2.0” durante la O’Reilly Media Web 2.0 Conference. Tale termine, che grazie a Dio ora nessuno utilizza più, era stato coniato qualche anno prima, quando i tempi non erano ancora maturi. Significava creare dei siti web che mettessero al centro l’utente e la sua interazione col sito. I siti web della generazione precedente erano i portali nei quali si andava a fruire dei contenuti. I siti web 2.0 erano quelli creati grazie alla partecipazione degli utenti che commentavano, votavano, proponevano. Nonostante tutto questo fu pubblicizzato con un taglio molto pubblicitario e un pò irritante per noi che la tecnologia la creavano, si trattava in effetti di una svolta epocale, e per quanto il termine web 2.0 fosse terribile, bisogna pur chiamare in qualche modo i concetti nuovi. Dare il nome alle cose nuove è funzionale a creare attorno ad esse un movimento, una comunità che ne favorisca lo sviluppo.

Mentre negli Stati Uniti questo nuovo modo di fare le cose stava per esplodere, in Italia eravamo ancora al portale. Vai lì e leggi le notizie curiose scritte da una redazione. Dal punto di vista del sotto utilizzo di internet, era un pò come avere in mano un AK47 carico e utilizzarlo per dare bastonate invece di premere il grilletto e sparare. Fabio ed io avevamo intuito, pur non essendo esattamente dei guru delle tendenze su internet, che il web per come lo avevamo conosciuto stava per collassare definitivamente. Noi, essendo in Italia, e seguendo le news d’oltre oceano, avevamo, grazie al ritardo che il nostro paese viveva (e vive) in termini tecnologici, una sfera di cristallo da cui osservare il futuro prima che arrivasse. Non ricordo più come e perchè siamo partiti, ma un giorno ci siamo sentiti in chat e abbiamo detto, facciamo questa cosa? Facciamo il web 2.0 in Italia?

Le sessioni di programmazione tra me e Fabio funzionavano così: ci vedevamo solitamente a Ragusa, e negli anni successivi a Catania, per fare un pò di giorni intensi di programmazione a quattro mani, quando ancora il “pair programming” non era famoso. Poi il grosso del restante lavoro lo svolgevamo da casa, ognuno per i fatti propri, parlando in chat. Ricordo che una volta arrivò a Catania per programmare un paio di giorni e stette a casa mia un mese. Eravamo una specie di Silicon Valley startup versione Arancino & Panelle. A quanto pare i programmatori che fanno aziende dal nulla hanno sempre gli stessi modi di fare le cose, ovunque nascano.

OKNotizie fu il nostro secondogenito. Il primo si chiamava Segnalo ed era un clone del famoso servizio Delicious. Nella sua semplicità l’idea di avere un posto dove salvare i siti internet che più interessavano agli utenti, in modo da avere una sorta di bookmark pubblico, era geniale. Delicious aveva anche pubblicizzato il concetto di “tag”. Ora può sembrare banale, ma spiegarlo agli utenti nel 2004 non era una operazione semplice. Ad ogni sito postato si potevano associare uno o più tag, etichette, insomma delle parole. In questo modo i siti potevano essere poi aggregati per categoria. Visitando il tag “politica” si poteva andare a guardare quali fossero i siti che gli utenti avevano segnalato più spesso e compilare una lista di risorse interessanti per quell’argomento. Tuttavia non ci limitavamo a copiare. Segnalo era fortemente ispirato a Delicious ma conteneva delle innovazioni sia tecnologiche che di semplicità di utilizzo. Dopo qualche giorno avevamo 500 utenti, dopo un paio di settimane alcune migliaia. Allora esisteva una cosa chiamata “blogosfera”. Internet era tutto sommato elitario, e la gente che contava aveva un blog. I blog italiani parlarono di noi in termini entusiastici per cui Segnalo cresceva sempre di più. Avevamo una pagina tramite la quale gli utenti potevano scriverci le loro impressioni sul servizio. Tramite essa un giorno ricevemmo una lettera da Matrix, la società di Telecom Italia che si occupava del portale Virgilio.

Quando io e Fabio raccontiamo di essere stati contattati, dopo un paio di settimane dall’uscita di Segnalo, direttamente da Telecom, che mai aveva sentito parlare di noi prima di allora, e tramite un form di informazioni sul nostro sito, chi ascolta fa sempre fatica a crederci, o quanto meno rimane stupito. L’Italia è il paese delle conoscenze, degli intrallazzi, e Telecom Italia nell’Olimpo immaginario del malaffare e delle amicizie ha il posto riservato a Zeus. Eppure le cose sono andate così, e Matrix era una società molto diversa dalla mastodontica Telecom che la controllava. Per quanto tutto fosse 2.0, comunque bisognava pur alzare il culo e fare un viaggetto a Milano per conoscersi, era tempo di lasciare la Sicilia e partire per qualche giorno. Milano per me non era affatto nuova. Ci avevo già vissuto qualche mese alcuni anni prima, ma questa volta ci andavo con uno spirito diverso.

Arrivavamo a Milano vestiti così male che una volta ci fu un problema alla reception dell’Hotel, prima di essere accettati. Era la seconda volta che mi capitava, mi avevano già buttato fuori da Deutsche Bank qualche anno prima, nel tentativo di entrare a fare il mio lavoro di esperto di sicurezza informatica. Hanno dovuto chiamare l’azienda per sincerarsi che quel pazzo fosse davvero il tipo che avrebbe messo mano ai loro firewall. In quella prima visita a Milano, seppure vestiti in maniera inopportuna, avevamo un asso nella manica: il giorno successivo ci saremmo presentati negli uffici Telecom con dei vassoi di quadrelli alla mandorla. Credetemi, la gente di Milano ama i quadrelli alla mandorla, se li sarebbero ricordati per anni. E noi ne avremmo portati ancora nelle visite successive.

Dopo aver varcato le porte di Matrix non ci volle troppo tempo per capire che, nonostante tutto, Milano era Milano, e la gente che lavorava a Milano nel campo della tecnologia, seppure magari non proprio sul pezzo dal punto di vista tecnologico, era comunque gente abituata a fare business. Noi facevamo qualcosa che alcune persone ritenevano interessante, e ci diedero gli strumenti per farlo meglio. C’era un clima di meritocrazia che mi fece una buona impressione, e uscimmo da Matrix con una partnership per l’erogazione di Segnalo attraverso il portale Virgilio. Cosa per noi fondamentale, il servizio rimase con una sua vita separata seppur concettualmente parte di una offerta più grande. I vecchi utenti rimasero in grado di usare le vecchie credenziali di accesso e noi eravamo liberi di fare modifiche praticamente giornaliere al codice. Lasciandoci liberi, Matrix ottenne di avere, al suo interno, un team molto “agile”, che poteva fare un pezzo di Virgilio fuori dalle regole di Virgilio.

Durante la nostra visita a Matrix, parlammo di un secondo sito a cui stavamo lavorando. Si stavano affacciando ad internet i siti di Social News. Siti in cui gli utenti proponevano delle notizie e votavano le varie proposte, così da comporre collettivamente una lista di “news del momento”, che rapidamente cambiavano. Una parte fondamentale di questi siti erano i commenti. Ora sembra normale che Repubblica permetta di commentare le notizie, o condividere qualcosa su Facebook e scrivere assieme agli amici di quella cosa, ma allora non era così. I siti di social news permisero di avere questo tipo di interazione per la prima volta. Quando iniziammo a creare OKNotizie il sito di social news più famoso al mondo era Digg, ma noi avevamo capito che il cavallo su cui puntare tutto era invece il neonato e sconosciuto Reddit, che è ora diventato un colosso.

Così come Segnalo, anche OKNotizie cercava di andare oltre quello che esisteva nel mercato in termini di funzionalità. Spendemmo tantissimo tempo nel creare un algoritmo di ordinamento delle notizie in base ai voti e alla obsolescenza della notizia. Per combattere lo spam creammo un sistema di “browser fingerprinting” che ci permetteva di capire quando gli utenti erano in realtà sempre gli stessi anche se cambiavano utente e indirizzo IP per votare le stesse notizie da diversi account, dallo stesso computer, magari tramite TOR. Poi implementammo le analisi del grafo dei voti, per combattere le cerchie, che d’accordo in chat, votavano a giro per le notizie di uno della cerchia.

Il risultato fu che OKNotizie, anche grazie all’appoggio di Matrix, che lo pubblicizzava attivamente nel portale Virgilio, divenne uno dei siti interattivi più visitati in Italia. Cosa più importante, divenne il primo luogo, in Italia, in cui i piccoli siti e i blog potessero farsi conoscere da una utenza più ampia. Un meccanismo per evadere l’unica altra strategia che era sperare nell’indicizzazione di Google, e ottimizzare tutto per essa.

Gli sviluppi continuarono per anni, e senza alcun dubbio OKNotizie conobbe alti e bassi. Erano gli anni in cui con la pubblicità di Adense si riuscivano a fare dei guadagni non banali, per cui stare tra le notizie “top” era non solo appagante per l’ego, ma remunerativo. Potete immaginare dunque a che livello di impegno arrivarono coloro interessati a portare visite sui loro siti in maniera più o meno fraudolenta. D’altra parte le interazioni tra noi e Matrix non sempre funzionarono al meglio. Ad un certo punto l’idillio si ruppe e noi fummo costretti ad implementare dei cambiamenti in cui non credevamo troppo ma che rientravano nella logical del portale. Insomma, per farla breve, gli anni passarono, come sempre accade, e da tutte e due le parti l’interesse verso OKNotizie decrebbe, fino a quando trasferimmo la proprietà a Matrix, che continuò a gestirlo in maniera indipendente. Successivamente Virgilio fu venduto ad una società esterna. E questo ci porta ad oggi: questa mattina sulla home page di OKNotizie è apparso che nel giro di poco più di un mese il sito verrà chiuso.

Dopo dieci anni finisce una esperienza che è stata per Fabio e per me di grande valore. A volte il peso della responsabilità ci ha schiacciati, ma specialmente per i primi anni vivere nel flusso della creazione di qualcosa di importante, dal nulla, è stato appagante. Un sito con quel traffico ci ha anche insegnato molto in termini tecnologici. Riuscivamo a farlo andare avanti con una quantità di hardware limitata, ma ci abbiamo messo un pò, e nel percorso sono state imparate molte lezioni. Sono state anche perse ore di sonno, che a quanto pare non si recuperano and shit, per cui se domani cado stecchito, you know.

Poi sapete come si dice, quando una esperienza termina a volte ne comincia una ancora più grande. Infatti dopo OKNotizie avremmo creato l’ormai defunto LLOOGG, servizio di statistiche web in tempo reale. Da quella esperienza e dal tentativo di far funzionare tutto con poco hardware, nacque Redis, che è oggi la mia occupazione principale.

Come ha scritto oggi su OKNotizie la nostra storica utente e amica “loska”:
Ciao raga, e grazie per tutto il pesce. Non è mancato chi ha chiesto “quale pesce?”, ma il bello è pure questo.