Riccardo Mori

Usabilità Web: otto problemi ancora attuali (Prima parte)

November 16, 2008

Fra le mie letture in corso, degno di nota è il libro Prioritizing Web Usability, a cura di Jakob Nielsen e Hoa Loranger. Uno dei capitoli che finora hanno maggiormente attratto la mia attenzione è il terzo, “Revisiting Early Web Usability Findings”, in cui gli autori riprendono i problemi di usabilità del Web che avevano già cominciato a individuare nel 1994 e analizzano la situazione odierna, dopo tutte le trasformazioni ed evoluzioni avvenute nel Web in questi 14 anni. Il capitolo ritorna su 34 dei più importanti problemi di usabilità per verificare quali fra questi sono stati migliorati, quali ormai sono irrilevanti, e quali sono ancora gravi così come lo erano allora.

Dato che mi sembrano spunti interessanti e condivisibili, ho tradotto e preparato un sunto della sezione “Eight Problems That Haven’t Changed”, ossia gli otto problemi legati all’usabilità che continuano a essere seri ancora oggi. Considerata la lunghezza del testo, per una maggiore leggibilità l’ho diviso in due parti, che appariranno in due distinti post.

Il testo originale della parte che segue è ovviamente copyright di Nielsen e Loranger.

Otto dei problemi di usabilità originari sono importanti oggi come lo erano quando li individuammo per la prima volta. Anche se oggi alcune di queste cattive pratiche di design sono meno diffuse sul Web, ve ne sono altre che rimangono problematiche, dato che il loro abuso continuato ha reso gli utenti ancora più sensibili verso di esse.

Fra le aree che continuano a dare gravi problemi citiamo:

Link che non cambiano di colore dopo essere stati visitati

Compromettere la funzione del pulsante Indietro

L’apertura di nuove finestre del browser

Finestre pop-up

Elementi di design che somigliano a riquadri pubblicitari

Il mancato rispetto delle convenzioni del Web

Contenuti fumosi e sensazionalismi vacui

Contenuti troppo densi e testi difficili da scorrere rapidamente

1. Link che non cambiano di colore dopo essere stati visitati

Una delle più vecchie linee guida di usabilità in rapporto al design per la navigazione è di aiutare gli utenti a capire dove sono stati, dove si trovano ora e dove possono recarsi — insomma, il loro passato presente e futuro online.

[…] Sul Web, i link sono un elemento chiave in questo processo di navigazione. Gli utenti possono abbandonare dei link che si sono rivelati di scarsa utilità in passato o, al contrario, ritornare a visitare link utili. Ma soprattutto, quando gli utenti sanno quali pagine hanno già visitato, sarà più difficile che vi ritornino accidentalmente.

Solitamente i browser Web sono piuttosto carenti nel facilitare la navigazione all’utente, ma offrono una funzione molto importante: permettono ai designer di cambiare il colore del link a una pagina quando l’utente l’ha già visitata. Cambiare il colore dei link visitati è stata una parte fondamentale della navigazione Web sin da quando il National Center for Supercomputing Applications (NCSA) produsse Mosaic nel 1993. Al momento, il 74% dei siti Web utilizza questo approccio, rendendolo di fatto una convenzione che gli utenti si aspettano di veder rispettata.

Sui siti che ignorano questa convenzione, però, si possono sperimentare seri problemi di usabilità. Nei nostri test, gli utenti hanno visitato più volte le stesse pagine per errore, si sono smarriti con più facilità, hanno frainteso o trascurato la differenza fra link simili quando non erano sicuri su quali avessero già visitato, e hanno abbandonato l’esplorazione di un sito più rapidamente. In generale si sono sentiti meno padroni di quei siti che non sono stati in grado di rispondere alle loro azioni e di aiutarli nell’esplorazione.

Tali problemi di usabilità risultano essere più seri per coloro che hanno problemi di memoria a breve termine, che spesso senza un indizio visivo non ricordano quali link hanno seguito. Naturalmente, tutti gli esseri umani hanno problemi di memoria a breve termine a vari livelli, e per questo il cambiamento del colore dei link visitati è un vantaggio per tutti. Dato che il problema affligge certe persone più di altre, è particolarmente importante variare i colori dei link se il target di un sito comprende per esempio molte persone anziane, come ha dimostrato la nostra ricerca con soggetti di età avanzata.

Link dai colori immutabili creano confusione nella navigazione perché gli utenti non capiscono bene le varie scelte che hanno a disposizione oppure a che punto si trovano. Questo problema di usabilità continua a essere grave come lo era un tempo.

[…]

2. Compromettere la funzione del pulsante Indietro

Nella vita a molte situazioni non v’è rimedio e non è possibile tornare indietro. […] Sul Web, tuttavia, le persone devono potersi sentire a proprio agio sapendo che è sempre possibile annullare o alterare un’azione. Incoraggiare gli utenti all’esplorazione libera di un sito, sapendo che possono sempre trovare una via d’uscita in caso di problemi, è uno dei principi fondamentali dell’interazione fra l’uomo e il computer.

Nelle applicazioni software tradizionali, il comando “Annulla” (ingl. “Undo”) serve proprio a questo. Se per esempio state esplorando un programma di grafica, potete colorare di rosso alcune parti di un’immagine e vedere se il risultato vi soddisfa. In caso contrario, basta un Cmd‑Z e il rosso viene eliminato. Sin dai primi anni Ottanta uno dei capisaldi del design è stato proprio il supporto della funzione Annulla nel maggior numero di applicazioni possibili.

Il poter tornare sui propri passi è l’equivalente di “Annulla” nella metafora della navigazione ipertestuale. È possibile muoversi nello spazio informativo quanto e come più aggrada, senza mai perdersi davvero perché si può sempre tornare indietro in territorio ‘sicuro’. Nei browser Web questo ritorno sui propri passi viene implementato attraverso il pulsante Indietro. Gli utenti continuano a premere su questo pulsante fino a tornare al punto in cui vogliono. I più esperti possono anche tenere premuto il pulsante per richiamare un menu con la cronologia dei siti visitati e tornare indietro in un punto preciso.

[…] Il pulsante Indietro offre due grossi vantaggi più un terzo beneficio di minore entità:

Il pulsante Indietro è sempre disponibile, si trova sempre nello stesso posto, e funziona sempre allo stesso modo, procedendo a ritroso un passo alla volta. Tale coerenza forte dell’interfaccia utente evita alle persone il bisogno di passare in rassegna l’intero contenuto di una pagina alla ricerca di un link. Così, sanno esattamente dove andare. Per contrasto, le pagine Web seguono raramente gli standard di design e gli utenti non possono contare di trovare determinati link nello stesso punto in pagine completamente diverse. Ancora peggio, alcune pagine Web potrebbero non avere affatto un link, rendendo così inutile ogni tentativo di ricerca dello stesso all’interno di una pagina.

Di regola, per il design di un’interfaccia utente, il riconoscimento è migliore del ricordo, dato che è più semplice riconoscere qualcosa piuttosto che ricordarne e costruirne una descrizione. Nel caso dei clic ripetuti sul pulsante Indietro, gli utenti devono semplicemente dare una rapida occhiata a ogni pagina mentre si carica (velocemente dalla cache, dato che è stata appena visitata), e se non è quella desiderata, premono di nuovo il pulsante Indietro. Al contrario, utilizzando un link di navigazione diretto, gli utenti devono prima ricordare e ricostruire un’idea del sito a cui vogliono tornare, poi analizzare la pagina attuale per verificare la presenza di eventuali link che si avvicinino a quell’idea. È uno sforzo intellettivo maggiore, in senso relativo, e in più porta una maggiore probabilità di errore — sia perché può non esservi affatto tale link, sia perché l’utente sbaglia a interpretare un certo link e viene portato a una destinazione diversa.

Infine, dato che il pulsante Indietro è un elemento piuttosto grande su cui fare clic, è più rapido da utilizzare rispetto a un classico link di navigazione. Ciò rappresenta un grosso vantaggio per quegli utenti con disabilità motorie. […]

Insomma, non importa quel che accade durante la navigazione, il pulsante Indietro è sempre un’àncora di salvezza. Assumendo, ovviamente, che funzioni come dovrebbe. Purtroppo i siti Web possono impiegare svariati trucchi a livello di codice che disabilitano il pulsante Indietro e frustrano gravemente la libertà di movimento dell’utente.

La maniera più insidiosa di eliminare il pulsante Indietro è di farlo sparire dalla finestra del browser mediante un’istruzione JavaScript. […] Anche fare clic su un link che apre una nuova finestra del browser è un modo per compromettere la funzionalità del pulsante Indietro, poiché in genere la nuova finestra non eredita la cronologia della finestra originaria. Far aprire agli utenti nuove finestre del browser non richieste è un errore puro e semplice (come vedremo nella prossima sezione), e questa è solo una delle tante ragioni per non ricorrere a tale tecnica.

Inoltre il pulsante Indietro può essere compromesso attraverso l’uso di reindirizzamenti incorporati all’interno di una pagina Web invece di essere comunicati dietro le quinte via server. Se una pagina Web ha cambiato posizione o indirizzo, è certamente un’ottima idea lasciare un’istruzione di reindirizzamento per evitare link ‘spezzati’. Ma tale istruzione dovrebbe essere implementata come risposta HTTP 301 o 302 da parte del server Web, poiché questi codici dicono al browser di andare immediatamente al nuovo URL e dimenticarsi del vecchio. […]

Purtroppo alcuni siti Web implementano il reindirizzamento disponendo un’istruzione di refresh come meta-tag nella vecchia pagina; in questo modo la vecchia pagina viene sostituita immediatamente dalla nuova, e quando gli utenti cercano di tornare al sito o alla pagina precedente, il primo clic sul pulsante Indietro li riporterà sulla vecchia pagina in cui è stato incorporato il codice di refresh. Come si può prevedere, il caricamento di tale pagina innesca le istruzioni di inoltro, e l’utente viene subito rimbalzato alla nuova pagina… che è proprio quella che l’utente voleva abbandonare! Ogni ulteriore clic sul pulsante indietro avrà il medesimo effetto, e quindi l’utente si trova ‘intrappolato’ nella nuova pagina.

Nei nostri test abbiamo notato parecchia confusione ogni qual volta il pulsante Indietro viene disabilitato o non funziona come previsto […] e ciò continua tuttora a provocare seri problemi di usabilità. […]

3. L’apertura di nuove finestre del browser

[…] Purtroppo molti Web designer insistono nel visualizzare nuove informazioni in una nuova finestra del browser invece di riutilizzare quella esistente. A volte si tratta di piccole finestre pop-up (vedi il prossimo punto). […] Altre volte viene mostrata una nuova pagina a piena grandezza.

I designer spesso ci dicono che l’apertura di nuove finestre serve a non far perdere visite ai loro siti. Per questo motivo, le nuove finestre vengono solitamente aperte quando si effettuano collegamenti a materiali su altri siti. Ma alla fine il voler ‘intrappolare’ gli utenti nel proprio sito è una causa persa. Se la gente se ne vuole andare, se ne andrà comunque. E se gli utenti seguono un link verso un altro sito e poi vogliono tornare al nostro, lo faranno invariabilmente premendo il pulsante Indietro, dato che è il modo più semplice e diffuso di tornare a visitare un sito.

[…] Riassumendo, l’apertura di una nuova finestra del browser presenta i seguenti inconvenienti:

Altera l’esperienza che l’utente si aspetta

Inquina lo schermo dell’utente creando una serie di elementi non richiesti e sgraditi (a volte provocando crash o errori di memoria del computer)

Ostacola la possibilità da parte dell’utente di tornare ai siti precedentemente visitati

Nasconde in tutto o in parte la finestra in cui l’utente sta attualmente lavorando

Può far credere agli utenti che i link siano inattivi, perché sembrano non avere alcun effetto, mentre in realtà l’informazione viene fornita in una finestra nascosta

[…]

Per quanto riguarda quest’ultimo aspetto, nel mio blog ammetto di aver quasi sempre proposto link che aprono nuove finestre nel vostro browser. L’ho fatto in buona fede perché nella maggior parte dei casi il testo a cui rimandavo era l’originale della fonte che citavo, e poteva essere utile avere due finestre aperte per fare confronti e integrazioni. Ma le obiezioni di Nielsen e Loranger sono sensate e io cerco sempre di aver ben presente le questioni di usabilità. Quindi d’ora in poi sarò più rispettoso del pulsante Indietro con i miei link!

[Fine Prima parte]

Al ridimensionamento serve una ridimensionata

November 14, 2008

by Riccardo Mori

Mele e appunti

Una delle cose che chiedo a Snow Leopard, la prossima versione di Mac OS X, è di sistemare un aspetto forse piccolo e trascurabile, ma che a me dà un fastidio inconcepibile: il ridimensionamento delle finestre. È una seccatura che ho sempre sopportato in silenzio, ma oggi ho voglia di sfogarmi un po’.

Il problema appare in tutta la sua grandezza quando si utilizzano due schermi differenti per lavorare, o quando si passa da una risoluzione all’altra. Cerco di spiegarmi. La mia macchina principale è un PowerBook con schermo da 12 pollici (e risoluzione 1024 x 768). Quando sono a casa, uso il PowerBook in modalità scrivania, collegato a un monitor da 20 pollici (e risoluzione 1680 x 1050). Quando sono fuori, ritorno sul piccolo schermo. Ora, in genere i programmi che tengo aperti sono Mail, Mailsmith, Safari, Camino, Skim, Anteprima, TextWrangler, a volte iTunes, eccetera. Lascio sempre tutti questi programmi con la finestra principale espansa al massimo, in modo da poter sfruttare tutto lo schermo. Quando torno a casa e collego il PowerBook al monitor da 20 pollici, il sistema riconosce correttamente il monitor più grande come schermo principale (Dock e barra dei menu passano dal piccolo 12 al grande 20); le finestre delle applicazioni no, rimangono tutte ammucchiate sullo schermo piccolo. Se apro una qualsiasi nuova finestra in Safari o Camino, si apre sullo schermo piccolo. Se chiudo tutte le applicazioni prima di collegare il portatile al monitor esterno, e le apro dopo essere passato sullo schermo grande, le applicazioni si aprono in quello piccolo. O meglio, le finestre delle applicazioni, perché la barra dei menu, come ho detto, viene correttamente trasferita al monitor grande.

Uno che fa, dunque? Trascina la finestra del programma dallo schermo piccolo al grande, e preme il pulsantino verde nell’angolo in alto a sinistra della finestra. Il pulsante verde serve a ridimensionare la finestra ed equivale al comando Finestra > Ridimensiona dell’applicazione (Window > Zoom se il programma non parla italiano). E qui il comportamento varia da programma a programma, e che siano applicazioni di Apple o di terze parti la morale è sempre quella: ognuna fa come cavolo le pare ma quasi nessuna ridimensiona la finestra correttamente, cioè a tutto schermo. Mail lo fa; Safari allunga la finestra in verticale fino a sfiorare il Dock, ma non c’è mezzo di estenderla in orizzontale se non trascinando manualmente e cercando di essere precisi altrimenti una piccola parte della finestra finisce nello schermo più piccolo. Camino tende a fare il contrario, cerca di espandersi orizzontalmente, ma occorre sempre agire a manina per riportare la finestra al massimo delle dimensioni. Mailsmith fa come Safari, in più ogni volta devo regolare di nuovo l’altezza del separatore che divide l’area dell’elenco messaggi in alto dall’area del messaggio in basso. iTunes è un disastro perché non ha un comando di ridimensionamento automatico: pigi il pulsantino verde e lui si rimpicciolisce nella versione mini-player.

La situazione è analoga quando cambio la risoluzione del monitor più grande. Non chiedetemi perché, ma con le ultime versioni di VLC non posso vedere filmati a pieno schermo con la risoluzione massima del monitor (1680 x 1050), devo prima scendere a 1360 x 768 e poi andare a pieno schermo con VLC. Se prima di fare questa operazione mi dimentico applicazioni aperte con finestre a tutto schermo… avete indovinato, ritornando alla risoluzione massima le finestre vanno di nuovo ridimensionate perché sono rimaste alla risoluzione precedente. Devo avere l’accortezza di minimizzarle nel Dock o di nascondere le applicazioni prima di usare VLC. Così facendo, tutto poi torna a posto automaticamente.

Saranno sciocchezze, ma quel che mi fa arrabbiare è l’assenza di logica. Quando si presenta la situazione contraria — dal monitor grande passo allo schermo piccolo — le finestre rimangono dimensionate sulla maggiore risoluzione, ma premendo il pulsantino verde, Mac OS X ridimensiona la finestra correttamente e la adatta al monitor da 12 pollici. Nello scenario inverso è come se il sistema operativo non sapesse bene a quale dimensione impostare la finestra, è come se non conoscesse la risoluzione del monitor esterno. Però certe applicazioni come Mail ridimensionano in maniera corretta, vallo a capire.

Estendere una finestra alle massime dimensioni disponibili sullo schermo principale dovrebbe essere il compito di quel pulsantino verde, e del comando da menu associato, Ridimensiona. E dovrebbe essere un’operazione semplice e automatizzata, invece non lo è. Peraltro il problema (vado a memoria) si presentava anche con Mac OS 9, ma se non ricordo male lì c’era un briciolo di logica: molte finestre venivano ingrandite quasi totalmente, lasciando visibile la fila di icone da sempre all’estrema destra sulle scrivanie dei Macintosh: quelle dei dischi rigidi, dei media rimovibili, del Cestino. In Mac OS X tutto sembra più casuale e disordinato. È così difficile da risolvere, o mi sfugge qualcosa? (Sì, ho già lasciato un paio di feedback ai tempi di Tiger e un paio da quando esiste Leopard).

Avventure vintage

November 12, 2008

by Riccardo Mori

Mele e appunti

È da lunedì che sto ristrutturando la mia rete domestica di Mac. Ho voluto apportare qualche miglioria, ma sono capitati alcuni incidenti di percorso che hanno creato un ‘effetto valanga’, facendomi tornare ai tempi della risoluzione dei problemi con il Mac OS classico. Amo i vecchi Mac e mi piace farli funzionare — ho persino un blog sull’argomento, System Folder — però una cosa va detta: nell’èra pre-OS X il processo di risoluzione dei problemi quando tutto va storto può diventare presto un piccolo incubo, e i tempi necessari per isolare la causa dell’inghippo e risolverla possono essere insopportabilmente lunghi. Questo per rinfrescare la memoria a quei pochi rimasti che “con Mac OS 9 si stava meglio”.

Il tutto inizia in maniera semplice, perfino banale. Nella mia rete domestica l’anello di congiunzione fra i Mac più recenti e i Mac vintage è sempre stato un Quadra 950. A volte un PowerBook 5300, ma solo temporaneamente. Voglio che sia una macchina versatile e espandibile, e il Quadra 950 sembra fatto apposta, visto che è possibile infilarci fino a un massimo di cinque dischi rigidi. Con la sua bella scheda Ethernet, è il ponte ideale fra i PowerBook moderni e la rete LocalTalk su cavo seriale su cui si affacciano il Colour Classic, il PowerBook Duo 280c e occasionalmente un Macintosh SE.

Il Quadra 950 ha fatto il suo onesto lavoro finora, ma avendo un PowerMac 9500 dotato di più potenza processore (un PowerPC a 133 MHz contro un Motorola 68040 a 33 MHz), e più RAM (272 MB contro 28), nonché di un’unità CD-ROM e di una scheda USB, ho pensato di mettere il PowerMac 9500 a fare il lavoro del Quadra. La ragione per cui non l’ho fatto prima è che il Quadra se ne stava collegato con il suo bel Macintosh Color Display CRT da 14″ (che pesa svariati quintali) la tastiera e tutto quanto. Dovendo liberare spazio e togliere quindi monitor, tastiera, mouse, ecc., ho pensato di utilizzare il Quadra ‘senza testa’, pilotandolo dal PowerBook G4 in remoto con un client VNC. Ma per questo il candidato migliore è il PowerMac 9500: oltre ai vantaggi citati, sul 9500 gira Mac OS 9.1, ed è sufficiente installare Vine Server per OS 9 (prima si chiamava OS9vnc) per essere felici.

La migrazione è avvenuta rapidamente, la configurazione del PowerMac fatta in pochi minuti, e tutto funzionava. All’avvio, il PowerMac attivava automaticamente AppleTalk sulla porta Ethernet e la condivisione documenti. Vine Server si avviava da solo (basta metterlo in Cartella Sistema > Avvia Con). Sul PowerBook G4 aprivo Condivisione Schermo, inserivo manualmente l’IP del PowerMac 9500 e in pochi istanti appariva una finestra con la scrivania del PowerMac.

Quattro ore dopo, l’inizio della fine: il disco interno SCSI da 8 GB con l’installazione di Mac OS 9 e alcune cartelle di backup ha smesso di funzionare, così, senza nemmeno un rantolo meccanico. Ogni tentativo di aprire file o cartelle mi dava errore (elemento non trovato) e riavviando il Mac non vedeva più il disco. Ho cercato quindi di riavviare dall’altro disco interno da 500 MB, sul quale però non c’era installato nessun sistema utile a far partire un PowerMac 9500, solo la versione ridotta all’osso del System 7.1 contenuta in A/UX.

Scollego tutto, apro il PowerMac, tolgo il disco guasto e, già che ci sono, provo a metterne un altro. Cerco negli scatoloni del vecchio hardware e trovo un Quantum Fireball da 1,3 GB che in una vita passata era il disco di avvio del fu Quadra 700. Lo collego e riavvio il PowerMac 9500. Si riavvia proprio da quel disco che contiene un’installazione di Mac OS 8.1. L’idea era quella di inserire il CD di Mac OS 9.1 e aggiornare l’8.1 ma — sorpresa — il Mac non vede il CD. Non sto a raccontare tutto, ma dirò che dopo una serie di ricerche ho scoperto che per vedere quel CD era necessario avere l’estensione Apple CD-ROM aggiornata… di Mac OS 9. Non era nemmeno possibile avviare direttamente da CD tenendo premuto il tasto C all’avvio. E mi trovavo in un circolo vizioso.

Ma non finisce qui. A complicare le cose, dopo uno dei tanti riavvii, muore anche il disco da 1,3 GB appena riesumato (o quantomeno si blocca in un loop in cui si sente ripetuto un rumore come ‘tri-tric tri-tric’). Morale: non importa se si è in un momento di ispirazione letteraria — mai chiamare una coppia di dischi rigidi “Rosencrantz” e “Guildenstern”.

Il lavoro a questo punto si complica, perché l’ultimo superstite è anche purtroppo il disco meno capiente, solo 500 MB di cui 180 liberi. Il lettore CD del PowerMac non vede il CD-ROM di Mac OS 9.1, quindi una possibilità è quella di estrarre il disco, inserirlo in un guscio esterno SCSI e collegarlo al PowerBook 5300. Quest’ultimo, connesso al PowerBook G4 Titanium via Ethernet, può vedere i dischi del Titanium e montarli sulla scrivania. Inserisco quindi il CD di Mac OS 9.1 nell’unità ottica del Titanium, lo monto sulla scrivania del PowerBook 5300 e da lì faccio partire l’Installer di OS 9.1 specificando un’installazione di base sul disco rigido da 500 MB del PowerMac 9500, diventato temporaneamente unità esterna. Arrivato a circa 60% del processo, l’installazione fallisce perché non riesce a estrarre dei file dall’Archivio Compresso dell’Installer di OS 9.1. Subito dopo, anche la connessione Ethernet con il Titanium cade improvvisamente.

Comincio a pensare che forse è il CD di OS 9.1 a non andare tanto bene. Il piano B è presto messo in atto: riattivo la connessione Ethernet fra il Titanium e il PowerBook 5300, e copio brutalmente la Cartella Sistema presente sul CD di OS 9.1, che è una configurazione minima per poter fare il boot da CD. Il piano prevede di reinserire il disco rigido nel PowerMac 9500, riavviare il PowerMac usando la Cartella Sistema minima copiata nel disco rigido, e finalmente inserire il CD di OS 9.1 nel lettore del PowerMac (che ora verrà riconosciuto) e fare una installazione completa di Mac OS 9.1.

L’installazione fallisce due volte: la prima per un non ben definito errore di copia; la seconda perché, arrivato in fondo, non c’è più spazio su disco (oggi con tutti i giga di cui disponiamo ci siamo dimenticati dell’errore “Disco pieno”!). Ora però, grazie alla Cartella Sistema 9.1 minima, la porta Ethernet del PowerMac viene riconosciuta nel pannello AppleTalk (nella precedente installazione di Mac OS 8.1 avevo tolto le estensioni per la Ethernet, dato che sul Quadra 700 la Ethernet era di tipo AAUI e non 10Base‑T, è per questo che ho dovuto espiantare il disco e collegarlo al Titanium usando il PowerBook 5300 come tramite), quindi posso riprovare l’installazione mettendo il CD di OS 9.1 nel Titanium e montandolo sulla scrivania del PowerMac 9500. Riprovo l’installazione e durante il processo la linea fra i due Mac cade. L’ultima spiaggia prima di cedere le armi è installare Mac OS 9.1 su un disco esterno FireWire collegato al Titanium, montare quel disco sulla scrivania del PowerMac 9500 (sempre connesso al Titanium via Ethernet) e copiare la Cartella Sistema — ora davvero completa — dal disco FireWire al disco interno del 9500. Stavolta tutto fila liscio.

Scollego tutto e riavvio il PowerMac 9500. Il sistema si carica, ma è sospettosamente lento. Dodici minuti dall’icona del Mac sorridente alla scrivania sono troppi. (Nota a margine: i tempi di avvio dei Mac con OS 9 e precedenti sono sempre più veloci di qualsiasi installazione di Mac OS X. Il vecchio Quadra 950 con System 7.5.3 si avvia in 40 secondi. Il PowerMac 9500 prima del disastro si avviava in poco più di un minuto, con Mac OS 9.1). Avviando con le estensioni disabilitate tutto è a posto e il PowerMac è molto reattivo, quasi più di prima. Il problema è evidentemente una o più estensioni, o anche un conflitto fra esse. Può essere che non installando Mac OS 9.1 direttamente sul PowerMac ma usando un’installazione fatta da un PowerBook Titanium, siano state aggiunte componenti che mandano il PowerMac in rigetto. La caccia all’estensione maledetta, in pieno stile pre-Mac OS X, ha inizio ora, e se l’argomento intrattiene e diverte, farò sapere come va.

So che la prima reazione, leggendo questa avventura, è quella di pensare che io abbia molto tempo libero, e che non abbia niente di meglio da fare. In realtà ci ho dedicato un paio di mattine. Mi sono ritrovato con un po’ di tempo libero e ho voluto più che altro divertirmi. Il bello di questi pasticci è il non demordere e vedere chi la spunta. Il bello è riuscire nell’impresa e avere una rete diversificata ed efficiente, con il PowerMac che si fa carico di montare i dischi dei Mac d’antan e di permettermi di accedere a tutti i miei archivi da un’unica posizione. Ma se eliminiamo la componente ‘ludica’ dell’impresa e la analizziamo seriamente e da un punto di vista produttivo, allora ci accorgiamo di come la vita con Mac OS X sia molto, ma molto più facile.

WPA: craccato ma non troppo

November 11, 2008

by Riccardo Mori

Mele e appunti

Battered, but not broken: understanding the WPA crack: Un bell’articolo di Glenn Fleishman, che spiega in dettaglio la vulnerabilità del protocollo WPA che è stata scoperta di recente:

Ricercatori universitari hanno trovato una vulnerabilità sfruttabile in una forma molto diffusa di crittografia delle reti wireless. La falla è in una parte del protocollo 802.11i che forma la base del WPA (WiFi Protected Access), e quindi potrebbe colpire i router di mezzo mondo. Questa settimana il laureato tedesco Erik Tews presenterà uno studio al PacSec di Tokyo scritto insieme a Martin Beck, collega e membro del team aircrack-ng, che rivela come i resti del predecessore di WPA abbiano permesso ai due studenti di ‘infilare il coltello’ in una crepa dello schema crittografico e inviare dati fasulli a un ignaro client WiFi.

L’articolo prosegue delineando una storia delle vulnerabilità in ambito wireless, poi entra nei dettagli della falla recentemente scoperta. Riporto la parte finale dell’articolo, che serve da riassunto ed è scritta in un linguaggio un po’ più comprensibile anche al profano.

[…] Le prime notizie riguardanti questo crack affermavano che le chiavi TKIP erano state compromesse. Non è così. “Abbiamo un solo keystream; non ricuperiamo le chiavi utilizzate per la criptatura nel generare il keystream”, ha detto Tews.

In breve, l’attacco consiste in un metodo per intercettare pacchetti corti in reti provviste di dispositivi che utilizzano TKIP, decodificarli, criptarli nuovamente e in maniera arbitraria, per poi reinserirli nella rete. È una distinzione cruciale: si tratta di un attacco serio, e della prima vera vulnerabilità di TKIP scoperta finora e sfruttata. Ma è sempre un sottoinsieme di un vero key crack.

Tews ha fatto notare che “se utilizzate delle funzioni di sicurezza per impedire ad altri di utilizzare la vostra banda, siete assolutamente al sicuro” — è il caso di molti utenti domestici. Non è possibile servirsi di questo attacco per penetrare in una rete domestica o aziendale. né per decifrare tutti i dati passanti.

Se una rete utilizza AES, è immune da questo attacco, e molte reti aziendali e ad alta sicurezza sono passate ad AES quando è stato possibile un paio di anni fa, in modo da evitare eventuali problemi con TKIP che avrebbero potuto presentarsi in futuro.

L’attacco dovrebbe essere meno efficace anche in quei casi in cui in una rete, un punto di accesso viene impostato per effettuare un rekey a intervalli regolari [cioè per rigenerare le chiavi]. Non è chiaro se tale regolazione sia disponibile per i punti di accesso aziendali e se gli amministratori di rete debbano già mettersi al lavoro per impostarla.

Tews ha dichiarato inoltre che una rete con molto traffico potrebbe contrastare l’attacco; non è sicuro se certi access point rigenerano le chiavi dopo il passaggio di una certa quantità di traffico. “Parecchio traffico non farà bene all’attacco, perché le chiavi saranno rigenerate più velocemente”, ha aggiunto.

Secondo Tews, le basi della sicurezza di rete sono ancora valide: una protezione WPA con TKIP o AES, con una chiave di rete lunga, magari composta da 20 caratteri piuttosto casuali, può contrastare tutti i metodi di cracking a forza bruta delle chiavi.

Per cui pare che, alla fine, il WPA è meno compromesso di quel che sembri, e TKIP rimane sostanzialmente intatto. Ma questo exploit basato sull’integrità e i checksum dovrebbe spingere verso una rapida migrazione a reti WiFi solo AES per quelle aziende che vogliono mettersi al riparo da ulteriori ricerche in questo ambito, ricerche che Tews e Beck stanno già pianificando. E ora che i due studenti hanno aperto la porta, WPA verrà di certo studiato più attentamente da molti altri individui, buoni e cattivi.

Mostruosamente ovvio

November 10, 2008

by Riccardo Mori

Mele e appunti

Oggi sono impegnato nella manutenzione hardware e nella profonda riorganizzazione della mia rete domestica, per cui mi tocca essere breve. Su MacOSXHints.com hanno pubblicato un suggerimento così ovvio… che non ci avevo pensato. In iPhone e iPod touch il Blocco Maiuscole è disabilitato per default, ed è attivabile andando alla sezione Tastiera delle preferenze Generali. Io (e penso di non essere il solo) preferisco tenerlo disabilitato, e quando mi capita di scrivere tutto maiuscolo (acronimi, in genere), premo il tasto Maiuscolo sulla tastiera, batto la prima lettera, premo Maiuscolo ancora, batto la seconda lettera, e così via. Dato che la frequenza con cui devo scrivere parole tutte maiuscole è bassa, il fatto di inserire le lettere nel modo descritto non mi pesa e lo faccio piuttosto velocemente.

Ma il suggerimento in questione fa notare che basta tenere premuto il tasto Maiuscole e battere sui tasti per avere un Blocco Maiuscole temporaneo. Sulla tastiera del Mac è un gesto spontaneo e ormai automatico, con iPhone neanche mi era venuto in mente. Eppure la tecnologia non si chiama multi-touch per caso… Un altro elemento su cui riflettere quando si parla di progettazione di interfacce utente.