La costruzione della timeline

La timeline viene solitamente costruita utilizzando dei tool automatizzati i quali prendendo come base i dati MAC^[1] dei file. I dati MAC vengono mantenuti dal sistema operativo, si basano sull’ora attuale impostata sul sistema e forniscono un’idea delle operazioni che sono state effettuate. In un sistema basato su sistema operativo Windows vi sono altre fonti utili che devono essere tenute presenti durante le analisi quali il registro di configurazione, i registri degli eventi ed altre fonti che esulano dagli scopi di questo articolo.

Esistono diversi tool che creano una timeline basandosi sulle operazioni effettuate sui file. Tali tool sono disponibili open source^[2] e generano una sequenza di record in cui viene specificata ogni singola operazione svolta (lettura, scrittura o creazione del file), la data e l’ora in cui è avvenuta l’operazione, il nome del file coinvolto.

Ad esempio la seguente timeline:

15 giu 2010@15.33  3852       .a..  C:\Programmi\Microsoft Office\word.exe
15 giu 2010@15.51  25422      .ac.  C:\Users\utente1\Documents\Prova.doc

indica che il 15 giugno 2010  alle ore 15.33 è stato eseguito il programma di videoscrittura Word e che alle ore 15.51 è stato salvato il file dal nome Prova.doc.

Modifiche maliziose e tracciabilità

Ci sono diversi modi per cambiare la data e l’ora del sistema ma non tutti lasciano tracce evidenti dell’operazione. La data può essere modificata attraverso il BIOS^[3] oppure attraverso il sistema operativo in esecuzione.

La modifica della data e dell’ora può avvenire con intenti maliziosi, con l’esplicito intento di nascondere le tracce di un’azione oppure di lasciar intendere che il computer fosse in uso quando in realtà non lo era. Per tale ragione è necessario fare analisi approfondite per cercare di identificare cambi maliziosi ed effettuare constatazioni più accurate, affiancando alla timeline dei dati MAC dei file, anche l’analisi del registro di configurazione e del registro degli eventi.

Modifica della data e dell’ora attraverso il BIOS

Tutti i sistemi informatici forniscono un metodo per accedere al pannello di configurazione del BIOS. Attraverso questo pannello è possibile, tra le altre cose, modificare la data e l’ora di sistema. Tale modifica – essendo effettua a basso livello e fuori dal controllo del sistema operativo – non è rintracciabile in maniera diretta dal sistema operativo.

Non esiste un modo univoco per identificare il verificarsi di una simile situazione. Dall’analisi del registro degli eventi di Windows, però, ci si può accorgere di alcune anomalie. Visualizzando l’elenco degli eventi si potrebbe notare una non continuità nella successione delle date. Ad esempio, potremmo notare un evento registrato il 25 gennaio che viene visualizzato successivamente ad un evento registrato il 15 di febbraio. Questo sarebbe un segno evidente della manomissione della data. In altri casi, però, non è possibile accorgersi della manomissione. Pensiamo ad esempio ad un sistema che sia stato spento per tutto il periodo che vada dal 25 gennaio al 2 febbraio e supponiamo che l’ultima operazione svolta sul file Prova.doc risalga alle ore 23.15 del 24 gennaio.

Il giorno 3 febbraio l’utente accende il pc, accede al BIOS e cambia la data dal 3 febbraio al 25 gennaio. Il sistema si avvia e l’utente modifica il file Prova.doc. In questo caso, nella timeline creata troveremo una coppia di eventi del genere:

24 gen 2011@23.15  26335       m...  C:\Users\utente1\Documents\Prova.doc
25 gen 2011@18.23  26335       ma..  C:\Users\utente1\Documents\Prova.doc

Il secondo evento del 25 gennaio, in cui è stato modificato il file Prova.doc, in realtà è avvenuto il giorno 2 febbraio e non c’è alcun modo di scovare l’artefatto.

Modifica della data e dell’ora attraverso l’interfaccia del sistema operativo

L’uso del BIOS per la modifica dell’ora non è alla portata di tutti. Per l’utente meno esperto risulta più semplice utilizzare l’interfaccia grafica di Windows per la modifica della data e dell’ora. Tale operazione in questo caso è molto semplice da effettuare ma lascia una traccia all’interno del registro degli eventi. La traccia dipende dalla versione di Windows che viene analizzata. In Windows Seven, ad esempio, nel registro degli eventi di Sicurezza troveremo un evento con ID 4616 con dicitura “Modifica stato sicurezza”. Oltre all’evento nel registro di Sicurezza verrà inserito un evento all’interno del registro di Sistema con ID 1 (Kernel-General). Entrambi gli eventi riportano, nella descrizione, sia la data e l’ora modificata che le precedenti.

Analisi ed utilizzo di tool automatizzati

La generazione della timeline stilata in maniera completamente manuale può richiedere una quantità di tempo enorme. I tool di generazione delle timeline sono molto utili e fanno risparmiare moltissimo tempo ma si dimostrano inefficaci qualora non venissero affiancati da un’analisi attenta ed accurata delle altre fonti.

La necessità di approfondire tramite l’utilizzo di altre fonti di dati – come il registro degli eventi di Windows – diviene ancora più forte quando i dati estratti devono essere utilizzati per determinare se, in un determinato lasso di tempo, il sistema sotto analisi era in funzione e se fosse stato sottoposto ad azioni interattive da parte di un utente umano.

—

1. ^[1] MAC è l’acronimo di Modified Accessed Created e si riferisce ai timestamp in cui un file è stato creato, oppure acceduto o modificato. ↩
2. ^[2] La filosofia open source prevede che il codice sorgente di un software sia disponibile al pubblico. In questo modo è possibile verificare la bontà dei dati raccolti ↩
3. ^[3] Basic Input Output System: è una componente software che fornisce una serie di operazioni di base per accedere all’hardware sottostante e sfruttare le caratteristiche delle componenti connesse al sistema ↩

1. Ne.Me.Sys.: come funziona

Il software effettua le misurazioni collegandosi ad un server FTP sul quale sono presenti due cartelle denominate upload e download. La cartella upload viene utilizzata per trasferire file dal client al server permettendo la misurazione della velocità di trasferimento in upstream. La cartella download contiene dei file a dimensione predeterminata (7 Megabit, 10 Megabit eccetera) che vengono trasferiti sul computer client per la misurazione della velocità di trasferimento in downstream.

fig. 1 - Collocazione server FTP per i test di Ne.Me.Sys.

I server utilizzati da Ne.Me.Sys. per i test sono fisicamente collocati nei NAP^[1] (fig. 1). In questo modo il trasporto dei pacchetti tra il client ed il server avviene solo attraverso la rete dell’operatore a cui è connesso il client e la misurazione non viene influenzata dall’eventuale congestione delle reti degli altri operatori. Al termine di ogni misurazione Ne.Me.Sys. genera un file xml da inviare al centro raccolta dati e dai quali viene poi generato il documento probatorio. Il file xml contiene i tempi impiegati per i download dei file dal server FTP, i tempi impiegati per gli upload dei file al server FTP ed i tempi di risposta alle richieste di echo (ping) da parte del server FTP.

2. La connessione ad internet

fig. 2 - Collegamento ad internet tramite gateway

Per usufruire della connessione ad internet è necessario stipulare un contratto con un ISP^[2] e dotarsi di un modem ADSL che permetterà al nostro computer di comunicare con i sistemi informatici dell’ISP. Volendo generalizzare^[3] possiamo vedere il modem come il gateway^[4] della rete a cui il computer è collegato. Il gateway viene visto dal nostro computer come una scatola nera a cui viene attribuito un indirizzo IP. Lo scopo del gateway è quello di far giungere i pacchetti che transitano attraverso di esso a destinazione il più velocemente possibile sfruttando al massimo la velocità delle sue connessioni. Per questo motivo se il gateway è connesso ad una linea ADSL che ha un flusso dati massimo di 10 Megabit, allora la rete interna potrà usufruire di un flusso dati massimo di 10 Megabit (fig. 2).

3. E se il gateway “imbroglia”?

fig. 3 - Connessione ad internet tramite con traffic shaper

Essendo il gateway una scatola nera è possibile sostituirlo con un qualunque sistema informatico ad-hoc senza che il computer client sia in grado di notare la differenza. Il nuovo gateway potrebbe essere un computer in grado di eseguire un traffic shaper^[5] configurato in modo da fornire ai client della rete un flusso dati individuale di 25 kilobit (fig. 3). Questo basterebbe a falsare i risultati ottenuti dalla misurazione dei flussi upstream e downstream.

Oltre al flusso upstream e downstream Ne.Me.Sys. misura anche il tempo che impiega un singolo pacchetto per arrivare a destinazione e tornare indietro. Il ping dell’host utilizza il protocollo ICMP^[6] e si basa sull’invio di una richiesta di ECHO al server di destinazione il quale, una volta ricevuto il pacchetto, invierà una risposta all’host richiedente. Ricevuta la risposta l’host utlizza i tempi di invio e ricezione, oltre al timestamp del pacchetto ricevuto in risposta, per determinare i tempi di andata e ritorno del pacchetto. Dotando il gateway di un software dedicato a ritardare l’inoltro della richiesta ICMP e della relativa risposta è possibile incidere in maniera molto significativa sulla misurazione.

4. Conclusioni

Come si è visto è possibile intervenire maliziosamente al fine di falsare le misurazioni effettuate dal software Ne.Me.Sys. senza che questo fosse in grado di accorgersene. Qualora l’ISP si preoccupasse di loggare tutti i pacchetti che transitano sulla sua rete sarebbe possibile sollevare dubbi in merito alla presenza o meno di un gateway malizioso ma nessuna certezza potrebbe essere fornita. Ci si chiede, allora, se non sia stato un po’ azzardato dotare di valore probatorio il documento prodotto dalle misurazioni di Ne.Me.Sys. vista la semplicità con cui questi risultati possono essere alterati. Certo ci sarebbe ancora molto da discutere sulla possibilità di confutare una misurazione alterata ma il concetto di base resta sempre lo stesso.

1. ^[1] NAP è l’acronimo di Neutral Access Point. E’ il nodo di interscambio tra le reti dei diversi operatori. ↩
2. ^[2] ISP è l’acronimo di Internet Service Provider. Con questa sigla viene identificato il soggetto che fornisce il servizio di connettività internet ↩
3. ^[3] Tale generalizzazione è possibile poichè tutte le situazioni possono essere ricondotte a quella qui presentata. ↩
4. ^[4] Il gateway è la componente hardware o software che permette di instradare i pacchetti verso l’esterno della rete. ↩
5. ^[5] Un traffic shaper è un software capace di regolare il flusso dei pacchetti che transitano attraverso un host collegato ad una rete permettendo la regolazione selettiva della banda disponibile. ↩
6. ^[6] ICMP è l’acronimo per Internet Control Message Protocol e si riferisce al protocollo utilizzato per trasmettere informazioni di controllo tra host. ↩

Allo stesso modo il processo di boot di una piattaforma mobile è molto simile a quello di un normale desktop. Anche se i sistemi operativi delle piattaforme mobile sono numerosi e spesso proprietari, il processo che porta all’avvio del kernel del sistema è pressochè identico indipendentemente dalla piattaforma che il sistema operativo deve controllare.

Tutto il processo coinvolge, a catena, diverse fasi e componenti:

questo articolo descrive ognuna di queste fasi senza scendere troppo nei dettagli tecnici.

1. Accensione ed esecuzione del codice nella boot ROM

All’atto dell’accensione tutte le componenti hardware si trovano in uno stato che possiamo definire, con le dovute precauzioni, “caotico”: nessuna inizializzazione è stata ancora effettuata, l’alimentazione è molto instabile ed i clock interni, quelli che sincronizzano alla perfezione tutte le componenti, non sono ancora sincronizzati. Quando il sistema si è stabilizzato viene eseguito il codice contenuto all’interno della boot ROM. Si tratta di un piccolo pezzo di codice cablato all’interno dell’ASIC^[1]. La boot ROM conosce la struttura hardware del sistema ed è in grado di identificare, grazie ai registri di sistema,  la periferica di boot dalla quale preleva il codice che compone la prima fase del boot loader^[2] caricandolo nella memoria RAM interna. Terminato il caricamento la boot ROM passa l’esecuzione alla prima istruzione della prima fase del boot loader.

2. Il boot loader

Il boot loader è un piccolo programmino che si preoccupa di configurare alcuni aspetti dell’hardware prima di passare il controllo al kernel del sistema operativo. Sui sistemi desktop i più famosi sono LiLO e GRUB per sistemi Linux ed NTLDR della Microsoft per sistemi Windows. Nel caso di sistemi embedded ogni produttore fornisce il suo personalissimo boot loader specializzato per uno specifico terminale. In ogni caso i sistemi operativi hanno dei requisiti che i boot loader devono rispettare affinchè il sistema operativo stesso sia in grado di avviarsi correttamente.

Solitamente il bootloader si compone di due fasi e per ognuna delle due fasi c’è del codice dedicato memorizzato nella periferica di boot. La prima fase si occupa principalmente di riconoscere la RAM esterna ed inizializzarla insieme, eventualmente, ad altri dispositivi presenti sul terminale. Quando il terminale è pronto il codice della seconda fase viene prelevato dalla periferica di boot e viene caricato in memoria.

Durante l’esecuzione della seconda fase del boot loader vengono inizializzati i file system ed il supporto per la comunicazione di rete. Per i sistemi come gli smartphone si fa anche carico di inizializzare il modem, le protezioni di basso livello per la memoria ed attivare le opzioni per la sicurezza.

Al termine della seconda fase il boot loader caricherà il kernel di Linux. Solitamente il kernel è memorizzato nella periferica di boot ma nulla vieta che possa essere memorizzato in altre posizioni. E’ però necessario che il boot loader sia in grado di inizializzare e di accedere alla periferica. Per questa ragione il boot loader non sarà mai in grado, da solo, di caricare un kernel memorizzato su una SD con file system NTFS.

Durante la fase di caricamento del kernel nella RAM il boot loader prepara la memoria affinchè sia possibile passare dei parametri al kernel, il quale li legge in fase di avvio. Alla fine del caricamento il boot loader effettua un salto all’indirizzo a cui è stato caricato il kernel il quale prende possesso del sistema.

3. Il kernel di Linux

La procedura di start up del kernel di Android è molto simile a quella seguita da un kernel Linux su un sistema desktop ed in generale sugli altri sistemi. Il kernel inizializza ed imposta tutto ciò che è necessario a far girare il sistema. Vengono inizializzati i controller degli interrupt, le protezioni della memoria, le cache e gli algoritmi di scheduling. L’inizializzazione dello spazio utente avviene tramite il processo init che nell’albero delle cartelle di Android è situato in system/core/init. E’ il primo processo a girare nello spazio utente.

4. Il processo init

Il processo init è il padre di ogni altro processo che gira nello spazio utente. Durante il suo avvio processa il file init.rc, uno script che descrive i servizi di sistema, il file system ed altri parametri che è necessario impostare. Nel progetto open source di Android questo script lo si trova in system/core/rootdir.

Tra i tanti servizi di sistema avviati dal processo init troviamo Zygote, un processo di sistema che si fa carico di configurare ed avviare un’istanza di Dalvik, la Java Virtual Machine utilizzata da Android.

5. Il System Server

Il System Server è il primo componente java che viene eseguito da Dalvik. Questo componente è paragonabile al processo init per Linux poichè si fa carico di avviare tutti i servizi di Android come il gestore della telefonia ed il bluetooth. Le sue azioni sono codificate direttamente nel codice java^[3] e non è quindi possibile configurarlo tramite file.

6. Completamento della fase di boot

Una volta che il System Server è attivo ed ha avviato tutti i servizi viene emanato un intent denominato ACTION_BOOT_COMPLETED. Questo intent avvisa tutti i processi e le applicazioni che il boot del sistema è terminato con successo.  Per effettuare delle azioni come registrare un allarme o avviare un proprio servizio, le applicazioni che intendono farlo devono registrarsi per ricevere questo intent.

1. ^[1] ASIC è l’acronimo di Application-Specific Integrated Circuit. Si tratta di un circuito integrato realizzato per uno scopo specifico. ↩
2. ^[2] Il bootloader solitamente si compone di due fasi: la prima fase effettua delle inizializzazioni di sistema per poi caricare il codice della seconda fase che provvede a terminare il processo di boot. ↩
3. ^[3] Le azioni cablate all’interno del codice sono reperibili nel metodo run() della classe ServerThread implementata nel file frameworks/base/services/java/com/android/server/SystemServer.java del codice sorgente di Anrdoid ↩

L’atto del sequestro

Quando gli organi predisposti si accingono ad effettuare il sequestro devono attenersi ad una semplice regola: se l’apparecchiatura è accesa, non spegnerla; se l’apparecchiatura è spenta, non accenderla.

Quando un’apparecchiatura come un computer è in funzione deve essere lasciata in funzione non solo perchè è possibile effettuare un’analisi live della memoria RAM alla ricerca di eventuali password utilizzate per la cifratura di partizioni e dati, ma è molto probabile che l’utente abbia posto in essere delle strategie che, qualora il computer non venga spento con le dovute attenzioni, prevedono l’esecuzione di script ed automatismi che potrebbero distruggere in maniera irreversibile dati importanti per le indagini. Laddove non vi siano le necessità di un’indagine live o non si dispongono di mezzi e risorse per farle, la cosa migliore da fare è quella di spegnere l’apparecchiatura eludendo ogni azione che permetta al sistema di avviare procedure di spegnimento (una di queste potrebbe essere il distacco della spina dopo aver forzato il rilascio delle cache di scrittura).

Per una ragione molto simile è opportuno evitare di avviare un sistema spento. Oltre alla possibilità dell’esecuzione di script ed automatismi che distruggono i dati, è possibile che alcuni software vadano a scrivere dei file e queste scritture potrebbero essere indirizzate verso settori dei supporti di memorizzazione precedentemente “abitati” da dati utili alle indagini.

L’integrità successiva al sequestro

Le strategie seguite all’atto del sequestro sono solo il primo passo per ottenere la maggior quantità di dati possibile che non siano compromessi. Ma l’integrità, successivamente al sequestro, deve essere garantita immutata al fine di difendere lo stato delle cose quando queste non sono più nella disponibilità del proprietario. I dati devono essere protetti contro le scritture accidentali e, soprattutto, contro le manomissioni volontarie.

Contro le scritture accidentali è possibile ricorrere a dispositivi software o hardware. Quelli software sono molto economici ed hanno la necessità di essere installati su un sistema in esecuzione o su un sistema host che verrà poi utilizzato per l’analisi. Alcuni sistemi operativi (come ad esempio Linux) permettono di operare sui dispositivi in sola lettura garantendo una protezione sicura ed ineludibile. I dispositivi hardware, invece, denominati write blockers, sono decisamente più costosi e vanno ad interporsi tra la logica elaborativa principale e le unità di memorizzazione fungendo da filtri ed impedendo il passaggio di qualsiasi istruzione, diretta all’unità di memorizzazione, atta a trasferire dati su di essa. I dispositivi hardware sono certamente da preferirsi a quelli software poichè non possono essere rilevati direttamente e, soprattutto, non possono essere ingannati.

La manipolazione dei dati

Per lo svolgimento delle indagini è necessario accedere ai dati sequestrati e questo è sempre preferibile farlo su una copia fedele ove possibile. Ove non sia possibile effettuare delle copie fedeli è sempre indispensabile ricorrere all’uso dei write blocker.

Che si lavori su una copia o sull’originale è comunque sempre necessario intraprendere delle azioni che garantiscano che i dati non vengano manipolati e che rendendo possibili futuri controlli di integrità dei dati stessi. Prima di iniziare una qualunque operazione sui dati è, quindi, opportuno procedere a generare l’impronta digitale di ogni singolo file e dell’intera unità di memorizzazione. Quest’ultima accortezza è fondamentale poichè generando soltanto le impronte dei file non rende possibile un controllo sui settori dell’unità occupati precedentemente da file che sono poi stati cancellati dal proprietario.

La generazione dell’impronta digitale deve avvenire attraverso algoritmi di hashing che siano riconosciuti come sicuri al fine di impedire che vengano sollevate obiezioni che invalidino la totalità delle indagini. Nel momento in cui scrivo questo articolo gli algoritmi di hashing considerati sicuri sono SHA-1 (anche se nel 2005 venne trovato un attacco sulle collisioni che comunuque è ancora inattuabile) oppure SHA-2.

Prese queste accortezze si possono effettuare tutte le operazioni che si ritengono necessarie alle indagini e che portanno essere poi ripetute, qualora si lavori su delle copie, anche sugli originali. Grazie alle impronte hash, nessuno potrà eccepire che si tratti di una manipolazione.

Nel web clustering non ci si può aspettare che il load balancer rediriga una connessione sempre verso lo stesso server. La cosa, anzi, è piuttosto improbabile e le configurazioni basate su IP sono ormai da considerarsi assolutamente obsolete ed inadatte all’attuale conformazione degli ISP. Questo comportamento causa problemi per chi avesse necessità di conservare i dati di una sessione.

Prendiamo ad esempio una configuarzione con due server, Ciccio e Polenta, connessi alla rete WAN tramite lo stesso balancer (fig. 1).

Immaginiamo che un client voglia eseguire un processo di autenticazione sul nostro server Web. Dopo aver visualizzato la pagina contente il form con i campi da riempire, l’utente cliccherà su una qualche forma di pulsante che permetterà al browser di inoltrare una richiesta HTTP passando al server i valori immessi per i campi di login e password. Supponiamo che la richiesta da parte del browser venga inoltrata, dal balancer, verso il server Ciccio. Ciccio provvederà a controllare i dati inviatigli dal client e, se corretti, procederà ad iniziare una sessione, comunicando al client il successo dell’operazione.

Successivamente all’autenticazione l’utente clicca sul link che gli permette di visualizzare il suo profilo. Il browser prepara allora una nuova richiesta che verrà presentata sull’interfaccia WAN del nostro server web. Il balancer, però, questa volta redirige la richiesta verso il server Polenta.

Il comportamento di default del PHP è quello di memorizzare i dati della sessione all’interno di un file locale al server. Tale file viene creato, in genere, quando viene avviata la sessione. Di conseguenza solo Ciccio è a conoscenza dei dati memorizzati nella sessione iniziata dall’utente e quando la richiesta di visualizzare il profilo arriva al server Polenta questi non ha idea di come rispondere alla richiesta poichè non sa gestire il session_id inviatogli dal browser.

Memcached^[1]

Una soluzione al problema può venire dall’uso di Memcached. Memcached è un sistema di caching distribuito open source ad alte prestazioni che permette di salvare delle informazioni asociandole ad una chiave univoca. Memcached si comporta esattamente come una memoria cache volatile: se il processo server dovesse morire portando giù il servizio tutte le informazioni memorizzate in Memcached andranno perse.

Per alcune applicazioni questo tipo di “rischio” può essere accettabile, soprattutto se si considera che Memcached può essere installato senza toccare una riga di codice dell’applicazione PHP, andando a sostituire integralmente il sistema di gestione delle sessioni di default.

Configurazione di PHP per l’uso di Memcached come handler di default per la sessione

La configurazione di Memcached attraverso il file php.ini è molto semplice. Per configurare gli handler di default della sessione è sofficiente modificare, dopo aver installato Memcached da qualche parte sulla rete, due parametri: session.save_handler e session.save_path:

session.save_handler=memcached
session.save_path="tcp://10.10.10.1:11211"

L’indirizzo IP 10.10.10.1 si riferisce al server sul quale è stato installato Memcached, mentre 11211 è la porta di ascolto del server.

Alternativamente si possono scrivere degli handler di sessione personalizzati utilizzando la funzione PHP session_set_save_handler()^[2]. In questo caso per accedere al server di Memcached si può far ricorso alle API per PHP di Memcached ampiamente documentate anche sul sito di PHP.

L’uso degli handler di salvataggio della sessione in maniera trasparente attraverso il PHP è sì molto veloce da realizzare ma si tratta comunque di una soluzione non scalabile e poco mantenibile. Se si dovesse, ad esempio, rendere necessario cambiare la porta di ascolto di Memcached sarà altresì indispensabile modificare tutti i file php.ini di tutti i server coinvolti per rispecchiare la nuova situazione. Inoltre qualora si dovesse aggiungere un server al cluster ci si dovrà ricordare di modificare la configurazione di PHP altrimenti sarà difficile rendersi conto dell’errore prima che si verifichino pesanti disservizi.

Memcached + MySql

Laddove l’applicazione PHP richieda una maggiore affidabilità circa le sessioni, è indispensabile avvalersi dell’appoggio di un database solido e performante come MySql. L’uso del database, però, apporta una forte latenza nella gestione delle sessioni.

Per evitare di sovraccaricare il server MySql e per eludere latenze che per grossi carichi di lavoro possono rivelarsi fatali, si può pensare di giungere ad una soluzione ibrida che preveda l’uso del database per una forte persistenza a cui si va ad affiancare l’uso di Memcached per effettuare il caching delle query così come schematizzato in fig. 2.

fig. 2 - Web cluster con Memcached e MySql

In questo caso, però, non ci si può affidare a PHP per la gestione delle sessioni ed è indispensabile scrivere degli handler personalizzati scegliendo le adeguate strategie di caching oltre a dover gestire l’indisponibilità del server di Memcached.

———

1. ^[1] Memcached ↩
2. ^[2] session_set_save_handler() ↩

Tramite il tag meta è possibile intervenire sulle politiche di caching del browser. Utilizzando ad esempio <meta http-equiv=”expires” content=”sun, 4 jul 2010 23:00:00 GMT”> è possibile costringere il browser a ricaricare la pagina a partire dalle ore 23 di domenica 4 luglio 2010. Se invece vogliamo che il caching venga disabilitato del tutto, possiamo utilizzare il tag <meta http-equiv=”cache-control” content=”no-cache”>.

Ciò che ci si aspetta, utilizzando il parametro no-cache della direttiva cache-control, è che il browser inoltri una richiesta al server ogni qual volta si ricarica la pagina. In Mozilla Firefox la pagina principale viene ricaricata ma non viene ricaricato il foglio di stile CSS nonostante questo sia stato modificato.

Sembrerebbe che Firefox utilizzi una strategia di caching particolarmente aggressiva per i fogli di stile e, per costringerlo a ricaricare il foglio di stile, è necessario effettuare numerosi aggiornamenti della pagina. Nemmeno tenendo premuto il tasto shift mentre si clicca sul pulsante “Aggiorna”.

Per eludere questo problema io ho utilizzato questo piccolo trucchetto. Supponiamo di avere un foglio di stile inserito in questo modo: <link rel=’stylesheet’ href=’http://www.zazy.it/stile.css’>. Per costringere Firefox a ricaricare il foglio di stile è necessario fargli credere che si tratti di un foglio di stile generato da una pagina dinamica. Per fare questo basta semplicemente aggiungere un ? (punto interrogativo) alla fine del nome del file css così da trasformare il tag di prima in <link rel=’stylesheet’ href=’http://www.zazy.it/stile.css?’>.

In questo modo il foglio di stile verrà ricaricato ogni volta che viene caricata la pagina. Ricordiamoci, però, di rimuovere quel punto interrogativo aggiuntivo quando abbiamo finito con le nostre modifiche, così da evitare inutili richieste al server con inutile spreco di banda .

Sembra essere prassi comune mostrare segnale pieno già da una misurazione di circa -90 dBm distribuendo le rimanenti “tacche” per i valori tra -131 dBm e -90 dBm. La spiegazione sembra sia da ricercarsi nelle “intenzioni” della visualizzazione. Mostrare segnale pieno serve ad indicare all’utente che la rete a cui ci si è agganciati può essere utilizzata senza problemi.

Resta comunque un fatto oggettivo che impugnando il telefono con la mano sinistra la qualità del segnale crolla ad un punto tale da impedire finanche una conversazione, così come mostrato nel video qui sotto.

Come detto anche da Steve Jobs tutti i telefoni hanno dei punti critici dovuti alla posizione dell’antenna interna. Il mio HTC Magic, ad esempio, ha l’antenna posizionata sul lato inferiore del telefono ed il segnale decade con qualunque mano tenga il telefono. Quello che Jobs si è dimenticato di dire è che nessun telefono (o almeno nessuno che io conosca) ha una simile caduta di segnale.

——–

1. ^[1] http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=services/java/com/android/server/status/StatusBarPolicy.java;h=3b0c436bf9b9cb71b1f057b4904c660318e20eff;hb=HEAD#l996 ↩

Ora però, sono gli utenti ad evidenziare i primi problemi, alcuni dei quali non sono di poco conto, soprattutto se si va a soppesare il modo in cui Apple ha affrontato la situazione.

Il primo e più evidente riguarda la ricezione. La particolare posizione dell’antenna e soprattutto il fatto che questa è assolutamente priva di protezione di qualunque genere, espone l’iPhone ad una terribile caduta della qualità del segnale quando il terminale viene impugnato con la mano sinistra. Un video pubblicato da IGM su youtube mostra come questo problema renda la vita pressochè impossibile soprattutto ai mancini.

Come si può vedere dal video nell’istante in cui si impugna l’iPhone con la mano sinistra e si va a coprire l’antenna posta nell’angolo in basso a sinistra la conversazione viene troncata a causa della caduta di ricezione.

Il blog BGR ha pubblicato un estratto della procedura che Apple ha imposto ai suoi customer care. In pratica ai suoi dipendendti ha imposto prima di tutto di utilizzare un tono sempre cordiale e di ripetere fino alla nausea al “contestatore”, qualunque siano le sue domande, che questo è il miglior iPhone di sempre e che per risolvere il problema sarebbe opportuno utilizzare una cover in gomma o in plastica così da evitare che la pelle tocchi l’antenna.

A peggiorare (a mio avviso) la situazione si ci è messa la presunzione arrogante di Steve Jobs il quale rispondendo alla domanda di un cliente ha detto “Sei tu a tenerlo nel modo sbagliato. Non tenerlo più così”. Bisognerà chiedere a Jobs quale sia il modo corretto per tenere il telefono.

Personalmente mi basterebbe questo per abbandonare il marchio della mela a causa delle sue politiche ma sembra che la gente compri l’iPhone proprio perchè tutti comprano l’iPhone… paradossale!

Diversi utenti hanno lamentato un malfunzionamento del sensore di prossimità, ossia di quell’agglomerato di circuiti che dovrebbe disattivare le funzionalità del touch screen quando questo viene avvicinato all’orecchio. Questa strategia serve ad evitare che vengano attivate inavvertitamente delle funzioni a causa del contatto del touch screen con la pelle dell’orecchio o del viso. Quando il sensore di prossimità non funziona il touch screen resta attivo e così è probabile che vengano inviati sms o inoltrate chiamate senza accorgersene.

Vacilla anche il tanto decantato retina display poichè è stata riscontrata l’apparizione di macchie giallastre molto vistose che rovinano l’immagine del display. Fortunatamente sembra che queste macchie svaniscano dopo qualche giorno di utilizzo dell’iPhone.

Avevo già sentito parlare del suo predecessore “Dream” e, a parte l’aspetto non proprio gradevole (per i miei gusti), mi aveva fortemente incuriosito così quando a giugno 2009 la Vodafone mi ha proposto questo prodotto a 360 euro e a rate da 9 euro al mese… non ho resistito alla tentazione e l’ho comprato.

Hardware

Il Magic è dotato del processore Qualcomm MSM7201a a 528 Mhz^[1], 512 MB di ROM e 192 MB di RAM, uno schermo TFT con risoluzione HVGA 320×480, GPS integrato, Wi-Fi, Bluetooth, fotocamera da 3,2 megapixel, bussola e gli ormai immancabili G-Sensor. In pratica, a parte la ROM di 512 MB ed una batteria dalle prestazioni leggerissimamente migliori, è in tutto e per tutto identico all’HTC Dream di qualche anno addietro.

Una cosa che non è affatto chiara consultando il portale di HTC, è che di questo smartphone ne esistono due versioni esteticamente identiche. Una versione, denominata Sapphire/32B, equipaggiata con 192 MB di RAM ed una versione, denominata Ebi1/32A, con 256 MB di RAM. Una differenza non da poco, soprattutto se si pensa che sui terminali 32B non è possibile far girare la tanto vantata interfaccia utente sviluppata da HTC e denominata HTC Sense UI.

Posso affermare che, dal mio punto di vista, il Magic 32B è stato un po’ abbandonato da HTC.

Confezione

Il Magic venduto da Vodafone si presenta in una scatola dalle dimensioni piuttosto contenute in cui trovere, oltre al telefono ed alla batteria, il caricabatterie, degli auricolari stereo, un manualetto utile solo a chi non ha mai usato un terminale touch, una tasca in similpelle marchiata HTC, il cavetto USB per il PC ed una praticissima scheda di memoria da 8 Gb.

Aspetto esteriore

A differenza del Dream, l’HTC Magic ha un aspetto molto gradevole ed un design morbido e delicato che gli conferisce una forma che non infastidisce quando lo si tiene nella tasca dei jeans. Non è molto ingombrante come potrebbe esserlo un iPhone e con i suoi 119 grammi batteria compresa lo si può considerare piuttosto leggero per il suo genere.

Scocca ed aspetto esteriore

Non appena ci si mettono sopra le mani (nel senso fisico della parola) ci si rende subito conto della qualità del prodotto. Non solo le plastiche sono di qualità eccellente ma anche il loro assemblaggio trasmette un’idea di robustezza. A “torcerlo” non si sentono scricchiolii e la tenuta degli agganci sembra essere molto solida.
I pulsanti sono in leggero rilievo rispetto alla scocca e sono piuttosto piccoli ma anche chi ha un pollice “ingombrante” come il mio riesce a premerli comodamente.

Audio

La qualità dell’audio di questo terminale mi ha davvero stupito. In ricezione offre un suono pieno e robusto e anche il nostro interlocutore potrà udirci senza troppi sforzi anche in ambienti piuttosto rumorosi.
Connettendo le cuffie stereo fornite in dotazione non si rimpiange di aver lasciato a casa l’iPod

Schermo

Il Magic è dotato di un ampio schermo da 3 pollici di tipo capacitivo che reagisce molto bene al tocco. Per chi usa questo tipo di schermo per la prima volta necessiterà di un po’ di pratica per prenderci la mano.
La visione è decisamente ottima anche sotto i raggi diretti del sole e resta tale indipendentemente dall’angolazione con cui lo si guarda. I colori sono brillanti e l’illuminazione è potente ma molto morbida e quindi non infastidisce gli occhi (ed io sono fotofobico!)

Durata batterie

All’inizio la batteria dura decisamente poco, anche perchè è molto difficile non mettersi ad esplorare e testare tutte le funzioni del telefono. Per arrivare ad ottenere il massimo delle prestazioni saranno necessari circa 15/20 cicli di ricarica.
Configurando bene il telefono ed evitando di attivare servizi inutili, sono riuscito ad ottenere un’autonomia di 20 ore continuate con un uso “modesto” delle sue funzioni mentre si riducono a 12 ore o meno quando se ne fa un uso intenso, soprattutto quando si lasciano accesi Wi-Fi e ricevitore GPS.

User experience

La così detta “user experience” è ormai ciò che più conta quando si utilizzano terminali così complessi. Il feeling con il Magic non è elevatissimo e di sicuro non arriva ai livelli di iPhone ma è decisamente gradevole e considerando che Android non è un sistema per il solo divertimento lo collocherei in una fascia medio-alta/alta. A volte il sistema tarda a reagire al tocco il che ci induce a ripetere l’azione con risultati non sempre gradevoli ma il suo comportamento globale è decisamente buono, soprattutto se si passa ad Android 1.6.
Peccato non sia previsto un sensore per disattivare lo schermo quando questo è vicino all’orecchio perchè mentre si è in conversazione può capitare che si faccia qualcosa senza accorgersene.

Pecche

La più grave riguarda, a mio avviso, l’impossibilità di utilizzare la sveglia a terminale spento. Questo vi costringe a tenere il telefono acceso sul comodino qualora fosse necessario e, anche se è possibile attivare la modalità aereo spegnendo tutte le trasmissioni radio, la cosa non mi piace affatto.

La fotocamera è piuttosto deludente. A causa del modo in cui è montata, il vetrino (o forse è meglio dire “la plastica”) frontale si sporca facilmente ed è necessario pulirlo molto spesso. Le foto non sono eccezionali e spesso i colori risultano un po’ “annebbiati”.

Altro aspetto molto deludente è la capacità di catturare video. Il Magic, infatti, riesce a catturare appena 10 fotogrammi al secondo il che risulta in un video molto scattoso, poco definito e che mostra “scie” anche con leggeri movimenti.

Conclusioni

Rinunciando a tutti gli aspetti ludici il Magic è un terminale decisamente valido anche se non riuscirà di certo a far tremare iPhone. Android è ancora giovane e si vede ma la sua evoluzione è rapida e le migliorie evidenti.
E’ un terminale che consiglio a chi non vuole avere tra le mani un giocattolo per bambini ma un telefono serio con un sistema robusto, pensato per esserci utile e non solo per essere esteticamente gradevole.

———

1. ^[1] http://pdadb.net/index.php?m=cpu&id=a7201a&c=qualcomm_msm7201a ↩

Interfaccia utente

La nuova home presenta uno stile grafico più accattivante ed una maggiore attenzione verso gli utenti più esigenti. Alcune applicazioni, come il browser ed il telefono, hanno un’area dedicata posta nella parte bassa dello schermo sempre accessibile da qualunque schermata della home.

Dopo diversi tentativi, più o meno maldestri, da parte di coraggiose software house, per gli utenti aziendali arriva un supporto per Exchange degno di tale nome. Grazie al pin alfanumerico e grazie alla distruzione dei dati da remoto, smarrire lo smartphone Android non comprometterà i dati aziendali. E’ inoltre stato aggiunto il supporto per il calendario di Exchange ed una migliore integrazione con il client di posta elettronica.

Per chi utilizza la tastiera virtuale è ora possibile configurarla con più di un linguaggio e sarà possibile saltare da una configurazione all’altra semplicemente strisciando con il dito sulla barra spaziatrice. Il cambio di configurazione non riguarda solo il layout della tastiera ma anche il dizionario.

Prestazioni

Gli sforzi degli sviluppatori si sono concentrati per lo più sull’ottenere maggiori prestazioni da un sistema le cui scelte progettuali ed architetturali sono state molto criticate sin dall’inizio.

Secondo quanto affermato dal capo del team di sviluppo Xavier Ducrohet l’introduzione del compilatore JIT per Dalvik (la JVM di Android) promette di ottenere, dalle applicazioni che fanno uso intensivo della CPU, un incremento medio di prestazioni fino a 5 volte superiori rispetto aquelle ottenute da Android 2.1. Le prestazioni sono state misurate utilizzando diversi software di benchmark. Il risultato migliore è stato offerto da Linpack secondo il quale si avrebbe un incremento di prestazioni che sfiora il 600% mentre il risultato “peggiore” è stato presentato da CaffeineMark secondo il quale l’incremento sarebbe “soltanto” di poco superiore al 450%.

Maggiori prestazioni dovrebbero arrivare anche dal browser che finora ha sempre deluso. Nella nuova versione viene infatti utilizzato il nuovo motore V8 che dovrebbe consentire prestazioni migliori soprattutto per pagine che fanno un uso intensivo di JavaScript.

Ritocchi anche per il modulo di gestione della memoria del kernel che dovrebbero consentire una maggiore fluidità nell’esecuzione di applicazioni in particolar modo su quei terminali con poca memoria RAM (come il pionieristico HTC G1 ed il suo fratellino HTC Magic).

Migliorate sembrano essere anche le prestazioni della videocamera. Grazie alle nuove API il framerate passa da un massimo di 10 fotogrammi al secondo ad un massimo di 20 concedendo prestazioni quasi raddoppiate.

Novità per gli sviluppatori

Molto interessanti appaiono le novità apportate al framework di Android. Prima fra tutte spicca la possibilità di installare le applicazioni su una memoria esterna al telefono, permettendo così di preservare spazio per i propri dati. Questa opportunità è stata offerta in passato da applicativi di terze parti (come Apps2SD) che causavano non pochi problemi soprattutto con le ROM moddate. La scelta di supportarlo in maniera nativa accoglie le tante lamentele sollevate soprattutto dai possessori del G1 che proponeva uno spazio dedicato alle apps piuttosto limitato.

Il servizio di data backup offre un metodo facile e veloce per salvare le impostazioni delle applicazioni. Questo permette di ripristinare rapidamente lo stato dello smartphone in caso di wipe o di reinstallazione di un’applicazione. Il servizio non opera in maniera indiscriminata ma dovranno essere le applicazioni ad attivarlo. Gli amanti della privacy dovranno stare attenti alla scelta degli applicativi da installare.

Un altro passo viene mosso per andare incontro alle esigenze di chi sviluppa applicativi basati su OpenGL. Nelle nuove API, oltre ad avere le OpenGL ES 2.0, troviamo utility e metodi per la compressione delle texture e nuove funzioni per la manipolazione delle immagini in formato YUV e la loro compressione in JPEG.

Piattaforma

Nella piattaforma di Android vengono introdotte nuove tecnologie per migliorare la multimedialità e, soprattutto, l’uso del bluetooth.

Per quanto riguarda la gestione dei file multimediali al già ben rodato OpenCore viene affiancato il framework Stagefright che supporta sia la riproduzione di file locali che lo streaming progressivo tramite HTTP.

Per il bluetooth vengono introdotte la possibilità di condividere i contatti con altri telefoni e troviamo anche un miglioramento per quel che riguarda la compatibilità con le periferiche audio come auricolari e kit vivavoce. Ma la novità più importante riguarda la possibilità di effettuare chiamate vocali tramite l’auricolare bluetooth, anche se non è ancora chiaro quali linguaggi siano supportati e quali siano le eventuali limitazioni.

Introdotta anche la possibilità di utilizzare uno smartphone Android come hotspot wi-fi. Grazie a questa modalità lo smartphone Android potrà essere condiviso tra massimo 8 periferiche che potranno utilizzarlo, grazie al supporto per il tethering nativo, per accedere ad internet. Unica pecca di questa modalità è l’enorme quantità di energia richiesta ad un terminale non concepito per tale scopo. Impossibile impedire alla batteria di scaricarsi in breve tempo (da alcuni test sembrerebbe fino ad un max di 4 ore su un HTC Nexus One) senza collegare lo smartphone ad una fonte di energia come un caricabatterie o una porta USB. In quest’ultimo caso, però, un uso intensivo della connessione da parte dei terminali collegati allo smartphone, rischia di surriscaldare lo smartphone con tutte le conseguenze del caso.