Newsgroup: it.lavoro.professioni.webmaster
Titolo: A cookie is a cookie is a cookie

Questo è solo un rant, e *non* fa parte della soluzione (ma del precipitato).
 
TL;DR la Cookie Law pone piu' problemi di quanti non ne risolva. Anche perche'
in realta' non ne risolve alcuno.
 
===
 
"1. Considerazioni preliminari.
 
I cookie sono stringhe di testo di piccole dimensioni che i siti visitati
dall'utente inviano al suo terminale (solitamente al browser), dove vengono
memorizzati per essere poi ritrasmessi agli stessi siti alla successiva visita
del medesimo utente"
 
Per brevita' riscrivo:
 
	"I cookie sono [STPD = stringhe di testo di piccole dimensioni]
	che godono della proprieta' [ATTR = sono inviati dai siti...]"
 
Quindi la legge:
 
	a) Afferma di avere giurisdizione (solo) sui cookie
	b) Definisce un cookie come un STPD dotato di ATTR.
 
Mi sembra che ci possano essere due interpretazioni.
 
Interpretazione stretta: qualsiasi STPD dotato di ATTR e' un cookie (ovvero se
si preferisce, "Cookie e' chi il cookie fa").
 
Interpretazione rilassata: un STPD dotato di ATTR e' un cookie, a patto che si
verifichi qualche altra condizione (come essere chiamato "Cookie" dal browser,
o trovarsi la' dove un esperto in subiecta materia s'aspetta di trovare quello
che lui chiama "cookie".
 
===
 
La prima interpretazione e' disastrosa; la seconda e' stupida.
 
===
 
Il fatto e' che ci sono almeno tre altri livelli meta sopra i cookie:
 
	1.: "Informazione atta a identificare unicamente un browser"
 
	2.: "<1> inviata dal server al client in modo che il client la
	     ritrasmetta al server in una visita successiva"
 
	3.: "<2> in forma identica"
 
	4.: "<3> tramite lo header Set-Cookie."
 
La legge si preoccupa del livello uno: ma regolamenta solo il livello QUATTRO.
 
Al livello tre, per esempio, ci sono informazioni come gli header ETag e Last-
Modified. C'e' il local-storage. Se uso covert channel, si sale al livello due
(reverse oracle attack in Javascript. Suona pomposo ma sono _quattro_ righe di
codice).
 
 
http://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags
 
 
Il server manda "Pippo". Il client risponde, "Pluto". Si puo' sostenere che la
stringa "Pluto" non e' mai stata inviata dal server al client, ma il server e'
perfettamente in grado di correlare "Pluto" con "Pippo"... e di "far finta" di
aver ricevuto "Pippo". Per quanto ne sa il server, quindi, il cookie c'e'. Per
quanto ne sa il client, il cookie non c'e'.
 
Al livello uno ci si puo' sbizzarrire (v. progetto Panopticlick).
 
O anche:
 
 
http://noc.to/
 
 
Anche qui, io posso "fare vedere" al server un cookie che il client non ha mai
mandato, ed e' convinto di non avere. Posso rendere l'operazione 100% passiva,
in modo che nessun dato transiti dalla rete e sia intercettato e riconoscibile
- e a quel punto non si puo' dimostrare che sto usando un "cookie invisibile",
a meno di condurre (estese) indagini statistiche.
 
Il problema e', che nemmeno posso dimostrare di NON starlo usando. Per il solo
fatto che POTREI starlo usando (o farlo in futuro), dovrei avvertire?
 
===
 
Quindi, riassumendo:
 
- nell'interpretazione "STRETTA", la legge in realta' definisce "cookie" quasi
  tutto quello che si trova al metalivello tre. Cookie, ETag, Last-Modified, e
  modifiche banali o richieste aggiuntive agli URL fatte in Javascript, usando
  dati in Local Storage.
 
Se io accetto l'interpretazione stretta, nemmeno un sito che risponda sempre e
solo "Error 404" o "It works!" potrebbe essere ritenuto "non usare cookie", in
base a una sola visita.
 
Se io adotto l'interpretazione morbida, chiudo la porta ai cookie... ma lascio
aperte finestre, abbaini e porta sul retro. Stiaccio magari il poverino che ha
la curiosita' di sapere quante visite uniche riceve il sito, ma per es. Google
potrebbe smettere di usare i cookie domani ma continuare a tracciare tutti con
la stessa efficienza di prima, usando sapientemente gli altri header.
 
In effetti, puramente per stronzaggine, mi sono scritto una PoC che legge quei
dati (e li riscrive ad hoc) dopodiche' inietta i risultati dentro la variabile
_COOKIE. Sul browser non c'e' piu' neanche un cookie - MA IL SERVER CONTINUA A
VEDERLI E USARLI COME SE CI FOSSERO. Semplicemente il contenuto lo archivio in
locale sul server. E' ragionevole che la legge me lo lasci fare? E se non vuol
farmelo fare... COME FA? Cosa mi impone? E come fa a imporlo solo a me, e non,
anche, all'universo mondo?
 
Leonardo
 
-- 
A stultis ex omnibus gentium varie pictis
A sanctae fidei adeptis, ab eorum odore;
AB insanis Iacobinis, ab eorum ardore
AB idolatris et martyribus odii et terroris;
A paradisi fautoribus dicentibus "est pro amore",
A manichaeis ululantibus "Nisi nobiscum prodes";
LIBERA, libera, libera, libera nos, Domine.

 anche, all'universo mondo?
 
Tutto perfetto.
Infatti sulla cosa mi pare che siano parecchi a lavorarci, anche perché aumentano i blocchi per la privacy (ROTFL), blocchi di javascript, etc... e chi prima "profilava" il web deve poter ovviare a tutto questo.
Quindi se ho capito bene usando tecniche più raffinate l'utente non ha alcuna possibilità non solo di evitare la profilazione, ma anche di capire che sia in atto, è così?


Sostanzialmente, si'. Si possono fare analisi comparate da due macchine
diverse, e notare che ricevono header diversi quando ci si aspetterebbe
il contrario. Ma un singolo client non ha motivi per insospettirsi.


 il contrario. Ma un singolo client non ha motivi per insospettirsi.
 
Quindi da un punto di vista teorico, un'azienda che fa analisi e profilazione, diciamo un'azienda importante, potrebbe tenere attive le due cose.
Da una parte rifilare i cookie, in modo da far credere all'utente di essere padrone della situazione, e dall'altra utilizzare le altre tecniche per bypassare il blocco.
 
Mi parte che sugli ETag si cominciò a discutere quando i sistemi di affiliazione cominciavano a mostrare buchi consistenti con perdita dei contatti di vendita (e di credibilità), a quel tempo c'era la necessità di tracciare vendite altrimenti bloccate lato client.
 
Ma ... quanto tu hai scritto deve per forza di cose essere applicato lato server giusto? Intendo sul server (o l'infrastruttura) dove si trova il sito, è corretto? O potrebbero farlo anche soggetti terzi? In questo modo riuscirebbero anche senza utilizzare javascript o altro codice eseguibile lato client e presente nelle pagine?
 
Un client potrebbe implementare una tecnologia in grado di riconoscere header alterati?

 Un client potrebbe implementare una tecnologia in grado di riconoscere header alterati?
 
Mi spiego meglio... potrebbe integrare una tecnologia che utilizzi risorse esterne per riconoscere questo tipo di sofisticazione dell'header? Che so... si collega ad una risorsa esterna di Microsoft, Mozilla o chissà che ... e ... probabilmente dirò una sciocchezza... effettua richieste multiple e poi le confronta...

 Un client potrebbe implementare una tecnologia in grado di riconoscere header alterati?
 
Non credo. Potrebbe fare studi statistici sulla variazione degli header, ma se
per es. ti mantrugio la PNG di un contatore delle visite, e' pacifico che ogni
volta debba cambiare:
 
	prima richiesta client 1    --> immagine 1, con ETag XXXXX1
	prima richiesta client 2    --> immagine 2, con ETag XXXXX2
	seconda rich. client1       --> immagine 3, con ETag XXXXX3
 
...pero' nel frattempo la seconda richiesta ha inviato un INM=XXXXX1, e cosi',
io so che la richiesta me l'ha fatta client1.
 
Quindi nel mio database (ipotesi SQL)
 
	UPDATE virtualcookies SET etag='XXXXX3' WHERE etag='XXXXX1';
 
e gli header ora sono _ESATTAMENTE GLI STESSI_ di una connessione onesta. Poi,
quando m'arriva INM=ABCDEF:
 
	SELECT * FROM virtualcookies WHERE etag='ABCDEF';
 
...leggo il codice utente, seleziono tutti i cookie che lui NON mi manda pero'
mi piacerebbe se mandasse, e li archivio - caso PHP - dentro a $_COOKIE[].
 
In effetti, inserendo il codice in un proxy o load balancer (che gia' ha tutto
il necessario per le sticky sessions) potrei fare la stessa cosa ancora meglio
aggiungendo i cookie alle connessioni in entrata e TOGLIENDOLI in uscita.
 
A quel punto il server non si accorge di nulla, ed i client neppure. Il server
e' convinto che i client accettino tutti i cookie; e i client sono convinti di
non accettarne manco mezzo.
 
Il proxy/load balancer, fra IP, TCP signature e browser fingerprinting, e' del
tutto in grado di stabilire che la richiesta X per una risorsa non mantrugiata
proviene dallo stesso client che poco prima ha richiesto una risorsa truccata.
 
E puo' segnarsi le richieste dubbie, in modo da non tracciarle e farci sopra i
resoconti statistici a fine mese: "Il sistema funziona al 95%".
 
Anzi, nulla mi vieta di truccare index.html e giustificare la diversita' degli
ETag col fatto che dentro la pagina c'e' data, ora al microsecondo e IP di chi
l'ha richiesta. Sono oggetti diversi, ergo hanno ETag diversi: e sarebbe folle
voler sostenere il contrario.
 
E in caso di contestazioni, posso sempre dire che seguo scrupolosamente quello
che la legge ordina in materia di intestazioni ETag. Ossia niente.
 
In maniera del tutto analoga e con un po' di collaborazione del server, quando
ti colleghi ti mando una pagina HTML statica con un tempo di caching enorme, e
nel codice <img src="/cookies/58ee09937d51f3886dcd0c0ea91c053e.png" />. Questa
immagine invece va di revalidation come fosse il giorno del castigo. E ritorna
sempre lo stesso ETag: tanto, il "cookie" e' nel nome :-)
 
Oppure potrei usare un form autosubmit, con un campo in autosave. Tutti quelli
che conosco hanno la funzione "Ricorda campi e password" impostata di default;
ma questo richiede ancora piu' lavoro lato server... mentre riscrivere il BODY
della sola pagina indice tutto sommato si puo' fare anche dall'esterno.
 
Leonardo che secondo me riesco a scrivermici un modulo PoC per nginx <g>


 	b) Definisce un cookie come un STPD dotato di ATTR.
 
Come mi è stato fatto notare oggi, la Cookie law non è una legge, ma è un provvedimento generale. Significa che la legge (a cui fa riferimento il provvedimento, esplicitamente in molti punti, ad esempio le sanzioni) da rispettare è il 196/03. In particolare l'art.122 che parla genericamente di informazioni archiviate nell'apparecchio terminale.


Art. 122. Informazioni raccolte nei riguardi del contraente o dell'utente
 
1. L'archiviazione delle informazioni nell'apparecchio terminale di un
   contraente o di un utente o l'accesso a informazioni già archiviate sono
   consentiti unicamente a condizione che il contraente o l'utente abbia
   espresso il proprio consenso dopo essere stato informato con le modalità
   semplificate di cui all'articolo 13, comma 3.
 
...il che vuol dire che se io "NON" invio alcun cookie, "MA" invio
informazioni che poi il terminale dell'utente potrebbe rimandarmi,
comunque devo informarlo in modo semplificato.
 
Ma questo è esattamente quello che fanno i server Web inviando gli
header Last-Modified ed ETag!
