18 Mar 2014
Nelle ultime ventiquattro ore, niente avrebbe potuto stupirmi più della dichiarazione recente di Mark Shuttleworth (il papà di Ubuntu, per capirci) secondo cui ACPI è il male supremo e non solo: permettere ad una tale tecnologia di venire utilizzata nell’era del software open source (per come la protodefinisce lui) sarebbe un fallimento nostro nel tentativo di smarcarci dai blob proprietari.
In sostanza la sua idea di portare l’innovazione e il codice che la rappresenta direttamente all’interno del kernel Linux, upstream, è ottima, e non la discuto. Un po’di debunking sul suo pensiero però farebbe bene. Mentre lui si proclama paladino dell’open software e in buona sostanza dell’open hardware, gli Ubuntu Phone vengono pianificati dai vendor con un’interfaccia molto simile ad ACPI, dove il kernel è Linux ed è grossomodo upstream, ma i blob proprietari utilizzati sono moltissimi.
We DO live in an era where any firmware code running on your phone, tablet, PC, TV, wifi router, washing machine, server, or the server running the cloud your SAAS app is running on, is a threat vector against you.
È vero Mark. Hai piuttosto ragione. Mister “Io sono stato sull’Enterprise e voi no” Shuttleworth continua il suo ragionamento in maniera sensata:
If you read the catalogue of spy tools and digital weaponry provided to us by Edward Snowden, you’ll see that firmware on your device is the NSA’s best friend. Your biggest mistake might be to assume that the NSA is the only institution abusing this position of trust – in fact, it’s reasonable to assume that all firmware is a cesspool of insecurity courtesy of incompetence of the worst degree from manufacturers, and competence of the highest degree from a very wide range of such agencies.
Per estensione, grossomodo, data l’invisibilità del codice sorgente di un software lato server, possiamo desumere che sia legittimo catalogare in questo modo tutto il software proprietario: in mancanza di prove, al posto della presunzione d’innocenza introduci lo scenario nel caso peggiore, in modo da prevedere le conseguenze più brutte rispetto ad un’azione specifica. Bene, tutto giusto.
Se. Se. Se non fosse che Mark “Er Mitico” Shuttleworth ha uno scheletro nell’armadio grosso così, perché installando Ubuntu poi compare questo.
Ora, non sta a me definire come il patron di Ubuntu dovrebbe comportarsi, anzi, è bene che dica cose del genere perché sicuramente mi riconosco più in queste frasi che nel comportamento fattivo della sua azienda. Copio da Wikipedia le informazioni che ho su Ubuntu One, che credo siano corrette:
Licenza: il software lato server è proprietario - il software lato client è in GPLv3.
Per carità, tutto bello e tutto figo, Ubuntu One tra l’altro funziona anche bene. Ma le cose sono due. O predichiamo bene e razzoliamo bene, oppure se il software proprietario lo equipariamo ad un malware, allora Ubuntu effettivamente include dei malware, esattamente come professa FSF. Esagero? È probabile. Sono nel torto? Può essere. Ma il fondatore di una compagnia il cui core business è la fornitura di servizi attraverso (anche) uno dei pilastri fondato su software proprietario (ovvero Ubuntu One server-side), non può permettersi di dire certe cose senza far seguire alle parole un gesto concreto.
Mi aspetto la release del server di Ubuntu One sotto GPL molto presto.
Photo courtesy of Esther Dyson
Poscritto
Riccardo Padovani, che mi osserva silente ma quando faccio un errore mi bastona subito (e fa bene!), mi fa notare che quello che ho scritto sugli Ubuntu Phone è senza fonte. È vero. Tuttavia, dato che sinora il mercato degli smartphone non ha trattato la questione open driver in maniera "frontale", ho sfornato quella che a tutti gli effetti è una congettura basandomi sul fatto che i primi dispositivi di test per Ubuntu Touch sono stati i Nexus, che necessitano di blob proprietari nemmeno indiferenti; quindi immagino che anche i Meizu con Ubuntu, più o meno, saranno fatti della stessa pasta.
11 Mar 2014
Proprio in questi giorni, uscito dalla sessione d’esame (e rivista quindi la luce del sole) ho deciso di dare una chance a Telegram, sia dal punto di vista della tecnologia pura (quindi esaminarlo abbastanza nel dettaglio lato server) che dal punto di vista dell’utilizzo quotidiano come sostituto potenziale di Whatsapp all’interno del mio flusso di comunicazioni.
Nonostante di solito io sia un tipo che sa abbastanza cosa vuole e cosa aspettarsi, pur trovandolo sostanzialmente un surrogato per ora non totalmente pronto a sostituire uno strumento come Whatsapp (o altri, se ne usate - ma per me sono anche peggio, quindi lasciamo stare), ho toccato con mano alcune novità che hanno un potenziale enorme dal punto di vista della user experience, e che effettivamente me lo hanno fatto apprezzare parecchio, soprattutto dal punto di vista (diciamo pure) lavorativo.
Di seguito quindi, tre motivi identificati da me per cui Telegram non è attualmente una soluzione alle criticità di cui soffre Whatsapp, ma non solo: anche tre ragioni per farvelo stare, ugualmente, molto simpatico come secondo classificato.
Reinventare la ruota non è bello
Viviamo in un ecosistema fatto di tecnologie aperte, oltre che di imprenditori che sanno vendere la propria creatura a un colosso per svariati miliardi di dollari (di cui un bel po’ in stock option); per questo motivo, risulta antipatico creare un proprio protocollo che non sia basato su XMPP per la comunicazione e RSA/OTR per la crittografia, dato che sono tecnologie da sempre presenti nella storia dell’informatica, e sostanzialmente rock-solid dal punto di vista della sicurezza.
Telegram invece si basa su un protocollo proprio, che per quanto ben descritto in molteplici paper e sulla pagina ufficiale (nonché messo in pratica attraverso il codice dei client che possiamo esaminare), è comunque una cosa nuova da studiare da capo, completamente. Mtproto è molto carino come concezione, ma il team avrebbe potuto risparmiare parecchio tempo non creando tutto questo, e partendo invece da quelli che sono dei golden standard. In questo modo invece abbiamo una creatura che per quanto carina, all’interno dei protocolli di comunicazione è in ogni caso un nuovo player che ha da mostrare tutte le sue carte, e da giocarle anche con cura.
È sicuro, ma non troppo
Telegram è più sicuro. Ok, abbiamo capito. Ma questo atteggiamento irritante degli sviluppatori di Mtproto, e di chi consiglia Telegram a sua volta, si scontra con un altro atteggiamento abbastanza deplorevole, e cioè quello di chi, nel frattempo, ne ha scoperto delle gravi falle a livello di protocollo crittografico.
Geoffroy Couprie, sviluppatore per VLC e consulente per la sicurezza informatica, ha scritto l’interessantissimo Telegram, AKA “Stand back, we have Math PhDs!”, dove ha messo alla berlina un po’ di corbellerie insite all’interno di Mtproto (ossia il protocollo usato da Telegram), come ad esempio una falla abbastanza grave nella chat criptata end-to-end, in quanto lo scambio di chiavi Diffie-Hellman viene coadiuvato dal server con un’operazione per cui (facendola breve) ci si espone ad un attacco Man In The Middle - il che significa sostanzialmente che se sono abbastanza furbo da fingermi un tuo server, riesco non solo a intercettare i tuoi messaggi, ma a decriptarli senza problemi.
Vogliamo continuare? Nah, piuttosto, leggetevi anche il thread di commenti sottostante in cui gli sviluppatori di Telegram accusano Couprie di aver scritto inesattezze - cosa in parte vera e rettificata nell’articolo, ma non totalmente: altri dettagli (come quello sovrastante) sono ancora in attesa di una smentita.
Si ma… mia nonna lo usa?
Siamo in tanti ad aver installato Telegram; parecchie persone che lo usano ne incoraggiano l’adozione tra quelli che conosco, e parecchi scettici sempre nella mia cerchia gli hanno dato una chance, alcuni con successo, altri meno. Nonostante questo, però, la curva d’adozione è sempre piuttosto bassa, dato che i numeri di Whatsapp sono stati raggiunti non con un’esplosione singola, ma con una serie di boom progressivi che gli hanno permesso di diventare praticamente la piattaforma leader nel settore del messaging nel mondo.
Certo, le recenti adozioni di massa di Telegram possono avere un piccolo peso per Whatsapp, ma chi ha grosse cerchie di amici ancora fortemente legate al messenger (ormai) di Facebook non sarà così facile da smuovere: le masse si muovono solo con numeri ingenti, e sinora il punto di adozione ingente sembra per Telegram un’oasi alla fine di un lunghissimo tracciato da percorrere in un deserto costellato di ostacoli, tra cui Line con la sua interfaccia bellina, e WeChat che in Cina fa numeri da paura.
Chiaramente quindi, chi non è interessato alla nicchia (a meno che tutti i propri amici non abbiano già fatto il salto) lascerà Telegram al palo.
È open source (almeno, in parte)
Almeno, un pezzo di Telegram è open source. Ed è pure una parte consistente: anche se il server è ancora proprietario per motivi piuttosto loschi (e probabilmente i russi si stanno babbando tutti i nostri numeri di telefono per poi farci chiamare uno ad uno dai Testimoni di Putin), il protocollo è aperto, sviscerabile, e completamente comprensibile, tant’è che infatti le falle di sicurezza presenti sono state rese evidenti da svariati ricercatori che si sono interessati al tema in maniera immediata.
Stessa cosa dicasi con le API, che, ben documentate e altrettanto ben sviluppate, hanno permesso non solo la creazione di un buon client che, reso open source, può essere utilizzato anche a livello accademico per la comprensione di come un’applicazione comunica con il proprio server (in maniera cifrata, oltre tutto), e può chiaramente essere migliorato da una comunità piuttosto attiva. Se infatti l’applicazione per iOS è stata creata dallo stesso team di sviluppo, già il client Android segue dinamiche diverse, dato che la prima versione (immagino come le successive) è stata frutto di un contest, vinto da due programmatori proprio con il client che noi utilizziamo sul sistema operativo di Google.
La open API ha fornito anche l’appiglio per la proliferazione di client per altre piattaforme, approccio che non si ferma solo al mobile: abbiamo infatti anche un client per la riga di comando (compatibile con Linux e OS X), ma anche Telegram per Mac e Telegram per Windows. In mancanza di sforzi “ufficiali”, oltre tutto, anche Windows Phone ha beneficiato di una API con un tale grado di apertura (ormai obbligatorio per questioni di engagement, secondo me), dato che la community anche in quel caso ha colmato la lacuna con dei client completamente “homemade”.
Dobbiamo aspettarci un server open source di Telegram ben presto. Nonostante di solito io creda poco a queste affermazioni, forse in questo caso l’inizio è talmente buono che il progetto si merita un po’ di fiducia durante un periodo di staging proprietario che giocoforza è causato da questioni di fruibilità del codice. E quello che possiamo attendere come passo successivo, è che i client di Telegram/MTproto ci permettano effettivamente di specificare se connetterci a un server ufficiale, o ad un server che abbiamo messo in piedi noi stessi. Perché no? In fondo un servizio decentralizzato di messaggistica mobile sarebbe veramente innovativo.
Altro che balle varie correlate.
Meglio di niente
Whatsapp, si sa, è veramente pessimo sia come implementazione (un XMPP modificato in maniera abbastanza promiscua), che come sicurezza. Se infatti è vero che sono state segnalate delle falle ben chiare che mettono in pericolo la nostra privacy in maniera ingente, è anche vero che oltre questo i developer non hanno fatto gran che per proteggerci da occhi indiscreti, anzi: continuando a fatturare la compagnia si è completamente disinteressata di tutte quelle istigazioni ad attacchi man-in-the-middle, e probabilmente con Facebook al timone il comportamento sarà grossomodo lo stesso.
Telegram, invece, si trova un passo avanti da questo punto di vista: con un protocollo aperto mette in evidenza una sicurezza parecchio maggiore, oltretutto nonostante la presenza di problemi abbastanza rilevanti nell’algoritmo di crittografia, dovuti per lo più alla possibilità di attacchi MITM (anche in questo caso), l’atteggiamento degli sviluppatori sembra costruttivo e - tanto per tornare al punto di cui sopra - l’apertura dimostrata non tanto in fase di progettazione quanto di condivisione del lavoro svolto fa ben sperare, e sicuramente fa da grimaldello per chi cerca un’azienda fornitrice di servizi che ha a cuore in maniera maggiore la sicurezza di uno scambio di informazioni.
È una tecnologia migliore
Quella introdotta da Telegram è inevitabilmente una tecnologia migliore, perché si sposa meglio con i bisogni dettati da un mercato che è stato completamente rivoluzionato, nel bene e nel male, da una certa attenzione per l’aspetto della sicurezza. Anche se non ancora completamente aperta, sulla carta la tecnologia utilizzata da Telegram è decisamente migliore di quella alla quale ci dà accesso Whatsapp. Una persona un po’ attenta a questo tipo di caratteristiche per cui dovrebbe sicuramente considerare uno switch, a meno di non prendere in considerazione anche altri fattori di cui sopra.
Non credo ci sia molto da dire. Uso Telegram da un paio di settimane, affiancato a Whatsapp come messenger principale sul mio smartphone Android e sulle mie macchine. Certamente c’è da lavorarci su. Tuttavia, l’approccio al servizio mi pare interessante, per quanto approssimativo come business plan (chi paga? Pantalone?); c’è solo da aspettare, sicuramente il team si merita un po’ di supporto e parecchi feedback.
21 Feb 2014
Oggi ho letto questo interessantissimo post di Dave Winer che espone un notevolissimo punto di vista per quello che riguarda Bootstrap, il framework per frontend development/design distribuito tramite GitHub (open source) da Twitter.
The idea of Bootstrap, as I see it, is to add a layer of standardization between the app developer and the "hardware," in this case, the user interface offered by the modern HTML 5 web browser. When you view it this way, there's nothing controversial about it. It's what engineers always do. When we see complicated chaos, we try to figure out what's really going on, and produce a simplified and rational view of it. Then all the code that rides on top of the new layer can also be rational and relatively simple.
Sostanzialmente Winer espone una tesi: con Bootstrap si sono venute a creare delle inconsapevoli HIG (Human Interface Guidelines), dato che l'utente riconosce un'applicazione creata con questo toolkit e ne identifica un certo design pattern che lo porta a cercare i menù e gli elementi familiari sempre negli stessi posti, un po' come funziona per le interfacce grafiche dei computer.
Questo viene stimolato in un certo senso dalla replicazione degli stessi elementi grafici (ad esempio l'aspetto dei bottoni) tra un sito e un altro. In poche parole, Bootstrap è diventato il GTK, il Cocoa del web: un toolkit con cui costruire interfacce, il più popolare, e probabilmente ciò che ha iniziato a definire un livello successivo (come dice anche il post originale) di come è possibile continuare la catena del software nel web.
Photo courtesy of Michael Imbeault
29 Jan 2014
Di recente sulla mia workstation con Fedora ho cominciato a pastrugnare con il package management in maniera indiscriminata, così invece di far fare tutto a Yum che mi dava qualche piccola incongruenza, per installare un pacchetto mi sono avvalso di RPM puro, cosa che ormai a quanto vedo non dovrebbe essere mai fatta, demandando a yum localinstall il compito di installare pacchetti singoli.
Fatto sta, che ho avuto un feedback "strano" dalla mia macchina provando a usare direttamente RPM: ha cominciato a rompermi le scatole ad ogni operazione di gestione dei pacchetti avvisandomi che il database di RPM era stato modificato senza che Yum lo avesse autorizzato.
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.
Al di là di ogni presa di coscienza del fatto, e procurato allarme (ok, ho scardinato RPM, ho capito), può essere utile rimettere in marcia il nostro sistema senza che mostri più quel feedback che, con tutto il rispetto, ma mi ha fatto prendere un accidente. Mi sono guardato un po' intorno e ho notato che basta dare un singolo comando per liberarsi di questo peso sulla coscienza:
$ sudo yum clean all
Occultamento di cadavere? Forse si. Ma se la macchina la amministriamo noi, chi se ne importa. Buon lavoro :-)
Photo courtesy of Kaleb Fulgham
