[e-privacy] Un nuovo concept di leaking alternativo a wikileaks

[Tommaso "Sanata" Gagliardoni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Textwall incoming!

Ho letto con attenzione il draft e avrei qualche osservazione da fare.


Se ho ben capito lo schema, ci sono 5 classi di "attori":

1) i leakers/whistleblowers, ovvero le fonti delle spifferate

2) i nodi globaleaks (intesi come software che agisce in maniera automatica)

3) i mantainers dei nodi globaleaks (che possono intervenire manualmente
moderando e selezionando)

4) i giornalisti/blogger/attivisti che daranno risalto alle notizie

5) il pubblico


mentre ci sono 5 classi di "oneri" (con annessi rischi):

A) trafugare materiale riservato

B) selezionare il giusto contesto linguistico/geografico e far si' che,
ad esempio, la notizia locale arrivi ai giornalisti locali e la notizia
globale arrivi ai giornalisti globali

C) filtrare lo spam

D) riconoscere i fake o le cose poco interessanti/pertinenti

E) diffondere al pubblico


Per farla breve anticipo una tabella riassuntiva di come dovrebbero
essere distribuiti questi oneri secondo me, segue grossa pippa mentale
sul perche' sono giunto a tale distribuzione:

X = necessario
x = opzionale, a seconda di quanta responsabilita' legale si vuole
assumere il singolo gestore del nodo


        |    A   |    B   |    C   |    D   |    E   |
- --------+--------+--------+--------+--------+--------+
   1    |    X   |        |        |        |        |
- --------+--------+--------+--------+--------+--------+
   2    |        |    X   |    X   |        |        |
- --------+--------+--------+--------+--------+--------+
   3    |        |    x   |    x   |    x   |        |
- --------+--------+--------+--------+--------+--------+
   4    |        |        |        |    X   |    X   |
- --------+--------+--------+--------+--------+--------+
   5    |        |        |        |        |        |
- --------+--------+--------+--------+--------+--------+


La prima cosa che vorrei fissare e' il ruolo che dovranno avere i
gestori dei nodi globaleaks rispetto a questi oneri, e questo e'
cruciale, perche' a seconda dei rischi a cui andranno incontro si dovra'
pensare a contromisure diverse.

Ad esempio, se si fanno le cose in modo che ai mantainer dei nodi non si
possa imputare alcuna liability, non ci sara' bisogno di mantenere
anonime le loro identita' (ne' di tenere i nodi dietro hidden service
Tor ad esempio).

Se, viceversa, i gestori dovranno assumersi almeno qualche rischio (come
credo che sia inevitabile), allora:

"Additionally if the leak router have established trust with other leak
routers, the leaker will be presented an option to spread it also across
the other trusted leak routers by selecting them. The other trusted leak
routers are presented with the their name, description and supported
languages."

e' MOLTO pericoloso e deve essere evitato a tutti i costi, perche'
conoscere la web of trust di un particolare nodo mette a rischio tutti i
suoi peer nel caso che l'identita' di quel nodo venga scoperta (ma mette
tutto a rischio a priori perche' espone al rischio di data mining e
correlation attacks).

Ne deduco che l'onere B) non puo' essere delegato all'attore 1), anche
per un altro motivo: quando il leaker trafuga qualcosa di "scottante",
magari non ha tempo per mettersi a fare tante tazzine, scrivere un
abstract e delle keywords, scegliere a quali nodi mandare il materiale,
informarsi sulla reputazione di questi nodi etc.: ha una fretta boia di
sbarazzarsi del materiale, e dato che alla fine e' lui quello che corre
piu' rischi, noi dovremmo agevolargli il compito: "passa qui la roba che
hai, ci pensiamo noi a smistarla".

Questo pero' comporta il rischio di esporsi a nodi "rogue": se il leaker
becca il nodo sbagliato, tutto il suo lavoro viene vanificato e si
espone a un rischio notevole. Credo che a questo si possa rimediare solo
costruendo la reputazione dei nodi in rete, ovvero il whistleblower che
ha qualcosa da spifferare "sa" che puo' farlo contattando il tal nodo
perche' quel nodo ha una buona reputazione. Usare un meccanismo di web
of trust in questa sede non mi pare la soluzione (anche perche' come
detto sopra le web of trust dei nodi e' meglio se rimangono
undisclosed), semplicemente il tam tam della rete ci dice che "c'e' un
nodo buono al tal indirizzo". Al massimo questo comporta per il leaker
solo l'onere aggiuntivo di documentarsi un po' sulla reputazione di un
nodo prima di mandargli il materiale (cosa che dovrebbe comunque fare se
e' appena un po' furbo).

Quindi l'onere B) va delegato all'attore 2), ovvero il nodo analizza
lingua e keywords del materiale leakato e usando qualche algoritmo
seleziona in automatico i nodi (tra quelli della sua web of trust) a cui
rigirare il materiale. Cioe' secondo me lo schema:

"When the leaker is submitting a leak it must apply a set of important
meta data such as a category, language, a set of tags/keywords, a title,
a description and a note to be forwarded to journalists."

e' impraticabile.

Quando un gestore mette su un nodo, dovra' riempire dei campi del tipo:
lingue supportate, aree geografiche d'interesse, argomenti di competenza
nel caso di moderazione del materiale, eventualmente tempo a
disposizione da dedicare al lavoro di filtraggio etc. Queste
informazioni sono "sensibili" perche' danno indizi sull'identita' del
mantainer, ma dato che vengono rivelate solo ai peer "trusted" del nodo
il problema non si pone piu' di tanto.

C'e' di meglio: quando un nodo si "presenta" ad altri nodi, non fornira'
SOLO le sue caratteristiche, ma anche quelle dei nodi peer, pesate e
anonimizzate!

Esempio: io sono un nodo che parla ITALIANO e INGLESE e che si occupa di
POLITICA ITALIANA.

Mi collego alla rete per mezzo di un amico, il quale parla ITALIANO e
TEDESCO e si occupa di POLITICA TEDESCA (per il 70%)e TEORIE UFO (per il
restante 30%). La fiducia che ho in questo mio amico e', diciamo, dell'80%.

A questo punto, quando mi connetto a un altro nodo, mi presentero' con
delle statistiche del tipo:

LINGUE DI COMPETENZA:
Italiano:	50%
Inglese:	36%
Tedesco:	14%


ARGOMENTI DI COMPETENZA:
Politica italiana:	60%
Politica tedesca:	25%
Teorie UFO:		15%

Il calcolo delle percentuali puo' avvenire in vari modi, terra' in
considerazione sia dei coefficienti messi dal mantainer stesso (se ad
esempio e' piu' competente/interessato in un argomento piuttosto che un
altro) sia dalla fiducia che ripone nei singoli peer, sia dalla
reputazione che il peer ha maturato (intesa ad esempio come numero di
leaks pubblicati nel corso del tempo), sia dal tempo che il peer
dichiara di poter mettere a disposizione, sia dal principio che "quello
che e' locale conta piu' di quello che e' dei peer".

Se aggiungo alla mia web of trust un nuovo nodo globaleaks di un tipo
che ho conosciuto durante un viaggio all'estero e che mi pareva
"abbastanza a posto" (fiducia 50%), le mie statistiche verranno
aggiornate, ad esempio, in:

LINGUE DI COMPETENZA:
Italiano:	46%
Inglese:	38%
Tedesco:	10%
Francese:	 6%


ARGOMENTI DI COMPETENZA:
Politica italiana:	46%
Politica tedesca:	19%
Teorie UFO:		11%
Politica francese:	12%
Parigi (citta'):	12%

E cosi' via man mano che aggiungo altri peer.

A questo punto supponiamo che uno dei miei molti peer riceva un leak
riguardante un cable diffuso dall'ambasciata italiana a Berlino.
Analizza le keywords presenti nel documento, la lingua etc e in base a
cio' decide automaticamente (o forse l'ha deciso manualmente il gestore
del nodo, non ho modo di saperlo) di passarlo anche a me.

Il mio nodo riceve il materiale, io supponiamo che abbia deciso di non
assumermi responsabilita' e di non intervenire, ma il mio nodo analizza
in automatico il messaggio e ne deduce che:
 - probabilmente non e' spam
 - e' sufficientemente interessante per il mio amico tedesco: lo
forwarda anche a lui
 - e' sufficientemente interessante per me, allora lo notifica, ad
esempio, alla mia casella email (oppure anche no, potrei voler declinare
anche questa responsabilita') _E_ lo notifica anche agli attori di tipo
4) presenti nella mia lista, ad esempio un blogger e un paio di
giornalisti (anche qui nel rispetto del grado di fiducia e di competenza
di ognuno di essi, ad esempio il mio nodo decide di scartare
automaticamente un blogger della mia lista che si occupa solo di
tecnologie di spionaggio e che quindi non sarebbe interessato al cable).
Contemporaneamente a cio', il mio nodo si premura di mettere in atto un
meccanismo che fara' in modo che quel materiale sara' comunque diffuso
tra, diciamo, 10 giorni, anche qualora nessuno dei giornalisti
contattati decida di dare risalto alla notizia, ad esempio carica quel
documento sulle reti torrent, kademlia e freent in forma cifrata, e dopo
10 giorni inviera' la chiave di decodifica su account facebook, twitter,
email, forum, insomma direttamente agli attori di tipo 5).

In questa fase spettera' solo ai giornalisti/blogger analizzare il
documento e capire se e' un fake o poco interessante o troppo rischioso
da pubblicare, ma avrei anche potuto decidere di intervenire io
personalmente (configurando il mio nodo) dando un'occhiata al materiale
prima di spedirlo ai giornalisti. Nessuno potra' sapere se mi sono
assunto questa responsabilita' se non sequestrandomi il nodo e facendo
forensic sul mio file di configurazione.

La tecnologia per fare tutte queste belle cose secondo me c'e': mi pare
la tipica cosa che viene bene se fatta tramite un plugin freenet (che
mette gia' a disposizione il meccanismo di web of trust e quindi sarebbe
perfetto), eccetto che bisogna studiare modi per distribuire i leak tra
i nodi nel caso che il volume di dati sia insostenibile dalla rete
freenet attuale in tempi ragionevoli. Inoltre per un leaker, spedire
materiale via freenet potrebbe essere problematico per motivi tecnici o
di tempo. Credo che l'unica soluzione praticabile sia, per il momento,
quella di appoggiarsi anche a Tor, e di implementare (come suggerito nel
draft) la pagina per la submission dei leaks come hidden service di tor,
facilmente raggiungibile da un proxy web2tor. A lungo andare pero'
prevedo problemi con questo approccio, e si dovrebbe pensare ad una
graduale migrazione sulla sola rete freenet.

Il problema cruciale secondo me sotto queste condizioni, e' quello di
creare contatto tra i nodi globaleaks e gli attori di tipo 4). Se un
nodo vuole restare anonimo non puo' permettersi il lusso di contattare
un blogger, per quanto fidato, e dirgli "hei psst... sono un nodo
globaleaks, ti va bene se ogni tanto ti mando materiale interessante in
anteprima?". No, secondo me ci dovrebbe essere l'approccio inverso:
"Hei, attenzione tutti quanti: sono un giornalista disposto a prendere
in visione preliminare i leaks, queste sono le mie informazioni di
contatto! Nodi globaleaks, mi aggiungereste alla vostra lista?".

Questa parte sarebbe carina, basterebbe che ogni
blogger/giornalista/attivista interessato pubblicasse sulla sua homepage
o profilo twitter/fb un tag appositamente formattato che includa:

 - una chiave pubblica gpg
 - informazioni di contatto
 - lingue/argomenti/geografia di interesse, anche per keywords

Cio' rimuoverebbe le ultime due criticita', ovvero:

"Each destination will be sent a personal password to access leaks and
will be sent a password reminder every 6 months."

(reminder in chiaro = pericoloso, meglio inviare le chiavi per ritrovare
i documenti direttamente via messaggio cifrato con chiave pubblica) e:

"The notification must provide the title of the leak, the brief
description and the personal access URL to retrieve the private leak
copy enciphered with the journalist password."

Resterebbe l'onere "social" per gli sviluppatori di openleaks di
pubblicizzare il progetto e far si' che blogger e giornalisti vari se ne
interessino e decidano di crearsi un loro tag openleaks per essere
contattati. In questo credo che anche la community di e-privacy possa
fare la sua parte :)


Questo e' quanto, sono bloccato a casa malato, devo pur passare il tempo
in qualche modo :P


- -- 
Tommaso "Sanata" Gagliardoni <tommasoATgagliardoniDOTnet>
GnuPG Key ID: 51D8DEB8
Fingerprint: DC10 0D2F 8F07 238D C5DB  63B8 0AEF 48C5 51D8 DEB8
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNDQCIAAoJEArvSMVR2N64lt4QAJV0FDMzAdYALvw8AuAX4LPE
rZqabWBHnnaNTt9UHm6jkD7BZVOKlQSsYT5REeKJ00J+GUfSQs9vcbBEwzppkWk3
gbFzVQE3NJ4Vw9TZA7AOXJsN2eHwdkoKZNxt8JYp9JOLC02FpPlnIab9rP1oS5Wt
xoNXgLSriu+fndTlzeTYcy0TIWpG0jIuGFe/NjASOBHs4bKMMhsaDpBRNqAEtScp
hy5sadPqpMjIzqaOAo4+8EfucZ1hGk1mxm8P4HBgmUJwlIxj7Hl+bGzfzucdvOG6
JtogP70WXDcA4ZiJ/e+l4AsWf6lSd/UL0lfNEvgSEIE1KM/LKdFzhp9dLYEvFVQi
KQITPgQwuBi6zIbGrVsdHbcT/VMu19iez2B9Qg/ZWyV1/F+5EAyPZ3ZZrSiXhuMX
QPCBsNCv+IrVOQBHuuadjKOKuHZiZQndVxBzovSaTQhMHhqby2CIiJjxq3erroJW
+rl5gRijewKT93zt/UOOibllTVbRTgn1Bf1BB4WS90xa2hSHV//SfCfjG1HtClE9
p32KpYBRgv2b2Q1ZaU7FkgJu5pJNzeufWmQIcLykoWPeOVbIc2P67kQtJYAccUNv
em3fqCcCCSARkaP+yKE91Xmv0AyZqsQioxI2BoKhQq9loYsj5kvZvSvemrE30PZO
ORM63N5dKjfRFJFlo8VB
=/uj7
-----END PGP SIGNATURE-----