Lo si capisce leggendo l’insieme di due interviste concesse da Horace Dediu della società di analisi di mercato Asymco al sudcoreano Chosun Daily e all’edizione britannica di MacUser. Ecco una parte della risposta a una domanda sui limiti di crescita di iOS nel mercato mobile e di Mac tra i personal computer:

The market for mobile phones is approximately 5.5 billion connections, perhaps 5 billion users. The iPhone has approximately 300 million installed base. I consider a base of 1 billion users to be a minimum for continuing participation in this market long term. […] The PC market will still exist 10 years from now but, similar to the mainframe market, it will be hard to notice. […] Applications for PCs are not an area of investment for any significant pool of capital. Development has moved almost entirely into mobile or web. Therefore, as the PC is now a commodity product, the best performers are those who can capture a larger margin. Those margins should be subsequently be invested in new platforms. PC vendors who neither capture margin, nor invest in new platforms are strategically insolvent.

Si capisce che le posizioni di mercato di oggi siano tutt’altro che consolidate. Anche che i giochi saranno finiti nel giro di relativamente poco tempo: le piattaforme “emergenti” alternative ad Android devono mostrare significativi progressi in fretta.

E chi riesce a immaginare un mercato dei personal computer di cui sia difficile accorgersi? Davvero, c’è chi si aspetta un ritorno, in qualche modo oscuro da intuire, al monopolio degli anni novanta. Che invece si allontana sempre più.

Se nell’ambito del software proprietario solitamente sono le aziende produttrici di un determinato software ad attivarsi affinché vengano creati percorsi formativi e di certificazione strettamente legati ai loro prodotti, nel mondo del software libero questa tipo di spinta viene meno per ovvie ragioni. Spetta dunque ai principali enti non-profit o alle aziende impegnate nel ruolo di “piloti” dei vari progetti open source promuovere questo tipo di iniziative.

È il caso recente della Document Foundation, l’ente che coordina e promuove lo sviluppo di LibreOffice; il 7 maggio scorso a Berlino è stato infatti annunciato l’avviamento di un programma di certificazione proprio sulla suite applicativa per l’ufficio più nota e diffusa del mondo open. A coordinare il comitato di certificazione sarà un italiano, Italo Vignoli, da tempo impegnato nella comunicazione e promozione di progetti di sviluppo open e così dichiara:

Il Programma di Certificazione per LibreOffice è un passo importante per la crescita del numero di aziende che migrano alla suite libera per ufficio, perché questo processo è strettamente legato alla qualità dei servizi, che a sua volta è legata alla definizione di metodologie riconosciute e condivise per tutti gli aspetti del processo stesso: sviluppo di template e macro, soluzione dei problemi specifici legati all’ambiente aziendale, formazione degli utenti a tutti i livelli e supporto.

I profili attualmente previsti dal processo di certificazione coprono i principali campi dello sviluppo, della formazione specialistica, della migrazione e della consulenza, e nello specifico sono Certified Developer, Certified Migration Professional, Certified Professional Trainer, L1 Support Professional, L2 Support Professional.

Il testo di questo articolo è sotto licenza Creative Commons Attribuzione – Condividi allo stesso modo 3.0 Italia.

C’è davvero da chiedersi dove siamo veramente arrivati nelle nostre elucubrazioni sul design per il Web (e per il mobile, e per gli ebook) se una pagina del genere è in grado di scatenare una discussione, per il semplice fatto di avere un font piuttosto grande, perfettamente leggibile su desktop e altrettanto su uno smartphone, provare per capire. Una frase per tutte:

This redesign is a response to ebooks, to web type, to mobile, and to wonderful applications like Instapaper and Readability that address the problem of most websites’ pointlessly cluttered interfaces and content-hostile text layouts by actually removing the designer from the equation.

Zeldman prosegue specificando che non si tratta di un atto di accusa contro i siti in questione, bensì una normale constatazione di ciò che fanno e del perché ottengono gradimento, a indicare quanto molto del nostro web design sia patetico nel momento in cui i visitatori si rivolgono sempre più ad applicazioni indipendenti semplicemente per leggere il contenuto di un sito.

Provocazione, evidente. Lo stesso autore mette in chiaro che probabilmente non avrebbe azzardato una cosa del genere sul sito per un cliente. Così come non esita a dire che nessun design è per sempre e che, almeno su un sito personale, la sperimentazione continua sarebbe d’obbligo o quasi.

Soprattutto, sugli schermi di oggi i font di grande dimensione si guardano splendidamente e si leggono con piacere. In tutte le provocazioni costruttive c’è qualcosa da raccogliere e qui dovremmo tenere tutti presente che forse abbiamo perso di vista, mescolato tra il tema da personalizzare, lo spazio del banner, il popup imprescindibile, la tripla colonna che tanto piace al grafico, quello che veramente spinge il visitatore a passare dal nostro sito. Potrebbe essere una community effervescente oppure un carrello della spesa di straordinaria efficienza. O forse il semplice, sempiterno piacere della lettura.

Ivan Rachieli: Le applicazioni web basate su HTML5 e CSS3 consentono di sviluppare prodotti editoriali potenzialmente molto complessi e accessibili utilizzando qualsiasi dispositivo dotato di un browser. Cosa pensi di queste tecnologie? Tra l’altro di Locusta Temporis esiste già una versione accessibile online: stai pensando anche a una vera e propria web app?

Enrico Colombini: La versione online di Locusta Temporis contiene solo il primo capitolo, ma non ci sono ostacoli tecnici che impediscano di pubblicare in questo modo un intero libro, o corsi interattivi, o altre opere. È interessante notare che, siccome concettualmente ciascuna pagina contiene in sé l’intero stato di lettura, non c’è alcuna necessità né di programmazione lato server o lato client, né di ‘salvare’ la situazione: basta usare un normale segnalibro (bookmark) del browser per conservare memoria di tutte le azioni compiute.

HTML5 è certamente interessante e le web app si diffonderanno sempre più, anche se penso che il loro costo di sviluppo sia più alto di quanto possa sembrare, a causa dei ricorrenti problemi di compatibilità con i diversi browser e le relative versioni, dei molteplici aspetti da considerare (server, client e comunicazione) e della necessità di un testing esaustivo. Parlo ovviamente di applicazioni affidabili, perché a fare un programma che funziona solo sui computer di prova sono capaci tutti. Lo so che oggi il software prima si vende e poi lo si fa funzionare, ma io sono della vecchia scuola. :)

Lavorando di HTML5 è possibile giocare a Angry Birds nel browser. Ma i costi di sviluppo per un ambiente in continua evoluzione sono sostenibili?

Personalmente non sono troppo attirato né dalla programmazione per il Web né a maggior ragione dalle web app, un po’ perché sono un orso delle caverne e non amo troppo la comunicazione permanente, un po’ perché ciò mi richama il tempo dei terminali che accedevano a un sistema centrale (il sistema dittatoriale che credevamo definitivamente rovesciato dalla rivoluzione del personal computer), ma specialmente perché mi piace lavorare su basi solide e ben definite e avere tutto sotto controllo, in modo da poter costruire sistemi complessi e affidabili.

A lavorare col Web sembra di programmare una spugna che cambia continuamente forma, per di più usando necessariamente librerie altrui che a loro volta possono avere problemi e cambiare di versione, il tutto navigando su standard in perenne mutamento e mai del tutto rispettati… insomma, mi sembra di costruire le bancarelle della fiera di paese, che domattina saranno smontate, piuttosto che la Tour Eiffel.

Ivan Rachieli: Parliamo di interfacce. Come si guida il lettore attraverso decisioni, scelte ed enigmi, facendo in modo che non finisca per perdersi o per imboccare un vicolo cieco?

Enrico Colombini: Il vicolo cieco è indubbiamente una delle peggiori situazioni che possano capitare al lettore; è assai poco desiderabile rimanere bloccati senza via d’uscita. Per prevenire questa evenienza ho usato tre accorgimenti: un’attenta organizzazione del ‘libro sorgente’ (non dover tenere traccia manualmente delle pagine e degli stati è di grande aiuto), un accurato testing delle possibili scelte e sequenze e, per sicurezza, un ulteriore programmino ausiliario.

Quest’ultimo ha il compito di verificare che la pagina finale (o le possibili pagine, nel caso di finali multipli) sia raggiungibile attraverso una catena di link da ciascuna delle altre pagine, di modo che non possa esistere una pagina ‘bloccante’.

Per quanto riguarda l’interfaccia propriamente detta, uno dei problemi connessi alla presenza di enigmi è che il lettore si ritrova a passare e ripassare più volte dalle medesime pagine… o almeno da pagine che possono sembrargli le stesse perché magari appartengono a un altro stato per effetto di una scelta precedente (e fin qui tutto bene, il lettore non deve saperlo) oppure hanno qualche piccola variante: ad esempio, nella descrizione la finestra è aperta anziché chiusa.

Come può il lettore rilevare la differenza nel testo senza rileggersi ogni volta la pagina, il che porterebbe a una noia mortale? Nel mio caso, oltre ad adottare pagine brevi pensate per essere completamente visibili sullo schermo (almeno con molti reader) ho cercato di piazzare le modifiche in testa o in coda alla pagina, in modo che possano essere individuate con facilità; mi rendo conto che non si tratta comunque di una soluzione ottimale, ma temo che il problema sia insito in questo tipo di lettura.

Tra libri interattivi e videogame si pongono problemi di interfaccia sempre nuovi. Anche per Frotz, una app nata per rigiocare in ambiente mobile le gloriose avventure testuali Infocom.

Per il resto ho cercato di far immedesimare il lettore con il protagonista di turno, in modo che l’interfaccia tendenzialmente sparisca dentro la vicenda stessa, ossia non venga percepita come separata dal testo; ovviamente non pretendo di avere trovato una soluzione ottimale, anzi sono certo che vi sia ancora molto spazio per la sperimentazione.

Ivan Rachieli: Quali sono i tuoi piani per il futuro? Stai lavorando su nuovi ebook interattivi?

Enrico Colombini: Magari! I miei appunti debordano di spunti e idee, ma al momento è meglio che mi dedichi a trovare qualcosa da fare, possibilmente che sia minimamente interessante (cosa assai difficile in Italia dove c’è un’atavica paura di ogni innovazione). Non mi spiacerebbe lavorare ancora nell’industria dei videogame, anche se i grandi sviluppatori cercano più che altro iperspecialisti da incatenare a una specifica scrivania, mentre i piccoli (dove è più facile trovare creatività e innovazione) hanno da far quadrare i conti, soprattutto in questo periodo, e faticano a cogliere i frutti del loro lavoro. Ma qualcosa mi inventerò.

Ivan Rachieli: Grazie di tutto Enrico, e a presto :)

Enrico Colombini: Grazie a te per l’ospitalità e la pazienza :)

(6-fine. I segmenti precedenti dell’intervista sono stati pubblicati in questa sequenza, dall’inizio: Tra ebook e videogiochi: parla Enrico Colombini, 4 maggio; Enrico Colombini: lettori interattivi, libri a misura, 8 maggio; Enrico Colombini, tra narrazione e gioco, 11 maggio; Gioco o ebook? Risponde Enrico Colombini, 15 maggio; Anatomia della Locusta di Enrico Colombini, 18 maggio).

Intanto si chiama commencement address, nonostante sia diretto a studenti al termine del loro corso di studi. In inglese sa di allusione alla vita vera, che sta per avere inizio.

Negli atenei anglosassoni, il saluto agli studenti da parte di un personaggio famoso per il suo lavoro – quindi non un politico di professione – è regola. È recente il discorso dello sceneggiatore Aaron Sorkin agli studenti di Syracuse:

Don’t ever forget that you’re a citizen of this world, and there are things you can do to lift the human spirit, things that are easy, things that are free, things that you can do every day. Civility, respect, kindness, character. You’re too good for schadenfreude, you’re too good for gossip and snark, you’re too good for intolerance—and since you’re walking into the middle of a presidential election, it’s worth mentioning that you’re too good to think people who disagree with you are your enemy.

Ancora più recente è l’intervento di Eric Schmidt di Google presso la Boston University, con il consiglio di spegnere un’ora al giorno la tecnologia e una considerazione in controtendenza:

Your generation’s opportunities are greater than any generation’s in modern history.

Jobs, Sorkin, Schmidt e tutti gli altri portano nelle università la voce autorevole dell’economia e del lavoro. I video e le trascrizioni dei discorsi hanno ampia eco e le argomentazioni più incisive si propagano su tutti i media, verso l’intera comunità, a beneficio collettivo.

È facile ascoltare idee radicali e potenti su come ognuno riformerebbe le università italiane. Privo di competenze in materia come sono, mi accontenterei di copiare dagli americani modalità e ricadute comunicazionali della cerimonia di fine anno.

Dopo aver partecipato nel corso del 2011 a ben 39 conferenze in 27 Paesi, ha scritto un articolo per rispondere ad una delle domande che si è sentito porre più spesso nel corso dei suoi interventi: HTML5 è già pronto?

La sua risposta è sintetizzata nel titolo HTML5 is not ready yet — and will never be (and that is a good thing) – HTML5 Question #1.

A quanto pare l’impostazione, del tutto originale per un documento di specifica, ossia quella di uno standard “vivo” dunque suscettibile di una miriade di frequenti microaggiornamenti, ha lasciato interdetta anche la comunità degli addetti ai lavori. Heilmann però richiama al significato di conformità allo standard.

Standard compliance on the web is a means to an end. It made it easier to track mistakes and it made your work understandable by other developers but when it comes to delivering web products, it had not much impact. As web developers we were constantly asked to build interfaces and apply designs and interactions that were never defined in the standard. Which is why we had to find ways to do that which in a lot of cases meant abusing the standard.

Proprio per via di questo continuo abuso dello standard cui fa riferimento Heilmann e per via della necessità di far fronte ad un sistema che cambia di continuo, il modo migliore per affrontare questo scenario è fare affidamento su di una serie di norme che sanno adattarsi al cambiamento.

So no, HTML5 is not ready and will never be — and that is a good thing. We have a standard for the web with all its change and adaptation and not a software standard that expects 5 year turnaround times in innovation.

Lontano dalle roboanti dichiarazioni di marketing, HTML5 è già oggi strumento irrinunciabile di qualunque sviluppatore web.

Con tutto il rispetto, va presa come fantascienza suggestiva e vagamente messianica e niente più, a dispetto dei tanti che hanno deciso di abbracciare il credo dello scientismo (cosa ben diversa dalla scienza), per via di pensieri come questi (tratti dalla versione originale):

Most long-range forecasts of what is technically feasible in future time periods dramatically underestimate the power of future developments because they are based on what I call the “intuitive linear” view of history rather than the “historical exponential” view.

In sintesi, l’innovazione futura viene sottovalutata perché non vediamo l’accelerazione del progresso e quindi sappiamo che – siccome accelera – il progresso sarà fantastico, non importa il perché.

Il progresso non accelera affatto; la rivoluzione digitale ha avuto inizio quarant’anni fa con l’invenzione del microprocessore, per iniziare a disvelarsi solo oggi, nel momento in cui hardware e software stanno arrivando faticosamente al momento magico. Non è la singolarità di Kurzweil; più modestamente (e molto più concretamente), è la disponibilità allargata a basso prezzo di hardware e software.

Nel 2045 avremo le basi dell’immortalità, come sostiene Kurzweil? Liberi di crederci. Preferisco godere del presente. In cui, per esempio, la disponibilità allargata di hardware e software permette a Claire Lomas, donna paralizzata dal torace in giù, di completare una maratona in sedici giorni. O rende Cathy Hutchinson, tetraplegica da quindici anni, capace di controllare un braccio robotico con il pensiero.

Ne vedremo di sempre più incredibili e meravigliose. Tra trentatré anni non avremo alcuna singolarità. E invece migliaia, milioni di tanti piccoli, decisivi progressi. Umani.

Ivan Rachieli: Veniamo a Locusta Temporis. La prima cosa che mi piacerebbe spiegassi ai nostri lettori è come hai progettato e costruito l’architettura della narrazione, delle interazioni e degli enigmi.

Enrico Colombini: Durante la progettazione di Locusta Temporis ho deciso di pensare al racconto interattivo come a una macchina a stati. Supponiamo che il lettore abbia la scelta se lasciare aperta o meno una finestra dalla quale, più avanti nella storia, potrà entrare un’allodola. L’unica cosa che il lettore può fare è scegliere tra due link: un link porterà alla pagina in cui la finestra rimarrà chiusa, l’altro alla pagina in cui la stessa finestra starà aperta.

Il problema è come memorizzare questa scelta, in modo da poterne tenere conto dopo qualche pagina, quando l’allodola potrà entrare e svegliare il protagonista solo se la finestra era stata precedentemente lasciata aperta. In un programma per computer mi basterebbe tenere lo stato della finestra in una variabile (scriverlo in una casella di memoria) per rileggermelo più tardi; in alcuni formati e lettori di ebook ciò potrebbe essere possibile, ma in altri no e non ci posso quindi far conto: devo comportarmi come se stessi scrivendo un libro stampato, che non possiede memoria. E nemmeno voglio obbligare il lettore a tenere nota dello stato della finestra segnando una crocetta su un’apposita casellina, come si usava negli antichi libri-gioco.

Non ho che una soluzione: far proseguire il lettore lungo due serie di pagine parallele, magari contenenti identico testo ma comunque separate tra loro; è come passare uno scambio ferroviario scegliendo tra due binari, che però rimangono paralleli. Solo più avanti nella vicenda le due serie di pagine divergeranno descrivendo eventi diversi, a seconda di quale binario sia stato imboccato all’inizio; ciascuna delle due serie di pagine rappresenta un diverso stato (finestra aperta o finestra chiusa).

La scelta del lettore sposta la narrazione su un binario possibile, corrispondente a una serie di pagine almeno inizialmente parallela alle altre.

Parrebbe che con un simile meccanismo di base non si possano realizzare costruzioni troppo complesse né tantomeno enigmi interessanti, dato che ad ogni scelta aggiuntiva la complessità si moltiplica; ad esempio per memorizzare cinque scelte indipendenti servono ben trentadue serie di pagine separate. Invece è perfettamente possibile se si riesce a tenerne sotto controllo la complessità: per chi fosse interessato, ho pubblicato un articolo che esplora alcune costruzioni realizzabili con questo sistema, molte delle quali sono usate in Locusta Temporis.

Pensavo anche che fosse difficile realizzare enigmi non banali, tanto che nei primi capitoli mi sono forse concentrato un po’ troppo sui puzzle rispetto alla narrazione, ma i risultati sono stati comunque interessanti, forse anche troppo, dato che diversi lettori hanno trovato alcuni enigmi più impegnativi di quanto mi aspettassi, benché avessi fatto leggere/giocare il libro a diversi collaudatori e in vari casi avessi ridotto la difficoltà dei puzzle. Probabilmente la forma libro fa sembrare le stesse situazioni più complesse di quanto apparirebbero se incontrate in un gioco.

Qui ci starebbe anche una questione di progetto dei racconti interattivi: puntare molto sugli enigmi (gioco puro) oppure renderli semplicissimi, quasi automatici o addirittura assenti, per non disturbare la narrazione (lettura pura)? Ho cercato di tracciare una delle possibili infinite vie di mezzo, ma saranno i lettori a dire se ci sia riuscito o meno.

Ivan Rachieli: Locusta Temporis è sia un ebook (in ePub, mobi e PDF) sia un’applicazione per iOS. Ci spieghi come hai organizzato il flusso di lavoro in modo da poter partire da una base comune di contenuti?

Enrico Colombini: Il sorgente comune del libro è un ibrido tra un testo e un programma: ciascuna pagina è in realtà una funzione in linguaggio Lua che, per così dire, stampa il testo corrispondente allo stato corrente della pagina stessa. Si tratta di un’impostazione per vari aspetti simile a quella del mio vecchio Idra, uno strumento per la costruzione di racconti interattivi Web, ovvero un normale programma che usa variabili per memorizzare tutte le informazioni necessarie.

La conversione di questo sorgente in un insieme di pagine immutabili collegate da link, ciascuna delle quali è una diversa istanza di una delle mie pagine originali e ne rappresenta un diverso stato, è opera di Medusa (Macchinario Esente Da Un Significativo Acronimo). Si tratta di un compilatore che non saprei se definire di Intelligenza Artificiale o di Pigrizia Naturale, dato che lo scrissi per evitare il lavoraccio di tener traccia a mano di tutte le necessarie varianti delle pagine e soprattutto dei numerosi link incrociati.

Questo è solo l'inizio dello schema della toolchain Medusa, che invitiamo a consultare per intero seguendo il link proposto nell'articolo.

I frammenti di codice del ‘libro sorgente’ vengono eseguiti non durante la lettura, dato che ciò non sarebbe possibile, ma durante la fase stessa di compilazione (tecnicamente si tratta di un metaprogramming compiler), producendo tutte le pagine necessarie per rappresentare ogni possibile stato raggiungibile durante la lettura.

Medusa produce un singolo file HTML contenente tutte le pagine del libro, o più comunemente quelle della parte di libro che scelgo di compilare per risparmiare tempo di caricamento nel browser durante le prove: se mi limito a un capitolo, in un paio di secondi dalla modifica del ‘sorgente’ posso leggere le pagine prodotte e verificarne il corretto funzionamento (durante la lavorazione produco una singola pagina HTML con link interni, invece che tanti file quante sono le pagine finali, perché il sistema operativo è relativamente lento nella creazione di molti file).

Una volta verificato che tutto sia a posto, a partire dal singolo file HTML produco le differenti versioni: ePub, Kindle/Mobipocket, PDF, pagine Web separate (per il demo) e infine l’applicazione iOS. Il lavoro dal lato PC è svolto da una serie di programmi che formano una toolchain – ma penso che il termine tecnico sia accrocchio – composta da convertitori scritti per la maggior parte in linguaggio Lua, ma comprendente anche tool esterni come kindlegen di Amazon e html2ps (un convertitore da HTML a PostScript scritto in Perl da Jan Kärrman).

La messa a punto di questa toolchain è costata molto più lavoro del previsto. In particolare la produzione della versione PDF necessita del citato html2ps, l’unico convertitore open source che si sia dimostrato capace di trattare correttamente le 5.800 pagine e gli 11 mila link di Locusta Temporis, sia pure in tempi molto lunghi (45 minuti sul mio PC).

Purtroppo il programma non è recente e accetta solo HTML (in pratica il 3.2), quindi niente CSS veri e propri; ciò ha condizionato l’intero meccanismo costringendomi a partire dall’HTML puro (con tutti i suoi limiti) e a convertirlo poi in XHTML per convenienza del resto della toolchain e dei reader, con annessa conversione da ISO-8859-1 a UTF-8… e sorvolo su altri problemi.

Ulteriori complicazioni sono venute dai cosiddetti ‘standard’ come ePub, che in pratica ciascun produttore di reader (hardware o software) interpretava e forse ancora interpreta a modo suo, spesso introducendo limitazioni arbitrarie (è inevitabile l’analogia con i browser Web, specie quelli dei primi tempi).

Arrivare a fare funzionare Locusta Temporis su tutte le piattaforme di ebook più diffuse più una app iOS ha richiesto un lungo lavoro di affinamento.

Ad esempio, alcuni reader non riuscivano nemmeno a caricare l’obbligatorio (quanto inutile, nel mio caso) elenco XML delle pagine del libro, costringendomi a comprimerne i numeri con un codice in base 26 per occupare meno spazio nel file stesso. Naturalmente ciascuna versione finale richiede modifiche particolari (formato, stili, pagine di testa e di coda, indici, qualche pagina da sostituire eccetera) per cui c’è voluto un po’ di lavoro. Ho anche preferito scrivere il programma che produce la versione ePub invece che usare uno dei vari tool liberamente disponibili, perché non ne ho trovati che rispettassero interamente lo standard e fossero capaci di trattare correttamente un libro complesso come questo.

Per la versione iOS le pagine sono compattate in un unico file indicizzato, con l’aggiunta di un paio di file ausiliari per trasferire le necessarie informazioni (ad esempio per l’indice, in cui appaiono automaticamente certe pagine chiave man mano le si visita) e il tutto è accessibile al Mac via rete locale. Il resto, dal lato iOS, è un normale programma Objective-C con una parte in JavaScript per la visualizzazione; per la verità all’inizio c’era molto più JavaScript, ma alcuni problemi delle librerie mi hanno costretto a cambiare strada. Inoltre i primi tester hanno (giustamente) stroncato la mia prima versione di interfaccia, per cui anche quella è stata progettata e programmata due volte. Per semplificare il lavoro ho scritto poi vari programmini ausiliari… insomma, ho avuto di che passare il tempo. :)

(5-continua. Ivan Rachieli e Enrico Colombini raccontano di paralleli tra ebook e videogiochi, tendenze verso la personalizzazione dei libri), differenze tra intrattenimento letterario e ludico e differenze di interattività tra gioco e libro).

Se si ha a che fare con sistemi con una gestione password dignitosa, è necessario effettuare tanti tentativi. Così facendo si genera un fastidioso rumore e molti sistemi sono configurati per bloccare automaticamente i tentativi di accesso su un certo protocollo quando si fallisca l’autenticazione più di un certo numero di volte, in un certo intervallo di tempo e da un certo indirizzo. Si tratta di una correlazione di eventi piuttosto semplice ed efficace ottenibile in diversi modi (magari usando un software specifico sul server bersaglio che dialoghi con il firewall, oppure attraverso un IPS, Intrusion Prevention System).

Che cosa può fare chi voglia comunque tentare un attacco di forza bruta senza far scattare i meccanismi che riconoscano l’attacco? Per esempio creare Hail Mary Cloud, una botnet così sintetizzata da Peter N. M. Hansteen, That Grumpy BSD Guy:

The most remarkable of these botnets is the one that tries to avoid detection by distributing the password guessing for any target across a large number of hosts, so each guesser never shows high enough rates of activity to trigger any of the traditional bruteforce detection mechanism.

Se sul vostro sistema Linux non consentite all’utente root di connettersi via ssh, utilizzate una porta diversa da quella standard e magari disabilitate l’autenticazione interattiva preferendo quella per chiave pubblica, un simile attacco non ha alcuna chance (come molti altri!). Se proprio non potete fare a meno dell’autenticazione interattiva (user/password) e della porta standard, almeno non permettete a root di accedere, utilizzate password non presenti nei dizionari utilizzati per gli attacchi di questo genere e sappiate che il tempo gioca a vostro favore: visti i tempi necessari per completare l’attacco vi accorgerete delle anomalie abbastanza in fretta.

Nella sopravvivenza nel tempo di questa botnet c’è un perseverare molto umano verso il perfezionamento di una tecnica destinata a fallire miseramente nella maggior parte dei casi. Un simile sforzo di coordinamento e manutenzione meriterebbe ben altro (e possibilmente qualcosa di lecito!).

HTML, neanche OpenDocument. È aperto e sganciato da software particolare; il sovraccarico della marcatura è minimo rispetto al testo; le possibilità espressive e descrittive sono invece illimitate; permette semplicità e indipendenza dall’aspetto della pagina così come la creazione di documenti sofisticati. La ricetta è semplice:

HTML and CSS are the fundamental technologies for building Web pages: HTML (html and xhtml) for structure, CSS for style and layout, including WebFonts. Find resources for good Web page design as well as helpful tools.

Avrei potuto scrivere quanto sopra rispetto al corpus letterario di uno scrittore moderno. Gli ebook stanno per affacciarsi sul mercato più ampio: scrivo mentre in prima serata nazionale passa la promozione di un libro disponibile esclusivamente in formato digitale.

Saremo invasi da legioni di libri autoprodotti (niente di male) realizzati con strumenti di massa riconosciuti automaticamente da Amazon o iBookstore.

Strumenti nessuno dei quali permette veramente la creazione di un ePub con la precisione e la qualità tipografica consentite da un uso accorto delle specifiche, di HTML, di CSS.

Un appello agli autori (e agli editori). Siate snob. Gli ebook non gratificano il tatto come la carta, né l’odorato come l’inchiostro. Ma possono gratificare la vista come nessuna orrenda paginata in Arial e Times New Roman farà mai. Imparate HTML. Imparate CSS. Distinguetevi.