E’ qualche tempo che mi sono messo ad osservare la sequenza di azioni che faccio quando torno a casa per aprire le varie porte. Essenzialmente la sequenza principale è:

1. Arrivo al cancello A
2. Prendo il mazzo di chiavi
3. Seleziono la chiave A
4. Apro A
5. Arrivo alla porta B
6. Seleziono la chiave B
7. Apro B

Questo funziona perfettamente se le porte sono entrambe chiuse. La cosa interessante – ciò mi ha fatto riflettere – è invece legata alle situazioni miste, ovvero quando per qualche motivo una delle porte è aperta. In particolare quella esterna.

Il motivo è che quando il cancello A è aperto mi sono accorto che nell’abitudine delle azioni mi trovavo in mano la chiave A davanti alla porta B, anche se era scorretta.

Per cercare di capire cosa succedeva nella mia testa ho provato a selezionare coscientemente la chiave per la porta interna, con svariati processi mentali. Il risultato però non è stato molto soddisfacente: comunque fosse, mi trovavo abbastanza spesso a tentare di aprire la porta B con la chiave A anche se coscientemente mi ero detto di non farlo. L’abitudine è più forte, a meno di prestarci davvero attenzione.

Capendo quindi che non stavo interpretando qualcosa in modo corretto mi sono messo ad osservarmi meglio anche nelle situazioni normali (entrambe le porte chiuse) ed ho notato che la sequenza non è proprio quella che ho scritto sopra, quella logicamente più intuitiva, ma:

1. Arrivo al cancello A
2. Prendo il mazzo di chiavi
3. Seleziono la chiave A
4. Apro A
5. Seleziono la chiave B
6. Arrivo alla porta B
7. Apro B

Ecco! La differenza è sostanziale: nella sequenza di azioni mentali, il passo “Seleziono la chiave B” non si è legata all’azione “Arrivo alla porta B” bensì all’istante successivo ad “Apro A”.

Il risultato è che l’insieme di azioni automatiche è raggruppato in questo modo:

1. Catena di operazioni cancello A, scatenata dal raggiungere il cancello A:
   prendo il mazzo di chiavi -> seleziono la chiave A -> apro A -> seleziono la chiave B
2. Catena di operazioni porta B, scatenata dal raggiungere la porta B:
   arrivo alla porta -> apro

Questo significa che ci sono due soli eventi che scatenano sequenze di azioni: il cancello A e la porta B. Fin qui è intuitivo.

Quello che succede è che la selezione della chiave io la faccio in conclusione della prima sequenza: già che ho il mazzo di chiavi in mano e lo sto manipolando, mi è più facile già selezionare la chiave successiva (prossimità di azione).

Cosa succede quindi quando la sequenza viene interrotta, trovando il cancello A aperto? Che non devo più eseguire l’azione “Apro A” e quindi non si scatena l’azione successiva, ovvero “Seleziono la chiave B”. Così, arrivo alla porta B e cerco di aprirla con la chiave che ho in mano: A. Quella sbagliata.

Eseguendo questa operazione  tutti i giorni almeno una volta al giorno per anni, è chiaro come lo sforzo mentale necessario deve contrastare una abitudine ben radicata nella quale l’azione è associata ad un evento precedente.

Faccio questo esempio perché lo trovo un esempio molto rilevante di alcuni processi:

• Le abitudini sono sequenze di azioni apprese che consentono alla nostra mente di lavorare in parallelo: mentre eseguo una operazione abitudinaria la mia mente è sostanzialmente libera di pensare ad altro.
• Il comportamento abitudinario è legato ad un evento trigger scatenante (”Arrivo al cancello A”) che è seguito da una serie di (re)azioni concatenate in una sequenza precisa.
• L’abitudine spesso è legata strettamente con il stare pensando ad altro: non si è presenti nel qui-e-adesso (hic-et-nunc) ma si sta usando il pilota automatico mentre si è altrove. Se si fosse presenti non si commetterebbe l’errore, ma non si potrebbe neppure pensare ad altro. Correggere un errore dettato da un cambiamento delle situazioni esterne implica la presa di coscienza del qui-e-adesso e quindi ad un ritorno del pensiero e all’abbandono dell’automatismo.
• Il raggruppamento della sequenza di azioni a partire da un trigger è dettato da criteri di semplicità, prossimità (sia fisica che mentale).
• Le abitudini, le azioni, i trigger vengono tutti selezionati e applicati in modo automatico dalla nostra mente se le condizioni esterne sono stabili e consentono quindi una efficace ripetizione automatica.

Inutile forse notarlo, ma strutturare le nostre azioni per permettere agli automatismi di presentarsi quando utile è una prassi che permette di risparmiare molto tempo: se quando tornate a casa lasciate sempre il portafogli in una precisa posizione, gli occhiali in un’altra e non variate mai tali posizioni succederanno due cose:

1. Si svilupperanno due automatismi: uno quando tornate a casa, uno quando uscite. Il primo vi permetterà senza sforzo di rimettere gli oggetti in quelle posizioni e il secondo di non dimenticare nulla quando uscite.
2. Se si forma un errore o una interruzione in una di queste sequenze ve ne accorgerete, notandolo subito o sentendo una leggera forma di disagio.

Egualmente, sarebbe da evitare il generarsi di automatismi quando non volete: se quando suona la sveglia al mattino la spegnete e tornate a letto… e lo rifate per più giorni, alla fine si formerà un automatismo. E avrete sempre problemi a svegliarvi. Provate invece a saltare subito giù dal letto…

I documenti “Design Motivazionale” ed “Elementi Teorici per la Progettazione dei Social Network” sono stati fusi in un unico documento. In questo modo il percorso di lettura è più completo, partendo dalle basi ed arrivando all’analisi e progettazione.

Il nuovo documento è “Motivational Design: una metodologia per il social network design“, sempre per mano mia e di Gianandrea Giacoma.

In questa nuova versione non ci siamo ovviamente limitati a fare una semplice fusione dei due testi, ma abbiamo anche chiarito alcuni passaggi più complessi, questo grazie a tutti i commenti e le critiche costruttive che abbiamo ricevuto in questi mesi. In più, abbiamo anche arricchito i primi due capitoli con un bel numero di esempi.

Il documento come sempre è scaricabile liberamente e pubblicato sotto licenza Creative Commons by-sa 2.5 (ita):

• Scarica Motivational Design in PDF da qui (748Kb).
• Guarda Motivational Design su Scribd.
• Leggi il post di Motivational Design 1.5 sul blog di Gianandrea.

Per il futuro sappiate che c’è una versione successiva già in cantiere – ci sono ancora delle parti che vogliamo chiarire e alcune rifiniture da fare – e anche alcune sintesi: ci rendiamo conto che un testo di oltre 70 pagine non è affrontabile alla leggera.

Se avete commenti, critiche o curiosità segnalatecele pure, come sempre avete fatto, grazie!

1. Parte 1
2. Parte 2
3. Parte 3

Nella presentazione sono evidenziati i quattro elementi chiave (Functional Needs, Social Usability, Relational Motivations, Circadian Activity Flow), con anche un buon numero di esempi. Se ci fossero dubbi potete naturalmente leggere il paper, in italiano, oppure fare domande sotto: ci sono delle parti che sono molto criptiche e che ovviamente necessiterebbero la presenza di un supporto vocale.

The Master in the art of living
makes little distinction between his work and his play,
his labor and his leisure,
his mind and his body,
his education and his recreation,
his love and his religion.

He hardly knows which is which.

He simply pursues his vision of excellence
in whatever he does,
leaving others to decide whether he is working or playing.
To him he is always doing both.
— Lawrence Pearsall Jacks (1932) Education through Recreation

Il tema è quello del Design Motivazionale. Visti gli obbiettivi della conferenza abbiamo deciso di tenere un approccio un poco più divulgativo, cercando di spiegare gli elementi centrali della nostra metodologia (bisogni funzionali, usabilità sociale, motivazione relazionale, flusso di attività circadiano) in modo da portare avanti il difficile tema della divulgazione umanistica in ambito IT e porre allo stesso tempo una serie di elementi utili e concreti per chiunque sviluppi o progetti oggetti con elementi dotati di interattività sociale.

A riguardo del nostro intervento siamo anche stati contattati dal gentile Maurizio Boscarol di Usabile.it, che ha pubblicato una intervista proprio su come il nostro metodo si applica alle attuali prassi di design… più qualche domanda interessante sulla disciplina e sugli sviluppi futuri.
In alcuni passaggi sono stato forse un po’ eccessivo per motivi retorici, fatemi nel caso sapere.

1. Ziv’s law: specifications will never be fully understood.
2. Humphrey’s law: the user will never know what they want until after the system is in production (maybe not even then)
3. Wegner’s lemma: an interactive system can never be fully specified nor can it ever be fully tested. This is the software analogy to Godel’s theorem.
4. Langdon’s lemma: software evolves more rapidly as it approaches chaotic regions (taking care not to spill over into chaos)

Queste sembrano prese da un post iniziale di Sutherland (o da una mailing list, entrambi del 2007), uno dei firmatari dell’Agile Manifesto, ma non sembra possibile capire chi siano Ziv, Humphrey, Wegner e Langdon a cui le leggi fanno riferimento. Qualcuno ne sa di più?

Così ho dato un altro paio di martellate allo script in PHP che avevo fatto e ho pubblicato: Check if Google gets different data.

Ci sarebbero ancora un po’ di finiture da aggiungere, ma non credo sia un oggetto così utile da richiedere un eccessivo lavoro. Però già così potrebbe essere interessante, quindi insomma… fatemi sapere.

Grazie a Sara Rosso per il check sull’inglese.

1. Hanno sparso per i filesystem dei file con nomi “simili” a quelli esistenti (xml.php, stream.php, …) che però avrebbero consentito l’upload e la modifica remota dei file da parte di chiunque avesse un cookie specifico (gli script sono c99 e r57shell).
2. Hanno editato alcuni file aggiungendo link di spam nei template (curiosamente, anche file di codice mio completamente custom, son andati a cercarsi il template).
3. Hanno editato wp-settings.php delle installazioni di WordPress (indipendentemente dalla versione presente) con un codice eval() scritto oltre il normale spazio visivo di un editor testuale (per intenderci, una riga che inizia con molti spazi). L’eval in questione iniettava un redirect 301 (permanent) verso un sito solo per i crawler dei motori di ricerca.
4. Hanno editato .htaccess delle installazioni di WordPress aggiungendo molte righe vuote ed in fondo un altro redirect analogo al precedente: solo per i crawler (redirect su bablo.me.uk).

Mi sono accorto della penetrazione un paio di giorni fa, a causa di un netto calo delle visite (sceso circa dell’80%). Visite che prima arrivavano sostanzialmente da Google. Ero sparito dalle classifiche su Google (folletto, intense minimalism, davide casali solitamente mi trovavano in prima pagina), pur rimanendo nell’indice. Ho aperto un topic sull’assistenza di Google Webmaster Tools (e ricevuto i consigli in privato di un paio di persone, grazie) e un googler alla fine mi ha segnalato la discrepanza: Googlebot vedeva un redirect 301 verso un altro sito.

Un hack piuttosto furbo.

Per verificare questa situazione potete usare dei siti (1, 2; specificando “Googlebot”) oppure un comando da linea di comando Mac o Linux (curl):

curl --user-agent "Googlebot" http://im.digitalhymn.com/

Provato se guardando solo Googlebot non risulta di suo evidente, basta provare anche con un user agent normale e poi con Googlebot in modo da notare le discrepanze.

I punti 3 e 4 che ho spiegato sopra son abbastanza bene delineati in questi due post che ho trovato mentre analizzavo i miei siti: “Exploit Redirects Googlebot to Malware Sites (Bablo me uk)” e “Did your WordPress site get hacked?“, piuttosto esaurienti.

Ecco cosa appariva come header (redirect 301) mentre i siti erano hackati:

HTTP/1.1 301 Moved Permanently
Date: Tue, 07 Apr 2009 15:35:49 GMT
Server: Apache/2.0.63 (Unix) PHP/4.4.7 mod_ssl/2.0.63 OpenSSL/0.9.7e
mod_fastcgi/2.4.2 Phusion_Passenger/2.0.6 DAV/2 SVN/1.4.2
Location: http://bablo.me.uk/
Vary: Accept-Encoding
Content-Length: 227
Content-Type: text/html; charset=iso-8859-1

Per trovare le modifiche ho fatto affidamento a due tools fin da subito: la data di modifica del file e SVN, con il quale installo quasi sempre le mie versioni di WordPress e simili.

La cosa curiosa in assoluto è stata però che la modifica ai file wp-settings.php non mi veniva segnalata da “svn status”. O mi è sfuggito qualcosa nelle varie verifiche che stavo facendo, oppure non so. Quando ho copiato in locale la cartella per fare ulteriori verifiche, TextMate invece ha trovato che il file era modificato.

Se qualcuno volesse visionare i files e il codice utilizzato per l’attacco e le modifiche ho salvato quasi tutto. Fatemi sapere (un commento con la mail è sufficiente).

Capitasse nuovamente, o capitasse a voi, ecco in sintesi le verifiche che ho fatto:

1. Verificare la modifica su GoogleBot (con curl, wget o analogo web).
2. Verificare la bash history se avete una login via SSH.
3. Verificare .htaccess, wp-config,php, wp-settings.php e i template (i file più frequentemente attaccati).
4. Utilizzare svn per verificare le modifiche fatte (svn status).
5. Utilizzare le date di modifica dei file per vedere se è stato modificato qualcosa (ls -la)
6. Verificare la differenza del codice rispetto ai backup.

Per quanto volendo si potrebbe semplicemente ripristinare la situazione da un backup, questi controlli permettono di capire con maggiore precisione cosa sia successo.

La domanda a questo punto è: da dove sono entrati?

Difficile dirlo. Questo blog ha l’ultima versione di WordPress installata. Di routine ho cambiato tutte le password adiacenti agli account che sono stati toccati, ma credo che l’attacco sia stato fatto tramite alcune vulnerabilità esistenti su xmlrpc.php di WordPress: sono stati sistemati sulle ultime versioni ma… avevo alcune versioni vecchie installate.

Qui nasce un dubbio: io quelle versioni di WordPress non posso aggiornarle, si riferiscono a vecchie edizioni e vorrei tenerle per motivi storici. Ho disattivato il disattivabile (fra cui un bel delete di xmlrpc.php) controllando alcune vulnerabilità segnalate, ma… come fare? Il problema è abbastanza rilevante: non è possibile aggiornare quelle versioni, perché utilizzano codice e componenti ad-hoc e aggiornarle equivarrebbe a rimuoverle. Qualcuno ha idee? Tutto quello che mi viene in mente richiederebbe una manutenzione abbastanza eccessiva (aggiornare tutto, fare un plugin di “lockdown”, staticizzare il sito, …).

1. Come libreria. Si può aggiungere a qualunque theme o plugin e si ottengono una serie di funzionalità addizionali: creazione di The Loops customizzati, iterazione semplificata sugli attachment, recupero dei term (tags o categories), creazione di pagine virtuali e alcune semplificazioni come una funzione per prelevare il contenuto di una pagina.
2. Come plugin. Aggiunto come plugin permette di inserire dei widget nella sidebar che sono in grado di visualizzare gli ultimi ‘n’ posts da una categoria specifica (e tutte le sotto-categorie). Funzionalità molto comoda per creare pagine ricche di contenuti (come homepages, dashboard o pagine di atterraggio intermedie).

Su questo blog ne ho già parlato qualche volta di questo plugin, infatti è una libreria che mi accompagna da tempo e sviluppo in parallelo ai miei progetti. Personalmente ne faccio un uso abbastanza intensivo e in questo modo ho una ottima riusabilità del codice, oltre ad una maggiore velocità nella realizzazione di template complessi (vedi ad esempio Good50×70 che ne fa uso dal 2007).

WordPress Portal è pubblicata, con documentazione ed esempi, sul mio sito parallelo di sviluppo Argilla. La libreria è un unico file, per semplificare aggiornamento e portabilità.

E’ pubblicata sotto licenza GPL, quindi potete farne l’uso che preferite. Ovviamente se avete feedback, integrazioni, patch o consigli, sono i benvenuti.

Ringrazio Alessandro Morandi e Roberto Ostinelli che sono stati i primi contributori e nel tempo hanno fornito vari suggerimenti e patch.