Delta Chat — dossier probatoire approfondi (état au 13 octobre 2026)¶
Registre de preuves — Phase 2
Ce dossier est une pièce de recherche datée. La conclusion canonique est celle du rapport final 1.0. Les synthèses antérieures et renvois à la Phase 3 restent historiques. UNKNOWN reste UNKNOWN.
Périmètre : client Delta Chat, core Rust/chatmail, relais mail choisis par l’utilisateur, push, mini-apps Webxdc et appels. « Delta Chat » n’est ni un serveur unique ni synonyme de chaque opérateur de relais. FACT = document ou code consulté, pas nécessairement vérification de production; VENDOR CLAIM = déclaration du projet; INDEPENDENT EVIDENCE = analyse tierce; INFERENCE = analyse; UNKNOWN = non établi. Les rapports d’audit détaillés figurent dans les sections précédentes.
| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | Application de messagerie construite sur SMTP/IMAP et relais chatmail; le client, le core Rust et les serveurs sont des composants séparés. Les relais peuvent être communautaires, tiers ou auto-hébergés. FAQ, core | Le service se décrit comme décentralisé, interopérable et relay-agnostic. | Code core et évaluations incluent des bibliothèques réseau / templates mail; ils ne couvrent pas tous les relais en production. | La fédération par e-mail distribue le contrôle mais laisse chaque serveur connaître les adresses et transporter des enveloppes. Une app client ouverte ne rend pas le réseau anonyme. | Inventaire des opérateurs, part de trafic, hébergeurs, logs et configuration de chaque relais utilisé par les profils. |
| 2. Protocole cryptographique | SecureJoin pour l’établissement/authentification de contact, Autocrypt et sous-ensemble OpenPGP via rPGP pour chiffrement/signature; en octobre 2026 la FAQ actuelle dit explicitement pas encore de PFS ni de PQ stable. FAQ crypto | Autocrypt v2 devrait apporter PFS/rotation et PQ, mais la FAQ le laisse « scheduled for full implementation in 2026 ». | Étude ETH/USENIX Security 2024 a trouvé cinq attaques nouvelles contre interactions SecureJoin/Autocrypt/rPGP; un audit rPGP fin 2024 a produit CVE-2024-53856 et -53857, corrigés selon éditeur. | Tant qu’Autocrypt v2 n’est pas attesté dans versions stables, une clé long terme compromise peut révéler les messages chiffrés collectés auparavant; ne pas compter une roadmap comme une propriété déployée. | État exact d’Autocrypt v2/PQ dans chaque stable 2.62.x, rotation effective des clés, comportement de récupération/changement de clé. |
| 3. Création d’identité | Profil créé avec une adresse e-mail; chatmail attribue des adresses générées aléatoirement sur les relais choisis, sans téléphone/e-mail personnel requis. Adresse classique utilisable avec identité réelle éventuelle. Politique, FAQ | Aucun compte chez les développeurs; nom/photo restent sur appareils et chez contacts selon policy. | Le serveur de transport voit néanmoins ses adresses de source/destination; comportement établi aussi dans la FAQ protocolaire. | Un alias aléatoire évite une donnée civile au service, mais les corrélations d’adresse, paiement, IP et réutilisation restent possibles. | Réidentification réelle de chaque profil par les opérateurs, récupération de boîte, paiement/abonnement de relais. |
| 4. Contact discovery | Pas de répertoire public ni recherche par nom/adresse; contact via QR ou lien d’invitation; import du carnet Android existe en option de réglage d’après historique d’app. FAQ, privacy | L’app dit ne pas uploader/accéder au carnet d’adresses. | Aucun manifeste/binaire actuel n’a été audité ici; la FAQ décrit un choix local, mais le label Play et chaque build ne sont pas contrôlés indépendamment. | Le QR/lien protège contre l’énumération publique mais la personne qui le reçoit peut le partager ou corréler le profil. | Comportement exact des apps par plateforme et version au refus/acceptation des permissions; import/sync éventuels hors Android. |
| 5. Métadonnées serveur | Selon FAQ: serveurs voient adresses expéditeur/destinataire, taille et date randomisée; corps incluant métadonnées de message/groupe est revendiqué chiffré. Serveurs supprimeraient après livraison ou généralement quelques semaines. FAQ metadata, policy | Les adresses sont aléatoires par défaut, les dates randomisées et aucun état de groupe stocké en clair sur relais. | Audits historiques et l’étude crypto n’établissent pas en eux-mêmes le comportement de logs actuel des relais. | Le fournisseur voit néanmoins des relations entre adresses de transport sur un même service, tailles et activité; « date randomisée » ne supprime pas une observation d’accès réseau côté ISP/serveur. | Logs SMTP/IMAP et MTA, IP, horodatage exact, backups/log rotation, corrélation entre plusieurs relais. |
| 6. IP utilisateur | Les relais doivent connaître l’IP d’une connexion; core a configuration TLS/proxy/Shadowsocks selon README; les mini-apps par défaut peuvent être téléchargées et le serveur de collection voit brièvement IP. FAQ IP, core, privacy | L’éditeur dit ne pas persister ni exposer les IP; politique dit relais temps réel/Webxdc voient les IP de pairs. | Aucun DNS/ASN ni capture réseau actuel effectué. | Le relais mail, proxy/VPN, fournisseur d’accès, push, pages externes et services auxiliaires sont des observateurs séparés; aucune conclusion « IP jamais visible » n’est valide. | Pratiques exactes des relais tiers, logs Cloudflare/hébergeur, durée et IP vues par le mailserver par version/config. |
| 7. IP exposée au correspondant | Les appels 1:1 essaient le chemin direct pour qualité; clients voient alors leurs IP mutuelles. Call relay voit les deux IP même lorsque le média passe direct; fallback turn.delta.chat documenté. Privacy calls |
E2EE protège le média; relay ne peut pas écouter selon l’éditeur. | Pas de capture ICE/STUN/TURN exécutée. | Le pair peut apprendre l’IP lors d’un appel direct; TURN peut déplacer la visibilité vers le relay au lieu du correspondant, mais ce relay voit les deux IP. | Candidat ICE réel par client, politique relay, IPv6, VPN, mode relay-only et appels vers nouveaux contacts non acceptés. |
| 8. Messages | Avec chatmail par défaut, FAQ dit envoi/réception sans E2EE impossible; avec email classique, messages chiffrés ou non peuvent être envoyés/reçus, les non-E2EE sont marqués d’une icône. FAQ | Le projet dit E2EE automatique par défaut et TLS strict entre appareil et serveur. | Audit 2020 a décrit configurations SMTP sans TLS et DB locale claire dans v1.39; audit TLS 2023 couvre un setup défini, pas tous les fournisseurs. | Le marqueur et le type de relais sont critiques: E2EE n’est pas garanti si classic mail configuré / mode opt-out; transport TLS ne remplace pas E2EE. | Proportion d’utilisateurs en classique, comportement UI dans chaque canal, messages non chiffrés et option « forced E2EE » dans build actuel. |
| 9. Groupes | Métadonnées de groupe et membres sont décrits comme E2EE; groupe égalitaire où tout membre peut ajouter/retirer, modifier le nom/avatar et supprimer des messages; limite pratique recommandée ~150. FAQ groupes | Les relais ne voient pas le groupe ou ses membres en clair. | Étude ETH 2024 analyse relations SecureJoin/Autocrypt; core expose protocole P2P group membership sans état serveur, mais pas d’audit de la totalité des workflows actuels. | Les membres sont un adversaire majeur: chacun peut modifier la liste/exporter le contenu; un relais peut lier adresses et tailles sans nom du groupe. | Fuites de tailles/timings et événements d’adhésion, groupes via relais classiques, récupération historique et comportement en présence de membre malveillant. |
| 10. Appels | Appels 1:1 audio/vidéo sur Desktop, Ubuntu Touch, iOS, Android 8+; direct ou chiffré via relay; call relay voit les deux IP selon privacy. FAQ, privacy | E2EE média et relais incapable d’écouter. | Aucun test WebRTC indépendant de la version actuelle. | E2EE du média ne cache pas IP/heure/durée au relay ni IP au correspondant en P2P. | Chiffrement/mode crypto par build, signaux, enregistrement, groupe, retention de logs, relay utilisé selon fournisseur. |
| 11. Fichiers | Pièces jointes message E2EE, y compris nom/fichier selon FAQ; Webxdc transmis dans le chat; mini-app téléchargée depuis une collection tierce/éditeur. FAQ attachments/Webxdc | Webxdc est sandboxé sans accès réseau ni permission propre; la collection voit l’IP et apps téléchargées brièvement selon politique. | Audit Cure53 2023 a trouvé plusieurs contournements d’isolation Webxdc dans versions antérieures; fixes annoncés en v1.36, pas retest général actuel. | Les fichiers partagés demeurent copiables au contact; la collection Webxdc, preview de liens et stockage local ajoutent des risques hors contenu chiffré. | Parcours exact d’aperçu de fichiers/liens, cache/CDN, version courante de Webxdc sandbox et correspondance au retest. |
| 12. Multi-device | Ajouter second device par transfert local en réseau entre appareils; après transfert les devices sont indépendants. Transfert par serveur non revendiqué dans la FAQ; multi-profil et multi-client supportés. FAQ multi-device | L’éditeur affirme données copiées directement, sans serveur intermédiaire. | Aucun test de protocole de transfert, clés copiées ni captures LAN effectué. | Le second appareil hérite de clés/historique; perte ou saisie d’un appareil affecte profil, même si devices peuvent ensuite vivre séparément. | Chiffrement/authentification exacte du canal P2P, révocation, clés distinctes, copies supprimées et transfert entre réseaux non locaux. |
| 13. Notifications push | Sur chatmail: APNs iOS, FCM Android; code utilise proxy Rust: token chiffré sur relais, proxy le déchiffre et forward, effacement annoncé après livraison; F-Droid/desktop ne font pas de push selon policy. FAQ push, privacy | Apple/Google ne voient pas profil, expéditeur ou contenu; proxy Delta ne voit pas IP/profil. | Pas d’analyse des paquets ou des payloads APNs/FCM de build actuel. | Le token arrive chez Apple/Google; ils voient nécessairement leur échange réseau avec terminal et heures, mais l’association à un profil Delta n’est pas démontrée dans les docs. | Réidentifiabilité, token/device correlation, logs, payload exact, policy APNs/FCM et comportement de classic-mail/F-Droid/UnifiedPush. |
| 14. Stockage local | Les historiques d’audit 2020/2023 ont rapporté DB non chiffrée (versions 1.39 / Desktop ciblé), core actuel déprécie le chiffrement DB car blobs restent en clair et conseille chiffrement du disque. | L’app stocke messages, contacts et clés localement; fonctions d’effacement/disappearing sont côté chaque client. FAQ | Audits passés sont indépendants mais anciens; aucune extraction forensic actuelle d’une build/OS donné établie. | Données en clair au niveau filesystem ou accessibles à une app déverrouillée peuvent être exposées malgré E2EE transport; une suppression côté client ne retire pas les copies de destinataires/backup. | DB v2.62, blobs, WAL, clés, cache, notifications, chiffrement FileVault/BitLocker, effacement physique et extraction appareil verrouillé. |
| 15. Sauvegardes | UI exige le PIN/mot de passe écran avant export manuel; restore depuis fichier backup. API core a passphrase optionnelle historique, mais chiffrement complet des blobs et GUI appelant à vérifier. FAQ backup, API | Documenter le PIN de déverrouillage n’équivaut pas à revendiquer chiffrement cryptographique intégral de l’archive. | Audit 2020 a lu backups SQLite en clair sur 1.39; étude actuelle de backup v2.62 non faite. | Le PIN peut seulement autoriser l’export plutôt que servir de clé de chiffrement; ne pas supposer la protection. | Format et cryptographie d’archive actuelle, chiffrement des médias et métadonnées, passphrase/KDF, sauvegardes OS/cloud. |
| 16. Analytics / SDK tiers | Stats d’usage Android opt-in hebdomadaires vers bot, exemples: versions, QR/invite, erreurs; mini-apps collection, APNs/FCM, relais Webxdc et fallback calls sont services auxiliaires. FAQ, policy | Le projet dit stats anonymes sans PII et pas de tracking; F-Droid/desktop n’utilisent pas push. | Aucun manifest/SDK/APK récent audité; privacy label magasin seul n’est pas preuve runtime. | Opt-in ne signifie pas impossible à corréler si d’autres métadonnées sont envoyées; tiers réseau ne sont pas tous trackers analytiques. | Firebase SDK exact, crash reports, telemetry par store, permission runtime et destinations réseau de la version actuelle. |
| 17. Code source | Clients et core publics; core Rust sert Android/iOS/Desktop et bots; licence et historique GitHub consultables. Core, Android | L’équipe dit que clients/serveurs sont open source et basés sur standards ouverts. | Audits et paper tierce apportent des revues ponctuelles; pas inspection exhaustive de toutes branches/maintainers. | Core partagé réduit divergence cryptographique mais UI/platform-specific/native app demeure une surface distincte. | Liste de mainteneurs actifs indépendants, review de sécurité, composants binaires/serveurs fermés par distribution. |
| 18. Reproductibilité des builds | F-Droid annonce construire/signature son APK depuis source; core annonce builds reproductibles de deltachat-rpc-server. Rien n’a été reproduit dans cette enquête. F-Droid, core |
Les tags/releases peuvent être signés/verified, mais ce n’est pas preuve de binaire identique aux stores. | Aucune comparaison APK/IPA/desktop-artifact à un build local n’a été faite. | Reproduction annoncée d’un sous-composant ne s’étend pas aux binaires mobiles des magasins. | Résultat exact par OS/store, attestation build, provenance, signature tags et reproductibilité des services. |
| 19. Supply chain | rPGP advisories CVE-2024-53856/-53857 ont été publiés et fixes déclarés intégrés depuis décembre 2024; repos exposent lockfiles, CI et changelog. FAQ audits, core | Équipe dit corriger ces CVEs sur tous stores depuis 2024. | Advisories sont éléments publics; scans modernes complets ou vérification des artefacts non faits ici. | Les dépendances Rust/OpenPGP/IMAP/TLS, Electron/Webxdc, stores et push forment supply chain distincte du protocole. | SBOM, versions exactes embarquées dans tous bins, signatures d’artefacts, CI compromise protections et maintainer distribution. |
| 20. Infrastructure | Delta Chat peut utiliser plusieurs relais SMTP/IMAP/chatmail et expose des fonctions auxiliaires de push/Webxdc/TURN; le répertoire officiel dit que les relais sont exploités par des groupes distincts, avec nine.testrun.org comme relais d’onboarding par défaut pour de nombreuses apps. Répertoire, FAQ |
L’équipe encourage les relais chatmail interopérables et l’auto-hébergement; la politique décrit un TURN fallback et des services push. Privacy | DNS/BGP du 14 oct. 2026: nine.testrun.org (A 77.42.49.41, AAAA 2a01:4f9:fff1:59::1) et turn.delta.chat (A 46.224.39.230, AAAA 2a01:4f8:c014:9593::1) sont tous deux annoncés dans AS24940 Hetzner; TTL observés ~3 400 s et ~14 200 s. RIPEstat AS24940 |
L’onboarding par défaut et le fallback TURN constituent des points de concentration/routage mesurables; même ASN ne signifie ni même opérateur contractuel ni que tous les clients utilisent ces hôtes. | Cartographie de tous les relais publics/privés, choix réel selon compte/build, push proxy, région physique, logs/rotation, domaines et IP des services secondaires. |
| 21. Juridiction | Relais peuvent relever de pays/opérateurs différents; développeurs de services (push, mini-apps, stats, fallback calls) distincts des hébergeurs mail. | Le projet dit ne pas gérer de compte et ne pas collecter/stocker les messages ou données personnelles. | Pas de cartographie juridique/contracts de tous opérateurs, ni registre central à analyser. | Légalement demander les données au relais, FAI, cloud, Apple/Google, e-mail classique ou appareil peut atteindre autre chose que Delta Chat developers. | Personne morale exacte par service/domaine, localisation/custody données, sous-traitants, clauses et juridictions actuelles. |
| 22. Demandes policières | Aucun transparency report Delta Chat et aucun cas de donnée réellement livrée par ses développeurs n’a été identifié dans ce dossier. | Politique dit développeurs ne collectent ni ne stockent messages/personnelles; cela ne parle pas pour relais tiers, hébergeurs ou stores. | Pas de recherche exhaustive d’ordonnances/saisie par pays/opérateur menée. | Dans une demande, email providers/relay peuvent produire IP/compte/horaires/taille/adresses; contenu dépend E2EE et option classique. | Données effectivement obtenues dans des affaires réelles, réquisitions à un relais concret et éventuelles demandes sous scellés. |
| 23. Affaires judiciaires connues | Aucun dossier public précis contre Delta Chat/son relay avec retour prouvé de données n’a été identifié ici. | Projet revendique ne pas détenir les messages. | Absence de cas dans les recherches consultées ne vaut pas absence; un serveur e-mail classique relève du fournisseur extérieur. | Séparer remise de Delta Chat, remise d’un mail host, saisie de terminal et données de push. | Demandes judiciaires par nom de relais, saisies, interception et jurisprudence nationale. |
| 24. Audits | Plusieurs audits tiers 2019/2020/2023, étude ETH/USENIX 2024, audit rPGP ROS fin 2024; détails antérieurs à cette section. FAQ audit | Projet dit qu’il subit analyses/audits indépendants continus. | Chaque scope est limité; audits ont détecté findings importants dans protocoles, stockage, Webxdc, template mail et rPGP. | Nombre d’audits élevé n’équivaut pas à couverture complète stable actuelle. | Audit end-to-end v2.62, infra service, store builds, push, forensic, retests détaillés et fixes non liés. |
| 25. Vulnérabilités | 5 attaques crypto ETH/USENIX 2024, webxdc findings high 2023, findings medium core/storage 2020, CVE rPGP 2024 corrigés annoncés. Voir synthèses d’audit plus haut. | Éditeur dit avoir corrigé toutes les issues ETH et fixes rPGP sur tous stores. | Paper peer-reviewed 2024 et advisories corroborent findings; patches encore besoin de retest exact/current. | Il faut distinguer protocole, lib, app, provider mail, stockage local et déploiement; les incidents anciens n’établissent pas la présence en stable courante. | CVE/advisories additionnels pour chaque dépendance/version; patch commit→release→store et exploitation active. |
| 26. Recherche académique | ETH Zurich/USENIX Security 2024 analyse Delta Chat SecureJoin/Autocrypt/rPGP; pièces existantes de recherche PFS/PQ et Webxdc séparées. | Le projet travaille avec chercheurs et cite plusieurs analyses. | L’article 2024 est une preuve indépendante majeure sur protocole spécifique; ne valide pas infrastructure ou current app. | Résultats ont suscité durcissement mais l’absence de PFS actuelle reste un défaut structurel pertinent. | Études récentes sur traffic analysis/réidentification des adresses ou serveurs en conditions réelles. |
| 27. Incidents historiques | Vulnérabilités documentées et corrigées de versions antérieures; aucun incident confirmé de compromission réseau global ou production de messages établi ici. | Projet dit avoir corrigé findings de sécurité et minimise collecte centrale. | Aucun registre incident indépendant consulté. | Faille audit, incident exploitée en prod, panne serveur et saisie légale sont catégories différentes. | Exploitation réelle, data breach, abuse reports, secrets compromis et incidents fournisseurs non publiés. |
| 28. Gouvernance / financement | Projet public et communauté chatmail; financement inclut grants / contributions selon pages officielles; n’a pas été audité pour ownership ou concentration. Financement FAQ | Le projet se présente comme communautaire/open source, avec relais gérés par différents opérateurs. | Pas d’audit gouvernance/finances ni mesure de concentration des mainteneurs consultée. | Client libre et relais diversifiés réduisent un opérateur unique, mais distribution, code review et notification proxy peuvent rester concentrés. | Structure légale, bénéficiaires/financement détaillé, droits de publication, succession et nombre de mainteneurs clés. |
| 29. Résistance à la censure | Relais e-mail multiples et proxy/Shadowsocks documenté dans core; client peut sélectionner/auto-héberger relais. Core | Interopérabilité e-mail et changement de relais sont présentés comme résilience. | Aucune mesure OONI ou blocage par pays/ASN réalisée. | SMTP/IMAP, DNS, relais, stores et push restent bloquables; le transport via email ou proxy dépend de fournisseurs et réseaux. | Résistance DPI, censure des domaines/relais, bridges/obfuscation par build, pays et performance réelle. |
| 30. Maintenance actuelle | Repos core et mobile actifs, stable 2.62.0 fin septembre 2026 dans les notes précédemment consultées; GitHub montre historique actif. Core, Android releases | Le projet publie de fréquentes versions et met à jour plusieurs stores. | Activité observable mais aucun audit quantitatif de mainteneurs actifs, review, couverture test ou délai CVE. | Cadence régulière est un signe d’entretien, non une preuve de sécurité ou qualité de builds. | Nombre d’actifs par composant, maintenance de la pile email, délai de réponse aux vulnérabilités, support des anciennes versions. |
Delta Chat — observation DNS/BGP d’un relais d’onboarding et du TURN fallback¶
Requêtes A/AAAA du 14 octobre 2026 vers 00:38–00:39 heure de Paris (13 oct. UTC), au résolveur local non identifié; préfixes/ASN IPv4 et IPv6 vérifiés avec RIPEstat. Aucun port n’a été contacté.
| Endpoint | Résolution mesurée | Routage BGP observé | Limite |
|---|---|---|---|
nine.testrun.org |
A 77.42.49.41 (TTL ~3 442 s); AAAA 2a01:4f9:fff1:59::1 (TTL ~3 474 s) |
AS24940 Hetzner; 77.42.0.0/17, 2a01:4f9::/32 |
Le répertoire officiel le présente comme onboarding par défaut de nombreuses apps, mais précise que d’autres relais publics et non publiés existent et sont gérés par des opérateurs distincts. |
turn.delta.chat |
A 46.224.39.230 (TTL ~14 243 s); AAAA 2a01:4f8:c014:9593::1 (TTL ~14 275 s) |
AS24940 Hetzner; 46.224.0.0/15, 2a01:4f8::/32 |
TURN n’est pas le serveur de messages; son usage dépend du transport/compte/appel et peut ne concerner que les appels. Même ASN que l’onboarding ne prouve pas même opérateur. |
Le site officiel distingue clairement le réseau de relais des serveurs du projet; les positions géographiques listées pour certains relais sont des déclarations du répertoire, non vérifiées ici. Ce snapshot ne couvre ni tous les chatmail relays, ni les services APNs/FCM/proxy push, ni les serveurs classiques choisis par les utilisateurs. Sources: répertoire chatmail, FAQ Delta Chat, politique vie privée, RIPEstat AS24940.
Delta Chat — matrice des métadonnées¶
Pour « fournisseur », distinguer l’équipe Delta Chat des opérateurs chatmail/e-mail. « Apple/Google » inclut push/store; aucun état ne signifie qu’une donnée a effectivement été remise à une autorité.
| Métadonnée | Fournisseur / relais | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ aux relais; développeurs disent ne pas conserver; services call/Webxdc voient aussi IP. | CONFIRMÉ pendant appel direct; POSSIBLE via webxdc temps réel ou lien externe. | CONFIRMÉ source, destination, heures/volumes. | PROBABLE IP de session APNs/FCM device, mapping profil non établi. | POSSIBLE auprès relais, ISP, store, cloud, terminal; aucun retour Delta documenté. |
| Téléphone | NON ACCESSIBLE PAR DESIGN comme compte chatmail par défaut; POSSIBLE via email classique/support/achat. | POSSIBLE s’il est partagé dans profil/conversation ou contact book local. | NON ACCESSIBLE PAR DESIGN via seul flux mail; opérateur mobile peut identifier l’abonné. | POSSIBLE dans compte store; lien vers adresse Delta non établi. | POSSIBLE via téléphone/ISP/store/email provider, pas par les seuls développeurs selon claim. |
| CONFIRMÉ adresses aléatoires de transport visibles au relais; email personnel visible si profil classique. | CONFIRMÉ adresse de transport correspondant, profil peut afficher autre nom. | POSSIBLE si adresse dans TLS app unavailable to passive ISP; logs réseau seuls ne l’établissent pas. | POSSIBLE compte store / push; mapping inconnu. | POSSIBLE auprès relais ou fournisseur email si données conservées; remise effective inconnue. | |
| Identifiant | CONFIRMÉ adresses émetteur/destinataire, randomisées par défaut; clé n’est pas vue par relay selon FAQ. | CONFIRMÉ clé publique/nom/photo/invite reçus. | NON ACCESSIBLE PAR DESIGN comme clé E2EE; destination serveur et timing observables. | POSSIBLE identifiant store/token, lien profil non établi. | POSSIBLE par relay, terminal ou co-utilisateurs selon données. |
| Graphe social | PROBABLE associations entre adresses et messages sur même relay; noms/groupes chiffrés selon éditeur; sealed sender non supporté. | CONFIRMÉ relations, membres, noms et messages visibles au membre. | POSSIBLE par timing/volume/endpoints; pas graphe direct. | POSSIBLE timing push, pas graphe démontré. | POSSIBLE via relais, carnet, backups, membres ou corrélation. |
| Timestamps | CONFIRMÉ relay observe réception/livraison; éditeur annonce date randomisée dans message; durée exact logs inconnue. | CONFIRMÉ dans chat local. | CONFIRMÉ horaire connexion et volume. | PROBABLE push wake-up timing. | POSSIBLE suivant logs du relay/ISP/store/device. |
| Volumes | CONFIRMÉ taille des messages visible à relay selon FAQ; cache mail peut aussi garder messages. | CONFIRMÉ contenu/tailles reçus. | CONFIRMÉ octets/durée. | POSSIBLE cadence push. | POSSIBLE chez relay/ISP/device si conservé. |
| Groupes | NON ACCESSIBLE PAR DESIGN en nom/membres selon FAQ; POSSIBLE inférence depuis destinataires/adresses et motifs. | CONFIRMÉ membres, contenu, changements; tout membre a des droits égaux. | POSSIBLE corrélation trafic. | POSSIBLE notifications/timing, lien au groupe inconnu. | POSSIBLE via terminal/membres ou motifs relay conservés. |
| Appareils | POSSIBLE par connexions mail/push, pas inventaire public établi; transfer local P2P. | POSSIBLE activité ou présence, pas inventaire fiable. | CONFIRMÉ connexions IP par appareil. | CONFIRMÉ token device côté push, lien profil caché revendiqué. | POSSIBLE auprès store/push/relay/terminal. |
| Push tokens | CONFIRMÉ relais détient token chiffré selon description; proxy le déchiffre et le passe au push provider puis l’oublie selon claim. | NON ACCESSIBLE PAR DESIGN au correspondant. | NON ACCESSIBLE PAR DESIGN token; réseau observe destination APNs/FCM/heure. | CONFIRMÉ token remis au service push; mapping profil non confirmé par sources indépendantes. | POSSIBLE auprès Apple/Google, relais/proxy si réquisition et traces présentes; remise documentée inconnue. |
Delta Chat — première colonne TM1–TM15¶
| Modèle | Cellule | Justification probatoire courte |
|---|---|---|
| TM1 — fournisseur curieux | 🟡 | Relay voit adresses de transport et taille; contenu E2EE par défaut sur chatmail, mais IP/relations d’adresses demeurent observables. FAQ |
| TM2 — fournisseur compromis | 🟡 | E2EE limite lecture contenu et signature/clé limite substitution; compromission peut bloquer, supprimer, retarder ou corréler adresses. |
| TM3 — fournisseur malveillant | 🟡 | Le relais n’est pas supposé voir la clé selon v2, mais l’invite peut usurper une identité et les builds/update pipeline ne sont pas reproduits. FAQ |
| TM4 — ISP / Wi-Fi / réseau local | 🟠 | TLS cache contenu de transport classique entre appareil et relay; DNS/destination, IP/temps/volumes restent visibles, appels P2P révèlent IP au pair. |
| TM5 — passif multi-points | 🟠 | Adresses/tailles et timing peuvent être corrélés entre relais et accès; aucun padding/mixnet n’établit une résistance générale. |
| TM6 — adversaire global passif | 🔴 | Architecture e-mail à faible latence et pas de sealed sender; pas de résultat prouvant résistance globale à analyse de trafic. FAQ |
| TM7 — contact malveillant | 🟠 | Le correspondant connaît adresse/clé/profile; appel direct peut révéler IP, fichiers peuvent être sauvegardés; Webxdc/invite et identity spoofing subsistent. |
| TM8 — harceleur/doxxer OSINT | 🟡 | Pas de recherche publique et alias aléatoires disponibles; réutilisation de profil, adresse, photo/nom, invitation, IP/appels et email classique créent des liens. |
| TM9 — demande judiciaire classique | 🟡 | Équipe affirme ne pas stocker messages; relay/e-mail provider détient adresses, logs et messages E2EE ou plaintext classique; aucun cas Delta réellement documenté identifié. |
| TM10 — enquête sophistiquée | 🟠 | Agrégation FAI, email relay, APNs/FCM, terminal, backups, contacts et IP d’appel peut identifier/obtenir du contenu local. |
| TM11 — appareil verrouillé | ❓ | Aucun test forensic current app + modèle + OS + tool; audits storage 2020/2023 ne permettent pas de conclure sur les versions actuelles. |
| TM12 — appareil déverrouillé | 🔴 | Clients stockent messages/contacts/clés localement; audit ancien DB claire et core déprécie DB encryption; OS full-disk encryption reste essentiel. |
| TM13 — spyware targeted | 🔴 | Malware avec écran/mémoire/DB déchiffrée lit avant/après E2EE. |
| TM14 — supply-chain compromise | 🟡 | Code/core publics et F-Droid/repro claims; aucun build store comparé, apps/platform CI/backend/push restent dépendances. |
| TM15 — censure étatique | 🟠 | Multiples relais/email et proxy peuvent aider; DNS/SMTP/IMAP, domaines, stores et push restent blocables, pas de mesure OONI actuelle. |
Delta Chat — contradictions et expériences requises¶
- PFS/PQ / roadmap : la FAQ actuelle répète que PFS et PQ ne sont pas encore supportés et annonce Autocrypt v2 « scheduled in 2026 »; la stable 2.62.0 observée en septembre ne documente pas une livraison. Statut stable 2026 à re-vérifier par code/tag et échange interop avant de mettre à jour.
- Metadata : la policy présente adresses aléatoires, taille et date randomisée comme seuls champs visibles par relais; FAQ dit explicitement qu’il ne supporte pas encore sealed sender. Ces assertions ne se contredisent pas nécessairement : chiffrer nom/groupe/date applicatifs ne cache pas l’association des adresses SMTP/IMAP ni les logs réseau.
- IP : la FAQ dit que les relais doivent connaître l’IP et que l’app ne la persiste/expose pas; la policy admet que le service Webxdc realtime voit les IP, et que les pairs se voient lors d’un appel direct. La portée de « n’expose pas » est donc au service de messagerie, pas à tous les appels/fonctions.
- Storage/backup : audits historiques ont vu DB/backup clair; état actuel et backup v2.62 restent non vérifiés malgré que le code documente des options obsolètes/export. Le PIN affiché avant backup ne prouve pas chiffrement de l’archive.
- Tests à faire : capture message chatmail vs email classique et extraction des headers; DNS/IMAP/SMTP/proxy IP passifs; call ICE direct/TURN; tester notification APNs/FCM; inspecter manifests/SDK et usage carnet; comparer backup Android/iOS/Linux et WAL/DB avec build/OS précis; reproduire F-Droid/Play/IPA; confirmer Autocrypt v2 par test de négociation; exécuter test de réidentification d’adresses/timing avec deux relais contrôlés; solliciter les opérateurs pour leurs retention/log policies. Aucun de ces tests n’est revendiqué comme effectué.