I cookie: cosa sono e come funzionano | ALTRI capitoli | |||||
Il protocollo HTTP non offre alcun meccanismo che permetta, ad un server, di identificare un utente, nel corso di più connessioni, o richieste, successive. Quindi, se un utente si connette ad un server e gli invia cinque richieste distinte, per cinque pagine web differenti oppure per una stessa pagina web, aggiornata cinque volte consecutive, il server accetterà queste cinque richieste come se provenissero da cinque computer differenti. Questo accade perchè HTTP è un protocollo "stateless", senza stato: o meglio, che non mantiene informazioni di stato. Le informazioni di stato, infatti, richiedono risorse fisiche e tempi molto superiori a quelli richiesti da una serie di connessioni isolate e distinte. In un mondo senza stato, però, sarebbe impossibile permettere ad un utente di accedere ad un negozio online, scegliere, con calma, gli articoli più interessanti, selezionare, per ciascun articolo, la quantità desiderata, per poi passare alla cassa e perfezionare l'acquisto. Per poter fare questo, è necessario trovare un meccanismo che permetta al server di gestire vere e proprie sessioni di lavoro, dove con il termine sessione si intende un insieme di connessioni ( richieste ) HTTP, tutte riconducibili ad un unico soggetto. Sarebbe sufficiente inviare, ad ogni richiesta HTTP inviata dal client, un dato che identifichi la sessione, intesa come una serie di richieste HTTP anonime dietro alle quali si cela sempre lo stesso utente, in modo che il server possa memorizzare sul proprio disco fisso tutti i dati ad essa legati ( quali pagine l'utente ha visitato, quali articoli di un catalogo ha prenotato, etc. ). Esistono, fondamentalmente, tre meccanismi HTTP, in grado di trasportare informazioni di sessione:
I cookie sono header HTTP, utilizzati dal server e dal computer client per trasportare i dati di una sessione. Dal lato client ( il vostro computer ), i dati vengono mantenuti in memoria, per la durata della sessione, per poi essere salvati sul disco fisso, in uno o più file, gestiti dal browser. Dal lato server, invece, i dati vengono immediatamente salvati in un qualche database, per rimanervi, presumibilmente, per sempre.
Quando un computer client invia una prima richiesta HTTP ad un server, il server, se desidera aprire una sessione con il client, invia una risposta HTTP che contiene un particolare header HTTP, definito nella RFC 2109, del febbraio 1997:
nel quale il server invia un primo dato, solitamente un identificativo ( ID ) di sessione, nella forma NOME/VALORE, che segnala al client l'apertura di una sessione. Per esempio:
Il computer client, per accettare di aprire una sessione, deve inviare, al server, in tutte le richieste HTTP successive, un header aggiuntivo di sessione:
contenente lo stesso dato identificativo inviato, precedentemente, dal server:
Nel corso della sessione di lavoro, sarà proprio quel dato identificativo a permettere al server di distinguere le richieste HTTP di un utente dalle richieste HTTP di un altro utente, permettendo, così, al server di memorizzare una serie di informazioni, relative al singolo utente. Se il browser del computer client non invia un header
contenente o le stesse informazioni inviate con la prima risposta, oppure informazioni differenti. Il server può anche decidere di non inviare alcun altro header
oppure una data di scadenza già passata:
Un server può inviare un header
Come vedremo nel prossimo esempio, il server può inviare, al browser del client ( user agent ), più cookie. Per esempio, il server può memorizzare un identificativo di sessione e la lingua di default per l'utente remoto, inviando due distinti header HTTP
In questo esempio, l'header HTTP
Il browser del computer client ( user agent ) potrà , comunque, eliminare il cookie prima della data di scadenza, nel caso in cui avesse terminato lo spazio su disco riservato ai cookie, oppure se ricevesse una richiesta di eliminazione da parte dell'utente. Anche il server può chiedere al computer client di eliminare un cookie, inviando un header HTTP
quello che prevale, determinando l'effettiva data di scadenza, è il primo (
Ciascun cookie inizia con la coppia NAME=VALUE, seguita da zero o più coppie di attributo/valore, ciascuna separata dall'altra da un punto e virgola:
dove:
contiene la data di scadenza del cookie. La data di scadenza deve essere espressa nel formato riportato nella RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1, Sezione 3.3.1:
così come definito nella RFC 1123 ( un aggiornamento della RFC 822 ). GMT è un acronimo per Greenwich Mean Time.
contiene il dominio per il quale il cookie è valido, il dominio al quale il browser ( user agent ) dovrà inviare l'header HTTP
il browser del client ( user agent ) dovrà includere il cookie nell'header HTTP
Qualsiasi punto premesso al nome di dominio (
quando l'attributo "Domain" avrà il valore:
oppure, il valore:
ma lo respingerà , quando l'attributo "Domain" avrà il valore:
oppure, il valore:
Molti browser sono configurati per respingere i valori dell'attributo "Domain" corrispondenti a suffissi pubblici, quali:
Questo, per ovvie ragioni di sicurezza. Se l'attributo "Domain" non fosse indicato, il browser del client ritornerebbe il cookie esclusivamente al server di origine, senza nemmeno includere eventuali sottodomini. L'attributo:
contiene la directory per la quale il cookie è valido. Il contenuto di un server, dal quale ha origine l'header
Tornando agli attributi disponibili per i cookie, abbiamo:
indica l'intervallo temporale di validità del cookie, espresso in secondi, dopo il quale il computer client dovrà eliminare il cookie. Il valore zero indica: elimina subito. Alcuni browser ( user agent ) non supportano l'attributo
non richiede alcun valore, ma indica al browser ( User Agent ) di rispondere al server, utilizzando solo canali di trasmissione sicuri ( solitamente, HTTP over Transport Layer Security, o TLS ). Se assente, il browser potrà utilizzare, per il trasporto, anche canali non protetti. L'attributo:
non ha nulla a che vedere con il precedente attributo (
nel qual caso, il browser dovrà eliminare sia il vecchio che il nuovo cookie. In tutti gli altri casi, i cookie verranno accumulati e conservati fino alla loro naturale scadenza, per poi essere distrutti. Un server può creare un header HTTP Nei browser, quali Firefox, è possibile impostare le proprie preferenze, in relazione all'accettazione o meno dei cookie. In Firefox, per esempio, è possibile aprire la scheda:
Alla voce:
selezionare:
Per attivare i cookie, contrassegnare la voce:
Nel menù immediatamente successivo, dovremo scegliere se:
Cosa sono i cookie di terze parti? "I cookie di terze parti sono cookie impostati da un sito web diverso da quello che si sta attualmente visitando. Ad esempio, il sito Catturare i cookie con Il comando
In questo esempio,
Vi siete connessi alla home page del giornale " La Repubblica "? Eseguendo il comando precedente dovreste trovare, tra le altre, righe come le seguenti ( nel nostro esempio, ciascuna riga viene spalmata su più righe, per un semplice problema di spazio ):
Per ciascuno dei cookie inviati dal server di Repubblica, dovremmo trovare, in ogni successiva richiesta, inviata dal nostro computer allo stesso server di Repubblica, un header
In questo esempio, uno stesso header I cookie, inizialmente, furono creati per una nobile missione: permettere, ad un server, di distinguere uno User Agent ( browser ) dall'altro, in modo da poter modellare i servizi offerti sulle informazioni inviate dall'utente che utilizzava quel browser. Naturalmente, l'abuso era dietro l'angolo e, di abuso in abuso, si arrivò alla formulazione di leggi, che si prefiggevano lo scopo di limitare la portata di tali abusi, e ad una serie di utility, che mettevano l'utente nelle condizioni di cancellare i cookie salvati. L'insieme di queste misure hanno comportato, ovviamente, una riduzione dell'efficacia dello strumento cookie. "Oggi, i cookie rappresentano ancora il principale meccanismo che le agenzie di advertising, quali Google, utilizzano per tracciare e profilare gli utenti, attraverso i siti web e nel tempo, arrivando, in alcuni casi e per ciascun utente, a costruire, negli anni, un singolo e gigantesco profilo. Molti membri dell'EFF ( The Electronic Frontier Foundation ) rispondono a queste minacce utilizzando i programmi di gestione dei cookie, offerti dai loro browser, per limitare sia il numero dei cookie da accettare, sia la loro durata. Oggi, la situazione dei cookie è la seguente: i siti che desiderano tracciare i loro utenti hanno a disposizione nuove tecnologie, alle quali è molto difficile opporsi, poichè hanno un comportamento simile a quello dei cookie, ma sono molto meno conosciute, molto più difficili da identificare e molto più difficili da controllare" ( New Cookie Technologies: Harder to See and Remove, Widely Used to Track You ). "Una delle principali tecnologie utilizzate ai giorni nostri è quella dei cosiddetti "cookie Flash", un tipo di cookie gestito dai plug-in di Adobe Flash, nascosto nelle applicazioni Flash, contenute nelle pagine web. I file di questi cookie sono salvati al di fuori della portata del browser. Il browser non è in grado di permettere o negare l'accesso dell'utente ai cookie gestiti dalle applicazioni Flash. Un utente non viene informato della creazione di un cookie di Flash. Un cookie di Flash non ha scadenza. I cookie di Flash possono tracciare un utente, al pari di quanto possono fare i cookie HTTP tradizionali, solo che i cookie di Flash vengono memorizzati o recuperati ogniqualvolta un utente accede ad una pagina web, in cui sia presente un'applicazione Flash." ( New Cookie Technologies: Harder to See and Remove, Widely Used to Track You ). "Adobe Flash offre agli sviluppatori la possibilità di creare applicazioni dinamiche, usando un linguaggio simile a JavaScript: ActionScript. Queste applicazioni sono connesse alla rete e possono caricare in memoria codice sorgente e dati, direttamente da Internet. Adobe include, anche, metodi per aggirare il vincolo di sicurezza, che dovrebbe essere applicato da qualsiasi browser, chiamato same-origin security policy, che impone di non permettere ad un'applicazione residente su un server di leggere i dati presenti su un server differente. Flash è anche browser-independent nella identificazione della locazione di memorizzazione dei dati. Se un utente apre un sito web con un browser, creando un oggetto Flash ( LSO: Local Shared Object ), potrà , in un secondo tempo, riaprire lo stesso oggetto Flash, anche utilizzando un browser differente. Grazie a questo meccanismo, Adobe garantisce, agli sviluppatori, la persistenza dei dati, attraverso browser differenti. Flash non offre alcuna interfaccia web ( browser ) per modificare le impostazioni sulla privacy o sulla memorizzazione. Flash, a questo scopo, mette a disposizione, con un click sul tasto destro del mouse, applicato al video in esecuzione, un menù contestuale, relativo al solo video in caricamento, che non può essere nascosto dallo sviluppatore e che può riferirsi esclusivamente al video in esecuzione. Per vedere o modificare le impostazioni generali, relative a tutti i siti, oppure, per vedere quali siti stiano memorizzando dati sul computer dell'utente, Adobe obbliga l'utente stesso ad aprire un video Flash speciale, ospitato sui suoi server, Flash Player Help, raggiungibile solo con una connessione HTTP ( insicura ). Un utente, quindi, che, per un qualsiasi motivo non fosse in grado di raggiungere il sito Adobe di controllo, non avrà alcuna possibilità di vedere o eliminare i dati salvati nel suo computer" ( Cleaning Up After Cookies ). Per gli utenti Firefox, esiste un plug-in, BetterPrivacy, che permette, attraverso un'interfaccia molto semplice ed intuibile, di gestire ( vedere o cancellare ) i cookie Flash. Gnash, il player GNU SWF, include "soldumper", una utility che permette di leggere direttamente i file in cui sono memorizzati gli oggetti LSO ( Local Shared Object ), i cookie Flash. In un sistema Linux, i dati di Adobe Flash vengono memorizzati in una sottodirectory, salvata nello spazio di ciascun singolo utente:
All'interno di questa sottodirectory, potreste trovare diverse altre directory, le più importanti delle quali sono:
La prima directory contiene le impostazioni globali e persistenti per il player Flash e una sottocartella, per ciascun dominio visitato, contenente le impostazioni Flash specifiche per quel dominio. La seconda directory contiene i cookie Flash. Un cookie Flash viene impostato quando un sito web pubblica un contenuto Flash embedded. Per esempio, un sito web potrebbe includere un banner pubblicitario in Flash, fornito da un'azienda che ha affittato lo spazio pubblicitario, oppure potrebbe caricare un file nascosto SWF ( ShockWave Flash ), il cui unico scopo sarebbe quello di memorizzare le impostazioni utente, quali il volume da assegnare ad un video Flash oppure la memorizzazione di un contenuto Flash in una qualche cache, sul disco locale, per una migliore performance ( qualità ), soprattutto nel caso di una connessione di rete poco affidabile. Questo significa che un'applicazione Flash potrebbe trasferire alcuni dati, da una Società pubblicitaria al computer di un utente, senza che l'utente sia a conoscenza di questa transazione e senza, nemmeno, che l'utente debba cliccare sul banner pubblicitario o sul video ( Flash Cookies and Privacy ). Sfortunatamente, non esiste un metodo semplice, per evitare il tracciamento delle nostre abitudini di rete, volendo visitare un sito web moderno, magari un sito di social networking ( Facebook, Twitter, etc. ), ricco di codice JavaScript e di cookie. Per limitare i danni da queste pratiche di tracciamento, è possibile prendere qualche buona abitudine:
|
||||||
I cookie: cosa sono e come funzionano | Le guide di .bit: contenuto originale |