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. 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.
>>> 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.
>> - 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.
>> - 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
È molto più di valore sapere a quali contatti scrivi attivamente. Questo
il server non lo logga, ma potenzialmente può, e non se ne esce.
L'alternativa è solo un sistema P2P puro, che però non va bene perché
non permette comunicazione asincrona.
La federazione aiuta perché puoi scegliere un server di cui ti fidi.
>> - 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?
t.
