App on Melabit

La falsa sicurezza delle app VPN per Android (e non solo)

Wed, 22 May 2019 06:00:00 +0000

Fino a pochi anni fa le reti private virtuali (VPN, Virtual Private Network) erano un prodotto di nicchia, riservato prevalentemente a chi era spesso fuori dall’ufficio per lavoro e aveva bisogno di connettersi in modo sicuro alla rete aziendale dal bar o dall’hotel di turno, oppure a chi viveva in paesi a rischio censura e voleva esprimere il suo pensiero senza poter essere rintracciato o più semplicemente desiderava accedere liberamente ai siti web oscurati dal proprio governo.

Poi, proprio all’inizio dell’amministrazione Trump, il Congresso degli Stati Uniti ha deciso di consentire ai fornitori di servizi di accesso alla rete (ISP, Internet Service Provider), gli equivalenti dei nostri Fastweb, Infostrada o Vodafone, di rivendere a chiunque e senza dover richiedere alcuna autorizzazione, i dati di navigazione dei propri utenti. Un business che vale 80 miliardi di dollari di sola pubblicità online.

In questi dati c’è di tutto, fra cui moltissime informazioni strettamente private: la storia della navigazione su internet con l’elenco di tutti i siti visitati, le ricerche effettuate, il contenuto delle email, informazioni mediche e finanziarie, indirizzi, date di nascita, numeri di telefono, e persino i dettagli della posizione geografica dell’utente nel corso della giornata. Di conseguenza l’uso delle VPN è letteralmente esploso.

Purtroppo non è affatto detto che una rete VPN aumenti la sicurezza delle proprie comunicazioni online. Anzi può essere persino peggio, una VPN può dare un falso senso di sicurezza che invita ad abbassare la guardia, con conseguenze potenzialmente catastrofiche (in particolare per coloro che hanno la sfortuna di vivere in paesi governati dal dittatorello di turno).

Lo dimostra una ricerca pubblicata nel 2016, immediatamente prima della deregolamentazione decisa dal Congresso USA. Per motivi pratici la ricerca è focalizzata sulle sole app VPN (gratuite) per Android e trascura completamente il mondo iOS e tutte le applicazioni analoghe per i sistemi operativi desktop, Windows e macOS e Linux. Ma pur con tutti i suoi limiti, i risultati della ricerca danno un quadro piuttosto chiaro di quanto sia critica la situazione in questo settore, e allargando ulteriormente il campo di analisi la situazione non potrebbe che peggiorare.

Qui sotto ho riassunto brevemente i risultati della ricerca, nel corso della quale i ricercatori hanno analizzato ben 283 app VPN disponibili gratuitamente sul Play Store di Google all’inizio dell’analisi (settembre 2015). Chi desidera approfondire può scaricare liberamente dai siti istituzionali degli autori sia l’articolo completo che le slide della conferenza nella quale è stato presentato il lavoro.

Bisogna notare che, anche se tutte le app analizzate sono gratuite, più della metà richiede il pagamento di un importo mensile per l’uso effettivo della rete VPN, una cosa assolutamente normale visti i costi associati alla gestione di una infrastruttura di rete.

Reti peer-to-peer: un gran numero di app VPN non utilizza una infrastruttura di rete costruita ad hoc ma si basa sui nodi di accesso messi a disposizione dagli altri utenti (spesso in cambio di sconti), formando quindi una rete peer-to-peer molto più economica da gestire ma che non garantisce assolutamente la trasparenza e la sicurezza necessarie.

Modello gratuito: mettere su una rete VPN ha dei costi significativi e quindi in questo caso specifico il modello free non può funzionare; per poter proporre delle VPN gratuite o a basso costo le aziende utilizzano spesso una serie di trucchi poco accettabili, con i quali portano gli utenti inconsapevoli sui siti dei partner pubblicitari oppure utilizzano codice JavaScript più o meno oscuro per iniettare gli annunci pubblicitari direttamente nel flusso dei dati. La pubblicità in sé può anche essere innocua, ma mettere le mani nel flusso dei dati trasmessi sulla connessione VPN può portare ad abusi molto più seri e pericolosi per chi utilizza la rete in questione.

Malware: più di un terzo delle app VPN era infestato da qualche forma di malware: non solo il quasi inoffensivo adware (pubblicità non richiesta) ma spesso anche da veri e propri spyware (programmi che spiano l’attività online dell’utente) o trojan (programmi installati di nascosto che possono eseguire operazioni dannose sul sistema).

Crittografia: non è affatto detto che il traffico di rete che transita attraverso queste app VPN sia crittografato e quindi risulti illeggibile agli ISP o alle agenzie governative un po’ troppo curiose; e anche quando lo è, può succedere che errori di implementazione o di configurazione delle app mostrino in chiaro gli accessi ai server DNS (quelli che traducono i nomi dei siti web negli indirizzi numerici comprensibili ai computer), rivelando così l’attività effettuata in rete dagli utenti, una cosa che in certi paesi può essere più che sufficiente per finire in carcere.

Certificati: alcune app VPN riescono perfino ad installare i propri certificati digitali al posto di quelli ufficiali del dispositivo Android (certificati root), rendendo del tutto inefficace la cifratura dei dati in transito sul dispositivo, perché chi dispone del certificato digitale dispone anche delle chiavi con cui decodificare tutto quello che passa attraverso la rete VPN.

Consapevolezza del rischio: solo l'1% delle recensioni sul Play Store solleva dei dubbi sull’attività potenzialmente fraudolenta svolta dalle app VPN; l’utente medio di questi prodotti non ha le capacità tecniche per accorgersi dei rischi che corre quando usa un’app di questo tipo e purtroppo il sistema operativo sottostante fa ben poco per aiutarlo.

Insomma, nonostante i limiti già ricordati, questa ricerca dimostra in modo inoppugnabile che le app VPN per Android (ma non solo) danno solo un falso senso di sicurezza, che le rende inutili e perfino controproducenti. Dubito fortemente che si otterrebbero risultati diversi analizzando le app analoghe per gli altri sistemi operativi mobili o desktop. E dubito altrettanto fortemente (se non di più) che dal 2016 ad oggi la situazione sia migliorata.

Perché?

Primo, perché tutti i sistemi operativi attuali fanno pochissimo per aiutare l’utente a valutare correttamente i rischi connessi a certe attività di rete. Far comparire di continuo avvisi e richieste di autorizzazione di tutti i tipi non è sufficiente, se non si spiega in modo corretto e comprensibile quello che succede. E in ogni caso, troppe richieste inutili non fanno altro che affogare ciò che è veramente importante in un rumore di fondo indistinto, da cui l’utente medio esce cliccando automaticamente, senza nemmeno leggere. Facile quindi infilare delle app più o meno malevole negli store online dei vari sistemi operativi, in particolare di quelli più diffusi, Android per il mobile e Windows per il desktop. Apple per fortuna riesce a controllare meglio di altri gli store di macOS e di iOS, ma possiamo essere sicuri che ci riesca al 100%?

Secondo, perché in questo campo il modello free non funziona a priori. Gestire una infrastruttura di una rete ha dei costi che devono essere ripagati in qualche modo, lecito (attraverso gli acquisti in-app e gli abbonamenti mensili) o illecito. E comunque non è nemmeno detto che una rete VPN a pagamento (anche di costo rilevante) assicuri un livello di sicurezza decente. Poter spiare una connessione considerata sicura può assicurare tanti di quei benefici, sia a livello economico (ad esempio, conoscere le attività e i progetti di certe aziende) che politico (primo fra tutti riuscire a individuare gli oppositori politici), che è meglio non fidarsi.

Che fare?

Come installare le vecchie versioni delle app su iOS - Seconda parte: quando le app non le abbiamo già acquistate

Thu, 09 May 2019 06:00:00 +0000

L’articolo precedente si concludeva con la domanda: è possibile installare la versione compatibile con il nostro dispositivo iOS di una qualunque app dell’App Store, e non solo di quelle che abbiamo già acquistato in passato?

In teoria non è possibile, in pratica ci sono alcuni modi semplici e perfettamente legali per risolvere il problema.

Naturalmente i metodi descritti qui funzionano con le app che, diciamo così, hanno una storia, cioè sono state rilasciate in passato almeno per la release di iOS che usiamo sul nostro dispositivo, non per le nuove app sviluppate solo per iOS 11 e 12.

A parte il primo, tutti i metodi descritti si basano sul fatto di poter installare su macOS una versione di iTunes precedente alla famigerata (almeno per i nostri scopi) versione 12.7 di settembre 2017, a partire dalla quale Apple ha rimosso da iTunes il supporto all’App Store di iOS, cioè la possibilità di acquistare e scaricare le applicazioni per iOS direttamente da iTunes. Come sempre, ogni volta che nel seguito mi riferirò all’iPad, sarà sottinteso che quanto detto vale anche per l’iPhone e l’iPod Touch.

Metodo #1. Questo metodo presuppone di avere a disposizione un dispositivo recente su cui gira iOS 11 o meglio ancora iOS 12, sul quale installare l’ultima versione disponibile dell’app che ci interessa. Fatto questo, l’app diventa nostra e compare nella lista delle app acquistate di tutti i nostri dispositivi iOS, fra cui l’iPad d’antan che ci ostiniamo ad usare.¹

Se ora apriamo l’App Store sull’iPad, ci basterà cliccare sull’icona della nuvola associata all’app in questione per far comparire la solita richiesta di installare la versione compatibile con il dispositivo che stiamo usando. Una volta accettata la richiesta, inizierà immediatamente l’installazione dell’app desiderata.

Metodo #2. Se abbiamo da qualche parte un vecchio Mac che prende polvere, possiamo usarlo per installare una versione relativamente recente di macOS che non contenga iTunes 12.7, magari El Capitan che, fra le versioni di macOS degli ultimi anni, è in assoluto la versione che preferisco (chi non ce l’ha, può scaricare El Capitan seguendo queste istruzioni). Se la macchina è davvero molto vecchia, una ottima alternativa può essere Mountain Lion.

Se per qualche ragione non possiamo usare il vecchio Mac per scaricare la release di macOS desiderata e non disponiamo di una chiavetta USB (o eventualmente di un DVD) di installazione, possiamo sempre reinstallare macOS sfruttando la funzione macOS Recovery, con la quale si può ripristinare la versione più recente di macOS già installata su quel Mac, oppure l’ultima versione compatibile.

Una volta installato macOS, possiamo lanciare iTunes, configurarlo in modo da mostrare l’App Store (per i dettagli, si vedano le immagini nella sezione relativa al metodo #4) e acquistare dall’App Store l’app che ci interessa. Le vecchie versioni di iTunes, infatti, permettevano di acquistare e scaricare le app per iOS direttamente dall’interfaccia di iTunes; queste venivano installate in un secondo momento sincronizzando il proprio dispositivo iOS con iTunes e si poteva perfino decidere la schermata nella quale dovevano essere visualizzate. L’app acquistata tramite iTunes diventerà nostra a tutti gli effetti e basterà andare sull’App Store dell’iPad e seguire le istruzioni del metodo precedente per installarla sul nostro dispositivo.

Metodo #3. In teoria si potrebbe downgradare iTunes alla versione 12.6 sul Mac che usiamo ogni giorno, ripristinando così l’accesso all’App Store tramite iTunes già descritto nel metodo #2.

In pratica, il processo di downgrade di iTunes può portare tanti di quei problemi che è meglio non rischiare ed usare invece una macchina virtuale, come descritto nel metodo successivo. Evito di proposito di inserire dei link agli articoli che spiegano come eseguire il downgrade di iTunes, chi decidesse lo stesso di farlo è avvertito.

Metodo #4. Quest’ultimo metodo è il più complicato ma anche il più interessante, perché non richiede di avere a disposizione un vecchio Mac oppure un dispositivo iOS recente su cui giri iOS 12 (o almeno 11).

In questo caso dobbiamo utilizzare un emulatore come VMWare Fusion o Parallels Desktop (commerciali) oppure l’ottimo Virtual Box (open source). L’emulatore verrà usato per creare una macchina virtuale nella quale installare una vecchia versione di macOS che contenga una versione di iTunes precedente alla versione 12.7 di settembre 2017 (a partire dalla quale, come ricordato all’inizio dell’articolo, non è più possibile gestire le app per iOS direttamente da iTunes).

Per fortuna, da qualche anno Apple consente di installare macOS in un emulatore a tutti coloro che hanno acquistato un Mac e dispongono della licenza per la release di macOS che installano nell’emulatore. Di conseguenza, per installare macOS in una macchina virtuale bisogna prima aver scaricato dall’App Store del Mac la release di macOS che vogliamo usare. Chi vuole rinfrescarsi la memoria, può leggere qui come scaricare le release di macOS da El Capitan in poi, oppure come scaricare le release di macOS precedenti a El Capitan

Una volta installato macOS in una macchina virtuale, dobbiamo eseguire iTunes all’interno della macchina virtuale e collegarlo al nostro account sull’App Store esattamente come si fa su un Mac vero. È possibile che all’avvio iTunes ci chieda se vogliamo aggiornarlo ad una versione più recente. Naturalmente dobbiamo rispondere di no, magari cliccando prima sull’opzione Non chiedermelo più in modo da tacitarlo per un po'.

Per motivi che mi sono sempre sfuggiti, l’App Store di iOS non è attivo di default in iTunes. Per attivarlo bisogna lanciare iTunes, cliccare sul menu a comparsa visibile in alto a sinistra (quello con la scritta Musica), selezionare la voce Modifica menu... e infine attivare il segno di spunta accanto alla voce App.

Fatto questo possiamo accedere all’App Store di iOS tramite iTunes.

Se ora andiamo a guardare cosa contiene la nostra Libreria , noteremo che è completamente vuota. La Libreria di iTunes su macOS, infatti, mostra di default solo le app scaricate tramite quella copia di iTunes, non tutte quelle che abbiamo a disposizione (le istruzioni per sincronizzare le nostre app con la libreria di iTunes si trovano in Appendice).

Solo quando acquistiamo con iTunes una nuova app dall’App Store (oppure quando scarichiamo un’app che abbiamo già) questa comparirà nella Libreria locale di iTunes.

Come già ricordato più e più volte, l’app appena acquistata tramite iTunes diventa nostra a tutti gli effetti e la ritroveremo immediatamente nella lista delle app di tutti i nostri dispositivi iOS vecchi e nuovi. Basterà collegare l’iPad al Mac emulato tramite il cavo USB oppure seguire le istruzioni del metodo #1 per installarla sul nostro vecchio iPad.

Conclusioni

Quando ho pensato per la prima volta a questo articolo ero sicuro che sarebbe bastate una decina di righe per spiegare tutto. Poi mi sono fatto prendere la mano, mi sono venuti in mente altri dettagli e metodi a cui non avevo pensato in un primo momento e l’articolo si è esteso molto oltre le previsioni. Mi rendo conto che l’argomento possa sembrare piuttosto esoterico, ma vedo anche che tanti lettori di questo blog sono molto interessati ad estendere il più possibile la vita utile dei propri dispositivi Apple. Del resto, se Apple fa prodotti di qualità che funzionano perfettamente anche dopo parecchi anni (io ne so qualcosa), perché non approfittarne?

Appendice

Volendo (ma perché?), è possibile sincronizzare tutte le app che abbiano acquistato con la libreria di iTunes del sistema macOS emulato. Per farlo, bisogna cliccare sul link Acquistati situato nella barra laterale destra ed inserire i dati di login del nostro ID Apple.

A questo punto iTunes interrogherà i server di Apple e scaricherà l’elenco completo delle app che abbiamo acquistato nel corso del tempo dall’App Store. La sincronizzazione purtroppo è snervante e, quel che è peggio, non c’è nessuna indicazione che indichi chiaramente se sta succedendo qualcosa di significativo o se il sistema si è bloccato. Ma la pazienza alla fine paga: mentre osserviamo lo schermo preoccupati iTunes continua a lavorare dietro le quinte a alla fine riuscirà a far comparire la lista tanto desiderata. Per la mia lista di app ha impiegato almeno mezz’ora.

Si noti che non tutte le app per iOS sono universali, cioè funzionano indifferentemente sull’iPad, l’iPhone (e l’iPod Touch). Per tutte quelle per le quali esiste una versione specifica per il solo iPad o iPhone, dovremo per forza di cose avere a disposizione un dispositivo iOS 11 o 12 corrispondente. ↩︎

Come installare le vecchie versioni delle app su iOS

Thu, 02 May 2019 06:00:00 +0000

Il mio iPad 3 è ormai definitivamente bloccato su iOS 9, ma quasi tutte le app che uso continuano ad essere aggiornate e sempre più spesso le nuove versioni sono compatibili solo con le release più recenti di iOS.

Normalmente non ci sono problemi, se le app sono già installate sull’iPad iOS non le aggiorna più e tutto finisce qui. Ma cosa succede se abbiamo ripristinato l’iPad allo stato di fabbrica e vogliamo reinstallare le app che ci servono? (anche in questo articolo ogni riferimento all’iPad sottintende che le stesse considerazioni valgono anche per l’iPhone e l’iPod Touch).

Un’app è per sempre

Apple ha introdotto da qualche anno una funzione (utilissima!), che permette di installare su un vecchio dispositivo iOS l’ultima versione compatibile delle app acquistate, cioè delle app che abbiamo già scaricato dall’App Store. Infatti, ogni volta che scarichiamo un’app dall’App Store, acquisiamo una licenza perpetua per quell’app, per cui Apple la considera a tutti gli effetti come se fosse stata acquistata, anche quando l’app in effetti è gratuita.

Questo significa che se anni fa abbiamo installato sull’iPad l’app ABC, la cui ultima versione compatibile con iOS 9 è la 2.3.0, potrò ancora installare sul mio iPad quest’ultima versione anche se intanto lo sviluppatore ha continuato ad aggiornarla ed ora l’app è arrivata alla versione 4.5.3 e gira solo su iOS 11 e superiori.

Per reinstallare un’app basta aprire l’App Store sull’iPad, cliccare sulla scheda delle app Acquistate e cercare l’app che ci interessa, ad esempio Google Chrome (l’immagine qui sotto mostra ancora la vecchia interfaccia dell’App Store perché iOS 9 non supporta l’interfaccia pesantemente modificata, e anche molto meno usabile, introdotta da Apple nelle ultime release del suo sistema operativo mobile).

Le app che abbiamo già acquistato hanno accanto l’icona di una nuvola, per cui possono essere reinstallate nella versione corrente (se lo sviluppatore ha deciso di supportare anche le versioni meno recenti di iOS), oppure nell’ultima versione compatibile con il nostro iOS.

Tutto facile? Non proprio, perché in questo meccanismo apparentemente lineare c’è un piccolo intoppo. Partiamo dalla schermata mostrata qui sopra e proviamo a toccare l’icona di Google Chrome, oppure il nome dell’app.

Si apre una finestra sovrapposta a quella principale con la solita icona della nuvola, a confermare che l’app è stato già acquistata ed è disponibile nella nostra nuvola virtuale.

Ma se proviamo ad installare l’app toccando l’icona della nuvola, otteniamo un messaggio scoraggiante, “Google Chrome non è compatibile con questo iPad”, messaggio che non possiamo far altro che accettare toccando la scritta OK.

Torniamo indietro alla lista delle app, ma questa volta tocchiamo l’icona della nuvola accanto a Google Chrome.

Questa volta l’icona si trasformerà immediatamente nell’icona rotante, ad indicare che l’app è in fase di download.

Dopo poco comparirà la scritta che ci chiede se vogliamo installare l’ultima versione compatibile con il nostro iPad. Toccando Download potremo finalmente installare Google Chrome sul nostro dispositivo.

Naturalmente quanto detto vale in generale: ogni volta che proviamo ad installare una vecchia versione di un’app già acquistata, il successo o meno dell’operazione dipende da come procediamo. Sembra un baco piuttosto evidente dell’App Store.

Purtroppo dubito che Apple rilascerà un update di iOS 9 solo per correggere questo problema, per cui è bene sapere come procedere per riuscire ad installare ancora oggi le app che ci interessano su un vecchio dispositivo iOS.

E se l’app non ce l’ho?

E se l’app non l’abbiamo già acquistata? È possibile installare una versione compatibile con il nostro dispositivo di una app qualunque, e non solo di quelle che abbiamo già acquistato in passato? In teoria non è possibile, in pratica ci sono parecchi modi semplici e legali per risolvere il problema. Ma questo lo vedremo la prossima volta.

Come ripristinare un iPad che non si avvia

Mon, 29 Apr 2019 06:00:00 +0000

Prima o poi doveva succedere: il mio venerando iPad 3 all’improvviso ha smesso di funzionare.

In realtà c’erano già stati dei segnali premonitori, prima dei crash improvvisi e apparentemente casuali delle app poi, nelle ultime settimane, dei blocchi completi del sistema (freeze) che dopo qualche minuto si concludevano con il riavvio spontaneo dell’iPad. Avevo attribuito tutte questi malfunzionamenti all’età, l’iPad ha più di sei anni, è bloccato da tempo su iOS 9 mentre la maggior parte delle app installate continuano ad essere aggiornate e pesano sempre di più sul processore e sul resto dell’hardware.

Alla fine, durante uno dei soliti cicli di aggiornamento delle app, l’iPad ha gettato la spugna, si è spento all’improvviso e non è più riuscito ad avviarsi. Non che non ci provasse, ma tutto quello che riusciva a fare era mostrare per qualche secondo il logo con la mela morsicata, per poi spegnersi subito dopo.

I dispositivi mobili possono essere soggetti al boot loop, un ciclo apparentemente infinito di riavvii del sistema operativo seguiti dallo spegnimento improvviso e dal riavvio successivo (a me è successo qualche volta su Android), ma questo comportamento era più strano e meno frequente.

La modalità DFU

Quando un dispositivo iOS non riesce ad avviarsi o presenta il boot loop, la cosa migliore da fare è provare ad attivare la modalità DFU (Device Firmware Update), che permette di aggiornare o di ripristinare il firmware di un iPad o di un iPhone attraverso iTunes, bypassando i problemi che impediscono l’avvio del dispositivo (nel seguito, ogni volta che mi riferirò all’iPad sarà sottinteso che le stesse considerazioni valgono anche per l’iPhone e l’iPod Touch).

In questa modalità, iTunes prende il controllo del dispositivo e prova ad reinstallare iOS senza cancellare le app e i file presenti nel sistema. Se non riesce a risolvere il malfunzionamento, iTunes passa alla soluzione più drastica, il ripristino completo del dispositivo al cosidetto “stato di fabbrica” (che poi non è un vero “stato di fabbrica”, dato che iOS viene comunque aggiornato all’ultima versione compatibile), che comporta la cancellazione totale di tutti i dati e le applicazioni presenti sul sistema.

È una soluzione estrema, non c’è dubbio, ma è sempre meglio che dover portare l’iPad in assistenza. Purtroppo, se dopo il ripristino totale del dispositivo l’iPad continua a non funzionare, è molto probabile che ci sia un problema di natura hardware e l’unica soluzione seria è rivolgersi all’assistenza tecnica Apple (ammesso che ne valga la pena).

Backup o no?

Se si leggono le guide che spiegano come attivare la DFU si trova quasi sempre la stessa avvertenza: prima di attivare la modalità DFU bisogna essere certi di aver fatto un backup recente dell’iPad, in modo da poter ripristinare facilmente il sistema dal backup. Grazie tante, peccato che questa indicazione sembri più uno scarico di responsabilità che ad una cosa veramente utile (non a caso il supporto tecnico Apple non ne fa menzione) e per due motivi:

se siamo costretti a mettere l’iPad in modalità DFU significa che il tablet ha problemi così gravi che è praticamente impossibile riuscire a fare prima un backup (come nel mio caso);
se un iPad va continuamente in crash o non riesce ad avviarsi perché il software di sistema o le app installate sono corrotte, il ripristino da un backup recente non farebbe altro che ripresentare immediatamente il problema.

In questi casi, secondo me, è preferibile ripartire veramente da zero, ripristinando il sistema operativo allo stato di fabbrica e reinstallando e riconfigurando ad una ad una tutte le app che ci interessano. È una cosa noiosissima, lo so, ma è anche il modo migliore per riavere un dispositivo efficiente e privo di problemi. Ed è anche una buona occasione per fare finalmente un po’ di pulizia, installando solo le app che usiamo veramente e lasciando fuori tutte quelle che teniamo sull’iPad solo perché non si sa mai.

Come attivare la modalità DFU

Attivare la modalità DFU su un iPad che dispone del tasto Home (il tasto circolare presente sul frontale) non è per niente difficile, basta eseguire questi quattro passi in sequenza:

chiudere iTunes sul Mac che vogliamo usare per il ripristino;
collegare l’iPad al Mac tramite il suo cavo Lightning o Dock (quello con il connettore a 30 pin che usa il mio iPad);
aspettare che iTunes si apra automaticamente, se non lo fa lanciarlo a mano;
sull’iPad, premere contemporaneamente il tasto Home e il tasto di accensione per diversi secondi.

Se tutto è andato bene, l’iPad si avvia, compare prima il logo della mela e poi una immagine che conferma il collegamento dell’iPad a iTunes (mostrata qui sotto). A questo punto è possibile rilasciare i due tasti. Se invece qualcosa è andato storto e l’iPad non è riuscito ad entrare in modalità DFU, bisogna solo armarsi di pazienza e riprovare dall’inizio.

Per i modelli più recenti di iPad e iPhone che non dispongono del tasto Home, la combinazione di tasti da premere è riportata in questo articolo. Tutto il resto rimane invariato.

A questo punto, iTunes ci avvertirà che l’iPad ha dei problemi e deve essere aggiornato, senza cancellare dati e applicazioni, oppure ripristinato da zero, cancellando tutto il contenuto precedente del tablet.

Naturalmente la prima cosa da fare è provare ad aggiornare l’iPad, sperando che iTunes riesca a ripristinare il funzionamento corretto.

Ma se la situazione è troppo grave per essere corretta con un semplice aggiornamento, sarà lo stesso iTunes a proporre di ripristinare il dispositivo allo stato di fabbrica.

Arrivati a questo punto non c’è altro da fare che accettare la proposta e andare magari a preparare un caffè o meglio (visti i tempi in gioco) un bel té. Infatti, se non l’ha già fatto prima, iTunes scaricherà l’ultima versione compatibile di iOS (il tempo di download dipende dal collegamento a internet oltre che dal carico dei server Apple, nel mio caso ci ha messo una buona mezz’ora) e la installerà sull’iPad, ripristinandolo allo stato di fabbrica. L’installazione vera e propria dura una decina di minuti e, una volta conclusa, richiede che l’iPad venga riconfigurato esattamente come se l’avessimo appena tirato fuori dalla scatola.

Per fortuna ormai la maggior parte dei dati, prima di tutto i contatti, il calendario, le foto e le email, possono essere ripristinati rapidamente da iCloud o dagli altri servizi di rete. Per il resto, ed in particolare per le app, bisogna armarsi di tanta pazienza e reinstallare tutto a mano. Poco male, se questo significa riuscire da soli a riavere un iPad perfettamente funzionante.

Imprevisti

Con questa procedura sono riuscito a riavere un iPad perfettamente funzionante e perfino più scattante di quanto fosse in precedenza. Infatti, dato che finora ho installato solo le app che uso davvero e che ci sono molti meno servizi che girano in background e aggiornano i dati delle app, il sistema è meno carico e di conseguenza fornisce prestazioni migliori (sempre tenendo conto dell’età dell’iPad).

Ma c’è un piccolo ma, collegato alla reinstallazione delle app su un iPad che non supporta le ultime versioni di iOS. Ma questo sarà l’argomento di un prossimo articolo.

Scrivere a mano sull'iPad

Fri, 11 May 2018 18:00:00 +0000

Scrivere a mano mi piace. Sono un baby-boomer e per me usare carta e penna è naturale quanto usare lo smartphone per un adolescente di oggi.

Ma non c’è solo la carta, mi piace anche scrivere a mano sull’iPad. Con l’applicazione giusta si può usare il tablet come se fosse un vero e proprio foglio di carta, con il vantaggio di poter correggere quello che si scrive o di poter trasformare la scrittura a mano in un testo modificabile.

Scrivere con le app

Di applicazioni (o come si usa dire per i dispositivi mobili, app) adatte a questo scopo ce ne sono parecchie – sul mio iPad ne ho installate anche troppe! – però alla fine mi ritrovo quasi sempre ad usare Notes Plus.

Di questa app mi piace moltissimo la possibilità di cancellare una parola tracciandoci sopra delle linee a zig zag, proprio come si fa su un foglio di carta, ma in questo caso la parola sparisce veramente dal foglio virtuale. Apprezzo anche che riesca a riconoscere abbastanza bene la mia scrittura, che in certi casi è così orrida che faccio fatica io stesso a capirla.

Ma quello che apprezzo di più in assoluto di Notes Plus è la sua area di zoom.

Scrivere direttamente sullo schermo dell’iPad come se fosse un foglio di carta è veramente scomodo, e produce un testo con caratteri così grandi da essere quasi illeggibili. Con l’Apple Pencil le cose sono di certo migliorate tantissimo, ma purtroppo non ho avuto ancora modo di averne una (aspetto il WWDC prima di fare nuovi acquisti) e quindi rimango a quella che è stata finora la mia esperienza diretta.

Nel corso degli anni gli sviluppatori hanno aggiunto alle app di scrittura sull’iPad delle funzioni che dovrebbero eliminare, o almeno attenuare, questo problema, escludendo i tocchi spuri della mano e del polso o proteggendo una parte dello schermo con una specie di tendina virtuale. Tutte cose che però risultano quasi sempre poco efficaci. La tendina virtuale in teoria è una buona idea, ma in pratica diventa una vera dannazione, perché costringe a continue interruzioni nel flusso di scrittura per spostarla sempre più in basso mentre si scrive.

Molto più efficace è invece l’area di zoom. Si tratta di una finestrella posta nella parte inferiore dello schermo (ma spesso posizionabile a piacere), che mostra una parte ingrandita dello schermo. Questa finestra permette di scrivere con i caratteri grandi che vengono naturali sull’iPad, che poi appaiono sul foglio virtuale della dimensione naturale a cui siamo abituati quando scriviamo su carta. Con un minimo di pratica si può trovare il rapporto di ingrandimento più adatto alla nostra scrittura.

Mentre scriviamo, la finestra di zoom si sposta automaticamente lungo la riga e riesce anche ad andare a capo da sola, rendendo il processo così fluido e naturale da non far rimpiangere troppo la carta. Altrettanto facile è passare dall’area di zoom al foglio intero, ad esempio per disegnare qualcosa o evidenziare una parte del testo.

Mi piacerebbe prima o poi riuscire ad analizzare in modo sistematico le funzioni delle diverse app di scrittura per iPad, ma per ora mi limito a notare che l’implementatazione dello zoom di Notes Plus mi sembra molto vicina alla perfezione (informatica).

La penna giusta

Ma un’app non basta, ci vuole anche la penna giusta. In teoria si potrebbe scrivere con il dito, ma è una cosa innaturale e parecchio stancante.

Steve Jobs aveva ragione a riteneva che il dito fosse il miglior dispositivo di puntamento, soprattutto in un tempo in cui il pennino era considerato un accessorio indipensabile di smartphone e computer palmari (ricordate i Palm o il Newton?).

Ma scrivere è una operazione ben diversa da puntare e selezionare una zona dello schermo, per scrivere in modo serio e continuativo ci vuole una penna.

Ma quale penna? Di penne per l’iPad (e per i tablet in generale) ce ne sono tantissime, di tipo attivo e passivo, con la punta spessa o sottile, in gomma o in plastica, economiche o costose. Quali sono le più adatte per scrivere a lungo sull’iPad? Qui non si tratta di scrivere qualche frasetta, per quelle il dito può essere sufficiente, ma di pagine e pagine di testo scritto a mano: appunti di lezioni (o di riunioni), note di lavoro, veri e propri documenti completi (come una parte di questo articolo).

La non-prova delle penne

Ho deciso quindi di provare alcune penne per l’iPad abbastanza diverse fra loro, cercando di verificare sperimentalmente quanto ciascuna di esse fosse adatta a lunghe sessioni di scrittura sull’iPad.

La scelta delle penne però non ha nulla di scientifico e non si basa su nessun criterio sistematico (penne attive, penne con diversi tipi di punta, etc.). Sono semplicemente le penne della mia piccola collezione personale, da cui la definizione di non-prova. Ho cercato comunque di eseguire ciascuna prova in condizioni controllate e ripetibili, concentrandomi in particolare sul peso, la comodità d’uso, la scorrevolezza, tutte cose che fanno la differenza quando si tratta di scegliere la penna più adatta alle proprie esigenze.

Ma prima di tutto qualche dettaglio tecnico.

Ho usato un iPad 3, un modello ormai datato ma ancora perfettamente funzionale, tenuto in posizione verticale (cioè con il lato corto dello schermo in basso) come se fosse un quaderno. L’app scelta è stata, come era facile immaginare, Notes Plus.

Prima di iniziare a scrivere ho aggiornato Notes Plus all’ultima versione disponibile e ho creato un nuovo quaderno con fogli a righe standard. I parametri scelti per la penna virtuale sono stati: spessore 2.0 e viscosità 0.50 (il valore di default). Per maggiore chiarezza, ogni volta che cambiavo la penna cambiavo anche il colore dell’inchiostro virtuale. L’intera sessione di scrittura è stata eseguita nell’area di zoom del programma (a parte una brevissima prova a schermo intero con l’unica penna attiva a disposizione).

Le penne utilizzate nel corso della non-prova sono state (Figura 1):

Bamboo Alpha, costata circa 10-15 euro;
Bamboo Fineline 2, pagata più o meno 50 euro;
Adonit Jot Pro, che suo tempo stava sui 50-60 euro;
Adonit Mini 3, ancora in vendita su Amazon a15 euro.

Tutte le penne sono mie, a parte l’Adonit Mini 3 che mi è stata inviata in prova da Sandra Tung di Adonit. La ringrazio sentitamente, sia per la penna che per la pazienza dimostrata nell’attesa di questa recensione.

Figura 1. Le penne utilizzate nel corso della prova.

Bamboo Alpha

La Bamboo Alpha è la tipica penna per tablet, del tipo con la punta grossa e morbida che ormai si può trovare ovunque a una decina di euro. Rispetto a queste cinesate, la Bamboo Alpha offre però una qualità di costruzione decisamente migliore.

Nel complesso la Bamboo Alpha non è male, è ben equilibrata e pesa più o meno quanto una penna vera. Purtroppo, dopo alcuni minuti di uso, l’attrito della punta con il vetro dello schermo inizia a farsi sentire e rende la scrittura piuttosto lenta e faticosa. Sembra di usare una biro, un tipo di penna che non sopporto. Io scrivo velocemente e quindi preferisco le penne a pigmenti o a gel (queste sono sorprendenti), che scorrono in modo ideale per i miei gusti e mi permettono di scrivere in fretta e senza ostacoli. Con la Bamboo Alpha mi sembra di avere il freno a mano tirato, le dita provano ad andare avanti ma la penna le frena senza pietà, e dopo un po’ la scrittura perde di piacevolezza e diventa faticosa.

Insomma, la Bamboo Alpha va benissimo per prendere dei brevi appunti, ma non la userei mai per scrivere a lungo, è troppo lenta e troppo stancante per i miei gusti.

Figura 2. Esempio di scrittura con la Bamboo Alpha.

Adonit Jot Pro

Come tutte le penne non “attive” di questa azienda, esplosa su Kickstarter qualche anno fa, l’Adonit Jot Pro ha una punta metallica molto fine a cui è fissato un disco di plastica trasparente di circa 1 cm di diametro. Questo tipo di punta permette di aumentare decisamente la precisione di puntamento, cosa fondamentale quando si disegna, ma che non fa certo male anche quando si scrive.

Ma la cosa che trovo più comoda di questa penna è la maggiore fluidità del dischetto di plastica, che rende la scrittura sullo schermo molto più vicina alla normale esperienza su carta.

L’unico difetto, se così lo possiamo considerare, dell’Adonit Jot Pro è il rumore chiaramente avvertibile che fa la punta quando tocca lo schermo di vetro dell’iPad. Ma è un piccolo prezzo da pagare per una esperienza d’uso più che soddisfacente. Meglio però non usarla di notte a letto mentre il/la partner dorme.

Figura 3. Esempio di scrittura con la Adonit Jot Pro.

Adonit Mini 3

Come ho gia detto, l’Adonit Mini 3 è l’unica penna che non ho comprato ma che mi è stata inviata da Sandra Tung di Adonit con lo scopo specifico di recensirla su questo blog. In effetti c’è poco da dire, la maggior parte delle cose scritte per la Jot Pro valgono anche per questo modello: la penna è fluida, il dischetto di plastica fa rumore quando tocca lo schermo, ma garantisce una precisione decisamente maggiore delle penne silenziose con la punta di gomma.

Dalla sua la Mini 3 ha il peso, ad occhio circa la metà della Jot Pro, e le dimensioni, che volendo permettono di metterla in tasca con il cellulare (cosa comunque sconsigliabile se non ci si vuole ritrovare con le tasche bucate). Inoltre, il corpo di forma triangolare fa si che la penna rimanga saldamente tra le dita e non rischi continuamente di cadere dalla scrivania, come succede a tutte le altre penne.

Se proprio vogliamo cercare il pelo nell’uovo, due piccoli difetti l’Adonit Mini 3 li ha. Il corpo della penna è un po’ troppo corto per chi ha le mani grandi, però forse si tratta più che altro di una questione di abitudine. Ma il difetto più grosso sta nel tappo a pressione. Se non si fa attenzione, quando si toglie il tappo è molto facile staccare il dischetto di plastica dal supporto di metallo. A me è successo un paio di volte, per fortuna sono riuscito a rimettere a posto il dischetto senza troppi problemi. Però il tappo a vite della Jot Pro mi sembra decisamente più pratico e affidabile.

Figura 4. Esempio di scrittura con la Adonit Mini 3.

Bamboo Fineline 2

L’ultima penna che ho provato è la Bamboo Fineline 2, l’unica penna attiva della mia collezione personale, pagata a suo tempo circa 50 euro. La penna si collega all’iPad tramite Bluetooth e, almeno in teoria, è la migliore penna a mia disposizione per scrivere sull’iPad.

Essendo attiva ha una punta piuttosto sottile, simile a quella di una penna “normale”, e dovrebbe permettere di scrivere direttamente sullo schermo, senza bisogno di usare l’area di zoom. Io ci ho provato, ma i risultati non mi sembrano entusiasmanti, come dimostra il tratto viola in Figura 5: nonostante mi sia impegnato, non sono riuscito a fare di meglio!

Figura 5. Bamboo Fineline 2: (verde) scrittura nella finestra di zoom, (viola) scrittura a pieno schermo.

Purtroppo quando si scrive con la Fineline 2 si avverte un costante ritardo fra la scrittura e la comparsa del tratto sullo schermo. Nell’area di zoom il ritardo è meno avvertibile, ma a pieno schermo diventa veramente fastidioso. Con il mio vecchio iPad 3 è una seccatura non da poco, che rende molto poco naturale l’esperienza di scrittura sullo schermo. Chissà se un iPad più recente può rendere più reattiva questa penna, io ho provato ad usarla con alcuni smartphone più recenti, sia Apple che con Android, e francamente non mi sembra di aver mai notato dei particolari miglioramenti nella velocità di reazione.

A questo si deve aggiungere un leggero sfasamento fra la punta della penna e la posizione dello schermo in cui compare il tratto. Una difetto noioso ma ancora veniale quando si scrive, che diventa però veramente fastidioso qaundo si prova a disegnare sullo schermo.

La Fineline 2 è anche piuttosto grossa e sembra più pesante di quanto sia veramente. Tutto sommato, più che con una penna, da l’impressione non molto gradevole di stare scrivendo con un grosso pennarello.

Figura 6. Esempio di scrittura con la Bamboo Fineline 2.

Conclusioni

Penso ci siano pochi dubbi. Le penne Adonit svettano su tutte le altre, con una leggera preferenza per la Pro, che trovo più equilibrata ed affidabile. La Bamboo Alpha ha dalla sua un ottimo rapporto qualità/prezzo, ma non è adatta a lunghe sessioni di scrittura. La vera delusione è la Fineline 2, una penna che più che “attiva” sembra nata stanca.

EyeAgnosis, diagnosi a distanza

Wed, 16 Aug 2017 18:00:00 +0000

Come vede una persona affetta da retinopatia diabetica. Fonte: National Eye Institute, National Institutes of Health.

Nella mia classifica personale la notizia tecnologica dell’estate è quella della ragazzina indiana sedicenne, Kavya Kopparapu, che ha inventato EyeAgnosis, una app per smartphone accoppiata ad un obiettivo stampato in 3D che consente di diagnosticare a distanza la retinopatia diabetica, una malattia che colpisce un terzo dei malati di diabete danneggiando i vasi sanguigni della retina e che è la principale causa di cecità negli adulti tra i 20 e i 65 anni.

Per Kavya la spinta iniziale per sviluppare il suo progetto è stato il nonno, affetto da retinopatia diabetica e rimasto in India dopo il trasferimento della nipote con i genitori negli Stati Uniti. Ma il problema del nonno si è trasformato in qualcosa di molto più grande e di più utile.

La storia completa la potete leggere qui e qui (in italiano), oppure qui e qui (in inglese), inutile che la ripeta anch’io. Ma ci sono due dettagli che mi hanno colpito più di tutto il resto.

La prima è il sistema scolastico. Lo so che il livello della scuola americana media non è un granché, perfino la nostra (sempre in media) è meglio (ma i nostri governanti si stanno impegnando a fondo per farla farla scendere sempre più giù), ma negli USA ci sono anche tante idee innovative e ci sono licei in cui è possibile studiare non solo informatica, ma argomenti avanzati come la visione artificiale, le reti neurali, l’apprendimento automatico (machine learning) o l’intelligenza artificiale. Saranno anche licei di élite, non lo nego, ma nei nostri licei di élite si insegna come farsi le amicizie giuste, non certo come far pensare un computer.

Dai licei e dalle università di élite americane escono quelli che mettono su Google, PayPal, YouTube, Twitter o Instagram, dalle nostre gente che mette su aziendine fallimentari che vivono solo con soldi pubblici.

La seconda cosa che mi ha colpito è che una ragazzina di sedici anni può scrivere o telefonare a professionisti, professori universitari o enti pubblici ricevendo simpatia, aiuto e risposte sensate. Da noi se avesse voluto fare lo stesso avrebbe fatto meglio ad essere la figlia di qualche altro professore o di un galoppino politico con qualche avviso di garanzia (o condanna) alle spalle, un titolo che ormai vale ben più di una laurea.

Chiedere informazioni ad altri enti pubblici… ma dai! Da noi gli enti pubblici negano dati persino banali – dati pubblici, pagati con i soldi di tutti – ad altri enti dello stato (come il CNR, tanto per fare un esempio a caso), figuriamoci cedere un database di immagini ad una ragazzina di buone speranze!

È proprio vero, uno come Steve Jobs non poteva nascere a Napoli, o se è per questo in qualunque altro posto in Italia.

Sandboxing in iOS: usciamo dal recinto

Thu, 22 May 2014 06:00:00 +0000

Esiste una soluzione semplice al problema del sandboxing delle applicazioni per iOS, che non impatti sulla sicurezza del sistema ma che allo stesso tempo permetta a più applicazioni di aprire e modificare un dato documento, evitando inutili duplicazioni e, quel che è peggio, di dover tenere traccia delle modifiche effettuate da ciascuna applicazione?

Soluzioni fattibili – più o meno semplici e più o meno affidabili o sicure – ce ne sono bizzeffe. Qui ne propongo una anch’io, che ha la caratteristica di sfruttare solo gli strumenti già esistenti in Unix e nei sistemi operativi derivati, fra cui anche iOS.

Sia chiaro che non voglio sostituirmi agli ingegneri e ai programmatori della Apple, che conoscono molto meglio di me il sistema su cui lavorano. Quello che voglio è solo dare un contributo di principio e di dimostrarne la fattibilità pratica.

L’eventuale (eventuale, non dimentichiamolo!) implementazione finale sarà di certo molto più brillante ed efficiente di questa.

Per evitare ambiguità userò nel seguito un linguaggio standard, evitando le definizioni tipiche del mondo Apple: directory al posto di cartella, file invece di documento, soft-link invece che link simbolico, e ogni volta che mi riferirò a Unix intenderò in effetti tutti sistemi operativi che derivano dalla base di Unix, come Linux, i vari BSD e ovviamente OS X e iOS.

Tutto è un file

Prima di proseguire il discorso bisogna ricordare alcuni concetti fondamentali sui file in Unix.

Tutto è un file in Unix. Questo è uno dei primi mantra che si imparano quando ci si accosta a questo sistema operativo. Una directory è un file, persino la comunicazione fra i vari processi o con i dispositivi hardware avviene tramite file.

Ma com’è fatto un file in Unix?

Un file è composto da tre parti diverse e ben distinte fra loro: il nome del file, il contenuto del file e i metadati, una serie di informazioni accessorie sul file che esamineremo meglio dopo.

Il contenuto del file è salvato in uno o più settori del disco rigido, i metadati sono memorizzati negli inode, delle strutture dati create al momento della formattazione del disco rigido e numerate univocamente, e infine il nome del file si trova nella directory (anch’essa un file!) che lo contiene, in una tabella che associa ad ogni nome di file della directory il numero dell’inode in cui sono salvati i metadati corrispondenti.

Ogni inode è una struttura dati (una specie di tabella un po’ più complicata) contenente, fra l’altro, la dimensione del file, i permessi di accesso e di modifica, la data e l’ora in cui in cui il file è stato creato, modificato o semplicemente letto, i puntatori ai settori fisici del disco rigido in cui è salvato il contenuto vero e proprio del file ed infine, quello che ci interessa di più, un numero intero che serve a contare il numero di copie (virtuali) del file stesso create tramite i cosiddetti hard-link.

Se a questo punto non vi gira già la testa potete continuare a leggere…

Hard-link e soft-link

In Unix è possibile riferirsi in modo indiretto ad un file mediante due diversi tipi di file: gli hard-link e i soft-link.

Dei soft-link ho già scritto in questo blog. Aggiungo che il soft-link crea un riferimento al nome del file, e si usa principalmente per dare un nome diverso ad un file.

Un hard-link crea invece un riferimento al numero dell’inode che contiene i metadati del file di partenza. Il file creato tramite un hard-link appare quindi a tutti gli effetti una copia del file originale, anche se non è esattamente così. Quando si copia un file, il nuovo file ha nome ed inode diverso ed anche il contenuto del file originale viene copiato in un’altra area del disco rigido. Creando un hard-link, il nuovo file avrà solo un nome diverso ma continuerà a riferirsi allo stesso inode, e quindi allo stesso contenuto, sul disco rigido.

Qualunque operazione effettuata sull’hard-link – modifica del contenuto del file, dei permessi, dell’ora di accesso al file – appare come se fosse effettuata anche sul file originale e su tutti i suoi hard-link: un hard-link è a tutti gli effetti lo stesso file, ma con un nome diverso.

A differenza del soft-link, però, che perde il riferimento al file originale e non serve più a nulla se quest’ultimo viene cancellato dal disco rigido, un hard-link continua ad essere valido anche se si cancella il file a cui fa riferimento.

Un hard-link ad un file viene creato con il comando,

$ ln file hfile

dove file è il file originale e hfile è l’hard-link (ovviamente i due file possono anche essere in directory diverse). Per creare il soft-link sfile basta aggiungere l’opzione -s al comando precedente.

$ ln -s file sfile

Ogni volta che si crea un nuovo file, il contatore delle copie del file contenuto nell’inode viene settato ad 1. Aggiungendo un hard-link a quel file, il sistema operativo incrementa di 1 il contatore, cancellando l’hard-link il contatore viene decrementato di 1. In effetti, tramite il contatore, il sistema operativo può sapere quanti hard-link sono presenti sul disco rigido oltre al file originale.

Arrivati a questo punto, chi vuole può saltare la sezione seguente e andare direttamente all’ultima parte del post.

Un po’ di pratica…

Usiamo ora il Terminale di OS X per mettere in pratica quanto abbiamo appena visto.

Il comando touch crea un nuovo file, a cui aggiungiamo una riga di testo qualunque con echo (un metodo quasi da hacker, si potrebbe benissimo farlo con un editor di testo).

$ touch file.txt
$ echo "Ho appena creato un file di testo." >> file.txt

Tramite ls -l mostriamo il file appena creato e una parte dei metadati associati.

$ ls -l
-rw-r--r--  1 maggi  staff  35 May 19T22:53:00 file.txt

Ci interessano qui due numeri in particolare. Quello contenuto nella seconda colonna è il contatore delle copie del file e vale 1 poiché il file è stato appena creato. Il numero nella quinta colonna, 35, è invece la dimensione in byte del file, uguale al numero di lettere che compongono il testo aggiunto con echo più il carattere (invisibile) di a capo.

Creiamo ora un hard-link e un soft-link che puntano entrambi al file di testo file.txt.

$ ln file.txt hfile.txt
$ ln -s file.txt sfile.doc

Eseguendo di nuovo ls -l,

$ ls -l
-rw-r--r--  2 maggi  staff  35 May 19T22:53:00 file.txt
-rw-r--r--  2 maggi  staff  35 May 19T22:53:00 hfile.txt
lrwxr-xr-x  1 maggi  staff   8 May 19T22:54:00 sfile.doc -> file.txt

si notano alcune cose fondamentali: (1) l’hard-link appare come un file del tutto identico al file originale, dimensioni, permessi, data di creazione (o di accesso), (2) il soft-link ha invece date, dimensioni e permessi differenti, (3) ed è anche mostrato in modo diverso nel Terminale, con una freccia che punta la file originale e con una l al posto del - nel primo carattere della riga, (4) avendo creato un hard-link il contatore delle copie del file contenuto nell’inode viene incrementato di 1 e, poiché i due file si riferiscono allo stesso inode (e quindi allo stesso contatore), il valore del contatore è uguale per file.txt e hfile.txt.

L’opzione -i del comando ls permette di stampare il numero dell’inode associato ad ogni file. Nel nostro esempio, si vede chiaramente che l’inode del file originale e quello dell’hard-link associato sono uguali.

$ ls -li
219115720 -rw-r--r--  2 maggi  staff  35 May 19T22:53:00 file.txt
219115720 -rw-r--r--  2 maggi  staff  35 May 19T22:53:00 hfile.txt
219115795 lrwxr-xr-x  1 maggi  staff   8 May 19T22:54:00 sfile.doc -> file.txt

Creando un hard-link si incrementa il contatore del numero di file contenuto nell’inode,

$ ln file.txt h2file.dat
$
$ ls -li
219115720 -rw-r--r--  3 maggi  staff  35 May 19T22:53:00 file.txt
219115720 -rw-r--r--  3 maggi  staff  35 May 19T22:53:00 h2file.dat
219115720 -rw-r--r--  3 maggi  staff  35 May 19T22:53:00 hfile.txt
219115795 lrwxr-xr-x  1 maggi  staff   8 May 19T22:54:00 sfile.doc -> file.txt

mentre se si cancella un hard-link il contatore viene decrementato di 1.

$ rm hfile.txt
$
$ ls -li
219115720 -rw-r--r--  2 maggi  staff  35 May 19T22:53:00 file.txt
219115720 -rw-r--r--  2 maggi  staff  35 May 19T22:53:00 h2file.dat
219115795 lrwxr-xr-x  1 maggi  staff   8 May 19T22:54:00 sfile.doc -> file.txt

Usciamo dal recinto

Per permettere a più applicazioni iOS di accedere alla stesso file, evitando allo stesso tempo la moltiplicazione dei file in diverso stato di “lavorazione”, serve un meccanismo che permetta di inserire tutti i documenti in un’area comune, riuscendo però a fare in modo che ciascuna applicazione continui ad accedere solo ai documenti che è autorizzata a gestire, cioè quelli contenuti nel suo sandbox.

Ricordo che il sandbox è un meccanismo che limita l’accesso di una applicazione ai file, alle preferenze, alle risorse di rete, all’hardware e così via, incapsulando ciascuna applicazione con i suoi documenti in una directory protetta.

Proprio gli hard-link possono essere sfruttati per implementare questo meccanismo.

In iOS (ma anche in OS X) le applicazioni ci appaiono come delle semplici icone. In realtà ogni applicazione è costituita da una directory che contiene al suo interno tutto quello che le serve per funzionare: l’eseguibile, le librerie, i file di supporto e di configurazione, le immagini e le icone e i documenti creati con l’applicazione stessa.

Immaginiamo ora di avere due applicazioni installate nel nostro dispositivo iOS. Se guardiamo al loro interno, osserveremo una struttura delle directory simile a questa.

$ tree
.
├── appA
│   ├── appA.app
│   ├── documents
│   ├── library
│   └── tmp
└── appB
	├── appB.app
	├── documents
	├── library
	└── tmp

La directory con estensione .app contiene il file eseguibile dell’applicazione, le altre non necessitano di spiegazioni. Si noti che il comando tree usato per mostrare la struttura delle directory delle due applicazioni non esiste di default in OS X, ma può essere installato sul Mac tramite Homebrew.

Aggiungiamo qualche file in ciascuna delle due applicazioni.

$ tree
.
├── appA
│   ├── appA.app
│   ├── documents
│   │   ├── file-AB.txt
│   │   └── file_A1.pdf
│   ├── library
│   └── tmp
└── appB
	├── appB.app
	├── documents
	│   ├── file-AB.txt
	│   ├── file_B1.pdf
	│   └── file_B2.txt
	├── library
	└── tmp

Come abbiamo già visto, ognuna delle due applicazioni può gestire solo i documenti contenuti al suo interno. Le due applicazioni possono al massimo scambiarsi i file contenuti nella directory documents di ciascuna, copiandoli integralmente da una applicazione all’altra. Nell’esempio precedente il file comune è file-AB.txt.

Una volta completata la copia, le modifiche effettuata da appA su file-AB.txt sono del tutto indipendenti da quelle effettuate da appB sul file omonimo contenuto nel suo sandbox. L’unico modo per mantenere il file sincronizzato fra le due applicazioni è quello di copiarlo dopo ogni modifica dal sandbox di una applicazione a quello dell’altra. Una cosa poco pratica e facilmente soggetta ad errori.

Immaginiamo invece di creare una directory pool, esterna alle due applicazioni, che agisca come spazio comune per tutti i documenti.

$ tree
.
├── appA
│   ├── appA.app
│   ├── documents
│   ├── library
│   └── tmp
├── appB
│   ├── appB.app
│   ├── documents
│   ├── library
│   └── tmp
└── pool
	├── file-AB.txt
	├── file_A1.pdf
	├── file_B1.pdf
	└── file_B2.txt

Ma le applicazioni presuppongono che i documenti siano all’interno del loro sandbox. È possibile fare in modo che le applicazioni riescano comunque ad accedere ai file in pool?

Facile: basta creare degli hard-link che dalla directory documents di ogni applicazione puntino ai file contenuti in pool. Ricreando tramite hard-link il contenuto originale delle directory documents delle due applicazioni si ottiene,

$ tree
.
├── appA
│   ├── appA.app
│   ├── documents
│   │   ├── hfile-AB.txt
│   │   └── hfile_A1.pdf
│   ├── library
│   └── tmp
├── appB
│   ├── appB.app
│   ├── documents
│   │   ├── hfile-AB.txt
│   │   ├── hfile_B1.pdf
│   │   └── hfile_B2.txt
│   ├── library
│   └── tmp
└── pool
	├── file-AB.txt
	├── file_A1.pdf
	├── file_B1.pdf
	└── file_B2.txt

dove, per chiarezza, gli hard-link sono indicati dal prefisso h aggiunto al nome del file.

Il vantaggio principale di questo meccanismo è che se una delle due applicazioni modifica il file hfile-AB.txt contenuto nel suo sandbox (quindi all’interno della sua directory documents), tutte le modifiche fatte dall’applicazione valgono anche per il file originale e per l’hard-link corrispondente contenuto nel sandbox dell’altra applicazione.

Ovviamente quanto detto finora è facilmente generalizzabile a un numero qualunque di applicazioni e di file.

Un altro vantaggio, che dovrebbe essere evidente da quanto detto in questo lunghissimo articolo, è che un hard-link non occupa altro spazio sul disco rispetto a quello occupato dal file originale. Si evita quindi di sprecare inutilmente spazio sul disco dell’iPhone e dell’iPad a causa della duplicazione dei file trasferiti da una applicazione all’altra. E si sa bene che lo spazio su qualunque computer non basta mai.

Ma come fa l’applicazione a inserire un nuovo documento in pool e a creare l’hard-link corrispondente nella sua directory documents? La risposta è semplice: non serve che lo faccia l’applicazione, il meccanismo immaginato qui può essere gestito dal solo sistema operativo. In altre parole, il meccanismo può essere implementato a livello del sistema operativo in modo del tutto trasparente alle applicazioni, che quindi non hanno bisogno essere modificate per funzionare correttamente.

Quando l’applicazione appA apre per la prima volta file-AB.txt, è il sistema operativo che si occupa di inserire il file in pool e di creare l’hard-link nel sandbox di appA. Il tutto è assolutamente trasparente ad appA, che non si accorge nemmeno di quello che è successo dietro le quinte. Se poi a un certo punto ho bisogno di inviare file-AB.txt da appA ad appB, posso limitarmi a cliccare come succede già oggi sull’icona apposita in appA, e sarà poi il sistema operativo ad intercettare la richiesta di copia del file, creando in realtà un nuovo hard-link in appB che punta anch’esso a file-AB.txt.

Infine, se si disinstalla una applicazione, supponiamo appB, anche i suoi documenti vengono cancellati dal disco, compreso hfile-AB.txt condiviso con appA. Ma il documento originale e l’hard-link in appA rimangono sul disco e non vengono persi inavvertitamente. Solo se si cancella anche appA, il sistema operativo attraverso il contatore nell’inode, si accorge che non ci sono più hard-link a file-AB.txt contenuto in pool e può decidere di cancellare anche il file originale, magari chiedendo conferma esplicita al proprietario o dopo aver effettuato un backup di sicurezza sul Mac.

E anche la cancellazione dei file può essere affidata senza problemi al sistema operativo e non deve essere gestita dalla singola applicazione.

Detto questo, aspettiamo pazientemente la WWDC 2014 per sapere che diavolerie inventerà veramente la Apple, in questo settore. Ammesso, naturalmente, che ne inventi qualcuna.

Sandboxing in iOS: un recinto troppo stretto

Fri, 16 May 2014 06:00:00 +0000

Si avvicina il WWDC e come al solito fioriscono le anticipazioni sulle novità che verranno presentate dalla Apple. Non sono particolarmente appassionato di queste pseudo-notizie, spesso completamente prive di fondamento, ma ogni tanto mi diverto a leggerle in giro per la rete.

Nel mare di cose inutili si trovano ogni tanto articoli intelligenti e ben fatti, in particolare quelli che invece che cercare di prevedere con una improbabile sfera di cristallo le mosse della Apple, provano ad elencare quello che sarebbe utile migliorare, in particolare nella struttura di base e nelle funzioni di OS X e iOS.

Fra gli articoli più interessanti che ho letto negli ultimi giorni, spiccano iOS 8 Wishes di Federico Viticci su MacStories – uno dei migliori blog in assoluto sul mondo Apple – e Why Apple should open up the iOS sandbox di Marco Tabini su MacWorld.

Entrambi gli articoli affrontano un tema che mi interessa moltissimo e che è di sicuro un grosso punto di forza di iOS, e contemporaneamente anche una grossa debolezza: il sandboxing delle applicazioni.

Il termine sandbox significa letteralmente recinto dei giochi e, in un contesto informatico, si può tradurre più o meno come ambiente protetto. Per semplicità da ora in poi userò quasi sempre il termine originale.

Il Sandbox delle applicazioni in iOS

Dalla iOS App Programming Guide:

For security reasons, iOS places each app (including its preferences and data) in a sandbox at install time. A sandbox is a set of fine-grained controls that limit the app’s access to files, preferences, network resources, hardware, and so on. As part of the sandboxing process, the system installs each app in its own sandbox directory, which acts as the home for the app and its data. To help apps organize their data, each sandbox directory contains several well-known subdirectories for placing files. Figure A-1 shows the basic layout of a sandbox directory.

Per motivi di sicurezza, nel corso dell’installazione iOS inserisce ciascuna app (incluse le preferenze ed i dati) in un ambiente protetto (sandbox). Un sandbox è un insieme di controlli specifici che limitano l’accesso dell’app ai file, alle preferenze, alle risorse di rete, all’hardware e così via. All’interno di questo processo di sandboxing, il sistema installa ciascuna app in una cartella protetta che racchiude sia l’app che i suoi dati. Per semplificare l’organizzazione dei dati di ciascuna app, ciascuna cartella protetta contiene una serie di cartelle ben definite in cui inserire i file. La Figura A-1 mostra l’organizzazione tipica di una cartella protetta.

[caption width=“975” align=“aligncenter”]<img src=“https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/Art/ios_app_layout_2x.png" width=“975” height=“1044” alt=“Figura A-1. Cartelle protette in iOS. La Figura è tratta da “iOS App Programming Guide”.” class /> Figura A-1. Cartelle protette in iOS. La Figura è tratta da iOS App Programming Guide.[/caption]

In pratica, quindi, ogni applicazione di iOS contiene al suo interno tutto quello che le serve per funzionare: l’eseguibile vero e proprio, i file di libreria, file vari di supporto e configurazione, i file delle immagini, le icone, i file temporanei ma anche i documenti prodotti usando l’applicazione stessa. Ci sono delle eccezioni, relative ad esempio alle foto, ma il concetto generale è questo.

Vantaggi

Quali sono i vantaggi di questo approccio?

Un primo vantaggio ovvio da quanto appena visto è che, essendo ogni applicazione completamente isolata dalle altre e dal sistema operativo, eventuali falle di sicurezza di una applicazione non compromettono le altre o il sistema operativo stesso.

Inoltre, il sandboxing evita all’utente di doversi preoccupare di gestire i file su iOS. Niente file o cartelle da creare, cancellare, rinominare, niente file da cercare chissà dove sul disco. Tutto è gestito dal sistema. Tutti i file sono visibili nell’applicazione usata, senza complicazioni inutili.

Un ulteriore vantaggio è che installare le applicazioni in iOS è facilissimo: basta copiare la cartella contenente tutto quello che serve all’applicazione per funzionare sull’iPhone o sull’iPad e via. Non servono installer che distribuiscano i file dell’applicazione qui e là sul disco. Una cosa pulita. Non ce ne accorgiamo solo perché il tutto è gestito da iTunes o direttamente dal dispositivo iOS.

Altrettanto facile è la disinstallazione delle applicazioni: basta tenere il dito sull’applicazione prescelta, aspettere che le icone inizino a tremolare e premere sulla piccola X in alto a destra per disinstallarla, sicuri che non ne rimarrà traccia sul dispositivo.

Molto più semplice che sul concorrente Android, in cui in teoria le applicazioni possono essere disinstallate più o meno allo stesso modo, ma accettando di lasciare tracce più o meno pesanti della loro presenza. Anche la disinstallazione tramite la voce apposita delle Impostazioni di Sistema lascia comunque rimasugli che possono solo essere rimossi manualmente o tramite tool appositi.

Svantaggi

Però l’approccio della Apple ha anche degli svantaggi.

Proprio perché la disinstallazione delle applicazioni rimuove tutto, si rischia di perdere insieme all’applicazione anche i documenti prodotti con essa. La cosa peggiore è che in caso di errore l’applicazione è facilmente reinstallabile ma i documenti sono comunque perduti per sempre.

Un altro svantaggio è che se si lavora su uno stesso file tramite più applicazioni, questo viene ogni volta copiato da una applicazione all’altra, per poter risiedere nella cartella protetta di ciascuna. Il problema non è tanto (o solo) lo spreco di spazio sul disco causato dalla duplicazione dei file, quanto il fatto che dopo un po’ si perde traccia delle modifiche effettuate sulle varie versioni dei file presenti nelle diverse applicazioni.

Prendiamo come esempio un file pdf. Il file inizialmente è sul Mac e viene sincronizzato con l’iPad tramite Dropbox per iOS. Da qui lo invio ad Adobe Reader per leggerlo. A un certo punto voglio aggiungere delle note o delle evidenziazioni al file, ma Adobe Reader non è adeguato e quindi lo trasferisco a GoodReader. Finito il lavoro, lo invio via email al Mac… Mi fermo qui ma è chiaro che dopo un po’ di passaggio (e dopo un po’ di tempo) ricordare la storia delle modifiche effettuate è praticamente impossibile.

Ancora peggio se si lavora su un progetto costituito da diversi file: documenti di testo, documentazione in pdf, presentazioni, immagini, filmati. Non c’è alcuna possibilità di accedere facilmente ai vari file del progetto e tutto è disperso fra le varie applicazioni, senza nessuno strumento che tenga insieme in qualche modo file di tipo diverso.

Un filesystem per iOS?

Insomma, con lo sviluppo dei dispositivi iOS, e soprattutto dell’iPad che ha ormai tutte le potenzialità per diventare un vero sostituto di un computer Desktop per la maggior parte degli utenti, si sente il bisogno di rendere più semplice ed efficiente la comunicazione fra le varie applicazioni.

Gli utenti avanzati, i power user, sarebbero favorevoli a che anche su iOS venga reso accessibile il filesystem (che esiste, ovviamente, ma è nascosto all’utente) o almeno una parte di esso (come su Android), vorrebbero avere a disposizione una specie di Finder per iOS che gli dia la possibilità di copiare o muovere i file ovunque o quasi all’interno del filesystem.

Mi metto anch’io fra questi. Per me l’uso del filesystem, la gestione di file e cartelle più o meno annidate, la scelta di volta in volta del programma da utilizzare per manipolare un determinato file, sono tutte cose ormai del tutto spontanee.

Ma so anche bene che per l’utente medio non valgono le stesse considerazioni.

I dispositivi iOS hanno successo non solo perché sono gestibili in modo più immediato con le dita, ma anche perché rendono naturale l’uso del computer e delle applicazioni, nascondendo all’utente tanti dettagli più o meno inutili. Si pensi ad esempio al non doversi preoccupare di salvare i file su cui si sta lavorando, ci pensa il sistema a farlo automaticamente. Per questi utenti un filesystem sarebbe una complicazione inutile. A quel punto i benefici di usare un iPad o un Phone verrebbero quasi a mancare del tutto.

Ma c’è una soluzione? Certamente e di certo più di una. Anche sfruttando le fondamenta stesse di Unix da cui deriva lo stesso iOS.

L'app del giorno

Mon, 03 Mar 2014 18:00:00 +0000

Se vi piace la grafica e la geometria – e non necessariamente entrambe – consiglio fortemente di scaricare iOrnament, che oggi è (quasi) gratis sull’App Store. E per una volta l’onnipresente acquisto in-app vale solo un caffé…

Persino un incapace totale dal punto di vista artistico come me può partire da uno scarabocchio qualunque,

per ottenere qualcosa di (quasi) decente.

Non riesco nemmeno ad immaginare cosa sarebbe capace di ottenere qualcuno in possesso di un minimo di talento artistico.