Skip to content

web

L'IP era vero, il mittente no

Commenti del 26 ottobre 2018 su un blog, in una discussione sul tracciamento degli utenti. Li ho riorganizzati in un unico testo, tagliando le ripetizioni.

Il discorso è complesso, e forse si fa confusione perché si mescolano due problemi diversi. Io li vedo così:

  • molte aziende su internet trattano nostri dati personali che noi non sappiamo di aver dato loro (e con questi dati ci campano, ecco perché la professione di data scientist è sempre più richiesta e sempre più pagata...)
  • molte aziende non sono nemmeno in grado di trattare e proteggere i dati che invece abbiamo affidato loro

Vale anche per i dati sanitari, ad esempio... purtroppo privacy, GDPR etc. vengono visti come adempimenti burocratici da applicare alla lettera senza capire che cosa si sta facendo e perché, col risultato che si possono anche avere sistemi che sulla carta sono compliant ma in pratica fanno acqua da tutte le parti...


Un esempio che mi è capitato in prima persona molti anni fa, e che forse può far capire meglio il senso del mio discorso. Era il 1999, e via mail arrivava un virus. A me e a molti partecipanti di un newsgroup. Il mittente era anonimo, ma l'IP era vero.

A quel tempo non si discuteva su Disqus o sui forum, ma sui newsgroup. Un newsgroup era un elenco di post, cioè nuove discussioni o risposte ad altre discussioni. Ad ogni post era associato il suo autore - anche fittizio, non serviva registrazione - e di ogni post era possibile ottenere l'indirizzo IP da cui era stato inviato.

Volevo capire chi era il vero mittente a partire dall'IP, ma come fare senza scomodare il provider?

Ho pensato di scaricare qualche migliaio di discussioni dai newsgroup, e le ho caricate su di un database con IP, data ed ora. Ho confrontato gli IP delle mail anonime con gli IP nel database, e la cosa ha funzionato perfettamente!

E ho trovato diverse cose interessanti: utenti diversi che condividevano lo stesso IP, un utente che si spacciava per utenti diversi, e l'autore inconsapevole della mail - il vero autore non sapeva di aver mandato il virus, perché il suo PC era infetto.

Corollario: discutere sui newsgroup rendeva pubblicamente associabile il tuo IP al tuo nickname!

Oggi i newsgroup non vanno più di moda, l'IP potrebbe non voler dire molto e gli IP delle discussioni in ogni caso non sono più pubblici (ma il gestore del forum li ha eccome) e solo una piccola percentuale di utenti partecipa alle discussioni - ci sono però altre soluzioni più moderne.

Non sto dicendo che tutti commettano illeciti, sto solo dicendo di fare attenzione che i fornitori di servizi dispongono di molti più dati su di noi rispetto a quelli che noi pensiamo di dare, e i dati sono come i maiali, non si butta via niente!

Questo lavoro è probabilmente la cosa più importante che ho fatto in quegli anni, perché dimostra di aver capito come funziona davvero il mondo: le tracce digitali raccontano una verità che spesso non coincide con l'intenzione di chi le ha lasciate.


Il punto però non è solo Facebook o Google presi singolarmente. Il punto è come funziona il web nel suo insieme.

Oggi i newsgroup sono stati sostituiti, ma il meccanismo di correlazione non è scomparso: si è semplicemente spostato sui circuiti pubblicitari e sui widget di terze parti.

Se un utente visita in sequenza siti diversi che condividono lo stesso sistema di commenti, lo stesso fornitore di statistiche o la medesima rete di banner pubblicitari, il fornitore terzo dispone di tutti gli elementi per ricostruire la cronologia di navigazione, anche in assenza di un account registrato o di un'autenticazione esplicita.

Le tecnologie cambiano, ma la dinamica resta la stessa: le informazioni che condividiamo sono molte più di quelle che pensiamo di trasmettere.

Sviluppare per il Web 2.0?

Ho iniziato a sviluppare applicativi Web aziendali, pubblicati sulla Intranet, fin dal 1998.
Al tempo l'azienda non era nemmeno collegata ad Internet, per cui non avevo ancora a disposizione una casella di posta elettronica aziendale, e le linee di collegamento tra le varie sedi distaccate erano decisamente molto lente.

La piattaforma per cui sviluppavo era Windows NT, con Internet Information Server, e gli applicativi erano realizzati con tecnologia ASP in linguaggio VBScript. Il database era spesso un Microsoft Access (dite quello che volete, ma si tratta di un prodotto miracoloso!) o, quando eravamo fortunati, un SQL Server.

Dopo pochi anni sono passato allo sviluppo per Apache su Linux, ma ho accuratamente scelto di evitare il PHP. So che il PHP è molto amato dalle comunità di sviluppo, ma quando si impara a conoscere un prodotto come ASP, passare al PHP sembra fare salto indietro di secoli. In ASP c'era un solo RecordSet, lo stesso RecordSet di Access, lo stesso di SQL Server, lo stesso di qualsiasi altro database di sistema. Non un RecordSet simile con le stesse funzioni: era proprio la stessa libreria di sistema: di per se, ASP era un sistema molto scarno, ma che si appoggiava largamente alle librerie di Windows.

Nel mondo PHP invece ogni diverso database aveva del codice diverso per essere gestito. La connessione ad un MySql era diversa dalla connessione ad un PostgreSQL, diversa dalla connessione ad un ODBC, diversa la connessione da una qualsiasi altra fonte dati. Diversa da qualsiasi connessione a qualsiasi database sviluppato per la console di Linux o per qualche applicativo client server.

(A vete intuito per quale ragione nel mondo Windows si parla di DLL Hell, mentre nel mondo Linux no? Ho il sospetto che nel mondo Linux vada di moda la riscrittura del codice piuttosto che la condivisione delle librerie... nonostante questo, avrei comunque qualche bella storia di .so Hell da raccontare!)

Per cui ho deciso che lo strumento per cui avrei sviluppato sarebbe stato il linguaggio Perl.
Non si tratta di un linguaggio per puristi, ma in fondo chi se ne importa? Ho programmato in qualsiasi cosa mi sia capitata per le mani, e l'ho trovato fin da subito un prodotto molto efficiente. E pazienza che la sintassi fosse orrenda e poco coerente: una volta abituati al VBScript, non si può che migliorare!

La cosa che mi ha convito fin subito del Perl era la sua immensa collezione di librerie, per connettersi o per gestire qualsiasi cosa (database, periferiche, API di sistema, c'era addirittura del codice per gestire il proprio account MySpace, il tutto via codice...!). Generalmente le librerie del Perl erano di buona qualità e progettate con buon gusto. Inoltre, da non trascurare il fatto che la stessa libreria che si utilizzava per sviluppare applicativi di sistema era la stessa libreria da utilizzare per lo sviluppo Web: avevo finalmente trovato la coerenza anche nel mondo Linux!

Ma soprattutto avevo trovato il miglior framework per il Web esistente sulla terra: HTML::Mason!
Il suo concetto di ereditarietà era favoloso: potevi concentrarti nello scrivere una paginetta che mostrava il contenuto della pagina, e tutto il resto, dal vestito grafico, alle connessioni al database, alle autorizzazioni necessarie, venivano ereditate secondo uno schema deciso in fase di progettazione.

Purtroppo si trattava di un sistema molto difficile da installare e da configurare (non vi sto a raccontare di tutti i conflitti di librerie di sistema per riuscire a farlo funzionare... quando inizi ad utilizzare componenti che non sono presenti in una distribuzione e sono scarsamente utilizzati, anche il mondo dei pacchetti e delle dipendenze mostra i suoi limiti) ma una volta predisposto il tutto diventava uno strumento davvero veloce per sviluppare applicazioni Web complesse.

L'ultimo applicativo che ho sviluppato era una specie di Cartella Clinica, con dati dei pazienti, variazioni anagrafiche, esami di laboratorio, esami radiologici, prescrizioni farmaceutiche, il tutto visualizzabile via Web oppure scaricabile in formato leggibile dal software del medico, previo accesso tramite utente e password.

Le fonti di dati erano MySql, Oracle, SQL Server (eh sì, vi si poteva accedere anche da Linux!), o file di testo importati tramite crontab.
Le pagine erano realizzate in XHTML, con CSS, con qualche bello spunto preso da CSS Zen Garden. JavaScript, come era giusto fare al tempo, era ridotto al minimo e si limitava a pre-convalidare i Form.

Poi si sa come vanno le cose nella pubblica amministrazione. Lo sviluppo interno viene abbandonato, e viene appaltato all'esterno. Così il mio lavoro non consiste più nel progettare e realizzare programmi, ma consiste nel riuscire a far funzionare programmi scritti da terzi, con tecniche di programmazione arcaiche e/o discutibili, e che ~~probabilmente~~ sicuramente avrei potuto scrivere meglio!

Negli ultimi cinque anni il mondo del Web è cambiato, il nuovo Web si chiama Web 2.0.
Cosa bisogna imparare per restare al passo?
Ho scelto di utilizzare il Google App Engine, questo richiede di imparare a programmare in Python ma (database a parte) tutto ciò che si utilizzava sotto Apache è ancora molto attuale. E all'autenticazione, il lato debole di ogni applicativo Web, non ci pensa più il programmatore ma se ne occupa Google!
La lista seguente serve soprattutto a me, per capire che cosa è cambiato dal punto in cui ero rimasto. Non è definitiva e la aggiornerò quando serve:

  • XHTML è stato abbandonato. Il successore di HTML4.01 è HTML5
  • Un applicativo, per essere funzionale ed apparire moderno, deve utilizzare AJAX
  • Utilizzare JavaScript non è più un tabù!
  • Creare a mano il proprio JavaScript è tabù: dove possibile, utilizzare JQuery o altre librerie standard!
  • Il framework standard di Google App Engine è Django. Non so se sarà il mio preferito, forse dovrei approfondire Pylons (che deriva in qualche modo da HTML::Mason)
  • Non bisogna dimenticarsi di integrare il proprio applicativo con Facebook e altri social networks, come ad esempio Google+.

Happy coding!

Scegliere i colori: programmatori e buon gusto!

La scorsa settimana cercavo un paio di mensole colorate da abbinare ad un mobiletto da mettere in sala. Non trovando nulla di interessante ho provato a chiedere un parere ad un dipendente Ikea, il quale mi ha mostrato delle mensole più larghe rispetto al mobiletto, con un altro spessore, e di colore simile ma diverso.

Credo che i programmatori, quando devono scegliere i colori per i propri programmi o per le pagine web, siano come i dipendenti Ikea: completamente privi di ogni buon gusto.

Capita spesso di vedere utilizzate combinazioni estreme di colori: serve un rosso, un verde, od un blu? Niente di più semplice, si sceglie un buon #ff000 per il rosso, un #00ff00 come verde, e per finire un buon blu #0000ff:

ma questi colori sono pesanti, difficili da combinare, ed assolutamente stonati. La prima regola da ricordare è tutte le combinazioni di colori più estreme devono sempre essere evitate!

Molto meglio utilizzare qualche combinazione più leggera, come ad esempio questa con codice #74A697, #FC8626 e #15766F:

Questi colori stancano di meno e si combinano più facilmente. Ma come scegliere una buona palette di colori?

Un grafico probabilmente non ha nemmeno bisogno di porsi questa domanda, ma un trucco che può usare anche un non grafico consiste nello scegliere una foto colorata, ed estrarre da essa una combinazione di colori che ci piace:

prendiamo un po' della cabina telefonica... ed un altro po' del taxi giallo... ecco qui i nostri amici #e02a2f, #f6d06d e #fbab20:

che possono essere combinati in questo modo:

Data Euribor 1 mese Euribor 2 mesi Euribor 3 mesi Euribor 6 mesi
18 ottobre 2010 0,78% 1,00% 1,22% 1,49%
19 ottobre 2010 0,79% 1,01% 1,23% 1,50%
20 ottobre 2010 0,81% 1,02% 1,24% 1,51%
21 ottobre 2010 0,82% 1,03% 1,25% 1,51%
22 ottobre 2010 0,82% 1,03% 1,25% 1,52%

Naturalmente è solo un esempio, ma come punto di partenza va sempre bene.
Poi magari... un giorno lontano... sistemerò anche i colori di questo blog!