Link alla notizia: https://www.hwupgrade.it/news/web/il-ceo-di-whatsapp-all-attacco-telegram-fornisce-dati-degli-utenti-al-governo-russo_114149.html

La piattaforma di messaggistica Telegram è stata accusata di aver depistato i suoi utenti sulla*sicurezza*della piattaforma. Un articolo di Wired, commentato dal CEO di WhatsApp, ha svelato nuove informazioni.

Click sul link per visualizzare la notizia.

Non capisco,

il backup di WhatsApp su Google Drive è comunque crittografato. In che modo Google potrebbe leggerli?

Non capisco,

il backup di WhatsApp su Google Drive è comunque crittografato. In che modo Google potrebbe leggerli?

La cifratura dei backup è una feature introdotta solo di recente, credo l'anno scorso. Tra l'altro credo sia disabilitata di default e vada attivata esplicitamente, ma su quest'ultima cosa non sono certo perché non ho mai attivato il backup su Google Cloud (ho impostato WA solo per fare backup locali).

La cifratura dei backup è una feature introdotta solo di recente, credo l'anno scorso. Tra l'altro credo sia disabilitata di default e vada attivata esplicitamente, ma su quest'ultima cosa non sono certo perché non ho mai attivato il backup su Google Cloud (ho impostato WA solo per fare backup locali).

Su WhatsApp è di default (quindi anche i backup su Drive), su Telegram no, quindi direi che il CEO di Telegram ha ben poco da sgallettare.

Su WhatsApp è di default (quindi anche i backup su Drive), su Telegram no, quindi direi che il CEO di Telegram ha ben poco da sgallettare.

Si ma non bisogna confondere l'End-to-End Encryption con la cifratura dei backup delle chat.

Nel primo caso parliamo di cifratura delle comunicazioni mentre sto chattando/parlando con un'altra persona, cioè comunicazioni "live"; nel secondo caso parliamo di cifratura di dati così detti *at rest* cioè "a riposo" sul disco.

Come già detto, WhatsApp non supportava la cifratura dei backup su Google Drive fino a poco tempo fa.

Tant'è vero che sempre qualche tempo fa uscì un documento dell'FBI (leak) che riportava lo stato di "intercettibilità" dei programmi di messagistica e WhatsApp su iPhone veniva contrassegnato come "intercettabile" ma *SOLO* per via dei backup delle chat.

Riguardo Telegram, le conversazioni di default non supportano cifratura End-to-End (quindi passano dai server Telegram), ma da quello che so è possibile attivarla usando la funzionalità delle "Chat Segrete".

Comunque WhatsApp se non ricordo male usa una variante dello stesso protocollo Noise usato da Signal, e ad oggi non dovrebbero essere note vulnerabilità particolari.

La critica maggiore mi sembra sia relativa al fatto che sia possibile conoscere dai metadati chi parla con chi, ma non il contenuto.

Comunque è chiaro che tweet di questo tipo hanno esclusiva natura commerciale. Telegram ha rubato un sacco di clienti a WhatsApp all'epoca dell'infame privacy policy.

Si ma non bisogna confondere l'End-to-End Encryption con la cifratura dei backup delle chat.

Nel primo caso parliamo di cifratura delle comunicazioni mentre sto chattando/parlando con un'altra persona, cioè comunicazioni "live"; nel secondo caso parliamo di cifratura di dati così detti *at rest* cioè "a riposo" sul disco.



Se è cifrata la chat, non vedo perché non debba esserlo anche il suo backup.



Come già detto, WhatsApp non supportava la cifratura dei backup su Google Drive fino a poco tempo fa.



Adesso si però.


Riguardo Telegram, le conversazioni di default non supportano cifratura End-to-End (quindi passano dai server Telegram), ma da quello che so è possibile attivarla usando la funzionalità delle "Chat Segrete".



Se una cosa non è di default, non la usa quasi nessuno.

Il DB delle chat di WhatsApp è criptato da tantissimi anni.
All'inizio veniva fatto il bakcup di tutto chiave compresa, in questo modo google e whatsapp potevano accederci.
Poi hanno cambiato e la chiave non è più salvata insieme al backup, ma è legata al numero di telefono, in questo modo whatsapp poteva leggere ancora i backup.
Di recente (un anno e mezzo fa) hanno introdotto una password che l'utente può impostare per proteggere il backup, in questo modo solo l'utente può accedere al backup.
Questo per Android, su iPhone non so se hanno le stesse possibilità.

Nel dubbio: Signal tutta la vita :D :D

WhatsApp è letteralmente uno spyware, roba che avrebbe fatto esplodere un Pc di 20 anni fa con installato Zone Alarm.

Nel dubbio: Signal tutta la vita :D :D

Quoto e aggiungo Briar e Session

il legame Telegram russia è spiegato bene nella storia.
Adesso la sede legale è a dubai.
Proprio per non essere in russia.

Come scritto da altri utenti, whatsapp utilizza la crittografia e2e di default per le comunicazioni, mentre i backup su google drive e icloud non sono crittografati con crittografia e2e di default (https://faq.whatsapp.com/1246476872801203/?locale=en_US).
Inoltre, il codice sorgente di whatsapp lato client e server non è disponibile e i binari del client sono offuscati. Non c'è modo di verificare quale sia l'implementazione effettiva della crittografia di whatsapp, occorre fidarsi di facebook (meta).

Un recente articolo FBI document shows what data can be obtained from encrypted messaging apps (https://therecord.media/fbi-document-shows-what-data-can-be-obtained-from-encrypted-messaging-apps/) mostra cosa possa ottenere FBI dai vari servizi e whatsapp è molto peggio di telegram.

Secondo questi due servizi ToSDR (https://tosdr.org/en/about) e PrivacySpy (https://privacyspy.org/about/):

Whatsapp C (https://tosdr.org/en/service/198) e 4.7 (https://privacyspy.org/product/whatsapp/)
Telegram B (https://tosdr.org/en/service/1946) e 8.8 (https://privacyspy.org/product/telegram/)


Il protocollo di crittografia di Telegram è testato alla pari di quello di Signal:

Automated Symbolic Verification of Telegram's MTProto 2.0 (https://arxiv.org/abs/2012.03141)
Security Analysis of Telegram (Symmetric Part) (https://mtpsym.github.io/)


P.S. comunque su telegram stiamo aspettando un'implementazione della crittografia e2e anche per i gruppi con un sistema di backup e approvazione delle sessioni come quello di element/matrix (https://element.io/blog/e2e-encryption-by-default-cross-signing-is-here/).

La cifratura dei backup è una feature introdotta solo di recente, credo l'anno scorso. Tra l'altro credo sia disabilitata di default e vada attivata esplicitamente, ma su quest'ultima cosa non sono certo perché non ho mai attivato il backup su Google Cloud (ho impostato WA solo per fare backup locali).

Bravo, i backup sempre offline su supporto apposito fatto per resistere negli anni.
Si ricorda sempre che tutto quello che e' connesso alla rete e' per sua natura vulnerabile.

Come scritto da altri utenti, whatsapp utilizza la crittografia e2e di default per le comunicazioni, mentre i backup su google drive e icloud non sono crittografati con crittografia e2e di default (https://faq.whatsapp.com/1246476872801203/?locale=en_US).
Inoltre, il codice sorgente di whatsapp lato client e server non è disponibile e i binari del client sono offuscati. Non c'è modo di verificare quale sia l'implementazione effettiva della crittografia di whatsapp, occorre fidarsi di facebook (meta).

Un recente articolo FBI document shows what data can be obtained from encrypted messaging apps (https://therecord.media/fbi-document-shows-what-data-can-be-obtained-from-encrypted-messaging-apps/) mostra cosa possa ottenere FBI dai vari servizi e whatsapp è molto peggio di telegram.

Secondo questi due servizi ToSDR (https://tosdr.org/en/about) e PrivacySpy (https://privacyspy.org/about/):

Whatsapp C (https://tosdr.org/en/service/198) e 4.7 (https://privacyspy.org/product/whatsapp/)
Telegram B (https://tosdr.org/en/service/1946) e 8.8 (https://privacyspy.org/product/telegram/)


Il protocollo di crittografia di Telegram è testato alla pari di quello di Signal:

Automated Symbolic Verification of Telegram's MTProto 2.0 (https://arxiv.org/abs/2012.03141)
Security Analysis of Telegram (Symmetric Part) (https://mtpsym.github.io/)


P.S. comunque su telegram stiamo aspettando un'implementazione della crittografia e2e anche per i gruppi con un sistema di backup e approvazione delle sessioni come quello di element/matrix (https://element.io/blog/e2e-encryption-by-default-cross-signing-is-here/).

Io ho "sparato" Signal semplicemente perchè è un fork si Whatsapp senza feature per ragazzini :D :D , ma è da sempre che Telegram è molto più avanti di Whatsapp: anzi molte delle feature oggi presenti su WA sono copiate a mani basse da TLG.

La verità è comunque che queste considerazioni le facciamo in pochi, la stragrande parte degli utenti (e l'ho verificato con i miei amici e conoscenti) anche quando gli dici che ti rivendono i dati, che non è sicuro, ti rispondono (anche correttamente) che lo usano tutti, mentre Telegram o Signal no.
In effetti della mia rubrica telefonica il 100% ha WA, mentre forse 1/3 ha Telegram, per non paralre di Signal: solo 2 oltre a me.

E' il mercato che dicide il successo, non la tecnologia e non è il primo esempio della storia (penso ai minidisc, al magneto ottico, alle cassette video2000...scusate mi sa che sono vecchio con queste citazioni :D )

In effetti della mia rubrica telefonica il 100% ha WA, mentre forse 1/3 ha Telegram, per non paralre di Signal: solo 2 oltre a me.


Stessa cosa, io WA lo uso solo nel telefono del lavoro, nel mio non l'ho mai installato, uso Telegram (che uso anche come social network) e Signal.
Ricordo quando ci fu il cambio delle politiche sulla privacy di WA, in un gruppo in cui ero iscritto successe un casino, tutti volevano toglierlo e passare ad altro, alla fine il gruppo fu riaperto su Signal e Telegram, su Signal ci trovammo in meno di dieci, su Telegram una ventina ... poi entrambi i gruppi morirono e sopravvisse solo quello su WA, tante urla, "famo arivoluzzzzione" e poi non riescono a cambiare una app di messaggistica :rotfl: :rotfl: :rotfl:

Come scritto da altri utenti, whatsapp utilizza la crittografia e2e di default per le comunicazioni, mentre i backup su google drive e icloud non sono crittografati con crittografia e2e di default (https://faq.whatsapp.com/1246476872801203/?locale=en_US).
Inoltre, il codice sorgente di whatsapp lato client e server non è disponibile e i binari del client sono offuscati. Non c'è modo di verificare quale sia l'implementazione effettiva della crittografia di whatsapp, occorre fidarsi di facebook (meta).

Un recente articolo FBI document shows what data can be obtained from encrypted messaging apps (https://therecord.media/fbi-document-shows-what-data-can-be-obtained-from-encrypted-messaging-apps/) mostra cosa possa ottenere FBI dai vari servizi e whatsapp è molto peggio di telegram.

Secondo questi due servizi ToSDR (https://tosdr.org/en/about) e PrivacySpy (https://privacyspy.org/about/):

Whatsapp C (https://tosdr.org/en/service/198) e 4.7 (https://privacyspy.org/product/whatsapp/)
Telegram B (https://tosdr.org/en/service/1946) e 8.8 (https://privacyspy.org/product/telegram/)


Il protocollo di crittografia di Telegram è testato alla pari di quello di Signal:

Automated Symbolic Verification of Telegram's MTProto 2.0 (https://arxiv.org/abs/2012.03141)
Security Analysis of Telegram (Symmetric Part) (https://mtpsym.github.io/)


P.S. comunque su telegram stiamo aspettando un'implementazione della crittografia e2e anche per i gruppi con un sistema di backup e approvazione delle sessioni come quello di element/matrix (https://element.io/blog/e2e-encryption-by-default-cross-signing-is-here/).

Se vedi l'asterisco vicino a "message content limited", noterai che è riferito solo ai dispositivi Apple, in quanto fanno il backup su iCloud, che non è zero-access.

Allo stato dei fatti: Telegram è più a rischio di WhatsApp.
Per WhatsApp (o simili) devi solo custodire bene il backup, o meglio, la chiave.
Per Telegram dei fidarti della parola di Telegram e di chiunque lo gestirà in futuro, oggi promette di non condividere, un domani potrebbe essere, da un giorno all'altro, acquisito da terzi che cambieranno completamente politica sulla riservatezza dei dati, senza contare poi che il rischio di violazione dei server, e del server neanche non si ha nulla per verificarne la qualità effettiva.

PrivacySpy in ogni caso lascia il tempo che trova... sono calcoli fatti con i piedi, per dire...
https://privacyspy.org/product/element/
Ad Element tiene in considerazione quando clicchi la pubblicità su siti esterni, cosa che non ha nulla a che vedere con il sistema di messaggistica.

Io ho "sparato" Signal semplicemente perchè è un fork si Whatsapp senza feature per ragazzini :D :D , ma è da sempre che Telegram è molto più avanti di Whatsapp: anzi molte delle feature oggi presenti su WA sono copiate a mani basse da TLG.

La verità è comunque che queste considerazioni le facciamo in pochi, la stragrande parte degli utenti (e l'ho verificato con i miei amici e conoscenti) anche quando gli dici che ti rivendono i dati, che non è sicuro, ti rispondono (anche correttamente) che lo usano tutti, mentre Telegram o Signal no.
In effetti della mia rubrica telefonica il 100% ha WA, mentre forse 1/3 ha Telegram, per non paralre di Signal: solo 2 oltre a me.

E' il mercato che dicide il successo, non la tecnologia e non è il primo esempio della storia (penso ai minidisc, al magneto ottico, alle cassette video2000...scusate mi sa che sono vecchio con queste citazioni :D )

Signal non è un fork di WhatsApp

occorre fidarsi di facebook (meta).
:sbonk:


Allo stato dei fatti: Telegram è più a rischio di WhatsApp.
Per WhatsApp (o simili) devi solo custodire bene il backup, o meglio, la chiave.
Per Telegram dei fidarti della parola di Telegram e di chiunque lo gestirà in futuro, oggi promette di non condividere, un domani potrebbe essere, da un giorno all'altro, acquisito da terzi che cambieranno completamente politica sulla riservatezza dei dati, senza contare poi che il rischio di violazione dei server, e del server neanche non si ha nulla per verificarne la qualità effettiva.

Allo stato dei fatti i messaggi su Telegram o WhatsApp sono da considerare a tutti gli effetti pubblici e a disposizione di cani e porci :stordita:

Io ho "sparato" Signal semplicemente perchè è un fork si Whatsapp senza feature per ragazzini :D :D , ma è da sempre che Telegram è molto più avanti di Whatsapp: anzi molte delle feature oggi presenti su WA sono copiate a mani basse da TLG.

La verità è comunque che queste considerazioni le facciamo in pochi, la stragrande parte degli utenti (e l'ho verificato con i miei amici e conoscenti) anche quando gli dici che ti rivendono i dati, che non è sicuro, ti rispondono (anche correttamente) che lo usano tutti, mentre Telegram o Signal no.
In effetti della mia rubrica telefonica il 100% ha WA, mentre forse 1/3 ha Telegram, per non paralre di Signal: solo 2 oltre a me.

E' il mercato che dicide il successo, non la tecnologia e non è il primo esempio della storia (penso ai minidisc, al magneto ottico, alle cassette video2000...scusate mi sa che sono vecchio con queste citazioni :D )

Whatsapp ha circa 2000 M MAU contro gli oltre 700 M MAU di Telegram. Al momento a livello di diffusione sta vincendo il primo, vedremo in futuro.

Se vedi l'asterisco vicino a "message content limited", noterai che è riferito solo ai dispositivi Apple, in quanto fanno il backup su iCloud, che non è zero-access.

Dal link precedente (https://faq.whatsapp.com/1246476872801203/?locale=en_US):

WhatsApp provides end-to-end encryption for all personal messages that you send and receive to ensure that only you and the person you’re talking to can read or listen to them. With end-to-end encrypted backup, you can also add that same layer of protection to your iCloud and Google Drive backups.

E' sufficiente che un solo membro di un gruppo abbia il backup attivo su google drive o icloud senza crittografia e2e per invalidarla per qualunque altro utente. Le uniche chat veramente e2ee sono quelle 1:1 per qualunque servizio di comunicazione. Nel caso di un gruppo per non avere troppo overhead di comunicazione anziché aprire N canali di comunicazione 1:1, viene condivisa una chiave simmetrica tra i partecipanti. Qui (https://eprint.iacr.org/2021/498.pdf) c'è un ottimo articolo comparativo.


Allo stato dei fatti: Telegram è più a rischio di WhatsApp.
Per WhatsApp (o simili) devi solo custodire bene il backup, o meglio, la chiave.
Per Telegram dei fidarti della parola di Telegram e di chiunque lo gestirà in futuro, oggi promette di non condividere, un domani potrebbe essere, da un giorno all'altro, acquisito da terzi che cambieranno completamente politica sulla riservatezza dei dati, senza contare poi che il rischio di violazione dei server, e del server neanche non si ha nulla per verificarne la qualità effettiva.

E' vero il contrario. Con whatsapp ti devi fidare sia di facebook (meta) poiché le applicazioni sono closed source e i binari offuscati e nessuno ti garantisce che cosa facciano effettivamente sia del gestore del cloud google o apple che legge i backup. In passato sono già stati beccati a cambiare la chiave di crittografia dei contatti, un vero e proprio attacco MITM (https://arstechnica.com/information-technology/2017/01/whatsapp-and-friends-take-umbrage-at-report-its-crypto-is-backdoored/), senza notificarlo all'utente (l'impostazione è ancora disattivata di default).
Su telegram le applicazioni sono open source con build riproducibili (https://core.telegram.org/reproducible-builds) e quindi se utilizzi le chat segrete e2ee non ti devi fidare di nessuno. Con gli altri tipi di chat di devi fidare di telegram, una singola entità rispetto alle due di whatsapp.
I rischi che riporti sono tutti veri e si sono già verificati per whatsapp con l'acquisizione da parte di facebook.


PrivacySpy in ogni caso lascia il tempo che trova... sono calcoli fatti con i piedi, per dire...
https://privacyspy.org/product/element/
Ad Element tiene in considerazione quando clicchi la pubblicità su siti esterni, cosa che non ha nulla a che vedere con il sistema di messaggistica.


Non ho capito quale punto non ti sia chiaro. Comunque se pensi ci siano degli errori, puoi aprire una issue su github e se verrà accettata cambieranno le valutazioni. Altrimenti non serve molto criticare.

Dal link precedente (https://faq.whatsapp.com/1246476872801203/?locale=en_US):

WhatsApp provides end-to-end encryption for all personal messages that you send and receive to ensure that only you and the person you’re talking to can read or listen to them. With end-to-end encrypted backup, you can also add that same layer of protection to your iCloud and Google Drive backups.

Innanzi tutto l'immagine da te postata risale al 2021, quando la crittografia end-to-end per i backup ancora non era disponibile per WhatsApp.
Ma, come fatto notare da altri utenti, su Android aveva già una crittografia più debole (ma sempre crittografia era).

Mentre sui dispositivi Apple, il discorso si fa più complesso con il meccanismo di backup di iCloud, dove anche Signal infatti non ha introdotto il backup su iCloud proprio per la ragione che non è sufficientemente sicuro.
Qui una lunga discussione dove puoi trovare alcune spiegazioni a riguardo
https://community.signalusers.org/t/ios-backup-keeping-message-history-when-switching-phones/1736

E' sufficiente che un solo membro di un gruppo abbia il backup attivo su google drive o icloud senza crittografia e2e per invalidarla per qualunque altro utente. Le uniche chat veramente e2ee sono quelle 1:1 per qualunque servizio di comunicazione.
Nel caso di un gruppo per non avere troppo overhead di comunicazione anziché aprire N canali di comunicazione 1:1, viene condivisa una chiave simmetrica tra i partecipanti. Qui (https://eprint.iacr.org/2021/498.pdf) c'è un ottimo articolo comparativo.

Non me ne volere, ma credo tu stia condividendo una marea di documenti tecnici e non, senza capirci molto degli stessi (vedi anche questione backdoor).

Mentre stiamo parlando della cifrature del backup (dove indubbiamente viene invalidata nel caso dell'anello debole del gruppo), hai tirato in ballo il metodo di cifratura delle chat e dei gruppi, che è una questione completamente differente.

Inoltre sentir parlare di "viene condivisa una chiave simmetrica" mentre stiamo parlando di applicazioni dove per ogni conversazione di chiavi simmetriche e/o asimmetriche ce ne sono diverse, mi lascia senza parole.


E' vero il contrario. Con whatsapp ti devi fidare sia di facebook (meta) poiché le applicazioni sono closed source e i binari offuscati e nessuno ti garantisce che cosa facciano effettivamente sia del gestore del cloud google o apple che legge i backup. In passato sono già stati beccati a cambiare la chiave di crittografia dei contatti, un vero e proprio attacco MITM (https://arstechnica.com/information-technology/2017/01/whatsapp-and-friends-take-umbrage-at-report-its-crypto-is-backdoored/), senza notificarlo all'utente (l'impostazione è ancora disattivata di default).
Su telegram le applicazioni sono open source con build riproducibili (https://core.telegram.org/reproducible-builds) e quindi se utilizzi le chat segrete e2ee non ti devi fidare di nessuno. Con gli altri tipi di chat di devi fidare di telegram, una singola entità rispetto alle due di whatsapp.
I rischi che riporti sono tutti veri e si sono già verificati per whatsapp con l'acquisizione da parte di facebook.

Il contrario assolutamente no.
La verità è che vale per entrambi.

Entrambi hanno il codice lato server chiuso.
Telegram ha il client open-source ma conserva i dati nei suoi server. Ed ha il capo poco credibile come Musk, e non appena si alzarono le critiche per alcune scelte recente (come la vendita degli username) blocco immediatamente i commenti sul canale di Telegram e sul suo, dopo che ha predicato "libertà di parola" ogni 3 secondi e come cavallo di battaglia (Esattamente come Musk), mi guarderei bene dal fidarmi di lui e di quello che dice.
WhatsApp ha il client closed, ma non conserva i dati. Ed i backup sono ora crittografati lato client. Ma dopo le rivelazioni passate il dubbio è legittimo ovviamente.

Poi se vuoi fare a gara a chi lo ha più lungo tra i due, con me caschi male dato che li ho appesi entrambi in favore di altri che non soffrono degli stessi problemi dei due programmi in questione.
Quindi per quanto mi riguarda mi limito a vedere ed esporre solo i fatti. E per me sono bocciati entrambi

La questione della backdoor in ogni caso si rivelò una bufala, già smentita da quelli di Signal (visto che hanno aiutato il team di WhatsApp ad implementare lo stesso protocollo), cosa che dice anche l'articolo, forse nell'articolo da te citato non è chiaro, e puoi leggerlo meglio qui
https://signal.org/blog/there-is-no-whatsapp-backdoor/

Non ho capito quale punto non ti sia chiaro. Comunque se pensi ci siano degli errori, puoi aprire una issue su github e se verrà accettata cambieranno le valutazioni. Altrimenti non serve molto criticare.

A me nessuno, è a loro che non è chiaro che una valutazione non va fatta in questo modo. E non dovrebbe neanche servire una issue su github per capirlo.

Nell'utilizzo di Element, non viene raccolto alcun dato specificato in quella sezione.
Altro errore è pure quello della notifica di violazione dati relativa al GDPR, porta 0 come punteggio, però poi porta "yes, within 72 hours" (anche perché è legge, si beccano una multa se non lo fanno).
E tra l'altro non tiene conto neanche del fatto che sia Matrix che Element possono essere installati su un server proprio.

Insomma, si fa prima a trovare altre fonti migliori che a sistemare tutti gli errori presenti.

Innanzi tutto l'immagine da te postata risale al 2021, quando la crittografia end-to-end per i backup ancora non era disponibile per WhatsApp.
Ma, come fatto notare da altri utenti, su Android aveva già una crittografia più debole (ma sempre crittografia era).

Mentre sui dispositivi Apple, il discorso si fa più complesso con il meccanismo di backup di iCloud, dove anche Signal infatti non ha introdotto il backup su iCloud proprio per la ragione che non è sufficientemente sicuro.
Qui una lunga discussione dove puoi trovare alcune spiegazioni a riguardo
https://community.signalusers.org/t/ios-backup-keeping-message-history-when-switching-phones/1736


Non so a quale immagine tu ti riferisca. Ho riportato il testo presente nella documentazione ufficiale di whatsapp (https://faq.whatsapp.com/1246476872801203/?locale=it_IT&cms_id=1246476872801203&draft=false). Forse non hai letto correttamente, te lo riporto in italiano:

WhatsApp offre la crittografia end-to-end per tutti i messaggi personali inviati e ricevuti, per garantire che solo tu e la persona con cui stai comunicando possiate leggerli o ascoltarli. Con il backup crittografato end-to-end, puoi aggiungere lo stesso livello di protezione anche ai tuoi backup su iCloud e Google Drive.

Mi pare chiaro che il backup su icloud e google drive non sia cifrato e2e, ma solo con la crittografia in transito di apple e google.
Anzi, non tutto viene cifrato. Whatsapp (https://security.stackexchange.com/questions/136072/how-can-whatsapp-restore-local-or-google-drive-backups?rq=1) memorizza in chiaro i dati in locale all'interno del database SQL. I backup dei messaggi, contatti, sticker e impostazioni sono cifrati con crittografia simmetrica AES-256. I dati multimediali (immagini, video e audio) sono in chiaro. Inoltre, la chiave di cifratura è memorizzata nei server di facebook e inviata in caso di reinstallazione o cambio di dispositivo.


Non me ne volere, ma credo tu stia condividendo una marea di documenti tecnici e non, senza capirci molto degli stessi (vedi anche questione backdoor).

Mentre stiamo parlando della cifrature del backup (dove indubbiamente viene invalidata nel caso dell'anello debole del gruppo), hai tirato in ballo il metodo di cifratura delle chat e dei gruppi, che è una questione completamente differente.

Inoltre sentir parlare di "viene condivisa una chiave simmetrica" mentre stiamo parlando di applicazioni dove per ogni conversazione di chiavi simmetriche e/o asimmetriche ce ne sono diverse, mi lascia senza parole.


E' tipico di chi ha terminato le argomentazioni, iniziare ad attaccare il proprio interlocutore invece che rispondere sul merito.
Conosco bene la differenza tra cifratura del backup e quella della comunicazione. Ti ho riporto l'articolo scientifico che ho letto in modo approfondito proprio per mostrare come la crittografia e2e in realtà esista solo per le chat 1:1. Nella prime versioni di Signal e quando ancora si chiamava TextSecure, nel caso di gruppi venivano aperte N^2 connessioni e2e 1:1 e infatti i gruppi erano limitati a N molto piccolo invece di circa 1000 attuali.
Per questo Signal ha abbandonato tale implementazione a favore di una in cui ogni utente in un gruppo condivide con gli altri una chiave simmetrica in modo tale che non siano necessari N^2 scambi di chiavi come con il caso di connessioni e2e 1:1. La chiave simmetrica di ogni utente viene rinegoziata periodicamente.


Il contrario assolutamente no.
La verità è che vale per entrambi.

Entrambi hanno il codice lato server chiuso.
Telegram ha il client open-source ma conserva i dati nei suoi server. Ed ha il capo poco credibile come Musk, e non appena si alzarono le critiche per alcune scelte recente (come la vendita degli username) blocco immediatamente i commenti sul canale di Telegram e sul suo, dopo che ha predicato "libertà di parola" ogni 3 secondi e come cavallo di battaglia (Esattamente come Musk), mi guarderei bene dal fidarmi di lui e di quello che dice.
WhatsApp ha il client closed, ma non conserva i dati. Ed i backup sono ora crittografati lato client. Ma dopo le rivelazioni passate il dubbio è legittimo ovviamente.

Sono d'accordo sul discorso degli username sulla piattaforma fragment, mentre trovo Durov molto diverso da Musk. Durov vive in esilio per non essere d'accordo con il proprio governo ed è stato elogiato anche da Snowden (https://nitter.snopyta.org/Snowden/status/986273158603952128) per non aver dato accesso alle chiavi di cifratura alla Russia, cosa che gli è costata il blocco per oltre 2 anni (in teoria, mentre in pratica ha sempre funzionato grazie ai proxy).
La differenza sostanziale è che con telegram, grazie al client open source e alle build riproducibili, nel caso delle chat segrete cifrate e2e non ti devi fidare di nessuno. Nel caso delle altre chat come i gruppi ti devi fidare di telegram, ma la storia è a suo favore al momento.
Con whatsapp nel caso di chat 1:1 se entrambi gli utenti hanno attivo il backup con crittografia e2e, ti devi fidare solo di facebook (meta). Altrimenti per un gruppo, se c'è anche un solo utente senza backup e2ee, ti devi sempre fidare sia di facebook sia dei gestori del backup google e apple.


Poi se vuoi fare a gara a chi lo ha più lungo tra i due, con me caschi male dato che li ho appesi entrambi in favore di altri che non soffrono degli stessi problemi dei due programmi in questione.
Quindi per quanto mi riguarda mi limito a vedere ed esporre solo i fatti. E per me sono bocciati entrambi


Riporto solamente i fatti in modo chiaro, poi ognuno decide di utilizzare quello che vuole, ma in modo consapevole. Certo anche io preferisco element/matrix, non utilizzando l'istanza del server ufficiale, ma una senza problemi riportati da privacyspy. Grazie alla federazione possiamo installarci la nostra.
Tuttavia, tra telegram e whatsapp, il primo è superiore dal punto di vista della sicurezza. Se parliamo di signal, li supera entrambi anche se il fatto di utilizzare gli enclave basati su intel sgx fallata (https://medium.com/@maniacbolts/signal-increases-their-reliance-on-sgx-f46378f336d3) e di avere i server su amazon, lascia qualche dubbio (per fortuna vengono salvati in cloud solo il grafo dei contatti e le impostazioni, niente messaggi).


La questione della backdoor in ogni caso si rivelò una bufala, già smentita da quelli di Signal (visto che hanno aiutato il team di WhatsApp ad implementare lo stesso protocollo), cosa che dice anche l'articolo, forse nell'articolo da te citato non è chiaro, e puoi leggerlo meglio qui
https://signal.org/blog/there-is-no-whatsapp-backdoor/


Conosco benissimo la questione, altrimenti non ti riportavo l'articolo che contiene il tuo link di signal. In breve i server di whatsapp che servono per recapitare il messaggio tra mittente e destinatario (singolo utente e gruppo) possono richiede un cambio dalle chiave di cifratura senza notificare l'utente (questo non è una backdoor, ma un attacco MITM). Whatsapp ha l'impostazione disattivata di default, mentre signal attivata di default. Mi chiedo perché...


A me nessuno, è a loro che non è chiaro che una valutazione non va fatta in questo modo. E non dovrebbe neanche servire una issue su github per capirlo.

Nell'utilizzo di Element, non viene raccolto alcun dato specificato in quella sezione.
Altro errore è pure quello della notifica di violazione dati relativa al GDPR, porta 0 come punteggio, però poi porta "yes, within 72 hours" (anche perché è legge, si beccano una multa se non lo fanno).
E tra l'altro non tiene conto neanche del fatto che sia Matrix che Element possono essere installati su un server proprio.

Insomma, si fa prima a trovare altre fonti migliori che a sistemare tutti gli errori presenti.

Infatti l'analisi riguarda l'istanza del server ufficiale di element che ha i problemi riportati. Ho letto la loro privacy policy (https://element.io/privacy) e non c'è traccia di come si comportano in caso di violazione del GDPR e notifica del data breach. Inoltre, raccolgono diversi dati, leggi le sezioni 2.2 e 2.10 (inoltre nella numerazione manca la sezione 2.3, chissà perché).
Per me l'analisi di privacyspy è sostanzialmente corretta.

Non so a quale immagine tu ti riferisca. Ho riportato il testo presente nella documentazione ufficiale di whatsapp (https://faq.whatsapp.com/1246476872801203/?locale=it_IT&cms_id=1246476872801203&draft=false). Forse non hai letto correttamente, te lo riporto in italiano:

WhatsApp offre la crittografia end-to-end per tutti i messaggi personali inviati e ricevuti, per garantire che solo tu e la persona con cui stai comunicando possiate leggerli o ascoltarli. Con il backup crittografato end-to-end, puoi aggiungere lo stesso livello di protezione anche ai tuoi backup su iCloud e Google Drive.

Mi pare chiaro che il backup su icloud e google drive non sia cifrato e2e, ma solo con la crittografia in transito di apple e google.

L'immagine mi riferisco a questa, che TU hai condiviso, risale al 7 gennaio 2021
https://therecord.media/fbi-document-shows-what-data-can-be-obtained-from-encrypted-messaging-apps/

E sono certo che sia tu quello che deve rileggere il testo, anzi te lo incollo io e ti evidenzio la parte

WhatsApp offre la crittografia end-to-end per tutti i messaggi personali inviati e ricevuti, per garantire che solo tu e la persona con cui stai comunicando possiate leggerli o ascoltarli. Con il backup crittografato end-to-end, puoi aggiungere lo stesso livello di protezione anche ai tuoi backup su iCloud e Google Drive.

Quindi vedi bene chi deve leggere correttamente il testo che condivide

Il backup crittografato end-to-end adesso ci sta, se uno non lo attiva problemi suoi e di chi lo frequenta.

Ma, dato che parlavamo di Gennaio 2021, questo è del tutto irrilevante alla questione, così come interamente il link che hai postato.

Andando più sul rilevante, affermi:
"Mi pare chiaro che il backup su icloud e google drive non sia cifrato e2e, ma solo con la crittografia in transito di apple e google."

Ti rendi conto degli errori in questa frase?

1. Stiamo parlando di crittografia at-rest e zero-access e mi tiri in ballo la crittografia in transito, che è tutt'altra cosa
2. ignori completamente invece la crittografia at-rest che è ed era già presente da tempo sui backup Google, sia di Google stessa (relativamente inutile ovviamente), che del backup di WhatsApp che NON ERA A LIVELLO DI QUELLA ATTUALE (non E2E,e mai ho affermato che fosse tale, ho parlato semplicemente di crittografia) MA CI STAVA.

Basta che fai un giro su GitHub, ci sono progetti, non esattamente recenti come la il backup e2ee di WA, che servono proprio a decriptarlo
https://github.com/ElDavoo/WhatsApp-Crypt14-Crypt15-Decrypter

Ed a conferma di ciò puoi leggere l'immagine da te stesso postata dove infatti parla dell'accesso solo tramite sistemi Cloud di Apple e non quello Google.
Ripeto, non lo sto dicendo io, ma i tuoi stessi "documenti" che hai postato


Anzi, non tutto viene cifrato. Whatsapp (https://security.stackexchange.com/questions/136072/how-can-whatsapp-restore-local-or-google-drive-backups?rq=1) memorizza in chiaro i dati in locale all'interno del database SQL. I backup dei messaggi, contatti, sticker e impostazioni sono cifrati con crittografia simmetrica AES-256. I dati multimediali (immagini, video e audio) sono in chiaro.
Su questo, effettivamente, almeno quando lo usavo i dati erano fuori dal backup criptato.

Inoltre, la chiave di cifratura è memorizzata nei server di facebook e inviata in caso di reinstallazione o cambio di dispositivo.

Non è esattamente così la situazione.

E' tipico di chi ha terminato le argomentazioni, iniziare ad attaccare il proprio interlocutore invece che rispondere sul merito.
Conosco bene la differenza tra cifratura del backup e quella della comunicazione. Ti ho riporto l'articolo scientifico che ho letto in modo approfondito proprio per mostrare come la crittografia e2e in realtà esista solo per le chat 1:1. Nella prime versioni di Signal e quando ancora si chiamava TextSecure, nel caso di gruppi venivano aperte N^2 connessioni e2e 1:1 e infatti i gruppi erano limitati a N molto piccolo invece di circa 1000 attuali.
Per questo Signal ha abbandonato tale implementazione a favore di una in cui ogni utente in un gruppo condivide con gli altri una chiave simmetrica in modo tale che non siano necessari N^2 scambi di chiavi come con il caso di connessioni e2e 1:1. La chiave simmetrica di ogni utente viene rinegoziata periodicamente.


nessun, attacco, semplicemente constatazione e ti sto rispondendo sul merito anche quindi, contrariamente a te che stai portando argomentazioni obsolete di anni.

Se conoscevi la differenza non mischiavi le due questioni insieme facendo un minestrone.

Che la crittografia esista solo per le chat 1:1, è un'altra castroneria, smentita dai fatti: chat e2ee di gruppo, checché tu ne dica, esistono e sono implementate dai vari client.

Altra castroneria, quella della singola chiave simmetrica, che ora hai edulcorato affermando che OGNI utente condivide una chiave simmetrica e periodicamente,e in ogni caso è sbagliata... facendo un mix delle due cose ti avvicini, forse, alla realtà seppur ipersemplificandola.

Ed è smentita direttamente dalle documentazioni ufficiale, anzi te la riporto, direttamente dal White Paper di WhatsApp (che usa il protocollo Signal) datato 24 febbraio 2023

Group Messages
End-to-end encryption of messages sent to WhatsApp groups utilize the
established pairwise encrypted sessions, as previously described in the
“Initiation Session Setup” section, to distribute the “Sender Key” component
of the Signal Messaging Protocol.

When sending a message to a group for the first time, a “Sender Key” is
generated and distributed to each member device of the group, using the
pairwise encrypted sessions. The message content is encrypted using the
“Sender Key”, achieving an efficient and secure fan-out for the messages
that are sent to groups.

The first time a WhatsApp group member sends a message to a group:
1. The sender generates a random 32-byte Chain Key.
2. The sender generates a random Curve25519 Signature Key
key pair.
3. The sender combines the 32-byte Chain Key and the public key from
the Signature Key into a Sender Key message.
4. The sender individually encrypts the Sender Key to each
member of the group, using the pairwise messaging protocol explained
previously.

For all subsequent messages to the group:
1. The sender derives a Message Key from the Chain Key, and updates
the Chain Key.
2. The sender encrypts the message using AES256 in CBC mode.
3. The sender signs the ciphertext using the Signature Key.
4. The sender transmits the single ciphertext message to the server, which
does server-side fan-out to all group participants.
The “hash ratchet” of the message sender’s Chain Key provides forward
secrecy. Whenever a group member leaves, all group participants clear their
Sender Key and start over.
In Chat Device Consistency information is included when distributing a
“Sender Key” and then excluded from the subsequent messages encrypted
with the Sender Key

https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

Ti rendi conto di quanto hai banalizzato e semplificato un sistema ben più complesso?

La crittografia, a questi livelli non può essere ridotta ad un "Prendere fratelli questo chiave è il corpo di crypto"

Sono d'accordo sul discorso degli username sulla piattaforma fragment, mentre trovo Durov molto diverso da Musk. Durov vive in esilio per non essere d'accordo con il proprio governo ed è stato elogiato anche da Snowden (https://nitter.snopyta.org/Snowden/status/986273158603952128) per non aver dato accesso alle chiavi di cifratura alla Russia, cosa che gli è costata il blocco per oltre 2 anni (in teoria, mentre in pratica ha sempre funzionato grazie ai proxy).

Tranquillo, tra poco confinano anche Musk, è questione di tempo prima che lo cacciano a pedate dagli US, non lo sopporta più nessuno. :D

E comunque se vedi il tweet (che tra l'altre è anche antecedente alla questione degli username), è anche il primo a criticare Telegram sul fronte della sicurezza

Apprezzabile che non ha dato dati, ma se poi cambia idea in futuro non puoi saperlo, a meno che non hai una sfera di cristallo.
Ed in ogni caso la sua credibilità è compromessa con il blocco dei commenti alle critiche

La differenza sostanziale è che con telegram, grazie al client open source e alle build riproducibili, nel caso delle chat segrete cifrate e2e non ti devi fidare di nessuno. Nel caso delle altre chat come i gruppi ti devi fidare di telegram, ma la storia è a suo favore al momento.
Con whatsapp nel caso di chat 1:1 se entrambi gli utenti hanno attivo il backup con crittografia e2e, ti devi fidare solo di facebook (meta). Altrimenti per un gruppo, se c'è anche un solo utente senza backup e2ee, ti devi sempre fidare sia di facebook sia dei gestori del backup google e apple.

Si tutto quello che vuoi, il client open-source e quello che vuoi ma:
Il client open-source non ti permette di sapere cosa succede sul server. mentre le chat e2ee di Telegram:
-Non sono predefinite
-Non sono disponibile su desktop (o meglio solo su Mac, mi pare)
-Non sono disponibili su web
-Non è possibile farne un backup

Sono letteralmente INUSABILI per queste ragioni

Riporto solamente i fatti in modo chiaro, poi ognuno decide di utilizzare quello che vuole, ma in modo consapevole. Certo anche io preferisco element/matrix, non utilizzando l'istanza del server ufficiale, ma una senza problemi riportati da privacyspy. Grazie alla federazione possiamo installarci la nostra.
Tuttavia, tra telegram e whatsapp, il primo è superiore dal punto di vista della sicurezza. Se parliamo di signal, li supera entrambi anche se il fatto di utilizzare gli enclave basati su intel sgx fallata (https://medium.com/@maniacbolts/signal-increases-their-reliance-on-sgx-f46378f336d3) e di avere i server su amazon, lascia qualche dubbio (per fortuna vengono salvati in cloud solo il grafo dei contatti e le impostazioni, niente messaggi).

No li riporti in modo sbagliato, pure ancora a tirare la questione intel sgx vecchia di anni e smentita.

Intel SGX per Signal è un poco come IGE (https://core.telegram.org/techfaq#q-do-you-use-ige-ige-is-broken) per Telegram

Entrambe sono tecnologie notoriamente fallate ma non nelle loro implementazioni.

Conosco benissimo la questione, altrimenti non ti riportavo l'articolo che contiene il tuo link di signal. In breve i server di whatsapp che servono per recapitare il messaggio tra mittente e destinatario (singolo utente e gruppo) possono richiede un cambio dalle chiave di cifratura senza notificare l'utente (questo non è una backdoor, ma un attacco MITM). Whatsapp ha l'impostazione disattivata di default, mentre signal attivata di default. Mi chiedo perché...

No è come funziona la crittografia, se cambi dispositivo, senza ripristinare il backup, ti genera una nuova chiave. (E, no, non è il server direttamente a richiederlo)
Nessuna backdoor, nessun attacco MITM, semplice funzionamento base della crittografia utilizzata.

E no., i server di WhatsApp non hanno le chiavi generate dai dispositivi (ufficialmente, se poi se le mandano di nascosto e hai prove di questo possiamo procedere con l'inchiesta)

Tutto il resto è puro complottismo spicciolo basato su aria fritta.

Infatti l'analisi riguarda l'istanza del server ufficiale di element che ha i problemi riportati. Ho letto la loro privacy policy (https://element.io/privacy) e non c'è traccia di come si comportano in caso di violazione del GDPR e notifica del data breach. Inoltre, raccolgono diversi dati, leggi le sezioni 2.2 e 2.10 (inoltre nella numerazione manca la sezione 2.3, chissà perché).
Per me l'analisi di privacyspy è sostanzialmente corretta.

Non ha nessuno dei problemi riportati.
La questione del marketing non ha nulla a che vedere con la chat, come ho già detto.

Ed è normale che non ci sia un punto che specifica l'avviso, visto che è obbligatorio, non è che ti fanno un favore.

Sul fatto che manca 2.3, verificherò, ma non ha comunque nulla a che vedere con la questione del GDPR, che infatti si trova nel 2.1.
E, a maggior ragione, il punto 2 è anche intitolato "Access to your data" quindi non idoneo per l'eventuale violazione dei dati che andrebbe in una categoria.

L'immagine mi riferisco a questa, che TU hai condiviso, risale al 7 gennaio 2021
https://therecord.media/fbi-document-shows-what-data-can-be-obtained-from-encrypted-messaging-apps/

Ok, intendevi l'altro link.


E sono certo che sia tu quello che deve rileggere il testo, anzi te lo incollo io e ti evidenzio la parte

Quindi vedi bene chi deve leggere correttamente il testo che condivide


Io ho letto benissimo, non ho capito di quale link tu parlassi.


Il backup crittografato end-to-end adesso ci sta, se uno non lo attiva problemi suoi e di chi lo frequenta.

Ma, dato che parlavamo di Gennaio 2021, questo è del tutto irrilevante alla questione, così come interamente il link che hai postato.

Invece è molto rilevante perché il 90% degli utenti ha le impostazioni predefinite e quindi il backup e2ee disattivato.


Andando più sul rilevante, affermi:
"Mi pare chiaro che il backup su icloud e google drive non sia cifrato e2e, ma solo con la crittografia in transito di apple e google."

Ti rendi conto degli errori in questa frase?

1. Stiamo parlando di crittografia at-rest e zero-access e mi tiri in ballo la crittografia in transito, che è tutt'altra cosa
2. ignori completamente invece la crittografia at-rest che è ed era già presente da tempo sui backup Google, sia di Google stessa (relativamente inutile ovviamente), che del backup di WhatsApp che NON ERA A LIVELLO DI QUELLA ATTUALE (non E2E,e mai ho affermato che fosse tale, ho parlato semplicemente di crittografia) MA CI STAVA.

Non ci sono errori. I backup sono protetti dalla crittografia in transito, una loro parte è crittografata in modo simmetrico con AES e una parte è in chiaro. La chiave di crittografia è in mano a facebook. Quindi google e apple accedono a buona parte del backup di whatsapp per impostazione predefinita e con la complicità di facebook a tutto (leggi qui (https://security.stackexchange.com/questions/136072/how-can-whatsapp-restore-local-or-google-drive-backups?rq=1)).
Se attivi il backup con crittografia e2e, non possono più accedervi.


Basta che fai un giro su GitHub, ci sono progetti, non esattamente recenti come la il backup e2ee di WA, che servono proprio a decriptarlo
https://github.com/ElDavoo/WhatsApp-Crypt14-Crypt15-Decrypter

Ed a conferma di ciò puoi leggere l'immagine da te stesso postata dove infatti parla dell'accesso solo tramite sistemi Cloud di Apple e non quello Google.
Ripeto, non lo sto dicendo io, ma i tuoi stessi "documenti" che hai postato


Rileggi questo (https://security.stackexchange.com/questions/136072/how-can-whatsapp-restore-local-or-google-drive-backups?rq=1).


Su questo, effettivamente, almeno quando lo usavo i dati erano fuori dal backup criptato.

Menomale.


Non è esattamente così la situazione.

Allora spiegami come funziona, con link validi che supportino le affermazioni.


nessun, attacco, semplicemente constatazione e ti sto rispondendo sul merito anche quindi, contrariamente a te che stai portando argomentazioni obsolete di anni.

Se conoscevi la differenza non mischiavi le due questioni insieme facendo un minestrone.

Che la crittografia esista solo per le chat 1:1, è un'altra castroneria, smentita dai fatti: chat e2ee di gruppo, checché tu ne dica, esistono e sono implementate dai vari client.

Altra castroneria, quella della singola chiave simmetrica, che ora hai edulcorato affermando che OGNI utente condivide una chiave simmetrica e periodicamente,e in ogni caso è sbagliata... facendo un mix delle due cose ti avvicini, forse, alla realtà seppur ipersemplificandola.

Non capisco perché tu non voglia capire. Conosco la differenza molto bene e te l'ho spiegata (penso che la capisci bene anche tu). L'unica vera crittografia e2e nei gruppi con N membri è quella in cui ogni client apre N-1 connessioni e2ee con gli altri. Il problema di questo approccio utilizzato anche dalle prime versioni di Signal è la scalabilità poiché per N grande occorrono N^2 scambi di chiavi tra i client (lo scambio viene fatto periodicamente, troppo overhead).
La soluzione adottata, spiegata bene qui (https://eprint.iacr.org/2021/498.pdf) (pag. 19, ma vedo che non lo hai letto), è quella di condividere una chiave simmetrica tra per ogni utente tra i membri delle chat di gruppo al fine di ridurre gli scambi di chiave a N.


Ed è smentita direttamente dalle documentazioni ufficiale, anzi te la riporto, direttamente dal White Paper di WhatsApp (che usa il protocollo Signal) datato 24 febbraio 2023

https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

Questa parte che hai riportato conferma quanto ho scritto in precedenza.
When sending a message to a group for the first time, a “Sender Key” is generated and distributed to each member device of the group, using the pairwise encrypted sessions. The message content is encrypted using the “Sender Key”, achieving an efficient and secure fan-out for the messages that are sent to groups.


Ti rendi conto di quanto hai banalizzato e semplificato un sistema ben più complesso?

Sto spiegando in modo semplice per persone non tecniche, se vuoi capire, puoi farlo. Il succo della questione è quello scritto sopra e nei messaggi precedenti. La vera crittografia e2e nei gruppi è solo quella con N-1 sessioni 1:1 per ogni client, il resto è un compromesso per questioni di efficienza computazionale.


La crittografia, a questi livelli non può essere ridotta ad un "Prendere fratelli questo chiave è il corpo di crypto"

:D


Tranquillo, tra poco confinano anche Musk, è questione di tempo prima che lo cacciano a pedate dagli US, non lo sopporta più nessuno. :D

Paragonare Musk a Durov è come paragonare lupi e agnelli, non c'è alcuna somiglianza.


E comunque se vedi il tweet (che tra l'altre è anche antecedente alla questione degli username), è anche il primo a criticare Telegram sul fronte della sicurezza

Se intendi gli username su telegram (https://telegram.org/blog/usernames-and-secret-chats-v2?setln=it), c'erano da oltre 3 anni prima del tweet dell'aprile 2018 (https://nitter.snopyta.org/Snowden/status/986273158603952128).
Conosco bene quello che dice Snowden su telegram e cosa pensa sulla crittografia e2e (lo condivido), ti ho solo mostrato che il tuo paragone sulla credibilità tra Durov-Musk non ha alcun senso.


Apprezzabile che non ha dato dati, ma se poi cambia idea in futuro non puoi saperlo, a meno che non hai una sfera di cristallo.
Ed in ogni caso la sua credibilità è compromessa con il blocco dei commenti alle critiche

Certo, ma su whatsapp sei certo che facebook prenda i dati (visti gli N precedenti), su telegram ancora non ci sono precedenti.
Nemmeno io sono d'accordo, ma non diciamo falsità. Tutti sbagliano, anche Durov.


Si tutto quello che vuoi, il client open-source e quello che vuoi ma:
Il client open-source non ti permette di sapere cosa succede sul server. mentre le chat e2ee di Telegram:
-Non sono predefinite
-Non sono disponibile su desktop (o meglio solo su Mac, mi pare)
-Non sono disponibili su web
-Non è possibile farne un backup

Sono letteralmente INUSABILI per queste ragioni

Su questo ti posso dare ragione, ma non sulle motivazioni precedenti su quale dei due sia più sicuro.


No li riporti in modo sbagliato, pure ancora a tirare la questione intel sgx vecchia di anni e smentita.

Intel SGX per Signal è un poco come IGE (https://core.telegram.org/techfaq#q-do-you-use-ige-ige-is-broken) per Telegram

Entrambe sono tecnologie notoriamente fallate ma non nelle loro implementazioni.

Da quanto ne sappiamo intel sgx (https://sgx.fail/) è ancora fallato (https://arstechnica.com/information-technology/2022/08/architectural-bug-in-some-intel-cpus-is-more-bad-news-for-sgx-users/). Molti ricercatori di sicurezza affermano che l'implementazione di signal non sia sicura proprio a causa della fiducia nella tecnologia link1 (https://palant.info/2020/06/16/does-signals-secure-value-recovery-really-work/) e link2 (https://github.com/IAIK/AEPIC). Hai qualche link che afferma il contrario?


No è come funziona la crittografia, se cambi dispositivo, senza ripristinare il backup, ti genera una nuova chiave. (E, no, non è il server direttamente a richiederlo)
Nessuna backdoor, nessun attacco MITM, semplice funzionamento base della crittografia utilizzata.

E no., i server di WhatsApp non hanno le chiavi generate dai dispositivi (ufficialmente, se poi se le mandano di nascosto e hai prove di questo possiamo procedere con l'inchiesta)

Tutto il resto è puro complottismo spicciolo basato su aria fritta.

Che fatica quando non vuoi capire. Il server di whatsapp può effettuare/richiedere un cambio di chiave senza notificare i due interlocutori (per impostazione predefinita, poi se uno attiva l'opzione verrà notificato). Mai scritto che sia una backdoor, ma un attacco MITM.
Dal "tuo" link (https://signal.org/blog/there-is-no-whatsapp-backdoor/) che era incluso nell'articolo "mio" link (https://arstechnica.com/information-technology/2017/01/whatsapp-and-friends-take-umbrage-at-report-its-crypto-is-backdoored/):

WhatsApp could try to “man in the middle” a conversation, just like with any encrypted communication system, but they would risk getting caught by users who verify keys.

The fact that WhatsApp handles key changes is not a “backdoor,” it is how cryptography works. Any attempt to intercept messages in transit by the server is detectable by the sender, just like with Signal, PGP, or any other end-to-end encrypted communication system.

The only question it might be reasonable to ask is whether these safety number change notifications should be “blocking” or “non-blocking.” In other words, when a contact’s key changes, should WhatsApp require the user to manually verify the new key before continuing, or should WhatsApp display an advisory notification and continue without blocking the user.

Questo è falso? Perché quando non sai cosa dire tiri in ballo argomentazioni inutili e al limite dell'intelligenza come il complottismo?


Non ha nessuno dei problemi riportati.
La questione del marketing non ha nulla a che vedere con la chat, come ho già detto.

Ed è normale che non ci sia un punto che specifica l'avviso, visto che è obbligatorio, non è che ti fanno un favore.

Sul fatto che manca 2.3, verificherò, ma non ha comunque nulla a che vedere con la questione del GDPR, che infatti si trova nel 2.1.
E, a maggior ragione, il punto 2 è anche intitolato "Access to your data" quindi non idoneo per l'eventuale violazione dei dati che andrebbe in una categoria.
Mi sembra che tu neghi l'evidenza dei dati raccolti dall'istanza ufficiale di element. Leggiti la loro privacy policy (https://element.io/privacy) (non stiamo parlando della tua istanza o di altro). No, non è normale che non sia specificato. L'articolo 33 del GDPR (https://www.privacy-regulation.eu/en/article-33-notification-of-a-personal-data-breach-to-the-supervisory-authority-GDPR.htm) richiede di notificare gli utenti->garante entro 72 ore da un data breach. Se un servizio non prevede un protocollo per la gestione dello stesso, come pensi li contatterà? Gli invia un messaggio?

Ok, intendevi l'altro link.

Io ho letto benissimo, non ho capito di quale link tu parlassi.


Non direi, visto che ti ho citato anche la data, e continuavi a capire il link su WhatsApp.
Segno che non hai letto approfonditamente neanche il link da te stesso condiviso.

Invece è molto rilevante perché il 90% degli utenti ha le impostazioni predefinite e quindi il backup e2ee disattivato.


Mi confermi i tuoi problemi nella lettura.
Ho detto che è irrilevante perché si parlava di un documento di quando l'attuale crittografia e2e non era ancora presente su WhatsApp.

Non ci sono errori. I backup sono protetti dalla crittografia in transito, una loro parte è crittografata in modo simmetrico con AES e una parte è in chiaro. La chiave di crittografia è in mano a facebook. Quindi google e apple accedono a buona parte del backup di whatsapp per impostazione predefinita e con la complicità di facebook a tutto (leggi qui (https://security.stackexchange.com/questions/136072/how-can-whatsapp-restore-local-or-google-drive-backups?rq=1)).
Se attivi il backup con crittografia e2e, non possono più accedervi.


Ci sono errori e continui a spararne.
Che i backup sono protetti in transito non l'ho mai negato (ma pure le castronerie che spari qui sono criptate in transito eh, non serve scomodare protocolli enormemente avanzati di comunicazione per esserlo), il problema è che stiamo parlando della crittografia at-rest dei backup, e dunque non di come ci arrivano sul server, ma di come vengono conservati.

Quindi facendo, nuovamente, un minestrone.

Menomale.
.
Rileggi questo (https://security.stackexchange.com/questions/136072/how-can-whatsapp-restore-local-or-google-drive-backups?rq=1).

Allora spiegami come funziona, con link validi che supportino le affermazioni.

A parte che il link da te postato già smentisce il fatto che avevi affermato che il backup fosse protetto solo dalla crittografia "in transito" (che poi sarebbe at-rest, ma vabbè soprassediamo su questa tua enorme lacuna, altrimenti non ne usciamo più) su Google Drive.

La chiave è sui server di WhatsApp, ma è in modo crittografato e non accessibile dove Meta non ha accesso

https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee-backups/

People can choose to secure the key manually or with a user password. When someone opts for a password, the key is stored in a Backup Key Vault that is built based on a component called a hardware security module (HSM) — specialized, secure hardware that can be used to securely store encryption keys. When the account owner needs access to their backup, they can access it with their encryption key, or they can use their personal password to retrieve their encryption key from the HSM-based Backup Key Vault and decrypt their backup.

The HSM-based Backup Key Vault will be responsible for enforcing password verification attempts and rendering the key permanently inaccessible after a limited number of unsuccessful attempts to access it. These security measures provide protection against brute-force attempts to retrieve the key. WhatsApp will know only that a key exists in the HSM. It will not know the key itself.

Si certo devi fidarti della loro parola, ma come detto e ripetuto (ma che fatichi a comprendere), per me WhatsApp è bocciato, così come Telegram.

Tu vuoi esaltarlo ed esserne un fan privo di razinalita, libero di farlo.

I preferisco altro (che no, non è WhatsApp, meglio ripeterlo visto che fatichi a comprendere le cose), il tempo dirà chi avrà avuto ragione. E se i messaggi sono più sicuri in un backup locale o in sui server di un tizio che ha dimostrato di non saper mantenere le promesse.

Non capisco perché tu non voglia capire. Conosco la differenza molto bene e te l'ho spiegata (penso che la capisci bene anche tu). L'unica vera crittografia e2e nei gruppi con N membri è quella in cui ogni client apre N-1 connessioni e2ee con gli altri. Il problema di questo approccio utilizzato anche dalle prime versioni di Signal è la scalabilità poiché per N grande occorrono N^2 scambi di chiavi tra i client (lo scambio viene fatto periodicamente, troppo overhead).
La soluzione adottata, spiegata bene qui (https://eprint.iacr.org/2021/498.pdf) (pag. 19, ma vedo che non lo hai letto), è quella di condividere una chiave simmetrica tra per ogni utente tra i membri delle chat di gruppo al fine di ridurre gli scambi di chiave a N.

Sto spiegando in modo semplice per persone non tecniche, se vuoi capire, puoi farlo. Il succo della questione è quello scritto sopra e nei messaggi precedenti. La vera crittografia e2e nei gruppi è solo quella con N-1 sessioni 1:1 per ogni client, il resto è un compromesso per questioni di efficienza computazionale.


(unificato un paio di punti che tanto ripetono la supercazzola del N1 e N2 connessioni, chiave simmetrica sessioni 1:1, ecc..)

Con il tuo atteggiamento mi hai fatto ricordare una frase citata da Beppe Grillo agli esordi "Se una cosa non è vera, ripetetela 10, 100, 1000 volte e diventerà vera",.

No mi spiace per te e per Grillo, la supercazzola che hai scritto (che tra l'altro varia anche ogni volta che la scrivi), puoi ripeterla anche 1000 volte, sempre supercazzola resta.

Sei tu che pretendi di sapere cose che stai dimostrando di non sapere assolutamente.

Basta il tuo mischiare:
-Post su Stack Exchange del 2016
-Articolo di ArsTechnica del 2017
-Articolo del 2020
-Documento FBI di febbraio 2021
-Documento scientifico di aprile 2021
-Documentazione WhatsApp del 2023

Se tu fossi VERAMENTE esperto di crittografia/sicurezza come affermi, o anche semplicemente programmatore, non andresti mai a prendere articoli obsoleti e di epoche diverse come stai facendo. Visto che dal 2016 ad oggi non ci sta un solo software di messaggistica che non sia variato completamente a livello di codice e tecnologia su tutti i fronti.

Stai facendo un minestrone di epoche differenti che solo uno inesperto che non ne capisce una mazza in merito può fare.

Seguiti adeguatamente tutti i client di messaggistica, come faccio io da anni, e solo dopo, forse, puoi considerarti minimamente esperto, anziché improvvisarti tale raccattando link obsoleti a destra e a manca.

Questa parte che hai riportato conferma quanto ho scritto in precedenza.
When sending a message to a group for the first time, a “Sender Key” is generated and distributed to each member device of the group, using the pairwise encrypted sessions. The message content is encrypted using the “Sender Key”, achieving an efficient and secure fan-out for the messages that are sent to groups.


Si, il problema, infatti, è che hai tagliato fuori tutti gli altri passaggi, connessioni e scambi di chiave che avvengono DOPO che smontano, di fatto, completamente la tua argomentazione.

Paragonare Musk a Durov è come paragonare lupi e agnelli, non c'è alcuna somiglianza.

Entrambi predicano libertà ma poi la tolgono al primo dissenso. Libertà finché fa comodo a loro.
O vuoi negare anche questo?

Se intendi gli username su telegram (https://telegram.org/blog/usernames-and-secret-chats-v2?setln=it), c'erano da oltre 3 anni prima del tweet dell'aprile 2018 (https://nitter.snopyta.org/Snowden/status/986273158603952128).
Conosco bene quello che dice Snowden su telegram e cosa pensa sulla crittografia e2e (lo condivido), ti ho solo mostrato che il tuo paragone sulla credibilità tra Durov-Musk non ha alcun senso.

Intendo la vendita degli username*, stavamo parlando di quello, ma contestualizzare le frasi, neanche?
* infatti ho parlato di "questione degli username", non solo di "username" nell'ultimo messaggio

Come già detto il paragone ha perfettamente senso.

Se condividi cosa pensa sulla crittografia Snowden, che ha fatto un esplicito endorsement a Signal (di cui WhatsApp ne condivide il protocollo), significa che soffri di personalità multiple, visto che sono svariati post che stai affermando di non condividere quanto detto da Snowden (che per l'appunto ha criticato il modello di sicurezza di Telegram).


Certo, ma su whatsapp sei certo che facebook prenda i dati (visti gli N precedenti), su telegram ancora non ci sono precedenti.
Nemmeno io sono d'accordo, ma non diciamo falsità. Tutti sbagliano, anche Durov.
Su questo ti posso dare ragione, ma non sulle motivazioni precedenti su quale dei due sia più sicuro.


Mi sa che a te non hai letto bene una cosa che ho affermato prima, te la riposto, così leggi meglio:

Poi se vuoi fare a gara a chi lo ha più lungo tra i due, con me caschi male dato che li ho appesi entrambi in favore di altri che non soffrono degli stessi problemi dei due programmi in questione.
Quindi per quanto mi riguarda mi limito a vedere ed esporre solo i fatti. E per me sono bocciati entrambi


Da quanto ne sappiamo intel sgx (https://sgx.fail/) è ancora fallato (https://arstechnica.com/information-technology/2022/08/architectural-bug-in-some-intel-cpus-is-more-bad-news-for-sgx-users/). Molti ricercatori di sicurezza affermano che l'implementazione di signal non sia sicura proprio a causa della fiducia nella tecnologia link1 (https://palant.info/2020/06/16/does-signals-secure-value-recovery-really-work/) e link2 (https://github.com/IAIK/AEPIC). Hai qualche link che afferma il contrario?

È ufficiale. O non sai leggere, o fai finta di non saper leggere.
Ho affermato che è fallato, ma NON NELLA IMPLEMENTAZIONE DI SIGNAL (è in uno dei thread sul forum di Signal, cercatelo da solo)
Così come IGE è ancora fallato (ed è anche Telegram stesso a dirlo, ti ho postato il link), ma non nella implementazione di Telegram.

Che fatica quando non vuoi capire. Il server di whatsapp può effettuare/richiedere un cambio di chiave senza notificare i due interlocutori (per impostazione predefinita, poi se uno attiva l'opzione verrà notificato). Mai scritto che sia una backdoor, ma un attacco MITM.
Dal "tuo" link (https://signal.org/blog/there-is-no-whatsapp-backdoor/) che era incluso nell'articolo "mio" link (https://arstechnica.com/information-technology/2017/01/whatsapp-and-friends-take-umbrage-at-report-its-crypto-is-backdoored/):

WhatsApp could try to “man in the middle” a conversation, just like with any encrypted communication system, but they would risk getting caught by users who verify keys.

The fact that WhatsApp handles key changes is not a “backdoor,” it is how cryptography works. Any attempt to intercept messages in transit by the server is detectable by the sender, just like with Signal, PGP, or any other end-to-end encrypted communication system.

The only question it might be reasonable to ask is whether these safety number change notifications should be “blocking” or “non-blocking.” In other words, when a contact’s key changes, should WhatsApp require the user to manually verify the new key before continuing, or should WhatsApp display an advisory notification and continue without blocking the user.

Questo è falso? Perché quando non sai cosa dire tiri in ballo argomentazioni inutili e al limite dell'intelligenza come il complottismo?

Si ma guarda che quello che hai evidenziato, smentisce completamente quanto hai affermato te fino adesso eh.

Certo poi se di un intero paragrafo ti leggi solo la frase "man in the middle" ignorando o non comprendendo tutto il resto, ovvio che pensi di aver ragione.
Ma così non è.

Mi sembra che tu neghi l'evidenza dei dati raccolti dall'istanza ufficiale di element. Leggiti la loro privacy policy (https://element.io/privacy) (non stiamo parlando della tua istanza o di altro).


Infatti, non sto parlando di istanze terze, ma di Element.io / Matrix.org: Quei dati NON LI RACCOGLIE CON LA CHAT, ma con LE CAMPAGNE PUBBLICITARIE SUI SOCIAL, sono due cose distinte e separate.

E ad Element / Matrix dell'azienda in questione. puoi REGISTRARTI IN TOTALE ANONIMATO, senza fornire né nome, né email né numero di telefono (cosa non possibile con Telegram, se non di recente, pagando)

No, non è normale che non sia specificato. L'articolo 33 del GDPR (https://www.privacy-regulation.eu/en/article-33-notification-of-a-personal-data-breach-to-the-supervisory-authority-GDPR.htm) richiede di notificare gli utenti entro 72 ore da un data breach. Se un servizio non prevede un protocollo per la gestione dello stesso, come pensi li contatterà? Gli invia un messaggio?

richiede di notificare non richiede di inserire l'avviso che notificheranno nella privacy policy.

Tra l'altro la pagina da te postata
"Notification of a personal data breach to the supervisory authority"
"supervisory authority", non "users"
Quindi hai letto nuovamente male, tanto per cambiare, e sbagliato dunque pure l'articolo della GDPR in questione

E, in ogni caso, tieni, così visto che proprio vuoi un testo a riguardo, tieni: Element ha un documento intero, di 46 pagine, dedicato esclusivamente al data processing
https://static.element.io/pdfs/data-processing-agreement.pdf


Ora mi fai però tu una cortesia, mi trovi dove parla si data breach nella privacy policy di Telegram? Perché la parola "breach" non la vedo neanche nominata mezza volta.
https://telegram.org/privacy

E neanche nelle FAQ, pur parlando di GDPR, di breach e simili non ci sta traccia.
https://telegram.org/faq#d-per-quello-che-riguarda-il-gdpr

Non direi, visto che ti ho citato anche la data, e continuavi a capire il link su WhatsApp.
Segno che non hai letto approfonditamente neanche il link da te stesso condiviso.

Non avevo capito a quale figura ti riferissi. Quando commetto un errore lo riconosco, differentemente da te.


Mi confermi i tuoi problemi nella lettura.
Ho detto che è irrilevante perché si parlava di un documento di quando l'attuale crittografia e2e non era ancora presente su WhatsApp.

No, qui ti sbagli. Il fatto di aver introdotto il backup e2ee successivamente all'articolo relativo al FBI, non risolve il problema poiché è disabilitato di default e permangono i problemi visto che il 90% dell'utenza non le modifica (è sufficiente un solo membro per gruppo senza backup e2ee per invalidarla a tutti).


Ci sono errori e continui a spararne.
Che i backup sono protetti in transito non l'ho mai negato (ma pure le castronerie che spari qui sono criptate in transito eh, non serve scomodare protocolli enormemente avanzati di comunicazione per esserlo), il problema è che stiamo parlando della crittografia at-rest dei backup, e dunque non di come ci arrivano sul server, ma di come vengono conservati.

Quindi facendo, nuovamente, un minestrone.

Nessun minestrone, quello forse ti piace a te :).
Ciò che ho scritto è la semplificazione di quanto riportato nei link. Li ho riletti e non ho trovato errori. Riportameli.


A parte che il link da te postato già smentisce il fatto che avevi affermato che il backup fosse protetto solo dalla crittografia "in transito" (che poi sarebbe at-rest, ma vabbè soprassediamo su questa tua enorme lacuna, altrimenti non ne usciamo più) su Google Drive.

La chiave è sui server di WhatsApp, ma è in modo crittografato e non accessibile dove Meta non ha accesso

https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee-backups/


Se parli della chiave del backup e2ee ok (su questo ti sto dicendo che è vero dall'inizio), se parli di quella del backup di default facebook (meta) ha l'accesso completo è scritto anche nel tuo link oltre che nel mio.
Di lacune ne vedo solo lato tuo, hai la possibilità di capire, ma non vuoi farlo.


Si certo devi fidarti della loro parola, ma come detto e ripetuto (ma che fatichi a comprendere), per me WhatsApp è bocciato, così come Telegram.

Tu vuoi esaltarlo ed esserne un fan privo di razinalita, libero di farlo.

I preferisco altro (che no, non è WhatsApp, meglio ripeterlo visto che fatichi a comprendere le cose), il tempo dirà chi avrà avuto ragione. E se i messaggi sono più sicuri in un backup locale o in sui server di un tizio che ha dimostrato di non saper mantenere le promesse.

Anche io preferisco altro, ma tra whatsapp e telegram, in termini di sicurezza e privacy, molto meglio il secondo lo dimostrano i fatti. Un qualunque software closed source con binario offuscato non può essere verificato e viola il principio Kerckhoffs alla base della crittografia.
Se stai parlando di signal al momento è meglio di telegram, ma per via delle falle di intel sgx e di essere su cloud amazon, non è comunque affidabile.


(unificato un paio di punti che tanto ripetono la supercazzola del N1 e N2 connessioni, chiave simmetrica sessioni 1:1, ecc..)

Con il tuo atteggiamento mi hai fatto ricordare una frase citata da Beppe Grillo agli esordi "Se una cosa non è vera, ripetetela 10, 100, 1000 volte e diventerà vera",.

No mi spiace per te e per Grillo, la supercazzola che hai scritto (che tra l'altro varia anche ogni volta che la scrivi), puoi ripeterla anche 1000 volte, sempre supercazzola resta.

Sei tu che pretendi di sapere cose che stai dimostrando di non sapere assolutamente.

Basta il tuo mischiare:
-Post su Stack Exchange del 2016
-Articolo di ArsTechnica del 2017
-Articolo del 2020
-Documento FBI di febbraio 2021
-Documento scientifico di aprile 2021
-Documentazione WhatsApp del 2023

Di supercazzole ne vedo molte lato tuo. Quando non sai più come argomentare tiri in ballo questioni farlocche, è già la seconda-terza volta. Inoltre, invece di dimostrare i fatti con riferimenti validi di terzi esperti, la butti in caciara. Tipico di chi non sa cosa dire.
Riportami delle fonti autorevoli che smentiscono i vari articoli di ricercatori e giornalisti sopra e ne possiamo parlare.


Se tu fossi VERAMENTE esperto di crittografia/sicurezza come affermi, o anche semplicemente programmatore, non andresti mai a prendere articoli obsoleti e di epoche diverse come stai facendo. Visto che dal 2016 ad oggi non ci sta un solo software di messaggistica che non sia variato completamente a livello di codice e tecnologia su tutti i fronti.

Stai facendo un minestrone di epoche differenti che solo uno inesperto che non ne capisce una mazza in merito può fare.

Seguiti adeguatamente tutti i client di messaggistica, come faccio io da anni, e solo dopo, forse, puoi considerarti minimamente esperto, anziché improvvisarti tale raccattando link obsoleti a destra e a manca.

Io non sono esperto, mai affermato. Conosco dei fatti e riporto pareri di esperti che contraddicono le tue affermazioni. Ci sono articoli di tutti i periodi, non mi risulta che il protocollo di signal alla base di whatsapp sia cambiato dal 2016. Pronto a cambiare idea con fatti, non con le tue barzellette su Grillo o altro.


Si, il problema, infatti, è che hai tagliato fuori tutti gli altri passaggi, connessioni e scambi di chiave che avvengono DOPO che smontano, di fatto, completamente la tua argomentazione.

Va bene. Rileggiti l'articolo recente (https://eprint.iacr.org/2021/498.pdf)che ti ho riportato varie volte.


Entrambi predicano libertà ma poi la tolgono al primo dissenso. Libertà finché fa comodo a loro.
O vuoi negare anche questo?

Di predicatore ne vedo solo uno, tu. Per me rimangono lontani anni luce, ma questo è solo un mio parere. Uno vive in esilio e combatte i governi per la democrazia, l'altro è al soldo dei governi.


Intendo la vendita degli username*, stavamo parlando di quello, ma contestualizzare le frasi, neanche?
* infatti ho parlato di "questione degli username", non solo di "username" nell'ultimo messaggio

Cerca di essere più preciso. Comunque, se ti interessa, Durov ha riattivato le reazioni proprio ieri (https://t.me/s/durov/206).


Come già detto il paragone ha perfettamente senso.

Solo nella tua mente, ma rispetto i pareri degli altri.


Se condividi cosa pensa sulla crittografia Snowden, che ha fatto un esplicito endorsement a Signal (di cui WhatsApp ne condivide il protocollo), significa che soffri di personalità multiple, visto che sono svariati post che stai affermando di non condividere quanto detto da Snowden (che per l'appunto ha criticato il modello di sicurezza di Telegram).

Dove avrei scritto di non condividere cosa afferma Snowden? Riportamelo.
Signal e whatsapp sono lontani anni luce pur avendo lo stesso protocollo. Sia per il fatto che il secondo è closed source con binari offuscati sia perché salva tutto in cloud in chiaro di default (ci siamo capiti cosa intendo, è cifrato ma leggibile da facebook (meta) che possiede le chiavi oltre ai pericoli di google e apple riportati in precedenza) e opzionalmente con crittografia e2e (in questo caso nessuno può leggerlo, salvo backdoor nel codice non analizzabile pubblicamente).


Mi sa che a te non hai letto bene una cosa che ho affermato prima, te la riposto, così leggi meglio:






È ufficiale. O non sai leggere, o fai finta di non saper leggere.
Ho affermato che è fallato, ma NON NELLA IMPLEMENTAZIONE DI SIGNAL (è in uno dei thread sul forum di Signal, cercatelo da solo)
Così come IGE è ancora fallato (ed è anche Telegram stesso a dirlo, ti ho postato il link), ma non nella implementazione di Telegram.

I tre ricercatori (uno (https://palant.info/2020/06/16/does-signals-secure-value-recovery-really-work/), due (https://sgaxe.com/files/SGAxe.pdf) e tre (https://blog.cryptographyengineering.com/)) di sicurezza affermano il contrario, ma l'esperto sei tu.


Si ma guarda che quello che hai evidenziato, smentisce completamente quanto hai affermato te fino adesso eh.

Certo poi se di un intero paragrafo ti leggi solo la frase "man in the middle" ignorando o non comprendendo tutto il resto, ovvio che pensi di aver ragione.
Ma così non è.

I fatti e le prove sono li, negare l'evidenza non serve.


Infatti, non sto parlando di istanze terze, ma di Element.io / Matrix.org: Quei dati NON LI RACCOGLIE CON LA CHAT, ma con LE CAMPAGNE PUBBLICITARIE SUI SOCIAL, sono due cose distinte e separate.

E ad Element / Matrix dell'azienda in questione. puoi REGISTRARTI IN TOTALE ANONIMATO, senza fornire né nome, né email né numero di telefono (cosa non possibile con Telegram, se non di recente, pagando)

Dove ho scritto che le raccoglie con l'analisi della chat? Dato che è cifrato e2e non è in grado di farlo. Ho scritto che nelle privacy policy sono chiaramente riportati i dati raccolti e non sono pochi.


richiede di notificare non richiede di inserire l'avviso che notificheranno nella privacy policy.

Tra l'altro la pagina da te postata
"Notification of a personal data breach to the supervisory authority"
"supervisory authority", non "users"
Quindi hai letto nuovamente male, tanto per cambiare, e sbagliato dunque pure l'articolo della GDPR in questione

Si, hai ragione, errore mio, ho scritto male. Garante non utenti.


Ora mi fai però tu una cortesia, mi trovi dove parla si data breach nella privacy policy di Telegram? Perché la parola "breach" non la vedo neanche nominata mezza volta.
https://telegram.org/privacy

E neanche nelle FAQ, pur parlando di GDPR, di breach e simili non ci sta traccia.
https://telegram.org/faq#d-per-quello-che-riguarda-il-gdpr

Infatti, non c'è ed è una mancanza quella di non prevedere un protocollo pubblico di notifica in caso di data breach.

Discorsi ridicoli oltre che scontati.
Tutti raccolgono i dati che ve lo dicano oppure no.

Telegram è russa, indipendentemente da dove abbia la sede e ovviamente i dati dove volete che li invii ? In Tanzania ?

Il DB di Whatsapp è criptato ? Ah e pensate che non siano in grado di decriptarli ? :rolleyes:

Non avevo capito a quale figura ti riferissi. Quando commetto un errore lo riconosco, differentemente da te.


No, qui ti sbagli. Il fatto di aver introdotto il backup e2ee successivamente all'articolo relativo al FBI, non risolve il problema poiché è disabilitato di default e permangono i problemi visto che il 90% dell'utenza non le modifica (è sufficiente un solo membro per gruppo senza backup e2ee per invalidarla a tutti).


Nessun minestrone, quello forse ti piace a te :).
Ciò che ho scritto è la semplificazione di quanto riportato nei link. Li ho riletti e non ho trovato errori. Riportameli.



Se parli della chiave del backup e2ee ok (su questo ti sto dicendo che è vero dall'inizio), se parli di quella del backup di default facebook (meta) ha l'accesso completo è scritto anche nel tuo link oltre che nel mio.
Di lacune ne vedo solo lato tuo, hai la possibilità di capire, ma non vuoi farlo.


Anche io preferisco altro, ma tra whatsapp e telegram, in termini di sicurezza e privacy, molto meglio il secondo lo dimostrano i fatti. Un qualunque software closed source con binario offuscato non può essere verificato e viola il principio Kerckhoffs alla base della crittografia.
Se stai parlando di signal al momento è meglio di telegram, ma per via delle falle di intel sgx e di essere su cloud amazon, non è comunque affidabile.


Di supercazzole ne vedo molte lato tuo. Quando non sai più come argomentare tiri in ballo questioni farlocche, è già la seconda-terza volta. Inoltre, invece di dimostrare i fatti con riferimenti validi di terzi esperti, la butti in caciara. Tipico di chi non sa cosa dire.
Riportami delle fonti autorevoli che smentiscono i vari articoli di ricercatori e giornalisti sopra e ne possiamo parlare.


Io non sono esperto, mai affermato. Conosco dei fatti e riporto pareri di esperti che contraddicono le tue affermazioni. Ci sono articoli di tutti i periodi, non mi risulta che il protocollo di signal alla base di whatsapp sia cambiato dal 2016. Pronto a cambiare idea con fatti, non con le tue barzellette su Grillo o altro.


Va bene. Rileggiti l'articolo recente (https://eprint.iacr.org/2021/498.pdf)che ti ho riportato varie volte.


Di predicatore ne vedo solo uno, tu. Per me rimangono lontani anni luce, ma questo è solo un mio parere. Uno vive in esilio e combatte i governi per la democrazia, l'altro è al soldo dei governi.


Cerca di essere più preciso. Comunque, se ti interessa, Durov ha riattivato le reazioni proprio ieri (https://t.me/s/durov/206).


Solo nella tua mente, ma rispetto i pareri degli altri.


Dove avrei scritto di non condividere cosa afferma Snowden? Riportamelo.
Signal e whatsapp sono lontani anni luce pur avendo lo stesso protocollo. Sia per il fatto che il secondo è closed source con binari offuscati sia perché salva tutto in cloud in chiaro di default (ci siamo capiti cosa intendo, è cifrato ma leggibile da facebook (meta) che possiede le chiavi oltre ai pericoli di google e apple riportati in precedenza) e opzionalmente con crittografia e2e (in questo caso nessuno può leggerlo, salvo backdoor nel codice non analizzabile pubblicamente).


I tre ricercatori (uno (https://palant.info/2020/06/16/does-signals-secure-value-recovery-really-work/), due (https://sgaxe.com/files/SGAxe.pdf) e tre (https://blog.cryptographyengineering.com/)) di sicurezza affermano il contrario, ma l'esperto sei tu.


I fatti e le prove sono li, negare l'evidenza non serve.


Dove ho scritto che le raccoglie con l'analisi della chat? Dato che è cifrato e2e non è in grado di farlo. Ho scritto che nelle privacy policy sono chiaramente riportati i dati raccolti e non sono pochi.


Si, hai ragione, errore mio, ho scritto male. Garante non utenti.



Infatti, non c'è ed è una mancanza quella di non prevedere un protocollo pubblico di notifica in caso di data breach.

Sai cosa? Hai ragione

(Ma perché mi sono stancato pure di risponderti, non per altro... Le discussioni che vanno per le lunghe rimanendo sempre sullo stesso punto e ripetendo sempre le stesse cose mi annoiano)

Sai cosa? Hai ragione

(Ma perché mi sono stancato pure di risponderti, non per altro... Le discussioni che vanno per le lunghe rimanendo sempre sullo stesso punto e ripetendo sempre le stesse cose mi annoiano)

Chi ha ragione lo devono stabilire gli altri utenti. Ognuno ha riportato i fatti più o meno supportati da riferimenti e le proprie idee, gli altri utenti faranno le proprie valutazioni.
Alla prossima! :D

Chi ha ragione lo devono stabilire gli altri utenti. Ognuno ha riportato i fatti più o meno supportati da riferimenti e le proprie idee, gli altri utenti faranno le proprie valutazioni.
Alla prossima! :D

Ma infatti saranno gli utenti a fare le valutazioni.
(Mi sa che neanche comprendere sarcasmo ed ironia è il tuo forte...)

Certo parlare prima esplicitamente di "come pensi li contatterà gli utenti in caso di breach, gli invia un messaggio?" , e poi ripiegare e dire che parlavi del garante (il garante lo contatti con i suoi appositi recapiti, no ti serve un protocollo per sapere come contattarlo...) quando ti sei reso conto che avevi sparato una castroneria, tra le tante, non depone assolutamente a tuo favore.:)

Saluti

Ma infatti saranno gli utenti a fare le valutazioni.
(Mi sa che neanche comprendere sarcasmo ed ironia è il tuo forte...)

Certo parlare prima esplicitamente di "come pensi li contatterà gli utenti in caso di breach, gli invia un messaggio?" , e poi ripiegare e dire che parlavi del garante (il garante lo contatti con i suoi appositi recapiti, no ti serve un protocollo per sapere come contattarlo...) quando ti sei reso conto che avevi sparato una castroneria, tra le tante, non depone assolutamente a tuo favore.:)

Saluti

Errore mio, dovuto al non rileggere bene quello che ho scritto. Nel link (https://www.privacy-regulation.eu/en/article-33-notification-of-a-personal-data-breach-to-the-supervisory-authority-GDPR.htm) da dove ho preso la frase era chiaro.
Tu i tuoi errori tu non li hai ammessi e ce ne sono diversi. Ciao.

Errore mio, dovuto al non rileggere bene quello che ho scritto. Nel link da dove ho preso la frase era chiaro.
I tuoi errori tu non li hai ammessi e ce ne sono diversi.

Non è solo un errore, è una totale incoerenza ed incongruenza tra le tue affermazioni.

Errore è quando sbagli una parola, non una frase intera, infatti se prendiamo l'intera frase dal post dove ora hai "corretto" per l'appunto la "parola"
Mi sembra che tu neghi l'evidenza dei dati raccolti dall'istanza ufficiale di element. Leggiti la loro privacy policy (non stiamo parlando della tua istanza o di altro). No, non è normale che non sia specificato. L'articolo 33 del GDPR richiede di notificare gli utenti->garante entro 72 ore da un data breach. Se un servizio non prevede un protocollo per la gestione dello stesso, come pensi li contatterà? Gli invia un messaggio?
L'intera frase ha ancora meno senso di prima, e vengono ancor di più fuori le incongruenze tra quello che dici
-"li contatterà", plurale, quando il garante da contattare è uno
-Si, gli invia esattamente un messaggio al garante, è quello che devono fare per legge.

Dulcis in fundo, su PrivacySpy, di cui parlavamo in origine, si parlava di utenti, perché sei passato improvvisamente al garante?
Ti piacciono i minestroni? ;)

Vuoi un consiglio? Tagliamola qui, perché così io evito di perdere tempo inutile a risponderti e tu ti risparmi l'inutile arrampicata sugli specchi in cui ti stai ficcando. :)

Semplicemente io non ho errori da ammettere perché, a differenza tua, mi informo adeguatamente e non dico nulla senza averlo verificato approfonditamente ed esserne certo.

Saluti.

Vuoi iniziare un'altra discussione?

Non è solo un errore, è una totale incoerenza ed incongruenza tra le tue affermazioni.

Errore è quando sbagli una parola, non una frase intera, infatti se prendiamo l'intera frase dal post dove ora hai "corretto" per l'appunto la "parola"

L'intera frase ha ancora meno senso di prima, e vengono ancor di più fuori le incongruenze tra quello che dici
-"li contatterà", plurale, quando il garante da contattare è uno
-Si, gli invia esattamente un messaggio al garante, è quello che devono fare per legge.

Dulcis in fundo, su PrivacySpy, di cui parlavamo in origine, si parlava di utenti, perché sei passato improvvisamente al garante?
Ti piacciono i minestroni? ;)



Io ho scritto L'articolo 33 del GDPR richiede di notificare gli utenti->garante entro 72 ore da un data breach

mentre

Note that all companies operating in the EU are subject to Art. 33 of the GDPR, which requires companies to notify their data protection authority of a data breach within 72 hours of discovering it.


Vuoi un consiglio? Tagliamola qui, perché così io evito di perdere tempo inutile a risponderti e tu ti risparmi l'inutile arrampicata sugli specchi in cui ti stai ficcando. :)

Semplicemente io non ho errori da ammettere perché, a differenza tua, mi informo adeguatamente e non dico nulla senza averlo verificato approfonditamente ed esserne certo.

Saluti.

Gli errori che hai fatto su signal, su telegram e whatsapp sono li con link che affermano il contrario di quanto hai detto.

Vuoi iniziare un'altra discussione?

No, vorrei smettere, in realtà, non ci provo gusto nel continuare a farti fare queste brutte figure che stai facendo

Io ho scritto L'articolo 33 del GDPR richiede di notificare gli utenti->garante entro 72 ore da un data breach

mentre

Note that all companies operating in the EU are subject to Art. 33 of the GDPR, which requires companies to notify their data protection authority of a data breach within 72 hours of discovering it.


Evita di fare Cherry-Picking e copia-incollare solo quello che ti conviene, grazie.

Il testo di PrivacySpy, che io, in ogni caso, ho già affermato essere una fonte discutibile da cui attingere informazioni, dice anche
"Does the policy require users to be notified in case of a data breach? "
Ed è, tra l'altro, quello su cui basa la valutazione.

Al contrario, il testo da te copiato invece, significa che la notifica al garante è obbligatoria e devono farla, per l'appunto, SEMPRE, non è una cosa che puoi o non puoi fare se la scrivi o non la scrivi nella privacy policy, è LEGGE. Sono OBBLIGATI, si beccano una MULTA SE NON LO FANNO.
Non devono scriverlo, devono farlo e basta.

https://web.archive.org/web/20230220190732/https://privacyspy.org/product/element/

Interessante il tuo non rispondere alla parte in cui facevi soffrire di sdoppiamento di entità il garante dandogli del plurale, o in cui volevi un protocollo nella privacy policy per sapere come il responsabile dei dati deve sapere come contattare il garante stesso :)

Dai su ti voglio bene, ma si sente il suono delle dita che strisciano sugli specchi :D

Gli errori che hai fatto su signal, su telegram e whatsapp sono li con link che affermano il contrario di quanto hai detto.

Questo secondo il tuo parere.
Ma credo bastino questi ultimi stralci di conversazioni sulla GDPR per rendere evidente la scarsa attendibilità di quello che affermi.

No, vorrei smettere, in realtà, non ci provo gusto nel continuare a farti fare queste brutte figure che stai facendo

Le brutte figure le stai facendo tu a non voler ammettere l'evidenza. Io quando ho sbagliato l'ho ammesso chiaramente.


Evita di fare Cherry-Picking e copia-incollare solo quello che ti conviene, grazie.

Il testo di PrivacySpy, che io, in ogni caso, ho già affermato essere una fonte discutibile da cui attingere informazioni, dice anche
"Does the policy require users to be notified in case of a data breach? "
Ed è, tra l'altro, quello su cui basa la valutazione.

Al contrario, il testo da te copiato invece, significa che la notifica al garante è obbligatoria e devono farla, per l'appunto, SEMPRE, non è una cosa che puoi o non puoi fare se la scrivi o non la scrivi nella privacy policy, è LEGGE. Sono OBBLIGATI, si beccano una MULTA SE NON LO FANNO.
Non devono scriverlo, devono farlo e basta.

https://web.archive.org/web/20230220190732/https://privacyspy.org/product/element/

Interessante il tuo non rispondere alla parte in cui facevi soffrire di sdoppiamento di entità il garante dandogli del plurale, o in cui volevi un protocollo nella privacy policy per sapere come il responsabile dei dati deve sapere come contattare il garante stesso :)

Dai su ti voglio bene, ma si sente il suono delle dita che strisciano sugli specchi :D

Tu ritieni che privacySpy non sia attendibile, secondo me lo è (certamente più di te, viste le tue risposte). Il testo da me copiato proviene dal privacySpy che a sua volta mette il riferimento all'articolo 33 del GDPR.
Concordo con te e l'ho scritto in precedenza (https://www.hwupgrade.it/forum/showpost.php?p=48117786&postcount=23) che è obbligatorio farlo e che è buona norma, come specificato anche da privacySpy, prevedere un protocollo di notifica per gli utenti. Da qui è nato il mio errore tra le due cose.
Curioso che tu ti sia impuntato in questa parte e abbia trascurato l'essenza della questione ovvero lo scarso rispetto della privacy da parte dell'istanza ufficiale di element (nessuno ha mai parlato dei dati delle chat).
Un tipico esempio del detto "Quando il saggio indica la luna, lo stolto guarda il dito".


Questo secondo il tuo parere.
Ma credo bastino questi ultimi stralci di conversazioni sulla GDPR per rendere evidente la scarsa attendibilità di quello che affermi.

Ci sono evidenze fattuali sostenute da ricercatori e persone indipendenti molto più autorevoli di me e te, riporto l'elenco cosi tutti potranno leggerle e farsi la propria opinione:

Il protocollo di crittografia di Telegram MTProto 2.0 è testato alla pari di quello di Signal, anche se in passato è stato criticato varie volte per non aver seguito vie standard.
2021 Automated Symbolic Verification of Telegram's MTProto 2.0 (https://arxiv.org/abs/2012.03141)
2021 Security Analysis of Telegram (Symmetric Part) (https://mtpsym.github.io/)
Whatsapp è molto peggio di Telegram in quanto a dati raccolti (la crittografia e2e dei backup (https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee-backups/), introdotta in seguito al documento del FBI, è disabilitata di default. Quindi è sufficiente che un solo contatto l'abbia disabilitata in un gruppo per invalidarla per tutti gli altri che l'hanno attiva. Come hai scritto giustamente anche tu, quello che conta sono le impostazioni default dato che oltre il 90% degli utenti non le cambia).
2021 FBI document shows what data can be obtained from encrypted messaging apps (https://therecord.media/fbi-document-shows-what-data-can-be-obtained-from-encrypted-messaging-apps/)
Secondo questi due servizi ToSDR e PrivacySpy:
Whatsapp C (https://tosdr.org/en/service/198)
2021 Whatsapp 4.7 (https://privacyspy.org/product/whatsapp/)
Telegram B (https://tosdr.org/en/service/1946)
2020 Telegram 8.8 (https://privacyspy.org/product/telegram/)
Telegram ha le applicazioni open source con build riproducibili (https://core.telegram.org/reproducible-builds) e quindi se utilizzi le chat segrete e2ee non ti devi fidare di nessuno. Nel caso degli altri tipi di chat, ti devi fidare di Telegram.
Whatsapp utilizza lo stesso protocollo di signal, è closed source con binari offuscati e quindi viola il principio alla base della crittografia di Kerckhoff (https://en.wikipedia.org/wiki/Kerckhoffs's_principle). Inoltre è passibile di attacco MITM poiché come default non notifica gli utenti del cambio di chiave di crittografia dei loro interlocutori.
2017 There is no WhatsApp 'backdoor' (https://signal.org/blog/there-is-no-whatsapp-backdoor/)
2017 Reported “backdoor” in WhatsApp is in fact a feature, defenders say (https://arstechnica.com/information-technology/2017/01/whatsapp-and-friends-take-umbrage-at-report-its-crypto-is-backdoored/) (contiene l'articolo precedente. Io non ho mai parlato di backdoor, ma di attacco MITM).
Il backup eseguito da whatsapp in cloud è cifrato (non completamente solo messaggi, contatti, sticker e impostazioni) con crittografia simmetrica AES e la chiave di cifratura è memorizzata nei server di meta e inviata in caso di reinstallazione o cambio di dispositivo. Quindi con le impostazioni di default ti devi fidare non solo di meta, ma anche di google e apple. Con la crittografia e2e dei backup, supponendo che non ci siano backdoor, dato che il codice sorgente non è verificabile, devi sperare che i tuoi contatti l'abbiano attivata e sei al sicuro.
2016 How can WhatsApp restore local or Google Drive Backups? (https://security.stackexchange.com/questions/136072/how-can-whatsapp-restore-local-or-google-drive-backups?rq=1) (questo è l'unico documento che ho riportato che potrebbe non essere più valido, ma occorrono le prove per confutarlo).
Element/matrix è probabilmente il miglior servizio di comunicazione attualmente presente grazie all'implementazione della crittografia e2e, con possibilità di verifica delle sessioni (https://element.io/blog/e2e-encryption-by-default-cross-signing-is-here/) e sopratutto grazie alla federazione dei server. Tuttavia, l'istanza ufficiale raccoglie un sacco di dati sugli utenti (https://element.io/privacy) (non stiamo parlando delle chat) e il suo rispetto della privacy degli utenti è poco più che sufficiente (https://privacyspy.org/product/element/).
La vera crittografia e2e è possibile solo tra chat 1:1. Nei gruppi è inefficiente dal punto di vista computazionale aprire N-1 canali di comunicazione e2e 1:1 per ogni partecipante e tale implementazione è stata abbandonata praticamente da tutti, anche da TextSecure-Signal, a favore di una che necessita di condividere una sola chiave condivisa per partecipante all'interno di un gruppo (riducendo la complessità computazionale da ~N^2 a ~N). Ho semplificato, ma il succo della questione è questo ed è spiegato molto bene qui, pagina 19.
2021 SoK: Multi-Device Secure Instant Messaging (https://eprint.iacr.org/2021/498.pdf)
SVR (https://signal.org/blog/secure-value-recovery/) di signal si basa sulla tecnologia TEE degli enclavi fallata di intel sgx. Inoltre, signal ha i server su amazon e quindi a causa del problema di intel sgx c'è un elevato di rischio di accesso ai dati (per fortuna vengono salvati in cloud solo il grafo dei contatti e le impostazioni).
2020 Signal Increases Their Reliance on SGX (https://medium.com/@maniacbolts/signal-increases-their-reliance-on-sgx-f46378f336d3)
2020 SGAxe: How SGX Fails in Practice (https://sgaxe.com/files/SGAxe.pdf)
2020 Does Signal’s “secure value recovery” really work? (https://palant.info/2020/06/16/does-signals-secure-value-recovery-really-work/)
2022 Why encrypted backup is so important (https://blog.cryptographyengineering.com/)
2022 SGX, Intel’s supposedly impregnable data fortress, has been breached yet again (https://arstechnica.com/information-technology/2022/08/architectural-bug-in-some-intel-cpus-is-more-bad-news-for-sgx-users/) (che contiene l'affermazione da parte di signal di non essere vulnerabile a questo specifico attacco in merito al private contact discovery (https://signal.org/blog/private-contact-discovery/) non al SVR).


Mi sembra di aver riportato tutti gli articoli che ho citato in precedenza (con la fretta potrei aver sbagliato e sono pronto ad ammettere i miei errori).
Quanto scritto in merito al resto (Snowden, Durov e Musk) sono opinioni e ognuno ha le proprie.
Saluti

Le brutte figure le stai facendo tu a non voler ammettere l'evidenza. Io quando ho sbagliato l'ho ammesso chiaramente.

Hai ammesso 1/10 delle cose sbagliate che hai detto.


Tu ritieni che privacySpy non sia attendibile, secondo me lo è (certamente più di te, viste le tue risposte). Il testo da me copiato proviene dal privacySpy che a sua volta mette il riferimento all'articolo 33 del GDPR.
Concordo con te e l'ho scritto in precedenza (https://www.hwupgrade.it/forum/showpost.php?p=48117786&postcount=23) che è obbligatorio farlo e che è buona norma, come specificato anche da privacySpy, prevedere un protocollo di notifica per gli utenti. Da qui è nato il mio errore tra le due cose.

Confermi la tua completa assenza di cognizione di causa a riguardo: agli utenti, se hai dati criptati e/o che non sono dati sensibili, non devi neanche notificare un bel nulla, al contrario, se queste circostanze non ci sono non è solo buona norma notificare (o come lo dici tu erroneamente "prevedere un protocollo di notifica", ma è OBBLIGATORIO.

La notifica del data breach
Il titolare del trattamento deve informare l’autorità di controllo entro 72 ore dal momento in cui viene a conoscenza di una violazione dei dati personali (data breach). Se il trattamento è effettuato da un responsabile per conto del titolare, il responsabile dovrà darne comunicazione a quest’ultimo immediatamente dopo esserne venuto conoscenza.

Anche gli utenti devono essere informati della violazione (entro lo stesso termine) a meno che i dati violati non siano stati protetti mediante cifratura (e quindi resi illeggibili per l’intruso) o, in generale, a meno che sia improbabile che la violazione comporti un rischio elevato per i diritti e le libertà degli interessati. In ogni caso, il titolare del trattamento deve tenere un registro delle violazioni verificatesi per poter dimostrare all’autorità di controllo il rispetto di tali disposizioni.

https://www.iubenda.com/it/help/5424-guida-gdpr#la-notifica-del-data-breach

E, in ogni caso, per Element ti ho postato un documento intero di 46 pagine sul data processing, che ovviamente hai totalmente ignorato perché non ti conveniva, in quanto confermava l'inaffidabilità di PrivacySpy, e la tua anche.

Ripeto: Taci, fai più bella figura, ed eviti di far perdere tempo a me.

Curioso che tu ti sia impuntato in questa parte e abbia trascurato l'essenza della questione ovvero lo scarso rispetto della privacy da parte dell'istanza ufficiale di element (nessuno ha mai parlato dei dati delle chat).
Un tipico esempio del detto "Quando il saggio indica la luna, lo stolto guarda il dito".


Veramente io ho indicato la valutazione della notifica agli utenti era l'oggetto della discussione, e tu hai guardato DOPO all'irrilevante, soprattutto ai fini del punteggio, sottotitolo.


Ci sono evidenze fattuali sostenute da ricercatori e persone indipendenti molto più autorevoli di me e te, riporto l'elenco cosi tutti potranno leggerle e farsi la propria opinione:

Il protocollo di crittografia di Telegram MTProto 2.0 è testato alla pari di quello di Signal, anche se in passato è stato criticato varie volte per non aver seguito vie standard.
2021 Automated Symbolic Verification of Telegram's MTProto 2.0 (https://arxiv.org/abs/2012.03141)
2021 Security Analysis of Telegram (Symmetric Part) (https://mtpsym.github.io/)
Whatsapp è molto peggio di Telegram in quanto a dati raccolti (la crittografia e2e dei backup (https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee-backups/), introdotta in seguito al documento del FBI, è disabilitata di default. Quindi è sufficiente che un solo contatto l'abbia disabilitata in un gruppo per invalidarla per tutti gli altri che l'hanno attiva. Come hai scritto giustamente anche tu, quello che conta sono le impostazioni default dato che oltre il 90% degli utenti non le cambia).
2021 FBI document shows what data can be obtained from encrypted messaging apps (https://therecord.media/fbi-document-shows-what-data-can-be-obtained-from-encrypted-messaging-apps/)
Secondo questi due servizi ToSDR e PrivacySpy:
Whatsapp C (https://tosdr.org/en/service/198)
2021 Whatsapp 4.7 (https://privacyspy.org/product/whatsapp/)
Telegram B (https://tosdr.org/en/service/1946)
2020 Telegram 8.8 (https://privacyspy.org/product/telegram/)
Telegram ha le applicazioni open source con build riproducibili (https://core.telegram.org/reproducible-builds) e quindi se utilizzi le chat segrete e2ee non ti devi fidare di nessuno. Nel caso degli altri tipi di chat, ti devi fidare di Telegram.
Whatsapp utilizza lo stesso protocollo di signal, è closed source con binari offuscati e quindi viola il principio alla base della crittografia di Kerckhoff (https://en.wikipedia.org/wiki/Kerckhoffs's_principle). Inoltre è passibile di attacco MITM poiché come default non notifica gli utenti del cambio di chiave di crittografia dei loro interlocutori.
2017 There is no WhatsApp 'backdoor' (https://signal.org/blog/there-is-no-whatsapp-backdoor/)
2017 Reported “backdoor” in WhatsApp is in fact a feature, defenders say (https://arstechnica.com/information-technology/2017/01/whatsapp-and-friends-take-umbrage-at-report-its-crypto-is-backdoored/) (contiene l'articolo precedente. Io non ho mai parlato di backdoor, ma di attacco MITM).
Il backup eseguito da whatsapp in cloud è cifrato (non completamente solo messaggi, contatti, sticker e impostazioni) con crittografia simmetrica AES e la chiave di cifratura è memorizzata nei server di meta e inviata in caso di reinstallazione o cambio di dispositivo. Quindi con le impostazioni di default ti devi fidare non solo di meta, ma anche di google e apple. Con la crittografia e2e dei backup, supponendo che non ci siano backdoor, dato che il codice sorgente non è verificabile, devi sperare che i tuoi contatti l'abbiano attivata e sei al sicuro.
2016 How can WhatsApp restore local or Google Drive Backups? (https://security.stackexchange.com/questions/136072/how-can-whatsapp-restore-local-or-google-drive-backups?rq=1) (questo è l'unico documento che ho riportato che potrebbe non essere più valido, ma occorrono le prove per confutarlo).
Element/matrix è probabilmente il miglior servizio di comunicazione attualmente presente grazie all'implementazione della crittografia e2e, con possibilità di verifica delle sessioni (https://element.io/blog/e2e-encryption-by-default-cross-signing-is-here/) e sopratutto grazie alla federazione dei server. Tuttavia, l'istanza ufficiale raccoglie un sacco di dati sugli utenti (https://element.io/privacy) (non stiamo parlando delle chat) e il suo rispetto della privacy degli utenti è poco più che sufficiente (https://privacyspy.org/product/element/).
La vera crittografia e2e è possibile solo tra chat 1:1. Nei gruppi è inefficiente dal punto di vista computazionale aprire N-1 canali di comunicazione e2e 1:1 per ogni partecipante e tale implementazione è stata abbandonata praticamente da tutti, anche da TextSecure-Signal, a favore di una che necessita di condividere una sola chiave condivisa per partecipante all'interno di un gruppo (riducendo la complessità computazionale da ~N^2 a ~N). Ho semplificato, ma il succo della questione è questo ed è spiegato molto bene qui, pagina 19.
2021 SoK: Multi-Device Secure Instant Messaging (https://eprint.iacr.org/2021/498.pdf)
SVR (https://signal.org/blog/secure-value-recovery/) di signal si basa sulla tecnologia TEE degli enclavi fallata di intel sgx. Inoltre, signal ha i server su amazon e quindi a causa del problema di intel sgx c'è un elevato di rischio di accesso ai dati (per fortuna vengono salvati in cloud solo il grafo dei contatti e le impostazioni).
2020 Signal Increases Their Reliance on SGX (https://medium.com/@maniacbolts/signal-increases-their-reliance-on-sgx-f46378f336d3)
2020 SGAxe: How SGX Fails in Practice (https://sgaxe.com/files/SGAxe.pdf)
2020 Does Signal’s “secure value recovery” really work? (https://palant.info/2020/06/16/does-signals-secure-value-recovery-really-work/)
2022 Why encrypted backup is so important (https://blog.cryptographyengineering.com/)
2022 SGX, Intel’s supposedly impregnable data fortress, has been breached yet again (https://arstechnica.com/information-technology/2022/08/architectural-bug-in-some-intel-cpus-is-more-bad-news-for-sgx-users/) (che contiene l'affermazione da parte di signal di non essere vulnerabile a questo specifico attacco in merito al private contact discovery (https://signal.org/blog/private-contact-discovery/) non al SVR).


Mi sembra di aver riportato tutti gli articoli che ho citato in precedenza (con la fretta potrei aver sbagliato e sono pronto ad ammettere i miei errori).
Quanto scritto in merito al resto (Snowden, Durov e Musk) sono opinioni e ognuno ha le proprie.
Saluti

Ecco la ragione per cui non voglio continuare la discussione con te, è un thread intero che posti SEMPRE le pagine di epoche differenti, o di fonti non attendibili.

Hai ammesso 1/10 delle cose sbagliate che hai detto.

Tu nemmeno 1/100 :D


Confermi la tua completa assenza di cognizione di causa a riguardo: agli utenti, se hai dati criptati e/o che non sono dati sensibili, non devi neanche notificare un bel nulla, al contrario, se queste circostanze non ci sono non è solo buona norma notificare (o come lo dici tu erroneamente "prevedere un protocollo di notifica", ma è OBBLIGATORIO.

I fatti dimostrano il contrario. Se leggi la privacy policy (https://element.io/privacy) di element vedrai quanti dati personali non cifrati raccoglie (email, IP).
Io ho sostenuto che fosse obbligatorio per entrambi dall'inizio e avevo scritto erroneamente utenti->garante. Ho anche scritto che sarebbe opportuno scrivere nelle privacy policy un protocollo/procedura di notifica in caso di data breach (https://www.hwupgrade.it/forum/showpost.php?p=48117786&postcount=23).

Mi sembra che tu neghi l'evidenza dei dati raccolti dall'istanza ufficiale di element. Leggiti la loro privacy policy (non stiamo parlando della tua istanza o di altro). No, non è normale che non sia specificato. L'articolo 33 del GDPR richiede di notificare gli utenti->garante entro 72 ore da un data breach. Se un servizio non prevede un protocollo per la gestione dello stesso, come pensi li contatterà? Gli invia un messaggio?


https://www.iubenda.com/it/help/5424-guida-gdpr#la-notifica-del-data-breach

E, in ogni caso, per Element ti ho postato un documento intero di 46 pagine sul data processing, che ovviamente hai totalmente ignorato perché non ti conveniva, in quanto confermava l'inaffidabilità di PrivacySpy, e la tua anche.

Ripeto: Taci, fai più bella figura, ed eviti di far perdere tempo a me.

PrivacySpy è molto più attendbibile di te, dimostra il contrario scrivendo sul loro github, altrimenti sono solo parole. La privacy policy di element parla chiaro, stai negando l'evidenza, come nel resto della discussione.



Io riporto i fatti, tu le tue opinioni personali. Quando vuoi possiamo finirla.

Ragazzi mobbasta :asd: usate C6 e morta li dai

Ragazzi mobbasta :asd: usate C6 e morta li dai

NO! quello non c'ha la GIDDIPIERRE! :D


Tu nemmeno 1/100 :D


I fatti dimostrano il contrario. Se leggi la privacy policy (https://element.io/privacy) di element vedrai quanti dati personali non cifrati raccoglie (email, IP).
Io ho sostenuto che fosse obbligatorio per entrambi dall'inizio e avevo scritto erroneamente utenti->garante. Ho anche scritto che sarebbe opportuno scrivere nelle privacy policy un protocollo/procedura di notifica in caso di data breach (https://www.hwupgrade.it/forum/showpost.php?p=48117786&postcount=23).

Mi sembra che tu neghi l'evidenza dei dati raccolti dall'istanza ufficiale di element. Leggiti la loro privacy policy (non stiamo parlando della tua istanza o di altro). No, non è normale che non sia specificato. L'articolo 33 del GDPR richiede di notificare gli utenti->garante entro 72 ore da un data breach. Se un servizio non prevede un protocollo per la gestione dello stesso, come pensi li contatterà? Gli invia un messaggio?


PrivacySpy è molto più attendbibile di te, dimostra il contrario scrivendo sul loro github, altrimenti sono solo parole. La privacy policy di element parla chiaro, stai negando l'evidenza, come nel resto della discussione.


Io riporto i fatti, tu le tue opinioni personali. Quando vuoi possiamo finirla.

E vabbè dai, mi arrendo, c'hai ragione tu.
Io non so leggere ed accetto delle privacy policy scritte male, insieme a quelli di KDE e Mozilla (https://element.io/solutions/self-hosted-or-cloud-collaboration), di GNOME (https://gnome.element.io/#/welcome) e di Fedora (https://fedora.element.io/#/welcome), e di NixOS (https://nixos.element.io/#/welcome)

E quelli del reparto legale della New Vector, che firmano contratti (https://element.io/customers) con il governo francese, le forze armate tedesche e l'università di Innsbruck, e con la la NATO (https://play.google.com/store/apps/details?id=int.nato.ni2ce) non sanno scrivere una buona privacy policy e rispettare la GDPR.

Non si smette mai d'imparare! :)

Saluti.

E vabbè dai, mi arrendo, c'hai ragione tu.
Io non so leggere ed accetto delle privacy policy scritte male, insieme a quelli di KDE e Mozilla (https://element.io/solutions/self-hosted-or-cloud-collaboration), di GNOME (https://gnome.element.io/#/welcome) e di Fedora (https://fedora.element.io/#/welcome), e di NixOS (https://nixos.element.io/#/welcome)

E quelli del reparto legale della New Vector, che firmano contratti (https://element.io/customers) con il governo francese, le forze armate tedesche e l'università di Innsbruck, e con la la NATO (https://play.google.com/store/apps/details?id=int.nato.ni2ce) non sanno scrivere una buona privacy policy e rispettare la GDPR.

Non si smette mai d'imparare! :)

Saluti.

No hai ragione tu, ormai non contano più i fatti, ma solo le chiacchere e tutti i link riportati scritti da ricercatori, giornalisti o appassionati sono errati.