On Thursday 30 March 2017 17:43:55 torn wrote:
> On 2017-03-30 17:11, Gio wrote:
> > On Thursday 30 March 2017 16:38:30 torn wrote:
> >> Intanto Signal è l'unico sistema dove tutto il codice è disponibile:
> >> client, server e librerie varie. Negli altri casi o è tutto
> >> proprietario, o è libero solo il client, che non è molto interessante.
> >
> > Da questa frase sembra che i tuoi altri casi in realta' siano un
> > sottoinsieme particolarmente ristretto... puoi esplicitare qual'e' il
> > sottoinsieme che stai considerando? Altrimenti st'affermazione e'
> > semplicemente falsa.
>
> Mi riferivo in particolare a quelli non-xmpp menzionati dall'articolo,
> ma penso sia vero per tutti i non-xmpp menzionati per esempio qui:
>
> https://www.eff.org/node/82654
>
> e in più anche per Wire.
>
> >> Poi ci sono delle scelte di sviluppo buone, non solo fatte con l'ottica
> >> di scriverci sopra "Private". Un esempio: il server non ha il concetto
> >> di "gruppo". I gruppi vivono solo nei client, quindi il server non ha
> >> mai accesso al delicatissimo metadato "gruppo".
> >
> > Dai questa e' troppo ingenua... Stai scherzando o per davvero secondo te
> > basta che il server non abbia il concetto di gruppo per nascondere quel
> > meta-dato li?
>
> Penso faccia parecchia differenza, è chiaro che analizzando il traffico
> per abbastanza tempo puoi fare delle deduzioni.
Nel caso di una chat di gruppo il l'abbastanza e' veramente molto piccolo
> Come sempre dipende da
> dove vuoi tracciare la linea del compromesso, tempo però che spingendola
> di più verso la paranoia tu debba iniziare rinunciare alla funzionalità
> "gruppi", per rimanere in questo esempio.
Non si tratta di paranoia, si tratta di prendersi cura della propria sicurezza
>
> >>> Perché invece il protocollo federato c'è già (XMPP), per cui la domanda
> >>> naturale è: cosa offre una versione "liberata" di Signal che non offrono
> >>> XMPP & conversations?
> >>
> >> La domanda è giusta. Ci sono secondo me alcune differenze sostanziali
> >
> >> anche rispetto all'ideale (XMPP+OMEMO):
> > Direi che e' meglio ma lungi dall'ideale
>
> Forse devo dire: ideale ed esistente.
Il punto e' che se non ci aveste dedicato non so quante ore di sforzo non
sarebbe esistente nemmeno la vostra soluzione, che anche se e' un'esperimento
interessante non sembra ideale e lo sapevate fin dal principio, di fatto direi
che di ideale e di esistente non ne esistono di esempi, pero' IMHO e' meglio
quando ci mettiamo a fare gli esperimenti un attimo tenere in conto di piu' le
nostre utopie, perche' se ci autolimitiamo ad esplorare strade che sappiamo
gia' ci portano in posti di cui non ci piace l'odore, perche' ci hanno detto
che le altre strade so troppo difficili, di posti profumati non ne troveremo
mai.
>
> >> - La barriera d'ingresso è bassissima e la logica d'uso corrisponde a
> >> ciò che l'utente si aspetta oggi. In particolare l'utente non deve
> >> crearsi una nuova identità, ma lega un'identità che già ha (il numero di
> >> telefono) ad un servizio. Ricordi il thread "siamo sul pezzo?" di mesi
> >> fa?
> >
> > Ma quindi anche col vostro servizio devo avere un cavolo di numero di
> > telefono?
> > Questa e' una antifeature...
>
> Ecco questo è un punto interessante. È un'antifeature per te, e ne vedo
> i motivi, ma per molti invece è una svolta. Su questo punto comunque
> abbiamo ragionato e ci sono un paio di alternative. La più plausibile è
> di rendere possibile la registrazione con un indirizzo email al posto
> del numero di telefono.
E mi sembra importantissimo che per l'utente sia possibile registrarsi senza
numero, e che sia incoraggiata a non usare il numero di telefono.
>
> >> - Dal punto precedente segue che esiste automaticamente una rete
> >> sociale: è la tua rubrica di contatti.
> >
> > E il server la sa anche lui ve?
>
> Funziona così: tu mandi un hash dei numeri di telefono dei tuoi contatti
> e il server risponde con l'intersezione tra gli hash che hai mandato e
> gli hash di numeri degli utenti registrati. Da questo viene generata
> (localmente) la lista dei tuoi contatti Signal/Cable.
>
> Lettura interessante: https://whispersystems.org/blog/contact-discovery
Il link non so cosa dica, ma fare l'hash del numero di telefono pensando che
migliori la privacy e' molto ingenuo, visto che a calcolarti tutti gli hash
dei numeri di telefono e' quasi un attimo...
[[[ref:rinuncia]]]
> È molto più di valore sapere a quali contatti scrivi attivamente. Questo
> il server non lo logga, ma potenzialmente può, e non se ne esce.
...
> La federazione aiuta perché puoi scegliere un server di cui ti fidi.
Ok quindi ci deve essere scritto molto molto grosso sulla toolbar del client
che ti stai fidando del server, se vuoi essere veramente amico con gli utenti
> L'alternativa è solo un sistema P2P puro,
Specifica puro please.
Se no a me sembra che non facciamo entrare i cani ;)
> che però non va bene perché
> non permette comunicazione asincrona.
Assertion failed!
https://gitlab.com/g10h4ck/RetroShare/tree/gxs_mail_experiments/libretroshare/src/gxstrans
> >> - Il protocollo è pensato dal principio per comunicazioni private,
> >> criptate e che non perdano metadati in giro.
> >
> > A me invece sembra l'opposto, nel caso di signal mi sembra che ci sia
> > proprio una rinuncia sul fronte metadati
>
> Ma rispetto a cosa?
Vedi <<ref:rinuncia>>
