Cioè Signal sta sul Cloud di Amazon

[jones@todon.nl]

@agitacion @lorcon @lorenzo @valhalla @kappazeta @ju

In altre parole: ci sta che all'installazione il server riceva, e solo in quella circostanza, il numero per poterti mandare l'SMS di attivazione (ma è ancora così realmente?), però ci sta che il codice ufficiale del server mostri che quel numero non viene salvato da nessuna parte o che venga cancellato subito dopo che la verifica del numero è stata effettuata, oppure, se non viene effettuata, dopo un tot di tempo (tipo che so, 24 ore); e in quel caso però non possiamo escludere che il codice del software server che gira sui server di Signal sia diverso da quello pubblicato (cosa che non possiamo escludere nemmeno per qualsiasi server XMPP).

(2/2)

[agitacion@kolektiva.social]

@jones @lorcon @lorenzo @valhalla @kappazeta @ju cosi al volo qui vedo qualche fonte https://security.stackexchange.com/questions/272982/does-signal-store-mobile-phone-numbers-server-side-in-plain-text ma se trovo di meglio le giro.

A questo va aggiunta la questione Sealed Sender, che non fa quello che si propone di fare (proteggere i numeri di telefono e gli IP):

https://sanesecurityguy.com/articles/signal-knows-who-youre-talking-to/

e oltre

https://arxiv.org/abs/2305.09799

Il fatto di trafficare con i numeri di telefono della gente apre una superficie di attacco abnorme, che incrociata con gli IP e con il traffico a due vie delle chat fa il disastro.

Questo credo sia un problema della sicurezza nelle chat in generale: in alcuni scenari di attacco è piu debole un singolo enorme DB dove fare comodamente analisi rispetto a un sistema federato che non ha mai completa vista sul sistema, in altri il sistema federato è peggio perche deve fare viaggiare piu metadati tra i nodi (punto superdebole di Matrix).

Riguardo alla verificabilità di quello che gira sui server dei servizi che usiamo ho una obiezione: sul _mio_ server lo so cosa gira, e ho anche solide informazioni al riguardo sui server XMPP su cui sono ospitati alcuni miei contatti :)
Non è molto ma meglio che niente o che AWS.

[jones@todon.nl]

@agitacion @lorcon @lorenzo @valhalla @kappazeta @ju

Grazie, tutta roba interessante, il problema è che ora non ho tempo di leggermela, e so per certo che, in questo campo più che in tutti gli altri dell'informatica, ci sono guerre "di religione" che portano tanta gente e spesso a spalare merda sulla tecnologia diversa da quella per cui tifano, e non di rado è pure gente "prezzolata" da quelli per cui tifano. Quindi insomma per risponderti a ragion veduta dovrei leggermi le quintalate di roba e ora non ho proprio tempo, sono in partenza, può darsi che lo faccia nei prossimi giorni, può anche darsi di no e che magari lo farò più in là, mi limito per ora a ribadire quello che ho già scritto qui, https://todon.nl/@jones/115407757192860510, che, mi pare, resta tutto vero.

[valhalla@social.gl-como.it]

@jones @lorcon @kappazeta @agitacion @ju @lorenzo ragioni che, a quanto ne so, arrivano dalle comunicazioni degli autori di signal, che sono altrettanto di parte e propensi a spalare merda sulle altre tecnologie.

per dirne una, no, far fare un audit di sicurezza all'anno non è il modo in cui la stragrande magioranza dei progetti di software libero si occupa di verificare la propria sicurezza, perché è un modo estremamente inefficiente di usare le risorse limitate a disposizione del progetto.

[jones@todon.nl]

@valhalla @lorcon @kappazeta @agitacion @ju @lorenzo

Per chi ha i soldi per farli, gli audit di terze parti mi sembrano un metodo più tutelante lə utentə rispetto a quelli interni alla comunità, che per altro non ho mai visto.

[valhalla@social.gl-como.it]

@jones @lorcon @kappazeta @agitacion @ju @lorenzo ah, certo, se uno può farli sono utili, ma dire che altri sistemi non sono sicuri perché non hanno fatto un audit di sicurezza è quantomeno fuorviante

[jones@todon.nl]

@valhalla @lorcon @kappazeta @agitacion @ju @lorenzo
Io non ho detto che altri sistemi di controllo del codice non sono sicuri, ho detto solo che se quelli di protocolli come xmpp, e di tutti i tanti client e server che lo implementano, sono controlli fatti suppergiù dalla stessa comunità che li sviluppa, mi pare che siano meno sicuri, poi non so se sono questi i sistemi cui ti riferisci, è un'ipotesi che faccio, se mi dici come funziona il controllo del codice delle app e dei server xmpp, con qualche link di esempio, sono contento e magari cambio idea.
(Non so se sia vero che la comunità dellə utent* di Signal sia "religiosa", io guardo quasi soltanto il blog e i post deə dev sul forum, spero che tu non ti riferisca a me comunque quando dici che sono "religiosi", perché ho scritto a più riprese in questo thread che penso che Signal potrebbe migliorare assai se prendesse esempio da xmpp per quanto riguarda la federabilità dei server, ecc., anche se continuo a reputarlo più sicuro già allo stato attuale rispetto a xmpp, poi magari quando e se leggerò i link girati da calmapiatta cambierò idea).

[valhalla@social.gl-como.it]

@jones @lorcon @kappazeta @agitacion @ju @lorenzo no, non la comunità, io dicevo i dev

[jones@todon.nl]

@valhalla @lorcon @kappazeta @agitacion @ju @lorenzo
Ə dev di signal sono "religiosi" e spalano merda sugli altri programmi? Boh a me non è mai capitato di leggere, sul blog sul sito o sul forum, dev di signal che nemmeno scrivessero genericamente di altri programmi, ma è anche vero che è da un po' che non seguo, però mi farebbe strano. Anche su questo, se hai link di esempio di quel che hai scritto, mettili.

[valhalla@social.gl-como.it]

@jones @lorcon @kappazeta @agitacion @ju @lorenzo il post famoso era signal.org/blog/the-ecosystem-…

(ci sono in giro risposte varie di sviluppatori di altri sistemi che spiegano perché la maggior parte di quello che dicevano in quel post è falso)