Discord — dossier individuel d’investigation (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. Discord messages/text, server channels and DMs are not E2EE. As of March 2026 DAVE E2EE is on by default for eligible voice/video calls, excluding Stage channels. A/V keying and message-store semantics are distinct.
| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1 Architecture | Centralized account/platform, API, text message storage, servers, media gateway/SFU; most voice/video has Cloudflare Edge routing by 2026. | Discord publishes architecture/engineering notes and DAVE code/spec. | 2026 engineering post states >80% voice/video traffic on Cloudflare Edge network, 300+ cities; specifically voice/video, not all backend. | Platform/operator can read server-side text and group membership; call relays still see network-level metadata. | Full domain/API/region/CDN mapping for text, attachments and each voice path. |
| 2 Protocole cryptographique | DAVE uses MLS-based group keying and ratcheted media encryption; voice gateway distributes/authenticates group-state and SFU relays encrypted media. | Vendor calls DAVE E2EE and says all eligible calls are E2EE by default since early March 2026. | Independent Trail of Bits protocol-design/implementation/WebAssembly reviews; code open. Oct 2026 advisory found a validation bug that could admit unrecognized participant when attacker controls signaling path. | E2EE applies media, not account metadata, membership exposed to signaling, or Discord text. | Current rollouts/platform protocol versions, client/server adoption of libdave fix v1.2.0, cross-platform consistency. |
| 3 Création d’identité | Account uses unique username/user ID plus credentials and may add email/phone; device/account telemetry. | Discord offers pseudonymous display identities and safety controls. | Privacy policy and LE guide enumerate subscriber/profile information. | Stable user ID and server/usernames can be correlated across public messages even if no legal name. | Which signup credential is mandatory per geography/product flow and retention. |
| 4 Contact discovery | Friend lookup via username/user ID, invites and contact sync/phone features depending settings. | Discord says contact sync is optional and controllable. | Help/policy public; no current app permission/traffic test. | Searchable unique handles and public server participation are OSINT surfaces. | Exact current contact-upload scheme/rate limits and account visibility defaults. |
| 5 Métadonnées serveur | User/account, IP, device, messages, interactions, timestamps, server/channel membership, attachments and event logs may be held; text DMs/channels not E2EE. | Privacy policy and transparency explain collection/retention/requests. | DOJ case in Oct 2026 shows stored DM records actually returned under warrant; case cites voluntary Discord data too. | Central service can produce message body/metadata subject to retention and legal process. | Exact retention by data type, deleted messages, audit access, region-specific logging. |
| 6 IP utilisateur | Discord receives source IP for API/login; voice/Cloudflare edge sees IP per session; policy lists IP. | Discord claims use for service/security and describes subprocessors. | Engineering post confirms Cloudflare edge voice traffic; policy/LE guide. | More than one provider may observe a call path; Cloudflare does not become E2EE endpoint but sees network/session. | Per-product logs/retention and mapping of text API to hosts/ASNs. |
| 7 IP au correspondant | Calls use relayed service infrastructure, voice Gateway/SFU; peer-to-peer exposure is not generally required as a Discord call architecture. | DAVE docs describe SFU/relay voice design. | Public architecture and edge migration post; no pcap or browser ICE candidate test here. | Discord relay can mask peer IP but sees each endpoint IP; bots/links outside voice may expose separately. | Exact clients/modes using direct vs relay candidates, stage/stream exception. |
| 8 Messages | Text DMs/server content is server-readable and stored subject to policy; no E2EE for text as of reviewed product docs. | Discord says it stores/processes content for service, safety, moderation and user controls. | DOJ US v Bryant says Discord gave FBI responsive records from a warrant; messages absent from suspect’s phone. This is strong case evidence text was available at server. | DAVE E2EE must not be generalized to messages. | Retention/deletion behavior and if future private message E2EE features alter scope. |
| 9 Groupes | DMs, group DMs, server channels with roles/membership; chat messages unencrypted E2EE-wise. | Discord moderation/safety features support scanning/review/reporting. | Court case records DMs obtained; public API/product semantics. | Server operator knows membership, message and role graph; members may copy contents. | Exact archived/deleted message retention and legal fields per channel. |
| 10 Appels | Eligible voice/video DMs, group DMs, voice channels, Go Live are DAVE E2EE by default since early Mar 2026; Stage channels excluded. | Discord says DAVE covers audio/video and prevents platform access to media plaintext. | ToB scoped reviews plus open protocol/code and 2026 vendor engineering statement; no runtime capture across every platform. | SFU/voice gateway still sees IP/participants/timing/control metadata, but E2EE can prevent reading valid media. | Platform/version rollout and whether any bot/SDK/Stage stream interop changes media security. |
| 11 Fichiers | Attachments uploaded to Discord storage/CDN; ordinary chat files are not E2EE at rest/through service in this dossier. | Privacy/safety docs provide upload scanning/moderation descriptions. | Discord court/LE materials and policy; no current file ciphertext test. | Service can access stored attachments, while links/CDN cache can outlive message context. | Encryption at rest/key custody, attachment retention after deletion, CDN and previews. |
| 12 Multi-device | Account login across desktop/mobile/browser/console and OAuth/bots; server synchronizes text. | Discord promotes cross-platform sessions. | Open DAVE library targets client platforms; case/policy support multi-device. | Additional signed-in clients and push tokens expand endpoint and access surfaces. | Session/device revocation semantics, per-device key handling for DAVE and exact sync data. |
| 13 Push | Mobile/desktop push and notification services; preview contents may be locally configurable; exact providers by platform. | Discord exposes notification settings and privacy controls. | No current binary manifest/payload capture. | Apple/Google or OS notification broker sees token/event and may receive notification metadata/content. | FCM/APNs use, payload, SDKs, token retention, lock-screen truncation. |
| 14 Stockage local | Apps cache local DB, attachments, logs and sessions; decrypted text accessible to signed-in app. | Discord has local app settings/cache clearing. | No current app data-dir forensic report tied to 2026 build in this investigation. | Unlocked session or compromised process gives plain text irrespective of DAVE media encryption. | Encryption-at-rest details, OS key store, current schema and cache deletion. |
| 15 Sauvegardes | User export/data package and OS/desktop backup possibilities; no user-managed E2EE backup guarantee for messages established. | Discord offers data request package and user data controls. | No encrypted backup protocol audit found. | Cloud platform copies/server retention are distinct from local backup. | Device backup defaults, export encryption and retention/deletion after account removal. |
| 16 Analytics / SDK tiers | Policy enumerates interactions/diagnostics/device data; analytics settings permit use of data to improve Discord. Third-party customer support vendor incident exposed submitted support tickets and IDs in Oct 2025. | Discord says user controls and subprocessor disclosures apply. | Official breach notice and Play/Apple disclosures; no current binary traffic/SDK scan. | Analytics toggle is not equivalent to preventing core account/IP/session telemetry; contractor may hold support data. | SDK inventory, Firebase/Sentry/analytics runtime payload and retention by app platform. |
| 17 Code source | discord/dave-protocol and discord/libdave public; primary client, text backend and service infrastructure closed. |
Discord says protocol is open and audited. | GitHub repos and ToB public report index; code review does not make full service open. | Public cryptographic component covers limited layer, not deployed clients/server end-to-end. | Exact commits bundled in each current client and server deployment. |
| 18 Builds reproductibles | No full official reproducible build for Discord client established. | DAVE protocol openness/audit should not be read as client rebuild claim. | Closed desktop/mobile app and no matched rebuild evidence. | Store signatures authenticate source channel, not source transparency. | Reproducible client build / provenance attestations / component hashes. |
| 19 Supply chain | Open DAVE code/library depends on release integration; closed app updater, platform store, Cloudflare and other cloud/service providers. CVE fixed in library v1.2.0/cpp commit 9686fba. |
Vendor/advisory recommends patched libdave. | GitHub release and advisory publicly link commit; no independent check of deployed client rollout. | Update distribution and gateway trust are critical to DAVE’s security guarantee. | Exact libdave versions live on all platforms, lockfile/SBOM, release signing and CI secret controls. |
| 20 Infrastructure OSINT | Voice/video edge: Cloudflare 300+ cities, >80% traffic per June 2026 Discord article; prior provider about 30 cities. | Discord engineering post details rollout. | Primary engineering source, not independent traffic measurement. No live DNS/ASN/IP/route query done. | That coverage is only A/V and does not describe chat, DB or file backend. | Domains, current DNS, ASN/anycast, exact regions and cloud providers for each service. |
| 21 Juridiction | Discord Inc. US company; data processed by vendors/regions; legal response depends on user and process. | Policy/LE guide state legal entity and handling. | Public corporate terms and court cases. | US process can reach company, but cross-border restrictions and user location complicate. | Data controller/subprocessor per country and litigation challenges. |
| 22 Demandes policières | Discord publishes legal guide/transparency; can provide subscriber/IP/account/message data according to process and retention. | Discord says reviews legally valid requests and emergencies. | US v Bryant 2026 provides actual disclosure of DM records following warrant; profile identifiers also used in identification. | Unlike E2EE text messenger, content of stored Discord chats can be remitted. | Per-case field set, disclosure counts, retention windows and gag-order rates. |
| 23 Affaires judiciaires connues | U.S. v James Cody Bryant, 2:26-mj-00618-BAT, complaint filed 2 Oct 2026: Discord voluntarily gave RCMP account information; later FBI warrant dated 13 Mar 2026 and records delivered 26 Mar 2026; many DMs over preceding six months, not present on Bryant’s phone. | — | DOJ affidavit/complaint states facts directly, primary court document. It includes account subscriber, communications, usernames, dates, messages; Discord’s own reported review tied account to user. | Actual platform message contents/records obtained; no E2EE claim applies to DMs. Still a complaint affidavit, not a final judgment on guilt. | Exact raw export/metadata fields and whether complete archive included. |
| 24 Audits | Three Trail of Bits reports read directly: DAVE design (PDF cover 16 Nov. 2023; ToB index row says Aug. 2024, 4 engineer-weeks), DAVE code review (final 16 Sep. 2024; 5 engineer-weeks), WebAssembly integration (3 Jun. 2025; 3 engineer-weeks). Targets, commits, findings, scope and fix-review text are transcribed below. | Discord presents DAVE as audited; that is a scoped claim, not assurance about all clients, server systems or later revisions. | The full public PDFs establish 11 design findings, 15 implementation findings and one non-security code-quality note; design and implementation reports include fix reviews with an internal inconsistency in the implementation report. | Exact source revision/current deployed builds and independent confirmation of each remediation remain separate questions. | Whether production clients use the reviewed/fixed revisions on every platform; independent retest after the Oct. 2026 advisory. |
| 25 Vulnérabilités | CVE-2026-104480 / GHSA-3q99-x36r-rchh (Oct 2 2026): libdave before 1.2.0 failed to reject MLS Welcome with unrecognized member; attacker must control DAVE signaling path or equivalent. Fix release v1.2.0/cpp, commit 9686fba; affected/deployed ranges unknown. |
Advisory describes patch; vendor claims no full client rollout? (No deployment statement verified.) | GHSA/NVD and signed GitHub release are public; finding attacks media confidentiality/integrity but requires signaling-path control. CVSS 9.4 indicates severity, not proof exploited. | Gateway integrity is part of real-world E2EE trust boundary; a remote arbitrary Discord user without signaling control is not shown to exploit it. | Affected production-client versions, exploitation in wild, rollout to all platforms and independent regression test. |
| 26 Recherche académique | MLS/DAVE analyses and audits are public; no independent academic measurement of current text moderation/log behavior found. | DAVE design paper reports its model. | Trail of Bits reports plus open IETF MLS docs. | Protocol assurance does not characterize platform deployment access or abuse. | Peer-reviewed 2026 DAVE security evaluation and independent client model. |
| 27 Incidents historiques | Oct 2025 5CA support contractor breach exposed support-ticket/customer identity documents; March 2026 voice outage affected A/V; Oct 2026 DAVE signaling bug advisory. | Discord notifications distinguish contractor incident from Discord core platform. | Company incident reports and advisory. | Third-party support exposure is not a breach of E2EE media or evidence of chat backend compromise; voice outage not a confidentiality incident. | Actual records count/abuse and root cause details not public. |
| 28 Gouvernance / société / financement | Private U.S. corporation with venture/market financing and commercial subscriptions; platform moderation/customer support third parties. | Company publishes transparency/safety policies. | Corporate/legal records and vendor reports; no financial/governance audit in scope. | Centralized governance lets company policy/control shape account/content availability. | Current ownership/control changes, access review, board/security oversight. |
| 29 Résistance à la censure | Central domains, account API, stores, CDN/Cloudflare voice and IP ranges can be blocked; no federation. | Discord does not provide a general anti-censorship network. | No national measurements here; 2026 edge footprint details only latency/service architecture. | Cloudflare and platform store choices can be both resilience and centralized dependency. | Country/ISP block history, protocol obfuscation and fallback capability. |
| 30 Maintenance actuelle | DAVE rollout reached eligible call paths by March 2026; official client releases and DAVE code updates active in 2026. | Discord says E2EE migration completed; library releases are public. | May 2026 blog, GitHub v1.2.0 release, CVE Oct 2026 establish active maintenance and patch activity. | Active maintenance does not show patch shipped to every production surface. | Client update timeline, release versions, exact per-platform code commit and regional deployment. |
Discord — audits DAVE, repositories, mobile, forensics et droit¶
| Rapport / organisme / chronologie | Version, commits, durée | Scope / exclusions / méthodologie | Findings, sévérité, recommandations et correction/retest | Limite résiduelle |
|---|---|---|---|---|
| Trail of Bits, “Discord DAVE Protocol Design Review / Cryptographic Design Review” (PDF canonique ToB). La couverture porte la date du 16 nov. 2023; deux consultants, revue du 25 sept.–6 oct. 2023, 4 engineer-weeks; fix review le 9 nov. 2023. L’index de ToB classe le rapport sous août 2024 et 4 engineer-weeks : décalage de dates à conserver, cause inconnue. | Document DAVE du 21 sept. 2023; Discord monorepo a02db9bc34e6bbc5b1eb1e0149d7b056828afacc; mlspp 8a010ef9ce9f1bdd8b79a11ee1c089440a3f63fb. |
Revue approfondie de conception MLS (authentification, livraison, membership, validation/progression) et du chiffrement média DAVE/codecs, avec accès au document, sources mlspp et monorepo. Le code était une référence pour comprendre le design, pas une revue approfondie de l’implémentation. Analyse manuelle de protocole et documentation codecs; le rapport ne décrit pas de campagne automatisée. |
11 findings : TOB-DISCE2EE-1 commit spam/DoS (Medium); -2 validation de leaf nodes (Medium); -3 durée de vie key packages (Informational); -4 MITM possible via client Web (High); -5 Welcome omis (Medium); -6 membre retiré pouvant encore déchiffrer (High); -7 fingerprint vulnérable à préimage partielle (Medium); -8 falsification du message de signalement d’abus (Medium); -9 forward secrecy affaiblie (Low); -10 risque de frames AV1 non chiffrées (High); -11 header vidéo non authentifié (High). Recommandations : corriger avant production; faire piloter l’évolution MLS par le serveur de signalisation; tester/intégrer les codecs, migrer vers chiffrement par paquet quand les API le permettent; revoir le code après implémentation. Fix review : 10 résolus, 1 partiel (-8, la conception de signalement restait à décider); corrections de design décrites pour commits DS, vérification QR, dérivation des clés et authentification AEAD des données clear. |
Le fix review porte sur des zones du document de conception, non une analyse complète du système. L’index 2024 et le PDF (2023) n’ont pas de date harmonisée. |
| Trail of Bits, “Discord DAVE Protocol Code Review / Security Assessment” (PDF canonique ToB). Final le 16 sept. 2024; trois consultants; engagement 12–16 août 2024, 5 engineer-weeks; fix review 4–6 sept. 2024. | Discord monorepo commit 67a37e2dc8a5774c99c996a4ad49e39b072266d6; C++, JavaScript, Elixir; plateformes listées Windows, macOS, Android, iOS. |
Implémentation client libdave et Discord Voice/MLS delivery, frames/media, validation, clés et UI de vérification. Sources/design accessibles. Tests statiques et dynamiques, manuels et automatisés; fuzzing ciblé; CodeQL JS, Cppcheck, Flawfinder, Semgrep. Exclusion explicite : pas d’audit end-to-end de mlspp; CodeQL ne pouvait pas construire libdave seul faute d’accès à d’autres repos privés. |
15 findings : TOB-DISCE2EC-1 UB frame parser (M); -2 validation ranges (M); -4 validation taille clé Windows (L); -5 frames différentes aux participants en retard / non-key-committing AEAD (L); -6 rejeu/réordonnancement (Info); -7 offsets/ranges non authentifiés (M); -8 contrôle de taille (Info); -9 overflow entier (L); -10 lecture hors limites H26X (L); -11 validation type proposal (L); -12 UI ne distingue pas certains échecs de vérification (Info); -13 clé publique non liée au compte (L); -14 secrets non effacés de mémoire (M); -15 session non fermée sur MLS invalide (Undetermined); -16 ratchet statique présent dans un chemin de production (H). Recommandations : fixes avant prod, property/randomized testing et couverture fuzz, support WebRTC natif des streams chiffrés, revue complète mlspp, migration progressive hors C/C++. Le texte du fix review dit 12 résolus, 1 partiel, 2 non résolus, mais sa table classe les 15 résolus et les résultats détaillés donnent des correctifs pour les 15 : contradiction interne au PDF. Les commits de correction documentés : 301f58369a285f8fa8107352f565d43f7d93d63b, ac5117f66bed96fa8821f6541becb7b11aa23a0a, d735f4b3f92741ea6483bd351f0176979457673b, 3bc779728c485c0393528e16616b31d373ddf921, eb9cb0b8bf14acd055c543271d0ad92ea429eb27, ac9e2cd03e2c62caa6d202311608bf0c92d2985a, 09ff623326c42bada57204cc13cf2fbcce3d5d26, 99204180f2674a957dce2b2b1800e3b123b8debe, 460184d8ca6b8486359f82ad1e8ab8bed134dcb9, 4294dc9c7295b87c2a380c2e4dfca3eb2ec084bc, 9c252427bb6b65f7c559bd7f2015cce6cbd9e53e; certains findings sont déclarés résolus par documentation ou par correction d’un autre finding. |
Pas de retest indépendant postérieur publié établi ici. « Résolu » est l’évaluation ToB du fix review, pas preuve que chaque binaire livré en production contient chaque commit. La contradiction de statut interdit de présenter un décompte net sans réserve. |
| Trail of Bits, “Discord E2EE WebAssembly Security Assessment (Summary Report)” (PDF canonique ToB). Rapport final 3 juin 2025; deux consultants; revue 12–21 mai 2025, 3 engineer-weeks (kickoff 8 mai, draft/readout 21 mai). | discord/discord commit 56a840db06a3cc3f8faf61dded1d731903c34146; discord/libdave-private commit 003ff776cb341ee2edb3a06d62cf8c86c5aa9fca; Web. |
Intégration WebAssembly des bibliothèques crypto dans libDAVE et l’app Discord; accès complet aux sources/docs; tests statiques et dynamiques, automatiques et manuels, ciblant branches WASM, build config/wrapper, gestion et nettoyage mémoire. Exclus : protocole crypto global et sécurité des bibliothèques sous-jacentes (ex. OpenSSL). |
Aucun finding de sécurité. Une note qualité de code : construction d’un chemin de stockage de clé à partir de l’ID pourrait permettre traversal si un attaquant contrôlait le session ID; ToB la juge inexploitable en pratique car ce même ID sert cryptographiquement. Recommandation défense en profondeur : canonicaliser/contrôler le chemin (realpath ou équivalent). Le résumé public ne fournit pas de fix review ni commit de correction. |
Un rapport résumé ne garantit pas l’absence d’autres défauts; ne couvre pas tout le protocole DAVE, mlspp, backend Discord ou les autres plateformes. |
GitHub Advisory/NVD, CVE-2026-104480, 2 Oct. 2026; Discord libdave v1.2.0/cpp, 26 Aug. 2026. |
Patch commit 9686fbaea864aa19f0675e486672b6a77811b6a1; exact production-client commit/affected range unknown. |
Reject MLS Welcome containing an unrecognized group member; advisory requires control of DAVE signaling path or equivalent. This is a code/advisory record, not a separate independent audit. | Severity 9.4; patch addresses the validation issue according to release/advisory. | Advisory is unreviewed and reports no confirmed exploitation; release alone does not prove client rollout or independent retest. |
Repos & supply chain: discord/dave-protocol and discord/libdave are public; main clients and backend remain proprietary. The library’s public commit/release and GitHub advisory are directly traceable, but we did not extract per-platform dependency lockfiles, CI signing, current client commit, exact maintainer count or reproducible app build. Do not report “the Discord app is open source” or “Discord binaries reproduce” from DAVE openness.
Mobile privacy: Apple listing, Google Play listing and Discord policy are disclosure surfaces. Google’s method is developer-reported; Apple App Privacy also derives from developer disclosures. Android manifests/iOS entitlements, camera/microphone/photos/contacts/location permission requests, FCM/APNs payloads, Firebase/Sentry/analytics SDKs and runtime network behavior were not captured. No absence/presence claim about a named SDK is made here.
Infrastructure & forensics: The 2026 Cloudflare migration is primary evidence only for voice/video. DNS/ASN/CDN of Discord API/text/file endpoints has not been passively sampled. No public case was found in this evidence pass mapping Cellebrite/GrayKey/Magnet version + platform OS + Discord build + acquisition date. The Bryant case is provider-side disclosure, not a phone-extraction demonstration. Locally cached decrypted messages and push/notification artifacts need app-build- and OS-specific testing.
Law enforcement: distinguish (i) technically stored/readable text DMs and group/server content, (ii) official LE guide/transparency declarations, and (iii) demonstrated delivery: in U.S. v Bryant the FBI received many DMs from Discord after a warrant although they were no longer stored on the user’s phone. The affidavit also says Discord voluntarily shared account/communications information with RCMP shortly after the incident. This is direct evidence of actual provider disclosure of plaintext chat records, not merely theoretical availability. DOJ complaint, 2:26-mj-00618-BAT, Discord law enforcement guide, transparency hub, DAVE protocol, Cloudflare edge engineering post.
Discord — matrice des métadonnées¶
| Métadonnée | Fournisseur Discord / Cloudflare voice | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ app/API and voice edge sees source IP | POSSIBLE external links/bots; generally relay hides peer IP in Discord voice | CONFIRMÉ | POSSIBLE app-store/network identity separate | CONFIRMÉ basic account/session fields under process |
| Téléphone | POSSIBLE/CONFIRMÉ account field by signup/verification | POSSIBLE if shared/profile visible | CONFIRMÉ carrier subscriber data, not Discord account linkage by itself | POSSIBLE phone/account separate | POSSIBLE when account records contain it |
| PROBABLE account identifier | POSSIBLE if disclosed | NON ACCESSIBLE PAR DESIGN | POSSIBLE store account separate | CONFIRMÉ/possible subscriber email if provided | |
| Identifiant | CONFIRMÉ stable user ID, username, device/session | CONFIRMÉ visible username/server IDs | POSSIBLE network correlation | CONFIRMÉ app installation/account record | CONFIRMÉ subscriber/profile records (Bryant case) |
| Graphe social | CONFIRMÉ DMs, server membership/channel roles readable server-side | CONFIRMÉ contacts/room membership | POSSIBLE traffic pattern only | NON ACCESSIBLE PAR DESIGN | CONFIRMÉ communications/contacts/DM logs in Bryant case |
| Timestamps | CONFIRMÉ messages, sessions, voice call events | CONFIRMÉ messages/call time | CONFIRMÉ connection/traffic time | POSSIBLE push/activity telemetry | CONFIRMÉ case records include six-month communications |
| Volumes | CONFIRMÉ message/file/call usage signals; exact fields unknown | CONFIRMÉ content and attachment sizes | CONFIRMÉ bytes | POSSIBLE diagnostics | POSSIBLE/CONFIRMÉ from record set; raw export not public |
| Groupes | CONFIRMÉ channels, membership and messages at service | CONFIRMÉ server/DM membership | POSSIBLE traffic only | NON ACCESSIBLE PAR DESIGN | CONFIRMÉ actual server returned DMs; case includes group/user communications |
| Appareils | CONFIRMÉ device/session fields likely; privacy policy lists device data | POSSIBLE linked-session/status | POSSIBLE fingerprint | CONFIRMÉ app-store/device association | POSSIBLE via provider data or seizure |
| Push tokens | PROBABLE backend push routing | NON ACCESSIBLE PAR DESIGN to normal contact | NON ACCESSIBLE PAR DESIGN | CONFIRMÉ APNs/FCM if used; provider/privacy mapping unverified | POSSIBLE through Discord or push-provider request |
XMPP / OMEMO — matrice provisoire TM1–TM15¶
| TM | Résistance | Justification courte et source |
|---|---|---|
| TM1 fournisseur curieux | 🟡 | OMEMO protège payload si activé et vérifié, mais serveur voit JID, IP, device list, timing, roster/MUC; XEP-0384. |
| TM2 fournisseur compromis | 🟡 | Chiffrement limite contenu historique; serveur peut altérer devices/bundles, bloquer, observer MAM et metadata; OMEMO XEP + ROS 2016. |
| TM3 fournisseur malveillant | 🟡 | Vérification OOB peut détecter une clé substituée; client UI/device trust sont critiques, OMEMO reste expérimental; XEP-0384 status & trust model. |
| TM4 ISP/Wi-Fi | 🟠 | TLS masque corps mais pas IP, timing/volume; ICE/Jingle direct peut exposer IP pair; XEP-0166. |
| TM5 passif multi-points | 🟠 | Serveur fédéré, push, upload/TURN et FAI peuvent corréler metadata; pas de mixnet documenté; XEPs/extensions. |
| TM6 adversaire global | 🔴 | IP/federation and timestamps lack global cover-traffic resistance proof; no global measurement. Inference from architecture; XMPP Core/XEP. |
| TM7 contact malveillant | 🟠 | Le correspondant reçoit clair et peut copier; membres MUC et fichiers partagés sont surface; OMEMO group semantics. |
| TM8 doxxer OSINT | 🟡 | JID stable/domain/pseudo et profils corrélables mais pas téléphone/e-mail universel requis; Conversations account model. |
| TM9 demande légale | 🟠 | Le serveur choisi peut fournir compte/IP/MAM/roster; plaintext OMEMO dépend des clés; données effectivement remises pour un hébergeur non trouvées; Conversations host. |
| TM10 enquête sophistiquée | 🟠 | Combinaison serveur/ISP/push/contact/endpoint contourne protections de contenu; ROS 2025 storage findings. |
| TM11 appareil verrouillé | ❓ | ROS 2025 observe DB en clair sur Android 15/Pixel 7, mais ne teste pas Cellebrite/GrayKey/Magnet sur un appareil verrouillé; rapport. |
| TM12 appareil déverrouillé | 🔴 | Messages/keys en SQLite en clair dans le build audité; endpoint chargé livre le contenu; rapport ROS 2025. |
| TM13 spyware | 🔴 | Malware endpoint voit écran/mémoire/keys avant/après E2EE; déduction de threat model, hors effet des messages chiffrés. |
| TM14 supply chain | 🟠 | Code public mais le build 2.20.4 n’était pas encore le dernier F-Droid verified build; FCM and server remain outside; F-Droid verification. |
| TM15 censure | 🟡 | Federation/self-hosted domain helps migration; DNS/IP/ports/stores/push can be blocked; XMPP federation docs. |
Telegram — matrice provisoire TM1–TM15¶
| TM | Résistance | Justification courte et source |
|---|---|---|
| TM1 fournisseur curieux | 🔴 | Cloud chats are not E2EE; centrally stored/decrypted by architecture; Telegram FAQ. |
| TM2 fournisseur compromis | 🔴 | Cloud chat content and account data remain in centralized service; Secret Chats reduce this only per-device; privacy/FAQ. |
| TM3 fournisseur malveillant | 🔴 | Server closed and no federation; Cloud Chat depends on provider; Secret Chat is a narrower exception; FAQ. |
| TM4 ISP/Wi-Fi | 🟠 | TLS/MTProto transport masks content in transit, not source IP/time/volume; MTProto. |
| TM5 multi-points | 🟠 | Central cloud, push, ISP and direct-call ICE create metadata correlation points; privacy policy. |
| TM6 global passive | 🔴 | No mixnet/cover traffic proof against global IP correlation; inference from centralized network paths. |
| TM7 contact malveillant | 🟠 | Contact sees messages, account/username and can copy; group/cloud content isn't E2EE; FAQ. |
| TM8 OSINT | 🟠 | Required phone and username-change metadata plus lookup surface enable correlation; rate-limits need current testing; privacy, NDSS discovery study. |
| TM9 demande légale | 🟠 | Policy allows phone/IP disclosure after qualifying order; India court case directed account/channel operator data; policy, Delhi HC [accès à vérifier]. |
| TM10 enquête sophistiquée | 🟠 | US DOJ affidavit says typical response phone + latest login IP since Sep 2024; endpoint/cloud material can complete attribution, but no plaintext disclosure proven in case cited; affidavit. |
| TM11 appareil verrouillé | ❓ | L’étude DFRWS 2025 associe Telegram iOS 11.1.1 à une extraction UFED Touch sur iPhone SE/7, mais ne donne ni version iOS, ni version UFED, ni état verrouillé; elle n’établit donc pas l’extraction d’un appareil verrouillé/courant. PDF. |
| TM12 appareil déverrouillé | 🔴 | Cloud and Secret Chat plaintext displayed to active client; device/cache accessible to process. |
| TM13 spyware | 🔴 | Endpoint spyware captures rendered text/keys/notifications; E2EE cannot protect compromised recipient device. |
| TM14 supply chain | 🟠 | Client source and experimental reproducible build guide, but server closed and no current rebuild performed; build guide. |
| TM15 censorship | 🟠 | Central service can be blocked despite proxies; proxy is another trust/routing point; API/FAQ. |
WhatsApp — matrice provisoire TM1–TM15¶
| TM | Résistance | Justification courte et source |
|---|---|---|
| TM1 fournisseur curieux | 🟡 | Private-chat E2EE hides body but phone/contact/group/session metadata remains; privacy. |
| TM2 fournisseur compromis | 🟡 | E2EE reduces server content access; service controls delivery/client-update and E2EE backups are optional; E2EE backup. |
| TM3 fournisseur malveillant | 🟡 | E2EE and safety-code verification help, but closed client/fork and updates remain trust boundary; 2026 model study. |
| TM4 ISP/Wi-Fi | 🟠 | Network sees IP/timing/volume; TLS protects transport and E2EE protects message payload; calls may expose IP if P2P. |
| TM5 multi-points | 🟠 | Meta server, push providers, ISP, backups and direct-call endpoints can correlate; call IP protection. |
| TM6 global passive | 🔴 | No mixnet/global cover-traffic guarantee; centralized delivery/IP routing exposes correlation opportunities. |
| TM7 contact malveillant | 🟠 | Recipient can screenshot/export/forward; phone profile, presence and contact graph visible depending settings; E2EE does not constrain recipient. |
| TM8 OSINT | 🟡 | Phone-number identity and contact discovery permit linking; historic crawling fixed by report, current username deployment/rate limits unresolved; NDSS 2026. |
| TM9 demande légale | 🟠 | Court records show PRTT group participants/timing/types; exact WhatsApp return not public; DOJ affidavit, LE guide. |
| TM10 enquête sophistiquée | 🟠 | Pair’s plaintext, targeted logs, ISP, push/backup and seized endpoint can combine; no current device-tool mapping. |
| TM11 appareil verrouillé | ❓ | No current exact Cellebrite/GrayKey/Magnet + OS + WhatsApp build study confirmed in this phase. |
| TM12 appareil déverrouillé | 🔴 | Active client must render plaintext; device export/backup/OS process becomes available regardless of network E2EE. |
| TM13 spyware | 🔴 | Malware sees input/display, files, keys and calls at endpoint; E2EE is not endpoint defense. |
| TM14 supply chain | 🟠 | Proprietary client/build, closed fork and no reproducible build; recent CVEs and patch uptake require verification; advisories. |
| TM15 censorship | 🟠 | Central service, app stores, SIM enrollment and Meta domains can be blocked; VPN only mitigates some network filtering. |
Discord — matrice provisoire TM1–TM15¶
| TM | Résistance | Justification courte et source |
|---|---|---|
| TM1 fournisseur curieux | 🔴 | Text DMs/server messages are not E2EE; DAVE protects eligible call media only; DAVE rollout. |
| TM2 fournisseur compromis | 🔴 | Central service stores/readable text, memberships and files; actual records returned in 2026 case; DOJ complaint. |
| TM3 fournisseur malveillant | 🔴 | Operator can access text and control signal paths; CVE shows DAVE depends on trusted signaling integrity; GHSA. |
| TM4 ISP/Wi-Fi | 🟠 | TLS/media encryption hides payload but network sees IP/time/volume; Cloudflare and SFU are observable points; edge post. |
| TM5 multi-points | 🟠 | Discord gateway, Cloudflare edge, ISP, push and client can correlate; no padding/mixnet. |
| TM6 global passive | 🔴 | Centralized internet service and live A/V has no demonstrated global correlation resistance. |
| TM7 contact malveillant | 🔴 | Contact can read/send server text, capture media, know account and retain copy; DAVE doesn't prevent recipient capture. |
| TM8 OSINT | 🟠 | Stable user ID, unique names, servers/public posts and optional account identifiers are linkable; privacy policy. |
| TM9 demande légale | 🔴 | 2026 warrant obtained historical DMs absent from device; DOJ case. |
| TM10 enquête sophistiquée | 🔴 | Actual account, DMs and subscriber details produced by service plus platform cross-correlation; same DOJ complaint. |
| TM11 appareil verrouillé | ❓ | No current exact commercial tool + OS + Discord build mapping; account-side history evidence is not device-unlock evidence. |
| TM12 appareil déverrouillé | 🔴 | Active app stores/opens plaintext messages and local attachments; DAVE call endpoint is clear to participant app. |
| TM13 spyware | 🔴 | Endpoint compromise can capture readable text, screen, mic, camera and DAVE keys at client. |
| TM14 supply chain | 🟠 | DAVE library public but main client/backend closed; CVE fix public yet rollout/rebuild unverified; advisory. |
| TM15 censorship | 🟠 | Central domains, stores and Cloudflare voice footprint are blockable; no federation or systematic censorship test. |
Ricochet Refresh — contradictions/tests propres à ce dossier : le slogan « personne ne sait qui/ quand » est plus fort que la propriété démontrée: pas de serveur central n’équivaut pas à résistance globale au trafic. Le cas Boystown indique des données effectivement obtenues du réseau/FAI pour le Ricochet historique; il ne prouve ni remise du contenu ni défaillance de Refresh 3.0.46. L’audit NCC historique est cité dans le dossier avec sa véritable portée; il n’a pas audité Refresh/Tor v3. Expériences requises: pcap 3.0.46 sur interfaces physiques et loopback/Tor control, DNS/IPv6 et navigateur externe; audit du fichier ricochet.json et protections OS par plateforme; extraction d’un poste verrouillé/déverrouillé; contrôle de signatures et rebuild bit-à-bit; test de bridges/censure; comparaison stable 3.0.46 et alpha 3.1 sous revue séparée; analyse des timestamps/tailles du protocole et simulation contrôlée de corrélation sans nœuds Tor publics perturbés.