Autore: vecna Data: To: hackmeeting Oggetto: Re: [Hackmeeting] scookies
bel lavoro baku, e ogni volta che vedo un plugin mi ricordo che dovrei
dedicarmici a pieno :P
e' un sistema efficace e semplice. le regexp equivalgono alla lista di
siti tacciabili di profilazione, e il modo migliore per espanderlo e'
accettare contributi dal sito, cosi' che gli utenti popolino questa lista.
sono scettico riguardo un altro aspetto.
il cambio dei cookie funziona, ma si lasciano tracce come il fingerprint
del browser, che sono extra-cookie.
il problema dell'informazione guidata, in qualche modo permane, anche se
non e' da considerarsi il reale obiettivo dei motori di ricerca.
in generale sostengo che sia necessario usare una rete di "proxy" (che
possono essere i client stessi) che si interfaccino con un engine
proprio ai server web. con un engine a layer 5 (tipo un proxy, o uno
script in python/php/perl) possono effettuare le ricerche e acquisire
dati dai motori di ricerca, possono mascherare user agent ed altri
aspetti applicativamente meno facili da mascherare, e possono essere
fruiti anche da utenti che non usano i plugin del browser.
cosi' da lasciare che il traffico web sia smazzato/fakato/mixato dai
proxy, e il traffico di "dati" (domande/risposte/liste/keyword) sia in
circolo tra client-semplici - client+plugin - proxy.
nel grande disegno, mi pare una soluzione piu' flessibile.
wiky, la tua preoccupazione e' significativa. nello specifico il cookie
di google non e' sufficente ad autenticarti alle sessioni gmail. ne era
uscita una vulnerabilita' che, sniffando un cookie di gmail in chiaro,
consentiva l'accesso alla posta della vittima. ma ora e' stato fixato
(basta marchiare i cookie come "secure" e farli transitare su HTTPS, i
cookie sicuri sono quelli che vengono rimossi alla chiusura del browser)
e inoltre il cookie di gmail e' differente da quello di google, anche
se, tra i cookie necessari a gmail.google.com, c'e' quello di google.com.
sara' premura di X1 in fase di verifica dei server, includere solo
coppie di server/cookie non necessari ad autenticazioni importanti.
X1: baku/software di baku/software di chiunque che voglia aiutarlo fatto
per aiutare baku a generare regexp server-cookie, perche' e' da
considerarsi la lista/database analoga ad un bd di firme d'antivirus,
dove pero' siamo noi a tenerlo aggiornato per coprire la maggior parte
di siti "profilanti".
anche a questo avviso, secondo me, l'uso di una rete di interfaccia al
web basata su proxy e' una soluzione piu' definitiva: una lista dovra'
sempre essere verificata e controllata, una rete che si interfaccia al
web invece se ne frega di come cambia il web, tanto lei e' composta da M
nodi che mascherano N utenti.