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

[vecna]

Tommaso "Sanata" Gagliardoni wrote:
> Textwall incoming!
TL;DR

:P

> 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 
> 4) i giornalisti/blogger/attivisti che daranno risalto alle notizie
> 5) il pubblico
tutto giusto

> 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
perfetto

> 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:
mi piaciono le analisi fatte in questo modo :) permettono di vedere cose
che altrimenti non si pensano in modo intuitivo

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

il gestore del nodo dovrebbe avere una responsabilità *nulla*, di fatto
ne pubblica ne stora i dati. questo è importante come elemento, poi
certo, la nostra interpretazione di responsabilità nulla magari non è la
stessa che avrebbe un avvocato.


>         |    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).

giusto, uno degli obiettivi è anche questo. che so, il CCC, o gli
amici-di-beppegrillo, mettono su il loro nodo. pero' i nodi non devono
essere attaccabili, quindi i dati di leak, le tracce e le segnalazioni
che lasciano i leaker, devono essere protetti al meglio. freenet o
hidden service sono *essenziali*.

> 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).
umh, non proprio ... non si tratta di WOT personale, si parla di dire
che il nodo gestito da gli-amici-di-beppegrillo vede che non è l'unico
nodo italiano, ne è l'unico nodo sensibile al problema dei mufloni
tedeschi. allora linka il nodo indymedia-italia e il nodo saven-muflonen
di bolzano.

quando il leaker si collega a loro, ha l'opzione (o è automatico, boh)
di fare commit anche sugli altri 2 nodi fidati sopracitati.

sarebbe la stessa cosa se il leaker andasse separatamente su due nodi
diversi a fare lo stesso commit, solo che così è piu' efficente.

> 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".
eh no, è onere del leaker descrivere il suo materiale, indicare delle
keyword, e pure risolvere un po' di captcha, mi auguro :)

e questo è necessario, perché la distribuzione deve funzionare
necessariamente a liste. ad esempio, il nodo saven-muflonen ha la lista
di giornalisti di politica tedesca, giornalisti politici italiani,
giornalisti sportivi, altro. quando il leaker arrivo si trova queste 3
checkbox. ne segna una. se ne segna una, la roba arriva anche subito (se
non ci sono pattern di spam), e non ne segna nessuna, viene segnata come
spam e deve essere moderata. altrimenti in tempo 0, ogni elemento scelto
(attivista, blogger, giornalista, investigatore di PG) si trova
subissato di roba che non gli compete.

> 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.
il rogue è un rischio e per questo il trust va guadagnato, non regalato
per questioni di convenienza algoritmica. il rogue comunque si supera
nel momento in cui il leaker si affida a N nodi, così che la volontà di
censura di uno non blocchi l'informazione.

> 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).
eh si. o seno cazzi suoi :) non gli dice nessuno di fare il leaker, ma
almeno che abbia uno strumento a disposizione.

> "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.
il mantainer non è anonimo, è, diciamo, pseudoanonimo. ma non ha dati,
non fa editing, non fa publishing.


> 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%
bellissima visione, un nodo maschera gli altri assimilando le competenze
propagate, ottimo modo per spiegarlo :)


> 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')
tu gestore del nodo, non è necessario ricevi i leak. certo, puoi
iscriverti alla lista di destinatari...

> _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).
ok

> 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
giusto questo e quello che segue

> 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?".
no, penso sia così. il nodo sceglie il destinatario, e il destinatario,
se non ne vuole sapere, lo mette in blacklist.

il destinatario comunque riceve un link decifrabile con una password
comunicatagli di volta in volta, perché deve essere protetto dal
ricevere robaccia.

> 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:
comunque la tua idea è ottima, una segnalazione volontaria aiuterebbe di
certo
a non far sembrare la cosa come mera invasiva selezione non richiesta.

>  - 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:

la password serve solo per evitare che lui distribuisca il link
ricevuto. la password serve per farlo accedere al documento leakato lui
e solo lui. metti, parte della password potrebbe essere anche il suo
contatto email :P

> 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 :)
a questo ci pensernno i PR :P


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <http://lists.winstonsmith.org/pipermail/e-privacy/attachments/20101218/784fed06/attachment.pgp>