# Étude comparative des messageries — PHASE 2 : dossier d’investigation approfondie

Snapshot documentaire : **14 octobre 2026**. Ce document prolonge le rapport de Phase 1 par des dossiers de preuves, des matrices et des inconnues explicitement bornées. La synthèse déjà fournie en Phase 1 est conservée comme repère et n’est pas réécrite ici. **Aucun score final ni classement Phase 3 n’est produit dans ce document**; la synthèse finale séparée se trouve dans [enquete-messageries-phase3.md](enquete-messageries-phase3.md). Les références synchronisées de `sources/` sont restées en lecture seule.

## Synthèse antérieure — Phase 1 conservée comme repère

Le bloc ci-dessous reprend la synthèse comparative déjà établie avant cette Phase 2; il est conservé pour garder le contexte et ne doit pas être lu comme le résultat d’un nouveau classement. En cas d’écart, les fiches probatoires et leurs limites de version/configuration font foi.

Il n’existe pas de messagerie qui maximise simultanément confidentialité du contenu, anonymat réseau, minimisation des métadonnées, maturité, résistance aux appareils saisis et disponibilité grand public. Les gagnants changent avec l’adversaire et le mode d’usage. Chiffrement E2EE, pseudonymat et anonymat sont des propriétés différentes; aucune ne neutralise un téléphone compromis, un correspondant qui divulgue la conversation ou une corrélation de trafic globale.

**Pour le scénario principal — une personne rencontrée sur Discord, sans révéler numéro, email ni identité civile, et en cherchant à éviter l’IP et les liens entre comptes — SimpleX est le meilleur point de départ pratique parmi les solutions évaluées**, sous réserve de créer un profil neuf, de ne pas publier un identifiant réutilisé, de désactiver la synchronisation des contacts, de garder les appels relayés ou de ne pas appeler, et de ne pas partager d’éléments identifiants. Son avantage distinctif est l’absence d’identifiant global public et l’usage de coordonnées de connexion propres aux relations; cela n’empêche ni ses serveurs de voir des connexions/IP et des horaires selon le chemin, ni un observateur réseau de corréler le trafic, ni le contact de conserver le contenu. Confiance : **moyenne**, car aucune capture de trafic ou inspection des binaires mobiles actuels n’a été faite.

**Si masquer l’IP à l’infrastructure est plus important que la simplicité et que les deux personnes peuvent adopter un outil de niche**, Cwtch (Tor v3) et Briar (Tor, plus synchronisation de proximité hors Internet) méritent un essai ciblé. Cwtch expose une adresse de profil persistante et des indices de présence si elle est rendue publique; Briar est principalement une solution Android et ses capacités d’usage distant/offline sont différentes. Leur Tor protège contre certains observateurs locaux, pas contre un adversaire capable de corréler les deux extrémités. Ricochet Refresh présente une architecture similaire mais sa maintenance et sa maturité sont nettement moins établies.

**Je ne recommande pas Session comme choix de sécurité maximale pour le scénario sans vérification corrective préalable** : il a un très bon modèle d’identifiants et de routage des messages, mais le protocole courant reste V1, sans PFS selon sa documentation et avec des attaques indépendantes publiées en 2026 contre l’authentification/l’ordre des messages; ses appels P2P exposent l’IP au correspondant et au service STUN/TURN. Le changement d’Oxen vers le Session Network en 2025 rend en revanche inapplicable, sans nouvelle analyse, toute attaque de consensus portant spécifiquement sur l’ancien réseau Oxen.

Signal demeure un choix de sécurité de contenu et de maturité très solide, mais l’inscription utilise toujours un numéro de téléphone que l’opérateur connaît; un username peut éviter de le montrer au contact, pas de l’effacer du modèle fournisseur/télécom. Olvid et Threema évitent l’obligation d’un numéro ou email, mais ne fournissent pas d’anonymat réseau; Olvid a des observables serveur (clés publiques de destinataires, tailles/horaires dans le modèle étudié), et Threema publie des remises judiciaires agrégées de dates de compte/connexion et, sur opt-in, de hash ou push token. Les messageries grand public comme WhatsApp, Telegram et Discord ne conviennent pas à cet objectif d’identité minimisée; Discord conserve en outre le contexte historique de la rencontre.

L’échange initial sur Discord est lui-même une trace : Discord peut connaître les deux comptes, le texte de l’invitation et l’heure du passage vers une autre app. Un changement de messagerie ne supprime ni l’historique Discord ni le lien déjà visible au contact. Dans un dossier pénal américain rendu public en 2026, Discord a fourni des informations à la police puis a remis des messages directs après mandat; c’est une preuve réelle pour Discord, pas une preuve générale sur les autres services. [Affidavit DOJ, U.S. v. Bryant](https://www.justice.gov/usao-wdwa/media/1464546/dl).

## Méthodologie

Périmètre : les 17 messageries demandées, plus Status/Waku comme candidat additionnel sérieux; Molly est évalué comme client Android du réseau Signal, pas comme réseau indépendant; Bitchat est conservé comme outil expérimental de mesh Bluetooth, hors comparaison de messagerie Internet générale. Matrix et Element, XMPP et les clients OMEMO, ainsi que protocole/client/serveur/opérateur sont distingués.

Les sources sont privilégiées dans cet ordre : spécification/code et commits; PDF d’audit et rapports académiques; pièces judiciaires et rapports de transparence; politiques/documentation du fournisseur; analyses indépendantes. Les déclarations fournisseur restent des `VENDOR CLAIM`; elles ne sont pas promues en preuve indépendante. Les disclosures agrégés, procédures judiciaires et retours de données individuels sont séparés. Versions, date, plateforme et configuration sont consignées quand elles sont établies.

Collecte réseau : des résolutions DNS et consultations BGP/ASN horodatées et documentées figurent dans les dossiers lorsque réalisées; elles sont des snapshots ponctuels, pas de l’historique DNS passif, ne démontrent ni la propriété contractuelle, ni la résidence des données, ni la rétention. Aucun scan de port, accès non autorisé, intrusion ou test sur un tiers n’a été effectué.

**Non testé dans cette investigation** : aucune acquisition de téléphone; aucun APK/IPA de chaque canal n’a été téléchargé puis disséqué ici; aucun trafic d’appels/push n’a été capturé entre appareils contrôlés; aucun build n’a été reproduit et comparé à un binaire de store; aucune expérimentation de doxxing ou d’attaque contre des personnes. Les dossiers gardent donc `UNKNOWN` sur ces points. Les tests contrôlés nécessaires sont listés en fin de rapport.

## Définitions utiles

- **Sécurité du contenu** : qui peut lire/authentifier le contenu en transit et au repos; E2EE ne couvre pas automatiquement les métadonnées, sauvegardes ou terminaux.
- **Confidentialité / minimisation des métadonnées** : quantité d’informations révélées par le compte, les serveurs, les relais, les notifications, le réseau et les appareils.
- **Pseudonymat** : usage d’un nom qui n’est pas le nom civil; un pseudonyme stable peut être corrélé dans le temps.
- **Unlinkability** : difficulté à relier deux profils ou deux relations; un identifiant stable, un avatar, une adresse IP ou des habitudes peuvent casser cette séparation.
- **Anonymat réseau** : difficulté à relier une activité à son adresse/réseau ou à un correspondant. Tor/onion routing réduisent certaines observations locales; les systèmes à faible latence ne protègent pas contre un observateur capable de voir/corréler les deux extrémités. [Limites Tor](https://support.torproject.org/about-tor/security/attacks-on-onion-routing/), [threat model Tor](https://spec.torproject.org/proposals/344-protocol-info-leaks.html).
- **E2EE** : le contenu est chiffré entre endpoints; cela ne rend ni le compte anonyme, ni le serveur aveugle à toute métadonnée.

## Candidats et lecture du rapport

Le socle comparatif comprend Signal, SimpleX, Olvid, Session, Threema, Cwtch, Briar, Jami, Tox/qTox, Matrix/Element, XMPP/OMEMO, Telegram, WhatsApp, Discord, Wire, Delta Chat et Ricochet Refresh. Status/Waku est ajouté comme dix-huitième architecture dans les matrices finales. Molly hérite des propriétés réseau/compte Signal, avec différences de client Android. Bitchat est analysé séparément : mesh Bluetooth hors-ligne et passerelle Nostr optionnelle, pas un remplaçant équivalent pour une conversation Internet asynchrone.

Les dossiers individuels, audits, matrices de métadonnées et sources détaillées suivent. La matrice TM transversale sert à lire les expositions par adversaire; elle n’est pas un classement. Toute notation finale selon les 21 dimensions et les 15 scénarios appartient à une Phase 3 séparée.

## Appels WebRTC/VoIP et exposition d’adresse IP

Règle d’analyse : E2EE protège le contenu média, pas les adresses IP. Une ICE candidate publique/directe communiquée au pair peut lui révéler l’IP publique observable. TURN remplace la destination réseau vue par le pair par l’adresse du relais, mais le relais voit les connexions, les IP sources, les temps, volumes et généralement la durée; l’E2EE média limite ce qu’il peut écouter. STUN révèle l’adresse publique au serveur STUN pour la découverte, mais ne relaie pas à lui seul le média. VPN/Tor changent le point de sortie et déplacent la confiance; ils ne garantissent pas qu’aucune candidate directe ou locale ne soit divulguée sans test de la configuration.

| Produit / mode vérifié dans la documentation | Le pair peut-il obtenir l’IP ? | Ce que le relais/opérateur peut apprendre | Limites de la preuve |
|---|---|---|---|
| **Signal, appel 1:1** | **Selon la relation et le réglage** : Signal affirme que les appels initiés par un non-contact sont toujours relayés; les autres peuvent être directs quand la connectivité le permet. « Always Relay Calls » force le relais. | Relais voit connexions et métadonnées réseau; E2EE protège le média. | Documentation éditeur + réglage documenté par [EFF](https://ssd.eff.org/ur/module/how-to-use-signal); pas de capture réseau faite ici. Voir la fiche Signal ci-dessous. |
| **SimpleX Chat** | **Non par défaut selon les docs actuelles** : appels via TURN; désactiver « Always use relay » autorise P2P et peut exposer l’IP au contact. | Le serveur TURN prédéfini peut observer durée d’appel; serveur ICE peut voir les IP qui s’y connectent. Possibilité d’utiliser son propre relais ICE. | La doc permet de changer la configuration; pas de vérification par capture sur versions mobile/desktop. [Guide officiel des appels](https://github.com/simplex-chat/simplex-chat/blob/stable/docs/guide/audio-video-calls.md). |
| **Session** | **Oui actuellement** : appels WebRTC en beta, P2P; la FAQ dit explicitement que le pair et le STUN/TURN géré par STF reçoivent l’IP. Appels désactivés par défaut; pas d’appels de groupe; appels onion-routés annoncés comme futurs dans la FAQ. | Le service STUN/TURN voit l’IP et la session; la FAQ ne démontre pas l’étendue exacte des logs. | Déclaration fournisseur actuelle, pas de mesure indépendante. [FAQ officielle, lignes Calls](https://getsession.org/faq). |
| **Olvid** | **Non selon la spécification 2024** : les SDP ne contiennent que des candidates TURN, ce qui masque l’IP du pair. | TURN reçoit les IP des deux côtés et voit métadonnées/durée; le serveur Olvid délivre les credentials TURN. | La spec précise TURN sur tous les appels; doc admin plus récente annonce régions et possibilité de TURN alternatif sur Android. Pas de test des endpoints en production. [Spec 2024, §39](https://www.olvid.io/assets/documents/2024-10-07_Olvid-specifications.pdf), [FAQ administrateurs](https://olvid.io/faq/for-administrators/). |
| **Threema 1:1** | **Oui si connexion directe possible**; « Always relay calls » route via Threema pour masquer l’IP. L’éditeur indique que les IDs de vérification rouge sont relayés. | Threema/son TURN voit les IP quand appel relayé. | La doc officielle limite la note P2P aux appels 1:1; groupe et versions doivent être vérifiés séparément. [FAQ appels](https://threema.com/en/faq/calls-info). |
| **WhatsApp** | **Oui lorsque l’appel 1:1 est direct**; activer « Protect IP address in calls » fait relayer tous les appels. Les appels de groupe sont relayés par défaut. | Meta/WhatsApp voit les IP et données réseau de ses relais, mais affirme que l’E2EE empêche l’écoute du média. | Documentation Meta et Help Center, pas mesure indépendante. [Engineering Meta](https://engineering.fb.com/2023/11/08/security/whatsapp-calls-enhancing-security/), [Help Center](https://faq.whatsapp.com/2635108359972899/?cms_platform=android). |
| **Telegram 1:1** | **Oui si P2P autorisé**; le réglage P2P désactivé force le relais Telegram pour ne pas révéler l’IP au contact. | Telegram reçoit les connexions/routage; le relais voit IP et timing. | API officielle documente P2P et reflectors; chaîne de traduction officielle décrit le réglage. [API appels](https://core.telegram.org/api/calls), [texte de réglage](https://translations.telegram.org/ru/ios/settings/Privacy.Calls.P2PHelp). |
| **Wire 1:1 / conférence** | **1:1 : oui quand ICE choisit un flux direct**; sinon TURN. Conférence : composant SFT/relay. | Le whitepaper dit que les TURN sont séparés du backend, sans user-ID selon la conception Wire; le TURN voit nécessairement les IP/temps/volume. | Source éditeur, whitepaper §Calling; proposition de séparation non vérifiée indépendamment. [Whitepaper PDF, pp. 24–28](https://wire.com/hubfs/Whitepapers/-wire-security-whitepaper.pdf). |
| **Delta Chat** | **Oui quand ICE établit une connexion directe**, selon la politique officielle. | La politique dit que le relais d’appel voit les IP des deux participants même quand le média est direct; fallback `turn.delta.chat` possible si le chatmail n’intègre pas de relais. | Doc/politique fournisseur; implémentation et configuration relay du contact peuvent varier. [Privacy Policy](https://delta.chat/ca/privacy), [architecture d’appel](https://github.com/deltachat/calls-webapp). |
| **Element / Matrix** | **Non établi uniformément**. Element Call actuel utilise une SFU/LiveKit; les services et le fournisseur voient l’IP, et l’E2EE du média est annoncé. Les anciens appels Matrix/WebRTC et installations auto-hébergées dépendent de la config STUN/TURN et client. | La politique Element dit que Element traite IP, Matrix ID, device ID, timestamp et type d’appel; pour call.element.io, LiveKit Cloud est utilisé. Un homeserver auto-hébergé change l’opérateur, pas le fait que le SFU/STUN voit des IP. | Pas de capture réseau cliente; ne pas généraliser le nouveau Element Call aux appels historiques. [Privacy policy, §Element Call et Push](https://element.io/en/legal/privacy), [Element Call/SFU docs](https://docs.element.io/latest/element-server-suite-classic/integrations/setting-up-element-call/). |
| **XMPP + OMEMO** | **Possiblement oui** : Jingle/ICE peut négocier des candidates directes; TURN peut masquer le pair. | JID/serveur, STUN/TURN et opérateur du client dépendent du déploiement. | Pas d’application cible choisie : conclusion protocolaire, pas comportement universel. [XEP-0166 Jingle](https://xmpp.org/extensions/xep-0166.html). |
| **Jami / Tox-qTox** | **Probablement oui en appels P2P directs**; exactes candidates et réglages par client/réseau non établis ici. | DHT/nœuds bootstrap, peer et éventuels relais voient des éléments différents; logs/config exacts inconnus. | À vérifier par docs/version et capture en laboratoire avant verdict. |
| **Briar / Cwtch / Ricochet Refresh** | Appels temps réel : non documentés comme fonctionnalité actuelle dans les sources examinées; **ne pas supposer qu’ils en ont**. | — | À confirmer par documentation des releases actuelles. |

### Conséquence provisoire pour le cas principal

Si masquer l’IP au correspondant est une exigence ferme et que des appels sont nécessaires, les preuves documentaires actuelles favorisent un réglage explicite de relais : Olvid documente TURN-only; SimpleX utilise TURN par défaut; Signal, Threema, WhatsApp et Telegram ont un réglage de relais; Delta Chat et Wire peuvent établir du P2P; Session expose explicitement l’IP du pair dans ses appels actuels. Cela ne constitue pas un classement général : le relais échange l’exposition au correspondant contre une exposition au relais, et la qualité/configuration doit encore être testée.

## Candidats supplémentaires retenus pour examen

### Molly (Android uniquement; client/fork, pas réseau indépendant)

- **F/VC** : dépôt officiel décrit un fork Android de Signal, compatible avec le réseau Signal, avec chiffrement local par passphrase, verrouillage automatique, prise en charge Tor/SOCKS, UnifiedPush, variante Molly-FOSS et fingerprints de certificat de signature publiés ([repo](https://github.com/mollyim/mollyim-android), [site](https://molly.im/)).
- **Portée** : améliore surtout la sécurité locale, la réduction de dépendance Google et le routage du client. Il ne supprime pas le numéro d’inscription ni le fournisseur Signal, et l’usage de Tor ne neutralise pas le correspondant, le contenu partagé ou les corrélations temporelles.
- **Points à vérifier avant notation** : activité/release exacte en octobre 2026, correspondance Signal protocol version, vérification indépendante des builds reproductibles, provenance du F-Droid repo et comportement de push/calls en mode Tor.

### Status App (Waku/Logos Messaging; app distincte et réseau P2P)

- **Fiche approfondie distincte ajoutée en annexe** : Status demeure un candidat supplémentaire, hors matrice de base des 17 tant que le périmètre de la Phase 3 n’est pas arrêté. L’annexe distingue spécifications 2026, marketing, observables indépendants, versions et inconnues.
- **Point d’attention étayé** : la publication d’infrastructure de Status décrit IP + content-topic visibles pour plusieurs services Waku gérés et une rétention annoncée de 15 jours pour certaines IP; cela ne révèle pas le contenu E2EE, mais exclut de lire « décentralisé » comme « aucun nœud ne voit de métadonnées ».
- **Incident historique distinct** : en 2018, Status a indiqué qu’un bug d’intégration TestFairy dans des builds nightly pouvait enregistrer des phrases de récupération malgré leur masquage attendu. L’éditeur dit avoir retiré TestFairy et supprimé les enregistrements; il déclarait alors n’avoir aucune preuve d’exploitation. Ce cas ne décrit pas les versions courantes.

### Candidats non ajoutés à ce stade

Nym dispose d’une architecture mixnet et de recherches pertinentes, mais aucun client de messagerie grand public mature et actuellement supporté n’a été établi dans les sources consultées; ne pas confondre une bibliothèque/réseau mixnet avec une app utilisable. La recherche continue pour d’autres clients sérieux, sans ajouter de projets obscurs uniquement parce qu’ils revendiquent Tor ou P2P.

### Bitchat (candidat expérimental, pas une messagerie Internet classique)

- **F/VC** : projet public de mesh Bluetooth LE hors ligne avec passerelle optionnelle vers Nostr quand Internet est disponible; le whitepaper décrit Noise XX, X25519, ChaCha20-Poly1305, SHA-256, et une identité à clé stable. [Whitepaper](https://github.com/permissionlesstech/bitchat/blob/main/WHITEPAPER.md).
- **IE / limite de confidentialité** : le whitepaper indique que la clé statique sert à une identité persistante et que l’ID pair est dérivé de sa fingerprint; les annonces publient nom et clés en clair. Dans le mesh, voisinage radio, RSSI, temps et tailles de trafic sont observables. La politique de confidentialité précise que les relays Nostr voient IP, taille/heure et tags de routage; l’affirmation « identité expéditeur non exposée » reste une revendication du projet à valider selon le chemin et la version. [Privacy policy](https://github.com/permissionlesstech/bitchat/blob/main/PRIVACY_POLICY.md).
- **Incident historique sourcé, statut corrigé à vérifier** : une analyse indépendante de 2025 a décrit un défaut précoce d’authentification/liaison d’identité permettant une usurpation/MITM; le projet a ensuite ajouté un avertissement de vérification et remplacé la conception d’échange par Noise selon l’analyse. Cela ne prouve pas une faille dans le code courant. [Analyse technique indépendante](https://www.supernetworks.org/pages/blog/agentic-insecurity-vibes-on-bitchat), [couverture contemporaine de l’absence d’audit externe en 2025](https://techcrunch.com/2025/07/09/jack-dorsey-says-his-secure-new-bitchat-app-has-not-been-tested-for-security/).
- **Supply chain / maturité** : le tag v1.7.1 apparaît avec signature GitHub vérifiée dans la page de releases; cela n’authentifie pas indépendamment l’identité du signataire ni ne prouve un build reproductible. Le dépôt ne listait aucun advisory public au moment de la consultation; absence d’advisory ≠ absence de défaut. L’audit formel actuel et le retest indépendant ne sont pas établis. [Releases](https://github.com/permissionlesstech/bitchat/releases), [Security](https://github.com/permissionlesstech/bitchat/security).
- **Inconnus importants** : état du correctif du bug d’identité dans la version Android/iOS actuelle; comparaison des implémentations; tests de build reproductible; audit; conservation forensic des messages/caches; comportement exact avec Tor désactivé, réseau Nostr donné, et groupes privés. Un tag signé ne clôt aucun de ces points.

## Divulgations légales et cas concrets — faits obtenus, pas seulement capacités

Une distinction doit rester visible dans chaque dossier : (a) le fournisseur déclare qu’il peut conserver/remettre une catégorie; (b) un document juridique demande cette catégorie; (c) une source primaire ou un témoignage crédible établit que la donnée a effectivement été remise ou extraite dans un cas. Les affaires ci-dessous ne permettent pas d’extrapoler la réponse à toutes juridictions, années, versions ou comptes.

| Produit | Donnée effectivement établie dans une affaire publique | Origine prouvée | Ce que cela ne démontre pas |
|---|---|---|---|
| **Signal — remise fournisseur, États-Unis, 2026** | Pour 37 numéros visés par un grand jury, 7 ne correspondaient à aucun compte; sur les 30 existants, la page Signal dit avoir fourni pour 6 comptes les dates de création et dernière connexion demandées; pour 24, aucune donnée responsive pour la période demandée. | Réponse officielle Signal et liens vers subpoena/NDO/lettre ACLU/réponse au tribunal. C’est une divulgation réelle de dates de compte/connexion, pas de contenu. | Ne prouve pas les métadonnées stockées ou obtenues par d’autres voies (téléphone saisi, destinataire, opérateur, Apple/Google); ce n’est pas une mesure de la collecte courante globale. [Signal, subpoena D.C. du 6 mars 2026](https://signal.org/bigbrother/district-of-columbia/).
| **Signal — terminal iOS, procès fédéral rapporté, 2026** | Témoignage FBI rapporté par 404 Media : des messages Signal entrants, réglés pour disparaître et disparus de l’app, ont été montrés; l’app avait été supprimée, mais des aperçus avaient subsisté dans le stockage interne des notifications iOS. Le récit indique uniquement les entrants; pas les sortants. | Extraction locale depuis l’appareil d’une personne, pas remise par Signal. Source directe de presse ayant recueilli notes de l’avocat présent et d’un témoin du procès; l’exhibit complet et les paramètres exacts n’ont pas été rendus accessibles dans cette recherche. [404 Media, 9 avril 2026](https://www.404media.co/fbi-extracts-suspects-deleted-signal-messages-saved-in-iphone-notification-database/).
| **Signal — correctif OS** | Apple documente CVE-2026-28950 : iOS/iPadOS 26.4.2, publié le 22 avril 2026, corrige un problème de journalisation/redaction où les notifications marquées pour suppression pouvaient être conservées. | Avis de sécurité primaire Apple; il atteste le défaut et son correctif, pas l’intégralité du récit du procès ni toutes les versions encore vulnérables. [Avis Apple](https://support.apple.com/en-us/127002).
| **SimpleX — transparence, 2025** | La page officielle dit avoir reçu 12 demandes policières de différents pays, et n’avoir identifié/fourni aucune information responsive. | Déclaration de transparence de l’opérateur; démontre une réponse déclarée pour ces 12 demandes. | Le contenu des demandes, juridictions, validité, période et preuve externe des réponses ne sont pas publiés; ce n’est pas un contrôle indépendant de toutes les données que des relais, FAI ou appareils tiers peuvent posséder. [Rapport SimpleX](https://simplex.chat/transparency/).
| **Threema — données fournisseur, Suisse, agrégat jusqu’au 30 juin 2026** | Le rapport dit qu’en 2025, 423 demandes ont été reçues, 422 ont passé le contrôle formel, 402 affaires ont donné lieu à des données pour 1 505 IDs; le fournisseur dit que la remise se limite aux jours (pas heures) de création et dernière connexion, et selon opt-in, hash du téléphone/email ou push token récent. Pour 2026 au 30 juin : 444 demandes, 438 affaires avec remise pour 2 026 IDs. | Rapport de transparence primaire; chiffres agrégés. | Aucun dossier individualisé public consulté ne précise quelles de ces données ont été remises à quel parquet ou pour quel suspect; le rapport est fournisseur-déclaré et ne montre pas les demandes/décisions brutes. Il ne faut pas traduire « data provided » comme contenu de messages. [Rapport Threema](https://threema.com/en/transparency-report).
| **Threema — contenus de groupes visibles dans une inculpation fédérale US, 2025** | L’acte d’accusation U.S. v. Wedding décrit échanges 1:1/groupes Threema, screenshots et actes d’un groupe créé par « Clark », puis relate qu’il écoutait secrètement un appel. | Document DOJ primaire prouvant que des contenus/événements Threema ont été obtenus par l’enquête; il ne dit pas que Threema AG les a fournis. Les allégations semblent compatibles avec accès d’un participant/co-conspirateur coopérant ou informateur; le canal exact d’obtention des messages n’est pas identifié dans les passages consultés. [Acte d’accusation DOJ, U.S. v. Wedding](https://www.justice.gov/opa/media/1418931/dl?inline=).
| **Telegram — données de compte, procédure civile indienne, 2022** | Après l’ordre du 30 août, Telegram a déposé un affidavit de conformité et des données sous pli scellé. L’ordonnance du 24 nov. 2022 dit que le juge a examiné un tableau indiquant, pour certains canaux, les noms d’administrateurs, numéros de téléphone et adresses IP; Telegram a indiqué que des données de certains canaux n’étaient plus disponibles après les durées légales de préservation. Le 1 déc. 2023, la demanderesse a déclaré que seules des adresses IP et des noms lui avaient été fournis, et jugeait ces éléments insuffisants — divergence apparente avec la description du tableau par le juge, dont les valeurs restent scellées. | Ordonnances du tribunal établissant une production effective à la Cour, puis aux avocats des demandeurs sous restrictions de confidentialité; elles disent que la divulgation à la police/aux autorités était permise, non qu’elle a effectivement eu lieu. La production concerne une affaire civile de droit d’auteur, pas une remise policière démontrée. Les valeurs réelles et les identités sont sous scellés. [Ordonnance Delhi HC, 24 nov. 2022](https://indiankanoon.org/doc/119238688/), [suivi, 1 déc. 2023](https://indiankanoon.org/doc/2402568/), [ordre de divulgation, 30 août 2022](https://dhccaseinfo.nic.in/jupload/dhc/PMS/judgement/31-08-2022/PMS30082022SC2822020_121640.pdf). |
| **Discord — données fournisseur et messages, affaire pénale US, 2020** | Dans U.S. v. Bryant, l’opinion rapporte que Discord a répondu à un mandat visant l’IP, device ID, username, email, messages/images, données VoIP transitoires et autres contenus; les enquêteurs ont trouvé dans le retour les images de permis de conduire déposées sur le compte et des chats/messages, dont des éléments les reliant à l’accusé. | Opinion judiciaire publique décrivant retour effectif de mandat Discord; le contenu exact a été utilisé comme élément probable cause. | Une affaire ciblée ne quantifie pas la conservation universelle ni le retour sous d’autres lois. [U.S. v Bryant, décision](https://app.midpage.ai/document/united-states-v-bryant-1000161304572).
| **Wire — compte utilisateur, enquête Tsunami Democràtic, 2024** | Wire a remis l’adresse e-mail utilisée à l’inscription du compte, via une demande des autorités suisses liée à une enquête espagnole; cette adresse a permis aux enquêteurs de solliciter Proton, puis Apple. Wire a confirmé à TechCrunch avoir reçu la demande et remis des informations de compte de base; l’entreprise dit ne pas pouvoir produire le contenu transmis dans son service. | L’article cite des documents judiciaires obtenus par TechCrunch et la confirmation directe d’un porte-parole Wire. Les pièces de retour intégrales et l’éventuel inventaire complet des champs ne sont pas publiés dans la source consultée. [TechCrunch, 8 mai 2024](https://techcrunch.com/2024/05/08/encrypted-services-apple-proton-and-wire-helped-spanish-police-identify-activist/). | Preuve concrète qu’un compte Wire peut relier un pseudonyme à un e-mail fourni à l’inscription; ne démontre ni remise du contenu Wire, ni une capacité générale à identifier tout compte. Le rapport de transparence Wire est agrégé et ne donne pas les champs de ces demandes. [Rapport Wire, 2014–2020](https://wire-docs.wire.com/download/Wire%2BTransparency%2BReport.pdf).
| **Matrix.org — procédure publiée, aucun cas de remise individuel établi ici** | La Fondation indique demander une procédure valide avant divulgation, traiter les urgences de danger imminent, accepter les requêtes non britanniques via entraide judiciaire, notifier normalement les personnes concernées, et conserver les données 90 jours sur une demande de préservation valide. Le homeserver ne peut pas lire les données E2EE selon sa documentation. | Il s’agit d’une politique fournisseur, non d’une preuve qu’une divulgation a effectivement eu lieu. Les règles sont formulées de façon légèrement divergente : § « demandes » demande subpoena, warrant ou court order, tandis que « What Information Do We Have? » parle de valid search warrant. Le rapport annuel 2025 mentionne des réponses aux demandes et à l’abus réseau mais ne chiffre pas les requêtes légales ni les données remises. [Guidelines](https://matrix.org/legal/law-enforcement-guidelines/), [rapport annuel 2025](https://matrix.org/foundation/reports/2025%20Public%20Annual%20Report.pdf). | Cela concerne Matrix.org uniquement; chaque homeserver, hébergeur, bridge et fournisseur Element peut relever d’une autre politique et juridiction. L’absence de cas public repéré n’établit pas l’absence de demandes ou de remises. |
| **WhatsApp — capacités légales publiées** | Le guide officiel indique les données de base qui peuvent être remises (nom, date de début, dernière activité, IP, email si disponibles), certaines données de compte avec ordonnance, et avec mandat des informations telles que profil, groupes et carnet d’adresses si disponibles. Un guide WhatsApp distingue contenu remis et les messages déjà livrés/non conservés; une demande de collecte future ciblée peut permettre des logs expéditeur/destinataire, horodatage, IP et type de message/appel. | Documentation officielle des catégories de réponses et des processus; ce n’est pas, à elle seule, la preuve d’une remise dans un dossier précis. [Guide forces de l’ordre WhatsApp](https://faq.whatsapp.com/444002211197967/?category=5245250&locale=fr_FR), [requêtes gouvernementales WhatsApp](https://faq.whatsapp.com/808280033839222/?locale=ru_RU).
| **WhatsApp — records en temps réel / judiciaire** | Un dossier fédéral public 2025 inclut des « pen register/trap and trace » obtenus sur WhatsApp et un groupe associé, démontrant que des données de signalisation/routage ont effectivement été obtenues dans une enquête. | Dossier judiciaire / records d’interception ciblée; ne prouve pas que le contenu E2EE des messages a été déchiffré ni qu’une remise historique ordinaire serait identique. [Dossier DOJ USAO-EDMI, 2:25-mj-30673](https://www.justice.gov/usao-edmi/media/1416961/dl).

### État des recherches par service — demande, capacité et remise réelle

Cette table sépare l’existence d’une politique/guide (capacité), une déclaration agrégée du fournisseur et une production réellement attestée dans un dossier. « Aucun cas public identifié » est un résultat borné de recherche, jamais la preuve d’absence de demandes ou de remises.

| Service | Ce qu’une source publique établit sur les données effectivement obtenues/remises | Qualification probatoire |
|---|---|---|
| Signal | Pour six comptes d’un dossier US de 2026 : date de création et dernière connexion; 24 comptes sans donnée responsive pour la période, sept numéros sans compte. | Remise fournisseur attestée par la réponse Signal; aucun contenu. [Dossier DC 2026](https://signal.org/bigbrother/district-of-columbia/) |
| SimpleX | Rapport de transparence 2025 : 12 demandes reçues; le fournisseur déclare n’avoir fourni aucune donnée responsive. | Déclaration primaire annuelle du fournisseur, non une vérification indépendante des données d’opérateurs de relais/tiers. [Rapport](https://simplex.chat/transparency/) |
| Olvid | Aucun dossier public de remise fournisseur avec champs identifiés n’a été établi dans cette recherche. La politique décrit la réponse aux demandes légales, pas un cas de production. | UNKNOWN pour les champs réellement remis; ne pas déduire qu’aucune demande n’a eu lieu. [Politique](https://olvid.io/privacy/en/) |
| Session | Rapport STF 2025 : 17 demandes/inquiries, zéro donnée fournie; 17 entrées « no data held ». | Déclaration de la fondation qui steward le service; ne couvre pas ISP, stores, appareil, opérateurs de nœuds ni correspondant. [Rapport 2025](https://session.foundation/report-25) |
| Threema | Le rapport agrégé indique des remises concernant 1 505 IDs pour 2025 et 2 026 IDs au premier semestre 2026, sous forme déclarée de dates de création/dernière connexion et, selon opt-in, de hash téléphone/e-mail ou push token. | Données fournisseur effectivement remises en agrégat; aucun retour individuel ouvert dans le corpus. [Transparence](https://threema.com/en/transparency-report) |
| Cwtch | Aucun guide de police, rapport de transparence ou cas public de remise par Open Privacy / opérateur de groupe identifié. | UNKNOWN; les opérateurs de groupes, hébergeurs, stores et terminaux sont des entités distinctes. |
| Briar | Aucun guide/rapport de transparence ou cas public avec champs réellement remis par Briar identifié. | UNKNOWN; cela ne couvre pas une saisie d’appareil, d’un contact ou d’un Briar Mailbox. [Politique](https://briarproject.org/privacy-policy/) |
| Jami | Aucun rapport ou cas public établissant une donnée effectivement remise par Savoir-faire Linux retrouvé. | UNKNOWN; DHT, proxy/TURN, annuaire, FCM/APNs, FAI et terminaux peuvent détenir des données différentes. |
| Tox / qTox | Aucune affaire publique attribuant à toxcore/qTox une production de données fournisseur trouvée. Les cas éventuels visant un utilisateur ou son FAI ne sont pas équivalents à une remise du projet. | UNKNOWN, sans opérateur de messagerie unique et sans rapport public de demande trouvé. |
| Matrix / Element | Matrix.org publie une procédure (warrant/MLAT, urgences, préservation 90 jours); aucun retour individualisé avec champs réellement divulgués par matrix.org n’a été établi ici. | Politique fournisseur seulement. Ne s’applique pas automatiquement à un homeserver tiers. [Guide](https://matrix.org/legal/law-enforcement-guidelines/) |
| XMPP / OMEMO | Pas de fournisseur unique; aucun cas attribuable à un serveur XMPP nommé et à une remise de champs par cet opérateur n’a été établi dans cette passe. | UNKNOWN, dépend du domaine/hébergeur choisi et des extensions (MAM, logs, push). |
| Telegram | Delhi HC a examiné une production en procédure civile de droit d’auteur sous pli scellé; le juge décrit un tableau comprenant noms d’administrateurs, numéros et IP pour certains canaux. La demanderesse a ensuite dit avoir reçu noms et IP seulement. | Production au tribunal/demandeurs établie; valeurs scellées, discordance non résolue et transfert à la police non prouvé. [Ordonnance 2022](https://indiankanoon.org/doc/119238688/), [suivi 2023](https://indiankanoon.org/doc/2402568/) |
| WhatsApp | Des records ciblés de signalisation/PRTT relatifs à un compte et groupe sont cités dans un dossier DOJ 2025; le guide officiel décrit aussi les catégories susceptibles d’être remises. | Données de relation/routage effectivement exploitées dans une affaire; retour brut non annexé, contenu E2EE non prouvé comme remis par WhatsApp. [Dossier DOJ](https://www.justice.gov/usao-edmi/media/1416961/dl), [guide](https://faq.whatsapp.com/444002211197967/?category=5245250&locale=fr_FR) |
| Discord | Dossier DOJ 2026 décrit une communication volontaire de données de compte/DM à la police canadienne puis un retour de messages privés et métadonnées sous mandat FBI; une décision antérieure U.S. v. Bryant décrit aussi des records/messages issus d’un mandat Discord. | Remise de contenu texte et de données de compte établie dans des cas précis, pas une mesure universelle de rétention. [DOJ 2026](https://www.justice.gov/usao-wdwa/media/1464546/dl), [U.S. v. Bryant](https://app.midpage.ai/document/united-states-v-bryant-1000161304572) |
| Wire | Dans l’enquête espagnole de 2024, Wire a confirmé avoir remis l’adresse e-mail d’inscription d’un compte via procédure suisse. | Remise d’un identifiant de compte établie; aucune remise du contenu Wire dans ce dossier n’est établie. [Dossier presse et documents cités](https://techcrunch.com/2024/05/08/encrypted-services-apple-proton-and-wire-helped-spanish-police-identify-activist/) |
| Delta Chat | Aucun cas public de donnée réellement remise par les développeurs Delta Chat identifié; les relais mail/chatmail sont des opérateurs séparés. | UNKNOWN pour développeurs et opérateurs; ne pas appliquer une seule politique à tous les serveurs. |
| Ricochet Refresh | Aucun transfert d’un fournisseur de chat central n’a été établi pour Refresh. Le dossier historique Boystown concerne Ricochet original et collecte côté réseau/télécom, pas une remise de contenu par Blueprint. | Preuve historique bornée à un autre client/version et à un autre détenteur de données; aucun cas actuel Refresh identifié. |
| Status / Waku | Aucun cas de remise par Status ou un opérateur Waku géré identifié dans cette recherche. | UNKNOWN; logs IP/topic annoncés, app stores, Apple/APNs et opérateurs de nœuds constituent des sources séparées. |

**Constat de méthode :** les subpoenas/mandats/ordonnances publiés, les guides de forces de l’ordre, les rapports agrégés et les exports réellement consultés ne sont pas interchangeables. Un affidavit qui cite un message ne prouve pas que le service l’a remis : l’origine peut être un téléphone, un participant coopérant, une sauvegarde, une interception prospective ou un export fournisseur. Les cas Discord ci-dessus prouvent des remises de DM texte, mais ne permettent pas de généraliser à d’autres produits.

### Cadre européen applicable à la date du rapport

Depuis le **18 août 2026**, le règlement (UE) 2023/1543 sur les European Production Orders et Preservation Orders est applicable. Il permet, dans des conditions et catégories de données définies, qu’une autorité judiciaire d’un État membre adresse directement un ordre/certificat à l’établissement désigné ou au représentant légal d’un fournisseur offrant ses services dans l’Union; la Commission décrit un délai ordinaire de 10 jours et un délai d’urgence de 8 heures. La directive (UE) 2023/1544, applicable depuis le 18 février 2026, organise la désignation d’établissements/représentants dans l’UE. Ce mécanisme accélère l’accès aux données **existantes ou contrôlées par le fournisseur**; il ne crée pas des messages que celui-ci ne possède pas, ne lui donne pas magiquement les clés E2EE et ne remplace pas les conditions de légalité, de proportionnalité, de recours et de notification prévues par les textes. Il faut distinguer ce dispositif des MLAT/entraides, demandes nationales, procédures d’interception et pouvoirs visant l’appareil, l’ISP, Apple/Google ou le correspondant. Sources primaires : [Règlement 2023/1543](https://eur-lex.europa.eu/eli/reg/2023/1543/oj/eng/pdf), [directive 2023/1544](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023L1544), [Commission européenne — calendrier et délais](https://commission.europa.eu/law/cross-border-cases/judicial-cooperation/types-judicial-cooperation/e-evidence-cross-border-access-electronic-evidence_en).

Cette évolution est pertinente pour les fournisseurs et représentants concernés dans l’UE, mais ne permet pas de déduire qu’un dossier donné a fait l’objet d’un ordre e-Evidence, ni qu’une donnée a effectivement été remise. Les reports de transposition, la désignation du représentant, la catégorie des données et les recours doivent être vérifiés au cas concret; ce rapport n’est pas un avis juridique.

### Portée des inconnues légales

- Pour SimpleX, Olvid, Session, Cwtch, Briar, Jami, Tox/qTox, XMPP/OMEMO, Delta Chat, Ricochet Refresh et Molly, je n’ai pas encore établi dans cette étape un cas public suffisamment documenté qui identifie exactement une remise du fournisseur et les champs retournés. **Cela ne signifie ni “aucune demande” ni “aucune donnée remise”**. Wire a un exemple de remise d’e-mail d’inscription confirmé par l’entreprise; Telegram a un dossier civil indien où une production sous pli scellé a été constatée par la Cour, mais pas de preuve consultée de transmission à la police. Matrix.org publie sa procédure, sans cas individuel de remise établi ici. Pour chaque produit, séparer politique/guide, transparence agrégée, production judiciaire et remise policière effectivement prouvée.
- Les données reçues d’un correspondant, d’un téléphone déverrouillé, d’une sauvegarde cloud, d’un push provider, d’un FCM/APNs token, d’un compte OS, d’un opérateur téléphonique ou d’une victime coopérante sont des vecteurs distincts du déchiffrement côté serveur du messager.
- Pour les services dont les rapports de transparence ne publient que des totaux, les totaux documentent un volume de demandes et de remises sans démontrer les champs particuliers remis dans chaque cas. Pour les fournisseurs américains ou suisses, le seuil de procédure juridique cité par le fournisseur est une description de sa politique et du droit applicable au contexte considéré, pas un avis juridique universel.

## Forensics publics — résultats bornés par plateforme, OS, version et date

| Outil / OS / app / date | Résultat observé ou affirmé | Limites de transfert au présent |
|---|---|---|
| **Cellebrite Physical Analyzer + Advanced Services / Android / Signal / 10 déc. 2020** | Le billet de Cellebrite décrit le déchiffrement de `signal.db` via une clé récupérée depuis Shared Preferences et Android Keystore, puis les tables `sms`/`part` et les pièces jointes sous `app_parts`. Il précise que les pièces jointes utilisent une clé distincte. | Annonce éditeur, pas article évalué par les pairs; aucun modèle d’appareil, version Android, version Signal, version Physical Analyzer ou état de verrouillage n’est donné dans le texte. Ne démontre pas que la méthode fonctionne sur Signal/Android courant ou sur appareil verrouillé. [Cellebrite](https://www.cellebrite.com/en/blog/cellebrites-new-solution-for-decrypting-the-signal-app/).
| **DC3 / Windows, macOS, Linux, iOS, Android / Signal / 26 mai 2021** | Le Technical Advisory 2021-005 documente clés et bases : clé desktop dans `config.json`; iOS keychain + `signal.sqlite`, fichiers Attachments et Snapshots; Android `signal.db`, Android Keystore et `app_parts`. L’avis qualifie desktop de straightforward et mobile de plus difficile quand les clés sont matériellement protégées. | Advisory d’investigation, sans matrice de versions d’app/OS ou de produits forensic; les chemins et conclusions sont des observations publiées à la date du conseil, pas une garantie de décryptage universel. [DoD DC3 TA-2021-005](https://content.govdelivery.com/accounts/USDODDC3/bulletins/2e03518).
| **FBI / iPhone (modèle et iOS inconnus) / Signal / preuve rapportée en avril 2026** | Messages entrants récupérés dans la base/stockage de notifications iOS, y compris app supprimée et messages temporaires expirés dans Signal; l’extraction était via stockage du système, sans casser Signal Protocol. | L’article rapporte témoignages/notes; version iOS, modèle, version Signal, état BFU/AFU et outil exact non publiés. Apple a corrigé le défaut CVE-2026-28950 en iOS 26.4.2 / iPadOS 26.4.2; un test après patch sur terminaux similaires est requis avant toute affirmation de persistance. [404 Media](https://www.404media.co/fbi-extracts-suspects-deleted-signal-messages-saved-in-iphone-notification-database/), [Apple](https://support.apple.com/en-us/127002).
| **Études universitaires sur WhatsApp, Signal, Threema / Android / années antérieures** | Il existe des travaux qui récupèrent bases, clés, pièces jointes et artefacts pour versions testées; une étude 2022 examine spécifiquement Signal, Wickr, Threema, et des travaux plus anciens WhatsApp. | Les années, builds d’app, appareils et techniques délimitent strictement la conclusion; aucune capacité Cellebrite/GrayKey/Magnet actuelle ne peut être inférée sans matrice explicitement publiée et reproduction. Ces sources sont à relever audit par audit, pas résumer comme « forensic bypass » permanent. [étude FSI: Digital Investigation 2022](https://doi.org/10.1016/j.fsidi.2022.301347), [étude WhatsApp Android sur arXiv](https://arxiv.org/abs/1507.07739).
| **Projet étudiant KISIA / Android / Session / présenté le 2 déc. 2023, résumé publié en 2024** | Le programme CISC-W’23 identifie un travail de l’équipe FaS de Kookmin sur le déchiffrement des fichiers temporaires Session; le résumé de projet KISIA dit qu’il a exploité Android Keystore pour les clés de base et de fichiers temporaires, puis déchiffré DB et fichiers. | Sources institutionnelles de présentation/projet, pas rapport d’extraction commerciale ni article complet évalué par les pairs. | Dans les éléments indexés accessibles, le modèle, patch Android, version Session, outil d’acquisition, état verrouillé et procédure détaillée ne sont pas établis; le PDF KISIA lié a renvoyé une page d’erreur lors de cette passe. Résultat à conserver comme piste datée, pas preuve actuelle générique. [Programme CISC-W’23](https://kiisc.or.kr/bbs/downloadBoardImage?uploadedFileId=8986), [résumé KISIA](https://www.kisia.or.kr/bucket/uploads/2024/01/25/%5Bkisia%5D%202023%20%EB%8C%80%ED%95%99%EC%A0%95%EB%B3%B4%EB%B3%B4%ED%98%B8%EB%8F%99%EC%95%84%EB%A6%AC%20%EC%84%B1%EA%B3%BC%EC%9E%90%EB%A3%8C%EC%A7%91.pdf).
| **Jaeckel et al. / Cellebrite UFED Touch / iOS non précisé / Telegram iOS 11.1.1 / publié le 24 mars 2025** | Sur des iPhone SE et iPhone 7, les auteurs ont généré des échanges de test (cloud chat, Secret Chat, groupes, canaux, textes, médias et appels), puis réalisé une extraction du système de fichiers avec « UFED Touch » et analysé le dossier `telegram-data`. Ils décodent contacts, identifiants, groupes/canaux/Secret Chats, textes, auteur, direction, horodatages, références média et événements d’appel depuis `db_sqlite`/BLOB; la base peut avoir un `db_sqlite-wal` avec des transactions absentes/anciennes. Le papier dit que les données examinées n’étaient pas chiffrées au niveau de la base/app. [Article complet DFRWS/FSI](https://dfrws.org/wp-content/uploads/2025/03/Forensic-analysis-of-Telegram-Messeng_2025_Forensic-Science-International-D.pdf). | Résultat d’extraction post-acquisition et de décodage, pas preuve d’un déverrouillage/bypass : version iOS, version exacte UFED, état verrouillé du téléphone et protection Data Protection des fichiers ne sont pas publiés. Données synthétiques; les auteurs disent que la récupération de données supprimées et davantage de tables restent à étudier. Ils préviennent aussi que le schéma varie avec les releases; le résultat de 2025 ne démontre pas l’extractabilité de Telegram/iOS actuel. |
| **ALEAPP (parser indépendant) / Android / SimpleX / 20 août 2026** | Le parser public sait extraire contacts, messages, fichiers, états edited/deleted et anciennes versions éditées depuis `files_chat.db` chiffrée, si l’acquisition contient aussi la clé/passphrase. Les auteurs déclarent deux échantillons Android privés; SQLCipher page-HMAC est vérifié sur le jeu testé. Pour médias, le parser note une clé 32 octets et nonce 24 octets, mais dit explicitement que le format de déchiffrement n’est pas établi dans l’analyse. | Le code du parser est une source technique indépendante, plus probante qu’un slogan ou qu’une simple capacité annoncée par un fournisseur forensic. | Échantillon de deux appareils seulement, pas de matrice précise d’OS/version d’app dans le commentaire public; nécessite extraction/secret, ne démontre pas de déverrouillage à distance ni une extraction Cellebrite/GrayKey. Anciennes versions du parser et app à comparer. [ALEAPP, parser SimpleX](https://github.com/abrignoni/ALEAPP/blob/main/scripts/artifacts/simplexChat.py).
| **Étude académique / Android / Session / 2025** | Kim et al., JKIISC 35(5), pp. 1209–1227, DOI 10.13089/JKIISC.2025.35.5.1209; le catalogue de la National Assembly Library date l’article du 31 oct. 2025. L’abstract indique une analyse de bases, logs et fichiers temporaires et une méthode de déchiffrement par extraction dynamique de clé via Frida sur appareil réel. | Article de revue; le résumé établit la catégorie de technique étudiée et l’existence de recherche forensic ciblant Session. | Le texte intégral n’a pas été accessible dans cette étape; l’abstract ne donne pas build, appareil, Android, état de verrouillage, version Frida, résultats détaillés ou outil commercial. Ne pas convertir en affirmation générale sur Session actuel. [Notice KCI](https://www.kci.go.kr/kciportal/landing/article.kci?arti_id=ART003256904), [catalogue bibliographique](https://dl.nanet.go.kr/detail/KINX2025208347).
| **ALEAPP / Android 14 et 15 / Session / parser créé le 7 août 2026** | La source du parser déclare quatre images de test : Android 14 avec codes d’app 372/376 et Android 15 avec codes 417/419. Elle lit dans `network.loki.messenger_preferences.xml` l’Account ID, profil, timestamps et clés de base/pièces jointes/logs sous forme de secrets enveloppés; elle liste les fichiers `app_parts` mais ne décode pas leur contenu. | L’auteur marque explicitement la frontière : il ne parse pas le contenu des messages. `signal_v4.db` et `session.db` sont SQLCipher; la méthode publiée d’extraction par offset de blob est notée applicable à un appareil virtualisé sans Keystore matériel. | Le commentaire de code dit que les essais de déchiffrement n’ont pas abouti sur les Keystores matériels des images; Session documente actuellement une clé DB scellée par Android Keystore. Ce sont du code et des notes de parser tiers, pas acquisition Cellebrite/GrayKey ni validation par article évalué. [ALEAPP parser](https://github.com/abrignoni/ALEAPP/blob/main/scripts/artifacts/sessionMessenger.py), [architecture Android Session](https://github.com/session-foundation/session-android/blob/dev/ARCHITECTURE.md). | Des artefacts de compte/fichiers et des passphrases enveloppées peuvent être récupérables après acquisition de fichiers sans que la DB soit lisible; « Frida sur appareil réel » ne suffit pas à conclure qu’un appareil stock verrouillé ou un Keystore matériel est contourné. | Modèles et patchs Android des images, état de déverrouillage, sources des échantillons, correspondance versionCode→release et possibilité de reproduire le déchiffrement sous conditions verrouillées. |

## Audits SimpleX — écarts de périmètre et état 2026

Les deux rapports Trail of Bits 2022 et 2024 ont été lus directement en PDF, avec extraction des cibles, calendriers, méthodes, exclusions, findings et éléments de correction. Le rapport 2022 comprend une revue des corrections par Trail of Bits; le PDF 2024 est un rapport résumé de design et ne contient pas de fix log. Les annonces de SimpleX sont séparées ci-dessous des constats du cabinet. Les résultats restent limités aux versions et périmètres indiqués.

| Audit | Date / durée / version | Périmètre / exclusions | Findings / sévérité / remédiation | Reste incertain |
|---|---|---|---|---|
| Trail of Bits — *SimpleX Chat Security Assessment*, implémentation, 2022–2023 | Rapport final avec fix review daté **2 févr. 2023**. Équipe de 2 consultants; engagement **11–14 oct. 2022**, 1 person-week; draft/readout 18 oct., rapport initial 3 nov.; revue des corrections le **13 janv. 2023**. Cibles fixées dans le PDF : `simplexmq` commit `413aad5139acee28033404aed2e5516fc71c337c`; `simplex-chat` commit `07d2c9ff49034520effdf247f022c03b5a890150`. | Revue manuelle et tests du code/documentation fournis, accès complet; priorité au client/serveur SimpleXMQ (`Server`, `Client`, `Agent`) et à `Crypto`/`Ratchet`; conformité X3DH/Double Ratchet et traitement des secrets. Exclusions/limites : notifications SimpleXMQ non examinées; reste du Haskell au mieux; dépôt app `simplex-chat` non priorisé car le rapport estimait qu’il déléguait crypto/réseau à la bibliothèque. Recommandations finales : tests unitaires/propriétés plus larges, renforcer/tester `cryptonite`, auditer le reste de SimpleXMQ et les apps mobiles. | Findings ToB : `TOB-SMP-1` X3DH sans HKDF sur concaténation DH (**Medium**; HKDF recommandée); `-2` conversion `fromIntegral`/longueur incorrecte >65 535 octets (**Low**; borner longueur + tests); `-3` `unPad` lève une exception sur entrée 0/1 octet (**Low**; valider taille + tests); `-4` secrets en mémoire Haskell non épinglée/non effacée, avec risque de swap (**Medium**; `mlock` si disponible, effacement mémoire, documenter modèle). Fix review ToB : **1, 2, 3 résolus** (PRs 548/547); **4 non résolu**, risque alors accepté par SimpleX. L’annonce fournisseur confirme que les trois corrections sont dans v4.2 et qualifie l’attaque mémoire de privilégiée; c’est une déclaration du fournisseur, tandis que le statut ci-dessus vient du retest ToB. [Annonce SimpleX](https://simplex.chat/blog/20221108-simplex-chat-v4.2-security-audit-new-website.html), [PDF ToB complet, fix review inclus](https://github.com/trailofbits/publications/blob/master/reviews/SimpleXChat.pdf), [PR 548](https://github.com/simplex-chat/simplex-chat/pull/548), [PR 547](https://github.com/simplex-chat/simplex-chat/pull/547). | Le rapport ne donne pas un SHA du binaire v4.2; les commits de cible sont ceux audités avant corrections. Le retest vérifie les PR, pas chaque distribution mobile/desktop. Le finding mémoire non résolu en 2023 n’établit pas son état dans les versions 2026. |
| Trail of Bits — *SimpleX Chat Design Review*, conception cryptographique, 2024 | Rapport résumé daté **12 août 2024**. Trois consultants; engagement **24–28 juin 2024**, 1 engineer-week; draft/readout 28 juin. L’annonce fournisseur appelle la revue « juillet 2024 » et « over a week » : écart de calendrier/durée entre l’annonce et le PDF, sans explication publiée. Cibles : design `simplexmq/protocol` commit `d47c099ac94eda3342d02da2da76ef5cab5793ac` et design `simplex-chat` commit `fba0478e509cf56851cef44dc0543a0531bec32b`. | Revue manuelle des documents de protocole avec accès complet; formal verification d’une version simplifiée de l’accord de queue SMP. Périmètre documentaire : SMP, SMP Agent, push, XFTP, XRCP, chat protocol; moins de temps consacré à Agent, push et groupe. Ce n’est pas une revue d’implémentation générale. Le PDF ne publie pas de standard méthodologique ni de fix log. | **7 findings dans le PDF** : `TOB-SIMPLX-1` descriptions informelles (**Info**; notation algébrique/diagrammes); `-2` side-channel GET et présence de message corrélable (**Low**; échanges égalisés, latence aléatoire envisagée); `-3` transport compromis rend la corrélation plus efficace (**Medium**; corriger le threat model, chiffrer identifiants/transport); `-4` SHA-256 employé comme KDF XRCP (**Info**; HKDF recommandée); `-5` pas de FS/BR pendant une session XRCP (**Info**; ratchets/primitif SMP ou documenter); `-7` compromission/modification locale peut cacher un MITM ou détourner les queues (**Medium**; préciser capacités et configurations adverses); `-8` latence contrôlée permet corrélation temporelle (**Medium**; documenter et envisager délais aléatoires). SimpleX dit que **3 findings sont améliorés dans v6.1** : couche interne de chiffrement SMP pour cacher les identifiants même si TLS est compromis, SHA-256 remplacé par SHA3-256 dans XRCP et ratchets de chaîne XRCP; menace/formulation et incohérences documentaires également mises à jour. Les attaques GET/latence restent des risques reconnus; latence aléatoire est une mesure future envisagée. La menace de modification complète de l’appareil est acceptée comme sans défense viable. [PDF Trail of Bits](https://github.com/simplex-chat/simplex-chat/blob/stable/docs/SimpleX_Design_Review_2024_Summary_Report_12_08_2024.pdf), [annonce et réponse fournisseur](https://simplex.chat/blog/20241014-simplex-network-v6-1-security-review-better-calls-user-experience.html). | Le PDF est un résumé (21 pages) et n’établit pas de retest indépendant après v6.1; les « 3 améliorés » et corrections de docs viennent du fournisseur. Les commits de design ne sont pas un mapping des releases/binaries déployés; état actuel des protections et de la latence aléatoire à tester. |
| Trail of Bits — implementation assessment, 2026 | En août 2026 l’éditeur écrit que ToB a audité en 2026 et que le rapport doit être publié avant fin 2026; politique sécurité mise à jour au 25 mai 2026 disait audit « scheduled for June 2026 ». | Le dépôt SEC de SimpleX dit globalement « protocol and application code »; aucun périmètre granulé, version, durée, exclusion, commit ou rapport final public vu au 13 oct. 2026. | **UNKNOWN** : findings, niveaux, corrections et retest non publics/consultés. [Post d’août 2026](https://simplex.chat/blog/20260819-simplex-chat-crowdfunding.html), [SEC Form C PDF](https://www.sec.gov/Archives/edgar/data/2140143/000214014326000002/simplexchatformcoriginal3.pdf), [SECURITY.md](https://github.com/simplex-chat/simplex-chat/security). | Retest indépendant et version corrigée après rapport public : inconnus jusqu’à publication/examen du rapport. |

**Correction de l’état d’audit** : les résultats publics vérifiables comprennent l’implémentation 2022 avec retest 2023 et la revue de design 2024; ils couvrent des snapshots/périmètres distincts. SimpleX annonçait en 2024 une assessment d’implémentation au début 2025; la communication d’août 2026 dit qu’une assessment ToB a finalement eu lieu en 2026 et que son rapport devait sortir avant la fin de l’année. Au **13 octobre 2026**, le rapport 2026 et ses findings n’étaient pas disponibles dans les éléments consultés : **UNKNOWN**, sans créditer par avance un audit seulement annoncé. [Annonce août 2026](https://simplex.chat/blog/20260819-simplex-chat-crowdfunding.html), [SEC Form C](https://www.sec.gov/Archives/edgar/data/2140143/000214014326000002/simplexchatformcoriginal3.pdf), [SECURITY.md](https://github.com/simplex-chat/simplex-chat/security).

## Censure — ce que les mesures publiques permettent réellement d’affirmer

- **Signal** : OONI rapporte mesures du produit de 2021 suggérant le blocage en Iran, Chine et Ouzbékistan pendant la période avril–septembre 2021, et un blocage temporaire de quelques jours à Cuba en juillet 2021. Les mécanismes observés étaient différents : interférence DNS, injection DNS et échecs TLS compatibles avec DPI. OONI décrit aussi à cette date domain-fronting/censorship-circumvention et proxies TLS Android; les réglages/protocoles actuels doivent être revalidés. C’est un cas documenté de contournement et de blocage, pas la preuve que cela marche encore en 2026 sur chaque réseau. [Analyse OONI](https://ooni.org/post/2021-how-signal-private-messenger-blocked-around-the-world/).
- **Briar** : le fournisseur décrit Tor comme transport Internet et Bluetooth/Wi-Fi/carte mémoire quand Internet est coupé; son threat model admet un adversaire qui bloque ou manipule les canaux longue portée et une capacité limitée de surveiller/bloquer le court rayon. C’est une propriété d’architecture et un modèle produit, pas une garantie de disponibilité universelle. App stores, téléchargement initial, Tor/bridges, densité de contacts proches, matériel radio et répression physique restent des dépendances. [How it works / modèle de menace Briar](https://briarproject.org/how-it-works/).
- **Limite de couverture de mesure** : OONI indique que seules Signal, WhatsApp, Telegram et Facebook Messenger ont actuellement des expériences OONI Probe dédiées parmi les messageries; les autres apps peuvent être sondées par domaine/serveur, mais l’absence d’expérience dédiée ou de mesure publiée n’est pas une preuve d’accessibilité. [Méthodologie OONI Explorer](https://ooni.org/post/2025-ooni-explorer-thematic-censorship-pages/).
- **À ne pas conclure** : aucun résultat public exact consulté ici ne démontre en octobre 2026 qu’une messagerie de la liste est bloquée ou accessible dans tous les AS d’un pays. Les cartes OONI changent dans le temps et couvrent seulement des réseaux/probes observés; les pays, opérateurs, versions, mécanismes anti-censure et périodes doivent être explicitement indiqués avant de noter TM15.

**Conclusion forensic bornée** : E2EE limite la remise du fournisseur; le terminal déverrouillé, snapshots, pièces jointes, base locale, OS notification store, sauvegarde et appareil du correspondant restent des surfaces indépendantes. Les cas publics datés prouvent l’existence d’extractions dans des environnements précis, mais pas leur succès sur toute version actuelle.

## Éléments probatoires à préserver dans la matrice globale

1. **Status/Waku** : ne pas écrire « les nœuds ne voient pas l’IP ou le graphe topic »; page d’infrastructure Status admet IP + topics et rétention de 15 jours pour certains services gérés. Distinguer données de transport/topic du contenu chiffré.
2. **Signal forensic** : ajouter preuve de récupération d’aperçus Signal iOS depuis le système dans un dossier pénal 2026, puis le correctif CVE-2026-28950. Cette preuve est locale et historique; version/capture exacte manquante.
3. **Signal remise fournisseur** : le cas D.C. 2026 ne se réduit pas à « Signal n’a rien remis » : Signal rapporte la remise des dates de création et dernière connexion pour six comptes; 24 autres sans données pour la période, 7 comptes absents.
4. **SimpleX requests** : le rapport publié dit 12 demandes policières en 2025 et aucune donnée responsive trouvée/remise. C’est la déclaration du fournisseur, pas une preuve que des données n’existent chez aucun relai, ISP ou endpoint.
5. **SimpleX audits** : les PDF ToB d’implémentation 2022 (avec fix review 2023) et de design 2024 ont été lus; le premier laisse le finding mémoire non résolu, le second couvre les designs et non l’implémentation générale. Une assessment ToB 2026 est déclarée réalisée, mais son rapport reste **UNKNOWN** au 13 octobre et n’apporte pas encore de preuve consultable.
6. **Threema légal** : le rapport 2025/2026 montre des remises effectives agrégées d’informations par ID (pas de contenus selon les catégories listées). L’acte d’accusation U.S. v. Wedding contient du contenu Threema, mais le canal de preuve paraît participant/co-conspirateur et ne doit pas être appelé « remise de Threema » sans dossier complémentaire.
7. **WhatsApp et Discord** : ne pas traiter E2EE/absence de serveur-content après livraison comme absence de données remises. WhatsApp documente des catégories d’account/contact/group records et collecte ciblée future; un dossier Discord documente un retour effectif de contenus et IP à la suite d’un mandat.
8. **Olvid — anonymat et routage** : le papier formel 2026, lu en entier, établit que dans le protocole modélisé le serveur voit les clés publiques des destinataires, la taille et le timing; il rapporte que l’équipe Olvid emploie « anonymat » dans un sens non technique et reconnaît l’identification par clés publiques. Ce point doit apparaître dans toute matrice de métadonnées, sans en déduire que le serveur connaît nécessairement le nom civil de tout utilisateur.

## Contradictions et distinctions de périmètre à conserver dans les matrices

1. **Session appels** : l’ancienne matrice laissait plusieurs comportements d’appel comme inconnus. La FAQ fournisseur actuelle dit que les appels beta sont P2P et partagent l’IP avec le pair et un serveur STUN/TURN STF; les appels onion ne sont pas la fonction actuelle annoncée dans cette FAQ.
2. **SimpleX appels** : au contraire, le réglage par défaut actuel documenté est TURN relay; l’utilisateur peut le désactiver et autoriser P2P, exposant alors son IP au pair. Le relais voit au minimum la durée.
3. **Olvid** : spécification 2024 documente TURN-only et cache les IP entre pairs; elle ne cache pas les IP des participants au TURN. Ce point est plus établi que la formulation générale « appels TURN » du rapport précédent.
4. **Element** : « Matrix/Element » ne peut pas recevoir une note unique d’IP d’appel : Element Call/SFU actuel, appels plus anciens, client utilisé et infra auto-hébergée sont des configurations distinctes. La politique Element confirme la collecte d’IP/ID/timestamps pour Element Call.
5. **Delta Chat** : la politique et l’architecture d’appel montrent une possibilité de P2P (IP au pair) mais aussi relais et fallback; ce n’est pas à classer comme « IP masquée » par défaut sans examiner les candidats ICE.

## Expériences sûres qui apporteront une preuve supérieure

Sur comptes et appareils de laboratoire contrôlés uniquement : pour chaque app/version ciblée, appeler entre deux terminaux, capturer côté client `webrtc-internals`/logs ICE et réseau local, comparer mode relay activé/désactivé, relever candidates host/srflx/relay, destination de transport et STUN/TURN, puis confirmer l’IP publique vue par l’autre terminal et par le relais. Capturer aussi les notifications à écran verrouillé séparément, sans messages sensibles. Aucune de ces expériences n’a été exécutée dans cette étape; les éléments du tableau sont documentés ou déclarés, pas `TESTED`.

## Mobile privacy / déclarations de magasins — contrôle ponctuel, 13 octobre 2026

**Méthode et portée.** Les fiches Play Data safety et App Store App Privacy consultées sont des déclarations des développeurs, non des audits de trafic ou des manifestes vérifiés. Google précise que les données consultées uniquement sur l’appareil et certaines données traitées éphémèrement peuvent ne pas être déclarées comme « collectées »; les déclarations varient selon version, usage, région et âge. Apple indique explicitement que ces renseignements développeur ne sont pas vérifiés par Apple. Les labels ne doivent donc pas être lus comme une mesure complète de ce qu’un relai, un FAI, un système push ou un appareil tiers observe. [Explication Google Play](https://support.google.com/googleplay/answer/11416267?hl=en), [fiche Signal App Store](https://apps.apple.com/us/app/signal-private-messenger/id874139669).

| Produit / source examinée | FACT — déclaration visible | Vendor claim / contradiction utile | Independent evidence / limite |
|---|---|---|---|
| Signal — Google Play, listing consulté oct. 2026 | Le label déclare « aucune donnée partagée avec des tiers » et indique que des informations personnelles peuvent être collectées; le détail visible classe aussi la transmission comme chiffrée en transit. | Le texte promotionnel du listing est plus absolu que la ligne de disclosure. | Le label est auto-déclaré; il ne décrit pas la rétention côté serveur ou la donnée observable par l’OS. Apple liste le numéro sous « contact info » et « not linked to you », tout en précisant que l’éditeur l’a déclaré et qu’Apple ne l’a pas vérifié. [Google Play](https://play.google.com/store/apps/details?hl=en-US&id=org.thoughtcrime.securesms), [App Store](https://apps.apple.com/us/app/signal-private-messenger/id874139669). |
| SimpleX — Play + App Store | Les deux labels déclarent aucune collecte et aucun partage avec des tiers (Play); la fiche Apple précise que la pratique est déclarée par l’éditeur et non vérifiée. | Cela n’annule pas le fait qu’un relai réseau voit l’IP source de sa connexion, ni le comportement d’APNs/FCM utilisé dans certains modes. | Aucun binaire/manifeste n’a été extrait; il s’agit de deux déclarations store seulement. [Play](https://play.google.com/store/apps/details?hl=en_CA&id=chat.simplex.app), [App Store](https://apps.apple.com/us/app/simplex-chat-secure-messenger/id1605771084). |
| Session — Play + App Store | Les fiches consultées déclarent aucune collecte / aucun partage de données. | Le Play listing affirme aussi que les IP ne sont jamais exposées au correspondant ou aux serveurs de stockage; la FAQ officielle dit que les appels bêta P2P exposent l’IP au pair et au STUN/TURN STF. C’est soit une différence de périmètre messages/appels, soit une déclaration de store trop générale/non actualisée; les sources ne tranchent pas l’intention. | Contradiction documentaire vérifiable, pas capture de paquet ni preuve d’une collecte analytics. [Play](https://play.google.com/store/apps/details?hl=en-CA&id=network.loki.messenger), [App Store](https://apps.apple.com/ca/app/session-private-messenger/id1470168868), [FAQ appels](https://getsession.org/faq). |
| Threema — Google Play | La fiche consultée (mise à jour déclarée 24 août 2026) dit « aucune donnée collectée » et « aucune donnée partagée ». | Le rapport de transparence indique pourtant que le serveur conserve au moins date de création et date de dernière connexion par ID, et parfois hash de téléphone/email ou token push actif récent. Cette tension peut venir de la classification store, du caractère éphémère, de l’identification du compte ou d’un label incomplet; elle ne prouve pas à elle seule une fausse déclaration. | Le contrôle indépendant nécessite inspection binaire/permissions et test réseau; non effectué ici. [Play](https://play.google.com/store/apps/details?id=ch.threema.app), [transparence](https://threema.com/en/transparency-report). |
| Wire — Google Play | La fiche déclare qu’aucune donnée n’est partagée avec des tiers; elle peut collecter nom, email, user ID, téléphone optionnel, interactions, crash logs et photos optionnels. | Le marketing insiste sur l’absence de profilage; cette formulation ne supprime pas les catégories de collecte déclarées. | Déclaration éditeur et non observation indépendante; permissions exactes et SDKs à vérifier dans les manifestes/binaire. [Play](https://play.google.com/store/apps/details/?hl=en-US&id=com.wire). |
| Delta Chat — Google Play / politique | Play déclare aucune donnée partagée mais peut collecter des informations personnelles. La politique de Delta Chat dit que les développeurs ne collectent pas/stokent les messages ou données personnelles, mais liste des services opérés pour push, fallback d’appels, mini-apps et statistiques optionnelles. | Écart de formulation ou périmètre entre label et politique; à résoudre par le détail du label et l’inspection des builds. L’existence de services auxiliaires est explicitement reconnue par l’éditeur. | Politique primaire, pas vérification réseau. [Play](https://play.google.com/store/apps/details?id=chat.delta), [privacy policy](https://delta.chat/ca/privacy). |
| Briar — Google Play | Une fiche Data safety encore indexée déclare email optionnel, localisation approximative optionnelle, interactions, crash logs/diagnostics pour analytics. La page consultée est signalée comme crawl vieille d’environ 1,3 an. | Ce label est ancien relativement à la date de cette enquête et ne peut pas être attribué à la version actuelle sans relecture d’une fiche fraîche. | Version, région et variant (Play/F-Droid) peuvent diverger; manifests non inspectés. [Fiche Data safety indexée](https://play.google.com/store/apps/datasafety?hl=en_US&id=org.briarproject.briar.android). |
| Olvid / Cwtch / autres | **UNKNOWN** dans ce relevé : aucune fiche actuelle suffisamment fiable n’a été capturée pour ces produits. | Ne pas convertir l’échec de recherche d’une fiche en absence de collecte ou de permission. | À reprendre par URLs de store exactes et inspection du manifeste par version/variant. |

### Contrôle complémentaire des fiches mobiles publiques — 14 octobre 2026

Ces fiches complètent les relevés précédents et corrigent quelques entrées devenues trop anciennes. Il s’agit des déclarations des éditeurs sur les magasins, non d’une observation de trafic. Les mentions « collecte » et « partage » de Google Play ou de l’App Store ne disent ni qu’une donnée est collectée à chaque session, ni qu’elle est visible au serveur de messagerie; elles ne remplacent pas l’inspection d’un binaire précis.

| Produit / variant réellement consulté | Déclaration publique actuelle | Contradiction / portée à ne pas dépasser |
|---|---|---|
| Signal — App Store iOS US | Le champ Phone Number est déclaré comme donnée de contact non liée à l’identité. La fiche précise que le label vient du développeur et n’est pas vérifié par Apple. [App Store](https://apps.apple.com/us/app/signal-private-messenger/id874139669) | Cela diffère du raccourci marketing « aucune collecte »; la fiche ne démontre pas à elle seule un envoi ou une rétention particulière. Le dossier légal séparé documente les champs effectivement retournés dans une affaire. |
| Olvid — Google Play US | Fiche mise à jour le 17 juin 2026 : « aucune donnée collectée » et « aucune donnée partagée »; la description dit que le numéro, l’e-mail et l’accès au carnet d’adresses ne sont pas requis. [Play](https://play.google.com/store/apps/details?hl=en_US&id=io.olvid.messenger) | Déclaration éditeur uniquement. Les clés de routage, IP et observables de taille/horodatage étudiés dans le papier indépendant ne sont pas une « collecte personnelle » telle que le magasin la catégorise. La fiche App Store iOS n’a pas été archivée dans cette passe. |
| Session — App Store iOS US | Le label consulté dit « aucune donnée collectée ». [App Store](https://apps.apple.com/us/app/session-private-messenger/id1470168868) | La fiche de magasin et le texte descriptif ne couvrent pas uniformément les appels actuels : la FAQ Session dit que les appels bêta P2P peuvent exposer l’IP au pair et au STUN/TURN de STF. Une adresse IP observable par un relais n’implique pas nécessairement une collecte durable; la rétention reste inconnue. |
| Threema — App Store iOS US, en regard de Google Play | Apple déclare Contact Info (email, téléphone), User ID lié à l’identité et crash diagnostics non liés; le Play US consulté précédemment déclare aucune donnée collectée/partagée. [Apple](https://apps.apple.com/us/app/threema-the-secure-messenger/id578665578), [Play](https://play.google.com/store/apps/details?id=ch.threema.app) | Écart matériel entre magasins; différence de plateforme, de taxonomie ou de déclaration possible. Il ne prouve pas à lui seul une fausse déclaration. Le rapport de transparence indépendant du magasin demeure une source distincte pour les données fournisseur effectivement remises en agrégat. |
| Cwtch — Google Play Android | Mise à jour indiquée le 2 septembre 2026; fiche déclare aucune donnée collectée ni partagée. [Play](https://play.google.com/store/apps/details?id=im.cwtch.flwtch) | Cwtch n’a pas de client iOS officiel documenté dans le dossier. Le label Play ne valide ni les permissions effectives du manifeste, ni les flux Tor, ni la sécurité locale. |
| Briar — Google Play Android | Listing actuel indique aucune donnée partagée avec des tiers, mais « peut collecter » des catégories de données; fiche mise à jour le 13 juillet 2026. [Play](https://play.google.com/store/apps/details?id=org.briarproject.briar.android) | Les catégories détaillées ne sont pas toutes rendues dans l’extrait consulté. Cette fiche actuelle remplace comme repère le crawl ancien cité plus haut, mais n’est toujours pas une vérification du binaire; les variants Play/F-Droid peuvent différer. |
| Jami — Google Play Android / App Store iOS | Play dit aucune donnée partagée, mais indique une collecte possible d’informations personnelles; l’App Store déclare User ID non lié à l’identité. [Play](https://play.google.com/store/apps/details?id=cx.ring), [Apple](https://apps.apple.com/us/app/jami/id1306951055) | Deux déclarations par plateforme; elles n’établissent ni les observables DHT/proxy/TURN, ni le destinataire/rétention de chaque identifiant. La page Play signale aussi le partage de localisation comme fonctionnalité. |
| Tox Messenger — Android, application tierce | L’app « Tox Messenger » de Redemptio Corp déclare aucune collecte/partage et affichait la version 1.3.0, mise à jour le 9 août 2026. [Play](https://play.google.com/store/apps/details?id=app.toxmessenger.android) | Ce produit n’est pas qTox ni une publication officielle du projet c-toxcore. Son label ne permet aucune conclusion sur les autres clients Tox; le repo, l’éditeur et la supply chain de ce client doivent être audités séparément avant de le traiter comme représentant du protocole. |
| Matrix / Element — Element X Android et iOS | Play déclare aucune donnée partagée mais peut collecter des informations personnelles, messages et quatre autres catégories; sa fiche mentionne les permissions d’installation d’APK reçus et de notification d’appel plein écran. Apple liste notamment identifiant utilisateur, identifiant appareil, localisation précise, adresse e-mail et données de diagnostic. [Play](https://play.google.com/store/apps/details?id=io.element.android.x), [Apple](https://apps.apple.com/us/app/element-x-secure-chat-call/id1631335820) | Le permission install-packages correspond à l’usage décrit d’installation d’apps reçues en pièce jointe; cela reste une permission à justifier/refuser, pas une preuve d’installation silencieuse. Les déclarations Play/Apple ne sont pas identiques et ne valident pas les flux homeserver/Push Gateway/LiveKit. |
| XMPP / OMEMO — Conversations Android | La fiche F-Droid relevée présente le build 2.20.4+free et les permissions listées par ce dépôt; aucun label Apple/Google propre au même variant n’a été vérifié. [F-Droid](https://f-droid.org/packages/eu.siacs.conversations/) | L’identité du fournisseur XMPP et le client choisi sont des variables du déploiement : le label d’un client ne peut pas représenter OMEMO ou tous les serveurs XMPP. Manifeste fusionné du build courant non extrait ici. |
| Telegram — App Store iOS US | Apple liste, parmi les catégories pouvant être liées à l’utilisateur, téléphone/nom, contacts, localisation précise, contenu utilisateur et User ID; la page dit que les informations ne sont pas vérifiées par Apple. [Apple](https://apps.apple.com/us/app/telegram-messenger/id686449807) | La fiche Android Data Safety détaillée indexée pendant cette passe date d’un crawl ancien; elle n’est pas utilisée comme photographie 2026. Le label ne distingue pas automatiquement Cloud Chats et Secret Chats. |
| WhatsApp — Google Play Android / App Store iOS | Play actuel indique aucune donnée partagée avec des tiers, mais collecte possible de localisation, informations personnelles et cinq autres catégories. Apple énumère notamment numéro, contacts, localisation, contenu, identifiants, interaction et diagnostics, certains pour analytics/publicité. [Play](https://play.google.com/store/apps/details?id=com.whatsapp), [Apple](https://apps.apple.com/us/app/whatsapp-messenger/id310633997) | Les taxonomies et déclarations divergent selon OS/région. « Aucun partage » sur Play ne signifie pas « aucune donnée côté Meta »; les catégories App Store sont auto-déclarées et ne prouvent pas que chaque champ est transmis dans toute configuration. |
| Discord — Google Play Android / App Store iOS | Play indique un partage possible d’identifiants d’appareil avec des tiers et la collecte de localisation, infos personnelles et neuf autres catégories. Apple déclare du suivi via identifiants, e-mail et identifiants appareil/utilisateur, interactions et diagnostics. [Play](https://play.google.com/store/apps/details?id=com.discord), [Apple](https://apps.apple.com/us/app/discord-talk-play-hang-out/id985746746) | Ce sont des disclosures store qui corroborent un modèle riche de données, non une inspection de logs ou de rétention. Les messages texte restent traités séparément de l’E2EE DAVE des médias admissibles. |
| Wire / Delta Chat | Les lignes Google Play plus anciennes du tableau restent les seules captures directes de ce relevé; les politiques, dépôts et permissions listées dans leurs fiches individuelles complètent le contexte. | Labels exacts à re-capturer par pays, date, version et variant avant Phase 3; aucun binaire Android/iOS courant n’a été décompilé pour cette mission. |
| Ricochet Refresh | App desktop; sans fiche Google Play/App Store officielle à comparer. | Les permissions OS de la build desktop et les capacités des composants Tor doivent être évaluées par manifeste/package propre à chaque OS; ce n’est pas un cas « aucune permission ». |

**État comparatif du code mobile :** les dossiers citent des éléments de code publics lorsque ceux-ci étaient effectivement consultés (notamment le manifeste Android Signal, la configuration FCM/F-Droid de Delta Chat et des entitlements/permissions documentés pour plusieurs clients). Le contrôle complet des manifestes fusionnés et binaires de magasin à la même version n’a pas été exécuté pour les 17 apps. Les permissions caméra, micro, photos/fichiers, localisation et Bluetooth listées dans un store ou un manifest ne prouvent pas qu’elles sont demandées ni utilisées; les permissions runtime et les destinations réseau nécessiteraient une capture sur appareil de laboratoire. Firebase, Sentry et analytics sont notés comme observés seulement lorsqu’une source liée à la version le prouve; leur absence ne peut pas être conclue à partir d’un label vierge.

**Permissions & SDKs — état probatoire.** Aucune archive APK/IPA n’a été téléchargée et décompilée ici; je ne peux donc pas affirmer les permissions Android effectives, les entitlements iOS, ni la présence/absence de Firebase, Sentry ou analytics dans les binaires courants. Les usages photo/micro/caméra/localisation doivent être séparés entre permission déclarée et permission demandée à l’exécution. Pour chaque finaliste, ces cases restent **UNKNOWN / NON TESTÉES** jusqu’à relever version, hash du binaire, manifeste/Info.plist, dépendances et destinations réseau sous permissions refusées puis autorisées.

### Complément statique — manifests Android des dépôts publics, snapshot du 14 octobre 2026

J’ai ensuite lu les manifests source du client Android courant disponible sur la branche par défaut pour quatre dépôts. Les liens ci-dessous pinent le blob/commit effectivement retourné par le dépôt. **C’est une observation de code source**, pas du manifest fusionné de release, d’un APK de magasin ou d’une permission accordée à l’exécution; les manifests de dépendances, flavors et variantes peuvent modifier le résultat final.

| Client / fichier public observé | Observé dans le dépôt à ce snapshot | Ce que cela n’établit pas |
|---|---|---|
| Signal Android — [`AndroidManifest.xml`, blob `8e112cff`](https://github.com/signalapp/Signal-Android/blob/8e112cffb471d4dd045d745dccd9e8f0ecee319c/app/src/main/AndroidManifest.xml) | Déclare contacts read/write, appareil photo, micro, coarse/fine location, état/téléphone, médias, notifications et Wi-Fi proche. `allowBackup=true` avec un `SignalBackupAgent` dédié. Le manifeste désactive la collecte Firebase Analytics et l’auto-init Firebase Messaging, et désactive la collecte d’Advertising ID par Google Analytics. | `allowBackup=true` ne prouve pas qu’une sauvegarde Android expose des messages en clair; l’agent dédié et les chemins de sauvegarde doivent être étudiés séparément. Les métadonnées Firebase ne prouvent ni absence de dépendance Firebase ni absence d’un appel initialisé autrement. Permissions déclarées ≠ permissions runtime accordées. |
| SimpleX Android — [`AndroidManifest.xml`, blob `64d7a03c`](https://github.com/simplex-chat/simplex-chat/blob/64d7a03cf75bd7de51b99899ed02f8c14e25e063/apps/multiplatform/android/src/main/AndroidManifest.xml) | Déclare caméra, audio/vidéo, notifications, foreground services, réseau, réveil/boot et stockage historique limité aux anciens Android; `allowBackup=false`. Le manifest `common` séparé n’ajoute ici que vibration et état réseau. | Le fichier `android` n’est pas à lui seul le manifest fusionné du build Play/F-Droid. L’absence de `READ_CONTACTS` dans ce fichier ne prouve pas son absence dans tous les variants/dépendances; elle ne dit rien sur les flux push ou la télémétrie runtime. |
| Session Android — [`AndroidManifest.xml`, blob `2a6f7bb8`](https://github.com/session-foundation/session-android/blob/2a6f7bb80bb2fd8e58c96c5765804050bb1d39d8/app/src/main/AndroidManifest.xml) | Déclare caméra, micro, médias/stockage, appels, notifications et réception `com.google.android.c2dm.permission.RECEIVE`; `allowBackup=false`. Les meta-data désactivent Firebase Analytics, la collecte SSAID/Advertising ID et l’auto-init Firebase Messaging. | Le C2DM permission atteste un mécanisme Android de livraison compatible FCM, pas le contenu d’un payload ni une collecte de profil. Le manifest final de chaque canal/build et l’usage runtime n’ont pas été contrôlés. |
| Threema Android — [`AndroidManifest.xml`, blob `128bfac3`](https://github.com/threema-ch/threema-android/blob/128bfac3c6cb0c136d5f0895c14e2566680b267d/app/src/main/AndroidManifest.xml) | Déclare contacts read/write, médias, localisation, microphone, état/appels téléphoniques, caméra, Bluetooth et notifications; `allowBackup=false`; `usesCleartextTraffic=false`. | Le manifest ne prouve ni que chaque permission est demandée ni qu’elle est utilisée. `usesCleartextTraffic=false` ne certifie pas toutes les bibliothèques natives, sockets custom ou le chiffrement de bout en bout. |

**Non obtenus dans cette passe :** manifests source fiables et pinés pour Olvid et Briar par les chemins GitHub testés; leurs dépôts peuvent utiliser un autre forge, une autre structure ou ne pas être indexés par cette API. Je ne transforme pas l’échec de recherche en absence de permissions/SDK. Cette inspection source réduit l’inconnu pour quatre clients, mais ne remplace pas l’extraction du binaire et la comparaison du `merged manifest` avec la version d’application installable.

## Dépôts publics / activité observée — échantillon borné, pas audit exhaustif

| Dépôt client | Observation vérifiable au 13 oct. 2026 | Ce qu’on ne peut pas en déduire |
|---|---|---|
| Signal Android | GitHub liste des releases fréquentes; v8.31.1 (8 oct.) est explicitement marquée pré-release, alors que v8.30.3 est marquée latest dans la page observée. Les tags affichent des commits courts; la page consultée n’établit pas à elle seule une signature cryptographique/reproductibilité. [Releases](https://github.com/signalapp/Signal-Android/releases). | La fréquence prouve une maintenance observable de ce dépôt, pas le nombre réel de mainteneurs, la sécurité du backend ou que le Play APK correspond au code taggé. Les artifacts et build pipeline n’ont pas été reproduits. |
| SimpleX Chat | Releases affichent v7.0.3 comme latest (26 sept. selon la page) et v7.1.0-beta.6 (3 oct.). Le tag et commit de cette beta sont marqués « verified » par GitHub pour la clé GPG D53BDFD153C366BA de Simplex Operations. La politique SECURITY.md est révisée le 25 mai 2026. [Releases](https://github.com/simplex-chat/simplex-chat/releases), [security](https://github.com/simplex-chat/simplex-chat/security). | Signature vérifiée GitHub ≠ build reproductible ni attestation que l’APK/IPA provient de ce commit; disponibilité de la clé/révocation et contrôle de la chaîne complète encore à documenter. |
| Element Android | Releases publiques jusqu’à v1.6.66. Un correctif high de sécurité est publié en v1.6.58 (13 mai, commit `80285ed` selon la page) contre l’usurpation de `sender_device_keys` sur événements to-device chiffrés Olm, CVE-2026-45056/GHSA-wfq4-36m3-9g42; v1.6.62 (21 juillet, commit `e2df418`) corrige aussi la sanitisation d’emplacement de fichiers (GHSA-fr74-76wm-x6pp). [Releases](https://github.com/element-hq/element-android/releases). | Ces correctifs doivent être reliés aux versions effectives utilisées; ils ne démontrent pas l’état de toutes les implémentations Matrix/clients ou serveurs. Date/commit courant de v1.6.66 pas suffisamment établi dans la lecture actuelle. |
| Briar | Page GitHub de releases consultée ne donne pas une liste exploitable dans l’extraction Web. | Ce résultat ne permet pas d’affirmer « projet sans releases » ni inactif; il faut interroger le dépôt, tags, F-Droid et site officiel de manière croisée. |
| Threema Android / iOS / Desktop / Web / Push Relay | Les dépôts officiels Android/iOS indiquent un commit par release publique non-bêta et commits PGP signés; Desktop publie l’historique des commits; Push Relay documente les champs de requête/payload. Au snapshot GitHub du 14 oct. 2026, l’activité était récente; Web est explicitement en maintenance (correctifs critiques, pas de nouveautés majeures). [Android](https://github.com/threema-ch/threema-android), [iOS](https://github.com/threema-ch/threema-ios), [Desktop](https://github.com/threema-ch/threema-desktop), [Web](https://github.com/threema-ch/threema-web), [Push Relay](https://github.com/threema-ch/push-relay). | Cela ne prouve pas que les binaires distribués correspondent au code. Android décrit la reproductibilité comme expérimentale; iOS dit qu’elle reste à l’étude. Le README iOS signale une dépendance WebRTC fournie en binaire par Threema. Aucun rebuild/comparaison de hash ni audit du backend principal n’a été effectué. La clé PGP Web indiquée dans le README expire le 4 sept. 2026 : rotation/révocation à vérifier; cette date seule n’invalide pas rétroactivement les signatures. |

### Échantillon reproductible d’activité visible — branche par défaut, 90 jours

Au 14 octobre 2026, j’ai demandé à l’API publique GitHub les commits depuis le 16 juillet 2026, page 1 (100 éléments max), puis compté les identifiants d’auteurs distincts dans les commits retournés. Les nombres ci-dessous sont des **comptes d’auteurs visibles dans l’échantillon**, pas des mainteneurs vérifiés, développeurs équivalents temps plein, reviewers ou personnes qui gèrent les releases. Les dépôts à 100 sont tronqués par la limite de page; les contributions de bots, translations, merges et comptes secondaires peuvent gonfler ou fragmenter le compte.

| Produit / dépôt réellement compté | Commits renvoyés | Auteurs distincts visibles | Portée |
|---|---:|---:|---|
| Signal — [Signal-Android](https://api.github.com/repos/signalapp/Signal-Android/commits?since=2026-07-16T00:00:00Z&per_page=100) | ≥100 | 7 | Dépôt client Android seulement; les 100 résultats sont un plafond, pas le total. |
| SimpleX — [simplex-chat](https://api.github.com/repos/simplex-chat/simplex-chat/commits?since=2026-07-16T00:00:00Z&per_page=100) | ≥100 | 5 | Monorepo du client/protocoles; plafond atteint. |
| Olvid — [olvid-android](https://api.github.com/repos/olvid-io/olvid-android/commits?since=2026-07-16T00:00:00Z&per_page=100) | 2 | 1 | Dépôt Android public seulement; services/backend séparés non comptés. |
| Session — [session-android](https://api.github.com/repos/session-foundation/session-android/commits?since=2026-07-16T00:00:00Z&per_page=100) | ≥100 | 5 | Dépôt Android; un compte auteur représente la majorité de l’échantillon, mais bots inclus. |
| Threema — [threema-android](https://api.github.com/repos/threema-ch/threema-android/commits?since=2026-07-16T00:00:00Z&per_page=100) | 3 | 1 | Android seulement; autres clients/repos non agrégés. |
| Tox — [c-toxcore](https://api.github.com/repos/TokTok/c-toxcore/commits?since=2026-07-16T00:00:00Z&per_page=100) | 23 | 6 | Cœur protocolaire. |
| qTox — [TokTok/qTox](https://api.github.com/repos/TokTok/qTox/commits?since=2026-07-16T00:00:00Z&per_page=100) | 23 | 10 | Client desktop; le fork actif est distinct de l’ancien dépôt archivé. |
| Matrix — [Element X Android](https://api.github.com/repos/element-hq/element-x-android/commits?since=2026-07-16T00:00:00Z&per_page=100) | ≥100 | 9 | Client Android uniquement. |
| Matrix — [Synapse](https://api.github.com/repos/element-hq/synapse/commits?since=2026-07-16T00:00:00Z&per_page=100) | ≥100 | 25 | Homeserver Matrix; il n’est pas agrégé avec les clients. |
| Telegram — [Android source](https://api.github.com/repos/DrKLO/Telegram/commits?since=2026-07-16T00:00:00Z&per_page=100) | 38 | 6 | Source Android publique du client; iOS/backend non comptés. |
| Discord — [libdave](https://api.github.com/repos/discord/libdave/commits?since=2026-07-16T00:00:00Z&per_page=100) | 15 | 2 | Bibliothèque DAVE seulement; ne mesure pas l’équipe du client Discord fermé. |
| Wire — [wire-android](https://api.github.com/repos/wireapp/wire-android/commits?since=2026-07-16T00:00:00Z&per_page=100) | ≥100 | 10 | Client Android uniquement; plafond atteint. |
| Delta Chat — [deltachat-android](https://api.github.com/repos/deltachat/deltachat-android/commits?since=2026-07-16T00:00:00Z&per_page=100) | ≥100 | 4 | Client Android seulement; le core Rust et desktop ne sont pas agrégés. |
| Ricochet Refresh — [ricochet-refresh](https://api.github.com/repos/blueprint-freespeech/ricochet-refresh/commits?since=2026-07-16T00:00:00Z&per_page=100) | 2 | 1 | Branche stable par défaut; alpha séparée non incluse. |
| Status — [status-app](https://api.github.com/repos/status-im/status-app/commits?since=2026-07-16T00:00:00Z&per_page=100) | ≥100 | 10 | App seulement; Logos/Waku/projets voisins non agrégés. |

**Hors mesure GitHub dans cette passe :** Cwtch publie ses dépôts sur [git.openprivacy.ca](https://git.openprivacy.ca/cwtch.im/cwtch); Briar sur son [GitLab officiel](https://code.briarproject.org/briar/briar); Jami sur son infrastructure de revue/dépôt [jami.net](https://review.jami.net/). Le lien GitHub Conversations cité dans le dossier XMPP a renvoyé 404 via l’API interrogée; le bon dépôt/miroir de la version 2.20.4+free reste à confirmer, donc aucun auteur n’est compté. Aucun dépôt public complet du client WhatsApp ou Discord n’est revendiqué ici. Ces absences d’échantillon GitHub ne signifient pas absence d’activité ou de source publique ailleurs.

**Bilan supply chain de cette sous-étape.** Rien ici ne prouve des builds reproductibles. Une release signée, un tag publié, du code source accessible ou une CI verte ne démontrent pas que l’installateur servi au téléphone a été construit à partir de ce code. Il faut comparer des builds locaux reproductibles aux binaires de chaque canal, vérifier signatures/digests, attestations CI, dépendances vendored et provenance des stores. Ce travail n’a pas été effectué.

## OSINT d’infrastructure — limite de la collecte actuelle

Les sources documentaires officielles décrivent les rôles d’infrastructure de tous les produits, mais les **observations DNS courantes** restent échantillonnées. Des réponses A/AAAA/CNAME et des préfixes BGP/ASN sont maintenant consignés pour des endpoints Matrix/Element, Signal, certains presets SimpleX, Wire, Jami, Olvid et deux endpoints Delta Chat. Pour Olvid, l’attribution régionale des IP AWS a été recoupée avec le fichier IP ranges du fournisseur et a révélé une discordance avec deux étiquettes de région TURN publiées. Pour Threema, les sources consultées donnent des ports et emplacements déclarés, mais pas les hostnames d’API nécessaires à une attribution réseau défendable. Pour les autres services, une carte DNS/ASN complète reste à acquérir. Les résolutions faites ici sont des requêtes DNS actives ordinaires, pas des historiques DNS passifs; elles ne révèlent pas à elles seules le propriétaire contractuel, les origins, les régions de données, les logs ou le trafic réellement utilisé. Aucun scan de port ni connexion applicative n’a été effectué. La première tentative standard avait reçu un accès réseau refusé; les requêtes ciblées ultérieures ont été autorisées.

### Couverture OSINT par service — observation et inconnues séparées

Cette table est un index de ce qui a effectivement été observé dans les dossiers ci-dessous, pas une cartographie exhaustive ni une attribution de propriété. « Snapshot » signifie résolution DNS ordinaire et consultation publique de BGP/ASN à une date donnée; ce n’est pas du passive DNS historique et cela ne prouve ni la localisation des données ni la route prise par un client donné.

| Service | Architecture / endpoints publics utiles | Observation DNS / ASN consignée | Inconnu qui demeure |
|---|---|---|---|
| Signal | Service central; noms officiels de connectivité et appels, dont `signal.org`, `sfu.voip.signal.org` et `turn3.voip.signal.org`. [Domaines et ports](https://support.signal.org/hc/de/articles/360007320291-Einstellungen-f%C3%BCr-Firewall-und-Internet) | `signal.org` → Cloudflare AS13335; SFU → Google Cloud AS396982; `turn3` a répondu NODATA au résolveur testé. [RIPEstat AS13335](https://stat.ripe.net/AS13335), [AS396982](https://stat.ripe.net/AS396982) | API de messagerie, origines, région SFU, autres pools TURN, routage réellement utilisé et journaux. |
| SimpleX | Réseau de relais SMP sélectionnables; presets officiels et relais ICE/TURN séparés. [Vue d’ensemble](https://simplex.chat/docs/guide/introduction/) | Snapshots de certains relais: `smp11` AS400226 (StormyCloud), `smp12` et `smp14` AS63949 (Linode/Akamai); échantillon de presets uniquement. [RIPEstat AS400226](https://stat.ripe.net/AS400226), [AS63949](https://stat.ripe.net/AS63949) | Inventaire complet et changeant des relais/ICE, domaine client réellement choisi, opérateur contractuel et rétention par nœud. |
| Olvid | Serveur de compte/routage, transfert, pièces jointes et régions TURN documentés par le fournisseur. [FAQ administrateurs](https://olvid.io/faq/for-administrators/) | Snapshots des noms TURN et comparaison aux plages AWS; deux étiquettes régionales publiées ne concordaient pas avec les network border groups AWS observés. [Plages AWS](https://ip-ranges.amazonaws.com/ip-ranges.json) | Répéter depuis d’autres régions/résolveurs; confirmer auprès du fournisseur; ne pas inférer région de stockage, opérateur contractuel ou politique de logs. |
| Session | Messages via Session Network/onion requests; appels beta avec STUN/TURN STF selon FAQ. [FAQ](https://getsession.org/faq) | Pas de snapshot DNS/ASN complet des services courants dans cette passe. | Nœuds de sortie/entrée réellement choisis, adresse source visible par chaque nœud, endpoints d’appel et rétention. |
| Threema | Services centraux, directory/identity, push, appels et transfert selon documentation; l’API courante n’est pas entièrement nommée dans le corpus. [Rapport de transparence](https://threema.com/en/transparency-report) | Aucun mapping défendable des domaines de production. Une bibliothèque tierce cite `api.threema.ch/identity`, mais la résolution n’a pas abouti ici; ce n’est pas une preuve d’API active. | Hostnames officiels actuels, domaines par fonctionnalité, DNS/ASN, hébergeurs, régions et sous-traitants. |
| Cwtch | Architecture Tor et services onion plutôt que serveur central classique. [Documentation](https://docs.cwtch.im/) | Pas de DNS/ASN applicatif attribué dans cette passe. | Inventaire des services onion/relays utilisés par build, bootstrap, opérateurs et dépendances de téléchargement. |
| Briar | Pas de serveur central de messages; Tor sur Internet et transports locaux Bluetooth/Wi-Fi/carte mémoire. [Architecture](https://briarproject.org/how-it-works/) | Pas de mapping DNS/ASN des chemins de production consigné. | Relais Tor réellement utilisés, bootstrap/bridges selon build, endpoints de téléchargement et disponibilité par pays. |
| Jami | DHT, bootstrap, proxy/TURN et service de noms documentés dans le code et les dossiers. [Code Jami](https://review.jami.net/) | Snapshots des endpoints échantillonnés principalement attribués à OVH AS16276; une adresse n’a pas été résolue/attribuée. [RIPEstat AS16276](https://stat.ripe.net/AS16276) | Ensemble de nœuds, rotation, opérateur de chaque service, configuration par client et éventuels relais tiers. |
| Tox / qTox | DHT distribué avec nœuds bootstrap; le client et le protocole n’ont pas d’infrastructure centrale de comptes. [c-toxcore](https://github.com/TokTok/c-toxcore) | Pas de snapshot complet des nœuds bootstrap, IP/ASN ou de leur disponibilité consigné. | Liste/version des nodes utilisés, changements de bootstrap, observation DHT et éventuels relais de fichiers/appels. |
| Matrix / Element | Homeserver choisi (Matrix.org ou autre), services Element Call/SFU et push distincts. [Element Call](https://docs.element.io/latest/element-server-suite-classic/integrations/setting-up-element-call/) | `matrix.org`, `vector.im` et endpoint d’appel observés derrière Cloudflare AS13335; SFU/JWT rattachés à AWS eu-central-1 dans l’échantillon. | Routes par région/utilisateur, fédération réellement utilisée, autres homeservers, storage/CDN et sous-traitants. |
| XMPP / OMEMO | Architecture dépend du domaine et de l’hébergeur choisis; le serveur `conversations.im` est une option, pas le réseau entier. [Hébergement Conversations](https://account.conversations.im/) | Aucun domaine d’instance choisi n’a été résolu/attribué dans cette passe. | Il faut fixer client, domaine, serveur upload, push gateway, DNS/ASN et juridiction; aucune généralisation au protocole. |
| Telegram | Service central avec points d’accès/API et stockage cloud; Secret Chats ont une portée distincte. [FAQ](https://telegram.org/faq) | Pas de snapshot DNS/ASN actuel consigné pour ce dossier. | Domaines/API par région, CDN/media, anycast, hébergement effectif et routage de compte. |
| WhatsApp | Service central Meta, avec push, média et chemins d’appels; déclaration d’infrastructure générale uniquement. [Privacy policy](https://www.whatsapp.com/legal/privacy-policy) | Aucun snapshot DNS/ASN de production consigné. | Domaines WhatsApp vs Meta, cloud/CDN/origins, régions, partenaires et routes par fonctionnalité. |
| Discord | API, messages/fichiers centralisés; migration Cloudflare annoncée pour une partie des appels audio/vidéo. [Annonce Discord](https://discord.com/blog/how-discord-uses-cloudflare-to-scale-voice-and-video) | Pas de DNS/ASN observé; l’annonce d’ingénierie sur Cloudflare concerne voice/video, pas l’API texte ou stockage. | Domaines/API, régions, ASNs et fournisseur de données pour texte, médias et services d’identité. |
| Wire | Backend central et pools séparés de TURN/SFT selon whitepaper et dossiers. [Whitepaper](https://wire.com/hubfs/Whitepapers/-wire-security-whitepaper.pdf) | Endpoints échantillonnés, notamment pools d’appels, attribués à Amazon AS16509; une entrée n’a pas de préfixe attribuable. [RIPEstat AS16509](https://stat.ripe.net/AS16509) | Mapping complet des endpoints backend, régimes régionaux, contrat cloud, routage effectif et logs. |
| Delta Chat | Email choisi par l’utilisateur, chatmail optionnel, push et relais d’appel/fallback Delta. [Politique](https://delta.chat/ca/privacy) | `nine.testrun.org` et `turn.delta.chat` observés sur Hetzner AS24940. [RIPEstat AS24940](https://stat.ripe.net/AS24940) | Les serveurs choisis par chaque utilisateur, relais tiers, régions et trafic réel; deux endpoints ne cartographient pas l’écosystème. |
| Ricochet Refresh | Messages via Tor onion services; site, dépôt et distribution binaire restent des dépendances séparées. [Dépôt](https://github.com/blueprint-freespeech/ricochet-refresh) | Pas de snapshot DNS/ASN du site/download ou des services Tor consigné. | DNS/registrar/CDN du site, signatures de releases, bootstrap Tor, relais et miroir de distribution. |
| Status / Waku | Nœuds Waku gérés et services Store/Bootstrap/Filter/Light Push, proxy RPC et push documentés par Status. [Infrastructure Status](https://status.app/technology/) | Pas de snapshot DNS/ASN pour les nœuds utilisés par Status App. | Endpoint réel par session, concentration d’opérateurs, régions/clouds, logs, IP/topics et push. |

**Limite de méthode :** les ASN nomment un réseau annonçant le préfixe au moment observé, pas nécessairement le fournisseur de service ou le propriétaire du serveur. CDN, anycast, reverse proxy et hébergement loué peuvent séparer annonce réseau, opérateur applicatif et détenteur contractuel. Les observations ne remplacent pas une capture réseau contrôlée sur client/version identifiés.

## Audits lus en détail — Briar, Threema et Delta Chat

### Briar — Cure53, mars 2017

- **FACT — organisme/date/durée** : Cure53, mission terminée en mars 2017, six testeurs, 13 jours. Rapport du 20 mars 2017. Méthode white-box avec source Android et APKs de debug fournis. [Rapport complet](https://briarproject.org/raw/BRP-01-report.pdf).
- **Version/commit** : rapport dit app à un stade très précoce; numéro de release ou commit exact non établi dans le PDF consulté.
- **Scope** : app Android et code source; revue de protocoles BQP, BSP et BTP et cryptographie. Trois jours dédiés à l’analyse crypto; le code crypto a reçu deux jours de revue; des spécifications BSP/BTP ont d’abord été jugées trop peu détaillées, puis « appropriées » après échanges. Pas d’app iOS ni d’infrastructure serveur à auditer, Briar n’ayant pas le serveur central classique.
- **Findings** : 12 au total, six vulnérabilités et six problèmes informatifs. Vulnérabilités : High — fuite DNS via import RSS; Medium — capture d’écran faute de `FLAG_SECURE`, tapjacking pouvant configurer/déclencher Panic et effacer les données, activités exportées/interruption, PendingIntent potentiellement détournable; Low — déconnexion arbitraire par PanicResponderActivity. Informational — fuites possibles dans logcat/debuggable, crash par intent, DoS de padding, contrôle de force du mot de passe et combinaison inutile de deux CSPRNG.
- **Recommandations/remédiation** : restrictions de capture écran, contrôle des overlays/intents exportés, correction du chemin RSS/DNS, renforcer l’estimateur de mot de passe, simplifier le RNG. OTF affirme aujourd’hui que les enjeux de l’audit 2017 ont été corrigés; le rapport 2017 ne contient pas de retest indépendant de ces correctifs. Il qualifie l’app testée d’early-stage et recommande un second audit après développement.
- **Conséquence** : historique utile pour endpoint/app, mais ni vulnérabilité actuelle démontrée ni audit de la version actuelle.

### Briar — Radically Open Security / OTF, septembre–octobre 2023, retest février–mars 2024

- **FACT — organisme/date/durée/méthode** : Radically Open Security, engagement OTF Security Lab « crystal-box/white-box ». Période 21 septembre–31 octobre 2023; effort 24–26 jours (préparation, test Android/desktop, analyse protocoles/crypto, retest, revue et coordination) selon le rapport PDF indexé. [Page OTF et findings](https://www.opentech.fund/security-safety-audits/briar-security-audit/), [rapport complet PDF](https://www.opentech.fund/wp-content/uploads/2024/06/report_briar-android.pdf).
- **Scope** : clients Android et desktop; protocoles et cryptographie Android. Pas d’indication d’audit de la gouvernance, des stores ou de toutes les distributions de binaires.
- **Findings** : six problèmes — un risque modéré et cinq faibles, aucun dans les catégories OTF Extreme/High/Elevated. Modéré OTF-001 : attaque overlay sur l’app Android; le rapport signale l’atténuation Android 12+ avec `Window.setHideOverlayWindows(true)`. Faibles : OTF-002 PSK trop courte pour le partage Wi-Fi du paquet (attaquant proche pendant le partage initial pourrait tenter brute-force puis injecter un paquet); OTF-003 socket TCP de l’app/service Tor sans isolation Android équivalente aux Unix domain sockets; OTF-004 protections stack overflow; OTF-005 impossibilité pour un contact initialement distant d’élever ultérieurement son niveau de vérification; OTF-006 la dénégation plausible dépend du type de contenu et n’est pas identique pour messages, forums, blogs et groupes, sans être explicitée dans la documentation utilisateur.
- **Recommandations** : masquer overlays sur Android 12+, doubler longueur PSK, utiliser Unix sockets pour app/Tor, activer stack canaries et `_FORTIFY_SOURCE`, permettre une vérification ultérieure (QR/SMP analogue), documenter les limites de dénégation.
- **Retest/corrections** : ROS a retesté en fév.–mars 2024; quatre des six issues résolues. OTF dit explicitement qu’OTF-003 et OTF-005 étaient encore planifiées pour correction. La page ne donne pas commit/build précis ni la correspondance complète des quatre correctifs au retest. Le PDF hébergé a répondu 403 dans l’outil de lecture; l’extraction actuellement exploitable provient des passages indexés du PDF et de la synthèse OTF, donc la lecture intégrale page par page reste à faire.

### Threema — audit de code IT Security Group, Hochschule Münster, 2018–2019

- **FACT — rapport/source** : rapport signé Fabian Ising, Damian Poddebniak et Sebastian Schinzel, daté du 28 mars 2019; période octobre 2018–janvier 2019; 22 jours-personne. [Rapport complet PDF](https://threema.com/assets/documents/audits/security_audit_report_threema_2019.pdf).
- **Scope** : audit source Android v3.54, iOS v3.0.9 et Threema Safe Android; code serveur hors scope; quelques tests live avec apps de production. Revue visant aussi les déclarations du whitepaper cryptographique.
- **Findings** : deux médiums et plusieurs faibles/informatifs. Une app Android malveillante pouvait lancer un partage contenant des fichiers privés, potentiellement `key.dat`, mais la victime devait encore choisir le contact destinataire; fragments du mot de passe Threema Safe présents dans un log interne Android. Aucun high/critical, pas d’écart au whitepaper rapporté.
- **Corrections** : le rapport dit que toutes les findings medium/low ont été corrigées en Android 3.62 et iOS 4.1 (correctifs souvent en heures ou jours). Aucun retest post-correction détaillé n’est décrit. Ce n’est pas un audit serveur, de l’infrastructure ou de versions actuelles.

### Threema — Cure53, apps mobiles, octobre 2020

- **FACT — durée/méthode** : 4 membres Cure53, 16 jours-personne sur la semaine CW42; white-box et sources fournies. Rapport Cure53 du 30 octobre 2020. [Rapport complet](https://threema.com/assets/6-resources/audits/2020_cure53_audit_mobile_apps.pdf).
- **Scope** : Android, iOS, Sodium/NaCl et intégration crypto. Stockage Android inspecté via adb sur appareil rooté Android 9 + deux émulateurs x86; stockage iOS sur appareil jailbreaké iOS 13.3.1/checkra1n. Interception réseau, TLS invalide, logs, attaques locales et VoIP examinés. Versions exactes d’app/commit non données dans les passages de scope parcourus.
- **Findings** : huit problèmes, aucun considéré comme vulnérabilité exploitable dans l’engagement; sept informatifs/faibles et un medium. L’index cite cache client iOS (`NSURLCache`) et fichiers d’état/snapshots, protections filesystem iOS perfectibles, dépendance GIF Android ancienne, absence `FORTIFY_SOURCE` dans plusieurs libs tierces, capture auto de screenshots révélant temporairement des informations, comparaison de PIN non timing-safe, recommandations de réglages.
- **Observation de stockage importante, historique** : Android stockait DB chiffrée; AES-256 master key dans `key.dat`, sans passphrase locale la clé pouvait être récupérée par un acteur déjà hautement privilégié/root; avec passphrase, les testeurs n’ont pas identifié de contournement. iOS : DB Core Data chiffrée et clé privée Keychain `AfterFirstUnlockThisDeviceOnly`; pas de contournement observé dans les conditions testées. L’audit n’établit pas les versions ni le comportement d’appareils actuels.
- **Remédiation/retest** : pas de réexamen indépendant post-correction identifié dans ce rapport. Il faut faire correspondre ces conclusions anciennes à la politique de passphrase, au stockage et aux versions présentes.

### Threema Desktop — Cure53, janvier 2024

- **FACT — organisme/date/durée** : Cure53, cinq testeurs seniors, 16 jours en CW03–CW04 2024; commandité par Threema GmbH. [Rapport Cure53 PDF](https://threema.com/assets/6-resources/audits/3ma-03-report.v3.pdf), [index officiel des audits](https://threema.com/en/faq/code-audit).
- **Version/scope** : Desktop 2.0 Beta 26. Test white-box de l’interface Svelte, backend et IPC, communication réseau; code source et builds multi-OS fournis. Pas audit des applis mobiles dans ce mandat.
- **Findings/remédiations listées dans le rapport** : 3 vulnérabilités : SVG preview pouvant provoquer DoS (Low, corrigé Beta 28); type de fichier/accès propriété non sûr provoquant DoS d’une room (Medium, Beta 28); fichiers téléchargés sans macOS quarantine flag (Low, Beta 28). Quatre general weaknesses : réglages Electron worker potentiellement propices à RCE si un XSS était déjà obtenu (étiqueté « High » dans le titre; Threema dit qu’il ne peut pas simplement retirer Node integration/sandbox en raison d’une limite Electron et a ajouté CSP stricte + SRI Beta 43); CSP insuffisamment restrictive (Medium, Beta 28 puis renforcée Beta 43); prototype pollution par postMessage (Info, Beta 31); contournement de navigation via History API (Info, Beta 31).
- **Contradiction interne à conserver** : le rapport classe `3MA-03-004` « High » dans son titre, mais indique dans son résumé qu’aucun finding Critical ni même High-scored n’a été relevé; le même document distingue vulnérabilités réelles et general weaknesses à faible potentiel d’exploitation. Le rapport n’explique pas complètement cette discordance de libellé. Il dit aussi qu’aucun XSS n’a été découvert; la chaîne RCE était une conséquence conditionnelle si XSS existait.
- **Retest** : fix notes versionnées dans le rapport, mais pas de retest externe post-fix identifié. Cure53 a néanmoins inspecté SQL local chiffré, vérifié absence de fuite claire dans les fichiers examinés, pinning/hostname verification et traitement des certificats invalides dans le build testé.

### Threema Ibex — analyse cryptographique académique, juillet 2023

- **FACT / source** : Paul Gerhart, Paul Rösler et Dominique Schröder, 30 juillet 2023, analyse avec preuve de sécurité publiée par le groupe de cryptographie appliquée d’Erlangen–Nuremberg (PDF 38 pages). [Analyse complète](https://threema.com/press-files/2_documentation/security_analysis_ibex_2023.pdf), [notice éditeur](https://threema.com/en/blog/security-proof-ibex).
- **Périmètre et résultat** : preuve formelle pour le protocole de canal/échange continu de clés Ibex selon un modèle donné, sous hypothèses GDH/Random Oracle; confidentialité, authenticité/intégrité, replay resilience et forward security. Ce n’est pas une pentest de l’app, du serveur ou du client courant.
- **Limites explicitement écrites par les auteurs** : analyse ne prouve pas la sécurité circulaire de la double encryption; suppose les clés publiques vérifiées hors bande/administrateur ou une PKI honnête; client desktop lié au mobile exclu. Recommande de travailler la résistance post-quantique, et note que le modèle de groupes un-à-un ne protège pas complètement l’existence/structure des groupes si le serveur analyse les motifs de communication; envisage des protocoles de type anonymous ratchet/ORAM.
- **Contradiction/cadrage** : l’affirmation marketing Threema selon laquelle « aucun tiers, pas même le serveur, ne peut identifier les participants » ne doit donc pas être étendue à la présence et structure des groupes sous analyse de motifs. La preuve Ibex valide des propriétés formalisées du protocole ciblé, pas l’anonymat global ni l’observation de trafic serveur.

### Delta Chat Webxdc — Cure53 / OTF, février–mars 2023

- **FACT — durée/méthode** : Cure53, 4 testeurs seniors, 12 jours, white-box; demandé en février et exécuté semaines de travail 11–13 de mars 2023. [Rapport PDF](https://public.opentech.fund/documents/XDC-01-report_2_1.pdf), [récit OTF](https://www.opentech.fund/security-safety-audits/delta-chat-pentest-and-privacy-leak-audit/).
- **Scope** : promesse de confidentialité Webxdc et revue de spécification; implémentations Android, iOS et desktop des mini-apps; période et build précis du rapport connus comme releases de février 2023, mais commit exact pas encore extrait.
- **Findings** : 7 total, 5 vulnérabilités et 2 problèmes informatifs. Cinq High dans les versions auditées : exfiltration DNS-prefetch desktop; bypass CSP complet par `webxdc.js` desktop; exfiltration DNS lookup Android; exfiltration via DevTools desktop; bypass CSP par inclusion PDF desktop. Info : recommandation `selfAddr` spoofable dans payload et manque d’en-tête CSP pour `webxdc-update.json` iOS.
- **Corrections** : blog de l’équipe indique corrections high par séries v1.36 (avril 2023), cite PR/commits desktop/Android/iOS et explique les limites Chromium (DNS prefetch/WebRTC). Les deux informatifs avaient décisions distinctes : API `selfAddr` à faire évoluer, CSP iOS corrigée. Retest externe formel après les fixes n’est pas établi par les sources consultées.
- **Portée** : cet audit valide spécifiquement la sandbox Webxdc d’un ensemble de clients en 2023; il ne faut pas l’appliquer au transport SMTP/IMAP ni à chaque Webxdc personnalisé actuel.

### Delta Chat — analyse ETH Zürich / USENIX Security 2024 (SecureJoin/Autocrypt/rPGP)

- **FACT / source indépendante** : Yuanming Song, Lenka Mareková, Kenneth G. Paterson, USENIX Security 2024, « Cryptographic Analysis of Delta Chat ». [Paper ETH/USENIX](https://www.usenix.org/system/files/usenixsecurity24-song-yuanming.pdf), [fiche publication ETH](https://www.research-collection.ethz.ch/handle/20.500.11850/727920).
- **Résultat** : les chercheurs décrivent cinq nouvelles attaques dans le modèle de menace Delta Chat, issues d’interactions SecureJoin/Autocrypt et de bugs dans rPGP. Responsibly disclosed; l’éditeur indique 20 issues au total dans ses corrections de hardening et incorporation dans Delta Chat v1.44 avant divulgation, ce qui peut comprendre des vulnérabilités et problèmes/durcissements connexes, et ne doit pas être assimilé automatiquement au nombre « cinq attaques » du papier.
- **Limite** : papier academic peer-reviewed/USENIX et correctifs répertoriés par la source mainteneur; ce n’est pas un audit actuel de tous les clients, de l’email, des fournisseurs chatmail, ni une preuve de retest indépendant de chaque patch. La chronologie et détails de corrections sont dans l’article officiel du 25 mars 2024.

### Delta Chat — précisions d’implémentation courante, stockage et mobile (contrôle au 13 octobre 2026)

- **FACT — versions observées dans les listings** : le repo Android publie v2.62.0 le 26 septembre 2026 (commit `97161cc`, marqué “Verified” par GitHub); F-Droid avait v2.62.0, build 7584, le 28 septembre, Android 5+. Le repo Desktop publie v2.62.0 du 26 septembre, commit `8f8ffd7` également marqué vérifié par GitHub. Un tag/commit signé améliore l’authenticité du source annoncé; ce n’est pas une preuve que les binaires Google Play/App Store ou GitHub sont bit-à-bit reproductibles. [Android releases](https://github.com/deltachat/deltachat-android/releases), [F-Droid listing](https://f-droid.org/en/packages/com.b44t.messenger/), [Desktop release](https://github.com/deltachat/deltachat-desktop/releases).
- **F-Droid / build** : le listing F-Droid dit que son APK est construit et signé par F-Droid et correspond au tarball source référencé, et fournit une signature PGP et un build log. Le fetch du tarball, de la signature et du log par l’outil de navigation a échoué (cache miss); je n’ai pas téléchargé ni comparé le binaire au source. **Fait établi :** provenance de build déclarée par F-Droid. **Inconnu :** reproduction indépendante effective, résultat de comparaison binaire et équivalence avec Play/App Store.
- **Permissions déclarées par F-Droid pour ce build** : localisation approximative/précise au premier plan, caméra, microphone, Bluetooth (incluant appareils voisins), fichiers/images/vidéos, réseau, démarrage, notifications et services de premier plan sont listés. Le fournisseur dit que caméra = photo/QR/appels vidéo, micro = messages vocaux/appels, position = partage volontaire, fichiers/photos = joindre/enregistrer et biométrie = verrouillage local. Le listing expose les capacités requises par le manifeste/build F-Droid, pas la preuve qu’elles sont utilisées en permanence; la page ne liste pas `READ_CONTACTS`, mais le manifeste APK n’a pas été extrait ici. [F-Droid permissions](https://f-droid.org/en/packages/com.b44t.messenger/), [privacy policy](https://delta.chat/ca/privacy).
- **Contacts / analytics / tiers** : le changelog Android ajoute explicitement en v1.43 un réglage opt-in “Read System Address Book”; l’historique indique la sélection manuelle de ce réglage, donc ne pas confondre import local avec upload du carnet. L’éditeur dit que la statistique hebdomadaire Android est facultative, envoyée à un bot seulement après opt-in, avec exemples de fonctions utilisées/erreurs, et qu’elle ne contient rien d’identifiant. Cela demeure une **déclaration éditeur**; l’extraction du binaire et une capture réseau n’ont pas été faites. Le changelog dit que le build F-Droid/non-Google-Play désactive FCM; le build Android ordinaire utilise FCM seulement si le fournisseur et l’OS le prennent en charge. [Changelog Android](https://github.com/deltachat/deltachat-android/blob/main/CHANGELOG.md), [policy](https://delta.chat/ca/privacy), [FAQ stats/push](https://delta.chat/en/help).
- **Mise à jour réseau / résilience** : v2.62.0 indique que le nouvel onboarding sélectionne aléatoirement plusieurs relais au lieu d’un seul relais par défaut codé en dur; les messages sont interrogés sur tous les relais et envoyés via le plus rapide lors de la configuration initiale. C’est une évolution de disponibilité et concentration du service, pas une preuve d’anonymat réseau. Le client et la métadonnée d’adresse restent dépendants des relais choisis par le compte.
- **Stockage local — point à ne pas figer à partir de l’audit 2020** : l’audit Include Security 2020 a constaté sur Delta Chat 1.39.0 une DB/backup non chiffrée; un audit Cure53 de 2023 a trouvé la DB desktop non chiffrée contenant des données d’accès. Les API Rust documentent encore des opérations d’export DB avec passphrase, mais la documentation générée du cœur indique que le chiffrement DB est **déprécié depuis novembre 2025** car les blobs restent non chiffrés et recommande plutôt le chiffrement filesystem/disque, nécessaire aussi pour l’isolation des apps. Ainsi, le mécanisme optionnel ancien ne doit pas être décrit comme protection complète des données locales courantes. [API ContextBuilder](https://rs.delta.chat/deltachat/context/struct.ContextBuilder.html), [API DB](https://rs.delta.chat/deltachat/context/struct.Context.html).
- **Sauvegarde — incertitude restante** : l’aide courante dit que l’export manuel demande le PIN/schéma/mot de passe de déverrouillage système, puis un fichier est transféré/restauré manuellement; elle n’affirme pas que l’archive est cryptographiquement chiffrée avec une clé indépendante. Le rapport 2020 prouvait que le backup `.bak` du build 1.39.0 se lisait comme SQLite et exposait messages, clés et pièces jointes; les réponses publiques du forum en 2023 disent que le tar contient DB et médias sans chiffrement. Le cœur actuel expose `export_backup(..., passphrase)` et `export_backup_stream`, mais je n’ai pas vérifié l’argument utilisé par le GUI v2.62.0 ni le chiffrement de tous les blobs dans l’archive. **Conclusion probatoire actuelle :** archive v2.62.0 et contenu exact **UNKNOWN** sans inspection du code de l’appel/UI ou essai contrôlé; ne pas affirmer qu’elle est sûre parce qu’un PIN système est demandé, ni affirmer sans réserve que la version actuelle est identique au backup 2020. [FAQ sauvegarde](https://delta.chat/en/help), [code API export/import](https://rs.delta.chat/deltachat/imex/index.html), [audit 2020](https://delta.chat/assets/blog/2020-second-security-review.pdf), [discussion technique 2024](https://support.delta.chat/t/encrypted-backup-of-chats/3119).
- **FS / PQ — contradiction “prévu en 2026” vs état actuel** : la FAQ officielle dit explicitement que Delta Chat **ne prend pas encore en charge** Perfect Forward Secrecy ni le post-quantique; Autocrypt v2 est “scheduled for full implementation in 2026” et doit apporter rotation de clés/PFS et PQ. L’annonce v2.62.0 parcourue ne mentionne pas la livraison d’Autocrypt v2; aucun changement de protocole ou étude indépendante de disponibilité en stable 2.62.0 n’a été localisé. Donc, au 13 octobre 2026, le statut sûr est **NON ÉTABLI comme livré dans les apps stables**; l’existence d’une échéance de roadmap n’est pas une preuve de fonctionnalité. [FAQ cryptographie](https://delta.chat/en/help), [release 2.62 Android](https://github.com/deltachat/deltachat-android/releases), [release Desktop](https://github.com/deltachat/deltachat-desktop/releases).
- **Contenu vs en-têtes email** : la doc dit que le message chiffré protège texte, pièces jointes et leurs noms; elle décrit néanmoins les adresses expéditeur/destinataire et taille de message comme visibles aux serveurs, tandis que les groupes/contacts sont localement conservés et leur metadata incluse dans la partie E2EE. À cette date, le transport peut aussi être du courrier classique non E2EE si le correspondant/service ne prend pas en charge le flux Delta Chat; la FAQ le distingue explicitement du chatmail et recommande l’icône “email” comme avertissement. Ce sont des comportements documentés par le projet; une analyse de paquets actuelle reste à faire. [FAQ metadata](https://delta.chat/en/help), [FAQ transport/limitations](https://delta.chat/en/help).

### Complément — lecture des rapports complets Delta Chat 2019, 2020 et 2023

#### Include Security / OTF, rPGP + RustCrypto RSA, 2019

- **Organisme / calendrier** : Include Security, audit financé par Open Technology Fund; effort déclaré de 9 jours entre le 3 juin et le 5 juillet 2019, dont 24 heures sur RSA et 48 heures sur rPGP. La copie publique porte encore la mention « CONFIDENTIAL — DRAFT REPORT ». Le test concernait les derniers commits de `master` au 3 juin, mais le PDF ouvert ne donne pas un SHA de commit exploitable dans son corps. Les dépendances de ces bibliothèques n’étaient pas auditées et l’équipe précise que le temps n’était pas exhaustif. [Rapport PDF](https://delta.chat/assets/blog/2019-first-security-review.pdf)
- **Findings** : 10 au total : 2 High, 1 Medium, 5 Low, 2 Informational, aucun Critical. High : récupération de plaintext par erreur de validation du MDC OpenPGP; dépendance `slice-deque 0.1.16` avec vulnérabilité memory-corruption connue, sans analyse d’exploitabilité dans ce mandat. Medium : oracle « quick check » pouvant révéler des octets de plaintext. Low : boucle infinie sur paquet incomplet; clés/messages sensibles potentiellement journalisés; DoS RSA par grosse clé publique; panic sur ciphertext incomplet; chiffrement permis avec une sous-clé dont les flags n’autorisent pas le chiffrement. Info : API ne permettant pas de désactiver/détecter certains paquets sans protection d’intégrité; bibliothèque en développement actif pendant l’audit.
- **Recommandations / remédiation** : réponses de déchiffrement génériques sans plaintext/oracle, mettre à jour les dépendances et intégrer `cargo-audit`, rejeter proprement les paquets incomplets, éviter journaux contenant des secrets, borner les clés/ressources, respecter les key flags. Delta Chat déclare que les deux High ont été corrigés; certains autres problèmes aussi, mais ne publie pas une correspondance exhaustive finding → commit → version → retest dans la FAQ. Le problème quick-check est déclaré corrigé dans rPGP 0.11 en 2024. **Retest externe post-correctif : non établi.** [FAQ audit officielle](https://delta.chat/en/help), [chronologie rPGP 0.11](https://delta.chat/en/2024-03-25-crypto-analysis-securejoin).
- **Lecture bornée** : ce rapport porte sur les bibliothèques crypto de 2019, pas sur les applications actuelles, les serveurs mail, ni sur l’usage en production de chaque finding.

#### Include Security / OTF, Delta Chat Rust core et bibliothèques réseau, 2020

- **Organisme / calendrier / version** : Include Security pour OTF; le rapport décrit un effort de 12 jours du 6 au 21 août 2020, après début d’analyse indiqué au 13 juillet; Delta Chat **1.39.0**. Méthode « standard grey-box », revue des bibliothèques Rust `deltachat-core-rust`, `async-smtp`, `async-imap`, `async-native-tls`, plus tests avec Android et Desktop. Le code Electron et le code spécifique mobile Android/iOS étaient **hors scope**; tests dynamiques limités. Le fuzzing a été utilisé avec parcimonie et le rapport dit que davantage de temps aurait été nécessaire. Pas de SHA de commit disponible dans les passages de cadrage consultés. [Rapport PDF](https://delta.chat/assets/blog/2020-second-security-review.pdf)
- **Findings** : 16 : 6 Medium, 8 Low, 2 Info; aucun High/Critical. Les six Medium sont : (M1) contenu/credentials transmis en clair si le compte est mal configuré sans TLS; (M2) messages, clés, mots de passe email et autres éléments dans SQLite en clair à l’époque, avec risque en cas d’accès au fichier/backup cloud; (M3) exports/backups non chiffrés; (M4) SSRF via URL contrôlée par l’utilisateur; (M5) tromperie par groupe ayant nom/avatar d’un utilisateur; (M6) type de contenu des fichiers non validé, extension falsifiable, pièces écrites automatiquement. Les huit Low : métadonnées en logs/config/local storage même en mode éphémère; CSP desktop autorisant `unsafe-inline`; limites d’envoi mais limites entrantes insuffisantes (DoS); SHA-1 encore sélectionnable/préféré; protections de compilation PIE/RELRO/stack cookie manquantes; usage `unsafe`/déréférencement; homographes; avertissement UI insuffisant sur la perte possible de confidentialité. Les deux Info portent sur une séquence de traversée de chemin théorique (les `/` et `\\` étant normalisés dans le cas décrit) et des considérations de surface d’attaque, trafic et cryptographie post-quantique.
- **Recommandations** : TLS strict et avertissement clair sur le non-chiffré; chiffrement du stockage et exports avec clé robuste/KDF; filtrer les URLs/SSRF; rendre groupes vs conversations individuelles plus distincts; valider type et taille des fichiers; limiter la journalisation et la persistance des métadonnées éphémères; durcir CSP, SHA-1 et flags de compilation, réduire `unsafe`, améliorer l’affichage des noms/alertes.
- **Corrections / retest** : la FAQ actuelle du projet ne prétend pas que tout a été corrigé : elle qualifie les faiblesses Medium de dépendantes de l’environnement, et dit que compatibilité/usabilité empêche d’en atténuer toutes; elle donne des recommandations aux utilisateurs exposés. Aucun tableau de correction finding-par-finding ni retest indépendant post-correctif n’a été trouvé. Ce rapport ancien décrit donc un état historique de 1.39.0, non les builds actuels. [FAQ officielle](https://delta.chat/en/help).

#### Cure53, mail-server template et bibliothèques Delta Chat, 2023

- **Organisme / durée / version** : Cure53; trois testeurs seniors nommés; 10 jours alloués, préparation CW06 et exécution CW07 février 2023; rapport daté du 22 février 2023. White-box sur repositories `mailcow-dockerized`, `mailadm`, `deltachat-core-rust`, `async-smtp`, `async-imap`, `async-native-tls`, `native-tls`, `fast-socks5` et instance de test. Aucun SHA de commit client n’est indiqué dans le rapport. [Rapport PDF](https://delta.chat/assets/blog/MER-01-report.pdf), [annonce de l’équipe](https://delta.chat/en/2023-03-27-third-independent-security-audit).
- **Scope / exclusion** : mail server-template, bot/gestion `mailadm`, dépendances configurées, parties du core Rust, TLS et flux réseau; ce n’est pas l’audit général de toutes les apps mobiles ou de toute infrastructure publique. Le rapport dit avoir validé les configurations SMTP/IMAP/TLS de son setup de test, et son analyse SMTP n’a pas trouvé de downgrade exploitable.
- **Findings détaillés** : huit, annoncés par Cure53 comme quatre vulnérabilités et quatre faiblesses générales : (High) `MER-01-008`, injection de commande shell dans la fonction mailcow Sync Job, exploitable uniquement si une permission supplémentaire est attribuée au compte; (Medium) `MER-01-004`, validation email divergente entre composants, laissant créer des comptes permanents/non supprimés; (Low) `MER-01-003`, DB SQLite desktop non chiffrée et contenant données de connexion; (Low) `MER-01-005`, traversal dans la construction d’une requête API mailcow; (Low) `MER-01-001`, traversal lors de la création QR par nom de token, jugée non exploitable au test car Pillow vérifiait les dossiers existants; (Info) `MER-01-002`, dépendances alors vulnérables/anciennes (`libsqlite3-sys 0.24.2`, `time 0.1.44`); (Low) `MER-01-006`, absence de version TLS minimale explicitement configurée, surtout pertinente pour OS anciens; (Info) `MER-01-007`, base statique de fournisseurs email pouvant inclure des réglages potentiellement faibles ou être altérée.
- **Recommandations / corrections** : validation stricte/unique des adresses et noms de fichiers, corriger l’injection Sync Job (temporairement supprimer XOAUTH2 selon Cure53 si nécessaire), protéger la DB desktop par passphrase, mettre à jour les dépendances avec contrôle automatisé CI, fixer TLS minimum à 1.2, générer et vérifier l’intégrité de la base fournisseurs. Le billet de Delta Chat déclare l’injection corrigée dans une mise à jour mailcow de mars 2023, la commande bot medium corrigée, et les six findings Low/Info « corrigés ou à traiter dans de futures versions » sans correspondance exhaustive publique. Aucun retest indépendant n’est rapporté. Cure53 recommande explicitement une nouvelle évaluation de mailcow.
- **Limite** : le PDF a été lu; contrairement à des résultats sommaires, ce n’est pas un constat que le réseau Delta Chat « n’a pas de vulnérabilités ». L’évaluation a vu un template/instance défini, et non tous les opérateurs, hébergeurs ou déploiements.

## Signal — dossier probatoire approfondi (état au 13 octobre 2026)

Codes de lecture : **FACT** = élément constatable dans les sources consultées; **VENDOR** = déclaration de Signal; **INDÉPENDANT** = recherche/source externe ou vérification indépendante; **INFÉRENCE** = conséquence technique raisonnable; **INCONNU** = non établi. Ce dossier ne prétend pas à un test de binaire, une capture réseau ou un audit de production.

| # | Catégorie | FACT | VENDOR | INDÉPENDANT | INFÉRENCE | INCONNU |
|---|---|---|---|---|---|---|
| 1 | Architecture | Service centralisé; dépôt serveur public servant Android, Desktop, iOS. | Chiffrement des messages/appels, métadonnées minimisées. | Code consultable; pas de vérification de la production. [Repo serveur](https://github.com/signalapp/Signal-Server) | Dépendance à l’opérateur et à son annuaire même si le contenu est chiffré. | Topologie, IAM, configuration, sauvegardes et déploiement prod. |
| 2 | Protocole crypto | X3DH/PQXDH à l’établissement, Double Ratchet, déploiement progressif SPQR/Triple Ratchet. | SPQR ajoute FS/PCS post-quantique hybride; vieilles sessions seront archivées plus tard pour couverture complète. | USENIX 2024 identifie des faiblesses de spec PQXDH v1, puis analyse v2 corrigée; certaines attaques v1 évitées dans le client Signal par encodage et propriété Kyber. [PQXDH](https://www.usenix.org/system/files/usenixsecurity24-bhargavan.pdf), [SPQR](https://signal.org/blog/spqr/) | Le niveau PQ varie selon handshake/session/migration. | Pourcentage des sessions stables actuelles sous SPQR. |
| 3 | Création d’identité | Inscription liée à un numéro de téléphone; clés générées dans client. | Username ponctuel/renouvelable masque le numéro au correspondant, mais n’élimine pas le numéro d’inscription. | Procédure décrite publiquement; aucun flux SMS testé. [Usernames](https://signal.org/blog/phone-number-privacy-usernames/) | Pseudonymat possible vis-à-vis du pair, pas forcément opérateur/partenaire SMS/télécom. | Identité réelle du titulaire dans un cas donné. |
| 4 | Contact discovery | La politique décrit la découverte optionnelle à partir du carnet via des valeurs hachées transmises. | Signal dit que le système protège la confidentialité des contacts. | Design public, mais implémentation réseau courante non testée. [Policy](https://signal.org/legal/) | Import local et upload de carnet sont deux choses distinctes. | Payloads, cache, rétention et réglages effectifs par plateforme/build. |
| 5 | Métadonnées serveur | Politique liste auth tokens, clés, push tokens et données opérationnelles; messages en attente E2EE en queue. | Sealed Sender et groupes privés masquent certains champs sociaux. | Les réquisitions 2026 montrent dates d’inscription et de dernière connexion remises pour six comptes. [Réponse 2026](https://signal.org/bigbrother/district-of-columbia/) | « Métadonnées chiffrées » ne veut pas dire absence d’événements techniques. | Journaux réellement conservés et durée de chaque champ. |
| 6 | IP utilisateur | Les connexions client→service/relais ont une IP source observable à l’endpoint réseau. | Multi-cloud/géodistribué déclaré. [Infrastructure/couts](https://signal.org/blog/signal-is-expensive/) | Pas de DNS/ASN/capture vérifiés durant cette passe. | Opérateur réseau/cloud peut techniquement voir IP et horaires; cela ne prouve pas journalisation longue durée. | Logs réels, association au compte, durée de conservation. |
| 7 | IP exposée au pair | Le fournisseur dit relayer tous les appels 1:1 initiés par un non-contact pour masquer l’IP. | Appels E2EE; relais protège les appels à des inconnus. [Source](https://signal.org/blog/signal-is-expensive/) | Aucun test ICE/paquets réalisé ici. | Risque dépend de type d’appel, réglage, contact et version. | Route effective par OS/version et paramètre « toujours relayer ». |
| 8 | Messages | Politique : contenus E2EE, queue temporaire, historique sur les appareils. | Signal ne peut lire le contenu. | Analyse formelle publiée sur le noyau X3DH/Double Ratchet, pas client complet. [IACR 2016/1013](https://eprint.iacr.org/2016/1013) | E2EE n’empêche pas endpoint/backup/destinataire compromis. | Rétention précise des messages non délivrés. |
| 9 | Groupes | Système de groupes privés et contenu E2EE documentés. | Serveur ne voit pas membres, titre, avatar, attributs en clair. | Papier de conception public; pas d’audit intégration groupe actuelle identifié. [Private groups](https://signal.org/blog/signal-private-group-system/) | Membres et appareils voient localement le graphe. | Champs opérationnels/timing corrélables côté serveur. |
| 10 | Appels | Voix/vidéo E2EE, infrastructure de relais utilisée. | Relais systématique annoncé pour appels aux non-contacts. | Pas de comparaison de captures réseau menée. | Opérateur peut observer session/volume de relais sans nécessairement voir contenu. | Journaux d’appel, métadonnées et routage exact. |
| 11 | Fichiers | Pièces jointes chiffrées et stockées temporairement pour livraison. | Backups ré-encryptent certains médias et ajoutent du padding. | Code ouvert; pipeline média courant non audité dans ce travail. | Destinataire et stockage local voient fichiers; tailles/timing peuvent rester informatifs. | Champs exposés aux serveurs par type de pièce jointe. |
| 12 | Multi-device | Appareils liés ont états/identifiants propres dans les clients. | Modèle client préserve E2EE. | Sources consultables; aucun scénario lien/délien testé. | Appareils liés multiplient copies et surfaces compromises. | Inventaire serveur, journaux de liaison et rétention. |
| 13 | Push | Android actuel inclut Firebase Messaging; manifeste désactive Firebase Analytics, ADID et auto-init FCM par défaut; iOS contient APNs/PushKit entitlements. [Gradle](https://github.com/signalapp/Signal-Android/blob/main/gradle/libs.versions.toml), [manifest](https://github.com/signalapp/Signal-Android/blob/main/app/src/main/AndroidManifest.xml), [iOS entitlements](https://github.com/signalapp/Signal-iOS/blob/main/Signal/Signal-AppStore.entitlements) | Push sert à réveiller/alerter sans texte lisible pour Apple/Google. | Présence de SDK/manifeste confirmée; payloads non capturés. | FCM/APNs peut apprendre token/appareil et moment d’un push. | Payload exact, identifiants, journaux Apple/Google et variantes de build. |
| 14 | Stockage local | Dépendance Android SQLCipher; iOS déclare Data Protection. | Protection par chiffrement local/OS. | Code/entitlements visibles; aucune DB extraite ou forensic actuelle réalisée. | E2EE réseau n’empêche pas accès forensic aux terminaux déverrouillés. | Clés AFU/BFU, WAL, caches, notifications et pièces jointes par version. |
| 15 | Sauvegardes | Secure Backups E2EE, clé de récupération locale; annonces septembre 2026 documentent disponibilité multi-plateforme et options locales. [Bilan](https://signal.org/blog/backup-improvements/), [support](https://support.signal.org/hc/en-us/articles/10074659364122-Backups-and-Device-Transfers-on-Signal) | Serveur ne peut déchiffrer; utilisateur seul possède clé de recouvrement. | Design public; archive courante pas testée indépendamment ici. | Toute copie de clé/terminal déverrouillé augmente durée de persistance des données. | Chiffrement de toutes les variantes/artefacts et rétention exacte de chaque plan. |
| 16 | Analytics / SDK | Dépendances Android incluent FCM; marqueurs manifest désactivent Analytics et collecte ADID. | Signal dit ne pas financer le service par pub/vente de données. | Manifeste observé, trafic non capturé; Apple label reste déclaration éditeur. [App Store](https://apps.apple.com/us/app/signal-private-messenger/id874139669) | SDK présent ≠ collecte active; désactivation explicite ≠ preuve sans inspection binaire. | Crash reporting, SDK transitifs fermés, trafic réel, label courant par pays/store. |
| 17 | Code source | Clients et serveur principaux publics; système anti-spam décrit historiquement comme une partie fermée. | Sources ouvertes aux contributions et revues. | Repos consultables, sans preuve de correspondance de chaque binaire. [GitHub](https://github.com/signalapp), [anti-spam](https://signal.org/blog/keeping-spam-off-signal/) | Il faut auditer client, libsignal, call stack, backend et anti-abus séparément. | Inventaire exhaustif des composants propriétaires déployés. |
| 18 | Builds reproductibles | Guide pour rebâtir tag Android, générer APK adaptés à l’appareil et comparer au binaire installé. [Guide](https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md) | Signal annonce builds Android reproductibles. | Aucune reproduction v8.30.3 exécutée dans cette enquête. | Méthode documentée ne prouve pas tous les builds/personnes ni iOS/Desktop/server. | Résultats tiers récents et couverture de bibliothèques natives. |
| 19 | Supply chain | Gradle liste versions et outils de vérification de dépendances; dépendances incluent libsignal, SQLCipher, FCM, RingRTC. | Workflow vise intégrité des builds. | Fichiers publics; revue transitive complète non faite. | Reproductibilité ne neutralise pas compromission CI, compte mainteneur, outil ou upstream. | SBOM signée, provenance SLSA, signatures tags et résultats dépendances du build exact. |
| 20 | Infrastructure / OSINT | Signal déclare AWS, Google Cloud, Azure et autres, avec réseau réparti; support publie `turn3.voip.signal.org` et `sfu.voip.signal.org` parmi les noms d’appel possibles. [Source](https://signal.org/blog/signal-is-expensive/) | Multi-cloud/géodistribution pour disponibilité et qualité des appels; les noms de relais peuvent changer. | Snapshot DNS/RIPEstat: `signal.org` → Cloudflare AS13335; `sfu.voip.signal.org` → Google Cloud AS396982; `turn3.voip.signal.org` a répondu NOERROR/NODATA pour A/AAAA depuis le résolveur utilisé. [Support](https://support.signal.org/hc/de/articles/360007320291-Einstellungen-f%C3%BCr-Firewall-und-Internet) | Cela attribue seulement les adresses/edges observés; pas la totalité des APIs, du stockage, du routage d’appel ou les origines. | Régions du SFU, hôtes réels de chaque appel, CDN/backend/origines et journaux/sous-traitants actuels. |
| 21 | Juridiction | Organisme américain 501(c)(3); termes et adresse renvoient à Californie, tribunal du Northern District pour litiges contractuels. [Policy](https://signal.org/legal/) | Organisation nonprofit financée par dons. | Déclarations publiques consultées; contrats cloud non disponibles. | Requêtes US applicables à l’opérateur; télécom/cloud/destinataires soumis à juridictions distinctes. | Lieu/loi applicable à chaque copie et sous-traitant. |
| 22 | Demandes policières | Signal publie demandes; des réponses peuvent contenir dates de création/dernière connexion. | Peu de données serveur disponibles, messages/groupes/contacts inaccessibles. | Réponse judiciaire publiée (voir ligne 23). [Portail](https://signal.org/bigbrother/) | Réquisition Signal seule ne couvre pas opérateur télécom, cloud, appareil ou correspondant. | Données d’autres cas non publiés/scellés et rétention non révélée. |
| 23 | Données remises en cas réel | Subpoena DC visait 37 numéros : 7 comptes inexistants, 24 sans donnée responsive pour la période, 6 avec timestamps de création et dernière connexion transmis. | Signal présente cela comme l’ensemble disponible dans ce dossier. | Page primaire publie réponse et documents liés. [Cas du 6 mars 2026](https://signal.org/bigbrother/district-of-columbia/) | Cas prouve ce qui a été remis là, pas absence universelle d’IP/logs dans tous contextes. | Requêtes encore scellées et autres sources d’enquête. |
| 24 | Audits | Analyses académiques protocole (2017, PQXDH 2024); SPQR documente ProVerif et hax/F* sur un sous-ensemble. | Signal dit intégrer preuves formelles dans CI. | Trail of Bits opère un auditeur AKV séparé; ce rôle est validation du journal, pas audit général de Signal. [ToB](https://blog.trailofbits.com/2026/08/11/how-trail-of-bits-helps-verify-the-integrity-of-your-signal-chats/) | Une preuve formelle bornée ≠ audit de l’app/infra complète. | Rapport public exhaustif d’audit indépendant des clients/serveur actuels non trouvé. |
| 25 | Vulnérabilités | Canal de divulgation et acknowledgments publics existent. [Security](https://signal.org/security/) | Signal publie remerciements/corrections. | Aucun CVE ici déclaré actuel sans advisory/version précise. | Nombre de CVE ne mesure pas risque sans version/exposition/patch. | Vulnérabilités privées/non divulguées, inventaire complet upstream. |
| 26 | Recherche académique | Analyse formelle 2017; PQXDH USENIX 2024; recherches Triple Ratchet/SPQR 2025. | Méthodes formelles font partie du développement courant. | USENIX 2024 précise que l’écosystème entier reste à modéliser et que des analyses de ratchet PQ composé restent à faire. [Article](https://www.usenix.org/system/files/usenixsecurity24-bhargavan.pdf) | Preuves concernent des modèles/propriétés, pas UI, OS, backups ou métadonnées. | Analyse indépendante exhaustive de la version et du déploiement courants. |
| 27 | Incidents historiques | Incident Twilio 2022 a permis à un tiers de demander réinscription pour numéros concernés; historique E2EE non déchiffré n’a pas été établi. [Signal support](https://support.signal.org/hc/en-us/articles/4850133017242-Twilio-Incident-What-Signal-Users-Need-to-Know) | Signal a notifié et conseillé de réinscrire/verrouiller le compte. | Établit risque d’usurpation par canal SMS, pas cassage du protocole. | Registration Lock/PIN réduit des risques, pas phishing d’appareil déjà autorisé. | Impact individuel non public pour comptes non nommés. |
| 28 | Gouvernance / financement | Foundation 501(c)(3), Signal Messenger LLC opère le service; dons et dépenses cloud publiés. | Modèle nonprofit, sans publicité. | Statut/publications consultés; audit financier complet non fait. | Incitations commerciales différentes, mais contraintes légales et erreurs subsistent. | Concentration de financements, contrats partenaires et pouvoirs internes. |
| 29 | Censure | Service centralisé; support proxy/Tor documenté selon plateforme. | Accès mondial, sans fournir le numéro au correspondant possible. | OONI a observé des blocages historiques (référencés plus haut), non représentatifs de l’état actuel. [Proxy officiel](https://support.signal.org/hc/en-us/articles/360056052052-Signal-Proxy) | Blocage domaines/IP/stores reste possible; Tor/proxy aide contre certaines formes, pas disponibilité garantie. | Accessibilité depuis chaque pays/réseau en octobre 2026. |
| 30 | Maintenance actuelle | Snapshot GitHub du 13 oct. : Android v8.30.3 stable (7 oct.), v8.31.0/8.31.1 préversions 7–8 oct.; serveur public actif. [Releases](https://github.com/signalapp/Signal-Android/releases), [server](https://github.com/signalapp/Signal-Server) | Releases fréquentes. | Tags et activité publique vérifiables; contribution active par mainteneur, signatures et couverture CI non calculées exhaustivement. | Activité ne prouve ni review indépendante ni absence de vulnérabilités. | Commit serveur effectivement déployé et binaire installé selon canal. |

### Signal — observation DNS/BGP de quelques endpoints (14 octobre 2026)

Résolution via le résolveur configuré localement et interrogation de l’API RIPEstat, environ 00:27–00:29 Europe/Paris (22:27–22:29 UTC le 13 octobre). Le résolveur local n’a pas été identifié. Les résultats décrivent un instantané, non une archive passive ni l’usage réellement observé par un client/appel.

| Endpoint / fonction selon la documentation | DNS observé | Préfixe / ASN RIPEstat | Portée et limites |
|---|---|---|---|
| `signal.org` (domaine du site officiel) | A `104.18.10.47`, `104.18.11.47` (TTL 30 s); AAAA `2606:4700::6812:a2f`, `2606:4700::6812:b2f` (TTL 300 s). | `104.18.0.0/20`, `2606:4700::/44`, AS13335 — Cloudflare. | Le site est servi par des adresses Cloudflare; cela ne cartographie pas les serveurs de messagerie ni l’origine. |
| `sfu.voip.signal.org` (endpoint publié pour appels de groupe / dépannage) | A `34.117.136.13` (TTL 30 s); AAAA `2600:1901:0:e149::` (TTL 250–300 s). | `34.116.0.0/14`, `2600:1901::/32`, AS396982 — GOOGLE-CLOUD-PLATFORM / Google LLC. | Observation compatible avec un endpoint réseau sur Google Cloud; aucune région GCP précise n’apparaît dans ces données. Pas de capture prouvant que les appels courants passent par ce nom. |
| `turn3.voip.signal.org` (nom de TURN publié par le support, qui précise qu’il peut changer) | Pour A et AAAA: réponse DNS `NOERROR` sans réponse (NODATA); le SOA `signal.org` était dans l’autorité. Aucun A/AAAA obtenu au moment de l’observation. | Pas de préfixe/ASN attribuable, faute d’adresse. | Ne prouve pas que le nom n’existe jamais, qu’il est inutilisé, ni que tous les résolveurs voient le même état; c’est le résultat de ce résolveur à cet instant. |

Références de vérification: [support Signal — domaines et ports](https://support.signal.org/hc/de/articles/360007320291-Einstellungen-f%C3%BCr-Firewall-und-Internet), [RIPEstat AS13335](https://stat.ripe.net/AS13335), [RIPEstat AS396982](https://stat.ripe.net/AS396982). Le support Signal distingue appels individuels/groupes et indique que les domaines d’appel peuvent changer; ces DNS ne remplacent pas une capture ICE/TURN sur versions Android/iOS/Desktop exactes.

### Key Transparency / Automatic Key Verification — nouvelle fonction et limites

- **FACT** — lancé le 11 août 2026. Vérification périodique automatique de son propre identifiant; vérification du pair depuis son écran Safety Number. La fonction ne prouve pas qui contrôle en réalité un numéro/username. La doc indique qu’un chat initié via username peut ne pas être vérifiable automatiquement sans numéro du pair. [Signal](https://signal.org/blog/automatic-key-verification/).
- **Auditeurs — clarification** — Signal nomme Cloudflare et Trail of Bits comme auditeurs indépendants; Trail of Bits précise trois signatures requises : instance opérée par Signal, Cloudflare et Trail of Bits. Donc deux auditeurs externes plus le propre auditeur Signal. Clients exigent une tête de journal cosignée dans une fenêtre de 7 jours; ce n’est ni une détection instantanée ni un audit global. [Trail of Bits](https://blog.trailofbits.com/2026/08/11/how-trail-of-bits-helps-verify-the-integrity-of-your-signal-chats/).
- **INDEPENDANT** — ToB dit maintenir un auditeur séparé et ouvert avec son propre état Merkle; ce service vérifie cohérence/append-only du journal, pas le code de tous les clients, les serveurs de messagerie, l’identité humaine ni la configuration de production. Code du service publié : [key-transparency-server](https://github.com/signalapp/key-transparency-server).
- **INCONNU** — rapport d’audit/pentest formel du service AKV, SLO/disponibilité, événements de panne et trafic d’auditeurs non établis ici.

### Inconnues Signal exigeant une preuve expérimentale

1. Comparer par build reproductible un APK stable v8.30.3 réellement installé, en consignant toolchain et couverture des libs natives; relever manifest/permissions/SBOM de ce build exact.
2. Test contrôlé de push, messages en attente et appels contact/non-contact/Tor : DNS, SNI, IP/ASN, destinations, ICE, payloads push, chronologie/volumes visibles par chaque endpoint.
3. Forensics de laboratoire appareil + OS + version app précis, avec états verrouillé/après premier déverrouillage, fichiers SQLite/WAL, caches, notifications, médias, clés, transfert et backup; aucun ancien résultat n’est extrapolable automatiquement.
4. Rapport complet s’il existe sur l’auditeur ToB/AKV et audits actuels clients, serveur, anti-spam et intégration SPQR; une preuve de protocole ne les remplace pas.
5. Mesures passives DNS/CT/ASN à partir d’un réseau autorisé, datées et liées à TTL, IP, anycast/CDN et résolution; aucune mesure de ce type n’est revendiquée ici.

### Signal — matrice des métadonnées (état établi vs capacité technique)

Sens de « fournisseur » : données que le service peut techniquement voir/détenir, pas garantie qu’il les journalise. « Autorités » : voie de contrainte du fournisseur ou du tiers indiqué; cela ne couvre pas une saisie d’appareil. `NON ACCESSIBLE PAR DESIGN` porte seulement sur le serveur Signal en clair, pas sur les terminaux.

| Métadonnée | Fournisseur Signal | Contact | ISP / Wi-Fi | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | **CONFIRMÉ** visible aux endpoints; rétention exacte inconnue. | **POSSIBLE** si appel direct; inconnue hors appel. | **CONFIRMÉ** IP source et destination réseau. | **POSSIBLE** via push/connexion d’app, pas lien compte démontré. | **POSSIBLE** via Signal/ISP selon logs et ordre. |
| Téléphone | **CONFIRMÉ** numéro d’inscription. | **POSSIBLE**; caché par défaut aux personnes qui ne l’ont pas déjà, configurable. | **NON ACCESSIBLE PAR DESIGN** via simple observation IP; opérateur télécom peut l’associer hors tableau. | **INCONNU** lien entre app Signal et compte store. | **CONFIRMÉ** que Signal a remis des timestamps concernant des numéros ciblés en 2026; attribution numéro↔personne peut relever du télécom. |
| Email | **POSSIBLE** si communiqué au support; pas établi comme identifiant obligatoire du compte. | **POSSIBLE** si échangé/partagé par utilisateur. | **NON ACCESSIBLE PAR DESIGN** à partir du seul flux Signal chiffré. | **POSSIBLE** compte store peut contenir email, association Signal non établie. | **POSSIBLE** via support, store ou appareil selon dossier. |
| Identifiant | **CONFIRMÉ** ACI/UUID/numéro et clés pour routage. | **POSSIBLE** profil/username fourni; ACI stable non établi comme visible au contact. | **NON ACCESSIBLE PAR DESIGN** comme identifiant applicatif, mais destination IP visible. | **POSSIBLE** push token/app-instance; mapping vers ACI inconnu. | **POSSIBLE** via réquisition de données existantes ou appareil. |
| Graphe social | **NON ACCESSIBLE PAR DESIGN** en clair selon private discovery/groups/sealed sender; certains événements opérationnels subsistent. | **CONFIRMÉ** relation et membres de groupes où le contact est présent. | **POSSIBLE** inférence temporelle/volumétrique multi-point, pas contenu du graphe directement. | **POSSIBLE** corrélation de push/timing, pas preuve qu’Apple/Google connaît le graphe Signal. | **POSSIBLE** depuis terminaux, témoins ou corrélation externe; Signal déclare ne pas le détenir en clair. |
| Timestamps | **CONFIRMÉ** inscription/dernière connexion disponibles dans le cas documenté 2026. | **CONFIRMÉ** dans l’historique local de conversation/appel reçu. | **CONFIRMÉ** horaires de connexion/volume. | **PROBABLE** horodatage de push ou livraison; payload exact non vérifié. | **CONFIRMÉ** certains timestamps remis dans le cas DC; autres champs/cas distincts. |
| Volumes | **PROBABLE** taille/quantité de blobs ou trafic d’appels observables au service; détail de padding/queue inconnu. | **CONFIRMÉ** taille des médias/messages reçus localement en pratique. | **CONFIRMÉ** octets et durée de flux. | **POSSIBLE** taille/rythme de notifications, payloads non mesurés. | **POSSIBLE** par réquisition de logs réseau/serveur ou appareil si disponibles. |
| Groupes | **NON ACCESSIBLE PAR DESIGN** en clair selon l’architecture privée; pas preuve de zéro fuite latérale. | **CONFIRMÉ** membres, titre et contenu visibles localement aux membres. | **POSSIBLE** corrélations temporelles, pas liste de membres par le seul ISP. | **POSSIBLE** timing push, pas identifiants de groupe établis. | **POSSIBLE** depuis terminaux membres; remise fournisseur en clair non établie. |
| Appareils | **CONFIRMÉ** éléments techniques nécessaires aux sessions/appareils liés; détail de logs inconnu. | **POSSIBLE** inférer appareils connectés par activité, pas inventaire fiable. | **CONFIRMÉ** connexions/adresses par appareil au niveau réseau. | **CONFIRMÉ** push token/device token côté service push; relation au compte Signal exacte inconnue. | **POSSIBLE** via réquisition provider ou saisie. |
| Push tokens | **CONFIRMÉ** la politique Signal cite les push tokens stockés côté service. | **NON ACCESSIBLE PAR DESIGN** au correspondant. | **NON ACCESSIBLE PAR DESIGN** comme token; IP/horaires seulement. | **CONFIRMÉ** FCM/APNs intervient dans le code/entitlements; token traité par service push. | **POSSIBLE** auprès de Signal ou du fournisseur push; remise réelle non établie ici. |

Sources de cadrage : [politique Signal](https://signal.org/legal/), [réponse judiciaire 2026](https://signal.org/bigbrother/district-of-columbia/), [username/visibilité numéro](https://signal.org/blog/phone-number-privacy-usernames/), [manifest Android](https://github.com/signalapp/Signal-Android/blob/main/app/src/main/AndroidManifest.xml), [dépendances Android](https://github.com/signalapp/Signal-Android/blob/main/gradle/libs.versions.toml), [private groups](https://signal.org/blog/signal-private-group-system/).

### Signal — première colonne de la matrice TM1–TM15

Cette colonne est une évaluation d’exposition par modèle, pas une place dans un classement. Les autres produits et colonnes restent à établir; les cellules marquées ❓ ne sont pas remplacées par une hypothèse.

| Modèle | Cellule | Justification probatoire courte |
|---|---|---|
| TM1 — fournisseur curieux | 🟡 | E2EE/private discovery masquent contenu et une partie des relations; compte lié à un numéro, push/auth tokens et quelques timestamps sont disponibles. [Policy](https://signal.org/legal/) |
| TM2 — fournisseur compromis | 🟡 | Le contenu chiffré protège contre lecture simple; endpoint compromis peut retarder/bloquer, observer trafic et tenter substitution de clé; AKV réduit le risque de vue divergente avec fenêtre allant jusqu’à 7 jours. [ToB AKV](https://blog.trailofbits.com/2026/08/11/how-trail-of-bits-helps-verify-the-integrity-of-your-signal-chats/) |
| TM3 — fournisseur malveillant | 🟡 | Transparency log/auditeurs et vérification manuelle de safety number détectent certains changements de clé; ne prouvent pas l’identité humaine, les mises à jour client ou un endpoint compromis. [Signal AKV](https://signal.org/blog/automatic-key-verification/) |
| TM4 — ISP/Wi-Fi/LAN | 🟠 | E2EE masque le contenu, pas nécessairement serveur cible, IP, heures et volumes; proxy/Tor peut déplacer l’exposition, mais aucun test réseau current n’a été fait. |
| TM5 — passif multi-points | 🟠 | Corrélation timing/volumes reste possible malgré sealed sender; les sources consultées n’établissent pas de protection générale contre traffic analysis. |
| TM6 — global passif | 🔴 | Pas de claim/documentation de résistance générale à l’adversaire global; centralisation, numéros et trafic restent des signaux, même si le contenu est E2EE. |
| TM7 — contact malveillant | 🟡 | Le numéro peut être masqué et username partagé sans annuaire, mais profil, messages et médias peuvent doxxer; appel direct dans certains cas peut révéler IP. [Usernames](https://signal.org/blog/phone-number-privacy-usernames/), [calls](https://signal.org/blog/signal-is-expensive/) |
| TM8 — harceleur OSINT | 🟡 | Absence d’annuaire de usernames et réglage « nobody can find me by number » aident; numéro requis à l’inscription et réemploi du pseudo/indices publiés restent corrélables. [Usernames](https://signal.org/blog/phone-number-privacy-usernames/) |
| TM9 — demande judiciaire classique | 🟡 | Résiste à la remise du contenu serveur, mais dates inscription/dernière connexion et données de compte ont effectivement été communiquées pour six comptes en 2026. [Cas DC](https://signal.org/bigbrother/district-of-columbia/) |
| TM10 — enquête policière sophistiquée | 🟠 | Combine données télécom/compte, appareil et artefacts iOS de notifications rapportés en 2026; cela contourne le serveur E2EE sans casser le protocole. Résultats bornés par OS/app/outils dans la section forensics. |
| TM11 — appareil verrouillé | ❓ | Résultats historiques forensics dépendent d’OS/appareil/versions; extraction iOS 2026 a une version et un outil insuffisamment documentés pour généraliser. |
| TM12 — appareil déverrouillé | 🔴 | La base de conversation et fichiers sont accessibles à l’app autorisée et potentiellement aux outils forensic; E2EE réseau ne protège pas un endpoint déverrouillé. |
| TM13 — spyware ciblé / endpoint compromis | 🔴 | Un malware avec accès à l’écran, mémoire ou données après déchiffrement peut lire avant chiffrement ou après déchiffrement; E2EE n’est pas un bouclier d’endpoint. |
| TM14 — supply-chain compromise | 🟡 | Code public et procédure reproductible Android apportent de la vérifiabilité; pas de reproduction actuelle exécutée et iOS/serveur/CI restent des dépendances. [Build guide](https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md) |
| TM15 — censure étatique | 🟠 | Proxy/Tor et réseau relayé peuvent aider certains scénarios, mais service centralisé, domaines/IP/stores restent bloquables; pas de mesure pays actuelle dans cette enquête. [Proxy](https://support.signal.org/hc/en-us/articles/360056052052-Signal-Proxy) |

## SimpleX — dossier probatoire approfondi (état au 13 octobre 2026)

Périmètre : applications SimpleX Chat et réseau SMP/XFTP/XRCP, sans assimiler les serveurs communautaires à l’opérateur de l’application. Dans le tableau, **FACT** désigne une propriété observée dans la documentation/code public consulté, non un test de production; **VENDOR CLAIM** est une déclaration du fournisseur; **INDEPENDENT EVIDENCE** est une publication ou observation tierce; **INFERENCE** est l’analyse qui en découle; **UNKNOWN** signale ce qui n’est pas établi. Les audits publics et leurs limites figurent aussi dans la section [Audits SimpleX](#audits-simplex--écarts-de-périmètre-et-état-2026), déjà renseignée plus haut.

| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | Architecture ouverte à plusieurs opérateurs : clients, relais SMP, relais de fichiers XFTP et services facultatifs; profil local, pas de compte réseau central. [Politique](https://simplex.chat/privacy/), [protocoles](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md) | Le réseau n’attribue aucun identifiant utilisateur global et permet de choisir ou d’héberger ses relais. [Présentation 2026](https://simplex.chat/blog/20260819-simplex-chat-crowdfunding.html) | Trail of Bits a audité l’implémentation réseau/crypto en 2022 et le design de protocole en 2024; ni l’un ni l’autre ne couvre tout le système actuel. | Le choix de relais répartit la confiance, mais ne crée pas un mixnet ni une protection uniforme contre une observation multi-points. | Cartographie exhaustive des opérateurs réellement utilisés par les clients, parts de trafic, déploiements et dépendances exactes. |
| 2. Protocole cryptographique | Double Ratchet avec échange X3DH utilisant Curve448 selon le dossier de sécurité; couches de chiffrement SMP supplémentaires; KEM SNTRUP761 post-quantique disponible dans le protocole, mais optionnel selon version/connexion. [Dossier de sécurité](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/security.md) | Le fournisseur décrit les messages comme E2EE, avec forward secrecy et récupération post-compromission. [Politique](https://simplex.chat/privacy/) | ToB 2024 a identifié des faiblesses de spécification et de session XRCP; les changements v6.1 sont revendiqués dans l’annonce. [Audit résumé](https://simplex.chat/blog/20241014-simplex-network-v6-1-security-review-better-calls-user-experience.html) | « PQ disponible » ne signifie pas que chaque échange de la version installée l’utilise; l’option, le négociateur, la compatibilité et la version comptent. | Négociation réellement observée pour chaque plateforme/version; état de sécurité du protocole complet après l’audit 2026 non publié. |
| 3. Création d’identité | Création locale d’un ou plusieurs profils; pas de numéro/e-mail obligatoire au protocole. Connexion au pair par lien/QR à usage unique; adresse publique longue durée facultative. [Guide](https://simplex.chat/docs/guide/making-connections.html) | Aucun identifiant réseau n’est assigné à l’utilisateur. | La politique précise que le profil ne crée aucun enregistrement de compte sur un relais. [Politique](https://simplex.chat/privacy/) | Absence d’identifiant de compte réduit la jointure côté réseau, pas le risque d’auto-identification par pseudonyme, nom/photo, lien public ou canal d’invitation. | Tests de création et de suppression de profil sur chaque build/store, y compris télémétrie indirecte. |
| 4. Contact discovery | Pas d’annuaire global de numéros ou d’identifiants; découverte par échange de lien/QR; adresses publiques et annuaire de groupes sont des fonctionnalités distinctes/opt-in. [Guide contacts](https://simplex.chat/docs/guide/making-connections.html), [politique Directory](https://simplex.chat/privacy/) | Le fournisseur affirme que personne ne peut contacter un utilisateur sans obtenir son adresse de connexion; les adresses publiques sont un choix. | La politique indique que le bot SimpleX Directory stocke les requêtes de recherche, messages et profils des groupes enregistrés. | L’option « pas d’annuaire » n’implique pas l’absence d’OSINT si une adresse publique ou un lien réutilisé est publié ailleurs. | Fréquence actuelle d’usage de Directory, rétention effective et logs, indexation des noms publics, comportement du client par défaut. |
| 5. Métadonnées serveur | Chaque direction de message utilise une queue avec clés/identifiants propres; une connexion TCP peut transporter plusieurs queues d’un profil par défaut. Les serveurs voient les requêtes, temps, tailles de transport et IP source de leurs connexions. | Les relais préconfigurés disent ne pas journaliser les IP; la politique autorise néanmoins une conservation temporaire d’IP, localisation et session pour défense contre attaques/surcharge. Elle indique aussi que les hébergeurs/réseaux tiers peuvent journaliser des IP. [Politique, §§104–139, 173–181](https://simplex.chat/privacy/) | Aucun audit indépendant de logs de production ou de rétention effective consulté. | Il y a une **tension de formulation** entre « ne journalise pas les IP » en fonctionnement ordinaire et la collecte temporaire permise en exception; « pas de profil/ID » n’équivaut pas à zéro métadonnée de transport. | Quels opérateurs ont activé les logs exceptionnels, critères, durée, mesures anti-corrélation et pratique effective des hébergeurs/CDN. |
| 6. IP utilisateur | Routage privé à deux relais documenté : le client expéditeur passe par un relais/proxy distinct avant le relais de destination; accès direct configurable. [Design de sécurité](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md) | Le relais choisi comme destination ne reçoit normalement pas l’IP source quand le routage privé par défaut est actif; Tor/VPN supplémentaires sont possibles. [Politique](https://simplex.chat/privacy/) | Pas de capture réseau ni mesure DNS/ASN/Tor réalisée dans cette enquête. | Le premier relais connaît l’IP source; le relais de destination connaît son pair réseau immédiat. Un observateur capable de voir entrée et sortie peut tenter une corrélation de temps/volume; routage à deux sauts n’est pas une preuve de résistance à un adversaire global. | Requêtes par version, circuits réutilisés, destination réelle, options « transport isolation », IPv6, DNS, SNI et comportement en panne/fallback. |
| 7. IP exposée au correspondant | Pour les appels, le réglage documenté par défaut utilise un relais TURN; l’option « Always use relay » peut être désactivée pour permettre P2P. [Guide appels](https://simplex.chat/docs/guide/audio-video-calls.html) | Avec relais actif, le pair ne reçoit pas l’IP directe; le relais peut voir IP, timing et durée de l’appel. | Aucun test ICE/capture ni vérification de l’IP vue par un correspondant n’a été exécuté. | Le risque de fuite au correspondant dépend du réglage et d’un éventuel fallback ICE, donc à vérifier sur le build réellement utilisé. | Candidates ICE exactes selon iOS/Android/desktop, appels derrière VPN/Tor, fuites IPv6 ou lors de transition réseau. |
| 8. Messages | Messages E2EE; les paquets sont complétés à 16 Ko selon la politique; les queues serveur gardent les messages non livrés puis suppression après livraison ou 21 jours sur relais préconfiguré. [Politique](https://simplex.chat/privacy/) | Le fournisseur dit que relais et opérateurs ne peuvent lire ni contenu ni taille du message. | L’architecture et la spec sont publiques; pas d’analyse indépendante de paquets actuelle. | Le padding à taille fixe masque une partie de la taille, pas l’activité, le nombre d’envois, le timing ni nécessairement les détails de segmentation/transport. | Vérification effective du padding, exceptions, receipts, logs d’erreur et rétention sur opérateurs tiers. |
| 9. Groupes | Groupes privés/« secret groups » et groupes publics/canaux existent; membres voient nécessairement une partie des membres et du contenu; relais gérés par les clients/réseau. Les canaux sont indiqués expérimentaux/beta. [Groupes](https://simplex.chat/docs/guide/secret-groups.html), [politique](https://simplex.chat/privacy/) | Les groupes privés ne donnent pas au serveur une liste lisible des membres; le fournisseur décrit une topologie sans identifiant global de groupe. | Le protocole d’agent et le modèle de menace sont publics; pas de mesure indépendante des fuites latérales de groupes. | Un membre malveillant peut exporter/capturer le contenu et cartographier les participants qu’il voit; les groupes publics/canaux ont un modèle d’exposition différent des groupes secrets. | Taille maximale et protections réellement actives par version, métadonnées visibles aux propriétaires de relais/canaux, limites anti-Sybil et historique remis aux nouveaux membres. |
| 10. Appels | WebRTC avec chiffrement média documenté; relais TURN prédéfini par défaut, possibilité d’ICE/TURN auto-hébergé et bascule P2P. Appels de groupe non établis comme fonctionnalité générale dans la documentation consultée. L’interface d’appel iOS/Android peut aussi s’afficher écran verrouillé et, selon réglage, accepter sans déverrouiller. [Guide](https://simplex.chat/docs/guide/audio-video-calls.html) | Le relais masque l’IP du contact et observe au moins la durée. | Audit de conception ToB 2024 inclut XRCP/push mais pas une validation exhaustive de chaque stack appel actuelle; aucun test réseau local. | TURN déplace l’exposition de l’IP du pair vers l’opérateur TURN; E2EE média ne masque pas adresse IP, timing, volume ou durée du relais. Une notification d’appel peut exposer nom/photo ou permettre l’acceptation locale selon les réglages. | Codecs, implémentation E2EE par build, journaux TURN en production, appels de groupe et fallback exacts. |
| 11. Fichiers | XFTP découpe les fichiers en chunks de 64 Ko, 256 Ko, 1 Mo ou 4 Mo; relais préconfigurés conservent les fichiers 48 h selon la politique. | Les fichiers sont E2EE et le serveur ne peut connaître leur contenu ou taille exacte. | Le parser ALEAPP indépendant sait lire une base SimpleX si la clé/passphrase est disponible; il n’a pas établi le format de déchiffrement des médias dans son analyse. [Parser](https://github.com/abrignoni/ALEAPP/blob/main/scripts/artifacts/simplexChat.py) | La granularité de chunks et le flux réseau peuvent donner des bornes sur le volume; il faut distinguer contenu illisible et métadonnées de transfert. | Existence/format de previews et fichiers temporaires par OS; chiffrement en transit des chunks au repos sur serveurs tiers; rétention réellement observée. |
| 12. Multi-device | La politique indique qu’un profil copié ne peut pas être utilisé simultanément sur plusieurs appareils sans perturber les conversations; export/import de données documenté. | Le comportement est présenté comme une propriété de sécurité du ratchet. | Les releases et docs distinguent app mobile, desktop et accès à distance; aucune analyse indépendante de toutes les liaisons n’a été faite. | Une copie de profil n’équivaut pas à des appareils liés indépendants avec état et clés séparés. | Exacte distinction actuelle entre transfert, desktop XRCP/remote control, sessions concomitantes et révocation par plateforme. |
| 13. Push | Sur iOS, les notifications instantanées passent par un serveur SimpleX et APNs; le service SimpleX conserve le token et peut compter les queues abonnées et volumes approximatifs par queue; APNs reçoit des notifications chiffrées. [Politique §§129–136](https://simplex.chat/privacy/) | Le fournisseur dit qu’Apple ne voit pas les contacts ni relais d’origine. Android peut fonctionner sans push Google, avec un compromis délai/batterie selon configuration. | Pas de capture push, inspection de payload ou test comparatif sur iOS/Android effectué. | L’option push ajoute une dépendance centralisée Apple + serveur SimpleX et un canal de timing/volume, même si le contenu est annoncé chiffré. | Payloads exacts, durée de rétention, lien token↔profil, notifications locales/écran verrouillé et comportement avec Play Services selon build. |
| 14. Stockage local | Base locale chiffrée; l’app génère un passphrase aléatoire et le conserve via Keychain iOS ou KeyStore Android (TPM disponible selon appareil). Desktop peut conserver le secret de base dans un fichier de configuration si choisi. [Docs confidentialité/sécurité](https://github.com/simplex-chat/simplex-chat/blob/stable/docs/guide/privacy-security.md) | Le chiffrement local protège la DB si l’appareil et le secret ne sont pas accessibles à l’attaquant. | ALEAPP documente l’extraction de messages/contacts à partir de la DB si la clé/passphrase est acquise; deux appareils testés et version exacte non établie dans sa note. | Verrouillage d’écran et chiffrement DB ne sont pas une preuve de résistance aux acquisitions forensiques; l’état du keystore et de l’appareil domine. | Réglages par défaut/build exact, fichiers WAL/journaux, bases historiques non chiffrées, exposition mémoire et secrets d’appareils déverrouillés. |
| 15. Sauvegardes | Export/import de données et passphrase de base documentés; données perdues si app supprimée sans backup; les copies anciennes peuvent désynchroniser certaines connexions. [Gestion des données](https://simplex.chat/docs/guide/managing-data.html) | La sauvegarde chiffrée est sous la responsabilité de l’utilisateur; le fournisseur recommande de la créer et la conserver sûrement. | Pas de vérification de l’archive exportée, du format ou d’un backup OS/cloud dans cette enquête. | La sécurité de la sauvegarde dépend du fichier/export et de son stockage; ne pas assimiler chiffrement de DB active à chiffrement garanti de toutes les copies. | Algorithmes, KDF, secrets inclus, exclusion iCloud/Google backup par version et restauration testée. |
| 16. Analytics / SDK tiers | La politique interdit analytics/tracking dans les clients officiels et autorise des statistiques agrégées côté relais. Le repo et les dépendances sont publics. | L’éditeur déclare que les clients ne partagent pas de tracking et que les relais préconfigurés ne publient pas de stats par personne/IP. [Politique](https://simplex.chat/privacy/) | La fiche Google Play affirme « aucune donnée collectée » selon la déclaration développeur; ce n’est pas un audit indépendant. [Google Play](https://play.google.com/store/apps/details?id=chat.simplex.app) | Une déclaration de store et la présence de code source n’établissent pas l’absence de télémétrie dans le binaire livré ou de logs chez les SDK/OS. | Inspection complète des dépendances, manifestes/permissions Android, privacy label Apple actuel, SBOM et trafic sortant du build store exact. |
| 17. Code source | Code client et serveur publié sous AGPLv3 dans les dépôts SimpleX Chat et SimpleXMQ. [Client](https://github.com/simplex-chat/simplex-chat), [serveur/protocoles](https://github.com/simplex-chat/simplexmq) | Le fournisseur affirme que clients et relais préconfigurés sont compilés depuis le code public sans modification. [Politique §§182–187](https://simplex.chat/privacy/) | Les dépôts, tags, commits et releases sont publiquement consultables. | « Open source » permet l’inspection, mais ne démontre ni que les binaires livrés correspondent au code ni que tous les composants tiers sont audités. | Équivalence exacte app stores, bibliothèques natives, composants Apple propriétaires et infra déployée. |
| 18. Builds reproductibles | Le projet publie une procédure pour reproduire/vérifier les builds; les releases publient des hashes; tag v7.0.4 et beta.6 affichés signés par clé committer vérifiée D53BDFD153C366BA. [Guide](https://simplex.chat/docs/guide/reproducible-builds.html), [releases](https://github.com/simplex-chat/simplex-chat/releases) | L’utilisateur est invité à comparer les binaires reproduits au binaire publié. | Aucun APK/IPA/Desktop n’a été reconstruit ni comparé dans cette investigation; la signature GitHub ne suffit pas à établir la reproductibilité. | Les tags signés et hashes améliorent provenance/intégrité, sans prouver le chemin complet source→build→store. | Résultats de reproduction indépendante récente par OS, toolchains déterministes, provenance CI et correspondance App Store/Play. |
| 19. Supply chain | Dépôt actif avec releases fréquentes, CI visible et fichiers de dépendances; la release beta.6 publie des hashes et un commit signé. | L’éditeur dit que les apps officielles suivent le code public; les modifications réseau AGPL doivent être publiées. | Audit ToB ne couvre pas la totalité de la supply chain actuelle; aucun SBOM/attestation SLSA complète examiné ici. | Risques restants : mainteneur/compte GitHub, action CI, dépendances Haskell/Swift/Kotlin/native, app stores et mise à jour. | Nombre de mainteneurs réellement actifs, revue à deux personnes des composants critiques, signatures de tous artefacts, vulnérabilités de dépendances à l’instant du build. |
| 20. Infrastructure | Réseau multi-opérateur et relais auto-hébergeables; la doc serveur publie notamment les presets mobiles `smp11`, `smp12`, `smp14`. [Serveurs](https://github.com/simplex-chat/simplex-chat/blob/stable/docs/SERVER.md) | Une publication d’août 2026 affirme plus de 1 000 serveurs communautaires, chiffre non audité indépendamment. [Présentation](https://simplex.chat/blog/20260819-simplex-chat-crowdfunding.html) | Snapshot DNS/BGP daté du 14 oct. 2026 : `smp11.simplex.im` a répondu par `23.128.248.121` (AS400226, StormyCloud); `smp12` et `smp14` par `172.234.102.246` et `172.232.141.74` (AS63949, Akamai Connected Cloud/Linode). Les AAAA ont aussi répondu mais leurs préfixes ne sont pas établis dans cette passe. [RIPEstat AS400226](https://stat.ripe.net/AS400226), [AS63949](https://stat.ripe.net/AS63949) | Les presets vérifiés montrent au moins deux opérateurs réseau pour trois noms, sans établir les opérateurs de toutes les instances, leur propriétaire effectif, leurs régions ou le trafic réel. | Topologie effective, hébergeurs/régions par relais, CDN, points concentrés, entités opératrices, logs et trafic réel par opérateur. |
| 21. Juridiction | SimpleX Chat Ltd est une société enregistrée au Royaume-Uni selon sa politique; les relais ont des opérateurs, hébergeurs et pays distincts. [Politique, adresse société](https://simplex.chat/privacy/) | La société dit traiter les demandes légales via due process et ne fournir que le minimum imposé. | Le rapport de transparence est une publication du fournisseur, pas une décision judiciaire indépendante. [Transparence](https://simplex.chat/transparency/) | Le droit applicable à une donnée dépend de la garde réelle (société, relais, hébergeur, Apple/Google, utilisateur), pas uniquement du siège SimpleX Ltd. | Entité contractante par app store, résidences précises de données, sous-traitants, accords et lois applicables à chaque opérateur. |
| 22. Demandes policières | Rapport fournisseur mis à jour le 9 février 2026 : 12 demandes d’autorités en 2025, aucune donnée responsive identifiée/remise selon l’entreprise. [Transparency report](https://simplex.chat/transparency/) | SimpleX affirme n’avoir jamais fourni de données utilisateur en réponse à ces requêtes; données présentes chez un tiers ne sont pas couvertes par cette seule déclaration. | Pas de dossier judiciaire, ordonnance ou production réellement remise par SimpleX identifié dans les sources consultées. | Le résultat décrit le stock détenu par l’entité au moment des demandes, pas ce qu’un opérateur indépendant, Apple/Google, ISP ou appareil pourrait remettre. | Nature juridictionnelle des 12 requêtes, catégories visées, requêtes non comptées, demandes adressées aux serveurs communautaires et cas ultérieurs. |
| 23. Affaires judiciaires connues | Aucune affaire publiquement documentée de remise de contenu ou de données par SimpleX Ltd n’a été identifiée dans cette étape. | L’entreprise se présente comme n’ayant pas eu à livrer de données utilisateur. | Pas de recherche exhaustive par pays/nom d’opérateur/ordonnance; absence de cas trouvé n’est pas preuve d’absence. | La faible identifiabilité serveur rend certains retours impossibles, mais l’utilisateur peut être identifié par endpoint, paiement, lien, hébergeur ou appareil. | Subpoenas sous scellés, saisies d’opérateurs communautaires, demandes d’interception et dossiers étrangers non indexés. |
| 24. Audits | ToB 2022: implémentation (`simplexmq` + app), commits `413aad…` / `07d2c9…`, 4 findings, retest 2023 avec 3 résolus et 1 mémoire non résolu. ToB 2024: revue documentaire du design, commits `d47c…` / `fba0…`, 7 findings. Détails complets plus haut. | En août 2026 SimpleX déclare une assessment ToB 2026 et promet le rapport avant fin d’année; SECURITY.md du 25 mai mentionnait une échéance prévue en juin. | Les PDFs ToB établissent séparément leur cible, méthode et scope; les fixes v6.1 du rapport de design sont décrits par SimpleX, sans fix review public. | Une assessment 2026 non publiée ne constitue pas encore preuve examinable; les rapports 2022/2024 ne garantissent pas versions 2026. | Audit 2026 : versions, commit, exclusions, findings, sévérités, corrections et retest. |
| 25. Vulnérabilités | Audits précédents ont rapporté des findings; 2022: 4 issues, 3 corrections annoncées en v4.2; 2024: 7 findings dans le résumé, 3 améliorations annoncées en v6.1. | Le fournisseur présente le reste comme difficulté élevée, risque résiduel ou limitation de modèle; voir rapport d’audit. | Pas de recherche exhaustive des advisories/CVE/RustSec pour chaque dépendance et plateforme à cette étape; le code public n’est pas un scan de vulnérabilités. | Les sévérités de cabinet, le risque exploitable dans un déploiement et le statut d’un patch sont trois questions différentes. | État exact des findings ouverts, CVE/advisories applicables, fixes liés à commit, retests indépendants et vulnérabilités non publiées. |
| 26. Recherche académique | La politique renvoie notamment aux travaux sur ré-identification de graphes sociaux; cette citation générale n’est pas une évaluation de SimpleX. | Le fournisseur soutient que l’absence d’identifiant rend la corrélation de conversations plus difficile. | Aucune étude évaluant indépendamment le réseau SimpleX en production, son trafic global ou une attaque de corrélation actuelle n’a été identifiée dans le corpus de cette étape. | Les analyses académiques générales sur traffic analysis / anonymisation motivent un test, mais ne démontrent pas la résistance de ce protocole précis. | Bibliographie exhaustive IACR/USENIX/NDSS/ACM/IEEE et résultats reproductibles sur SimpleX. |
| 27. Incidents historiques | Aucun incident public de compromission globale du réseau n’a été confirmé dans cette étape; des findings de sécurité ont néanmoins été publiés dans les audits. | L’éditeur dit n’avoir jamais été requis de donner accès à ses serveurs ou des données dans les textes historiques, puis publie les 12 demandes 2025 en transparence. | Pas de recherche DFIR exhaustive, registre d’incidents ou notification indépendante consultés. | « Aucun incident trouvé » ne signifie pas absence d’incident; panne, censure, bug protocolaire et violation de données sont à distinguer. | Incidents non publics, compromises de relais communautaires, incidents fournisseurs cloud et réponse utilisateur. |
| 28. Gouvernance / société / financement | SimpleX Chat Ltd est l’éditeur commercial britannique; crowdfunding en capital annoncé en août 2026; le réseau compte aussi des opérateurs et contributeurs externes. [Entreprise / campagne](https://simplex.chat/blog/20260819-simplex-chat-crowdfunding.html) | Le projet affirme que le financement communautaire et les options payantes soutiendront un réseau ouvert et diversifié. | La page de campagne est une déclaration du fournisseur; pas d’audit indépendant de gouvernance, cap table ou concentration des mainteneurs consulté. | Le client est libre/AGPL, mais développement, publication, clés de signature et push iOS restent des points de confiance organisationnels. | Bénéficiaires effectifs, répartition financière, droits des investisseurs, gouvernance sécurité et succession des clés. |
| 29. Résistance à la censure | Relais interchangeables/auto-hébergés, adresses .onion et proxy Tor documentés selon plateformes/configuration. [Guide sécurité](https://github.com/simplex-chat/simplex-chat/blob/stable/docs/guide/privacy-security.md) | Le fournisseur présente le réseau sans identifiant et multi-opérateur comme plus résilient à la déplateformisation. | Aucune campagne OONI ni mesure de blocage/censure SimpleX par pays/ASN n’a été établie ici. | Changer de relais/Tor peut contourner certains blocages, mais domaines de découverte, téléchargement, stores, bootstrap, push iOS et disponibilité des pairs restent censurables. | Fonctionnement réel des bridges/obfuscation, résistance DPI, accessibilité des .onion par app/version et résultats par pays/réseau. |
| 30. Maintenance actuelle | Au snapshot du 14 oct. 2026, GitHub liste v7.0.3 comme stable/latest (26 sept.) et v7.1.0-beta.6 publiée le 3 oct.; tags/commits récents sont marqués signature vérifiée Simplex Operations. [Releases](https://github.com/simplex-chat/simplex-chat/releases) | L’éditeur publie régulièrement versions stables/bêta et plateformes Android/iOS/Desktop. | Releases datées et signatures visibles sur GitHub; l’état effectivement servi par chaque store/pays n’a pas été comparé. | Activité récente observable, mais release cadence et signatures ne démontrent pas l’absence de défauts ni déploiement immédiat. | Versions exactes en Play/App Store/F-Droid par région, taux d’adoption, mainteneurs actifs et délai de correctif. |

#### SimpleX — observation DNS/BGP des presets publics

Résolution A/AAAA effectuée le 14 octobre 2026 vers 00:29–00:32 heure de Paris (13 oct. UTC); RIPEstat a servi à rechercher les préfixes/ASN IPv4. Le résolveur DNS utilisé n’a pas été identifié. C’est une mesure active ordinaire de résolution DNS, pas une recherche passive DNS historique, et aucun port n’a été contacté.

| Nom publié par le projet | A observée | AAAA observée | Routage IPv4 RIPEstat au snapshot | Ce que cela établit / n’établit pas |
|---|---|---|---|---|
| `smp11.simplex.im` | `23.128.248.121` | `2602:fc05::121` | `23.128.248.0/24`, AS400226 (StormyCloud Inc.) | Route annoncée vers un réseau StormyCloud à ce moment; pas le propriétaire du serveur ni son emplacement physique. |
| `smp12.simplex.im` | `172.234.102.246` | `2600:3c09::2000:66ff:fe0b:4cb2` | `172.234.96.0/19`, AS63949 (Akamai Connected Cloud/Linode) | Attribution réseau, pas preuve que SimpleX loue directement l’hôte ni d’une région précise. |
| `smp14.simplex.im` | `172.232.141.74` | `2600:3c09::2000:64ff:fe13:e8ca` | `172.232.128.0/19`, AS63949 (Akamai Connected Cloud/Linode) | Même ASN que `smp12` au snapshot; ne prouve pas une administration commune ni les logs du relais. |

Les TTL DNS observés variaient (environ 30 s à 2 h); l’attribution BGP et les réponses DNS peuvent donc changer. Les adresses IPv6 ont été notées, mais leur préfixe/ASN n’est pas reporté ici faute de résultat RIPEstat vérifiable conservé. L’observation n’établit pas les autres services SMP, XFTP/XRCP, API, push, CDN, journaux, localisation ou l’usage effectif d’un compte donné. La policy et les docs réseau restent la preuve de l’architecture déclarée; les observations ci-dessus ne valident pas la rétention annoncée.

### SimpleX — matrice des métadonnées

Ici, « fournisseur » distingue le service SimpleX Chat Ltd des relais tiers choisis; l’ISP voit le trafic réseau, pas nécessairement les données applicatives. « Autorités » signifie données potentiellement accessibles par voie légale auprès de la partie qui les détient, et non remise effectivement constatée.

| Métadonnée | Fournisseur / relais | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | **CONFIRMÉ** aux relais/routeurs connectés; politique dit pas de logs ordinaires mais autorise rétention temporaire défensive et logs des hébergeurs. | **NON ACCESSIBLE PAR DESIGN** via message routé normalement; **POSSIBLE** si P2P appel activé ou hors-app. | **CONFIRMÉ** IP source et adresses des relais; contenu chiffré. | **POSSIBLE** via app store/push; lien avec profil SimpleX inconnu. | **POSSIBLE** auprès de relais, hébergeur, ISP ou téléphone si données existent. |
| Téléphone | **NON ACCESSIBLE PAR DESIGN** comme champ de compte requis. | **POSSIBLE** si communiqué dans le profil/conversation/autre canal. | **NON ACCESSIBLE PAR DESIGN** via seul flux de données; opérateur mobile peut l’associer à l’abonné. | **POSSIBLE** dans compte Apple/Google, sans lien app démontré. | **POSSIBLE** via opérateur, appareil ou carnet d’adresses; remise par SimpleX non établie. |
| Email | **NON ACCESSIBLE PAR DESIGN** comme identifiant SimpleX; **POSSIBLE** au support si l’utilisateur écrit par email. | **POSSIBLE** si partagé dans la conversation. | **NON ACCESSIBLE PAR DESIGN** par le seul transport chiffré. | **POSSIBLE** compte store; corrélation au profil inconnue. | **POSSIBLE** via fournisseur mail, app store ou appareil. |
| Identifiant | **CONFIRMÉ** identifiants/clefs propres aux queues et tokens techniques; **NON ACCESSIBLE PAR DESIGN** pour un identifiant global d’utilisateur revendiqué par le protocole. | **CONFIRMÉ** adresse/lien et code de connexion remis au contact; profil de chat choisi. | **NON ACCESSIBLE PAR DESIGN** en clair comme ID de profil, mais IP/route visibles. | **POSSIBLE** via installation/push; mapping profil↔token non mesuré. | **POSSIBLE** via données détenues, contact, appareil ou saisie. |
| Graphe social | **NON ACCESSIBLE PAR DESIGN** en clair selon design; timing, queues, push et logs défensifs peuvent créer des indices. | **CONFIRMÉ** sur les contacts/groupes qu’il rejoint et profils qui lui sont montrés. | **POSSIBLE** par corrélation multi-points timing/volume, pas par accès direct à la liste de contacts. | **POSSIBLE** par signaux de push/timing; graphe non démontré. | **POSSIBLE** auprès des membres, appareils ou par corrélation multi-sources; aucune remise SimpleX documentée ici. |
| Timestamps | **CONFIRMÉ** comme conséquence des connexions/queues et compteurs de push; durée de stockage inconnue. | **CONFIRMÉ** dans historique local et événements visibles. | **CONFIRMÉ** heures de connexions et volumes. | **PROBABLE** sur événements de livraison push; rétention exacte inconnue. | **POSSIBLE** selon logs du relais, hébergeur, ISP et appareil. |
| Volumes | **CONFIRMÉ** volume de transport; fournisseur dit que le message est paddé et ne révèle pas taille exacte. | **CONFIRMÉ** contenu/taille reçus localement. | **CONFIRMÉ** octets, durée, cadence. | **POSSIBLE** nombre/cadence de push. | **POSSIBLE** via logs techniques/ISP si conservés. |
| Groupes | **NON ACCESSIBLE PAR DESIGN** en clair selon conception des groupes secrets; services expérimentaux/canaux à part. | **CONFIRMÉ** pour les membres du groupe; nouveaux membres peuvent recevoir un historique limité selon réglage. | **POSSIBLE** par analyse de trafic répétée, pas liste directe. | **POSSIBLE** corrélation de push/timing; groupe précis inconnu. | **POSSIBLE** via appareils de membres, relais de canal ou données de trafic disponibles. |
| Appareils | **POSSIBLE** via connexions IP/session et comportement réseau; pas d’inventaire utilisateur connu revendiqué. | **POSSIBLE** à partir des changements d’état, sans inventaire fiable. | **CONFIRMÉ** adresses/connexions par appareil au niveau réseau. | **CONFIRMÉ** token APNs sur push iOS; relation profil exacte inconnue. | **POSSIBLE** via relais/ISP/store/appareil selon conservation et ordre. |
| Push tokens | **CONFIRMÉ** stockés au serveur push SimpleX pour iOS instantané. | **NON ACCESSIBLE PAR DESIGN** au correspondant. | **NON ACCESSIBLE PAR DESIGN** comme token; IP/temps visibles. | **CONFIRMÉ** APNs reçoit la notification chiffrée selon design déclaré; token détenu côté service push/Apple selon fonctionnement APNs. | **POSSIBLE** auprès de SimpleX/Apple si soumis et conservé; remise documentée inconnue. |

### SimpleX — première colonne de la matrice TM1–TM15

Échelle conforme aux définitions de la mission initiale; appréciation provisoire et spécifique aux versions/configurations documentées, pas classement inter-produits. Les cellules 🔴 concernant l’endpoint ne signifient pas que l’E2EE est cassé : elles indiquent que l’adversaire considéré agit après le déchiffrement.

| Modèle de menace | Cellule | Justification probatoire courte |
|---|---|---|
| TM1 — fournisseur curieux | 🟡 | Pas d’identifiant global ni contenu lisible revendiqué, mais IP/temps/volumes, tokens push et rétention défensive potentielle; politique précise les sous-traitants. [Politique](https://simplex.chat/privacy/) |
| TM2 — fournisseur compromis | 🟡 | E2EE et queues distinctes limitent le contenu; un serveur peut observer transport/queues, bloquer ou altérer la disponibilité. Analyse de compromission conjointe de plusieurs relais non établie. [Security design](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md) |
| TM3 — fournisseur malveillant | 🟡 | Clés/lien de connexion établis hors bande et codes de sécurité aident contre substitution de relais; une app/mise à jour malveillante ou endpoint visé reste hors de cette protection. [Guide vérification](https://github.com/simplex-chat/simplex-chat/blob/stable/docs/guide/privacy-security.md) |
| TM4 — ISP / Wi-Fi / réseau local | 🟠 | Peut voir IP des relais, horaires et volumes; Tor/proxy modifie le point visible mais aucune capture actuelle ni preuve d’obfuscation systématique. |
| TM5 — passif multi-points | 🟠 | Le routage à deux relais complique la liaison par un seul relais; deux points d’observation peuvent corréler timing/volume, sans preuve de défense par mixage/délai/couverture. |
| TM6 — adversaire global passif | 🔴 | Pas de preuve de résistance à l’observation globale; routage à faible latence, relais connus et corrélations de trafic restent des signaux. |
| TM7 — contact malveillant | 🟡 | Pas de numéro requis et l’adresse peut être à usage unique; appel P2P si activé, profil, liens externes, capture de contenu et messages partagés restent exposés. [Calls](https://simplex.chat/docs/guide/audio-video-calls.html) |
| TM8 — harceleur / doxxer OSINT | 🟡 | Réduit l’énumération par identifiant public obligatoire; ne protège pas contre réemploi de pseudonyme/photo, adresse publique, liens partagés, paiement ou corrélation hors app. |
| TM9 — demande judiciaire classique | 🟡 | SimpleX déclare 12 demandes en 2025 sans information fournie; IP/logs tiers ou push potentiellement accessibles ne sont pas couverts par cette déclaration. [Transparence](https://simplex.chat/transparency/) |
| TM10 — enquête policière sophistiquée | 🟠 | Peut agréger données ISP/hébergeur/store, saisie d’appareil, contact et OSINT; DB peut être analysée si le secret est obtenu. Aucune extraction universelle actuelle n’est démontrée. [ALEAPP](https://github.com/abrignoni/ALEAPP/blob/main/scripts/artifacts/simplexChat.py) |
| TM11 — saisie d’un appareil verrouillé | ❓ | DB chiffrée et secret via Keychain/Keystore sont des protections documentées, mais aucun test forensic verrouillé sur version/OS/appareil précis n’a été établi ici. |
| TM12 — appareil déverrouillé | 🔴 | Historique et médias doivent être accessibles à l’app; un outil avec accès à la session peut lire les données après déchiffrement. L’E2EE réseau ne protège pas ce cas. |
| TM13 — spyware ciblé / endpoint compromis | 🔴 | Spyware avec accès à l’écran, mémoire, base déchiffrée ou saisie peut capter avant/après chiffrement; pas de protection d’endpoint absolue démontrée. |
| TM14 — supply-chain compromise | 🟡 | Code public, tag/commit signés et procédure de reproduction documentée; aucune reproduction de build ni validation de la chaîne CI/store n’a été faite ici. [Releases](https://github.com/simplex-chat/simplex-chat/releases) |
| TM15 — censure étatique | 🟡 | Relais interchangeables, auto-hébergement et Tor/onion offrent des options; stores, domaines, bootstrap, push iOS, protocole et pairs restent bloquables. Aucune mesure pays/ASN actuelle consultée. |

### Contradictions et questions expérimentales propres à SimpleX

- **Identité** : l’affirmation « aucun identifiant utilisateur » est vraie au sens du protocole/réseau sans compte global; elle ne signifie pas qu’un utilisateur ne peut pas créer une adresse publique ni être identifié par son profil, son lien ou les endpoints.
- **Logs IP** : « preset servers do not log IPs » coexiste dans la même politique avec une possibilité de stockage temporaire d’IP/session/localisation pour défense contre abus et avec les logs d’hébergeurs. C’est une différence entre pratique ordinaire déclarée, exception technique autorisée et collecte sous-traitant, pas nécessairement une contradiction logique; la fréquence et la rétention réelle sont inconnues.
- **Post-quantique** : la KEM PQ est une option de protocole, pas une garantie démontrée de négociation sur toute connexion/appareil.
- **Audit 2026** : « effectué » dans l’annonce d’août; rapport et détails encore non publics au 13 octobre. L’état « scheduled » de SECURITY.md (révision 25 mai) est périmé sur la réalisation, mais reste la dernière page de sécurité de repo consultée.
- **Tests nécessaires** : capture DNS/TLS/IP/IPv6 et corrélation de flux sur deux relais; test appels ICE avec relay on/off; inspection APNs et notifications; reproduction APK/IPA depuis tags signés; inventaire AndroidManifest/permissions et frameworks embarqués; forensic Android/iOS avec build, OS, modèle, état verrouillé, passphrase/keystore, WAL et fichiers; lecture du rapport ToB 2026 dès publication; mesure DNS/ASN/CT passive datée pour les services choisis. Aucun de ces tests n’est revendiqué comme effectué ici.

## Olvid — dossier probatoire approfondi (état au 13 octobre 2026)

Périmètre : applications Olvid grand public et services officiels décrits par l’éditeur. Les certificats ANSSI/Synacktiv cités ci-dessous portent sur des versions 2020–2021 et ne certifient pas les builds 2026. **FACT** signifie constat vérifiable dans un document/code public consulté, pas test actuel de production; **VENDOR CLAIM** reprend une affirmation de l’éditeur; **INDEPENDENT EVIDENCE** désigne une source tierce; **INFERENCE** est la conséquence analytique; **UNKNOWN** n’est pas remplacé par une supposition.

| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | Client multi-plateforme, serveurs de relais, stockage de pièces jointes, notifications, TURN, services de transfert et sauvegarde; les endpoints et certains sous-traitants sont publiés par l’éditeur. [Réseau requis](https://www.olvid.io/faq/for-administrators/) | Les serveurs ne sont pas dans la frontière de confiance cryptographique et ne pourraient ni lire le contenu ni savoir qui parle à qui. [Technologie](https://olvid.io/technology/en/) | L’analyse formelle 2026 modélise le cœur cryptographique, pas l’ensemble du service opéré. [ePrint 2026/1622](https://eprint.iacr.org/2026/1622) | Le chiffrement peut limiter la lecture du contenu sans supprimer l’exposition réseau, IP, disponibilité, push et services tiers. | Architecture complète et actuelle du backend, flux par build et séparation exacte des données sur chaque endpoint. |
| 2. Protocole cryptographique | La spécification publique d’octobre 2024 nomme un protocole « Full Ratchet »; la spécification 2020 et la FAQ plus ancienne décrivent des primitives et protocoles antérieurs. L’éditeur dit employer des clés éphémères à usage unique par message/fichier. [Spécifications 2024](https://olvid.io/assets/documents/2024-10-07_Olvid-specifications.pdf), [FAQ](https://olvid.io/faq/news-questions/) | L’éditeur revendique E2EE, forward secrecy et chiffrement des métadonnées. [Technologie](https://olvid.io/technology/en/) | Terzo et al. (2026) ont formalisé avec Tamarin l’échange authentifié CCCD et le Full Ratchet (FRP), à partir de la spécification et du code Android v3.6; résultats positifs dans leur modèle : authentification mutuelle, secret de clé de session, forward secrecy standard, anti-rejeu, et post-compromise security pour la session FRP modélisée après guérison du canal. Le papier identifie aussi des échecs dans des modèles plus forts (dont eCK/MEX) et des limites de récupération/entropie. [PDF intégral](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf), [ePrint](https://eprint.iacr.org/2026/1622) | Preuve symbolique sous hypothèses de primitives idéales, adversaire actif et éléments modélisés; elle n’est ni une preuve de l’app complète, ni une validation de toutes les garanties de « PCS » ou des versions 2026. | Algorithmes/négociation dans chaque build 2026; conformité exacte de l’implémentation courante, déploiement PQ et portée des propriétés hors modèle. |
| 3. Création d’identité | L’app demande nom/prénom à l’utilisateur, selon sa politique; compte réseau avec numéro ou e-mail non requis d’après l’éditeur. L’identité Olvid et ses clés sont créées localement. [Politique](https://olvid.io/privacy/en/) | Les éléments d’identification restent sur le téléphone et ne sont envoyés qu’aux contacts invités. | Les rapports CSPN de 2020/21 ont examiné des mécanismes d’identité/authentification sur versions précises, pas la création d’identité des builds actuels. [Rapports Synacktiv](https://olvid.io/technology/en/) | Pas de numéro obligatoire réduit la liaison directe à un abonné mobile, mais nom/photo, invitation, achats professionnels, support ou appareil peuvent identifier l’utilisateur. | Génération et stockage des clés en build actuel; suppression effective côté tous appareils, relais, sauvegardes et stores. |
| 4. Contact discovery | La doc d’administration décrit ajout de contacts par invitation distante et annuaire d’organisation; la politique dit que l’app n’accède pas au carnet d’adresses. [FAQ admin](https://www.olvid.io/faq/for-administrators/), [Politique](https://olvid.io/privacy/en/) | Pas d’annuaire public imposé; l’utilisateur choisit les personnes invitées. | Les audits CSPN évaluent l’authentification du contact par des canaux d’introduction précis (QR/e-mail/SMS selon configuration), pas l’ensemble des sources de découverte actuelles. | L’absence d’import du carnet d’adresses réduit une collecte, mais liens d’invitation et annuaire organisationnel restent des surfaces de corrélation. | Télémétrie exacte d’invitation, liens d’annuaire et rétention des requêtes; code/manifests actuels des permissions. |
| 5. Métadonnées serveur | L’éditeur publie de nombreux services réseau (API, WebSocket, transfert, pièces jointes, sauvegarde, TURN, cartes); une ancienne spécification (2020) décrit des échanges d’identité/deviceUID, requêtes et horodatages côté serveur. | La politique actuelle affirme que données et métadonnées sont chiffrées et que l’opérateur ne peut pas voir les interlocuteurs; elle dit aussi que les IP sont utilisées pour le fonctionnement sans être conservées. [Politique](https://olvid.io/privacy/en/) | L’étude formelle 2026 précise que le serveur voit les clés publiques des destinataires nécessaires au routage, tailles et timing des messages; elle indique qu’un opérateur ayant ses propres contacts peut parfois relier une clé publique à une personne. Les CSPN excluaient les serveurs et ne vérifient pas les journaux de production. [PDF, § analyse de confidentialité](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) | « Métadonnées chiffrées » ne masque pas IP, connexion, taille, cadence, service contacté ni tous les identifiants de routage. Les auteurs qualifient l’anonymat cryptographique de pseudonymat dans ce modèle; cela ne prouve pas une identification universelle. | Champs visibles par endpoint et groupe, liens de clés ↔ personnes, traces réellement journalisées/conservées, versions du protocole effectivement déployées. |
| 6. IP utilisateur | Les clients se connectent aux endpoints publiés; certains sont sur AWS/CloudFront/API Gateway, AWS S3, Clever Cloud et Scaleway. [FAQ admin](https://www.olvid.io/faq/for-administrators/) | La politique dit que les IP sont utilisées techniquement mais ne sont ni consultées/collectées ni conservées par Olvid; elle reconnaît que le fournisseur AWS peut voir l’IP. | Aucune résolution DNS/ASN, capture réseau ou mesure de journaux n’a été faite dans cette enquête. | L’ISP voit le trafic vers des endpoints et l’IP source; cloud/CDN peut techniquement traiter l’IP, même sans preuve qu’il la journalise ou l’associe à une identité Olvid. | IPs/CNAME/ASN actuels par région, journaux AWS/CDN et politiques effectives de rétention. |
| 7. IP exposée au correspondant | La documentation publie un service TURN pour appels; l’éditeur décrit le relais d’appels et permet sur Android de configurer son propre TURN. [FAQ admin](https://www.olvid.io/faq/for-administrators/) | Le TURN est conçu pour relayer audio/vidéo; le correspondant ne reçoit normalement que l’IP du relais dans un appel relayé. | Aucun test ICE/STUN ni vérification de l’IP vue par le pair n’a été réalisé. | TURN masque l’IP au correspondant si le flux passe effectivement par le relais, mais expose les IP des deux côtés au fournisseur TURN. | Routage direct/fallback par plateforme et build, candidates ICE réellement échangées, IPv6, VPN et fuite IP au correspondant. |
| 8. Messages | Le serveur API fournit l’envoi/réception et les pièces jointes sont hébergées sur plusieurs services dédiés. L’ancienne spécification décrit une queue jusqu’au retrait par le destinataire. | Le fournisseur affirme que le contenu est E2EE et effacé du relais après récupération; contenus/champs de messages seraient protégés. [FAQ](https://olvid.io/faq/news-questions/) | L’analyse académique 2026 porte sur le cœur cryptographique; elle ne mesure pas les pratiques de rétention ni toutes les couches de messagerie. | Le contenu chiffré ne prouve ni suppression immédiate sur tous les caches/backups ni masquage des tailles et timestamps. | Durée actuelle des messages non livrés, receipts, retries, journaux, caches CDN et fichiers orphelins. |
| 9. Groupes | Les fonctionnalités professionnelles et grand public évoluent; les certificats CSPN anciens ne démontrent pas la sécurité des groupes actuels. | L’éditeur étend ses mécanismes d’authentification et de confidentialité aux discussions; cela doit être lu selon fonctionnalité et version. | Aucun audit indépendant de groupes Olvid actuels ni analyse des métadonnées de groupe n’a été identifié ici. | Un membre voit nécessairement les messages et membres qui lui sont accessibles; le serveur peut encore observer des signaux réseau même si champs groupe sont chiffrés. | Adhésion/retrait, historique, admin, appels de groupe, métadonnées et fuites latérales par version. |
| 10. Appels | Service TURN officiel sur UDP 5349/TCP 443, avec endpoints géolocalisés annoncés; TURN personnalisable seulement sur Android selon FAQ actuelle. [FAQ admin](https://www.olvid.io/faq/for-administrators/) | L’éditeur présente appels audio/vidéo relayés et chiffrés. | Aucun appel n’a été intercepté ou testé; l’audit CSPN iOS/Android cité ci-dessous ne valide pas le service d’appel 2026. | TURN voit au minimum les IP, heures, volumes et durées; E2EE média éventuel ne masque pas ces métadonnées de transport. | Chiffrement média, appels de groupe, enregistrement, journaux TURN, comportement iOS/Desktop, fallback direct et rétention exacte. |
| 11. Fichiers | Les documents d’administration identifient plusieurs backends de pièces jointes; les profils disposent aussi d’un service de sauvegarde séparé. | L’éditeur dit chiffrer les pièces jointes et utiliser des URLs signées/uniques; ses pages techniques revendiquent une clé éphémère par fichier. | Les rapports CSPN 2020/21 incluent le chiffrement de pièces jointes dans le scope des versions mobiles auditées; ils ne couvrent pas le stockage cloud courant dans son ensemble. | Les fournisseurs de stockage peuvent voir connexions, taille, timing et objets; confidentialité du contenu ne garantit pas l’absence de métadonnées, de caches ou de résidus locaux. | Rétention objet, clés et format actuels, noms/mime/hash visibles, aperçu de lien et nettoyage local exacts. |
| 12. Multi-device | Transfert/import de profil sur second appareil documenté via transfer.olvid.io; app annonce synchronisation sans appareil maître. [FAQ admin](https://www.olvid.io/faq/for-administrators/), [Technologie](https://olvid.io/technology/en/) | L’éditeur dit que le service de transfert relaie un profil chiffré. | Les audits de certification anciens ont précédé/limité le multi-appareil courant; aucun audit dédié actuel identifié. | Le multi-device multiplie les endpoints et les copies locales; sécurisation d’un appareil ne sécurise pas les autres. | Clés par appareil, révocation, synchro/rétention, visibilité opérateur du graphe d’appareils et données résiduelles après dissociation. |
| 13. Notifications push | La FAQ liste APNs et FCM pour mobile, WebSocket pour desktop. L’ancienne spec (2020) décrit des masques de push et une charge utile iOS chiffrée. | L’éditeur affirme masquer les identifiants et le contenu sensible aux fournisseurs push. | L’ancienne spécification n’établit pas le payload de chaque version 2026; aucune capture APNs/FCM actuelle. | Apple/Google observent des tokens et horaires; les masques peuvent limiter la liaison au profil, mais doivent être vérifiés en implémentation. | Payload exact, token-service mapping, affichage sur écran verrouillé, APNs/FCM retention, push silencieux et analytics associés. |
| 14. Stockage local | Clients mobiles et desktop sont publics en partie; une ancienne spec CSPN décrit données locales chiffrées, mais elle ne prouve pas le format actuel. | L’éditeur dit que la désinstallation supprime les données personnelles du téléphone. | Analyse formelle 2026 ne porte pas sur une extraction forensique locale; aucune extraction actuelle documentée avec couple OS/app/version ici. | Une session déverrouillée, sauvegarde, notification, fichier partagé ou snapshot système peut produire des artefacts au-delà du stockage DB principal. | Schéma SQLite, clés/KeyStore, WAL, caches, pièces jointes, journaux, notifications et effacement sécurisé par version. |
| 15. Sauvegardes | iCloud/Google Drive sont listés pour sauvegarde de profil; WebDAV automatique est documenté pour Android. [FAQ admin](https://www.olvid.io/faq/for-administrators/) | L’éditeur décrit les sauvegardes de profil comme chiffrées; l’utilisateur peut choisir un serveur WebDAV côté Android. | Pas d’inspection de sauvegarde ni de mesure d’entropie/passphrase par build. | Une sauvegarde élargit la frontière de confiance à Apple/Google/WebDAV et aux secrets de restauration; E2EE en transit n’établit pas le chiffrement au repos ou sa qualité. | Clé, KDF, chiffrement du contenu et métadonnées de sauvegarde, récupération compte store, rétention/versioning. |
| 16. Analytics / SDK tiers | Les endpoints documentés incluent AWS, Clever Cloud, Scaleway, APNs/FCM, iCloud/Drive; l’app peut contacter les sites pour prévisualiser des liens. | Olvid affirme absence de trackers, et que l’app n’accède pas aux contacts/fichiers sans action dédiée. [FAQ](https://olvid.io/faq/news-questions/), [Politique](https://olvid.io/privacy/en/) | Le listing Google Play auto-déclare « aucune donnée collectée/partagée »; pas de vérification APK/manifeste/SDK ou label iOS détaillé faite ici. | Services push/cloud et prévisualisation sont des tiers opérationnels, même s’ils ne sont pas des SDK analytiques. | Inventaire SDK, Firebase, Sentry, crash reporting, telemetry, permissions par build et divergence store/code. |
| 17. Code source | Dépôts officiels iOS/Android publics sous AGPLv3 selon leurs fichiers; Android changelog: 4.5.1 build 311 daté 23 sept. 2026; le moteur Android a été extrait dans un dépôt distinct lors de la série 4.5. Le dépôt serveur officiel `olvid-aws-server` publie des fonctions Lambda pour distribution/transfert, mais indique que des éléments Enterprise/Store sont retirés et que des constantes sont anonymisées. [Android](https://github.com/olvid-io/olvid-android), [iOS](https://github.com/olvid-io/olvid-ios), [serveur](https://github.com/olvid-io/olvid-aws-server) | Le site dit que le code est ouvert et invite à l’examiner. | Le papier 2026 indique que les sources serveur ont été publiées en janvier 2026. Lecture ciblée des dépôts/changelogs seulement : le repo serveur consulté expose un périmètre partiel et n’établit pas que le déploiement de production corresponde à ce dépôt. | Code public améliore l’inspectabilité, mais un dépôt incomplet/anonymisé, les services exploités et les composants Enterprise ne sont pas vérifiables comme un serveur intégralement reproductible. | Complétude exacte du backend, code Enterprise, correspondance déploiement ↔ repo, maintainers actifs et gouvernance de revue. |
| 18. Reproductibilité des builds | Guides de build/CI existent; le build Android par défaut récupère le moteur comme dépendance Maven Central. Le dépôt n’établit pas une reproduction bit-à-bit des binaires Play/App Store; aucune compilation/recomparaison n’a été effectuée ici. [Android build](https://github.com/olvid-io/olvid-android) | Pas de claim précis de reproduction bit-à-bit iOS/Android vérifié dans les éléments consultés. | Le papier académique 2026 cite l’application Android v3.6 et examine le code; cela ne lie pas ce snapshot aux binaires ni aux builds actuels. | Code source, CI vert ou signature store ne suffisent pas à établir que le binaire distribué correspond au commit et aux dépendances publiés. | Correspondance APK/IPA/MSI publié ↔ commit, provenance CI, signatures, SBOM et reproduction par tiers. |
| 19. Supply chain | Le repo Android distingue les variantes `full` (Google/Firebase, Billing, Drive) et `nogoogle`/F-Droid avec dépendances différentes; le moteur est séparé et tiré de Maven Central. Le README indique que les credentials push sont liés à la signature Play officielle. Repo serveur officiel présent mais un seul commit observé lors de la consultation et périmètre partiel. [Android](https://github.com/olvid-io/olvid-android), [serveur](https://github.com/olvid-io/olvid-aws-server) | L’éditeur maintient officiellement les clients, mais pas de preuve que toutes les dépendances/artefacts sont audités en continu. | Lecture ciblée des README/configurations, non audit de dépendances, workflows CI, clés, signatures ou SBOM; les variantes ne sont donc pas équivalentes par défaut. | Stores, Maven Central, Google SDKs, AWS, CDN, cloud de fichiers, push et outils de build forment des maillons distincts du protocole. | Inventaire complet des dépendances et CVE, provenance du moteur publié, rotation/protection des credentials, signatures de tags/releases et correspondance de chaque variant distribué. |
| 20. Infrastructure | La FAQ admin publie endpoints/ports et rôles : API/WebSocket/transfert de profil derrière CloudFront/API Gateway; pièces jointes via AWS S3 ou Clever Cloud Cellar; sauvegardes S3; cartes Clever Cloud, recherche d’adresses Scaleway, TURN et push APNs/FCM. [FAQ admin](https://www.olvid.io/faq/for-administrators/) | La même FAQ annonce trois pools TURN « géolocalisés » et donne des domaines/IP/régions. | DNS A/AAAA et RIPEstat observés le 14 oct. 2026; AWS `ip-ranges.json` mappe les IP publiques de `eu.turn` vers `eu-west-3`, `ap.turn` vers `ap-southeast-1`, `us.turn` vers `us-east-1`. Cela contredit les labels géographiques écrits dans la FAQ pour les deux derniers, pas nécessairement le déploiement actuel; détails ci-dessous. [AWS ranges](https://ip-ranges.amazonaws.com/ip-ranges.json), [RIPEstat AS16509](https://stat.ripe.net/AS16509), [AS14618](https://stat.ripe.net/AS14618), [AS213394](https://stat.ripe.net/AS213394) | Le DNS échantillonné confirme fronts AWS et Clever Cloud, mais pas leur contrat, l’usage par une session, le lieu des données à l’origine, ni la résidence de chaque copie. | Logs, région réellement sélectionnée pour chaque utilisateur, origine CloudFront/API Gateway, prises en charge de fallback, flux exacts, stockages/télémétrie tiers et rétention effective. |
| 21. Juridiction | Éditeur Olvid SAS immatriculé à Paris; politique mentionne AWS et traitement de données de facturation/support. [Politique](https://olvid.io/privacy/en/), [Conditions](https://www.olvid.io/terms/en/) | L’entreprise dit minimiser les données des utilisateurs gratuits et répondre conformément au droit applicable. | Aucune analyse indépendante du contrôle effectif des données par filiale/cloud/juridiction n’a été faite. | Droit français pour l’entité n’exclut pas les pouvoirs légaux du pays du fournisseur/cloud ou du store qui détient certaines données. | Régime contractuel précis de chaque sous-traitant, entité contrôleur par store, conflits de lois et lieu de conservation par flux. |
| 22. Demandes policières | Politique autorise une communication pour demandes légales/réglementaires, décisions judiciaires, subpoenas ou procédures. [Politique, § partage](https://olvid.io/privacy/en/) | L’éditeur soutient que son service de messagerie ne détient pas de données personnelles ou de contenu déchiffrable à remettre; les licences professionnelles impliquent toutefois des données de facturation/support. | Aucun rapport de transparence Olvid, dossier judiciaire, affidavit ou remise réelle de données n’a été identifié dans les recherches de cette passe. | Capacité techniquement accessible (IP côté opérateur, données cloud/store/appareil) ≠ données annoncées ≠ production effectivement remise. | Quels champs ont été remis en cas réel, existence de demandes sous scellés, demandes à AWS/Apple/Google et réquisitions françaises/étrangères. |
| 23. Affaires judiciaires connues | Aucun cas documenté de production Olvid n’a été retrouvé ici; la politique formalise néanmoins la possibilité de répondre au droit. | L’éditeur affirme ne pas avoir de données de messages/interlocuteurs à fournir. | Recherche non exhaustive par dénomination de société, juridiction et fournisseurs; absence de cas retrouvé n’est pas preuve d’absence. | Une réquisition peut viser adresse IP, achat/licence, compte store, hébergeur, appareil ou contact plutôt que contenu. | Dossiers non publiés, saisies d’appareils, ordres visant fournisseurs et demandes d’interception. |
| 24. Audits | Deux évaluations CSPN ANSSI/Synacktiv publiées: iOS Olvid 0.8.2 en 2020 et Android 0.9.2 build 113 en 2021; détails ci-dessous. Une analyse formelle académique distincte du cœur cryptographique a été lue intégralement (2026). | Olvid présente les certifications comme validation de la sécurité de l’app. [Page audits](https://olvid.io/technology/en/) | Les CSPN sont ponctuelles et limitées; le papier académique n’est pas un audit produit ni une certification. | Ces éléments n’établissent pas l’état actuel des clients, serveurs, appels, multi-device ou supply-chain. | Audits complets post-2021 des versions 2026, revues cloud et retests des correctifs revendiqués. |
| 25. Vulnérabilités | Rapports CSPN décrivent notamment usurpation conditionnelle, confusion d’homonymes et rejeu de commitment. Le papier 2026 signale malleabilité de signatures sur valeurs EC non canoniques, DoS persistant par remplissage de la DB (expérience Pixel 4, env. 100 KB/min; Android/build non précisés), et multiplication scalaire non constante via une PoC Flush+Reload sur Java compilé en natif sous Linux x86. | Olvid a indiqué aux auteurs en 2025–2026 prévoir des corrections (constantes, calcul EC constant-time, contrôle des valeurs non canoniques); statut public/version/commit et retest non établis. | Le papier est une analyse indépendante de code Android v3.6, non preuve d’exploitation réelle ou de présence dans les builds actuels. La PoC temporelle n’est pas une exploitation Android de bout en bout. [PDF](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) | Ces résultats montrent des limites crypto et d’implémentation concrètes dans le snapshot étudié; ils ne signifient pas compromission générale ni vulnérabilité actuelle confirmée. | Versions affectées, commits de correction, effet sur iOS/Android actuels, conditions d’attaque et retest indépendant. |
| 26. Recherche académique | Terzo et al. (2026), « Formal Security Analysis of the Olvid Messenger », ePrint 2026/1622, soumis le 5 août et accepté comme contribution CCS 2026; à la date du 13 oct., la conférence (15–19 nov.) n’a pas encore eu lieu. PDF complet et appendices lus. [ePrint](https://eprint.iacr.org/2026/1622), [PDF](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) | — | Modèle Tamarin basé sur la spécification et code Android v3.6 (tag/release `v3.6_263`, SHA non cité); tests symboliques d’authentification/secret/FS/anti-rejeu, plus revue ciblée du code Java. Les auteurs indiquent environ 8–9 mois-personnes de modélisation et 11,5 h de calcul cumulées sur Tamarin 1.10.0; ce n’est pas une durée d’audit en jours-personnes. | Résultats et faiblesses dépendent des hypothèses formelles; le papier ne couvre pas les groupes, la gestion des appareils, sauvegardes, services backend ou tout l’appareil mobile. Une thèse distincte de Padoue examine l’anonymat; son évaluation par les pairs et les détails de réplication restent à distinguer. | Reproduction locale des preuves/PoC, portée exacte des variantes et état des correctifs courants. |
| 27. Incidents historiques | Pas d’incident de compromission globale d’Olvid confirmé dans cette enquête; les papiers CSPN/formel documentent des vulnérabilités et limites, non des incidents de production. | L’éditeur dit ne pas connaître de faille compromise dans son service; non vérifié exhaustivement. | Le papier rapporte divulgation responsable (contact le 2 avril 2025, réunion le 9 avril, réponse écrite le 10 avril; échanges ultérieurs en nov. 2025 et mai 2026) mais ne rapporte pas d’exploitation observée en production. | Absence de notification publique trouvée n’exclut pas bug, panne, incident cloud ou exploitation ciblée. | Historique complet incidents, pannes, compromissions fournisseur, notifications CNIL et réponse de l’entreprise. |
| 28. Gouvernance / société / financement | Olvid SAS est une société française (RCS Paris); pas d’analyse des actionnaires ni des contrats de financement réalisée. [Politique](https://olvid.io/privacy/en/) | L’entreprise présente son origine et sa gouvernance comme indépendantes des serveurs/cloud. | Aucun audit de gouvernance, comptes, investisseurs ou concentration des droits de signature trouvé ici. | Société française ne signifie pas que services, code, clés de publication ou données sont entièrement souverains/locaux. | Bénéficiaires effectifs, financement, contrôle des releases, gouvernance sécurité, succession clés et dépendance fournisseurs. |
| 29. Résistance à la censure | Architecture mobile dépend de domaines API, CDN, push, stockage et TURN publiés; possibilité d’infrastructure entreprise/personnalisée documentée pour certains éléments, mais pas de réseau public décentralisé établi. | L’éditeur revendique la robustesse aux serveurs compromis, pas une résistance mesurée à la censure réseau. | Aucune mesure OONI ou test multi-ISP/pays n’a été faite. | CDN et multiples fournisseurs peuvent améliorer disponibilité ou au contraire concentrer/blocquer des points; chiffrement n’empêche pas le blocage des domaines/IP/stores. | Fonctionnement hors serveurs Olvid, relais de repli, obfuscation, Tor, accès en pays censurés et mesures DPI. |
| 30. Maintenance actuelle | Changelog Android consulté : 4.5.1 build 311 publié le 23 sept. 2026; dépôts Android/iOS et moteur montrent du code public récent. [Android](https://github.com/olvid-io/olvid-android), [iOS](https://github.com/olvid-io/olvid-ios) | L’éditeur distribue des clients mis à jour et annonce l’extraction du moteur Android partagé. | Version/date Android établies dans le changelog; release stable exacte sur chaque store/région et statut iOS non appariés aux binaires ici. | Maintenance récente vérifiable pour Android, mais l’activité du dépôt ne prouve pas la couverture de correctifs, le support serveur ni une cadence homogène. | Versions iOS/Android effectivement installées, délais de patch, nombre de mainteneurs actifs, maintenance du backend et support des anciennes releases. |

### Olvid — observation DNS/BGP et rapprochement des régions annoncées

Snapshot DNS effectué le 14 octobre 2026 vers 00:38–00:39 heure de Paris (13 oct. UTC), avec le résolveur local non identifié; RIPEstat et le fichier IP-range officiel AWS consultés ensuite en lecture seule. Les adresses/TTL ci-dessous sont un point de mesure, parfois avec une rotation A en quelques dizaines de secondes. Aucun port applicatif n’a été contacté. Les régions AWS décrivent l’annonce réseau publiée par AWS, pas à elles seules la localisation de chaque traitement applicatif ou sauvegarde.

| Endpoint documenté | Réponses DNS observées | Routage / région publiée | Observation et limite |
|---|---|---|---|
| `server.olvid.io` (API message) | A: `15.188.206.243`, `15.224.188.72`, `15.224.194.9`; AAAA: 8 réponses sous `2600:9000:274d:*` | A: AS16509, préfixes AWS `15.188.0.0/16` et `15.224.128.0/17` (AWS ranges en `eu-west-3`); AAAA exemple `2600:9000:274d::/48`, AS16509 | Réponses A antérieures, à TTL ~30 s, étaient différentes (`15.188.22.231`, `13.37.97.205`, `13.37.198.59`), preuve d’un pool/rotation court; cela ne révèle pas l’origin applicatif. |
| `ws-server.olvid.io` (notifications WebSocket) | A: `13.39.45.111`, `13.39.58.182`, `15.224.61.60`; 8 AAAA sous `2600:9000:274d:*` | A dans AS16509; AAAA dans AS16509; CloudFront/AWS edge possible d’après docs + plage, pas preuve de la cible d’une session donnée | TTL A ~27 s et AAAA 60 s; pas d’observation de payload push. |
| `transfer.olvid.io` (transfert/appairage profil) | A: `35.180.107.37`, `35.181.73.239`, `15.224.197.197`; pas d’AAAA direct observé | AS16509; préfixes AWS `35.180.0.0/16`, `35.181.0.0/16`, `15.224.0.0/16`, tous `eu-west-3` dans le fichier AWS consulté | Concorde avec un service AWS à ce snapshot; ne montre ni chiffrement de transfert ni contenu des logs. |
| `eu.turn.olvid.io` | A: `35.180.107.30`; pas d’AAAA observé | AS16509; `35.180.0.0/16`, `eu-west-3` (Paris selon AWS) | Cohérent avec l’étiquette `(Paris)` de la FAQ. |
| `ap.turn.olvid.io` | A: `13.214.105.6`; pas d’AAAA observé | AS16509; `13.214.0.0/15`, AWS `ap-southeast-1` (Singapore) | La FAQ actuelle associe pourtant `ap.turn.olvid.io` à « North Virginia »; discordance fournisseur ↔ registre AWS. |
| `us.turn.olvid.io` | A: `3.93.110.92`; pas d’AAAA observé | AS14618 (Amazon AES); `3.80.0.0/12`, AWS `us-east-1` (Northern Virginia) | La FAQ associe pourtant `us.turn.olvid.io` à « Singapore »; discordance fournisseur ↔ registre AWS. |
| `upload.attachments.olvid.io`, `download.attachments.olvid.io` | Les deux renvoient `domain.par.clever-cloud.com` puis un pool A comprenant `91.208.207.214`, `.215`, `.216`, `.217`, `.218`, `.220`, `.221`, `.222`, `.223`; pas d’AAAA numérique observé | `91.208.207.0/24`, AS213394, titulaire RIPEstat Clever Cloud SAS | Le routage public corrobore l’association déclarée par Olvid à Clever Cloud Cellar; ne prouve pas l’isolation/stockage ou le titulaire de données. |
| `olvid-attachment-chunks.s3.eu-west-3.amazonaws.com` | CNAME `s3-r-w.eu-west-3.amazonaws.com`; A `52.95.155.40`, `3.5.205.38` | AS16509; AWS classe les deux préfixes `eu-west-3` et service S3 | Région du service endpoint publiée, pas preuve qu’aucune réplication, logs ou métadonnée ne sort de la région. |
| `olvid-backup.s3.dualstack.eu-west-3.amazonaws.com` | CNAME `s3.dualstack.eu-west-3.amazonaws.com`; A `3.5.205.31`, `52.95.155.61`; AAAA `2a05:d030:2000:80::305:cca9`, `2a05:d030:2000:c0::305:ce4e` | IPv6 exemple dans AS16509; nom d’endpoint et alias AWS indiquent `eu-west-3` | La policy de backup, les ACL, chiffrement et rétention restent à examiner séparément; le DNS ne les établit pas. |

La FAQ indique également `invitation.olvid.io`, `configuration.olvid.io`, `openid-redirect.olvid.io`, `map.olvid.io`, `pelias.olvid.io` et `web.olvid.io`; ces noms n’ont pas été résolus dans ce snapshot. Elle précise que des requêtes vers le site lié peuvent être faites pour récupérer une prévisualisation. L’écart région/étiquette n’est pas résolu par un seul snapshot; répétition depuis plusieurs résolveurs/régions et confirmation du fournisseur seraient nécessaires. Sources: [FAQ réseau Olvid](https://www.olvid.io/faq/for-administrators/), [régions AWS](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html), [fichier AWS IP ranges](https://ip-ranges.amazonaws.com/ip-ranges.json), RIPEstat [AS16509](https://stat.ripe.net/AS16509), [AS14618](https://stat.ripe.net/AS14618), [AS213394](https://stat.ripe.net/AS213394).

### Olvid — audits, certificats et analyse indépendante

Les rapports ci-dessous sont bien les documents PDF publics d’ANSSI/Synacktiv; leurs métadonnées et conclusions ont été extraites des rapports, et non déduites de la seule page marketing. Aucun commit n’est donné dans les rapports; les évaluations portent sur des versions applicatives binaires précises.

| Évaluation | Organisme / date / version | Durée et scope | Exclusions / méthode | Findings, gravité et recommandations | Corrections / retest |
|---|---|---|---|---|---|
| Certification iOS CSPN-2020/30 + RTE public | ANSSI, certificateur; Synacktiv CESTI, évaluateur; rapport daté du 27 avril 2020 / certification signée 18 septembre 2020; Olvid iOS 0.8.2, configuration iPhone 11 iOS 13.4.1, iPhone 8 iOS 13.3, iPhone 7 iOS 13.2.3. [Certificat ANSSI](https://cyber.gouv.fr/sites/default/files/document/2020-09-18%20Rapport%20de%20certification%20ANSSI%20Olvid-0.8.2%20iOS.pdf), [RTE Synacktiv](https://www.olvid.io/assets/documents/Synacktiv-Olvid-CSPN-Olvid-0.8.2-RTE-public.pdf) | 40 jours-personnes; authentification utilisateur et interlocuteur, chiffrement messages et pièces jointes, sauvegarde chiffrée des contacts. Revue de code source, analyse statique et dynamique, recherche de comportements suspects et relecture protocolaire. | Serveur Olvid explicitement hors périmètre; versions ultérieures, appels/multi-device courant et infrastructure non évalués. Deux appareils jailbreakables étaient utilisés pour l’analyse; aucun commit SHA dans le rapport. CSPN est un niveau d’évaluation défini, pas une preuve d’absence de faille. | V-01 usurpation partielle par scénario combinant contrôle réseau et du canal d’introduction, avec probabilité estimée de 10⁻⁴ dans les conditions décrites; attaque complexe, non exécutée, seuil de résistance expert/attaque forte. V-02 confusion d’homonymes, jugée non exploitable, risque d’usage. V-03 rejeu de commitment dans conditions complexes après échecs précédents; impact jugé limité mais amélioration recommandée. Ce ne sont pas des scores CVSS. | Le RTE indique qu’aucun correctif n’a été appliqué à la version évaluée. Aucune preuve publique de retest indépendant sur une version ultérieure n’a été identifiée dans cette passe; recommandations détaillées à l’éditeur, état de V-03 à établir. |
| Certification Android CSPN-2021/12 + RTE v1.2 | ANSSI, certificateur; Synacktiv CESTI, évaluateur; Olvid Android 0.9.2, build 113; certificat 26 mai 2021, RTE v1.2 daté du 2 juin 2021. [Certificat ANSSI](https://www.olvid.io/assets/documents/2021-05-26%20Rapport%20de%20certification%20ANSSI%20Olvid-0.9.2%20Android.pdf), [RTE Synacktiv](https://olvid.io/assets/documents/Synacktiv-Olvid-CSPN_Olvid-0.9.2-RTE-v1.2.pdf) | 35 jours-personnes; fonctions de sécurité analogues : identité/authentification, messages/pièces jointes chiffrés et sauvegarde de contacts. Méthodes CSPN, revue manuelle source, analyse statique/dynamique et tests protocole. | Serveurs hors scope; pas de validation des clients actuels ni des composants séparés depuis 2026. Rapport ne fournit pas de commit source dans les éléments lus. | V-01 possibilité théorique d’usurpation partielle (probabilité 1/10 000 dans scénario construit), nécessitant contrôle du canal de contact QR/e-mail/SMS en plus de la position réseau; serveur seul insuffisant. V-02 homonymie/confusion de contact, non exploitable. Le rapport juge que cela ne réduit pas substantiellement la sécurité globale au niveau évalué; pas de classification CVSS. | Aucun correctif n’était appliqué au build évalué; recommandation de défense autour du contrôle d’introduction et de l’ergonomie d’identité. Pas de retest indépendant post-correction trouvé ici. |
| Analyse formelle académique, hors audit CSPN | Terzo, Cremers, Gonzalez, Schwabe, Yarom et Zhang; « Formal Security Analysis of the Olvid Messenger », ePrint 2026/1622, soumis le 5 août 2026; accepté pour CCS 2026, conférence à venir au 13 oct. [ePrint](https://eprint.iacr.org/2026/1622), [PDF intégral](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf), [artefact lié par les auteurs](https://doi.org/10.5281/zenodo.20647106) | Environ 8–9 mois-personnes de formalisation/modélisation (rapporté par les auteurs), calcul Tamarin 1.10.0 totalisant env. 11,5 h sur Apple M4/24 GB; ces mesures ne sont pas la durée d’un audit. Tamarin et PoC Flush+Reload fournis dans artefact. | Cœur crypto seulement : CCCD et FRP; preuve symbolique Tamarin fondée sur spec/code. Source Android v3.6 tag `v3.6_263`, sans SHA dans l’article. Exclut groupes, gestion d’appareils, sauvegardes, backend, stockage et audit complet du client. Adversaire réseau Dolev–Yao et primitives idéalisées; le PoC local est distinct du modèle formel. | Propriétés établies dans le modèle : authentification mutuelle, secret de clé de session, FS standard, anti-rejeu; KCI/PCS selon protocole et conditions. Limites : échec de modèles eCK/MEX plus forts, absence d’accumulation d’entropie entre certains ratchets; compromis de clés éphémères peut exposer le seed suivant. Revue source : signatures EC non canoniques/malléables; DoS DB persistant (Pixel 4, env. 100 KB/min, build/Android non précisés); deux chemins de multiplication EC non constante. PoC timing vise Java compilé en natif par GraalVM sur Intel i7-10710U / Ubuntu 20.04.6 avec attaquant local/co-résident; pas de démonstration Android réelle ni d’exploitation en production. Pas de tableau CVSS/recommandations de sévérité formelles. | Divulgation responsable aux développeurs en avril 2025; réponse indiquant en nov. 2025 qu’ils prévoyaient du temps pour les correctifs; en mai 2026, les auteurs indiquent qu’une zone a reçu un correctif source et donnent conseils supplémentaires. Les intentions/fix partiel ne précisent pas commits/releases; statut de déploiement et retest indépendant inconnus. Artefact annoncé reproductible, mais non exécuté ici (Tamarin absent de l’environnement). |

**Lecture prudente des audits.** Les CSPN sont des évaluations approfondies de versions mobiles anciennes, avec un serveur exclu et un scope défini; les certificats ANSSI eux-mêmes ne garantissent pas l’absence de vulnérabilités. Les findings V-01 étaient conditionnels et n’ont pas été présentés comme une exploitation observée. Les qualifiers « non exploitable »/« résistance élevée » des évaluateurs ne signifient pas « risque nul ». Pour les versions 2026, la preuve la plus récente indépendante est l’analyse formelle prépublication, qui porte sur un modèle crypto limité. Ni les corrections historiques ni leurs retests ne sont prouvés pour les builds actuels dans ce dossier.

### Olvid — matrice des métadonnées

Statut = possibilité/absence technique d’accès établie par sources publiques, pas preuve d’une remise policière. « Contact » désigne le correspondant; « Apple/Google » inclut stores, APNs/FCM et sauvegardes associées. Les affirmations de politique restent des déclarations fournisseur.

| Métadonnée | Fournisseur Olvid / cloud | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | **CONFIRMÉ** techniquement visible aux endpoints; Olvid affirme ne pas la conserver; AWS peut la voir selon politique. | **POSSIBLE** en appel direct/fallback ou hors canal; appels via TURN sont relayés selon doc. | **CONFIRMÉ** IP source et destination réseau. | **POSSIBLE** via push/store/sauvegarde; lien au profil Olvid non établi. | **POSSIBLE** via Olvid, AWS/CDN, ISP, store ou appareil; aucune production effective trouvée. |
| Téléphone | **NON ACCESSIBLE PAR DESIGN** comme identifiant requis selon éditeur; peut apparaître achat/support. | **POSSIBLE** si partagé hors profil ou dans le chat. | **NON ACCESSIBLE PAR DESIGN** dans le seul payload chiffré; opérateur télécom connaît l’abonné de la SIM. | **POSSIBLE** au compte Apple/Google; mapping Olvid non établi. | **POSSIBLE** via opérateur télécom, store, appareil ou données d’achat. |
| Email | **POSSIBLE** pour support, licence ou correspondance; non requis au compte gratuit selon politique. | **POSSIBLE** si partagé dans invitation/conversation. | **NON ACCESSIBLE PAR DESIGN** par le seul flux chiffré. | **POSSIBLE** au compte store; lien de profil inconnu. | **POSSIBLE** auprès d’Olvid pour compte pro/support, store, mail ou appareil; remise documentée inconnue. |
| Identifiant | **CONFIRMÉ** le serveur voit la clé publique du destinataire nécessaire au routage dans le protocole modélisé; lien avec un nom civil et visibilité exacte en production restent inconnus. [Analyse formelle 2026](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) | **CONFIRMÉ** identité et données de profil communiquées au contact choisi selon l’éditeur. | **NON ACCESSIBLE PAR DESIGN** comme ID de profil applicatif, mais endpoints/IP visibles. | **POSSIBLE** token d’installation/store; mapping profil inconnu. | **POSSIBLE** via données détenues, terminal, licence ou réquisition fournisseur. |
| Graphe social | **PROBABLE** le serveur de routage voit la clé publique destinataire et peut corréler certains échanges; le papier 2026 indique qu’un opérateur ayant ses propres contacts peut relier certaines clés à des personnes. Graphe complet/non propriétaire : non établi. | **CONFIRMÉ** contacts et discussions dont le correspondant est membre. | **POSSIBLE** inférence timing/volume, pas graphe directement depuis une seule ligne. | **POSSIBLE** corrélation de push, sauvegardes et compte; non démontré. | **POSSIBLE** via terminal, contacts, autres membres, opérateur ou corrélation; aucune remise Olvid documentée. [Analyse formelle](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) |
| Timestamps | **CONFIRMÉ** timing des messages/routage visible dans le modèle formel 2026; logs/rétention de production restent inconnus. Connexions, queues, fichiers, push et TURN ajoutent d’autres traces possibles. | **CONFIRMÉ** dans l’historique local. | **CONFIRMÉ** connexion et volume temporel. | **PROBABLE** horodatages de push, sauvegarde et activité store. | **POSSIBLE** chez chaque détenteur si conservés; cas réel non établi. |
| Volumes | **CONFIRMÉ** taille des messages et volume réseau/objets techniquement observables aux relais/cloud; existence et rétention de logs inconnues. | **CONFIRMÉ** messages/fichiers reçus localement. | **CONFIRMÉ** octets et durées de flux. | **POSSIBLE** tailles/fréquences de notifications/sauvegardes selon payload. | **POSSIBLE** auprès du fournisseur/cloud/ISP si logs existent. |
| Groupes | **INCONNU** visibilité exacte du service pour les groupes courants; audit 2020/21 ne couvre pas état actuel. | **CONFIRMÉ** pour les membres du groupe et discussions auxquelles ils ont accès. | **POSSIBLE** corrélation de trafic répétée, sans liste directe. | **POSSIBLE** push/timing; appartenance non établie. | **POSSIBLE** via terminaux/membres ou services ayant traces. |
| Appareils | **CONFIRMÉ** transfert/import d’un second appareil est une fonction et un endpoint dédiés; visibilité des logs inconnue. | **POSSIBLE** par appareils actifs, états et notifications, sans inventaire fiable. | **CONFIRMÉ** IP/connexion de chaque appareil vu au réseau. | **PROBABLE** token APNs/FCM et compte store liés à un terminal, mais mapping Olvid inconnu. | **POSSIBLE** par réquisition de traces, cloud/store ou saisie. |
| Push tokens | **CONFIRMÉ** serveurs APNs/FCM figurent au chemin; liaison token ↔ identité côté backend non vérifiée. | **NON ACCESSIBLE PAR DESIGN** au correspondant selon architecture push. | **NON ACCESSIBLE PAR DESIGN** comme token; IP et timing de connexion visibles. | **CONFIRMÉ** token traité par service push; payload exact actuel inconnu. | **POSSIBLE** auprès d’Olvid/Apple/Google si conservé et légalement demandé; remise effective inconnue. |

### Olvid — première colonne TM1–TM15

Appréciation provisoire et spécifique aux preuves disponibles, pas classement de produits. Les catégories d’endpoint portent sur l’exposition du terminal, pas sur une faiblesse de l’E2EE.

| Modèle | Cellule | Justification probatoire courte |
|---|---|---|
| TM1 — fournisseur curieux | 🟠 | Analyse formelle 2026 : serveur voit clés publiques de routage, taille et timing; les auteurs jugent certaines clés corrélables par un opérateur qui connaît ses contacts. La rétention en production reste inconnue. [PDF](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) |
| TM2 — fournisseur compromis | 🟡 | L’analyse formelle indépendante appuie plusieurs propriétés crypto du cœur, sous modèle symbolique; backend peut observer/retarder/bloquer transport et disponibilités. Elle ne couvre pas tout le service. [ePrint](https://eprint.iacr.org/2026/1622) |
| TM3 — fournisseur malveillant | 🟡 | Authentification hors bande et mécanismes d’identité documentés; les évaluations CSPN anciennes montrent des scénarios conditionnels de spoofing du canal d’introduction et n’auditent pas les releases 2026. [RTE Android](https://olvid.io/assets/documents/Synacktiv-Olvid-CSPN_Olvid-0.9.2-RTE-v1.2.pdf) |
| TM4 — ISP / Wi-Fi | 🟠 | Le réseau voit IP, endpoints, horaires et volumes; aucun test d’obfuscation actuel démontré. [FAQ réseau](https://www.olvid.io/faq/for-administrators/), [analyse formelle](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) |
| TM5 — observateur passif multi-points | 🟠 | Cloud/CDN, push, ISP et clé destinataire/timing peuvent offrir des points corrélables; aucune preuve de défense indépendante générale contre l’analyse de trafic. [FAQ](https://www.olvid.io/faq/for-administrators/), [papier 2026](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) |
| TM6 — adversaire global passif | 🔴 | Pas de mixnet ni résultat de résistance globale établi; architecture faible latence avec endpoints, TURN, push et clouds identifiables. [FAQ réseau](https://www.olvid.io/faq/for-administrators/) |
| TM7 — contact malveillant | 🟡 | Le contact reçoit contenu/profil partagés; TURN-only documenté pour appels masque l’IP du pair mais expose les deux côtés au relais. [Spec appels](https://www.olvid.io/assets/documents/2024-10-07_Olvid-specifications.pdf), [FAQ](https://www.olvid.io/faq/for-administrators/) |
| TM8 — harceleur/doxxer OSINT | 🟡 | Pas de numéro/e-mail obligatoire et pas d’accès carnet revendiqué; nom/photo, invitation, clé stable et réemploi hors app restent corrélables. [Politique](https://olvid.io/privacy/en/), [papier 2026](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) |
| TM9 — réquisition ordinaire | 🟡 | Pas de cas de remise Olvid trouvé; la politique autorise la réponse légale et l’infrastructure/cloud/store/ISP peuvent détenir des catégories distinctes. [Politique](https://olvid.io/privacy/en/), [FAQ réseau](https://www.olvid.io/faq/for-administrators/) |
| TM10 — enquête sophistiquée | 🟠 | Agrégation possible de données AWS/store/ISP, appareils, sauvegardes et contacts; aucune preuve de remise de données Olvid dans un cas public consulté. [Politique](https://olvid.io/privacy/en/), [analyse formelle](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) |
| TM11 — appareil verrouillé | ❓ | Aucun résultat public exact associant outil Cellebrite/GrayKey/Magnet + modèle + OS + build Olvid n’a été établi; les CSPN 2020/21 ne sont pas des tests d’extraction forensic contemporaine. [RTE iOS](https://www.olvid.io/assets/documents/Synacktiv-Olvid-CSPN-Olvid-0.8.2-RTE-public.pdf), [RTE Android](https://olvid.io/assets/documents/Synacktiv-Olvid-CSPN_Olvid-0.9.2-RTE-v1.2.pdf) |
| TM12 — appareil déverrouillé | 🔴 | Le client déchiffre les conversations sur le terminal; l’accès local à l’app/session contourne la protection de transport. L’état DB/artefacts version 2026 reste à mesurer. [Politique](https://olvid.io/privacy/en/) |
| TM13 — spyware ciblé | 🔴 | Un spyware ayant accès à l’écran, mémoire ou processus après déchiffrement peut capturer le contenu; la multiplication scalaire non constante étudiée en 2026 ne prouve pas une infection réelle. [Papier 2026](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) |
| TM14 — supply-chain compromis | 🟠 | Sources clients publiques mais builds distribués non reproduits; backend public incomplet/anonymisé, moteur/Maven, magasins, CI, signatures et cloud restent à auditer. [Android](https://github.com/olvid-io/olvid-android), [backend](https://github.com/olvid-io/olvid-aws-server) |
| TM15 — censure étatique | 🟠 | Plusieurs domaines/API, fournisseurs cloud, push et TURN peuvent être bloqués; aucun mécanisme Tor/bridge ni campagne de mesure pays établi. [FAQ réseau](https://www.olvid.io/faq/for-administrators/) |

### Olvid — contradictions, limites et tests restant à faire

- **Anonymat vs pseudonymat cryptographique** : le papier indépendant 2026 conclut que le serveur voit clés publiques de destinataire, tailles et timing, et que des contacts propres à l’opérateur peuvent permettre de relier une clé à une personne; ses auteurs recommandent de comprendre la propriété comme pseudonymat plutôt qu’anonymat cryptographique. L’équipe Olvid aurait répondu que le terme « anonymat » est employé dans un sens non technique (serveur ne connaît pas nom/contact) et reconnaît que les utilisateurs sont identifiés par clés publiques. Le désaccord porte donc en partie sur la définition, mais les observables réseau/routage restent réels. [PDF](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf)
- **IP** : politique dit IP techniquement utilisée mais non conservée par Olvid; même politique indique qu’AWS peut voir les IP. Cela distingue l’application/opérateur du sous-traitant, mais la durée effective des logs cloud reste inconnue.
- **Certifications** : les CSPN sont réelles et substantielles, mais datent de 2020/2021, évaluent iOS 0.8.2 / Android 0.9.2 build 113 et excluent le serveur. Elles ne sont pas une certification du produit complet actuel.
- **Crypto / PQ** : la page technologie contient encore une formulation ancienne affirmant qu’aucun standard post-quantique NIST n’existe; c’est un indice de contenu vieillissant, pas preuve de l’état crypto courant. Le PDF intégral de l’ePrint a été lu; il reste à lire la spécification 2024 au-delà des éléments extraits et à établir les algorithmes/négociation du build courant.
- **Données effectivement obtenues par police** : capacité/possibilité légale documentée; aucune livraison dans un cas réel identifié. Ne pas transformer le silence de la recherche en « aucune donnée jamais remise ».
- **Tests prioritaires** : (1) relever DNS/CNAME/TLS/ASN et permissions réseau depuis des résolveurs autorisés; (2) capture passive d’un compte de test pour lister domaines, IP, timing/volumes et appels/push; (3) audit manifests/permissions/SDK des versions exactes Play/App Store; (4) reconstruire APK/IPA et comparer aux artefacts signés; (5) test ICE/correspondant et serveur TURN; (6) inspecter sauvegarde iCloud/Drive/WebDAV et DB locale/WAL/fichiers; (7) analyse forensic verrouillée/déverrouillée avec outil + modèle + OS + build Olvid notés; (8) reproduire Tamarin et la PoC localement, sans en extrapoler à Android; (9) retrouver commits/releases et retester les corrections annoncées aux auteurs; (10) rechercher dossiers judiciaires par entité et fournisseurs sans conclure à l’absence depuis les seuls résultats indexés.

## Delta Chat — dossier probatoire approfondi (état au 13 octobre 2026)

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](https://delta.chat/en/help), [core](https://github.com/chatmail/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](https://delta.chat/en/help) | 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](https://delta.chat/ca/privacy), [FAQ](https://delta.chat/en/help) | 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](https://delta.chat/en/help), [privacy](https://delta.chat/ca/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](https://delta.chat/en/help), [policy](https://delta.chat/ca/privacy) | 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](https://delta.chat/en/help), [core](https://github.com/chatmail/core), [privacy](https://delta.chat/ca/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](https://delta.chat/ca/privacy) | 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](https://delta.chat/en/help) | 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](https://delta.chat/en/help) | 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](https://delta.chat/en/help), [privacy](https://delta.chat/ca/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](https://delta.chat/en/help) | 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](https://delta.chat/en/help) | 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](https://delta.chat/en/help), [privacy](https://delta.chat/ca/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](https://delta.chat/en/help) | 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](https://delta.chat/en/help), [API](https://rs.delta.chat/deltachat/imex/index.html) | 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](https://delta.chat/en/help), [policy](https://delta.chat/ca/privacy) | 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](https://github.com/chatmail/core), [Android](https://github.com/deltachat/deltachat-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](https://f-droid.org/en/packages/com.b44t.messenger/), [core](https://github.com/chatmail/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](https://delta.chat/en/help), [core](https://github.com/chatmail/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](https://chatmail.at/relays), [FAQ](https://delta.chat/en/help) | 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](https://delta.chat/ca/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](https://stat.ripe.net/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](https://delta.chat/en/help) | 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](https://delta.chat/en/help) | 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](https://github.com/chatmail/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](https://github.com/chatmail/core), [Android releases](https://github.com/deltachat/deltachat-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](https://chatmail.at/relays), [FAQ Delta Chat](https://delta.chat/en/help), [politique vie privée](https://delta.chat/ca/privacy), [RIPEstat AS24940](https://stat.ripe.net/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. |
| Email | **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](https://delta.chat/en/help) |
| 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](https://delta.chat/en/help) |
| 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](https://delta.chat/en/help) |
| 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é.

## État d’audit Delta Chat — distinction probatoire

La documentation fournisseur répertorie les audits et confirme plusieurs correctifs; cela établit un **Vendor Claim** appuyé par historique public de releases, pas le fait qu’un tiers ait retesté chaque fix sur chaque plateforme. Pour les audits 2019/2020/2023 examinés ici, aucune durée exacte de retest ni aucun rapport de retest indépendant n’a été trouvé. L’analyse ETH 2024 constitue une vérification séparée : les chercheurs ont relu les patchs SecureJoin et ont écrit ne pas avoir trouvé de défaut dans ces patchs; ceci ne reteste pas tous les findings des audits précédents.

## Briar — dossier probatoire approfondi (état au 13 octobre 2026)

Périmètre principal : Briar Messenger Android 1.5.21; Briar Mailbox est une application compagnon distincte. Briar Desktop demeure une bêta distincte, avec cadence différente. **FACT** = document/code public consulté, pas essai actuel; **VENDOR CLAIM** = déclaration Briar; **INDEPENDENT EVIDENCE** = étude/audit tiers; **INFERENCE** = analyse; **UNKNOWN** = non établi.

| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | P2P store-and-forward/synchronisation directe entre appareils, via Tor sur Internet ou Bluetooth/Wi‑Fi/mémoire hors ligne; pas de service central classique. Briar Mailbox optionnelle est un téléphone Android d’utilisateur qui garde temporairement les messages chiffrés. [Architecture](https://briarproject.org/how-it-works/), [Mailbox](https://www.briarproject.org/mailbox/) | Pas de serveur central; données de compte et contacts restent sur appareils. [Politique](https://briarproject.org/privacy-policy/) | ETH Zurich a décrit BQP/BRP/BHP/BTP/BSP et leurs clients en 2023; l’étude conseille encore d’analyser le trafic et Briar Mailbox. [Étude](https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/education/theses/report_YuanmingSong.pdf) | La décentralisation élimine une base centrale riche, mais chaque contact et Mailbox déployée constituent des endpoints qui peuvent observer/être saisis. | Topologie réelle, protocoles actifs par version et transports, comportement Mailbox face à pair malveillant ou hors ligne. |
| 2. Protocole cryptographique | BQP v4 (code/spec courant à contrôler) utilise échange X25519 éphémère et commitment QR; analyse ETH décrit BLAKE2b-256 et Ed25519 identité/signature; BTP transporte avec chiffrement/authentification et rotation périodique des clés. BHP handshake historique 1.4.20 remplacé par un handshake corrigé en 1.5.3. [ETH](https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/education/theses/report_YuanmingSong.pdf), [correctif éditeur](https://briarproject.org/news/2023-three-security-issues-found-and-fixed/) | Chiffrement E2EE et rotation de clés visent la forward secrecy. [Comment ça marche](https://briarproject.org/how-it-works/) | Étude ETH 2023 a trouvé absence de FS dans l’ancien BHP; l’éditeur confirme un design défectueux mais dit que Tor v3 empêchait l’écoute du scénario pratique, puis remplace le handshake en v1.5.3. Aucun retest indépendant actuel n’est établi ici. | Ne pas réduire « BTP rotation a FS » à « tout échange est FS » : le handshake initial fournit la clé racine et a dû être corrigé; la version de protocole et la voie QR/distance comptent. | État exact BHP v1 actuel, comparaison code 1.5.21/commit aux patchs; politiques de rotation/durée de clés par transport; preuves formelles récentes. |
| 3. Création d’identité | Un compte local se crée avec pseudonyme et mot de passe; téléphone/e-mail non requis. Pas de cloud recovery ou transfert de compte selon le manuel. [Manuel](https://briarproject.org/manual/) | Le compte est gardé sur l’appareil et supprimé avec désinstallation, selon policy/manuel. | Le travail ETH 2023 décrit clés d’identité/signature locales, mais sa version de départ est antérieure aux releases courantes. | Pseudonyme local limite l’identité déclarée au service; l’adresse publique Briar Link contient une clé et peut être diffusée/corrélée à un profil ailleurs. | Entropie effective du mot de passe, clés et KDF dans build courant, effacement réel après désinstallation et traces de l’OS. |
| 4. Contact discovery | Aucun annuaire public. Ajout par QR réciproque en personne ou échange out-of-band d’un lien Briar; introduction par un contact mutuel également possible. [Manuel](https://briarproject.org/manual/) | Les contacts ne sont pas recherchables par nom; QR local garantit l’identité de la personne qui scanne si users vérifient physiquement. | Étude ETH signale qu’une introduction malveillante sans vérification hors bande peut créer MITM, problème connu; la liaison QR est plus forte si les écrans sont échangés de visu. [Étude](https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/education/theses/report_YuanmingSong.pdf) | Link à distance est un bearer-ish public key d’invitation, pas annuaire anonyme: partagé publiquement, il peut associer pseudonyme et futurs contacts. | Étapes exactes d’acceptation, révocation de liens et comportement après changement d’identité selon version actuelle. |
| 5. Métadonnées serveur | Pas de serveur central exploité pour les comptes/messages usuels; les relais Tor et nœuds réseau voient certains flux; une Briar Mailbox donne un point de conservation chiffré contrôlé par l’utilisateur. | Le projet affirme ne pas avoir accès au contenu ni aux métadonnées de communications; crash reports/feedback seulement opt-in. [Politique](https://briarproject.org/privacy-policy/) | Aucune mesure de production ou inspection indépendante des relais Tor/mailsboxes n’est effectuée ici. | La politique s’applique au projet, pas aux journaux d’ISP/Tor, au device pair, à la Mailbox utilisateur, ni à un terminal saisi. | Données observables par chaque nœud Tor et Mailbox, métadonnées locales/offline et temps de conservation. |
| 6. IP utilisateur | Internet se connecte via Tor selon la documentation; utilisateur peut activer bridges, désactiver Internet ou limiter aux réseaux locaux. [Manuel réseau](https://briarproject.org/manual/) | Le projet dit Tor protège utilisateurs et relations contre surveillance, et cite les bridges contre blocages. | Pas de capture réseau, identification du guard, DNS ni analyse du chemin réel par version dans cette enquête. | Un ISP voit une connexion Tor/bridge et volumes/horaires, mais pas normalement le pair final; le guard Tor voit l’IP source; observation corrélée multi-points reste possible. | Comportement exact fallback Tor, bootstrap/bridge transports, IPv6, empreintes, mises à jour onion et réseau sur Briar 1.5.21. |
| 7. IP exposée au correspondant | Connexion distante annoncée via Tor, dont des services onion/hide services; ajout de contact offline via QR utilise transports courts. | Le fournisseur revendique empêcher l’observateur Internet de savoir quels utilisateurs se parlent. [Architecture](https://briarproject.org/how-it-works/) | Aucun test de l’IP vue par un correspondant, d’un pair malveillant ou de transfert Mailbox n’a été fait. | Sur le chemin Tor courant le pair ne devrait pas obtenir l’IP publique directe; contact local apprend proximité physique/radio, et une configuration Mailbox ou bug de routage peut changer les points observés. | Candidats/transport et IP pair sur chaque client/option et version; adresse exposée pendant setup, crash ou fallback. |
| 8. Messages | Messages E2EE; quand le pair est offline, livraison attend la prochaine rencontre réseau sauf Mailbox auxiliaire. [Manuel](https://briarproject.org/manual/), [Mailbox](https://www.briarproject.org/mailbox/) | Message stocké sur l’appareil; Mailbox aide à livrer les messages chiffrés offline. | ETH 2023 analyse le sync BSP; Cure53/ROS 2023-24 tests app Android/desktop mais pas la version 2026. | Pas de cloud central réduit conservation serveur; la disponibilité dépend de contacts en ligne, stockage local ou d’une Mailbox persistante. | Disappearing messages actuels, tombstones, retries, données dans mailbox chiffrées/non chiffrées et purge après livraison. |
| 9. Groupes | Messages privés, groupes privés, forums publics et blogs. Groupes privés : créateur seul peut inviter, membres peuvent quitter; forums ont membres plus ouverts; posts group/forum/blog signés, qui change le modèle de deniability. [Manuel](https://briarproject.org/manual/), [audit ROS](https://www.opentech.fund/security-safety-audits/briar-security-audit/) | La synchro P2P chiffre le transport et stocke chaque réplica chez membres/subscribers; pas de serveur de groupe central. | ETH 2023 a démontré un défaut historique de duplication de messages signés dans groupes/forums/blogs; éditeur dit corrigé en v1.4.22. ROS 2023 a signalé les limites de dénégation peu documentées. | Un membre compromis/hostile peut observer et copier les données qu’il reçoit; forums/blogs publics ne sont pas équivalents aux chats privés. | Modèle exact de membership/expulsion, historique, anti-Sybil, protections contre corrélation et version actuelle de la correction. |
| 10. Appels | Aucune fonctionnalité vocale/vidéo Briar actuelle établie dans les manuels/docs consultés. | — | Les documents de version/site parlent messages, groupes/forums/blogs, pas appels. | Ne pas attribuer à Briar le modèle IP d’appel d’une autre app. | Toute fonction expérimentale/desktop non publiée ou plugin externe. |
| 11. Fichiers | Photos/images sont partagées selon release Android v1.3; la mise à jour de maintenance 2026 cite encore « file attachments » parmi les fonctions manquantes, ce qui suggère que partage générique de fichiers reste absent ou limité. [Release 1.3](https://briarproject.org/news/2021-briar-1.3-released/), [maintenance 2026](https://briarproject.org/news/2026-maintenance-mode/) | Les contenus échangés utilisent E2EE, y compris médias pris en charge. | Pas d’inspection du format image/médias ni de l’historique exact de pièces jointes current. | Photos reçues peuvent être copiées ou extraites localement; « fichier » non pris en charge doit être séparé de l’image intégrée. | Extensions, taille/metadata, fichiers arbitraires, cache galerie, sauvegarde et rétention. |
| 12. Multi-device | Le compte ne peut pas être restauré ou transféré selon le manuel; Briar Mailbox est appareil auxiliaire connecté au compte par QR mais n’est pas une seconde interface de chat complète. Desktop existe en beta séparée. | Les données restent locales et le compte perdu si appareil/password perdu. | Aucun audit de réplication multi-device actuel; ETH 2023 indique pas de backup/transfert dans son snapshot. | Pas de multi-device classique réduit copies serveur mais rend perte d’appareil irréversible; Mailbox crée une copie d’infrastructure utilisateur supplémentaire. | État 2026 de fonctionnalités preview desktop, compatibilité Android↔Desktop et gestion de révocation. |
| 13. Notifications push | Pas d’APNs/FCM de messagerie identifié; réception Internet dépend du service Briar en arrière-plan; Mailbox peut rester en ligne sur appareil séparé. | Projet positionne l’absence de serveur/push central comme protection et reconnaissance d’une limite de batterie. | Pas de manifeste Android actuel ni capture de wake-up/FCM faites; documentation permissions ancienne. | Pas de token central réduit exposition Apple/Google, mais OS, fabricant Android et données réseau de l’app restent observables. | Dépendances Play services dans version courante, notification locale, FCM éventuel et permissions Android exactes. |
| 14. Stockage local | Identité, clés, contacts, messages sont stockés localement; base annoncée chiffrée et verrou app disponible avec password/PIN device. [Manuel](https://briarproject.org/manual/), [audit Cure53 2017](https://briarproject.org/raw/BRP-01-report.pdf) | Compte reste sur appareil et n’est pas récupérable depuis le cloud. | Oxygen Forensic Detective v16 a annoncé « brute-force passcode for Briar app » sur extractions full filesystem, mais sans modèle Android/Briar précis dans les lignes consultées; ce n’est pas une preuve d’extraction universelle. [Oxygen v16 notes](https://oxygenforensics.com/uploads/press_kit/OFDv160ReleaseNotes.pdf) | Le chiffrement au repos dépend du secret/device/Android FBE; accès appareil déverrouillé ou bruteforce ciblé peut exposer les DB; sécurité cryptographique réseau ne suffit pas. | Schéma/encryption actuelle, key derivation, WAL/tempfiles, extraction par Cellebrite/GrayKey/Magnet et combinaison exacte tool+OS+app. |
| 15. Sauvegardes | Le manuel dit pas de recovery/backup de compte; maintenance 2026 cite l’absence de backup comme problème de produit. | Perte de l’app, device ou password peut rendre le compte irrécupérable. | Aucun dump/bac forensic de la version actuelle analysé. | Avantage pour limiter une copie centrale, coût opérationnel élevé et risque de perte de données. | Possibilité de backup Android OS/cloud automatique, exclusion `allowBackup`, export et résidus. |
| 16. Analytics / SDK tiers | Feedback/crash reports sont envoyés uniquement sur action/choix et chiffrés; web server logs visits 7 jours selon privacy. [Privacy](https://briarproject.org/privacy-policy/) | L’éditeur dit ne collecter ni usages ni identités hors feedback/crash choisis. | Aucune inspection SDK/manifest APK actuel; ancien wiki permissions cite ACRA et permission READ_LOGS, historiquement. [Permissions wiki historique](https://code.briarproject.org/briar/briar/-/wikis/permissions) | Opt-in diagnostics peuvent contenir device/email si ajoutés; la version actuelle doit être comparée à wiki 2021 avant d’affirmer présence/absence d’ACRA. | Trackers, Firebase, Sentry, crash frameworks, destination réseau et permission manifest v1.5.21. |
| 17. Code source | Client Android GPLv3 public; specs et code du core publics; GitHub est miroir du GitLab source officiel. Desktop/Mailbox composants distincts. [Source](https://code.briarproject.org/briar), [miroir](https://github.com/briar/briar) | Le projet publie source et procédures de reproduction. | ETH/Cure53/ROS inspectent versions précises, pas chaque release. | Code ouvert facilite review mais attention aux dépôts sous-projets, pins Git submodules, code CI et APK store. | Mainteneurs actifs au 13 oct., branches de sécurité, commits security-hidden, dépendances et provenance du binaire release actuel. |
| 18. Reproductibilité des builds | F-Droid Verification Server publie un résultat reproductible ✅ pour Briar 1.5.19 (version code 10519, essai 10 août 2026); latest website 1.5.21 du 30 sept. n’apparaît pas encore dans le tableau consulté. Le projet publie Docker reproducer. [F-Droid verification](https://verification.f-droid.org/packages/org.briarproject.briar.android/), [release](https://briarproject.org/) | Le projet dit que ses builds reproduisibles permettent de vérifier l’APK publié. [GitHub mirror README](https://github.com/briar/briar) | F-Droid fournit une comparaison indépendante reproductible pour certaines releases historiques/récentes; aucun résultat encore repéré pour 1.5.21 ni Google Play release. | C’est l’une des preuves de build les plus concrètes de ce dossier, mais elle doit être liée à la version exacte utilisée. | Reproductibilité v1.5.21, APK direct site/Play ↔ tag et signature, et Desktop/Mailbox variants. |
| 19. Supply chain | Dépôt public utilise CI et versions/dépendances pinées; F-Droid buildserver construit son APK. Pas de scan complet advisories/SBOM actuel. | Projet invite des tiers à reproduire ses APKs. | La comparaison F-Droid 1.5.19 apporte une preuve pour ce canal/version; aucun build test personnel effectué. | Réduire la confiance au store est possible via F-Droid, mais source/build runner/keys/releases restent à protéger. | Secrets CI, signatures releases, dépendances transitive, APK Play vs direct, advisories actuels, maintainer concentration. |
| 20. Infrastructure | Tor est infrastructure réseau pour les connexions Internet; bridges configurables; Bluetooth/Wi-Fi directs; Mailbox personnelle optionnelle. Aucun endpoint central Briar à résoudre pour messagerie classique. [Manual](https://briarproject.org/manual/), [architecture](https://briarproject.org/how-it-works/) | Le projet ne connaît pas l’adresse des utilisateurs et n’exploite pas un serveur de messagerie. | Aucune mesure passive DNS/ASN/bridge/tor guard effectuée; les nodes Tor changent. | ISP peut reconnaître Tor ou bridge et faire traffic analysis, mais ne voit pas nécessairement l’adresse contact; appareil Mailbox crée une dépendance réseau personale. | Bootstrap/bridge list, point Tor guard, régions/hébergeurs des bridges et comportement de Tor daemon intégré actuel. |
| 21. Juridiction | Projet communautaire à gouvernance par board auto-nommé chaque année; page courante cite financeurs institutionnels mais la page de board donne membres « as of Apr 2023 », pas un siège juridique complet. [Gouvernance](https://briarproject.org/governance/), [funding](https://briarproject.org/news/2026-maintenance-mode/) | Le projet n’a pas de comptes/contenus centraux et son travail a été financé par plusieurs fonds. | Pas d’examen de personnalité juridique, structure contractuelle ou contrats de financement réalisé. | Les réquisitions peuvent viser utilisateurs, hébergeurs Tor/bridge, fournisseur store, mailbox ou appareils plutôt qu’un « serveur Briar ». | Pays d’enregistrement, entité responsable, siège actuel, bénéficiaires, conflits de lois et entité contractante pour Google Play/F-Droid. |
| 22. Demandes policières | Aucun guide LE, transparency report, subpoena, ordre de production ou retour de données Briar effectivement obtenu n’a été identifié ici; website logs 7 jours et rapports diagnostics opt-in constituent une surface limitée du projet. [Privacy](https://briarproject.org/privacy-policy/) | Projet affirme n’avoir accès à aucun message/métadonnée de communication. | Pas de recherche judiciaire exhaustive mondiale et pas de preuve de requête/remise réelle. | Peu de données centrales chez l’éditeur n’empêche ni saisie locale, ni demande à l’ISP/store, ni collecte chez correspondant/Mailbox. | Données réellement obtenues dans des affaires, logs Tor/Mailbox ou appareils, ordres non publiés. |
| 23. Affaires judiciaires connues | Aucun cas public Briar-specific avec retour de données confirmé n’a été identifié dans cette étape. | — | Absence de cas retrouvé n’est pas preuve qu’il n’en existe aucun; la recherche est ciblée/indexée. | Exposition dépend du détenteur de l’appareil et de l’opérateur de relais/Tor, pas d’un backend central Briar. | Saisies d’appareils activistes, demandes aux app stores, ordonnances sous scellés et contentieux. |
| 24. Audits | Cure53 2017 (early-stage Android), ROS/OTF 2023 Android/Desktop avec retest en 2024, et projet académique ETH 2023; éléments résumés plus haut dans les audits détaillés. | Briar dit avoir corrigé findings 2017 avant premier stable; 2023 ETH findings corrigés en 1.4.22/1.5.3, aucun signal d’exploitation rapporté. [Annonce 2023](https://briarproject.org/news/2023-three-security-issues-found-and-fixed/) | ROS/OTF est un mandat tiers; quatre/6 findings résolues au retest, deux planifiées selon la page audit. ETH semester project indépendant, pas audit contractuel complet. | Historique montre des audits réels + corrections, mais il n’y a pas d’audit complet post-2024 identifié pour version 1.5.21. | Retest exact des 2 issues ROS restantes, audit release actuelle, Mailbox, Desktop beta, build/release pipeline et API OS. |
| 25. Vulnérabilités | Étude ETH sur 1.4.20: BHP non-FS; DoS BSP par contact malveillant; duplication messages groupes/forums/blogs; introduction MITM connue. Editeur dit corrigé en v1.5.3 (handshake) et v1.4.22 (DoS+duplication), pas d’exploitation connue. [ETH](https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/education/theses/report_YuanmingSong.pdf), [éditeur](https://briarproject.org/news/2023-three-security-issues-found-and-fixed/) | Correctifs publiés et upgrade conseillé. | Findings reproducibles dans un projet ETH; action de correction confirmée éditeur, mais no independent retest post-fix démontré ici. | Très important : le résultat non-FS vise l’ancien BHP et contexte de setup remote; ne pas attribuer au BQP QR local ni à 1.5.21 sans version mapping. | Correspondance de commits/fixes, test anti-regression current, advisory/CVE/OSV additionnels et exploitation pratique. |
| 26. Recherche académique | ETH Zurich semester project de Yuanming Song, 5 mars 2023, analyse protocoles et Tamarin simplifié; l’auteur conclut crypto globalement solide tout en demandant analyses supplémentaires, traffic analysis et Mailbox. [Rapport 70p](https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/education/theses/report_YuanmingSong.pdf) | Briar a demandé audit plus large après ces découvertes. | La thèse n’est pas une publication peer-reviewed de conférence; elle donne modèle, version, détail d’attaques et artifacts Tamarin dans le PDF. | C’est une source d’analyse crypto approfondie et nuancée, non une preuve complète de l’anonymat réseau ou de sécurité de toutes releases. | Études récentes peer-reviewed de traffic correlation Tor/Briar, tests Mailbox, reproductions indépendantes sur version courante. |
| 27. Incidents historiques | Editeur dit n’avoir reçu aucun signal d’exploitation des bugs ETH; échec Play Store 2022 décrit comme bref retrait de conformité review/login, non incident crypto. Aucun compromis réseau confirmé trouvé. | Pas d’accès aux contenus et aucune donnée de communication détenue. | Aucun registre d’incidents, notification fuite ou enquête DFIR indépendante consulté. | Vulnérabilités publiées et bugs ne sont pas incident exploité; panne, app-store removal et censure réseau sont catégories distinctes. | Exploitations non rapportées, Tor attacks, breaches de devices ou dépendances et pannes majeures. |
| 28. Gouvernance / financement | Board de communauté auto-nommé, max 5, membres réélus annuellement selon règle; noms listés datés avril 2023, donc stale. Financement historique de plusieurs fondations. [Governance](https://briarproject.org/governance/), [funding 2026](https://briarproject.org/news/2026-maintenance-mode/) | Briar annonce en juillet 2026 être maintenu, mais seulement pour mises à jour de sécurité/bogues; fonctionnalités/refonte suspendues faute de moyens. | Déclaration du fournisseur; pas d’audit des finances/contrôle/gouvernance externe. | Le contrôle du code/releases et le faible budget sont facteurs supply chain/continuité, même en projet décentralisé. | Board actuel après 2023, financement durable, mainteneurs opérationnels, processus incident et succession des clés. |
| 29. Résistance à la censure | Tor Bridges, relais/circuits Tor, Bluetooth/Wi-Fi et transfert mémoire permettent de contourner certains blocages ou pannes Internet. [Manual](https://briarproject.org/manual/), [architecture](https://briarproject.org/how-it-works/) | Site revendique fonctionnement malgré coupures, censure et absence de point central. | Pas de mesures OONI ni étude par pays/DPI; modèle de menace du site assume contrôle global des canaux longue portée mais capacités limitées sur liens courts. | Résilience forte à coupure Internet si contacts proches et radios autorisées; Tor/bridges/store/app distribution restent bloquables et pratiques locales peuvent être surveillées. | Reachability en pays censuré, bridge freshness/obfuscation, Bluetooth confiscation, efficacité de mise à jour hors-ligne. |
| 30. Maintenance actuelle | Site officiel relevé au 13 oct. annonce Briar 1.5.21 (30 sept. 2026); communiqué du 9 juillet dit projet actif en maintenance mode : seulement updates sécurité essentielles et bug fixes pour l’instant. Desktop dernière news beta trouvée 0.6.0 en 2023. [Release](https://briarproject.org/), [maintenance](https://briarproject.org/news/2026-maintenance-mode/), [news](https://briarproject.org/news/) | L’équipe dit continuer plutôt que fermer, tout en reportant backup, pièces jointes et problèmes batterie/arrière-plan. | Release 1.5.21 récente établit une publication, pas la capacité de correction à long terme; F-Droid vérification la plus récente repérée est 1.5.19. | Maintenance continue mais scope réduit et dépendance à une petite équipe; Desktop/Mailbox doivent être suivis séparément. | Nombre de maintainers actifs, SLA correction CVE, continuité de Tor build, roadmap et statut des composants desktop/mailbox. |

### Briar — matrice des métadonnées

La colonne fournisseur désigne l’équipe/projet, non les relais Tor, FAI, contacts, stores ou propriétaires de Mailbox. Aucune donnée de cette matrice n’est une preuve de remise effective aux autorités.

| Métadonnée | Fournisseur / infrastructure | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | **NON ACCESSIBLE PAR DESIGN** à une base Briar centralisée; **CONFIRMÉ** au guard Tor/bridge et possesseur Mailbox selon connexion. | **NON ACCESSIBLE PAR DESIGN** sur chemin Tor onion selon conception; **POSSIBLE** sur transport local/fallback. | **CONFIRMÉ** IP vers guard/bridge et timing/volume, pas destination directe habituelle. | **POSSIBLE** compte Play/install; aucune association Briar ↔ identité établie. | **POSSIBLE** auprès ISP/Tor relay/bridge/Mailbox/device si données existent; pas de retour Briar identifié. |
| Téléphone | **NON ACCESSIBLE PAR DESIGN** comme donnée requise du compte. | **POSSIBLE** si partagé dans profil/conversation ou autre service. | **NON ACCESSIBLE PAR DESIGN** via seul flux réseau; opérateur mobile sait l’abonné. | **POSSIBLE** dans le compte Play, pas lien vers profil Briar démontré. | **POSSIBLE** via opérateur, store ou terminal. |
| Email | **NON ACCESSIBLE PAR DESIGN** au compte; **POSSIBLE** volontaire dans diagnostic/support. | **POSSIBLE** si communiqué hors app. | **NON ACCESSIBLE PAR DESIGN** sur seul flux Tor/E2E. | **POSSIBLE** compte store; association inconnue. | **POSSIBLE** via support/store/device; aucun cas project production connu. |
| Identifiant | **NON ACCESSIBLE PAR DESIGN** à un serveur central; clé publique/link existe côté compte local et peut être divulgué. | **CONFIRMÉ** clé/nom choisis dans contact, QR/link; contacts reçoivent informations de profil. | **NON ACCESSIBLE PAR DESIGN** pour clé/contact via ISP; Tor pattern/IP demeurent. | **POSSIBLE** package/app identity et account store, profil Briar non relié par preuve consultée. | **POSSIBLE** via device, contact, backup OS ou link intercepté. |
| Graphe social | **NON ACCESSIBLE PAR DESIGN** à l’équipe selon policy; Mailbox/contacts intermédiaires peuvent observer relations locales ou groupes. | **CONFIRMÉ** contacts/groupes/forums connus; introductions révèlent lien mutuel. | **POSSIBLE** corrélation de flux Tor multi-point; pas graphe direct. | **POSSIBLE** signaux d’installation/store, graphe non établi. | **POSSIBLE** via appareils, pairs, infiltré, Mailbox ou corrélation réseau. |
| Timestamps | **NON ACCESSIBLE PAR DESIGN** à l’opérateur central; **POSSIBLE** logs website 7 jours et diagnostics. | **CONFIRMÉ** horaires locaux et message IDs. | **CONFIRMÉ** horaires de connexion Tor/bridge, volume. | **POSSIBLE** timestamps d’installation/updates Play. | **POSSIBLE** par appareil, ISP, guard/bridge si logs; aucune production confirmée. |
| Volumes | **POSSIBLE** si mailbox utilisateur voit échanges; aucun serveur project classique. | **CONFIRMÉ** messages/media synchronisés localement. | **CONFIRMÉ** volume/temps vers Tor et voisins Wi‑Fi/Bluetooth locaux. | **POSSIBLE** taille téléchargement/update. | **POSSIBLE** par saisie/ISP/relay logs. |
| Groupes | **NON ACCESSIBLE PAR DESIGN** à l’équipe; un membre ou device peut accéder aux messages de son groupe; forum/blog public à ses abonnés. | **CONFIRMÉ** selon adhésion, membres/messages visibles aux utilisateurs autorisés. | **POSSIBLE** motifs temps/volume, pas liste des membres au niveau IP seul. | **NON ACCESSIBLE PAR DESIGN** pour membership de groupe selon preuves disponibles; store metadata inconnue. | **POSSIBLE** via membres/appareils ou corrélation. |
| Appareils | **POSSIBLE** pour Mailbox et connexions réseau mais pas inventaire central compte. | **POSSIBLE** d’inférer l’activité et device pour groupe/correspondant; pas inventaire du profil. | **CONFIRMÉ** connexion IP/Tor par terminal au niveau réseau. | **PROBABLE** appareil/store registration, pas identité Briar. | **POSSIBLE** auprès store, ISP, seized devices; data retention unknown. |
| Push tokens | **NON ACCESSIBLE PAR DESIGN** comme mécanisme de push central utilisé par Briar Android; pas d’APNs/FCM messenger établi. | **NON ACCESSIBLE PAR DESIGN** au correspondant. | **NON ACCESSIBLE PAR DESIGN** de token; connexions réseau visibles. | **POSSIBLE** signaux de compte/store mais push token Briar non établi. | **INCONNU** comme token/message Briar spécifique; store/appareil peuvent fournir métadonnées. |

### Briar — première colonne TM1–TM15

| Modèle | Cellule | Justification probatoire courte |
|---|---|---|
| TM1 — fournisseur curieux | ✅ | Pas de fournisseur central de messagerie avec compte/graphe/historique; exceptions diagnostics opt-in, site et Mailbox utilisateur séparée. [Policy](https://briarproject.org/privacy-policy/) |
| TM2 — fournisseur compromis | ✅ | Absence de backend central réduit l’impact; un bridge/guard Tor compromis voit son segment, Mailbox compromise possède contenu reçu, store/updates restent des tiers. |
| TM3 — fournisseur malveillant | 🟡 | Pas de serveur pour substitution de clé, mais builds/updates restent privilégiés et l’étude ETH identifie le risque de contact malicieux/introduction sans OOB. |
| TM4 — ISP / Wi‑Fi | 🟡 | Tor/bridges cachent les destinations habituelles mais ne cachent pas une connexion Tor, timing/volume ou proximité radio; pas d’obfuscation de trafic validée ici. [Manual](https://briarproject.org/manual/) |
| TM5 — passif multi-points | 🟠 | Plusieurs points Tor/ISP peuvent tenter corrélation timing; recherche actuelle identifie traffic analysis comme travail futur, pas protection prouvée. [ETH](https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/education/theses/report_YuanmingSong.pdf) |
| TM6 — adversaire global passif | 🟠 | Tor/P2P résiste à une vue serveur unique et menace documentée inclut observation longue portée, mais pas mixnet/cover traffic ni preuve contre corrélation mondiale. |
| TM7 — contact malveillant | 🟡 | Pas d’IP directe de l’autre pair attendu par Tor; contact voit profil/messages et link/activité, peut infiltrer groupe, transmettre/screenshot ou participer à une introduction. |
| TM8 — harceleur/doxxer OSINT | 🟡 | Pas d’annuaire ni téléphone/e-mail, mais lien clé publique, réutilisation nick/avatar, posts/forums et traces hors app peuvent recouper l’identité. |
| TM9 — demande judiciaire classique | ✅ | Projet déclare ne pas avoir contenus/métadonnées centralisés à fournir; requête peut viser diagnostics/store/Tor/ISP, pas de production Briar connue. [Policy](https://briarproject.org/privacy-policy/) |
| TM10 — enquête sophistiquée | 🟠 | Appareil, co-utilisateurs, mailbox, OS/store, ISP/Tor corrélation et extraction Android peuvent viser l’endpoint sans casser crypto. |
| TM11 — appareil verrouillé | 🟡 | Base locale chiffrée/password et screen-lock aident, mais Oxygen v16 annonce bruteforce Briar en full-file-system mode sans paramètres device/app établis; résultat actuel inconnu. [Oxygen](https://oxygenforensics.com/uploads/press_kit/OFDv160ReleaseNotes.pdf) |
| TM12 — appareil déverrouillé | 🔴 | Terminal déchiffre messages/contacts/clé; lock app et E2EE réseau ne protègent pas une session accessible. |
| TM13 — spyware ciblé | 🔴 | Maliciel avec écran/mémoire/DB accessible lit les messages au terminal. |
| TM14 — supply-chain compromise | 🟡 | Build F-Droid 1.5.19 reproductible vérifié; aucune preuve encore pour 1.5.21, Google Play, Desktop ou Mailbox. [F-Droid](https://verification.f-droid.org/packages/org.briarproject.briar.android/) |
| TM15 — censure étatique | 🟡 | Tor bridges + transport Bluetooth/Wi‑Fi/mémoire rendent certains blocages contournables; Tor, app distribution, radio et proximité restent surveillables/bloquables. [How it works](https://briarproject.org/how-it-works/) |

### Briar — contradictions, inconnues et tests ciblés

- **Forward secrecy** : l’étude ETH date de 2023 et examine Briar 1.4.20; elle démontre une lacune BHP dans l’ancien handshake. L’éditeur confirme la conception imparfaite, affirme qu’une écoute exploitante n’était pas possible du fait du Tor v3 dans le scénario, et dit avoir remplacé BHP en 1.5.3. Ce point est donc un finding historique corrigé selon l’éditeur, pas une preuve que le build 1.5.21 a été indépendamment retesté.
- **Réseau vs anonymat global** : Briar revendique résistance à surveillance des métadonnées par Tor et contacts locaux; cela ne prouve pas résistance à une corrélation multi-points/global passive, et le papier ETH appelle explicitement à l’étudier.
- **Maintenance** : le projet est toujours actif au 13 oct. 2026 et a publié 1.5.21, mais communique une phase de maintenance limitée aux correctifs essentiels; ce n’est ni abandonné, ni développement fonctionnel soutenu.
- **Forensics** : Oxygen Forensic Detective v16 annonce passcode brute-force Briar via extraction full-file-system et mentionne support Android 12/13 dans ses release notes générales; l’extrait consulté ne donne ni téléphone exact, ni version de Briar, ni taux/cas d’exploitation. C’est une capacité d’outil revendiquée par le vendeur, pas un test récent et universel. Aucun résultat Cellebrite/GrayKey/Magnet précisément versionné n’a été établi ici.
- **Tests nécessaires** : comparer APK 1.5.21 par canal, vérifier exactitude F-Droid reproducible result, télécharger/inspecter manifest, permissions et SDK; test contrôlé Tor/bridge/local transport avec capture d’IP et timing; saisir téléphone de labo verrouillé/déverrouillé avec Oxygen/Cellebrite/Magnet versions documentées et noter modèle/Android/Briar; vérifier DB/WAL/fichiers et diagnostics; auditer BHP v1, onboarding lien et Mailbox sur source commit courant; vérifier retest ROS issues OTF-003/005; mesurer data-loss et Tor traffic sur Android récent; faire une revue indépendante traffic-analysis à deux points. Aucun n’est présenté comme déjà exécuté.

## Session — dossier de preuves approfondi (complément, état au 13 octobre 2026)

Ce complément sépare le protocole Session V1 déployé, le réseau Session, les services annexes (push, fichiers, appels et communautés) et la feuille de route V2. Les sources de code sont des branches publiques consultées, pas un audit du binaire des stores. Les constats de papier décrivent les versions/configurations de leur étude, pas automatiquement chaque release actuelle.

| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | Application multi-plateforme; identité stable par Account ID/clé; messages via requêtes onion vers un swarm de nœuds, stockage temporaire répliqué; fichiers via service distinct; appels WebRTC beta et communautés sont des chemins différents. [Routage](https://docs.getsession.org/session-network/session-protocol/onion-requests-and-message-routing), [FAQ](https://getsession.org/faq) | Nœuds distribués et onion requests visent à éviter un serveur de messagerie central connaissant IP et correspondants. [Session Network](https://docs.getsession.org/session-network) | L’étude USENIX 2026 analyse le protocole client-serveur/swarm courant V1 et montre que décentralisation du stockage n’empêche pas substitution de clé par un nœud malveillant. [Article](https://www.usenix.org/conference/woot26/presentation/urushigaki), [PDF](https://www.usenix.org/system/files/woot26-urushigaki.pdf) | « Décentralisé » décrit le stockage/routage, pas l’absence de points de confiance: seed, swarms, push, fichiers, appels et distribution d’apps restent distincts. | Part réelle des nœuds indépendants, concentration de propriété/hosting, bascules et comportements exacts selon chaque version/réseau. |
| 2. Protocole cryptographique | L’implémentation V1 étudiée combine Ed25519 (signature/identité), X25519, clés éphémères par message, BLAKE2 et NaCl `crypto_box`/XSalsa20-Poly1305; messages persistants signés et compteur applicatif. [USENIX 2026](https://www.usenix.org/system/files/woot26-urushigaki.pdf) | Le protocole est présenté comme E2EE; V2 doit apporter PFS/PQ et meilleure liaison d’appareils; le code PFS/PQ est en branche de développement, non livré dans le protocole courant selon update du 2 août. [Roadmap](https://getsession.org/blog/session-development-update-pro-beta-protocol-v2) | WOOT 2026 relève absence de FS et de déni plausible en V1, absence d’authentification mutuelle robuste des clés publiques et absence de binding cryptographique fiable au compteur monotone; il construit des attaques de substitution, falsification d’horodatage, suppression/rejeu. | E2EE contre un relais passif ne suffit pas à l’authentification de la bonne identité ni à l’intégrité de l’ordre/actualité face à un nœud actif. | Correctifs/proposition post-publication, statut réel des contre-mesures sur les tags Oct 2026 et retest externe. |
| 3. Création d’identité | Compte créé sans numéro/e-mail; Account ID est dérivé de clés stables et récupération via phrase secrète. Le client Android courant demande création/restauration localement. | Aucun identifiant téléphonique ni mail nécessaire; l’adresse IP n’est pas liée à l’Account ID selon l’éditeur. [Privacy app](https://getsession.org/app-privacy-policy) | L’article WOOT confirme que clés longues dérivées du seed sont déterministes/stables; clé publique connue reste liée au même pseudonyme dans le temps. | Cela réduit l’association automatique à une identité civile, mais augmente la linkabilité interne du pseudonyme et ne neutralise pas OSINT/réutilisation. | Entropie/mécanisme précis dans toutes builds stores actuelles, éventuel lien réseau par les parcours onboarding, et protection/effacement mémoire réel. |
| 4. Contact discovery | Ajout par Account ID, QR ou partage d’invitation; pas d’annuaire téléphonique obligatoire; manifest Android consulté ne déclare pas `READ_CONTACTS`. | Le service est conçu pour ne pas collecter le carnet d’adresses ni exiger numéro/e-mail. [FAQ](https://getsession.org/faq) | USENIX rapporte vérification de fingerprint hors bande possible mais non imposée et UX de comparaison longue/peu pratique; boîte de demandes réduit certaines surprises mais pas le risque de substitution pour un contact connu. | L’utilisateur doit authentifier indépendamment l’Account ID/fingerprint par canal fiable; l’existence d’un QR n’est pas en soi une vérification si transmis sur canal compromis. | Comportement des variantes desktop/iOS, éventuelles suggestions/contact import et taux de vérification utilisateur réel. |
| 5. Métadonnées serveur | Le routage transmet ID destinataire, timestamp, expiration et namespace à un nœud du swarm; messages répliqués dans swarm et expirent par défaut après 14 jours selon docs. [Onion routing](https://docs.getsession.org/session-network/session-protocol/onion-requests-and-message-routing) | Onion layers empêchent chaque hop d’apprendre l’IP et le correspondant complet; les messages ne sont pas accessibles au serveur. | Paper WOOT montre une manipulation active possible par nœud sur l’authentification/compteurs, sans déchiffrer le texte. | Chiffrement masque le corps mais pas nécessairement toutes les propriétés de routage/cadence; timing/volume multi-point et présence dans un swarm restent surfaces. | Champs exacts vus par chaque hop pour chaque namespace, format récent, retention logs et observabilité du graphe via collusion de nœuds. |
| 6. IP utilisateur | À l’onboarding, le client Android contacte un seed node pour la liste de nœuds; ce point reçoit l’IP. Lors des messages normaux l’architecture onion est conçue pour masquer IP au node destinataire. | La politique dit que seed voit IP mais ne la journalise pas; push standard/rapide et appels ont des exceptions. [Policy](https://getsession.org/app-privacy-policy), [FAQ](https://getsession.org/faq) | Aucun test réseau passif/pcap n’a été réalisé ici; WOOT n’est pas une mesure de l’observabilité IP des déploiements. | Un seed compromis/logging, fournisseur réseau ou corrélation temporelle peut relier une source à des fenêtres d’activité, même si payload relay ne reçoit pas l’IP source directement. | Rétention réelle seed/nodes, logs opérateurs, DNS/IP de chaque endpoint, adresse vue à travers VPN et résistance à un adversaire multi-hop. |
| 7. Exposition IP au correspondant | FAQ dit explicitement que les appels WebRTC beta peuvent révéler l’IP au pair; appels désactivés par défaut, aucune conférence de groupe. [FAQ](https://getsession.org/faq) | Appels futurs onion-routés sont annoncés; les messages texte n’exposent pas directement l’IP au correspondant selon design. | Aucun test ICE/capture sur version courante. | Pseudonyme distinct ne protège pas contre un correspondant qui appelle ou partage un lien externe; passerelle TURN change l’exposition pair↔service, sans effacer métadonnées de l’opérateur. | Candidats ICE réellement émis par build, effets VPN, mode TURN, OS et appels beta selon release/région. |
| 8. Messages | Chats individuels E2EE et messages stockés côté réseau temporairement; disparition configurable. | Par défaut, messages de l’infrastructure expirent en 14 jours; l’éditeur ne peut lire le contenu. [FAQ](https://getsession.org/faq) | WOOT 2026 montre falsification de l’ordre/timestamp, drop et replay sous modèle nœud actif; il n’a pas cassé la primitive de chiffrement ni observé attaque mainnet. | L’E2EE ne garantit pas livraison, ordre/actualité véridiques ou authenticité de l’interlocuteur sans vérification de clés. | Politique exacte de disparition pour chaque conversation/version, notifications, copies locales, captures côté destinataire et propagation des messages supprimés. |
| 9. Groupes | Groupes fermés annoncés E2EE, jusqu’à 100 membres selon FAQ; « Communities » publiques/self-hosted ne sont pas E2EE et serveur peut recevoir contenu en clair au niveau applicatif. [FAQ](https://getsession.org/faq) | Groupes fermés utilisent le même modèle de protection E2EE que 1:1. | WOOT traite fermé/one-to-one mais exclut communautés; findings d’authentification/compteur concernent le protocole évalué. | Un membre compromis peut copier le contenu; « communauté Session » ne doit jamais être assimilée à un groupe privé E2EE. | Audit indépendant du protocole de groupe sur tag actuel, confidentialité des membership lists et correctifs spécifiques après WOOT. |
| 10. Appels | Appels audio/vidéo en beta 1:1, P2P WebRTC, option désactivée par défaut; pas d’appel de groupe dans FAQ. [FAQ](https://getsession.org/faq) | Média décrit E2EE; STUN/TURN STF et le pair voient l’IP; aucun contenu accessible à STF. | Pas de mesure indépendante de la suite ICE, TURN, identité cryptographique du média ou rétention. | Appel ne bénéficie pas automatiquement du modèle d’anonymat des onion messages; l’IP pair est une exposition directe documentée. | État fonctionnel par store/OS, chiffrements exacts SDP/WebRTC, relais obligatoire éventuel et comportement après update 1.33.6/2.15.5. |
| 11. Fichiers | Service de fichiers central distinct; téléchargement est chiffré E2EE selon FAQ, plafond 10 MB indiqué; FAQ dit métadonnées EXIF retirées sur desktop mais pas sur mobile. | Onion routing masque IP au serveur de fichiers; fichiers sont chiffrés et service ne peut pas les lire. [FAQ](https://getsession.org/faq) | Pas d’analyse APK/IPA ni capture du fichier actuel; Quarkslab 2021 a trouvé attachements iOS historiques en clair sur stockage local (voir audit plus bas). | E2EE réseau n’efface pas EXIF, copies locales, thumbnails, caches ou partage vers un autre app; absence EXIF mobile est une limite explicitement documentée. | Le chiffrement nouvellement activé des flux d’attachements iOS 2.15.5, algorithmes, serveur/régions, durée fichiers, URL/headers/logs et EXIF exacts par format. |
| 12. Multi-device | Restauration d’un même Account ID via phrase de récupération sur autre device; pas de modèle publié de clés d’appareil indépendantes pour V1. | V2 prévoit groupe privé d’appareils, rotation et approbation d’un nouveau device, selon roadmap officielle. | WOOT traite l’identité et la sécurité V1, pas audit de l’onboarding multi-device actuel. | Même secret de compte restauré sur plusieurs appareils élargit la surface: compromission d’un terminal peut exposer identité/communications, et l’utilisateur peut ne pas voir tous les appareils actifs. | Limite de devices, sessions révoquées, signaux d’ajout, cohérence des clés, état de session ancienne après restauration et effacement de compte. |
| 13. Notifications push | Android rapide passe par FCM et push backend STF; mode lent repose sur polling. iOS utilise APNs dans mode rapide. | Apple/Google voient IP/token; STF reçoit Account ID/token; l’éditeur affirme que le push n’inclut ni contenu ni contact ni heure exacte du message. [FAQ](https://getsession.org/faq) | Aucune capture push, inspection des payloads ou vérification indépendante du lien token↔ID. | Le chemin rapide ajoute des observateurs/horodatages et une dépendance Google/Apple, même si payload opaque; mode lent réduit ce chemin au coût batterie/latence. | Payload exact, timing, durée de conservation FCM/APNs/STF, permutation token, lien d’identité et comportement réel par OS/version. |
| 14. Stockage local | Le code Android courant décrit `signal_v4.db`/`session.db` sous SQLCipher et une clé scellée par Android Keystore; les préférences contiennent des secrets enveloppés. [Architecture](https://github.com/session-foundation/session-android/blob/dev/ARCHITECTURE.md) | Android déclare `allowBackup=false`; l’éditeur décrit les données comme chiffrées au repos et le Keystore comme protection de clé. | Quarkslab 2021 a examiné des bases chiffrées sur Android 10/Session 1.4.1 et trouvé des pièces jointes iOS 1.6.0 en clair. Le parser ALEAPP 2026 lit des artefacts de préférences sur quatre images Android 14/15, mais note l’échec de déchiffrement des bases lorsque le Keystore matériel est non exportable. [Audit PDF](https://blog.quarkslab.com/resources/2021-05-04_audit-of-session-secure-messaging-application/20-08-Oxen-REP-v1.4.pdf), [ALEAPP](https://github.com/abrignoni/ALEAPP/blob/main/scripts/artifacts/sessionMessenger.py) | Artefacts récupérables après acquisition n’impliquent pas contenu DB en clair; résultat dépend notamment de l’état verrouillé, du matériel Keystore, de l’OS et de la voie d’instrumentation. | Correspondance exacte versionCode/release et modèle Android, déchiffrement de DB/WAL sur appareils verrouillés/déverrouillés, iOS/Desktop actuels, effacement sûr et validation indépendante des résultats Frida 2025. |
| 15. Sauvegardes | Android manifest `allowBackup=false`; récupération de compte via mnemonic n’équivaut pas à sauvegarde de base de messages. | Le seed permet de rétablir le compte; disponibilité du contenu d’historique dépend du réseau et de l’expiration. | Aucun backup courant analysé. | Un secret de recovery stocké dans cloud/clipboard/capture écran peut annuler l’avantage; restauration d’identité ne garantit pas historique. | Mécanisme précis iOS/desktop, backup OS/cloud, export et sauvegarde locale, secrets résiduels / migration. |
| 16. Analytics / SDK tiers | Android source consultée désactive analytics/crash analytics; Gradle conserve Firebase Messaging dans variants concernés tout en excluant analytics/core/measurement. Google Play et App Store déclarent « aucune donnée collectée » (auto-déclaration éditeur). [Gradle](https://raw.githubusercontent.com/session-foundation/session-android/dev/app/build.gradle.kts), [Play](https://play.google.com/store/apps/details?id=network.loki.messenger), [App Store](https://apps.apple.com/us/app/session-private-messenger/id1470168868) | L’app ne collecte pas données personnelles de messagerie; policy distingue app, website et endpoints réseau. | Source manifeste/build public vérifiée, mais pas instrumentation runtime; labels des stores ne sont pas audit indépendant. | « No data collected » n’exclut ni IP nécessaire aux services tiers, ni FCM/APNs, ni données visibles par contact/relay, ni collecte de l’OS/store. | SDK inclus dans IPA, télémétrie réellement émise sur toutes plateformes/releases, attestation store labels contre build distribué. |
| 17. Code source | Repos publics session-foundation Android, iOS, desktop; chacun contient code client et scripts de build; Session Router/libsession et infrastructure sont des repos/composants séparés. | Projet présente ses apps comme open-source et invites vérification communautaire. [GitHub org](https://github.com/session-foundation) | Lecture partielle des repos/release pages; aucune revue complète des backends/nœuds déployés. | « Client ouvert » n’implique pas code serveur, configuration opérateur ni binaire identique entièrement vérifiés. | Inventaire exact de composants propriétaires, dépendances firmware/SDK, correspondance source de chaque release et services réseau exécutés. |
| 18. Reproductibilité des builds | Repos affichent signatures de commits et release hashes/signatures; Android 1.33.6 publiée le 11 oct. 2026 (tag/release), iOS 2.15.5 aussi le 11 oct.; desktop 1.18.1 publié le 10 juil. 2026. [Android](https://github.com/session-foundation/session-android/releases), [iOS](https://github.com/session-foundation/session-ios/releases), [Desktop](https://github.com/session-foundation/session-desktop/releases) | Le projet publie des hash/signature pour sécuriser les releases; ce n’est pas une affirmation équivalente à build reproductible de chaque store binary. | Aucun build indépendant n’a été reproduit/comparé à APK/AAB/IPA/EXE dans cette investigation. | Signature authentifie une origine/clée dans un modèle de confiance; elle ne prouve pas que source publique reproduit le binaire. | Reproductibilité exactes par canal/commit, provenance Android Play, TestFlight/App Store, notarisation et rotation/custody des release keys. |
| 19. Supply chain | Android CI et dép. Gradle/Firebase sont publics; desktop Electron/Node avec workflow de release signée; repos Android/desktop actifs au moment du relevé. | Releases signées et CI automatisée. | Pas d’audit de secrets CI, dépendances transitoires, provenance attestée ou vérification indépendante des binaires. | Le client a plusieurs plateformes, SDK push, stores et libraries cryptographiques: supply chain et review capacité comptent séparément de protocole. | SBOM/signatures SLSA, mainteneurs avec droits de release, nombre d’actifs soutenus, audits dépendances, apps stores comparées et incidents de pipeline. |
| 20. Infrastructure | Documentation annonce 1 500+ nœuds/50+ pays; seed node au démarrage, swarm, push STF, file server, STUN/TURN, communautés auto-hébergées; site utilise Cloudflare. [Network](https://docs.getsession.org/session-network), [privacy](https://getsession.org/privacy-policy) | Nœuds sont indépendamment opérés et onion routing répartit confiance; seed IP n’est pas conservée selon policy. | Article WOOT compte 1 596 nœuds et 274 swarms via explorer en nov. 2025, photographie historique; pas de mesure actuelle faite ici. | Multiplicité de nœuds ne prouve pas diversité opérateur/ASN/hosting; services périphériques peuvent être centralisés. | DNS/ASN/hosting/régions/certificats actuels de chaque service, distribution réelle des opérateurs, rétention et dépendance CDN/cloud non cartographiées. |
| 21. Juridiction | Session Technology Foundation est fondation suisse; page publique donne dirigeants/board mais n’établit pas à elle seule quelles sociétés, sous-traitants ou juridictions contrôlent chaque endpoint. [Foundation](https://session.foundation/) | STF dit ne pas posséder messages/IP identifiants et publie des rapports de transparence. | Recherche ici n’a pas vérifié registre, contrats, sous-traitants, choix de loi ou propriété des opérateurs de nœuds. | Domicile de fondation n’implique pas immunité extraterritoriale; demandes peuvent viser Apple/Google/hosting/ISP ou opérateurs individuels. | Entités juridiques exactes responsables par app, lieu de contrôle des serveurs tiers, procédures de contestation et portée transfrontalière. |
| 22. Demandes policières | STF publie rapports: 2025 indique 17 demandes/enquêtes, 0 divulgation et « no data held »; Q4 2024 après début de stewardship, 8 demandes signalées. [Transparency](https://session.foundation/transparency-reports), [2025 report](https://session.foundation/report-25) | Fondation affirme n’avoir remis aucune donnée d’utilisateur; le rapport compte requêtes ou inquiries et répond qu’aucune donnée n’est tenue. | Publication émise par la partie concernée; aucune ordonnance ni réponse tierce jointe/validée indépendamment dans ce dossier. | Ceci établit ce que STF déclare avoir reçu/remis, pas qu’aucune donnée n’a été obtenue ailleurs (store, ISP, device, correspondant, opérateur). | Copies des demandes/redactions, demandes visant tiers/old operator, données obtenues en saisie terminal ou par autres juridictions, cases non publiées. |
| 23. Affaires judiciaires connues | Aucun cas public retrouvé dans cette recherche où un tribunal identifie des données Session effectivement produites par STF, swarm, Apple/Google ou un nœud, avec nature de donnée vérifiée. | Rapports indiquent zéro disclosure STF pour leurs périodes. | Aucun jugement/affidavit/FOIA propre à Session avec résultats de production n’a été vérifié ici. | « Aucun cas trouvé » n’est pas preuve d’absence; les documents peuvent être scellés ou l’app n’être qu’un moyen parmi d’autres. | Recherches judiciaires par pays, alias anciens (Loki/Oxen), demandes de saisie, affaires pénales et productions hors juridiction. |
| 24. Audits | Rapport Quarkslab public (2021, 78 pp.) est l’audit indépendant détaillé principal identifié; audits de build/infrastructure actuels non identifiés ici. [PDF](https://blog.quarkslab.com/resources/2021-05-04_audit-of-session-secure-messaging-application/20-08-Oxen-REP-v1.4.pdf) | Éditeur dit plusieurs findings corrigés sur releases postérieures. | Étude académique USENIX WOOT 2026 sur V1 actuelle à son étude constitue analyse distincte et révèle vulnérabilités de protocole non résolues par l’ancien scope; pas audit contractuel complet des apps. | Un audit d’app Android/iOS 2020 ne certifie pas l’état des clients, réseau, endpoints annexes et crypto V1 en 2026; corrections annoncées ≠ retest. | Audit indépendant post-correctifs incluant desktop, build pipeline, backend, mobile courant; statut de toute revue crypto V2. |
| 25. Vulnérabilités | WOOT 2026 décrit key substitution/impersonation par nœud malveillant, modification d’horodatage, suppression/rejeu; Quarkslab a trouvé plusieurs issues Android/iOS/desktop historiques. | L’éditeur annonce des corrections 2021 et développe V2; release Android 1.33.6 / iOS 2.15.5 ne cite pas explicitement fixes WOOT dans notes vues. | Papier fournit modèle de menace et attaque en app environnements; éthique limite explicitement test à observation passive en opérations standard, pas d’attaque active sur mainnet; divulguée en déc. 2025–avr. 2026, réponse substantielle en attente à la date papier. | Findings graves pour authenticité/ordre, mais pas preuve d’exploitation en conditions réelles; status courant doit rester « vulnérabilité publiée, correctif non établi ici », pas « activement exploitée ». | Réponse auteur/session post-conférence, ticket/advisory, commit exact patch, release stable contenant fix et retest indépendant. |
| 26. Recherche académique | USENIX WOOT 2026, paper 16 pages publié août 2026, analyse Session Protocol V1 déployé; Quarkslab 2021 antérieur; le papier exclut communities non-E2EE. [USENIX](https://www.usenix.org/conference/woot26/presentation/urushigaki) | Docs officielles disent V2 en développement; update 6 oct. annonce une revue crypto indépendante future. [Update](https://getsession.org/blog/development-update-stability-fixes-and-network-improvements) | Étude précise protocol primitives, attaques et disclosure; ne rapporte aucune attaque mainnet conduite. | Source académique indépendante pertinente, mais borne d’étude et date de commit comptent; ne pas la généraliser à V2 non déployé ni à toutes features. | Corpus de protocoles/commits exacts, réplication indépendante de chaque attaque, réponse de l’éditeur, recherche adversarial trafic/metadata actuelle. |
| 27. Incidents historiques | Quarkslab a documenté faiblesses de TLS/routage/logs/stockage sur anciennes apps; WOOT rapporte un rapport responsable de vulnérabilités, mais aucune exploitation observée dans son étude. | Rapports de transparence disent zéro donnée communiquée; roadmap et updates reconnaissent équipe/budget réduits. | Aucun incident public confirmé de compromission massive ou exploitation de ces attaques dans la base consultée. | Finding de sécurité, faille exploitée, exposition metadata, panne et disclosure légale sont catégories distinctes. | Historique complet incidents, interruptions réseau, événements de fuite/nœuds compromis, exploitation non publiée et détails d’incidents sous NDA. |
| 28. Gouvernance / société / financement | STF publie en 2026 que financement communautaire a permis continuer après le 8 juillet avec une petite équipe jusqu’en 2027; update 2 août dit équipe technique de 3 développeurs. [Donation](https://getsession.org/donate), [future](https://getsession.org/blog/the-future-of-session), [V2](https://getsession.org/blog/session-development-update-pro-beta-protocol-v2) | Les mises à jour d’octobre décrivent activité continue, correctifs, lancement Pro; l’équipe dit V2 est financée mais séquencée après Pro. | Données d’équipe et budget sont annonces du projet; aucune vérification financière indépendante consultée. | Projet actif, mais capacité de réponse/audit limitée par taille; risque continuité/maintenance distinct de propriétés cryptographiques. | États financiers, dépendance donateurs, contrôles board, succession clés, effectifs actifs réels par client/backend au 13 oct. |
| 29. Résistance à la censure | Swarm distribué et onion requests éliminent un serveur unique pour messages; app distribution, seed, push, file host, DNS, internet mobile et communautés restent blocables. | Le réseau prétend fonctionner à travers plusieurs nœuds indépendants et éviter la centralisation. | Aucun test OONI, mesure DPI, blocage par pays/ASN ou test de bootstrap réellement exécuté. | Résilience partielle contre panne d’un seul node; l’existence de points de démarrage/services annexes et du token/staking n’établit pas résistance à un état-censeur/global. | Canaux bootstrap alternatifs, reachability censurée, stratégies bridges, stores, transaction staking, performance et test real-country. |
| 30. Maintenance actuelle | Android 1.33.6 et iOS 2.15.5 publiés GitHub le 11 oct. 2026; Desktop 1.18.1 le 10 juil. 2026; les repos montrent développement/release actif. La version en store peut différer. | Updates 6 oct. disent stabilité, router 1.1.0 et V2 indépendant; le protocole de messages V1 reste courant, V2 pas encore déployé. [Update 6 oct.](https://getsession.org/blog/development-update-stability-fixes-and-network-improvements) | WOOT publie août 2026 et décrit disclosure sans résolution à la date de rédaction; aucune réponse/correctif ultérieur établi. | Activité de releases ≠ réponse aux findings précis, ni maintenance équivalente sur les trois clients. | Propagation stores, cadence durable, active maintainer count par repo, suivi des issues USENIX, dates de release des fixes, support long terme. |

### Session — mise à jour réseau et recherche indépendante, 14 octobre 2026

- **Architecture actuelle :** Session a migré de l’ancien réseau Oxen au **Session Network** en mai 2025; ce n’est donc plus exact de décrire les nœuds courants comme des Oxen Service Nodes. La documentation courante décrit des swarms de 5–7 nœuds pour le stockage temporaire des messages, un réseau Session Node et une couche d’incitation Session Token/Arbitrum. Ces chiffres et propriétés de décentralisation restent des déclarations fournisseur, pas un audit indépendant de la diversité réelle des opérateurs. [Annonce de migration](https://getsession.org/blog/migrating-from-the-oxen-network-to-session-network), [page réseau](https://getsession.org/blog/introducing-the-session-network-page), [architecture Android](https://github.com/session-foundation/session-android/blob/dev/ARCHITECTURE.md).
- **Services non entièrement décentralisés :** l’architecture Android distingue messages/configs/swarms des API dédiées, notamment Pro, version de l’app et enregistrement push. Le code indique que plusieurs de ces requêtes utilisent par défaut l’onion transport, mais l’autorité et le modèle de données restent côté serveur; le bootstrap des seed nodes est un chemin distinct. Il ne faut donc pas résumer l’ensemble des flux par « aucun serveur / aucune IP observée ». [Architecture Android](https://github.com/session-foundation/session-android/blob/dev/ARCHITECTURE.md).
- **Étude académique supplémentaire :** Yu et Haines, *Practical Attacks on Session Messenger and Oxen Blockchain*, IACR ePrint 2026/773, accepté à EuroS&P 2026, annonce sept vulnérabilités dont des attaques réalistes de prise de contrôle du consensus **Oxen** et des vulnérabilités sérieuses du protocole de groupes Session V1. L’abstract et le programme IEEE sont consultables; le PDF complet IACR a renvoyé 403 lors de cette passe, donc les détails finding-par-finding, commits, sévérités, corrections et retests sont **UNKNOWN** ici. Puisque le réseau a changé en 2025, les findings de consensus Oxen ne sont pas transposables au réseau actuel sans analyse de la nouvelle implémentation; les findings groupe V1 peuvent être pertinents, mais leur version exacte et leur correction courante n’ont pas été établies. [IACR ePrint 2026/773](https://eprint.iacr.org/2026/773), [programme EuroS&P 2026](https://www.ieee-security.org/TC/EuroSP2026/program.html).
- **L’étude WOOT 2026 reste distincte :** elle analyse Session Protocol V1 et décrit des attaques d’authentification/chronologie/livraison. La documentation officielle indique encore en octobre 2026 que Protocol V2, qui doit réintroduire PFS et ajouter du post-quantique, est en développement; aucune correspondance commits → versions de store → retest indépendant n’est établie. [USENIX WOOT 2026](https://www.usenix.org/conference/woot26/presentation/urushigaki), [état officiel V2](https://github.com/session-foundation/session-docs/blob/main/session-network/session-protocol/README.md).
- **Appels et push — preuves fournisseur détaillées :** la FAQ actuelle précise que les appels beta utilisent WebRTC P2P et partagent l’IP avec le contact et le STUN/TURN géré par STF; ils sont désactivés par défaut et il n’existe pas d’appels de groupe. En mode push rapide, FCM/APNs voit l’IP et le token du téléphone, tandis que STF reçoit le Session Account ID et le push token selon l’éditeur; ces éléments n’ont pas été capturés indépendamment. [FAQ Session, appels et notifications](https://getsession.org/faq).
- **Disclosure de l’opérateur :** le rapport PDF 2025 de STF indique 17 demandes reçues, 0 cas de données fournies et 17 cas « no data held ». C’est une déclaration annuelle primaire du steward, pas une preuve indépendante que les opérateurs des nœuds, stores, ISP ou appareils ne détiennent rien. [Rapport STF 2025 (PDF)](https://session.foundation/report-25).

### Session — audit Quarkslab 2021 : extraction des éléments du PDF

**Organisme/date/version.** Quarkslab, rapport REP-v1.4 daté du 4 mai 2021, Charlie Boulo et Marwan Anastas; mandat d’Oxen, rapport public de 78 pages. Les cibles indiquées sont Android 1.4.1 sur Android 10 (Pixel 2/3), iOS 1.6.0 sur iOS 13.4.1 (iPhone 8) et une révision Desktop identifiée dans le rapport. [Rapport PDF](https://blog.quarkslab.com/resources/2021-05-04_audit-of-session-secure-messaging-application/20-08-Oxen-REP-v1.4.pdf), [présentation Quarkslab](https://blog.quarkslab.com/audit-of-session-secure-messaging-application.html)

**Durée, méthode, limites.** Le mandat total représente environ 42 jours de travail étalés sur plus d’un an, avec une dizaine de jours environ par client mobile, puis du temps supplémentaire consacré au protocole avant Desktop. L’audit combine revue de code et interactions utilisateur, tests dynamiques (dont Frida) et scénarios de client/réseau/serveur compromis; le rapport qualifie l’examen de limité/non exhaustif en raison de l’ampleur du code et de dépendances tierces. Il ne certifie pas le fonctionnement d’un réseau mondial, tokenomics/Lokinet, l’ensemble de l’infrastructure, la supply chain de releases ni les versions 2026. Le protocole et le produit ont évolué depuis.

| Finding dans le rapport | Sévérité/source | Description et recommandation rapportée | Réponse/correction éditeur documentée | Retest indépendant |
|---|---|---|---|---|
| SESS-AND-03 | Android — High | Validation du certificat TLS manquante sur récupération d’IP/clé publique de nœud; permet scénario MITM/substitution au bootstrap. Le rapport recommande validation stricte du certificat. | Oxen annonce correctif Android 1.5.4 puis pinning dans 1.9.0. | Aucun retest Quarkslab post-fix trouvé. |
| SESS-AND-05 | Android — Moderate | Certaines requêtes/communications ne passaient pas par Lokinet; conséquence: IP exposée au serveur concerné. | Annoncé corrigé Android 1.5.4. | Non établi. |
| SESS-AND-06 / AND-07 | Android — Moderate | Seed copiable au clipboard et possibilité de screenshot/lecture visuelle; risque d’exposition locale, particulièrement si malware/OS capture. | L’éditeur considère le choix de partage/visualisation intentionnel (fonctionnement utilisateur). | Non; différence entre UX et mitigation locale reste un choix de produit. |
| SESS-AND-01 | Android — Low | Notifications par défaut divulguaient du contenu. | Toggle d’aperçu ajouté, mais défaut historique avec contenu complet conservé. | Pas de test des réglages/defaults 2026. |
| SESS-AND-02 | Android — Low | Vue/activité pouvait exposer des données lors du passage arrière-plan. | Annoncé corrigé Android 1.5.4. | Non établi. |
| SESS-AND-04 | Android — Low | Générateur de seed de 128 bits, plutôt que 256 bits. | Oxen répond que 128 bits restent impraticables à brute-force pour dériver le compte; auditeurs discutent le compromis mais ne donnent pas d’exploitation réalisable. | Aucun retest; ce finding n’est pas équivalent à une vulnérabilité exploitable confirmée. |
| SESS-IOS-01 | iOS — Moderate | Fichiers attachés stockés en clair dans le sandbox dans la version testée. | Réponse dit chiffrement local de base de données par mot de passe en cours de développement; pas de version corrective ferme identifiée dans le rapport. | Non établi; historique seulement. |
| SESS-IOS-02 | iOS — Moderate | Pinning/bootstrap server certificate absent. | Éditeur indique pinning iOS 1.9.4. | Non établi. |
| SESS-IOS-03 | iOS — Moderate | Téléchargement de fichiers pouvait contourner Lokinet et exposer l’IP. | Annoncé corrigé iOS 1.5.3. | Non établi. |
| SESS-IOS-05 | iOS — Moderate | Logs pouvaient contenir des données sensibles. | Annoncé corrigé iOS 1.7.0. | Non établi. |
| SESS-IOS-06 / IOS-07 | iOS — Moderate | Seed clipboard; enregistrement d’écran non bloqué. | Comportements présentés comme intentionnels/usages contrôlés par l’utilisateur. | Non établi. |
| SESS-IOS-04 | iOS — Low | Seed de 128 bits, même discussion sécurité/usage que Android. | Éditeur défend le niveau d’entropie pour compte Ed25519. | Non établi. |
| SESS-DES-01 | Desktop — Moderate | Données de circuit onion apparaissaient en clair dans des logs. | Éditeur annonce fix Desktop 1.5.3. | Non établi. |
| SESS-DES-02 | Desktop — Low | Updater n’était pas routé par onion; FAI pouvait apprendre une connexion de mise à jour. | Limitation reconnue; intention d’amélioration évoquée. Une résolution précise ne ressort pas du rapport. | Non établi. |

**Conclusion de portée.** Pour chaque fix ci-dessus, le rapport donne une réponse du fournisseur mais aucune campagne de retest indépendante attachée ne prouve la correction sur un binaire stable actuel. Le résultat ne doit donc servir ni à déclarer les anciennes failles présentes aujourd’hui, ni à certifier qu’elles sont corrigées. Les versions et contextes de test sont explicitement historiques.

### Session — preuves forensiques Android (2023–2026) et limites de transfert

| Source et statut | Résultat précis publié | Limites établies |
|---|---|---|
| **CISC-W’23 / équipe FaS de Kookmin, présentation du 2 décembre 2023; résumé de projet KISIA publié en 2024** | Le programme confirme le travail « déchiffrement de fichiers temporaires Session ». Le résumé de l’équipe indique extraction/analyse des clés de base et de fichiers temporaires au moyen d’Android Keystore, puis construction d’un outil de déchiffrement de DB/fichiers. | Le PDF KISIA a renvoyé une page d’erreur dans cette passe; je n’ai donc pas pu lire le rapport complet. Aucune version Session, modèle, patch Android, état verrouillé, type d’acquisition ni outil commercial n’apparaît dans le résumé indexé. À retenir comme travail étudiant public et piste, non comme preuve d’une extraction d’un téléphone actuel verrouillé. [Programme](https://kiisc.or.kr/bbs/downloadBoardImage?uploadedFileId=8986), [résumé KISIA](https://www.kisia.or.kr/bucket/uploads/2024/01/25/%5Bkisia%5D%202023%20%EB%8C%80%ED%95%99%EC%A0%95%EB%B3%B4%EB%B3%B4%ED%98%B8%EB%8F%99%EC%95%84%EB%A6%AC%20%EC%84%B1%EA%B3%BC%EC%9E%90%EB%A3%8C%EC%A7%91.pdf). |
| **Kim et al., JKIISC 35(5), pp. 1209–1227, publication catalogue daté du 31 oct. 2025** | L’abstract décrit une analyse de DB, logs et fichiers temporaires Session Android, avec extraction dynamique de clé par Frida annoncée comme applicable à un appareil réel; l’article est repéré sous DOI 10.13089/JKIISC.2025.35.5.1209. | Le texte intégral ne s’est pas ouvert depuis KCI/publisher pendant cette passe. L’abstract ne permet pas de confirmer modèles, OS/build Session, niveau de privilège/root, état de verrouillage, Frida version, extraction commerciale, tables décodées ou retest. Sa phrase d’introduction suggérant une hausse d’usage criminel après l’évolution de Telegram n’est pas étayée dans l’abstract par des données d’adoption; elle n’est pas utilisée comme preuve. [Notice KCI](https://www.kci.go.kr/kciportal/landing/article.kci?arti_id=ART003256904), [catalogue bibliographique](https://dlps.nanet.go.kr/search/searchInnerList.do?bestMeterialSearchQuery=%ED%95%9C%EA%B5%AD%EC%A0%95%EB%B3%B4%EB%B3%B4%ED%98%B8%ED%95%99%ED%9A%8C%3AALL_NI_TOC%3AAND&branchCode=ALL&dpBranch=REFD&hanjaYn=Y&navigationSize=5&orderBy=WEIGHT&pageNum=5&pageSize=10&queryText=%ED%95%9C%EA%B5%AD%EC%A0%95%EB%B3%B4%EB%B3%B4%ED%98%B8%ED%95%99%ED%9A%8C&searchClass=S&searchQuery=%ED%95%9C%EA%B5%AD%EC%A0%95%EB%B3%B4%EB%B3%B4%ED%98%B8%ED%95%99%ED%9A%8C&searchType=INNER_SEARCH&seqNo=44&totalSize=3828&totalSizeByMenu=3828). |
| **ALEAPP `sessionMessenger.py`, parser tiers créé/mis à jour le 7 août 2026** | Les métadonnées du parser nomment quatre images testées : Android 14 / Session versionCode 372 et 376; Android 15 / versionCode 417 et 419. Le code extrait les champs de compte/profil et les secrets DB/attachement/logs tels qu’ils apparaissent dans XML de préférences; il ne déchiffre pas le contenu DB ni les pièces jointes, et ne fait que lister chemins/tailles d’`app_parts`. Ses notes disent que le déchiffrement essayé échoue avec les clés Keystore matérielles non exportables dans ces images; la technique d’extraction par offset de blob citée ne s’applique qu’à un environnement virtualisé sans Keystore matériel. | Code/parser tiers et notes de l’auteur, pas étude évaluée par les pairs; les quatre images/données brutes ne sont pas fournies par la page source, modèles exacts non documentés dans les métadonnées. Un parser d’image acquise ne prouve ni déverrouillage ni contournement d’Android Keystore. [Code ALEAPP](https://github.com/abrignoni/ALEAPP/blob/main/scripts/artifacts/sessionMessenger.py). |

**Synthèse calibrée.** Les résultats ne se contredisent pas nécessairement : ils peuvent concerner des versions, appareils virtualisés/réels, privilèges et états de verrouillage différents. Le code Session actuel confirme une DB SQLCipher dont la clé est scellée sous Android Keystore; les preuves publiques 2023/2025 suggèrent que le contenu peut être extrait sous certaines conditions (notamment instrumentation Frida), tandis que le parser 2026 ne réussit pas à décoder les bases sur ses images à Keystore matériel. **Non établi** : déchiffrement de la base sur appareil stock, verrouillé et matériellement protégé, avec version commerciale Cellebrite/GrayKey/Magnet actuelle. [Architecture Android officielle](https://github.com/session-foundation/session-android/blob/dev/ARCHITECTURE.md)

### Session — étude USENIX WOOT 2026 : findings protocolaires et statut

L’article *Practical Attacks on a Decentralized Secure Messenger Session* (Kota Urushigaki, Hayato Kimura, Atsushi Tanaka, Takanori Isobe), présenté à WOOT 2026 en août, étudie Session Protocol V1 déployé à la date de recherche. La V2 évoquée est alors en développement et non déployée; les communautés ouvertes sont exclues car non E2EE. Les auteurs ont examiné le code et les opérations standard et ont limité leurs essais à l’observation passive/éthique : ils disent expressément ne pas avoir lancé d’attaque active contre le mainnet. [Page USENIX](https://www.usenix.org/conference/woot26/presentation/urushigaki), [PDF](https://www.usenix.org/system/files/woot26-urushigaki.pdf)

Les attaques reposent sur deux faiblesses de conception relevées par les auteurs : (a) l’absence d’authentification mutuelle obligatoire et cryptographiquement complète des clés entre correspondants; (b) absence de liaison cryptographique suffisante avec des compteurs/ordre monotones. Ils démontrent dans le modèle d’application des scénarios d’usurpation/substitution de clé par node malveillant, de manipulation de timestamp, et de drop/rejeu/duplication. L’article ne prétend pas retrouver la clé de chiffrement ni casser XSalsa20/Poly1305; l’impact est l’identité, la chronologie et la fiabilité de livraison.

La comparaison de fingerprint existe comme vérification hors bande, mais elle nécessite une action utilisateur longue et est facultative; la friction est un facteur humain, non preuve que tout utilisateur est vulnérable. Le papier explique l’attaque économique d’un node malicieux avec données de token/prix et snapshots de réseau 2025 : ces montants et nombres de nodes sont **historiques**, pas un coût ni un état du réseau au 13 octobre 2026.

Les auteurs indiquent notification responsable à partir du 2 décembre 2025, relances en janvier et mars 2026 et contact alternatif; une réponse développeur mentionnée en avril n’avait pas encore abouti à une réponse technique substantielle lors de rédaction. Les notes de release Android 1.33.6 et iOS 2.15.5 du 11 octobre que nous avons consultées ne citent pas explicitement les findings. Cela ne prouve pas qu’aucun correctif discret n’existe : **correctif actuel et retest restent UNKNOWN** tant que commits/advisory et tests ne sont pas rapprochés.

### Session — matrice des métadonnées (ce que chaque partie peut obtenir)

Les termes « CONFIRMÉ » et « PROBABLE » décrivent capacité/visibilité documentée ou nécessaire au protocole, pas remise à une autorité. « NON ACCESSIBLE PAR DESIGN » exprime la propriété visée, non une mesure adversariale; aucun retour judiciaire réel n’est inféré de la table.

| Métadonnée | Fournisseur / relais | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | **CONFIRMÉ** au seed pendant bootstrap selon policy; **NON ACCESSIBLE PAR DESIGN** au destinataire de message pour onion path, mais push/appels/fichiers à distinguer. | **NON ACCESSIBLE PAR DESIGN** via texto; **CONFIRMÉ** potentiellement pair d’appel WebRTC. | **CONFIRMÉ** IP source, destination de sortie, temps/volumes et activité vers Tor-like network. | **CONFIRMÉ/PROBABLE** au service push lors session/token; détails lien vers Account ID non indépendamment établis. | **POSSIBLE** par seed si logs, ISP, push, opérateur node ou terminal; aucun cas de remise documenté ici. |
| Téléphone | **NON ACCESSIBLE PAR DESIGN** comme champ de compte requis; peut être volontairement partagé. | **POSSIBLE** si partagé dans profil/chat/hors app. | **NON ACCESSIBLE PAR DESIGN** via flux app seul; opérateur mobile connaît l’abonné selon pays/contrat. | **POSSIBLE** via compte Apple/Google, pas association Session démontrée. | **POSSIBLE** via opérateur/store/appareil si données légales disponibles. |
| Email | **NON ACCESSIBLE PAR DESIGN** à l’inscription; **POSSIBLE** si support/web ou partage. | **POSSIBLE** si révélé; pas requis. | **NON ACCESSIBLE PAR DESIGN** à partir du seul flux chiffré, mais autres activités/réutilisation OSINT. | **POSSIBLE** compte de store; mapping au compte Session inconnu. | **POSSIBLE** auprès tiers ou device; production réelle inconnue. |
| Identifiant | **CONFIRMÉ** Account ID au swarm/serveurs nécessaires à l’adressage; seed reçoit IDs réseau selon flux. | **CONFIRMÉ** ID/fingerprint du correspondant avec qui il échange; signature/key trust problème WOOT si non vérifié. | **NON ACCESSIBLE PAR DESIGN** au contenu Account ID de chaque message par simple IP observation; timing peut corréler. | **POSSIBLE** identifiant store/token/app, lien utilisateur↔Account ID non établi. | **POSSIBLE** par nœud/serveur/terminal ou demandes tierces, mais aucune production réelle établie. |
| Graphe social | **PROBABLE** corrélation de IDs/réception au swarm et push backend; limites de ce que chaque node voit dépendent onion layer; pas de mesure collusion. | **CONFIRMÉ** relation et membres connus localement; groupe révèle autres membres selon interface. | **POSSIBLE** par timing/volume et destination réseau; relation logique pas directement visible sans corrélation. | **POSSIBLE** tokens/timing; graphe Session non démontré. | **POSSIBLE** par logs, saisies, membres/contacts; aucun cas de retour identifié. |
| Timestamps | **CONFIRMÉ** requêtes de relais et push portent nécessairement timing; message timestamp est vulnérable à manipulation selon WOOT. | **CONFIRMÉ** timestamp présenté/local et activité; authenticité de chronologie peut être compromise selon finding. | **CONFIRMÉ** heures de connexions et volumes. | **PROBABLE** heure de push/session. | **POSSIBLE** si logs tiers/relay/device disponibles. |
| Volumes | **CONFIRMÉ/PROBABLE** taille/cadence réseau visible au point d’entrée/hop; champs exacts de chaque nœud inconnus. | **CONFIRMÉ** contenu, taille, nombre de messages et fichiers reçus. | **CONFIRMÉ** octets/durée par session. | **PROBABLE** payload/timing push, volume global. | **POSSIBLE** par ISP/service/appareil; retention/production inconnue. |
| Groupes | **PROBABLE** pattern de groupe/IDs via swarm/notifications; communauté n’est pas E2EE et son serveur peut voir contenu. | **CONFIRMÉ** membres et contenu auxquels le compte a accès. | **POSSIBLE** par tailles/timing, pas liste directe prouvée. | **INCONNU** lien des notifications au membership exact. | **POSSIBLE** via terminal, membres, logs ou serveur de communauté; cas effectif inconnu. |
| Appareils | **PROBABLE** push registrations et Account ID/token; V1 ne publie pas d’inventaire/approbation complète de devices. | **POSSIBLE** à inférer du comportement; aucun inventaire complet visible établi. | **CONFIRMÉ** connexions IP distinctes du terminal via réseau. | **CONFIRMÉ** token/appareil push; mapping identité app dépend payload/service. | **POSSIBLE** via Apple/Google, opérateur et device saisi; remise Session documentée inconnue. |
| Push tokens | **CONFIRMÉ** STF backend reçoit Account ID/token selon architecture annoncée; éditeur dit lien non révélateur de messages/heures. | **NON ACCESSIBLE PAR DESIGN** au correspondant. | **NON ACCESSIBLE PAR DESIGN** token, mais destination APNs/FCM et timing visibles. | **CONFIRMÉ** token fourni à APNs/FCM; logs, durée et association compte non établis indépendamment. | **POSSIBLE** via store/push/STF si conservé; aucun retour avéré dans un dossier public retrouvé. |

### Session — première colonne TM1–TM15

Ces cellules sont des évaluations provisoires et non des scores de classement. La colonne complète des autres finalistes reste à construire avant la Phase 3.

| Modèle | Cellule | Justification courte et source |
|---|---|---|
| TM1 — fournisseur curieux | 🟡 | Message body chiffré et pas de numéro/e-mail requis, mais bootstrap/push/metadata/services périphériques existent; scope de l’éditeur à distinguer des opérateurs. [Policy](https://getsession.org/app-privacy-policy) |
| TM2 — fournisseur compromis | 🟡 | Onion protège contre une lecture simple de contenu, mais node actif peut manipuler authenticité/timestamp/livraison selon attaques WOOT; compromission push/seed ajoute corrélation. [WOOT](https://www.usenix.org/system/files/woot26-urushigaki.pdf) |
| TM3 — fournisseur malveillant | 🟠 | La substitution de clé par nœud malveillant est le finding central de l’étude V1; vérification fingerprint OOB atténue si faite correctement mais n’est pas imposée. [WOOT](https://www.usenix.org/system/files/woot26-urushigaki.pdf) |
| TM4 — ISP / Wi‑Fi / réseau local | 🟡 | Onion requests masquent normalement nœud destinataire, mais ISP voit IP vers réseau, heure/volume; activités seed, push et appels ont chemins propres. [Routage](https://docs.getsession.org/session-network/session-protocol/onion-requests-and-message-routing) |
| TM5 — observation passive multi-points | 🟠 | Évite un serveur unique pour chemin des messages, mais pas de preuve anti-corrélation trafic; timing/volumes et seed/push points permettent hypothèses. Aucune mesure multi-point faite. |
| TM6 — adversaire global passif | 🔴 | Pas de preuve indépendante de résistance globale; V1 faible latence avec timings, sans mixnet/cover traffic établi ici, facilite corrélation en principe. **INFERENCE**, pas démonstration empirique. |
| TM7 — correspondant malveillant | 🟠 | Correspondant voit messages et identifiant stable; appel P2P peut révéler IP; fichier/metadata partagé persiste; usurpation/chronologie sous node actif. [FAQ](https://getsession.org/faq), [WOOT](https://www.usenix.org/system/files/woot26-urushigaki.pdf) |
| TM8 — harceleur/doxxer OSINT | 🟡 | Pas de téléphone/e-mail obligatoire, mais Account ID persistant, QR/invitations, avatar et réutilisation de pseudonyme créent linkability. [FAQ](https://getsession.org/faq) |
| TM9 — demande judiciaire classique | 🟡 | STF rapporte 17 inquiries/demandes en 2025 et 0 données divulguées; seed/ISP/push/stores/nœuds et terminaux peuvent être visés séparément. [Rapport](https://session.foundation/report-25) |
| TM10 — enquête sophistiquée | 🟠 | Corrélation ISP/push/seed, demandes à stores, saisie d’appareil ou interlocuteur contourne protection du corps en transit; aucune extraction actuelle par tool versionnée testée. |
| TM11 — appareil verrouillé | ❓ | Le parser ALEAPP 2026 documente des artefacts Android 14/15 (Session versionCodes 372/376/417/419) mais dit ne pas avoir déchiffré les DB avec le Keystore matériel testé; l’étude Frida 2025 ne donne pas état de verrouillage ni patch OS. Aucun tuple actuel Cellebrite/GrayKey/Magnet + appareil/OS/build + état verrouillé établi. [ALEAPP](https://github.com/abrignoni/ALEAPP/blob/main/scripts/artifacts/sessionMessenger.py), [KCI](https://www.kci.go.kr/kciportal/landing/article.kci?arti_id=ART003256904) |
| TM12 — appareil déverrouillé | 🔴 | Messages, compte et clés doivent être rendus accessibles par client actif; E2EE réseau ne protège plus l’écran/mémoire/exports. No current extraction test; conclusion de menace d’endpoint. |
| TM13 — spyware ciblé | 🔴 | Maliciel avec accès aux processus/écran/notifications peut capturer avant chiffrement/après déchiffrement; cryptographie transport ne protège pas terminal compromis. |
| TM14 — supply-chain compromise | 🟠 | Repos publics et releases signées, mais reproductibilité store binaries non démontrée, SDKs push et pipeline restent tiers; signatures seules n’assurent pas le contenu source/binaire. |
| TM15 — censure étatique | 🟠 | Distribution de nœuds rend certaines pannes moins fatales, mais seed, endpoints push/fichiers/app stores/domaines et internet peuvent être bloqués; aucune mesure censorship/OONI. |

### Session — contradictions et tests expérimentaux requis

- **« Anonyme » et non lié à l’IP** : l’inscription sans numéro/e-mail et onion requests sont des propriétés de conception; elles ne prouvent pas l’anonymat global. Policy dit que le seed voit l’IP sans la conserver, alors que push rapide et appels ont observateurs identifiés. Vérifier par captures passives de chaque parcours.
- **Chiffrement vs intégrité/authenticité** : les primitives E2EE ne sont pas le finding WOOT; l’étude expose falsification de clé/ordre/rejeu via une faiblesse de protocole V1. Les notes de releases publiées 11 oct. ne suffisent ni à confirmer ni à exclure une correction.
- **V1 vs V2** : roadmap officielle parle PFS/PQ, mais les mises à jour disent que l’E2EE Protocol V2 est encore distinct du Router 1.1.0. L’update 6 oct. évoque PFS/PQ du router comme couche de transport des nouvelles sessions; cela n’est pas une preuve de PFS/PQ du contenu E2EE Session V2.
- **Communautés vs groupes** : communautés auto-hébergées ne sont pas E2EE; ne pas les compter comme une variante de groupe privé protégée.
- **Labels mobiles vs flux réseau** : « No data collected » est auto-déclaré. Il coexiste avec l’IP reçue par seed, Apple/Google push et permissions appareil nécessaires (caméra/micro/fichiers). Pas de contradiction logique si labels excluent certaines données de transit, mais leur portée est facilement surinterprétée.
- **Audit historique vs état actuel** : fixes Quarkslab sont principalement annoncés par l’éditeur; aucune revalidation indépendante connue. L’audit ne portait ni sur le protocole V1 actuel, ni sur les services 2026.
- **Forensics / Android Keystore** : le résumé de projet 2023 rapporte un déchiffrement DB/fichiers via Keystore; l’abstract JKIISC 2025 décrit extraction dynamique Frida sur « real devices » sans préciser OS, version ou état de verrouillage; le parser ALEAPP 2026 expose des artefacts de préférences sur Android 14/15 mais dit que le déchiffrement DB a échoué sur les clés Keystore matérielles de ses images. Ces résultats ne s’annulent pas : virtualisation, instrumentation, élévation de privilèges, versions et état du téléphone diffèrent ou sont inconnus. Aucun ne prouve un déverrouillage commercial d’un téléphone stock verrouillé. [KISIA](https://www.kisia.or.kr/bucket/uploads/2024/01/25/%5Bkisia%5D%202023%20%EB%8C%80%ED%95%99%EC%A0%95%EB%B3%B4%EB%B3%B4%ED%98%B8%EB%8F%99%EC%95%84%EB%A6%AC%20%EC%84%B1%EA%B3%BC%EC%9E%90%EB%A3%8C%EC%A7%91.pdf), [JKIISC](https://www.kci.go.kr/kciportal/landing/article.kci?arti_id=ART003256904), [ALEAPP](https://github.com/abrignoni/ALEAPP/blob/main/scripts/artifacts/sessionMessenger.py).
- **Expériences nécessaires** : (1) rapprocher finding WOOT → issue/advisory → commit → Android/iOS/Desktop release et effectuer retest indépendant; (2) reproduire build signé vs store; (3) pcap onboarding, messaging, FCM/APNs slow/fast, fichier et appel avec/ sans VPN; (4) observer les candidats ICE et logs TURN; (5) inspecter iOS entitlements/SDK, Android AAB final, push payload; (6) acquisition forensic comparative sur Android 14/15 et versionCodes 372/376/417/419, puis versions stores actuelles, avec modèle/patch/root/verrouillage/état Keystore explicités; comparer XML de préférences, `signal_v4.db`, `session.db`, WAL, `app_parts` et logs, sans assimiler l’extraction de fichiers au déverrouillage; (7) corrélation trafic multi-nœuds sous mesure contrôlée; (8) inventorier DNS/ASN/hosting des endpoints à une date donnée; (9) confirmer transparence/judicial production par dockets et obtenir rapports expurgés si publics. Aucun de ces tests n’est revendiqué comme effectué ici.

## Threema — dossier probatoire approfondi (état documentaire au 13 octobre 2026)

**Convention de lecture.** Chaque ligne sépare ce que les documents établissent (**FACT**), ce que Threema affirme (**VENDOR CLAIM**), ce qu’une source indépendante établit (**INDEPENDENT EVIDENCE**), l’interprétation limitée (**INFERENCE**) et les lacunes (**UNKNOWN**). « FACT » signifie ici fait documentaire attribuable à la source indiquée, et non validation indépendante de son exactitude. Les politiques et rapports de transparence sont des déclarations du fournisseur. Aucune connexion à l’infrastructure, inspection de paquet, analyse de binaire ou reproduction de build n’a été effectuée pour ce dossier.

| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | Clients Android, iOS et desktop; serveurs centraux relaient messages/fichiers; Desktop 2.0 encore en bêta et modèle multi-device en évolution. [Changelog](https://threema.com/en/changelog), [Desktop](https://github.com/threema-ch/threema-desktop/releases) | Serveurs suisses, contenu E2EE; groupes gérés côté clients; appels directs lorsque possible, relais ou SFU de groupe sinon. [Données](https://threema.com/en/faq/data), [appels](https://threema.com/en/faq/calls-info) | Étude universitaire de protocole Ibex et audits de clients (détaillés plus bas) examinent des versions/contextes définis, pas toute l’infrastructure 2026. [Analyse Ibex](https://eprint.iacr.org/2023/1087) | Architecture centralisée pour la remise et les fichiers, avec chiffrement de contenu; infrastructure distincte pour la voix et les appels de groupe. | Topologie complète des serveurs actifs, redondance/régions, architecture production actuelle, contrats de sous-traitance exhaustifs. |
| 2. Protocole cryptographique | Whitepaper daté du 20 avril 2026 décrit primitives NaCl : ECDH Curve25519, XSalsa20, Poly1305, clés 256 bits; Ibex est le protocole de messages moderne. [Whitepaper](https://threema.com/assets/8-press/2026-04-20-threema-cryptography-whitepaper.pdf) | Threema affirme le chiffrement E2EE des messages, appels et pièces jointes; Ibex fournit PFS aux messages avec multi-device désactivé. [Whitepaper](https://threema.com/assets/8-press/2026-04-20-threema-cryptography-whitepaper.pdf) | Analyse académique formelle d’Ibex par Gerhart, Rösler et Schröder (2023); son modèle et ses exclusions ne valent pas audit de l’appareil, de l’infrastructure ni de chaque extension. | Garantie de confidentialité de contenu dépend du mode : la PFS documentée ne s’étend pas au multi-device actuel; aucun élément ici ne démontre résistance post-quantique du contenu. | Vérification du code du protocole 2026 contre le whitepaper, paramètres effectifs par client, résultats de retests après changements, protocole exact de tous les appels de groupe. |
| 3. Création d’identité | Threema ID est un identifiant aléatoire de huit caractères/chiffres lié à une paire de clés; numéro de téléphone et e-mail ne sont pas nécessaires. [ID](https://threema.com/en/faq/threema-id) | L’éditeur présente l’inscription comme anonyme et la clé privée comme conservée localement. | La conception documentée supprime l’obligation de fournir un numéro/e-mail; aucun audit indépendant de l’onboarding actuel n’a été exécuté dans cette phase. | Pas de numéro requis ≠ anonymat : identifiant stable, paiement, store, partage de profil et graphe relationnel peuvent relier l’identité. | Entropie et génération exactes dans les builds actuels, corrélation d’achat/licence ↔ ID, récupération effective de l’identité après réinstallation. |
| 4. Contact discovery | Recherche possible par ID; synchronisation de carnet d’adresses optionnelle. Les permissions contacts Android sont nécessaires seulement si cette fonction est utilisée. [Permissions](https://threema.com/en/faq/android-permissions) | Les adresses sont hashées, transmises de façon chiffrée et les correspondances temporaires supprimées; coordonnées volontairement liées restent révocables. [Politique](https://threema.com/en/privacy_policy/private/extended) | Pas d’analyse indépendante actuelle du protocole de découverte ou de son risque d’énumération/dictionnaire. | Hachage d’un téléphone/e-mail à faible entropie n’assure pas l’anonymat si l’adversaire peut tester des candidats; TLS protège le transport mais pas nécessairement contre le serveur receveur. | Algorithme et sel actuels, nombre de requêtes/rate limits, accès internes aux correspondances, pratiques exactes sur chaque OS/build. |
| 5. Métadonnées serveur | Le service doit acheminer les ID destinataires et voir des paramètres de trafic; messages non remis conservés jusqu’à livraison ou au plus 14 jours. [Stockage](https://threema.com/en/faq/message-storage) | L’éditeur dit ne pas journaliser qui communique avec qui; contacts et groupes sont stockés localement. [FAQ données](https://threema.com/en/faq/data) | Le rapport de transparence indique pouvoir livrer des dates d’inscription/dernière connexion et, dans certains cas, hashes/jetons push; preuve que des champs limités sont disponibles à l’éditeur. [Rapport](https://threema.com/en/transparency-report) | Même sans journal historique de graphe, traitement opérationnel des ID, files de remise et événements push laisse une visibilité transitoire possible. | Journaux techniques internes, corrélation de messages de groupe, durée des métadonnées de remise, accès opérateurs et rétention réelle des backups/logs. |
| 6. IP utilisateur | Les connexions IP arrivent nécessairement aux serveurs de messagerie et aux fournisseurs push; les appels directs et relais ont des chemins différents. | Politique dit ne pas stocker durablement les IP; politique d’appel détaille leur traitement transitoire. [Appels/politique](https://threema.com/en/privacy_policy/private/extended) | Aucune mesure réseau passive de cette enquête; aucune validation externe des délais de suppression. | L’IP est techniquement visible au point de terminaison au moment de la connexion même si non conservée; « pas de logs » est une assertion de rétention, non d’invisibilité. | Journaux d’accès, télémétrie anti-abus, IP de proxy/CDN, exacts délais et cas d’exception légale. |
| 7. Exposition IP au correspondant | Appel individuel peut être P2P ou relayé; l’application permet le réglage « toujours relayer »; appels de groupe passent par un SFU. [Appels](https://threema.com/en/faq/calls-info) | Threema dit qu’un appel direct peut exposer l’IP aux pairs; SFU masque les IP entre participants. | Politique indique que le SFU traite les IP des membres de groupe dès l’envoi du message de démarrage, y compris membres qui ne rejoignent pas l’appel; serveur Leaseweb à Amsterdam, suppression annoncée à la fin. [Politique étendue](https://threema.com/en/privacy_policy/private/extended) | Pour masquer l’IP à un correspondant, désactiver P2P/relayer systématiquement est la mesure documentée; l’IP reste visible au relais/SFU et à l’hébergeur concerné. | Vérification par capture de paquets, comportement par OS/version, candidats ICE, connexions aux membres inactifs, métadonnées exposées au SFU/hébergeur. |
| 8. Messages | Messages E2EE; files d’attente stockent temporairement les messages non livrés, au plus 14 jours selon FAQ. | Après livraison, message supprimé du serveur; historique de conversation local. [Données](https://threema.com/en/faq/data), [rétention](https://threema.com/en/faq/message-storage) | Audits 2019/2020 ont inspecté des clients anciens; ils ne valident pas la version 2026 ni la suppression côté production. | La sécurité en transit ne protège pas contre client compromis, sauvegardes, appareil déverrouillé ou correspondant qui conserve/exporte. | Durée précise en pratique, gestion des accusés, logs/archives d’abus, exact contenu des notificatifs par défaut par OS et version. |
| 9. Groupes | Groupes jusqu’à 256 personnes selon FAQ; liste et gestion de groupe sont côté client. [Groupes](https://threema.com/en/faq/groupchat) | Fournisseur dit ne pas connaître la composition du groupe; messages adressés aux membres. | Analyse protocolaire indépendante publiée sur attaques de groupe Threema (Rösler et al., EuroS&P 2018) et étude Ibex 2023; limites/version à vérifier avant extrapolation. [Recherche Ibex](https://eprint.iacr.org/2023/1087) | Le serveur peut observer les ID de destinataires/événements de remise, même si l’application ne lui envoie pas un objet « groupe » durable; cette inférence n’établit pas la reconstruction complète du graphe. | Format exact des messages de groupe 2026, cloaking des membres, visibilité serveur par destinataire, résistance actuelle aux attaques de groupe publiées. |
| 10. Appels | WebRTC; appels 1:1 direct si possible, option de relais; appels de groupe sur SFU; signalisation par messages Threema. [Appels](https://threema.com/en/faq/calls-info) | Contenu d’appel E2EE; adresse IP directe n’est pas révélée si appel relayé; IP groupe traitée transitoirement par SFU. | Documentation de politique identifie Leaseweb aux Pays-Bas/Amsterdam pour le SFU; aucune capture indépendante. | E2EE du média n’équivaut pas à confidentialité de l’IP, des horaires et des membres potentiellement notifiés. | Codec et chiffrement effectifs par build, configuration TURN/SFU, sous-traitants supplémentaires, journaux et contenu de signalisation en pratique. |
| 11. Fichiers | Pièces jointes chiffrées avant transfert; fichiers en attente peuvent rester sur serveur jusqu’à remise/expiration, jusqu’à 14 jours selon documentation. | Fichiers E2EE; médias de groupe expirent sur le serveur. [Whitepaper](https://threema.com/assets/8-press/2026-04-20-threema-cryptography-whitepaper.pdf) | Étude forensic Android 2022 récupère bases, clés et médias sur appareil rooté avec accès à l’ID/mot de passe ou migration de sauvegarde; preuve historique, non d’une faiblesse de transit. [Étude](https://kr-labs.com.ua/books/1-s2.0-S2666281722000166-main.pdf) | Données déchiffrées existent sur endpoint et peuvent survivre dans caches/WAL/exports même si la copie serveur expire. | Durée réelle serveur par catégorie, suppression serveur vérifiée, fichiers mis en cache sur chaque OS actuel et chiffrement du cache au repos. |
| 12. Multi-device | Threema Desktop 2.0 bêta prend en charge des appareils liés; au plus un téléphone et deux ordinateurs selon FAQ. | Les appareils peuvent fonctionner indépendamment du téléphone; stockage Desktop chiffré localement par mot de passe. [Vue d’ensemble](https://threema.com/en/faq/md-overview) | Documentation actuelle dit que PFS n’est pas prise en charge en multi-device/Desktop 2.0 bêta; build bêta66 publié le 15 sept. 2026. [Support](https://threema.com/en/support/private), [release](https://github.com/threema-ch/threema-desktop/releases) | L’activation du mode peut réduire la garantie PFS sur messages; synchronisation étend les terminaux et lieux d’exposition. | Exact protocole de liaison/révocation, état de PFS par version stable mobile, résistance aux appareils orphelins, récupération après perte. |
| 13. Notifications push | Android peut utiliser Threema Push ou FCM/HMS; iOS s’appuie sur APNs. Le dépôt **Push Relay** public est explicitement un service de notification Threema Web, distinct du push mobile. [Push](https://threema.com/en/faq/privacy-push), [code Push Relay](https://github.com/threema-ch/push-relay) | Pour le mobile, la page support décrit des payloads différenciés; l’éditeur dit retirer les composants de tracking Firebase. | Le code Push Relay montre que le relay Web reçoit token (sauf backend Gateway), hash SHA-256 de la clé publique permanente de l’initiateur (`session`), version protocole et champs optionnels d’affiliation/TTL; le payload vers APNs/FCM/HMS contient hash de session, affiliation optionnelle, epoch Unix et version. Aucun texte de message n’est dans ce schéma. Aucune inspection d’un binaire mobile n’a été faite. [Push Relay README](https://github.com/threema-ch/push-relay) | Fournisseurs push et relay Web peuvent corréler un token/pseudonyme de session à des heures et versions; ceci ne démontre ni liaison au Threema ID en clair, ni historique réellement conservé. Ne pas transposer les champs Web aux payloads mobiles. | Payloads/rétention exacts par Android/iOS/build, mapping token↔ID, logs serveur et présence actuelle de SDK de tracking. |
| 14. Stockage local | Android/iOS stockent conversations, clés, paramètres et médias localement; Desktop 2.0 bêta décrit une base chiffrée par mot de passe. | L’éditeur décrit chiffrement local AES-256 et protection de la clé maîtresse (whitepaper 2026). | Audits Cure53/Münster et étude forensic 2022 ont examiné versions antérieures; résultats historiques ne valident pas le schéma actuel. | Chiffrement au repos protège surtout appareil verrouillé et secret robuste; application ouverte/déverrouillée peut fournir les clés. | Comparaison technique actuelle par OS, gestion des secrets Keychain/Keystore, sauvegardes OS, mémoire, WAL et protection sans verrou d’app. |
| 15. Sauvegardes | Threema Safe inclut ID, contacts, adhésions de groupe et paramètres sélectionnés; exclut historiques chats/médias/photos de profil; sauvegarde périodique et expiration documentée 180 jours sans connexion. [FAQ Safe](https://threema.com/en/faq/threema-safe-interval) | Safe est chiffré; sauvegarde manuelle/migration peut exporter données plus complètes, dont chats et médias, vers archive protégée par mot de passe. [Support](https://threema.com/en/support/private) | Étude 2022 exploite le flux officiel de migration depuis téléphone non rooté vers appareil rooté pour acquérir les fichiers privés; limitation : connaît l’identifiant et, si configuré, secret d’app. | Un backup manuel riche élargit l’attaque aux fichiers/phrase secrète et au stockage choisi; Safe ne remplace pas une sauvegarde des messages. | Schéma exact/crypto de Safe et migration actuels, rétention côté serveur au-delà de la FAQ, pratiques de sauvegarde d’OS/cloud des apps. |
| 16. Analytics / télémétrie / SDK tiers | Les stores déclarent des informations différentes (voir section Mobile). Android a des permissions dépendant des fonctions; services push tiers optionnels/OS. | Threema affirme aucune publicité/trackers et retrait des composants Firebase de suivi; collecte minimale pour crash/diagnostic selon plate-forme. | App Store Apple présente les labels comme déclarés par développeur et non vérifiés par Apple; Google Play Data Safety est aussi déclaration du développeur. Aucun audit de binaire/manifest actuel effectué. | Écart entre labels peut venir des définitions/store/régions et n’établit pas à lui seul une collecte cachée. | SDK et endpoints actifs exacts, opt-in/out analytics, crashes, identifiants persistants, manifeste de la release et flux runtime. |
| 17. Code source | Dépôts officiels publics couvrent clients Android/iOS/Desktop/Web et Push Relay; politique Android/iOS : un commit par release publique non bêta. [Organisation](https://github.com/threema-ch), [Android](https://github.com/threema-ch/threema-android), [iOS](https://github.com/threema-ch/threema-ios), [Desktop](https://github.com/threema-ch/threema-desktop), [Web](https://github.com/threema-ch/threema-web), [Push Relay](https://github.com/threema-ch/push-relay) | Android et iOS sont présentés comme source complète du client; commits PGP signés. | Le README iOS précise que sa dépendance WebRTC s’appuie aussi sur des binaires hébergés par Threema; client Web et Push Relay publics, mais le backend privé de messagerie n’est pas inclus dans ces dépôts. Les pages consultées indiquent `SECURITY.md` pour Android/iOS/Desktop et une procédure GObugfree. | Transparence client utile, mais ne prouve ni correspondance des binaires distribués, ni auditabilité du backend/services d’exploitation, ni provenance des composants binaires. | Liste exhaustive des services backend publics/fermés, URL/hash WebRTC iOS, composants livrés par build/variant, mainteneurs actifs et CVE/advisories privés. |
| 18. Reproductibilité | L’éditeur publie procédure de build reproductible Android et précise que c’est expérimental; il indique que l’iOS n’est pas encore reproductible. [Builds](https://threema.com/en/why-threema/open-source) | Reproduction Android prévue à partir d’un tag, image Docker et outils spécifiés, avec comparaison au APK correspondant. | Aucun build reproductible ni comparaison de hash n’a été exécuté dans cette mission. | « Source public » et « recette reproductible disponible » ne démontrent pas que l’APK/iOS reçu du store provient du source publié. | Résultats par version/ABI/store, reproductibilité Desktop, build iOS, signatures, attestations provenance/SBOM. |
| 19. Supply chain | CI/dépendances visibles dans plusieurs dépôts; Desktop utilise pnpm et dépendances natives Rust/WASM; iOS déclare Swift Package Manager et WebRTC fourni en binaires hébergés par Threema. [Desktop](https://github.com/threema-ch/threema-desktop), [iOS](https://github.com/threema-ch/threema-ios) | Android documente les builds en environnement Docker; commits Android/iOS PGP signés; Desktop permet de produire un package signé si l’environnement de signature est configuré; les tags Web sont annoncés comme signés. | Déclarations des dépôts lues; aucun audit supply-chain, SBOM, vérification CI ou comparaison de provenance des binaires n’a été fait. | Code ouvert et signatures versionnées aident à contrôler des changements, sans éliminer dépendances binaires, registres, CI, clés de signature, stores ou backend. | Origine/hash WebRTC iOS, SBOM, provenance CI, signature effective de chaque binaire/store/tag courant, reproductibilité Desktop et sécurité des mises à jour. |
| 20. Infrastructure | Threema affirme exploiter ses serveurs dans deux centres de données dans la région de Zurich; les docs réseau publient surtout ports/protocoles (5222/443, UDP 3478, groupes UDP 22500–22532) et ne donnent pas de hostname/IP d’API standard. SFU d’appels de groupe annoncé chez Leaseweb à Amsterdam. [Emplacement](https://threema.com/en/support/private), [ports](https://threema.com/de/faq/ports), [appels](https://threema.com/en/privacy_policy/private/extended) | Le fournisseur décrit rétention IP courte et suppression de données de service dans ses politiques. | Aucun DNS/ASN/certificat actuel n’a pu être attribué de façon défendable faute de FQDN d’endpoint service public dans les docs consultés; la FAQ firewall Work n’est pas automatiquement transposable à Private. | L’emplacement des deux datacenters et du SFU ne cartographie pas CDN/DNS/push, réplication, sauvegardes ou juridictions des tiers Apple/Google. | Hostnames/IP/ASN de service, régions de chaque flux, CDN, rétention effective, tiers autres que SFU, changements après acquisition. |
| 21. Juridiction | Threema AG et serveurs annoncés en Suisse; société mère passée à Comitis Capital (Allemagne) au début 2026; l’opération du service reste suisse. [Propriété](https://threema.com/en/faq/owners) | Threema explique être principalement assujettie au droit suisse; RGPD peut s’appliquer à traitement de résidents UE selon contexte. | Droit suisse actuel de surveillance inclut les fournisseurs AAKD dans son champ; les obligations précises varient et ne sont pas automatiquement identiques à celles d’un opérateur télécom. [Autorité suisse](https://www.li.admin.ch/de/pflichten) | Être suisse ou propriété allemande ne garantit ni immunité étrangère, ni remise automatique; assistance judiciaire internationale et ordres suisses importent. | Avis juridique sur les obligations concrètes et seuils de Threema après réforme; conflits de lois et demandes reçues non publiées individuellement. |
| 22. Demandes policières | Rapport officiel : 423 demandes en 2025, 402 cas ayant conduit à des informations pour 1 505 IDs; du 1 janv. au 30 juin 2026 : 444 demandes, 438 cas avec données pour 2 026 IDs. [Rapport](https://threema.com/en/transparency-report) | Threema dit fournir seulement données disponibles (notamment date de création/dernière connexion sans heure, hash coordonnées si volontairement liées, push token sous conditions), pas de contenu de message. | Les comptes agrégés établissent des divulgations réelles d’informations d’identité limitée; aucun dossier individuel source n’établit les champs transmis dans chaque cas. | « Aucune métadonnée conservée » ne signifie pas « aucune donnée jamais remise »; le type exact et la provenance doivent être séparés. | Réponses ligne à ligne, ordonnances/mandats expurgés, partages étrangers, demandes urgentes, données hors transparence, demandes concernant contenu/appareils tiers. |
| 23. Affaires judiciaires connues | Tribunal fédéral suisse, affaire 2C_544/2020 (29 avr. 2021), a confirmé la classification Threema comme fournisseur dérivé (AAKD), pas TSP; droit actuel a depuis précisé le champ AAKD. [Décision](https://www.bger.ch/ext/eurospider/live/de/php/aza/http/index.php?highlight_docid=aza%3A%2F%2F29-04-2021-2C_544-2020&lang=de&type=show_document) | Threema a présenté la décision comme confirmation d’obligations de données limitées, et non comme immunité générale. | Rapport Eurojust sur Kuciak décrit données Threema déchiffrées admises dans une procédure; indictment DOJ Wedding 2024 reproduit contenu/captures de groupes, mais n’établit pas que Threema les a livrés. [Eurojust](https://www.eurojust.europa.eu/sites/default/files/assets/joint-ep-ej-third-report-of-the-observatory-function-on-encryption-en.pdf), [DOJ](https://www.justice.gov/opa/media/1418931/dl?inline=) | Ces exemples attestent la disponibilité de contenu depuis appareils/participants dans un dossier, non une remise de contenu par le fournisseur. | Résultat d’appel Kuciak postérieur au rapport, origine exacte des données DOJ, subpoenas/production orders et décisions expurgées individualisées. |
| 24. Audits | Audits Münster (2018–19), Cure53 (2020, 2024 Desktop) et analyses académiques Ibex/groupe existent; les extractions disponibles sont détaillées ci-dessous et dans la section « Audits lus en détail ». | Fournisseur annonce fixes dans releases après certains constats. | Les rapports donnent versions testées, findings et limites; pas de retest indépendant courant identifié après les corrections annoncées. | Audit daté et borné n’est ni certification permanente ni preuve de vulnérabilité actuelle. | Retests publics, audit complet de versions 2026, backend, mobile actuel, SFU, supply chain et indépendance des correctifs. |
| 25. Vulnérabilités | Rapports historiques signalent notamment divulgation de fichiers via Android share intent, fragments de mot de passe Safe dans logs (2019), défauts locaux divers (2020), et vulnérabilités/faiblesses Desktop 2.0 bêta (2024). | Threema indique corrections dans des versions ultérieures pour les findings listés. | Findings publiés par auditeurs indépendants, mais limites et retours de correction sont décrits dans les rapports; aucun exploit actif actuel établi ici. | Les findings historiques concernent versions et conditions de test précises; on ne les transpose pas à 2026 sans repro. | CVE/advisories complets, état actuel de chaque finding, retests, vulnérabilités non publiques, réponse du programme de bug bounty. |
| 26. Recherche académique | Étude formelle d’Ibex publiée 2023; études de sécurité de groupe antérieures; forensics Android publié 2022; thèse Mittweida publiée 2024. | Le fournisseur présente les résultats cryptographiques formels comme une validation du design Ibex. | La formalisation précise propriétés et hypothèses; étude forensic décrit extraction sur Android anciens avec conditions connues, pas Cellebrite/GrayKey actuels. [Ibex](https://eprint.iacr.org/2023/1087), [forensics](https://kr-labs.com.ua/books/1-s2.0-S2666281722000166-main.pdf) | Plusieurs familles de preuves existent mais ne couvrent pas ensemble toute la stack, les builds et les versions actuelles. | Réplications indépendantes récentes, protocoles d’appels, serveur, device-state forensic contemporain et publications non indexées. |
| 27. Incidents historiques | Dossier public comprend findings d’audits, changements d’actionnariat 2026 et divulgations légales agrégées; pas d’incident massif de compromission Threema confirmé par les sources consultées. | Fournisseur affirme absence de tracking/stockage durable de nombreuses données. | « Aucun incident retrouvé » n’est pas preuve d’absence; les rapports d’audit sont des constats, pas des incidents exploités en production. | Conserver distinction entre défaut, exploitation observée, panne, demande légale et transfert commercial. | Historique exhaustif de fuites, incidents internes, accès employés, bugs silencieux, indisponibilités, réponses CERT. |
| 28. Gouvernance / société / financement | Société opérationnelle Threema GmbH/AG suisse; acquéreur Comitis Capital depuis début 2026 selon page officielle. [Propriété](https://threema.com/en/faq/owners) | Éditeur dit que siège et serveurs restent en Suisse, équipe et service continuent. | Le changement de contrôle est confirmé par page de l’entreprise; aucune analyse financière indépendante/de gouvernance consultée. | Domiciliation et contrôle capitalistique sont deux faits distincts; changement d’actionnaire ne prouve pas changement de politique ni absence d’influence. | Conditions de financement, gouvernance et droits du nouvel actionnaire, bénéficiaires effectifs détaillés, clauses de transfert, audits post-acquisition. |
| 29. Résistance à la censure | Service centralisé nécessaire aux comptes/remises; clients distribués en magasins publics; il existe plusieurs modes push et destinations/serveurs. | Aucune promesse de résistance forte à un État censeur établie dans les sources examinées. | Aucun test OONI/DPI ni campagne de mesure géographique effectuée ici. | Les mécanismes de relais/région peuvent résister à certains blocages d’IP, mais domaine, DNS, stores, push et service central restent des points de censure. | Disponibilité dans pays bloquants, domaines miroirs, bootstrap alternatif, ordre de blocage, tests de connectivité et canaux de distribution. |
| 30. Maintenance actuelle | Changelog consulté : iOS 7.4.1 le 6 oct. 2026, Android 6.5.3 le 23 sept., Desktop 2.0 beta66 le 15 sept.; desktop reste bêta. [Changelog](https://threema.com/en/changelog), [Desktop releases](https://github.com/threema-ch/threema-desktop/releases) | L’éditeur présente les releases comme maintien actif et ajoute des protections Desktop (ex. capture/Recall selon notes). | Repos publics ont activité/release récente; iOS repo n’expose pas de releases GitHub, et aucune analyse du volume réel de maintainers n’a été faite. | Releases récentes prouvent activité, pas niveau de support, temps de correction ni maintien homogène des clients. | Nombre de mainteneurs actifs par produit, SLA de vulnérabilités, releases store par région, maintenance backend et durée support des versions. |

### Threema — audits et analyses : extraction des résultats, scope et retests

Les rapports historiques sont référencés et détaillés dans « Audits lus en détail — Briar, Threema et Delta Chat » plus haut dans ce fichier; ce paragraphe rassemble la fiche de portée pour ne pas les confondre avec un audit 2026.

| Organisme / date | Version / commit | Durée / méthode | Scope et exclusions établis | Findings / sévérité | Recommandations, correctifs et retest |
|---|---|---|---|---|---|
| Université de Münster, rapport du 28 mars 2019 | Android 3.54, iOS 3.0.9; audit Threema Safe Android; commits exacts non publiés dans les éléments consultés | 22 personne-jours; revue de code/tests applicatifs. | Apps sélectionnées et Safe; backend serveur hors scope; pas d’attestation de la chaîne de build ou retest actuel. | Deux findings medium et plusieurs low/informational; un intent Android pouvait faire partager un fichier privé potentiellement sensible après action/interaction utilisateur; fragments de secret Safe apparaissaient dans logs. | Rapport recommande durcissement des intents et suppression des données sensibles des logs. Éditeur annonce fixes Android 3.62/iOS 4.1; aucun retest indépendant documenté dans la source. |
| Cure53, 30 octobre 2020 | Clients Android/iOS et libs NaCl/Sodium des versions testées; versions exactes consignées dans rapport antérieur, pas de SHA de release pour toutes. | 4 testeurs, 16 personne-jours; revue white-box, tests sur Android 9/root et émulateurs, iOS 13.3.1 jailbreaké. | Clients mobiles et cryptographic libraries dans les limites du mandat; pas d’infrastructure backend, ni builds 2026. | Huit issues, une medium et sept info/low; le rapport ne qualifie pas les issues identifiées de vulnérabilités exploitables dans le cadre du test. | Recommandations techniques par issue dans rapport; statut de corrections déclaré pour certains points; pas de campagne publique de retest Cure53 ultérieure établie ici. |
| Cure53, janvier 2024 | Threema Desktop 2.0 Beta 26; commit exact du build testé non indiqué dans la synthèse publique consultée. | 5 testeurs seniors, 16 jours ouvrés, semaines calendrier 03–04/2024; test white-box. | Client desktop bêta; ne certifie pas backend, client mobile, stores, système d’update dans toutes configurations ni version bêta66/production actuelle. | Trois vulnérabilités et quatre faiblesses générales; rapport classe les issues par sévérité et décrit impact/remédiation (détails déjà transcrits dans la section d’audit). | L’éditeur a publié des correctifs après findings selon le rapport; aucune confirmation d’un retest externe sur beta66 n’a été trouvée. |
| Analyse académique Ibex, Gerhart/Rösler/Schröder, 2023 | Spécification/protocole Ibex étudié au moment de l’article; commit de chaque client non applicable/non établi. | Analyse formelle/modèle cryptographique, pas pentest temporel du produit complet. | Propriétés de protocole sous hypothèses explicites; groupes/multi-device et sécurité endpoint/infrastructure ne sont pas couverts comme audit complet. | Résultats de sécurité formelle dans le modèle étudié; les propriétés ne couvrent pas les modes et hypothèses exclus. | Ne constitue pas une liste de fixes produit ou un retest de binaire; reste complémentaire aux tests d’implémentation. |
| Forensic Science International: Digital Investigation, Son et al., mars 2022 | Threema Android 4.55; essais sur Android 9/10 non rootés et Android 11 rooté, Nox Android 7/9; acquisition réalisée avec outils OS/ADB, pas Cellebrite/GrayKey/Magnet. | Étude expérimentale de forensic sur instances et backups de test; méthodes de migration officielle et ADB. | Analyse base `threema4.db`, DB nonce, `key.dat`, `msgqueue.ser`, private key, préférences, caches et pièces jointes; ne démontre pas contournement de mot de passe inconnu ni capacité actuelle des outils commerciaux. | Données locales et médias déchiffrables avec matériel/conditions d’accès indiqués; sans secret d’app lorsque verrou activé, les auteurs n’ont pas cassé le verrou; migration officielle d’un téléphone non rooté vers appareil rooté facilite l’acquisition si les secrets nécessaires sont disponibles. | C’est une méthode d’acquisition historique, pas un finding cryptographique ni preuve d’extraction « à distance ». Aucun retest sur versions 2026. [PDF](https://kr-labs.com.ua/books/1-s2.0-S2666281722000166-main.pdf) |

**Précision sur les outils forensiques.** Dans les sources examinées, aucune démonstration publique récente n’associe précisément un modèle commercial **Cellebrite, GrayKey ou Magnet + version d’outil + version Android/iOS + build Threema actuel + date**. L’étude 2022 n’utilise aucun de ces produits. Une thèse de 2024 observe `ThreemaData.sqlite` et `Threema.sqlite-wal`, mais n’établit pas une décryption, une récupération d’éléments supprimés ni un bypass; les versions exactes d’appareil/app ne sont pas suffisamment spécifiées dans l’index de thèse. [Thèse](https://monami.hs-mittweida.de/frontdoor/index/index/year/2024/docId/15018). Il serait donc trompeur de présenter une ancienne méthode Android root/ADB comme capacité actuelle d’un outil commercial ou sur iPhone verrouillé.

### Threema — repositories publics, chaîne de build et périmètre fermé

Lecture directe des pages et README de dépôts le 14 octobre 2026, sans clone ni build local. Les politiques de release ci-dessous sont celles annoncées par les mainteneurs; les compteurs GitHub reflètent un instantané de plateforme, pas un effectif d’ingénieurs actifs.

| Dépôt / surface | Faits établis dans les dépôts publics | Limite probatoire |
|---|---|---|
| Android | Le README décrit le source complet de l’app, un commit par release publique non-bêta et commits signés PGP. Il localise le cœur métier dans `domain/`; variantes `store_google`, `hms`, `store_threema`, `libre` ont des intégrations différentes, notamment push propriétaire et auto-updater absents de `libre`. Une procédure de build reproductible est publiée et qualifiée d’expérimentale. [README](https://github.com/threema-ch/threema-android) | L’usage des serveurs officiels requiert une licence; aucun APK Play/Shop n’a été comparé à un build local. Le commit signé ne prouve pas la provenance du binaire distribué. |
| iOS | Le README annonce source complet, un commit par release publique non-bêta et signatures PGP. Il mentionne Swift Package Manager et une dépendance WebRTC basée aussi sur des binaires hébergés par Threema. La reproductibilité iOS est à l’étude en raison de contraintes Apple. [README](https://github.com/threema-ch/threema-ios) | URL, version/hash, provenance et procédure de revue du binaire WebRTC de chaque release non établis ici; aucun IPA comparé. |
| Desktop 2.0 | Dépôt public AGPL avec historique complet depuis la release; recettes de build/packaging et dépendances pnpm, Rust/WASM visibles. Le README dit que la signature d’un package nécessite de configurer l’outillage approprié. [README](https://github.com/threema-ch/threema-desktop) | Pas de preuve que tous les artefacts publiés sont signés ou reproductibles; aucune comparaison entre beta66 et l’artefact distribué. |
| Threema Web | Le dépôt dit que le client utilise WebRTC (Android) ou WebSocket chiffré (iOS), avec SaltyRTC pour signalisation/données; il est en « maintenance mode » pendant le développement de Desktop 2.0 : corrections critiques/maintenance oui, nouveautés majeures et corrections non critiques non. La README mentionne des tags signés par une clé PGP dont l’expiration indiquée est le 4 septembre 2026. [README](https://github.com/threema-ch/threema-web) | La date d’expiration passée exige de vérifier rotation/révocation de clé; elle n’invalide pas rétroactivement des signatures antérieures. Les URLs observées dans un log d’incident 2021 ne prouvent pas les hostnames actuels. |
| Push Relay (Web) | Service Rust public qui relaie les demandes vers APNs/FCM/HMS/Gateway; arborescence consultée expose CI, `Cargo.lock` et protocole détaillé. [README](https://github.com/threema-ch/push-relay) | Un code public ne prouve pas le déploiement courant ni la rétention réelle; aucun `SECURITY.md` ne figurait dans la liste racine observée, sans conclure à l’absence de canal privé de signalement. |

**Activité et mainteneurs.** Les pages GitHub consultées montraient des mises à jour récentes en 2026 pour Android, iOS, Desktop, Web et Push Relay; le dépôt Web annonce pourtant une maintenance limitée, ce qui n’équivaut pas à une cessation. L’organisation n’expose pas ses membres publiquement. Les listes de contributeurs, commits de release et compteurs ne permettent donc pas de donner un chiffre fiable de mainteneurs actifs sans analyse d’historique/identités de bots, qui n’a pas été menée. Aucun backend de messagerie complet, SBOM, attestation de provenance CI ou de build du backend n’a été établi comme public dans cette enquête.

**Endpoint de répertoire et OSINT borné.** Une bibliothèque tierce non affiliée, archivée en mai 2025, décrit une API REST opérée par Threema pour récupérer une clé publique à `https://api.threema.ch/identity/{ID}`; elle dit également que l’API d’enregistrement n’est pas publique. [Dépôt tiers](https://github.com/karalabe/go-threema). Cela établit une référence publique à un endpoint de répertoire, pas que le client privé courant l’utilise encore ni qu’il s’agisse de l’API de chat. La résolution DNS ciblée n’a pas été obtenue dans cette passe (accès réseau refusé); aucun ASN actuel n’est donc attribué. Un ancien journal d’incident Threema Web de 2021 mentionne des hôtes `saltyrtc-*`, `ds-turn-*` et `push-web.*`, mais ces noms sont historiques et ne doivent pas être présentés comme actifs aujourd’hui. [Exemple de log historique](https://github.com/threema-ch/threema-web/issues/996)

### Threema — stores mobiles, permissions et télémétrie

- **Google Play (Android)** : Data Safety indique « aucune donnée collectée » selon déclaration du développeur; cette déclaration n’est pas une inspection indépendante du binaire. [Fiche Google Play](https://play.google.com/store/apps/details?id=ch.threema.app)
- **Apple App Store (iOS)** : labels développeur déclarent coordonnées (téléphone/e-mail) et identifiants liés à l’utilisateur, ainsi que diagnostics/crash non liés; Apple affiche que ces informations ne sont pas vérifiées. La région/fiche consultée est l’App Store Irlande. [Fiche App Store](https://apps.apple.com/ie/app/threema-the-secure-messenger/id578665578)
- Les deux déclarations divergent en surface avec « aucune donnée collectée »/« aucun tracker »; elles peuvent refléter les définitions de store, les plateformes, crash reporting ou fonctions optionnelles, et ne suffisent ni à conclure à une collecte cachée ni à l’exclure. Réconciliation impossible sans version/build, déclaration datée, manifest/entitlements et tests réseau.
- Permissions documentées Android : Contacts pour synchronisation, caméra QR, micro appels/messages vocaux, localisation si partage demandé, stockage/médias pour fichiers, état d’appel pour gérer un appel téléphonique concurrent. [Permissions Android](https://threema.com/en/faq/android-permissions). Cette liste de besoins fonctionnels ne prouve pas que chaque version demande/obtient effectivement toutes ces permissions.
- L’éditeur affirme que Firebase Analytics/tracking components ont été supprimés du client Android; push FCM/HMS/APNs restent des tiers possibles selon mode. Aucun manifest/AAB/IPA ni liste de SDK de la release actuelle n’a été extrait ici. Pour contacts/photos/localisation, l’accès est décrit comme déclenché par fonctions; aucun test runtime de permission OS n’est revendiqué.

### Threema — loi, production effective et affaires

**Ce qui a effectivement été communiqué.** Le rapport officiel compte 402 dossiers avec transmission d’informations concernant 1 505 IDs en 2025, puis 438 dossiers concernant 2 026 IDs au premier semestre 2026. Les catégories publiées sont essentiellement dates de création/dernière connexion (sans heure), hashes de coordonnées volontairement liées, et jetons push sous conditions. Cela établit une production agrégée de données dans des cas réels; ne prouve ni remise de contenu de messages, ni champs remis dans un cas individuel, ni saisie d’appareil. [Transparency report](https://threema.com/en/transparency-report)

La décision suisse **2C_544/2020** de 2021 traite de la classification d’un service comme AAKD et non TSP au regard du droit alors en cause. La page officielle actuelle de l’autorité de surveillance décrit les AAKD comme inclus dans le champ BÜPF, avec devoirs possibles qui varient selon catégorie, importance économique et seuils. Ainsi, l’arrêt n’est pas une immunité générale et le seuil invoqué par l’entreprise sur la conservation générale de métadonnées ne signifie pas qu’aucune ordonnance ciblée ne puisse être exécutée. Le projet de révision VÜPF évoqué en 2026 reste un processus réglementaire distinct, non une règle déjà entrée en vigueur. [Autorité suisse](https://www.li.admin.ch/de/pflichten), [état de la révision](https://www.estv.admin.ch/de/newnsb/EXv-JkPBAZuL)

Dans l’affaire Kuciak, un rapport Eurojust décrit des données Threema déchiffrées provenant du dossier; les données étaient exploitées en procédure, mais cela n’établit pas une remise par Threema. Dans l’acte d’accusation américain Wedding (2024), captures/contenus de groupes Threema figurent comme pièces ou éléments du récit; source exacte (participant, appareil saisi, autre) et éventuelle assistance du fournisseur ne sont pas établies par l’acte lui-même. Ce sont des cas d’accès au **contenu**, mais pas preuve d’une production serveur de contenu par Threema.

### Threema — métadonnées par observateur

Les statuts indiquent visibilité/capacité documentée, pas remise garantie ni conservation réelle dans un dossier donné. **NON ACCESSIBLE PAR DESIGN** décrit la propriété annoncée et non une garantie contre compromission/collusion.

| Métadonnée | Fournisseur | Contact | ISP | Apple/Google | Autorités |
|---|---|---|---|---|---|
| IP | **PROBABLE** visible pendant la session; absence de conservation durable est une déclaration du fournisseur; **CONFIRMÉ** temporairement pour traitement des appels selon politique | **CONFIRMÉ** en appel P2P; **NON ACCESSIBLE PAR DESIGN** si appel relayé/SFU selon déclaration | **CONFIRMÉ** IP source, destinations, horaires et volumes | **CONFIRMÉ** par requête push et token en contexte APNs/FCM/HMS | **CONFIRMÉ** pour certains jetons push/date d’activité remis en agrégat publié; IP par ordres aux tiers possible, pas de remise individuelle retrouvée |
| Téléphone | **POSSIBLE** si l’utilisateur le lie; fournisseur dit ne garder que hash selon fonction | **POSSIBLE** via contact partagé/profil/hors application | **NON ACCESSIBLE PAR DESIGN** dans le seul flux IP; opérateur mobile identifie son abonné | **POSSIBLE** au compte store/opérateur, association avec ID Threema inconnue | **POSSIBLE** auprès opérateur/store ou si lié volontairement; cas individuel non public |
| E-mail | **POSSIBLE** si lié volontairement; hash annoncé | **POSSIBLE** si partagé | **NON ACCESSIBLE PAR DESIGN** depuis le seul flux app | **POSSIBLE** compte Apple/Google | **POSSIBLE** via fournisseur si lié/haché ou tiers; champ précis communiqué inconnu |
| Identifiant | **CONFIRMÉ** ID source/destinataire nécessaire au routage; clé publique au serveur selon FAQ | **CONFIRMÉ** ID affiché/associé au contact | **POSSIBLE** corrélation de destination réseau, pas nécessairement ID lisible si contenu chiffré | **POSSIBLE** token/app ID, mapping ID Threema non documenté | **CONFIRMÉ** date de création/dernière connexion de certains IDs divulguée; ID de compte connu par rapport au dossier |
| Graphe social | **PROBABLE** métadonnées de remise/timing permettent corrélations; fournisseur affirme ne pas conserver qui parle à qui | **CONFIRMÉ** avec les contacts et groupes auxquels il appartient | **POSSIBLE** par timing/volume, pas par contenu E2EE seul | **POSSIBLE** via notifications/timestamps; graphe non établi | **POSSIBLE** par métadonnées tiers, appareils, contacts ou correspondants; cas public précis non identifié |
| Timestamps | **CONFIRMÉ** pour création/dernière connexion (date sans heure) dans divulgations; timing des requêtes nécessaire au service | **CONFIRMÉ** timestamps locaux des messages | **CONFIRMÉ** horaires de connexion/routage | **CONFIRMÉ/PROBABLE** horodatage/token de notification | **CONFIRMÉ** pour catégories date-only communiquées; heures et historiques individuels non établis |
| Volumes | **PROBABLE** taille/cadence transportables par l’infrastructure; conservation inconnue | **CONFIRMÉ** nombre/taille des messages et médias reçus | **CONFIRMÉ** octets et durée des connexions | **PROBABLE** taille et cadence de payload push | **POSSIBLE** par ISP/push/appareil; production réelle inconnue |
| Groupes | **PROBABLE** destinataires et événement de remise observables; fournisseur dit que composition n’est pas connue durablement | **CONFIRMÉ** membres/contenu côté participant | **POSSIBLE** par formes de trafic, pas liste directe | **POSSIBLE** notification de groupe; champs exacts diffèrent selon OS | **POSSIBLE** par appareils, participants, appels et tiers; aucune remise groupe serveur documentée ici |
| Appareils | **PROBABLE** appareils liés et statuts de push requis pour service; inventaire/rétention inconnu | **POSSIBLE** inférence d’usage par appareil | **CONFIRMÉ** connexions distinctes observées par IP/réseau | **CONFIRMÉ** token rattaché à installation/appareil | **POSSIBLE** via fournisseurs push/stores ou appareils saisis; remise Threema individualisée non établie |
| Push tokens | **CONFIRMÉ** jetons mobile traités selon le mode; Push Relay Web reçoit le token et le hash de session de requête selon code public; rétention inconnue | **NON ACCESSIBLE PAR DESIGN** au correspondant | **NON ACCESSIBLE PAR DESIGN** token, mais destination push et timing peuvent être observés | **CONFIRMÉ** token au service APNs/FCM/HMS | **CONFIRMÉ** des push tokens figurent parmi les catégories déclarées communicables sous conditions; cas nominatif public inconnu |

### Threema — première colonne de matrice TM1–TM15

Évaluation provisoire par scénario. Les catégories ne constituent pas encore un classement comparatif; les autres colonnes restent à documenter.

| Modèle | Cellule | Justification courte et source |
|---|---|---|
| TM1 — fournisseur curieux | 🟡 | Contenu chiffré E2EE mais ID, routage, données de compte limitées et IP au transport; fournisseur annonce absence de graphe conservé. [FAQ données](https://threema.com/en/faq/data), [transparence](https://threema.com/en/transparency-report) |
| TM2 — fournisseur compromis | 🟡 | Chiffrement contenu limite l’accès direct au message, mais serveur, fichiers en attente, clés publiques, push et signalisation/metadata restent surfaces; backend non audité indépendamment dans ce dossier. |
| TM3 — fournisseur malveillant | 🟡 | Il peut observer routage/ID et éventuellement manipuler disponibilité; authenticité dépend vérification de clé/contact. Les preuves disponibles ne démontrent pas attaque actuelle de substitution, mais aucun audit serveur actuel n’est fourni. |
| TM4 — ISP / Wi‑Fi | 🟠 | IP, destinations, horaires et volumes visibles; TLS/E2EE protège le contenu. VPN/Tor tiers peut changer l’observateur IP mais transfert la confiance. |
| TM5 — surveillance passive multi-points | 🟠 | Une observation côté ISP, push et service peut corréler timings; pas d’étude expérimentale actuelle prouvant/quantifiant la résistance. |
| TM6 — adversaire global passif | 🔴 | Pas de mixnet ni preuve de protection contre corrélation globale; trafic centralisé et temps/volumes constituent une surface. **Inference d’architecture**, pas mesure expérimentale. |
| TM7 — correspondant malveillant | 🟠 | Le correspondant voit contenu, identité stable, fichiers et heures; appel P2P peut révéler IP; appel relayé réduit l’exposition directe. [Appels](https://threema.com/en/faq/calls-info) |
| TM8 — harceleur/doxxer OSINT | 🟡 | Pas de coordonnées obligatoires, mais Threema ID persistant, choix de profil/partage et synchronisation optionnelle peuvent être reliés. [ID](https://threema.com/en/faq/threema-id) |
| TM9 — demande judiciaire classique | 🟠 | Des divulgations effectives de données sur 1 505 IDs en 2025 et 2 026 IDs au S1 2026 sont rapportées; champs de cas individuels et contenu non établis. [Rapport](https://threema.com/en/transparency-report) |
| TM10 — enquête sophistiquée | 🟠 | Tiers push, ISP, sauvegardes, endpoint et correspondants peuvent fournir des données hors serveur E2EE; l’affaire Kuciak montre contenu déchiffré dans un dossier sans prouver une remise fournisseur. [Eurojust](https://www.eurojust.europa.eu/sites/default/files/assets/joint-ep-ej-third-report-of-the-observatory-function-on-encryption-en.pdf) |
| TM11 — appareil verrouillé saisi | ❓ | Étude Android 4.55 date de 2022 et ne contourne pas un verrou inconnu; aucun test public courant modèle commercial + version outil + OS + Threema actuel trouvé. [Étude](https://kr-labs.com.ua/books/1-s2.0-S2666281722000166-main.pdf) |
| TM12 — appareil déverrouillé | 🔴 | Contenu déchiffré est affiché et stocké dans client; acquisition Android historique récupère DB, clés et médias sous conditions d’accès. Endpoint non protégé par E2EE contre utilisateur/outils autorisés. |
| TM13 — spyware ciblé | 🔴 | Malware avec accès au processus, écran, mémoire ou fichiers peut capturer avant/après chiffrement; pas de claim qu’E2EE protège un terminal compromis. |
| TM14 — supply chain compromise | 🟠 | Clients Android/iOS publics et Android builds reproductibles expérimentaux, mais aucune reproduction réalisée; iOS non reproductible annoncé et serveur central n’est pas établi public. [Open source/builds](https://threema.com/en/why-threema/open-source) |
| TM15 — censure étatique | 🟠 | Service central, DNS/stores/push et hébergeurs sont points de blocage possibles; aucun test pays/DPI/mesure OONI effectué. |

### Threema — contradictions et questions expérimentales

- **« Aucune donnée collectée » (Google Play) vs labels iOS** : Play indique aucune collecte, tandis qu’Apple affiche téléphone/e-mail, identifiants et diagnostics déclarés par le développeur. Ce n’est pas une preuve de malhonnêteté : les définitions et fonctionnalités diffèrent, mais la divergence est non résolue sans manifest/entitlements, builds et captures réseau.
- **« Pas de métadonnées » vs données remises** : absence revendiquée de conservation d’un graphe ne contredit pas nécessairement traitement transitoire et production de date de création/dernière connexion, hashes de coordonnées et jeton push. Il faut préciser champ, source et fenêtre de rétention.
- **Suisse / décision 2021 vs droit 2026** : 2C_544/2020 n’est pas une garantie qu’aucun ordre ne peut contraindre le service. Le cadre officiel actuel inclut les AAKD avec obligations conditionnelles; ne pas confondre absence de conservation générale avec impossibilité d’ordre ciblé.
- **E2EE vs fuite d’IP en appel** : le chiffrement du média ne masque pas l’adresse IP à un pair sur P2P. En groupe, le SFU peut traiter IP de personnes notifiées mais absentes; c’est une exposition d’infrastructure distincte du contenu.
- **Open source vs reproductible** : Android a une recette de builds dite expérimentale, iOS pas encore; aucun hash binaire n’a été reproduit ici. La disponibilité du source ne ferme pas le risque store/CI/backend.
- **Recherche judiciaire vs remise fournisseur** : les contenus Kuciak/Wedding sont documentés comme éléments de dossiers, mais la provenance fournisseur n’est pas établie; la transparence agrégée, elle, établit que des métadonnées limitées ont été communiquées dans des affaires.
- **Expériences nécessaires** : (1) produire/reproduire APK Android actuel et comparer au store; extraire manifests/permissions/SDK; (2) faire de même pour iOS via inspection autorisée; (3) capturer onboarding, sync contacts, DM, groupe, fichier, push lent/rapide, appel P2P/relay et appel de groupe; (4) observer IP, payloads et destinations sous chaque OS; (5) effectuer retest indépendant des commits correctifs des rapports Münster/Cure53 contre versions actuelles; (6) vérifier desktop beta66 vs source et la protection PFS multi-device; (7) test forensic contrôlé avec appareil/modèle/OS/build/app/tool exacts, verrouillé puis déverrouillé, en préservant chaîne de preuve; (8) corréler chaque disclosure légale avec dossier/ordre si documents deviennent publics; (9) DNS/ASN/CDN passif daté des endpoints réellement observés, sans scan; (10) mesurer censure par pays depuis sondes consenties. Rien de cela n’est revendiqué comme effectué ici.

## Wire — dossier de preuves individuel (référence : 13 octobre 2026)

### Registre de preuves en 30 catégories

Chaque ligne sépare le fait documentaire du discours éditeur et de l’inférence. « Inconnu » signifie que les sources consultées ne permettent pas de conclure, non que la donnée n’existe pas.

| # / catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | Wire Cloud est un service centralisé avec backends, bases, DNS, relais d’appel et files de remise; le serveur est publié sous licence open source. Wire documente aussi l’auto-hébergement et la fédération entre backends. [Architecture](https://docs.wire.com/latest/understand/federation/architecture.html), [serveur](https://github.com/wireapp/wire-server) | Wire présente son cloud comme hébergé en Europe et offre du cloud privé / on-prem à des clients entreprise. [Options](https://wire.com/en/deployment-options) | La documentation de déploiement exige plusieurs services (API, asset store, webapp, comptes; optionnels SFT/fédération); ce n’est pas un réseau pair-à-pair. [DNS/deploiement](https://docs.wire.com/latest/how-to/install/includes/helm_dns-ingress-troubleshooting.inc.html) | Le mode personnel public concentre le pouvoir opérationnel chez Wire; un backend privé déplace la confiance vers l’administrateur client. | Architecture physique exacte du Wire Cloud courant, concentration réelle par compte, mécanisme de consensus/indépendance des fédérations, topologie de secours. |
| 2. Protocole cryptographique | Documentation de sécurité distingue Proteus et MLS. Proteus combine Double Ratchet, préclés/X3DH, X25519, ChaCha20, HMAC-SHA256, HKDF et Ed25519. MLS est l’autre protocole E2EE documenté; la mise à jour standard vers MLS est annoncée le 24 mars 2026. [Whitepaper](https://wire.com/hubfs/Whitepapers/-wire-security-whitepaper.pdf), [migration MLS](https://support.wire.com/hc/en-us/articles/12434725011485-Messaging-Layer-Security-MLS), [RFC 9420](https://www.rfc-editor.org/rfc/rfc9420) | Wire annonce E2EE, forward secrecy et post-compromise recovery selon protocole/configuration. | La thèse ETH 2023 a trouvé des attaques de sécurité dans l’intégration Proteus de l’époque et des problèmes de conception de l’intégration MLS alors en développement; elle ne teste pas le produit de 2026. [Thèse](https://doi.org/10.3929/ethz-b-000673362) | La présence d’un standard MLS ne prouve pas que tous les clients, conversations, appels et versions utilisent partout un même profil; une transition coexistante Proteus/MLS reste documentée. | Build courant et sélection du protocole par plateforme/type de conversation; paramètres MLS, ciphersuites réellement négociées après retrait de Kyber, garanties d’authentification/PCS par mode. |
| 3. Création d’identité | Pour le compte Messenger, la politique exige username, email et mot de passe; inscription par double opt-in; Wire peut conserver horodatages de création/vérification et IP d’inscription. Les comptes entreprise peuvent employer SAML/SSO. [Politique](https://wire.com/en/privacy-policy), [whitepaper sécurité](https://wire.com/hubfs/Whitepapers/-wire-security-whitepaper.pdf) | Wire dit qu’email et mot de passe sont utilisés pour assurer le compte et que des informations de profil supplémentaires sont facultatives. | L’affaire espagnole de 2024 montre qu’une adresse email d’inscription a effectivement été remise en réponse à une demande légale. [TechCrunch, citant des pièces judiciaires](https://techcrunch.com/2024/05/08/encrypted-services-apple-proton-and-wire-helped-identify-activist/) | Un pseudonyme de profil n’isole pas d’une adresse email réutilisée ou corrélable; compte Wire personnel n’est pas anonyme par défaut. | Possibilité actuelle d’inscription sans email avec tous clients; seuils anti-abus, CAPTCHA, attributs conservés après suppression, possibilités de paiement anonyme entreprise. |
| 4. Contact discovery | La recherche Wire permet la découverte par nom ou username; le résultat peut inclure nom d’affichage, username et photo. L’équipe peut restreindre la découverte à un username exact. [Privacy Whitepaper](https://wire.com/hubfs/wire-white-privacy-paper.pdf) | Le livre blanc décrit le carnet d’adresses comme optionnel et affirme que les numéros hachés sont traités pour recherche sans téléverser le carnet complet. | Aucun protocole PSI/TEE ni mesure de requête réseau actuelle n’a été trouvé; le hachage simple, s’il est employé, ne rend pas un espace de numéros faible non devinable. | Recherche nominative centralisée crée une surface d’énumération et de corrélation; la confidentialité dépend des paramètres et de la version. | Algorithme actuel de découverte, sel/OPRF/PSI éventuel, limitation de débit, données exactes vues lors d’une recherche et rétention. |
| 5. Métadonnées serveur | La politique actuelle (mise à jour oct. 2025) dit que logs techniques sont collectés à chaque accès, conservés max. 90 jours; profil conserve username, display name et email pendant la vie du compte. Le backend connaît auteur, date UTC, participants et leurs appareils, nom et rôles des groupes; ces métadonnées ne sont que chiffrées en transport. [Politique](https://wire.com/en/privacy-policy), [privacy paper](https://wire.com/hubfs/wire-white-privacy-paper.pdf) | Wire dit minimiser les données et ne pas accéder au contenu des conversations. | Le whitepaper précise aussi noms de dossiers et associations conversation/dossier en clair sur le backend; l’architecture de remise requiert identifiants appareils et état de file. | Wire Cloud détient suffisamment de métadonnées pour relier comptes, groupes, appareils et opérations serveur, sans déchiffrer le contenu E2EE. | Schémas et rétentions courants par microservice; logs API complets; requêtes d’accès interne; durée réelle des logs et des événements de remise. |
| 6. IP utilisateur | Politique dit que l’IP d’inscription peut être enregistrée et que logs de service durent jusqu’à 90 jours; le site public a une politique séparée avec IP des visiteurs de site jusqu’à 30 jours. | Wire ne vend pas les données et ne fait pas de publicité ciblée; cette déclaration n’équivaut pas à absence de collecte IP. | Les docs réseau listent des API, assets, TURN et SFT centralisés. [Domaines/ports](https://support.wire.com/hc/en-us/articles/115005341805-What-domain-names-and-ports-does-Wire-connect-to) | Un opérateur de service reçoit nécessairement une IP source lors de connexion directe au cloud; un VPN déplace la confiance vers l’opérateur VPN et ne supprime pas les corrélations temporelles. | Quelle IP parvient à chaque composant, conservation des logs API hors catégorie annoncée, adresses des utilisateurs derrière proxy/VPN, conditions légales de remise par cas. |
| 7. IP exposée au correspondant | Wire documente appels WebRTC directs quand possible, TURN/Co-TURN si connexion directe impossible et SFT pour conférences; TURN/SFT changent le chemin réseau. [Support réseau](https://support.wire.com/hc/en-us/articles/115005341805-What-domain-names-and-ports-does-Wire-connect-to) | Le whitepaper affirme que TURN masque l’adresse peer quand l’appel est relayé et que ses relais sont séparés du backend utilisateur. | Les rapports 2017–18 n’ont pas audité ICE/WebRTC dans son ensemble ni l’analyse de trafic; ils ne valident donc pas chaque chemin 2026. [Audit Web/Calling](https://x41-dsec.de/static/reports/X41-Kudelski-Wire-Security-Review-Web-Calling.pdf) | En appel direct, le pair peut obtenir l’adresse réseau candidate via ICE; un relais peut la masquer au pair mais connaît lui-même l’IP source. | Comportement réel par client, option « masquer IP », IPv6, appel 1:1/groupe et stratégie de sélection ICE sur chaque version actuelle. |
| 8. Messages | Wire affirme que texte, voix, vidéo et documents partagés dans les conversations sont E2EE; messages chiffrés mis en file hors ligne puis supprimés après livraison. [Politique](https://wire.com/en/privacy-policy) | Wire déclare ne posséder aucune clé de déchiffrement et ne pas avoir de backdoor. | Privacy paper décrit une file de messages par utilisateur/appareil et métadonnées associées, avec rétention de queue de quatre semaines dans une autre section; c’est une différence de périmètre à résoudre avec la formulation « immédiatement supprimé après livraison ». | Le contenu ciphertext doit rester accessible au serveur avant livraison; après livraison, il peut subsister une copie locale ou autre appareil/capture. | Distinction actuelle exacte entre message payload, notification queue, états/cursors et backups; vérification expérimentale de purge réelle après livraison. |
| 9. Groupes | Backend stocke participants et appareils, créateur, timestamp, nom et rôles. Wire annonce migration des conversations vers MLS; MLS permet l’état de groupe cryptographique, mais ne cache pas la liste au backend dans cette architecture. [Whitepaper privacy](https://wire.com/hubfs/wire-white-privacy-paper.pdf), [MLS](https://support.wire.com/hc/en-us/articles/12434725011485-Messaging-Layer-Security-MLS) | Les messages de groupe sont E2EE et les administrateurs contrôlent membres/guests selon options entreprise. | Thèse ETH 2023 a étudié redirection de groupe / confidentialité sous serveur malveillant dans des versions antérieures; non retesté ici sur integration actuelle. | L’ajout d’un appareil ou participant et les métadonnées du groupe sont des surfaces critiques distinctes de la confidentialité des messages. | Assurance d’ajout/suppression et gestion des groupes mixtes Proteus/MLS; audit MLS en production, guests anonymes, limites de taille et logs admin. |
| 10. Appels | Clients utilisent WebRTC, SRTP et mécanismes Wire de signalisation/établissement de clés; 1:1 peut être direct ou TURN; conférences passent par SFT puis éventuellement TURN. | Wire présente voix/vidéo comme chiffrées de bout en bout; le fournisseur décrit SFT comme relais de paquets chiffrés. | L’audit X41/Kudelski 2018 s’est limité à la signalisation et à certains aspects de protocole; codecs, WebRTC complet, ICE, traffic analysis et dépendances tierces étaient exclus. | Chiffrement du média n’empêche pas le relais de voir IP, horaires, participants routés, volumes et durée. | Vérification du chemin, suites cryptographiques et réduction de visibilité par type d’appel/plateforme actuelle; audits indépendants récents de SFT. |
| 11. Fichiers | Pièces jointes conversationnelles sont incluses dans la déclaration E2EE; Wire Drive distingue stockage documentaire chiffré au repos/en transit mais pas E2EE. [Politique](https://wire.com/en/privacy-policy), [Support](https://support.wire.com/hc/en-us/articles/203122470-Can-anyone-read-the-messages-I-send-on-Wire) | Wire annonce partage de fichiers E2EE dans les conversations. | La documentation de déploiement distingue service d’assets; cette URL/infra traite les blobs, tandis que chiffrement E2EE dépend du type de fonctionnalité utilisé. | Confondre pièce jointe dans un chat et Wire Drive crée une erreur de périmètre; nom de fichier/metadata peuvent être séparés du contenu crypté. | Parité des clients, thumbnails, EXIF, liens prévisualisés et détails actuels du protocole Wire Drive/retention. |
| 12. Multi-device | Chaque client a une clé d’identité publique et peut avoir des sessions/chiffres propres; backend conserve l’inventaire participant-appareil. Le store Android annonce jusqu’à 8 appareils. [Sécurité](https://wire.com/hubfs/Whitepapers/-wire-security-whitepaper.pdf), [Google Play](https://play.google.com/store/apps/details?id=com.wire) | Wire dit que les appareils sont vérifiés et que l’état MLS peut être attesté via certificats X.509 pour backend d’entreprise/on-prem. | Whitepaper décrit fingerprint manuel par appareil sous Proteus, vérification MLS conditionnée à la confiance dans le backend CA; ajout appareil fait passer une conversation en état « dégradé » tant que non vérifié. | Appareil secondaire est une nouvelle frontière cryptographique et peut donner accès à l’historique futur; ajout silencieux serait important mais non prouvé ici. | Flux exact actuel d’ajout/suppression, synchronisation de vérification entre appareils, mécanismes de recovery et portée des clés/certificats sur Wire Cloud. |
| 13. Push | Android utilise FCM, iOS APNs; push contiendrait UUID associé et signal de réveil, puis client récupère la queue; F-Droid contourne FCM via websocket permanent. [Privacy Whitepaper](https://wire.com/hubfs/wire-white-privacy-paper.pdf) | Wire dit que les push ne contiennent pas de contenu et offre F-Droid sans FCM. | Apple/Google peuvent voir existence app, token d’installation, IP et horaires d’échanges push par conception des services OS; contenu exact dépend du payload réellement transmis. | Push réduit certains coûts mais introduit observateur OS-tier; WebSocket évite FCM côté Android mais garde IP/horaires visibles à Wire/ISP et augmente consommation. | Payload réseau actuel Apple/Google, token lifecycle, notifications de groupe, mode iOS alternatif, nombre de réveils et éventuelle corrélation identifiant↔compte côté OS. |
| 14. Stockage local | Clients ont bases locales, éléments chiffrés/déchiffrés, clés et caches pour fonctionnement multi-device; l’audit Android a examiné stockage, partages et WebViews en 2017. | Wire dit que messages restent sous contrôle utilisateur et peuvent être supprimés localement. | Anciens audits ont trouvé risques de path traversal, intents et caches; cela documente surfaces/version de 2017, pas comportement de l’app actuelle. | Un appareil déverrouillé ou session active expose le plaintext, indépendamment d’E2EE; partage de logs par l’utilisateur est une voie d’exfiltration volontaire. | Schéma/algorithme exact de chiffrement de DB actuelle, clés Android Keystore/iOS Keychain, caches supprimés, état notification/clipboard, protections OS et retention locale. |
| 15. Sauvegardes | La documentation consultée ne décrit pas une sauvegarde consumer de messages E2EE équivalente à iCloud/Drive; l’admin peut exporter des données d’équipe selon outils. | Wire dit qu’une suppression de compte supprime les données associées côté service. | Aucune publication indépendante n’a vérifié les fichiers de sauvegarde système actuels, clés d’app ou restauration sur iOS/Android. | L’absence de fonctionnalité « backup » identifiée ne signifie pas absence de copies OS, exports, cache ou copies de destinataire. | Inclusion/exclusion des données Wire dans iCloud/iTunes/Android backup, chiffrement et restauration; durée des éléments chez correspondants et appareils désinstallés. |
| 16. Analytics / SDK tiers | Politique actuelle indique Countly avec consentement, auto-hébergé par Wire en UE, events/crash/usage; pseudonyme, version, modèle/OS et IP traitée mais non conservée selon la politique; données max 365 jours. APNs/FCM et Zendesk sont mentionnés; stores peuvent recevoir crash reports opt-in OS. [Politique](https://wire.com/en/privacy-policy), [whitepaper](https://wire.com/hubfs/wire-white-privacy-paper.pdf) | Wire affirme que Countly n’est pas lié au compte et n’est pas partagé avec Countly Ltd; F-Droid et backend custom n’envoient pas ces métriques selon le whitepaper. | Google Play et App Store privacy labels sont auto-déclarés; ils ne certifient pas les flux. SDK/manifests de binaires exacts non extraits pour cette enquête. | Version Play, F-Droid, iOS, web et build entreprise peuvent différer nettement; l’analytics du site (HubSpot/Google Analytics) n’est pas l’analytics du Messenger. | Liste complète des SDK embarqués en 2026, endpoint réel, opt-in effectif, rapports OS, crash uploads et consentement entreprise par déploiement. |
| 17. Code source | Dépôts publics existent pour serveur, Android, iOS, webapp, signalling et composants cryptographiques; serveur est sous licence AGPL (clients selon repo GPLv3). [Org Wire](https://github.com/wireapp) | Wire affirme que le code publié permet une inspection et propose des déploiements autonomes. | Android README décrit variante F-Droid sans clés/API Play et lib AVS ouverte; binaire Play contient améliorations AVS propriétaires. iOS README décrit amélioration AVS propriétaire dans Store, absente du source ouvert. [Android](https://github.com/wireapp/wire-android), [iOS](https://github.com/wireapp/wire-ios) | « Open source » ne signifie pas identité source↔binaire officielle, ni service cloud identique au dépôt. | Inventaire précis des composants fermés actuels (AVS, SDK), écarts de config et licences pour chaque store/build. |
| 18. Reproductibilité | Releases Android récentes ont des tags/commits GitHub « Verified »; F-Droid compile une version source publiée. iOS source compile mais APNs dépend de signature/configuration du développeur. [Release Android](https://github.com/wireapp/wire-android/releases), [F-Droid](https://f-droid.org/en/packages/com.wire/) | Éditeur affirme une certaine transparence et publie source/build docs. | Aucun binaire App Store/Play courant n’a été reproduit ni comparé bit à bit dans cette enquête; parties AVS propriétaires empêchent une reproduction exacte à partir du seul source public. | Tag signé vérifie attribution/intégrité Git, pas reproductibilité ni conformité du binaire distribué. | Attestations SLSA, provenance store, reproduction actuelle indépendante, hashes comparatifs, reproducible release pour iOS et Play. |
| 19. Supply chain | Dépôts GitHub publics exposent commits, CI et dépendances; politique de sécurité demande rapport privé, dernière version supportée et traitement annoncé. [SECURITY.md](https://github.com/wireapp/wire/security) | Wire décrit une coordination responsable avec délais et divulgation publique après correction. | Advisory iOS CVE-2026-35049 est public; releases Android récentes signées; les audits historiques ont couvert des dépendances ciblées seulement. | Clés de signature store, pipeline propriétaire, dépendances binaires AVS et mise à jour restent des points de concentration. | Couverture CI/secret scanning actuelle par repo, provenance officielle des stores, nombre de mainteneurs, attestations/build isolation et retests de fix. |
| 20. Infrastructure | Wire publie les domaines client, TURN et SFT; ses IP de load balancer sont dynamiques. [Support](https://support.wire.com/hc/en-us/articles/115005341805-What-domain-names-and-ports-does-Wire-connect-to) | Livre blanc dit données clients stockées en Europe; déploiement Wire peut utiliser AWS, Azure, StackIT, autre cloud ou on-prem. [Options](https://wire.com/en/deployment-options) | Snapshot DNS/BGP du 14 oct. 2026 : les pools `prod-nginz-https`, `prod-nginz-ssl`, `sft.calling-prod-v01` et trois des quatre cibles TURN observées routaient par AS16509 (Amazon). Une cible TURN (`18.184.5.76`) n’a pas de préfixe RIPEstat vérifié dans cette passe. | Cela établit un routage réseau observé pour les adresses répondues, pas que Wire détient les serveurs, où les données sont stockées, ni que tous les appels/utilisateurs utilisent ces cibles. | Région et propriétaire de chaque instance, origin/CDN, backends, trafic réel, rétention/logs, autres points d’accès et changements de pool. |
| 21. Juridiction | Wire Swiss GmbH, Zug, Suisse; droit suisse de protection des données; Wire Germany GmbH est représentant UE RGPD. [Politique légale](https://wire.com/en/privacy-policy) | Wire indique que les demandes étrangères passent par les autorités suisses/entraide selon son rapport historique. | Cas 2024 confirme requête espagnole transmise par voie suisse et réponse de Wire par email d’inscription. [Dossier presse/court records](https://techcrunch.com/2024/05/08/encrypted-services-apple-proton-and-wire-helped-identify-activist/) | La juridiction ne neutralise pas une donnée existante; l’email de compte a été techniquement récupérable et communiqué. | Propriétaire ultime/gouvernance actuelle, lois d’interception et obligations applicables précisément à la forme Wire Cloud; changement depuis ancien rapport de transparence. |
| 22. Demandes policières | Transparency report officiel historique publie 2018: 1 requête valide/8 comptes impactés (+2 rejetées); 2019: 192 requêtes/142 comptes (+7 rejetées); 2020: 349/310 (+3 rejetées). [Rapport PDF](https://wire-docs.wire.com/download/Wire%2BTransparency%2BReport.pdf) | Wire déclare ne pas pouvoir produire le contenu E2EE; le rapport dit coopération selon droit applicable. | Cas 2024: Wire a effectivement remis l’email d’inscription lié au compte ciblé, lequel était un email Proton; pas de contenu chat Wire remis établi dans cette procédure. [TechCrunch](https://techcrunch.com/2024/05/08/encrypted-services-apple-proton-and-wire-helped-identify-activist/) | Les agrégats attestent requêtes, mais seuls les documents du cas et la confirmation Wire établissent quel champ a été remis dans cette affaire. | Données précises pour chaque demande 2018–20, taux et champ par request, rapport après 2020, warrant/subpoena guides, données urgentes et existence d’ordres de conservation. |
| 23. Affaires judiciaires | Procédure espagnole visant un activiste catalan (requête 2024) a utilisé email d’inscription fourni par Wire; police a ensuite interrogé Proton et Apple. | Wire dit avoir répondu à une demande officielle en fournissant le seul identifiant email demandé/disponible selon les éléments rapportés. | Court documents consultés par TechCrunch décrivent la chaîne et l’email remis; la police obtient ensuite identité/adresses auprès d’Apple. | C’est preuve réelle de divulgation d’un identifiant, non d’accès Wire au contenu ou d’interception live. Les captures de conversations annexées au dossier ne prouvent pas leur provenance serveur. | Copie primaire complète des requêtes/ordres et du retour Wire, champs/horaires exacts, éventuel contenu Wire produit autrement. |
| 24. Audits | Rapports publics Kudelski/X41 2017–18 ont examiné Proteus/Cryptobox, clients Android/iOS et web/signalling; détails ci-dessous. | Wire indique avoir corrigé ou mitigé findings et, pour plusieurs rapports, auditeurs ont revu patchs. | PDFs complets donnent commit, durée, scope/exclusions, sévérités; ce sont audits ciblés datés, pas certification du produit actuel. | L’existence d’audits améliore l’historique d’évidence, mais échéance/versions (2016–17) rendent impropre une validation globale 2026. | Audits indépendants post-MLS/serveur/app actuelle, fréquence de retest, portée backend/cloud, push, store binaries et SFT moderne. |
| 25. Vulnérabilités | GitHub Advisory iOS CVE-2026-35049: clients <4.16.0 peuvent recevoir un payload Proteus malformé de moins de 16 octets et entrer dans une boucle de crash; corrigé en 4.16.0 le 29 mai 2026. [Advisory](https://github.com/wireapp/wire-ios/security/advisories/GHSA-v6wg-c7qc-x66g) | Le dépôt marque la version fixée et l’éditeur a diffusé le correctif. | Advisory classé modéré/CVSS 6.5, vecteur disponibilité, attaque par message sans interaction selon advisory; aucune exploitation réelle signalée dans la source. | Les anciennes installations restent vulnérables si non mises à jour; pas de preuve qu’un adversaire ait exploité le bug. | CVE/NVD final, nombre de versions réellement exposées, diffusion Store par pays, rapport de retest/forensic, autres advisories privés. |
| 26. Recherches académiques | Thèse ETH Zürich 2023 (Andreas Tsouloupas, 111 p.) analyse attaques contre versions Wire utilisant Proteus et design MLS de l’époque. [DOI / thèse](https://doi.org/10.3929/ethz-b-000673362) | La documentation Wire actuelle décrit MLS/Proteus et leurs garanties attendues. | Travail académique indépendant rapporte notamment faiblesse PCS sous certains adversaires et attaques de redirection/ordre/confidentialité pour l’intégration étudiée; ce n’est pas un audit de production 2026. | L’étude est pertinente comme historique et liste de conditions de menace à retester, non comme affirmation qu’une attaque actuelle est confirmée. | Mapping commits corrigés à la thèse, publication de réponses Wire, réplication et analyse de la génération MLS actuelle. |
| 27. Incidents historiques | Historique documenté ici : findings/audits 2017–18, CVE iOS 2026, et divulgation légale 2024. | Wire annonce correction des problèmes et limitation des données par E2EE. | Aucun incident public de déchiffrement massif ou compromission de Wire Cloud n’a été identifié dans ce corpus; cette absence n’établit pas qu’il n’y en a jamais eu. | Un bug de disponibilité n’est pas compromission de confidentialité; une divulgation email légale n’est pas une fuite accidentelle. | Timeline exhaustive de pannes, incidents internes, sous-traitants, notification de breach, accès internes et rapports CERT. |
| 28. Gouvernance / société / financement | Entité légale active et contrôleur indiqués: Wire Swiss GmbH (Zug); représentants allemands documentés. | Wire se présente comme entreprise européenne/suisse de communication sécurisée. | Sources publiques consultées n’établissent pas de manière fiable propriétaire ultime, parts, financement actuel ou droits de contrôle. | Identité suisse de l’entité contractante est établie, mais elle ne répond pas à la question du contrôle économique. | Bénéficiaires effectifs, actionnaires 2026, financement, conseil, structure de holding, clauses de changement de contrôle. |
| 29. Résistance à la censure | Wire Cloud dépend de domaines documentés, DNS, IP/load balancers, stores mobiles, FCM/APNs et endpoints centraux; Wire documente federation et self-hosting. | Wire propose déploiement privé et autonome pour organisations. | Aucun test DPI/mesure OONI ou blocage par pays n’a été mené; DNS dynamique est dit par le support, non mesuré ici. | Le service central public est bloquable par domaine/IP/store; fédération/on-prem peuvent aider une organisation à diversifier, mais ne constituent pas un mécanisme de contournement anonyme. | Mesures de disponibilité par pays, résistance à DPI, bridges/proxies, installation alternative, conséquences de révocation de certificat/app. |
| 30. Maintenance actuelle | Au 13 oct. 2026, Android 4.36.1 (9 oct., commit `240b2a0`, signature GitHub vérifiée); iOS 4.28.0 (28 sept. selon release repo); backend publie des releases et le 12 juin 2026 a retiré une suite hybride Kyber faute de support dans sa branche OpenMLS. [Android releases](https://github.com/wireapp/wire-android/releases), [iOS releases](https://github.com/wireapp/wire-ios/releases), [serveur](https://github.com/wireapp/wire-server/releases) | Wire décrit support continu et mises à jour sécurité. | Activité des dépôts/release tags est vérifiable; pas de comptage reproductible des mainteneurs actifs ni test de publication Store réalisé ici. | Le retrait de Kyber signifie que le PQ hybride évoqué antérieurement n’est pas attesté comme activé dans la release serveur indiquée; « agilité » n’est pas protection PQ présente. | SLA vulnérabilité actuel, proportion de clients actifs par protocole, support versions, validité signatures tags, mainteneurs effectifs et plan PQ. |

### Wire — extraction d’audits (rapports primaires lus)

| Organisme / date / commanditaire | Version / commit | Durée / méthode | Scope et exclusions | Findings, sévérité | Correctifs / recommandations / retest |
|---|---|---|---|---|---|
| Kudelski Security + X41 D-Sec, rapport public 8 fév. 2017, commanditaire Wire Swiss GmbH | Proteus `6b317191` (préfixe de révision donné dans le PDF) en Rust/CoffeeScript, Cryptobox API/C et sérialisation CBOR; revue basée sur dépôt à la date indiquée. | 14 jours-personnes, 23 nov. 2016–9 janv. 2017; revue surtout manuelle de code, spécification et composants fournis (~3300 lignes Rust, 2400 CoffeeScript, 400 C). | Protocole/librairies et API; ne couvre pas app complète, backend, appels, push, déploiement ou toute la supply chain. [PDF](https://x41-dsec.de/static/reports/Kudelski-X41-Wire-Report-phase1-20170208.pdf) | 14 findings: **5 MEDIUM et 9 LOW**, aucun critique/élevé. Findings: clés DH dégénérées/invalides non rejetées, thread-safety en Rust/JS, valeurs secrètes non effacées, chaînes C et pointeurs, longueur prekey, buffer overread tests, overflow et parser CBOR laxiste. | Recommande valider clés/erreurs, effacer secrets, corriger thread-safety et parser strictement. Des corrections sont liées dans certains constats; pas de retest actuel/indépendant annoncé pour la version 2026. |
| Kudelski + X41, Phase 2 Android, 7 mars 2018 | Android client, commit `4135eada…`; sync engine `565b72cb…`; versions de travail 2017. | 9 jours-personnes, mars–nov. 2017; revue source + tests dynamiques sur APK officiel, émulateurs, appareils de test rootés. | Android app et sync; core Proteus, appels, dépendances tierces exclus. [PDF](https://www.x41-dsec.de/reports/X41-Kudelski-Wire-Security-Review-Android.pdf) | 6 findings: 1 élevé, 5 faibles; chemin de traversal lors d’enregistrement fichier (élevé), PRNG / LZW, WebView remote content, intent URI fichier non assaini, deep link pouvant forcer déconnexion. | Rapport décrit assainissement canonical path/URI, validation, ouverture navigateur, correctifs; il indique patches et revue des changements. Aucun retest de l’app actuelle. |
| Kudelski + X41, Phase 2 iOS, 7 mars 2018 | Huit commits testés : cryptobox `8e96cccb35b259187e590ca75e969cde7a6e2efd`; data-model `54302381324dfcd017154d4e59590905610d956e`; images `ba105ea632251fcadd9f388ed319e8300164ace9`; message-strategy `22e7c4210e10acfc37963b3f2e2e108496a48190`; share-engine `1aba9b92931073d6050cecc18059863cf7ebe1d2`; sync-engine `dd66a9fc2a056e320a2f62fca277cb233042147f`; system `db0abf2504f16b4c2ae67e6feaa454d1c08d843b`; transport `967db8121677940aa59b101139b6731b61977a3c`. | 10,75 jours-personnes, août–nov. 2017; revue source et tests dynamiques sur app officielle / appareils de test jailbreakés. | Client iOS; Proteus, appels et dépendances tierces exclus. [PDF](https://x41-dsec.de/static/reports/X41-Kudelski-Wire-Security-Review-iOS.pdf) | 4 issues: 1 faible, 3 moyennes; clé WebSocket fixe réutilisée, crash sur preview PDF malformé, format strings non sûrs, collisions de cache d’assets fondées sur nonce. | Recommande clé aléatoire, validation PDF/format strings et clé cache distincte; rapport dit que patches ont été corrigés et revus. Pas de retest récent. |
| Kudelski + X41, Phase 2 Web/Calling, 7 mars 2018 | `wire-webapp` `ef30665e6824047a60af00405b10758897db46fa`; signalling `99799d12f49fcddf7252748b8f3dceff3625d0fe`. | 7,5 jours-personnes (4,5 Kudelski + 3 X41), 7 mars–5 juil. 2017; revue code, fuzz du décodeur SDP avec afl; auditeurs indiquent avoir contribué à des conseils de conception du key establishment. | Webapp base desktop/browser et signaling d’appel; Electron, codecs, WebRTC complet, deps tierces, traffic analysis et ICE exclus. [PDF](https://x41-dsec.de/static/reports/X41-Kudelski-Wire-Security-Review-Web-Calling.pdf) | 7 vulnérabilités: 1 élevée (jQuery 2.1.4 via antiscroll), 5 moyennes, 1 faible; XSS possible via localisation, token dans URL, base64 permissif, DoS JSON signalling, effacement tardif de clé, libvpx avec DoS distant (CVE-2017-0393), plus les findings Web décrits dans le rapport. | Rapport dit que Wire a corrigé/mitigé et que patchs de signaling ont été revus. Certaines recommandations (ne pas mettre token dans URL) étaient acceptées comme risque par Wire. Aucun retest actuel; limites de scope restent importantes. |

**Lecture historique — recherche ETH 2023, non-audit.** La thèse *Security Analysis of the Wire Messaging Protocol* étudie les versions alors disponibles. Elle rapporte des vulnérabilités de l’ordre des messages et de redirection/confidentialité des groupes contre un serveur malveillant pour Proteus, ainsi que des limites de post-compromise security sous certains adversaires; elle identifie également des défauts dans le design/intégration MLS au stade alors étudié. La version 2026 a migré vers MLS mais l’audit/retet correspondant n’a pas été retrouvé. Il faut donc convertir ces résultats en hypothèses de test, pas les présenter comme exploités ou non corrigés aujourd’hui. [Thèse ETH](https://doi.org/10.3929/ethz-b-000673362)

### Wire — dépôts, releases et état de la chaîne logicielle

- `wire-server`, `wire-android`, `wire-ios`, `wire-webapp`, `wire-audio-video-signaling`, `wire-proteus` et plusieurs librairies sont publics. Server open source n’implique pas que l’instance Wire Cloud ou son état de production soit reproductible.
- **Android** : release 4.36.1 datée du 9 oct. 2026, commit `240b2a0`, signature committer GitHub vérifiée. Le README documente flavors Play/F-Droid et les écarts de bibliothèques d’appel/API keys; F-Droid n’est pas le binaire Play.
- **iOS** : repo GPL public; release 4.28.0 annoncée 28 sept. 2026 (commit exact à reprendre du tag avant toute vérification binaire). Le README prévient que Store utilise amélioration AVS propriétaire et qu’un build local n’a pas la même configuration APNs/signature.
- **Serveur** : repo public avec releases continues en 2026. Release 12 juin 2026 indique explicitement retrait de la suite hybride post-quantique basée Kyber, car non supportée par la branche Wire d’OpenMLS; ne pas décrire Kyber comme protection active.
- **Tags/signatures/CI** : releases Android montrent tags ou commits signés « Verified » par GitHub. Ce n’est ni signature reproductible du binaire distribué ni preuve que le contenu compilé est identique. Les comptes exacts de mainteneurs actifs, la diversité des reviewers et l’attestation des artefacts n’ont pas été mesurés.
- **Sécurité coordonnée** : `SECURITY.md` du dépôt Wire donne une procédure de signalement privé et versions supportées; l’iOS advisory `GHSA-v6wg-c7qc-x66g` / CVE-2026-35049 est publié et décrit la correction 4.16.0. Aucun retest externe/public post-fix n’y est indiqué.

### Wire — mobile privacy, permissions et analytics

| Surface | Fait observé dans les sources actuelles | Déclaration / limite |
|---|---|---|
| Google Play | Listing développeur : email/nom/IDs, téléphone optionnel, interactions d’app pour analytics, crash logs, photos éventuelles; données chiffrées en transit. [Store](https://play.google.com/store/apps/details?id=com.wire) | Déclaration développeur; pas une inspection indépendante d’APK. Les catégories peuvent varier par usage. |
| Apple App Store | Label du développeur : email, nom, téléphone, user ID liés à l’identité; usage/crash déclarés non liés; Apple prévient que la déclaration n’est pas vérifiée par Apple. [Store](https://apps.apple.com/us/app/wire-secure-messenger/id930944768) | Ne remplace pas l’analyse des entitlements, SDK et trafic de la version installée. |
| Countly / crash | Politique oct. 2025 décrit Countly auto-hébergé Wire, avec consentement; events, appareil/OS, version, ID pseudo; logs jusqu’à 90 jours et usage/analytics jusqu’à 365 jours selon catégories; crash reports par OS/store si consentis. | Le privacy paper indique F-Droid sans Countly et sans FCM, mais ce point doit être retesté sur APK actuel. La politique et le PDF ne détaillent pas la totalité des SDK buildés. |
| Push | FCM Android / APNs Apple selon docs; F-Droid utilise WebSocket. Le payload annoncé contient UUID + réveil, pas le message. | Observation packet-level non faite; métadonnées push peuvent inclure heures, token, installation et IP observée par Apple/Google. |
| Permissions et contacts | Fonctionnalités nécessitent selon usage micro/caméra pour appel, sélection fichier/photos et éventuellement contacts; manifest iOS/Android actuels non extraits dans cette enquête. | Permission déclarée n’est pas permission accordée ni preuve d’un accès. Pas de test runtime, instrumentation ou comparaison APK/IPA. |
| Website vs app | La politique distingue HubSpot/Google Analytics/cookies du site web et les outils Messenger; le site peut traiter IP/cookies avec consentement. | Ne pas imputer les trackers du site aux clients mobiles. |

**À tester pour clore le volet mobile :** extraire manifeste Android + permissions fusionnées, SDK, endpoints et trackers depuis Play et F-Droid; comparer avec commit et build; inspecter entitlements/Privacy Manifest iOS et labels régionaux; tracer premier lancement, opt-in Countly, contacts, partage fichier, caméra/micro, push et crash; capturer APNs/FCM payloads uniquement sur comptes et appareils de laboratoire. Ces tests n’ont pas été exécutés ici.

### Wire — infrastructure OSINT observée et documentée

**DOCUMENTÉ** : Wire Support (actualisé 22 janv. 2026) publie les domaines clients listés dans le registre ci-dessus, indique load balancers à IP dynamiques, TCP/443; TURN via SRV sous `turn.calling-prod-v01.wire.com`; conférence via `sft.calling-prod-v01.wire.com`; d’autres domaines peuvent apparaître pour aperçus de liens/média. Le livre blanc Wire dit données client hébergées en Europe; le site web utilise HubSpot sur infrastructure UE selon sa politique (cela concerne le site, pas nécessairement le Messenger). [Domaines/ports](https://support.wire.com/hc/en-us/articles/115005341805-What-domain-names-and-ports-does-Wire-connect-to), [privacy paper](https://wire.com/hubfs/wire-white-privacy-paper.pdf), [politique web](https://wire.com/en/privacy-policy)

**OBSERVATION DNS/BGP DE CETTE PHASE** : requêtes A/AAAA et SRV à un résolveur local (identité inconnue), puis préfixes IPv4 via RIPEstat, vers 00:29–00:32 heure de Paris le 14 octobre 2026 (13 oct. UTC). Aucun port n’a été contacté.

| Endpoint documenté | Réponses DNS capturées | RIPEstat IPv4 | Limite d’interprétation |
|---|---|---|---|
| `prod-nginz-https.wire.com` | A `108.128.248.229`, `54.195.173.137`, `18.203.1.6`; aucun AAAA retourné par le résolveur | Préfixes `108.128.0.0/13`, `54.195.0.0/16`, `18.202.0.0/15`, tous AS16509 (Amazon) | Pool dynamique; pas la preuve que chaque requête client touche ces trois IP. |
| `prod-nginz-ssl.wire.com` | A `34.240.177.63`, `54.229.239.4`, `52.208.42.237`; aucun AAAA retourné | `34.240.0.0/13`, `54.229.128.0/17`, `52.208.0.0/13`, AS16509 | L’ASN identifie l’annonce réseau, pas le contrat/hôte ou la résidence des données. |
| `sft.calling-prod-v01.wire.com` | A `18.198.15.177`, `18.158.173.249`, `3.120.232.124`; aucun AAAA retourné | `18.198.0.0/15`, `18.156.0.0/14`, `3.120.0.0/14`, AS16509 | Endpoint conférence documenté; ne prouve pas utilisation systématique. |
| `_turn._udp.turn.calling-prod-v01.wire.com` | SRV vers `coturn-0`…`coturn-3.coturn.calling-prod-v01.wire.com`, port UDP/3478, poids 10; A `18.184.5.76`, `63.187.91.96`, `3.125.158.35`, `3.66.84.189`; aucun AAAA retourné | Trois IP : AS16509, préfixes `63.184.0.0/14`, `3.124.0.0/14`, `3.64.0.0/12`; pas de préfixe vérifié pour `18.184.5.76` | Le résolveur a donné quatre cibles à l’instant observé; choix réel TURN dépend de client/région/call. |

AS16509 est annoncé par Amazon.com, Inc. [RIPEstat AS16509](https://stat.ripe.net/AS16509). **La géolocalisation précise, les origins, les journaux, les traitements effectifs et la résidence réelle par type de donnée restent inconnus.** Ces réponses sont un snapshot DNS courant, non du passive DNS ni un inventaire de l’ensemble du service; l’absence d’AAAA dans cette réponse n’établit pas une absence universelle d’IPv6. Aucun scan, connexion applicative ou intrusion n’a été effectué.

### Wire — forensique et limites datées

Dans les sources consultées, aucune démonstration publique récente ne relie **Cellebrite/GrayKey/Magnet + version d’outil + modèle d’appareil + version iOS/Android + Wire app build + date**. Des audits Wire 2017–18 ont examiné code de stockage, intents, fichiers, logs et caches, mais ce ne sont pas des validations de capacités forensiques actuelles. Les éléments localement accessibles sur un appareil déverrouillé sont par principe hors portée de la garantie E2EE; la quantité récupérable sur appareil verrouillé dépend des secrets système, de la base, du modèle, de la version OS et du build. Aucun test de saisie contrôlé n’a été fait ici. Il faut considérer chiffrement local de DB, Keychain/Keystore, clés et contenu supprimé comme **inconnus**, non présumer un état en clair ou au contraire un chiffrement complet.

### Wire — ce qui a effectivement été obtenu par des autorités

- **Donnée réellement communiquée dans un cas identifié :** en 2024, à la suite d’une demande espagnole transmise via la Suisse, Wire a fourni l’email utilisé à l’inscription d’un compte Wire; cet email Proton a permis la demande suivante à Proton, puis à Apple. L’email a donc bien été remis; le reportage attribue cette information à des documents judiciaires et cite la confirmation de Wire. [TechCrunch, 8 mai 2024](https://techcrunch.com/2024/05/08/encrypted-services-apple-proton-and-wire-helped-identify-activist/)
- **Contenu des messages :** le dossier public cité n’établit pas que Wire a remis des conversations; Wire dit ne pas disposer des clés/contenus. Les messages/éléments reproduits dans un dossier ne démontrent pas à eux seuls une production serveur — ils peuvent venir d’appareils ou de participants.
- **Échelle agrégée :** le PDF Wire couvre 2018–2020 et compte demandes/comptes touchés, sans lister les champs remis pour chaque ordonnance. Ce rapport ne répond pas à lui seul à « quelle donnée exacte dans chaque affaire ». Aucun rapport annuel post-2020 n’a été trouvé dans cette recherche.
- **Trois niveaux à ne pas confondre :** (1) email, IP d’inscription et logs sont techniquement traitables selon la politique; (2) Wire déclare ne pouvoir fournir le contenu E2EE; (3) la seule remise nominativement documentée ici est l’email d’inscription dans l’affaire 2024.

### Wire — matrice des métadonnées par observateur

Statuts fondés sur les sources citées et l’architecture documentée. **NON ACCESSIBLE PAR DESIGN** signifie inaccessible au correspondant dans le flux E2EE nominal; ce n’est pas une garantie face au terminal compromis, au partage ou à un membre de groupe.

| Métadonnée | Fournisseur Wire Cloud | Contact | ISP / réseau local | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | **CONFIRMÉ** : IP d’inscription peut être conservée; logs jusqu’à 90 j; accès réseau voit source | **POSSIBLE** : appel direct/WebRTC peut révéler candidat IP; TURN réduit cette exposition | **CONFIRMÉ** : IP source, destinations, timing et volumes | **POSSIBLE** : push/IP vers APNs/FCM; store voit téléchargement/IP | **CONFIRMÉ** : email d’inscription remis en 2024; IP/logs techniquement traitables, remise dans ce cas inconnue |
| Téléphone | **POSSIBLE** : optionnel/annuaire ou compte entreprise; label store déclare parfois optionnel | **POSSIBLE** si fourni dans profil, équipe ou hors Wire | **NON ACCESSIBLE PAR DESIGN** dans le flux réseau seul; opérateur mobile connaît abonné | **POSSIBLE** via compte store/appareil; lien Wire non prouvé | **POSSIBLE** via opérateur/store ou donnée de compte; aucun cas remis identifié |
| Email | **CONFIRMÉ** : requis pour compte perso, conservé pendant durée compte selon policy | **POSSIBLE** si profil/coordonnée partagé | **NON ACCESSIBLE PAR DESIGN** dans trafic TLS/E2EE seul | **POSSIBLE** compte store | **CONFIRMÉ** : email d’inscription divulgué dans affaire 2024 |
| Identifiant | **CONFIRMÉ** : UUID interne / username / devices pour routage | **CONFIRMÉ** : username/display name dans contact et conversation | **POSSIBLE** par corrélation trafic, non lisible normalement sous TLS | **POSSIBLE** : ID app/store/token | **POSSIBLE** ou **CONFIRMÉ** par demande ciblée; cas 2024 associe compte/email |
| Graphe social | **CONFIRMÉ** pour membres/groupes et participants (backend conserve) | **CONFIRMÉ** pour conversations/groupes connus | **POSSIBLE** par timing/destinataires IP et volumes | **POSSIBLE** par notifications, pas graphe complet établi | **POSSIBLE** via Wire + autres sources; disclosure graph dans un cas non établie |
| Timestamps | **CONFIRMÉ** : création/vérification email, groupes et logs/routage | **CONFIRMÉ** : heures/messages/appels vus localement | **CONFIRMÉ** : horaires de trafic | **PROBABLE** : événements push ont timing | **POSSIBLE** : logs existent jusqu’à fenêtre déclarée; remise individuelle exacte inconnue |
| Volumes | **CONFIRMÉ** au niveau transport/asset et taille payload chiffré | **CONFIRMÉ** par messages/fichiers/appels reçus | **CONFIRMÉ** octets/durée | **POSSIBLE** taille/rythme push, payload exact inconnu | **POSSIBLE** via Wire, ISP ou push; cas documenté ne porte que sur email |
| Groupes | **CONFIRMÉ** : participants, devices, nom, rôles, créateur et heure UTC | **CONFIRMÉ** aux membres | **POSSIBLE** via motifs de trafic | **POSSIBLE** selon pushes et données OS | **POSSIBLE** à obtenir via Wire car backend les détient; remise en cas réel inconnu |
| Appareils | **CONFIRMÉ** : clients/public keys et participants-appareils pour E2EE | **POSSIBLE** via liste/verification et indicateurs conversation | **CONFIRMÉ** connexions réseau distinctes; identité physique pas toujours | **CONFIRMÉ** pour installations et push tokens côté service OS/store | **POSSIBLE** via Wire / Apple / Google / saisie; champ de remise non établi |
| Push tokens | **CONFIRMÉ** pour traitement FCM/APNs dans configurations concernées | **NON ACCESSIBLE PAR DESIGN** | **POSSIBLE** destination au fournisseur push + timing | **CONFIRMÉ** token d’installation pour push | **POSSIBLE** auprès Wire/Apple/Google; aucune remise de token identifiée dans l’affaire 2024 |

### Wire — colonne provisoire TM1–TM15 (pas un classement)

| Modèle | Évaluation | Justification courte / preuve |
|---|---|---|
| TM1 — fournisseur curieux | 🟠 | E2EE protège le contenu, mais Wire conserve identifiants/email, groupes, appareils et logs jusqu’à 90 jours. [Politique](https://wire.com/en/privacy-policy), [privacy paper](https://wire.com/hubfs/wire-white-privacy-paper.pdf) |
| TM2 — fournisseur compromis | 🟡 | MLS/Proteus empêche en principe lecture du contenu historique en transit/queue sans clé client; groupe, IP/logs et métadonnées sont exposés; compte/appareil malveillant reste une surface. Audit serveur actuel complet non trouvé. |
| TM3 — fournisseur malveillant | 🟡 | Le serveur peut manipuler disponibilité, délivrance, membership/metadata et pousser des clients; Proteus fingerprints manuels et MLS X.509 optionnel selon backend donnent une vérification, mais l’ajout d’un client non vérifié dégrade l’état. [Security whitepaper](https://wire.com/hubfs/Whitepapers/-wire-security-whitepaper.pdf) |
| TM4 — ISP/Wi‑Fi | 🟠 | TLS masque contenu mais pas destinations, IP source, timing et volumes; appel direct ajoute ICE/STUN exposure. VPN ne fait que déplacer l’observation. |
| TM5 — adversaire passif puissant | 🟠 | Cloud, push, ISP et relais d’appel offrent des points de corrélation; pas de padding/mixnet de Wire établi ni test de corrélation public actuel. |
| TM6 — global passive adversary | 🔴 | Architecture IP centralisée + routage/temps/volumes sans mixnet; aucune preuve de protection contre corrélation globale. Inférence de l’architecture, pas étude de mesure. |
| TM7 — contact malveillant | 🟠 | Pair reçoit email non requis par défaut dans le profil affiché, mais username/profil visible; appel direct peut exposer IP; partage volontaire des fichiers et métadonnées. |
| TM8 — harceleur/doxxer OSINT | 🟡 | Username unique et email requis isolent un peu si compartimentés; photos, recherche par nom, réutilisation d’alias et annonces de groupe peuvent relier identité. |
| TM9 — demande judiciaire classique | 🟠 | Wire a effectivement remis un email de compte dans l’affaire espagnole 2024; logs, groupes et identifiants existent selon policy/whitepaper; contenu E2EE déclaré inaccessible. [Cas](https://techcrunch.com/2024/05/08/encrypted-services-apple-proton-and-wire-helped-identify-activist/) |
| TM10 — enquête policière sophistiquée | 🟠 | Email Wire puis Proton recovery puis Apple ont permis identification dans un cas réel; ISP, push, device forensics et participants ajoutent de la visibilité. [Cas documenté](https://techcrunch.com/2024/05/08/encrypted-services-apple-proton-and-wire-helped-identify-activist/) |
| TM11 — appareil verrouillé saisi | ❓ | Aucun cas public actuel avec modèle/OS/Wire build/version Cellebrite/GrayKey/Magnet trouvé; protection locale actuelle non auditée ici. |
| TM12 — appareil déverrouillé | 🔴 | Client affiche plaintext, clés et pièces jointes pour usage normal; E2EE n’isole pas du processus/OS utilisateur. Les chemins exacts d’extraction n’ont pas été testés. |
| TM13 — spyware ciblé | 🔴 | Malware avec écran/processus/micro/mémoire peut lire avant/après chiffrement; E2EE ne protège pas un endpoint compromis. |
| TM14 — supply-chain compromise | 🟠 | Beaucoup de code public et releases signées, mais AVS propriétaire dans stores, aucune reproduction de binaires réalisée et serveur/cloud/update/store restent points de confiance. |
| TM15 — censure étatique | 🟠 | Domaines/serveurs centraux, push et stores sont bloquables; fédération/auto-hébergement aide organisations capables de le maintenir, mais aucun mécanisme anti-DPI/bridges démontré. |

### Wire — contradictions, zones inconnues, tests à réaliser

- **Durée des logs** : politique actuelle et Privacy Whitepaper disent jusqu’à 90 jours; un ancien sous-domaine de politique encore indexé dit 72 heures. La page principale se déclare mise à jour octobre 2025; l’ancien document semble obsolète mais n’a pas de versionnage vérifiable. À ne pas mélanger avec les logs du site public (max. 30 jours).
- **Message « supprimé après livraison » vs queue quatre semaines** : probablement des objets différents (payload livré vs queue par device / état de notification), mais le texte public ne permet pas ici une résolution certaine. Il faut vérifier le modèle exact ou instrumenter un compte de test.
- **E2EE vs métadonnées groupe** : marketing « toutes communications E2EE » concerne le contenu; la politique technique révèle membres, appareils, noms de groupe et rôles lisibles côté backend après transport TLS.
- **MLS/Post-quantique** : MLS est annoncé standard en 2026, tandis que release serveur retire le cipher hybride Kyber; post-quantique n’est donc pas démontré actif dans ce tag. Thèse 2023 concerne un état plus ancien et exige retest des correctifs.
- **Open source/reproductibilité** : source client et server disponibles; les versions Play/iOS incluent des composants AVS propriétaires et aucun binaire officiel n’a été reproduit pour cette enquête.
- **Divulgation légale** : cas 2024 établit remise de l’email d’inscription, non de contenu Wire. Les comptes statistiques 2018–2020 ne détaillent pas les champs remise par remise.
- **Forensique** : pas de preuve publique qualifiée de capacité outil commercial actuel. Données locales, protections DB/Keystore et récupération d’éléments supprimés demeurent à mesurer avec variables exactes.
- **Tests nécessaires** : (1) retest indépendant de MLS/Proteus et des commits ETH liés; (2) reproduire build et inspecter manifests/SDK/permissions/permissions runtime; (3) captures réseau par version pendant registration, contact search, message, groupe, fichier, push, appel direct/TURN/SFT; (4) vérifier purge de queue et rétention logs; (5) test d’ajout d’appareil et de dégradation de vérification; (6) acquisition forensic contrôlée avec modèle, OS, build, app et outil explicités; (7) résoudre DNS/ASN/CDN par observations passives datées des domaines listés; (8) obtenir la série de transparence post-2020 ou docs de demandes anonymisés. Aucun de ces tests n’est présenté comme réalisé.

## Matrix / Element — dossier de preuves individuel (référence : 13 octobre 2026)

**Périmètre.** Matrix est un protocole/API fédéré; un homeserver (Synapse ou autre) stocke et réplique l’état des salons; Element est un ensemble de clients et services d’hébergement, pas « le réseau Matrix ». La politique de matrix.org ne vaut que pour le homeserver matrix.org. Les données et garanties dépendent donc de l’opérateur, des réglages E2EE, des clients, des bridges et des services annexes. [Spécification Matrix](https://spec.matrix.org/v1.15/), [politique matrix.org](https://matrix.org/legal/privacy-notice/)

### Registre de preuves en 30 catégories

Chaque ligne distingue fait établi, déclaration éditeur, preuve indépendante, inférence et inconnue. Un point d’interrogation ne signifie pas que la donnée n’existe pas.

| # / catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | Matrix fédère des homeservers par API serveur-à-serveur; événements et médias sont répliqués selon les membres/permissions des salons. | Matrix Foundation présente un réseau sans point de contrôle unique; Element vend clients et hébergement Synapse/EMS. | La politique matrix.org confirme la réplication vers homeservers distants, éventuellement hors contrôle de la Foundation et sous d’autres lois. | Fédération distribue la confiance, mais chaque serveur demeure un point de concentration pour ses propres comptes et journaux. | Proportion des comptes par hébergeur; topologie/réplication réelle d’un salon spécifique. |
| 2. Protocole cryptographique | E2EE est optionnel par salon/client. Element utilise Olm pour échanges appareil-à-appareil et Megolm pour groupes; Megolm spécifie AES-256-CBC, HKDF-SHA-256, HMAC-SHA-256 tronqué à 64 bits, Ed25519. [Spec](https://spec.matrix.org/unstable/olm-megolm/megolm/) | Element annonce E2EE Olm/Megolm, vérification SAS/QR et sauvegarde de clés avec clé de récupération. | Analyse formelle 2024 : Olm+Megolm comparable à Signal+Sender Keys si les préclés Olm sont signées; PCS moins bonne si elles ne le sont pas. [Papier](https://arxiv.org/abs/2408.12743) | E2EE protège le contenu d’événements chiffrés si appareils vérifiés et implémentation saine; ne masque pas membership, IP, événements de contrôle ni salons non chiffrés. | Profil réellement négocié par build/client, state post-quantique et configuration actuelle sur chaque plateforme. |
| 3. Création d’identité | Identité de protocole = MXID @nom:serveur. Matrix ne requiert pas en lui-même email/téléphone; matrix.org exige aujourd’hui email vérifié dans ses conditions. | Matrix.org indique stocker username, hash de mot de passe, email, téléphone vérifié si fourni; pas de mot de passe en clair. | Politique effective 25 août 2025 : bcrypt avec au moins 4096 rounds, sel et pepper; username conservé indéfiniment pour éviter recyclage. | Un MXID sans téléphone peut rester pseudonyme, mais email, SSO, alias, serveur choisi et réutilisation de nom sont corrélables. | Données conservées par autres homeservers; suppression après désactivation et sauvegardes. |
| 4. Contact discovery | Identifiants tiers email/téléphone peuvent être associés à un MXID via Identity Service facultatif; matrix.org utilise son service d’identité. [API](https://spec.matrix.org/v1.15/identity-service-api/) | Matrix.org dit que email/téléphone peuvent permettre à d’autres de retrouver le MXID. | La spec définit vérification et lookup 3PID; ce n’est pas requis par le protocole global. | Si un utilisateur enregistre un 3PID, le service d’identité peut l’associer à son MXID, en dehors du chiffrement E2EE. | Rétention, limitation et résistance à l’énumération du service d’identité actuel. |
| 5. Métadonnées serveur | Homeserver traite MXID, device IDs, membership, room/event IDs, horodatages et événements de contrôle; corps chiffré en salon E2EE, structure de routage non cachée. | Matrix.org dit ne pas profiler et limiter la collecte aux besoins du service. | Étude forensique 2026 a extrait relations usager-salon, membership, appareils, IP, horaires, receipts, API calls de Synapse de test. | Le homeserver peut produire graphe social et chronologie même sans lire le contenu E2EE. | Durée des événements/logs/receipts/typing et rétention par instance, backups et services secondaires. |
| 6. IP utilisateur | Matrix.org déclare logger IP, device ID, user-agent et dernière connexion; IP logs jusqu’à 180 jours. Element déclare IP 180 jours pour Element chat, 30 jours pour IP des clients EMS, rageshake 180 jours. [Matrix](https://matrix.org/legal/privacy-notice/), [Element](https://element.io/legal/privacy) | Logs présentés comme prévention abus, diagnostic, gestion d’appareils. | Synapse 1.133.0 sur Ubuntu 22.04 a produit IP/user-agent/device/heure dans logs et table user_ips lors de l’étude 2026. | Connexion directe expose nécessairement l’IP source au homeserver; VPN/Tor déplacent le point d’observation et peuvent affecter les services. | Proxy/CDN en amont et IP loggée réellement; rétention/purge par serveur tiers. |
| 7. IP exposée au correspondant | Appel WebRTC peut utiliser chemin direct ou TURN/SFU. Element Call déclare traiter IP participants, MXID/device, timestamps et type d’appel. | Element dit que Element Call est E2EE; ESS utilise LiveKit auto-hébergé par défaut, call.element.io LiveKit Cloud. | Politique Element distingue métadonnées d’appel du contenu E2EE; l’étude Synapse 2026 n’évalue pas les fuites ICE côté client. | P2P peut révéler IP aux pairs; relay la cache au pair mais le relay connaît IP. E2EE du média ne cache pas IP/horaires au relais. | Chemin ICE réellement choisi par build/config, IPv6 et métadonnées conservées par LiveKit; pas de mesure packet-level ici. |
| 8. Messages | Événements Matrix persistent et se répliquent. En salon non chiffré le contenu est visible aux homeservers; en salon E2EE le corps est ciphertext si le client chiffre correctement. | Element précise que chiffrement est par salon et n’est pas automatiquement actif partout. | La spec définit événements chiffrés; étude 2026 retrouve contenus plaintext des échanges non chiffrés et dit que le contenu E2EE reste protégé. | E2EE ne protège pas salons non chiffrés, bots/bridges/membres lecteurs ni terminaux compromis. | Défaut exact par client, caches/prévisualisations, rétention, redaction propagée aux homeservers distants. |
| 9. Groupes | Membership, invitations, rôles/permissions et état du salon sont gérés comme événements; chiffrement ne cache pas en soi la membership au serveur. | Element dit chiffrer salons E2EE et vérifie les appareils. | Spec + étude Synapse 2026 montrent membership et liens room-user extractibles; recherche académique 2024 analyse limites Olm/Megolm. | Serveur compromis peut voir/perturber membership et distribution; vérification inter-appareils réduit le risque, sans l’annuler. | Résistance des versions actuelles à homeserver malveillant, historique des nouveaux membres et propagation suppressions. |
| 10. Appels | Matrix sert à la signalisation; Element Call peut employer WebRTC/MatrixRTC, TURN et LiveKit SFU. | Element présente média comme E2EE. | Sa politique expose IP, MXID/device, timestamps et type d’appel au service. | P2P expose plus les IP aux pairs; SFU centralise visibilité réseau/disponibilité; contenu et métadonnées sont couches différentes. | Chiffres crypto actuels, conservation LiveKit, appel P2P vs SFU par configuration. |
| 11. Fichiers | Media repository stocke fichiers et URI. En salon E2EE client peut chiffrer fichier et transmettre la clé dans l’événement chiffré; sinon media service lit le fichier. | Matrix.org dit utiliser AWS pour certains fichiers et que l’opérateur ne lit pas le contenu E2EE. | BSI a trouvé en 2023 média téléchargeable sans authentification si URL connue; Element dit corrigé par authenticated media Matrix 1.11 en juin 2024. | Partager un média hors fonction E2EE ou une URL/clé divulguée contourne la protection; EXIF/thumbnail dépend du client. | Purge cache/CDN et copies fédérées; assurance que chaque client chiffre thumbnails et fichiers. |
| 12. Multi-device | Chaque appareil a identifiants/keys propres; sync passe par homeserver; cross-signing établit confiance entre appareils. | Element documente QR/SAS et synchronisation/vérification appareils. | Vulnérabilités E2EE critiques 2022 touchaient certaines intégrations JS/iOS/Android SDK; Element X/Rust SDK n’était pas dans le groupe annoncé comme affecté. | Appareil ajouté non vérifié ou sauvegarde mal configurée élargit les détenteurs de clés. | UX et défauts d’ajout par version; comportement d’ignorance de vérification et export des clés actuels. |
| 13. Notifications push | Homeserver utilise Push Gateway puis APNs/FCM. Element indique OS peut voir roomID/eventID et token tandis que traitement restant est local. | Element dit que contenu déchiffré n’est pas partagé par ce chemin. | Politique Element liste métadonnées visibles Apple/Google; aucune capture du payload de release actuelle n’a été faite. | IDs/horaires push peuvent permettre corrélation avec installation et compte via d’autres données OS. | Payload exact par OS/config/région; liaison token↔MXID dans gateways et télémétrie OS. |
| 14. Stockage local | Clients conservent cache/sync state et clés locales pour fonctions multi-device; chiffrement est par appareil. | Element présente stockage de clés sécurisé selon plateforme/OS. | Étude 2026 précise que l’examen forensique complet des clients Element desktop/mobile/web reste à faire. | Appareil déverrouillé/compromis peut donner le contenu clair même si serveur n’a que ciphertext. | Algorithmes DB, gestion de clés keystore/keychain, caches supprimés/fichiers temporaires par version. |
| 15. Sauvegardes | Key backup Matrix stocke potentiellement clés de salon chiffrées côté serveur avec clé de récupération côté client; données distinctes des messages. | Element décrit sauvegarde chiffrée et récupération d’historique. | Étude 2026 observe des opérations backup dans logs, pas le déchiffrement de backup sans secret utilisateur. | Backup étend surface/copies; une recovery key ou un appareil autorisé compromis réduit séparation. | KDF, paramètres, rétention/suppression versions et defaults exacts par client. |
| 16. Analytics / telemetry / SDK | Matrix.org utilise PostHog agrégé basé sur MXID en centres UE. Element propose Matomo opt-in, Sentry/rageshake (potentiellement IP/hostname/nom/email) et MapTiler pour cartes. | Politiques décrivent analytics opt-in et crash reports volontaires. | Policies séparent analytics du serveur et des clients; aucune inspection des binaires/traffic faite ici. | Consentement, crash reports et SDK sont distincts d’E2EE; un rapport de crash volontaire peut identifier. | Liste exhaustive SDK/endpoints par build, activation par défaut et rétention actuelle des rapports. |
| 17. Code source | Spécification, Synapse, Element Web, Element X Android/iOS, matrix-rust-sdk et vodozemac ont des repos publics. | Element présente Element X et ses services comme code ouvert selon composants/licences. | Repos contiennent releases/CI; Element Classic Android reste maintenu sécurité mais sans nouvelles fonctions, migration recommandée vers X. [Classic](https://github.com/element-hq/element-android) | Code public ne rend pas l’instance hébergée, config, CI/signing, binaire Store ou service tiers vérifiables. | Nombre mainteneurs réellement actifs; composants commerciaux fermés et différences de build. |
| 18. Reproductibilité | Workflows CI/build sont publics. Repos publient artifacts et tags. | Les équipes fournissent instructions de compilation. | Releases vérifiées: Element X Android 26.09.4 (29 sept., commit 8f07865), iOS 26.09.2 (23 sept., 47f881c signé), Synapse 1.162.0 (29 sept., 63dc0cb signé), Element Web 1.12.31 (13 oct., 959eb55 signé). [Android](https://github.com/element-hq/element-x-android/releases), [iOS](https://github.com/element-hq/element-x-ios/releases), [Synapse](https://github.com/element-hq/synapse/releases), [Web](https://github.com/element-hq/element-web/releases) | Signature de tag authentifie objet Git mais n’établit pas identité entre source et binaire Store. | Rebuild bit-à-bit indépendant APK/IPA/desktop et provenance des artifacts non réalisés. |
| 19. Supply chain | Plusieurs SDK, dépendances et opérateurs tiers nécessaires; repos montrent CI, dépendances et advisories. | Element évoque Dependabot/outillage qualité et correctifs coordonnés. | Deux bugs E2EE critiques SDK publiés en 2022; buffer overflow CVE-2021-44538 dans libolm/matrix-js-sdk corrigé pour Element Web/Desktop 1.9.7; advisory ne vaut pas état actuel. [Disclosure](https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients/) | Déploiement d’instances/forks mis à jour à des rythmes différents maintient risque post-fix. | SBOM et provenance des builds Store; mainteneurs dépendances et comparaison version publiée/source. |
| 20. Infrastructure | Matrix.org mentionne AWS pour certains fichiers, Cloudflare anti-DDoS, PostHog UE; Element documente EMS, Element Call/SFU, identity server, Matomo, Sentry; homeservers du réseau tiers. [Domaines EMS](https://docs.element.io/latest/element-cloud-documentation/element-matrix-services/domains-and-ip-addresses/) | Matrix/Element indiquent choix de serveur et région d’hébergement selon offre. | Docs publient endpoints matrix.org, vector.im, element.io, call.element.io, sfu.call.element.io et services tiers. | Fédération ne retire pas dépendances à cloud/CDN/push propres à une config. | DNS/IP/ASN/CDN/région actuelle horodatés en passif; hébergeur de chaque serveur précis. |
| 21. Juridiction | Matrix.org Foundation CIC à Londres; politique couvre matrix.org seulement et cite Element comme processor. Autres homeservers gouvernés par opérateur/juridiction. | Foundation se présente comme custodian neutre du protocole; Element propose déploiements régionaux. | Politique reconnaît fédération/transferts potentiellement partout et hors contrôle de matrix.org. | Choix serveur est choix de confiance, mais copie d’un salon peut dépasser ce pays. | Région réelle de l’instance précise et transferts sous-traitants. |
| 22. Demandes policières | Matrix.org exige warrant UK IPA 2016 ou demande étrangère via MLAT; notification sauf interdiction; conservation 90 jours sur demande valide; urgence de mort/blessure grave imminente peut permettre disclosure sans warrant. [Guide](https://matrix.org/legal/law-enforcement-guidelines/) | Foundation dit ne pas remettre volontairement données et ne pas accéder au corps E2EE. | Guide fixe procédure, non compte réel de demandes/remises. Aucun transparency report agrégé repéré dans cette passe. | Un serveur peut produire ce qu’il détient : IP, identifiants, events non chiffrés, membership; homeservers fédérés sont opérateurs distincts. | Champs remis réellement dans chaque affaire, nombre demandes et ordres secrets/interceptifs. |
| 23. Affaires judiciaires | Le guide n’est pas un dossier judiciaire ni preuve d’une remise précise. | Foundation dit notifier utilisateur sauf interdiction. | Aucun cas primaire avec Matrix.org/Element et liste des champs divulgués retrouvé dans cette recherche. | Absence de cas public identifié ne prouve pas absence de demandes/remises. | Ordonnances, affidavits, FOIA et données effectivement obtenues. |
| 24. Audits | Rapports publics NCC 2016, Least Authority 2022 et BSI/MGM 2023 détaillés ci-dessous. | Matrix/Element mettent en avant les audits et corrections. | Périmètres/versions datés; aucun n’est audit complet de l’écosystème Matrix 2026 et tous les clients/serveurs. | Résolution d’un finding historique ne certifie pas version actuelle. | Audit indépendant 2026 du client X, Synapse courant, LiveKit, bridges, push et cloud. |
| 25. Vulnérabilités | Historique : bugs E2EE SDK critiques en 2022; CVE-2021-44538 buffer overflow; CVE timing libolm révélées en 2024; Synapse advisories; vulnérabilités state-resolution hautes sévérités annoncées 2025 (dont CVE-2025-49090). [2025](https://matrix.org/blog/2025/07/security-predisclosure/) | Matrix publie advisories et versions corrigées. | Conditions et plages de versions varient; release disclosure 2022 indiquait aucun signe d’exploitation observée à cette date. | Écosystème fédéré dépend de patch rate de serveurs indépendants, forks et clients. | Inventaire complet 2026, exposition réelle et compliance des instances, exploitation d’instances précises. |
| 26. Recherche académique | Papier formel 2024 étudie Olm/Megolm; papier DFRWS 2026 étudie Synapse 1.133.0. | Éditeur met en avant standard ouvert et chiffrement. | Les papiers formels/serveur ne certifient pas UI, builds mobiles ni configurations courantes. | Résultats guident tests, ne remplacent pas retest des releases. | Recherche récente indépendante sur Element X, push, federation et multi-device courant. |
| 27. Incidents historiques | Advisories documentent défauts de code/protocole et correctifs; disclosures 2021/2022 ont précisé conditions/versions. | Matrix a dit ne pas avoir observé exploitation de vulns 2022 au moment de publication. | CVE-2021-44538 était déclenchable à distance mais jugé peu pratique; bugs de clients ont été corrigés par release. | Vulnérabilité n’implique pas incident ou exploitation; garder capacité adversaire et période. | Exploit non divulgué ou impact sur instances non patchées. |
| 28. Gouvernance / société / financement | Foundation est CIC britannique custodian du protocole; Element société distincte développe Synapse/clients et vend hébergement; rapport annuel Foundation public. [2025 report](https://www.matrix.org/foundation/reports/2025%20Public%20Annual%20Report.pdf) | Foundation revendique neutralité/transparence; Element dit financer équipes sécurité via offres commerciales. | Rapport annuel établit activités/finances de Foundation, pas actionnariat/financement interne complet d’Element. | Fournisseur principal concentré peut faciliter cohérence et centraliser influence technique. | Mainteneurs clés, répartition exacte budget sécu, risques de succession et influence par service. |
| 29. Résistance à la censure | Standard ouvert, federation et auto-hébergement permettent changement d’instance et clients tiers. | Matrix affirme le choix du serveur et décentralisation. | APIs fédérées établies par spec; aucune mesure actuelle par pays/ISP de blocage n’a été conduite. | Migration possible si utilisateurs disposent de DNS/instances alternatifs; domaines, stores, FCM/APNs et internet peuvent être filtrés. | Résistance mesurée par pays/DPI, onboarding en censure, mécanisme anti-blocage officiellement déployé. |
| 30. Maintenance actuelle | Repos publient releases fréquentes et contribs multiples; état des versions exactes ci-dessus au 13 oct. 2026. | Element distingue Classic/X et niveaux de support de plateformes. | Element Web 1.12.31 mentionne un nouveau défaut de vérification device, avec réversion identifiée pour staging; Synapse 1.162.0 signé. | Activité amont n’assure pas mise à jour de tous les homeservers ni reproductibilité de builds. | Mainteneurs actifs mesurés, délai patch des opérateurs, artifact Store comparé au source et versions supportées exactes. |

### Matrix / Element — extraction d’audits

| Organisme / date / commanditaire | Version / commit | Durée / méthode | Scope / exclusions | Findings / sévérité | Recommandations, correctifs, retest |
|---|---|---|---|---|---|
| NCC Group Crypto Services, mandat Matrix financé par Open Technology Fund; rapport public 1 nov. 2016, v2.0. [PDF lu](https://www.nccgroup.com/media/5bspr3ie/_ncc_group_olm_cryptogrpahic_review_2016_11_01-1.pdf) | libolm 1.3.0; pas de commit SHA publié. | 2 consultants, 19–30 sept. 2016, 15 jours-personnes; revue source crypto, fuzzing entrées/pickling; suivi seconde moitié d’octobre. | Olm Double Ratchet/API, Megolm, C et entrées. matrix-js-sdk/clients **hors scope**; après 5 jours, l’audit a réorienté davantage de temps vers Megolm. | Initial : 1 HIGH, 1 MEDIUM, 6 LOW, 1 INFO (9); après retest : 1 HIGH, 1 MEDIUM, 5 LOW, 1 INFO restant (8). UKS Olm/Megolm, replay de groupes, forward/backward secrecy Megolm, transcript consistency, champs pre-key non MACés, bounds-check DoS. | Recommande lier identité aux prekeys, revue Megolm, rotation de sessions, canal sûr et protections timing/mémoire. Plusieurs protections appliquées dans matrix-js-sdk, mais findings marqués non fixés dans libolm lui-même; un bounds issue fixé. Pas de retest public clients actuels. |
| Least Authority TFA GmbH; audit vodozemac commandé par Matrix, final 30 mars 2022. [PDF lu](https://matrix.org/media/Least%20Authority%20-%20Matrix%20vodozemac%20Final%20Audit%20Report.pdf) | Revue initiale 7c11a501bc316a0bf92a5fe06fee8582aad24897; vérification 57d8d87a747653d6d7b7a53acb9a8d8f8de48285. | Revue 20 déc.–25 janv.; rapport initial 28 janv.; retest 28–29 mars; rapport final 30 mars. Le PDF ne donne pas de jours-personnes. | Librairie Rust vodozemac Olm+Megolm; dépendances et bindings Android/Java, Python, JS hors scope sauf cas cités. | A–H résolus selon dashboard; G session Olm invalide consommait OTK/DoS; H conservation d’ancien ratchet. I secrets en mémoire vulnérables au swap/side-channel et J MAC trop court restent non résolus; suggestion 8 sur configuration de chain/message keys non résolue. | Recommande amélioration secrets mémoire, rétention de ratchet et réexaminer MAC; retest confirme certains fixes sur commit donné. Aucun retest indépendant de version 2026. |
| MGM Security Partners, financé par BSI CAOS; rapport publié 2024. [PDF BSI](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/P486-Codeanalyse/Matrix-Kommunikationssoftware.pdf?__blob=publicationFile&v=3), [réponse Element](https://blog.element.dev/bsi-funds-security-analysis-of-matrix/) | Synapse 1.90.0 et Element 1.11.39, releases du 15 août 2023. | Tests 1 sept.–17 nov. 2023; scans sept.-oct.; white-box, analyse statique outillée + analyse dynamique. Jours-personnes non trouvés. | Synapse + Element dans déploiement combiné; pas audit crypto complet, federation générale, clients X courants ni infra cloud. PDF BSI renvoie 403 ici; résumé technique recoupé via réponse Element, pas rapport téléchargé intégralement dans cet environnement. | 3 findings vulnérabilité de faible sévérité selon Element : E3.1 média accessible URL connue; E4.1 clore sondage d’un autre utilisateur (Element conteste la qualification sécurité); E6.1 décrit comme bypass de CVE-2023-32683 (Element conteste et dit MGM suivait CVE-2023-49953). Autres : enumeration username, politique password client, version serveur, logs reset, session longue, fichiers, scan antivirus, headers Web, dépendances, TODO/FIXME et duplication. | Element dit média authentifié ajouté Matrix 1.11 en juin 2024; E7.1 réglé avec OIDC. D’autres points qualifiés de configuration/non-security (password serveur non activé au test, antivirus au download, headers du serveur Web). Retest public complet non retrouvé. |

**Recherche académique, non audit.** *The Matrix Reloaded* (Ginesin & Nita-Rotaru, arXiv v2, 7 déc. 2024) formalise Olm/Megolm dans Verifpal et précise que conclusion comparative dépend de signature des préclés Olm. Le modèle ne valide pas les SDK/UI/builds particuliers. [Papier](https://arxiv.org/abs/2408.12743)

### Matrix / Element — repositories, builds et supply chain

- Dépôts principaux : [Synapse](https://github.com/element-hq/synapse), [Element Web](https://github.com/element-hq/element-web), [Element X Android](https://github.com/element-hq/element-x-android), [Element X iOS](https://github.com/element-hq/element-x-ios), [matrix-rust-sdk](https://github.com/matrix-org/matrix-rust-sdk), [vodozemac](https://github.com/matrix-org/vodozemac). Element Classic est à distinguer d’Element X.
- Les tags consultés sont signés/vérifiés GitHub et les workflows CI sont publics. Cela authentifie objets Git, pas identité binaire/source; aucune reproduction bit-à-bit d’APK, IPA ou desktop n’a été effectuée.
- Repositories exposent releases, CI, dependabot et advisories; nombre des mainteneurs actifs estimé sur une fenêtre trimestrielle non calculé. Les contributors d’une release ne sont qu’un proxy.
- Instance hébergée matrix.org est administrée opérationnellement par Element; ESS/EMS, push, LiveKit Cloud, MapTiler, analytics/crash et serveurs tiers créent des dépendances distinctes du code protocole.

### Mobile privacy — store labels et code/permissions

| Surface | Élément observé ou déclaré | Limite |
|---|---|---|
| Google Play — Element X Android | Data Safety déclare « pas de données partagées avec tiers »; collecte possible : email, nom optionnel, photos/vidéos/audio/fichiers/messages optionnels selon usage et interactions pour analytics; chiffrement en transit. [Play](https://play.google.com/store/apps/datasafety?hl=en&id=io.element.android.x) | Auto-déclaration développeur variable par version/région/usage, non vérifiée par Google; ne recouvre pas nécessairement données de protocole chez le homeserver. |
| Apple App Store — Element X iOS | Store US déclare email, IDs user/device, location précise et diagnostics liés à identité; analytics également déclarés; Apple dit réponses non vérifiées. [App Store](https://apps.apple.com/us/app/element-x-secure-chat-call/id1631335820) | Label spécifique au storefront consulté; déclaration n’est pas preuve indépendante d’exfiltration/track publicitaire. |
| Permissions | Caméra/micro selon appel; photos/fichiers selon pièces jointes; localisation si partage location; contacts selon découverte choisie. | Manifest/entitlements du build Store actuel et permissions effectivement accordées non extraits ici. Permission déclarée ≠ accès effectivement utilisé. |
| SDK/analytics | Policies décrivent Matomo opt-in, Sentry/rageshake et MapTiler; release Android montre dépendance Sentry. | Aucun APK/IPA inspecté; pas de capture endpoint, tracker, trafic ou activation consentement. |
| Push | Policy Element indique APNs/FCM, token et métadonnées roomID/eventID possibles. | Aucune capture comparée Android/iOS et aucun payload évalué sur version actuelle. |

### Matrix / Element — infrastructure OSINT passive et juridiction

**Documenté publiquement :** Matrix.org dit AWS pour certains fichiers, Cloudflare anti-DDoS, PostHog hébergé en UE. Element publie endpoints EMS, Element Call, SFU, Identity Service, Matomo et Sentry; le réseau Matrix n’a pas de région globale car chaque homeserver est géré par son opérateur. La liste d’endpoints est dans [docs Element](https://docs.element.io/latest/element-cloud-documentation/element-matrix-services/domains-and-ip-addresses/).

**Observation de cette enquête :** un snapshot DNS A/AAAA/CNAME et BGP/ASN limité a été acquis pour les noms principaux matrix.org/Element et figure dans le complément ci-dessous. Il manque encore l’archive DNS historique, une observation du résolveur indépendant, les origines derrière CDN, les régions des backends et la cartographie des autres services; aucun scan ni test de ports n’a été fait.

**Frontières de confiance :** homeserver (IP, session, membership/events); homeservers fédérés (réplicas/juridictions); Identity Service (3PID↔MXID); Push Gateway/APNs/FCM (token/metadata); LiveKit/TURN/SFU (IP/temps/type call); AWS/media; Cloudflare selon endpoint; Matomo/Sentry/MapTiler selon fonctionnalités.

### Matrix / Element — forensics

| Étude / outil | Système + versions + date | Résultat | Limites |
|---|---|---|---|
| Wang et al., « DFRWS down the Rabbit-Hole: A forensic analysis of the Matrix protocol and Synapse server », FSI: Digital Investigation 56 (2026), DOI 10.1016/j.fsidi.2026.302049; outil open source SynExtract. [PDF lu](https://dfrws.org/wp-content/uploads/2026/03/DFRWS-down-the-Rabbit-Hole-A-forensic-analy_2026_Forensic-Science-Internati.pdf) | Ubuntu Server 22.04; Synapse 1.133.0 Docker, Synapse Admin 0.11.1, SQLite; Element Desktop Ubuntu, Element Android 1.6.44 / Android 13; trois comptes de test. | Extraction de 175 tables annoncées et logs Docker : user/device IDs, IP/user-agent, login, salons/membership, horaires, receipts, API calls, media transfer, événements de clé/backup. Corps E2EE demeure chiffré; plaintext observé dans échanges non chiffrés. | Homeserver unique; fédération/bridges exclus; pas d’interception active de clés; les auteurs disent que forensique clients Element desktop/mobile/web reste à faire. Ce n’est pas Cellebrite/GrayKey/Magnet ni un cas de divulgation policière. |
| Schipper, Seelt & Le-Khac, « Forensic analysis of Matrix protocol and riot.im application », FSI: Digital Investigation 36 (2021), 301118. [DOI](https://doi.org/10.1016/j.fsidi.2021.301118) | Riot.im pré-Element, étude publiée 2021. | Étude historique de client et structures LevelDB/SQLite, référencée par les auteurs 2026. | Build/appareil/outil commercial doivent être relus dans PDF avant toute transposition; ne prouve rien sur Element X actuel. |

**Cellebrite / GrayKey / Magnet.** Pas de preuve publique vérifiée retrouvée ici qui donne simultanément outil, OS/build, version exacte Element, date et résultat d’extraction. On ne conclut ni impossibilité ni capacité actuelle. Les traces DB/keys/fichiers/caches doivent être testées en labo avec versions exactes; l’étude de serveur ne s’applique pas à un téléphone.

### Matrix / Element — law enforcement : ce qui est disponible et ce qui a réellement été remis

| Niveau | Résultat |
|---|---|
| Techniquement disponible | Matrix.org déclare MXID, email/téléphone éventuellement vérifiés, device ID, IP, user-agent, last seen et contenu/événements selon chiffrement. Pour salon E2EE, contenu ciphertext côté serveur; metadata de protocole demeure. Autres serveurs ont politiques propres. |
| Officiellement annoncé | Warrant UK IPA 2016 ou MLAT étranger; preservation jusqu’à 90 jours sur demande valide; notification sauf interdiction; transfert de données E2EE vers l’agence; exception d’urgence de danger imminent grave selon politique. |
| Effectivement remis dans un cas documenté | Aucun cas primaire avec Matrix.org/Element, ordonnance et champs effectivement transmis retrouvé dans cette phase; aucun rapport public agrégé repéré. « Non identifié publiquement ici », pas « jamais remis ». Ne pas confondre avec l’opération du 3 décembre 2024 contre un service criminel distinct nommé « MATRIX » : Europol dit que 2,3 millions de messages de ce service ont été interceptés/déchiffrés, et a confirmé à Matrix.org que le service n’a aucun lien avec le protocole Matrix; la police néerlandaise confirme également la distinction. Ce n’est donc pas une preuve d’accès à Matrix.org, Synapse ou Element. [Europol](https://www.europol.europa.eu/media-press/newsroom/news/international-operation-takes-down-another-encrypted-messaging-service-used-criminals), [clarification Matrix.org rapportant la réponse d’Europol](https://matrix.org/blog/2024/12/unrelated-cybercriminal-network-taken-down/), [police néerlandaise](https://www.politie.nl/headless-api/nieuws/2024/december/3/11-opnieuw-versleutelde-communicatiedienst-criminelen-ontmanteld.html). |

### Matrix.org — complément probatoire sur politique, infrastructure et demandes (contrôle du 14 octobre 2026)

Cette mise à jour précise le périmètre matrix.org à partir de la notice effective du 25 août 2025 et du guide LE actuellement publié. Elle ne s’étend pas automatiquement aux autres homeservers, aux autres clients Matrix, ni à un retour policier réel.

| Sujet | FACT — texte publié / observation | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| Identité et compte | La notice matrix.org énumère MXID/username, hash de mot de passe, display name, email, téléphone vérifié si fourni, SSO liés et type de compte; username conservé indéfiniment pour éviter le recyclage. | La Foundation dit limiter ces champs et ne pas profiler les utilisateurs du homeserver. | Politique primaire de l’opérateur, pas inspection indépendante de la base de production. | Un compte sans nom civil reste pseudonyme seulement si email/SSO/alias et autres liens ne l’identifient pas. | Suppression réelle et expiration des sauvegardes, rétention des emails/3PID et données par fournisseur SSO. |
| Sessions, IP et appareil | La notice cite création/fin/dernière activité de session, dernière IP, user-agent initial, client utilisé; par appareil: identifiant configurable, IP, user-agent, dernière connexion. Les journaux IP d’accès seraient conservés au plus 180 jours. | Motifs annoncés: gestion des appareils, anti-abus, diagnostic et tendances de trafic. | Étude Synapse 1.133.0 reproduit la disponibilité de champs similaires en laboratoire; elle ne mesure pas le cluster matrix.org ni sa purge. | Un serveur peut produire une chronologie de compte et lier sessions/IP/device IDs; la politique ne prouve pas la purge effective. | Routage proxy, IP visible dans les logs app vs réseau, vérification de purge; pratiques d’autres homeservers. |
| Analytics | Plausible pour le site, sans cookies/identifiants persistants; PostHog pour usage du compte, décrit comme agrégé à partir du MXID, hébergé dans l’UE. | La Foundation présente l’usage comme agrégé et destiné à améliorer les performances, sans profilage. | Politique seulement; pas d’instrumentation du client ni capture de télémétrie faite. | « Agrégé » et « sans profilage » ne signifient pas qu’aucun événement ne soit associé au MXID avant agrégation. | Schéma d’événements, base d’agrégation, IP/champs transmis, rétention exacte et activation selon client. |
| Hébergeurs/régions | La même notice dit que la majorité du service est hébergée dans des centres Mythic Beasts, certains services dans des centres UpCloud, et nomme Element comme processeur. Elle place PostHog en centres UE. | Des documents officiels distincts citent aussi AWS pour certains fichiers et Cloudflare anti-DDoS. | Les documents établissent des déclarations d’opérateur, pas le mapping hostname→fournisseur/région actuellement actif. | Les références peuvent concerner des services distincts ou des périodes différentes; il serait prématuré de désigner l’une comme fausse. | Répartition exacte des médias, API, anti-DDoS, backups, logs et appels; régions physiques et chaîne de sous-traitance actuelle. |
| Procédure de demandes | Le guide LE dit qu’un ordre valide est requis pour les informations non publiques; le canal opérationnel présenté exige une autorisation UK au titre de l’IPA 2016 et les demandes étrangères via MLAT. Conservation: 90 jours, extensible sur requête valide. | Notification des personnes visées sauf interdiction; urgence sans mandat si danger imminent de mort ou blessure physique grave; données transférées à l’agence sous chiffrement de transport. | Guide primaire de politique, non preuve du nombre ou des champs effectivement produits dans un cas. Aucun rapport agrégé ni dossier de production attribué à Matrix.org identifié dans cette recherche. | Le transport E2EE de la réponse ne signifie pas que le fournisseur déchiffre un salon applicatif E2EE; il signifie que le fichier de réponse est protégé en transit. | Catégories exactes déjà remises, conservation après demande, ordres secrets/interception et cas non publics. |
| Résultats judiciaires | Aucun dossier public primaire consulté ne relie une demande à des champs effectivement remis par Matrix.org/Element. | Le guide annonce notification et non-remise volontaire pour la surveillance. | La mention d’un service criminel distinct « MATRIX », intercepté/démantelé en 2024, ne concerne pas le protocole Matrix; Matrix.org indique qu’Europol lui a confirmé l’absence de lien. | Consigner séparément « données techniquement détenues », « cadre de réponse annoncé » et « production observée »; le troisième état reste inconnu ici. | Dockets, retours de warrant, FOIA et dossiers étrangers ou scellés. |

**Mise à jour de la matrice d’observateurs.** Pour le homeserver matrix.org seulement: IP = CONFIRMÉ, rétention annoncée ≤180 jours; email = CONFIRMÉ comme champ de compte; téléphone = POSSIBLE/CONFIRMÉ s’il est fourni et vérifié; MXID/device/session/timestamps = CONFIRMÉ; graphe social/membership = CONFIRMÉ par l’architecture et les données de salon; contenu = lisible en salons non chiffrés, ciphertext côté serveur pour salons E2EE selon politique; push = élément lié à l’appareil selon Element, tandis que l’OS peut voir roomID/eventID. Pour les autorités, ces catégories sont techniquement possibles si elles existent encore, mais aucune remise Matrix.org avec champs concrets n’a été établie ici. Pour un homeserver tiers, chaque cellule doit être remplacée par sa propre politique et sa configuration.

**Observation DNS/BGP publique, limitée et datée.** Entre environ 00:23 et 00:27 le 14 octobre 2026, heure Europe/Paris (22:23–22:27 UTC le 13 octobre), les noms ci-dessous ont été résolus par le résolveur configuré localement avec des requêtes DNS A/AAAA/CNAME; ce résolveur n’a pas été identifié. RIPEstat `network-info`/`as-overview` a ensuite été interrogé sur les IP obtenues. Les TTL sont ceux vus dans les réponses et peuvent varier. L’ASN désigne le réseau annonçant l’adresse résolue, pas nécessairement l’hébergeur d’origine ni l’entité contrôlant les données.

| Nom / rôle documenté | DNS observé (TTL approx.) | Préfixes annoncés / ASN RIPEstat | Interprétation et limites |
|---|---|---|---|
| `matrix.org` (homeserver public/nom de service) et `matrix-client.matrix.org` (utilisé comme endpoint média par un projet officiel Matrix) | A: `172.66.139.239`, `172.66.135.3`; AAAA: `2606:4700:10::ac42:8bef`, `2606:4700:10::ac42:8703`; TTL 30–300 s. Les deux noms partagent les mêmes réponses observées. | IPv4 `172.66.128.0/20`, IPv6 `2606:4700:10::/44`, AS13335 — CLOUDFLARENET / Cloudflare, Inc. | Les adresses visibles sont sur Cloudflare; origine, chemin jusqu’au homeserver et distinction entre site/API/media non établis par cette résolution seule. Le client Matrix peut aussi découvrir une base URL selon son serveur. |
| `vector.im` (identity service listé dans la documentation Element) | A: `172.67.144.66`, `104.21.28.52`; AAAA: `2606:4700:3030::ac43:9042`, `2606:4700:3030::6815:1c34`; TTL ~300 s. | `172.67.144.0/20`, `104.21.16.0/20`, `2606:4700:3030::/48`, AS13335 — Cloudflare. | Edge DNS observé; backend, région et journaux de l’Identity Service inconnus. |
| `call.element.io` (client web Element Call) | A: `104.20.39.237`, `172.66.165.154`; AAAA: `2606:4700:10::ac42:a59a`, `2606:4700:10::6814:27ed`; TTL ~300 s. | `104.20.32.0/20`, `172.66.160.0/20`, `2606:4700:10::/44`, AS13335 — Cloudflare. | Cela attribue le frontend/hostname observé à l’edge Cloudflare, pas le chemin du média ni le SFU. |
| `sfu.call.element.io` et `livekit-jwt.call.element.io` (SFU et service JWT selon docs Element) | Les deux CNAME ont abouti à `k8s-core-coreingr-b3bd03665a-d205ac2886bcb3d3.elb.eu-central-1.amazonaws.com`; A `3.72.129.101` pour les deux. AAAA `2a05:d014:f9c:f200:3c8b:2a0e:96a7:bbc2` observé pour `sfu.call.element.io`. TTL vus ~16–300 s selon la réponse/le moment. | IPv4 `3.64.0.0/12`, IPv6 `2a05:d014:c00::/38`, AS16509 — AMAZON-02 / Amazon.com, Inc. | Le CNAME porte le label régional AWS `eu-central-1` (Europe/Francfort). Ce point de présence concerne les noms résolus à cet instant; il ne démontre ni l’unicité de région ni la résidence des logs, des clés, ou de toutes les données d’appel. [Régions AWS](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html). |

Références de contrôle BGP: [RIPEstat AS13335](https://stat.ripe.net/AS13335), [RIPEstat AS16509](https://stat.ripe.net/AS16509), [endpoint Matrix/Element et identity service](https://docs.element.io/latest/element-cloud-documentation/element-matrix-services/domains-and-ip-addresses/), [endpoint média Matrix dans le dépôt officiel](https://github.com/matrix-org/policyserv), [spécification de découverte homeserver](https://github.com/matrix-org/matrix-spec/blob/main/content/client-server-api/_index.md). Ces sources documentent les rôles ou ASN; les enregistrements DNS listés sont des observations faites pendant cette enquête, pas des archives historiques. Aucun scan ni test de ports n’a été effectué.

Sources primaires: [notice Matrix.org](https://matrix.org/legal/privacy-notice/), [guide Law Enforcement](https://matrix.org/legal/law-enforcement-guidelines/), [spécification d’architecture](https://spec.matrix.org/latest/), [politique Element](https://element.io/en/legal/privacy).

### Matrix / Element — matrice des métadonnées par observateur

| Métadonnée | Fournisseur / homeserver | Contact | ISP / réseau | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ : connexion, matrix.org indique jusqu’à 180 j | POSSIBLE lors appel P2P ICE; sinon relay | CONFIRMÉ : source/destinations/timing | POSSIBLE via push/store/OS | PROBABLE si logs conservés; remise réelle inconnue |
| Téléphone | POSSIBLE s’il est donné/lié comme 3PID | POSSIBLE si profil/partage | CONFIRMÉ par opérateur téléphonique, mapping MXID non automatique | PROBABLE via compte OS/store, lien MXID inconnu | POSSIBLE via opérateur/service; remise non documentée |
| Email | CONFIRMÉ sur matrix.org; dépend serveur ailleurs | POSSIBLE si divulgué/lookup 3PID | NON ACCESSIBLE PAR DESIGN sous TLS seul | PROBABLE via compte OS/store; liaison inconnue | POSSIBLE si homeserver le détient; cas de remise inconnu |
| Identifiant | CONFIRMÉ : MXID, device IDs | CONFIRMÉ pour interlocuteurs/salons connus | POSSIBLE par corrélation, pas MXID lisible sous TLS | POSSIBLE ID application/installation | POSSIBLE via instance et compte; cas inconnu |
| Graphe social | CONFIRMÉ : membership/rooms; étude 2026 retrouve ces liens | CONFIRMÉ pour salons connus | POSSIBLE par timing multi-point | POSSIBLE via room/event IDs push | PROBABLE si homeserver ciblé possède les événements; disclosure inconnue |
| Timestamps | CONFIRMÉ : événements, connexion, receipts selon config | CONFIRMÉ pour échanges reçus | CONFIRMÉ via métadonnées trafic | PROBABLE via événements push | PROBABLE si logs/events retenus; cas inconnu |
| Volumes | CONFIRMÉ : ciphertext/media et transferts | CONFIRMÉ pour reçus/appels | CONFIRMÉ octets/durées | POSSIBLE taille/rythme push | POSSIBLE serveur/ISP, champs remis inconnus |
| Groupes / salons | CONFIRMÉ membership/IDs/état, contenu chiffré si E2EE | CONFIRMÉ pour salons partagés | POSSIBLE motifs trafic | POSSIBLE IDs de notification | PROBABLE au homeserver pertinent; cas non documenté |
| Appareils | CONFIRMÉ IDs/clés publiques/agent/last seen | POSSIBLE via vérification/liste selon client | POSSIBLE nombre sessions/IP | PROBABLE device/token OS; mapping variable | POSSIBLE données serveur ou saisie terminal |
| Push tokens | CONFIRMÉ au Push Gateway/serveur selon flux | NON ACCESSIBLE PAR DESIGN token d’un autre appareil | POSSIBLE destinations APNs/FCM | CONFIRMÉ token installation et metadata policy | POSSIBLE auprès homeserver/Apple/Google; cas Matrix non identifié |

### Matrix / Element — matrice provisoire TM1–TM15 (pas un classement)

| TM | Valeur | Justification |
|---|---|---|
| TM1 — fournisseur curieux | 🟡 | Salon E2EE vérifié cache contenu; IP, sessions, membership/rooms, appels et salons non chiffrés restent visibles au serveur. |
| TM2 — fournisseur compromis | 🟡 | Ciphertext protège corps historique, mais serveur maîtrise disponibilité, fédération, metadata et livraison de clés; bugs historiques montrent risque versionnel. |
| TM3 — fournisseur malveillant | 🟡 | Vérification SAS/cross-signing peut signaler changement, mais client/versions et distribution de clés restent surfaces; choix du homeserver est central. |
| TM4 — ISP/Wi-Fi | 🟠 | TLS masque le corps, pas IP, horaires, volume; P2P peut divulguer l’IP au correspondant. |
| TM5 — adversaire passif multi-points | 🟠 | Serveur, push, SFU/TURN et FAI peuvent corréler temps/volumes; pas de mixnet démontré. |
| TM6 — adversaire global passif | 🔴 | Pas de protection documentée contre corrélation globale d’un réseau fédéré IP; métadonnées observables à plusieurs points. |
| TM7 — contact malveillant | 🟠 | Contact membre voit messages, peut capturer/partager et inviter bot/bridge; appel P2P peut exposer IP. |
| TM8 — doxxer OSINT | 🟡 | MXID/serveur compartimentés favorisent pseudonymat; email/téléphone, alias, avatars et salons publics corrèlent. |
| TM9 — demande judiciaire ordinaire | 🟠 | Guide Matrix.org spécifie mandat/conservation; homeserver détient IP, IDs, membership et contenu non E2EE; remise réelle inconnue. |
| TM10 — enquête sophistiquée | 🟠 | Étude Synapse 2026 montre extraction serveur de IP/appareils/rooms/timeline; contenu E2EE reste ciphertext sans clés. |
| TM11 — appareil verrouillé saisi | ❓ | Pas d’étude Cellebrite/GrayKey/Magnet actuelle avec OS/build/app Element précis retrouvée. |
| TM12 — appareil déverrouillé | 🔴 | Client/OS rendent les contenus accessibles en clair à l’utilisateur/processus; acquisition précise non testée. |
| TM13 — spyware ciblé | 🔴 | Spyware endpoint peut saisir écran, entrées, mémoire ou audio avant/après chiffrement; E2EE ne protège pas l’endpoint. |
| TM14 — supply-chain compromise | 🟠 | Source ouvert et tags signés, mais store/CI/cloud/tiers peuvent diverger; builds non reproduits. |
| TM15 — censure étatique | 🟡 | Auto-hébergement/fédération aide migration; domaines, DNS, stores, push et accès réseau peuvent être filtrés; pas de mesure pays par pays. |

### Matrix / Element — contradictions, zones inconnues, expériences à mener

- « Matrix est E2EE » est trop large : chiffrement par salon/client, optionnel dans le standard; salon non chiffré est lisible par homeservers.
- « Décentralisé donc sans point central » confond réseau et opération : un homeserver centralise les données de ses comptes; replication et federation ajoutent détenteurs/juridictions et empêchent d’assurer suppression globale.
- « Calls E2EE donc rien visible » est contredit par la politique Element Call, qui déclare IP, MXID/device, timestamps et type d’appel. Média et métadonnées sont deux couches.
- NCC 2016 findings de crypto/protocole, mitigations applicatives annoncées; formalisation 2024 montre dépendance aux signatures de préclés. Cela ne prouve ni vulnérabilité présente ni absence de vulnérabilité en release courante.
- BSI 2023 : le rapport décrit findings faibles; Element conteste certaines qualifications et annonce corrections. PDF BSI renvoie 403 ici, donc finding-level recoupé via l’éditeur, non lecture intégrale indépendante.
- Forensics 2026 : 175 tables concerne Synapse 1.133.0 de labo, pas un téléphone, pas outil commercial, pas disclosure à la police, et pas chaque déploiement. Paper distingue corps E2EE ciphertext de messages non chiffrés.
- Law enforcement : guide établit procédure/capacité, pas un cas de champs réellement remis. Cas documenté inconnu, pas preuve de non-remise.
- **Expériences nécessaires** : (1) payload APNs/FCM et analytics avec consentement sur builds exacts; (2) WebRTC direct vs TURN/SFU/IPv6; (3) build Store reproductible, manifests/entitlements/SDK/permissions; (4) tests de suppression, federation, retention/logs/media; (5) extraction forensique téléphone verrouillé/déverrouillé avec modèle+OS/build+Element+outil notés; (6) DNS/ASN/CDN passif horodaté; (7) cas judiciaire primaire montrant champs effectivement divulgués; (8) retest indépendant des fixes NCC/Least Authority/BSI sur commits actuels. Aucun test de cette liste n’est présenté comme réalisé.

## Cwtch — dossier de preuves (situation au 13 octobre 2026)

Sources primaires déterminantes : [manuel technique et de sécurité](https://docs.cwtch.im/security/intro/), [protocole Tapir](https://docs.cwtch.im/security/components/tapir/authentication_protocol/), [paquets Tapir](https://docs.cwtch.im/security/components/tapir/packet_format/), [serveurs et groupes](https://docs.cwtch.im/security/components/cwtch/server/), [fichiers](https://docs.cwtch.im/docs/chat/share-file/), [stockage local](https://docs.cwtch.im/security/components/cwtch/profile-encryption/), [changelog](https://docs.cwtch.im/changelog/), [repo core](https://git.openprivacy.ca/cwtch.im/cwtch), [repo UI](https://git.openprivacy.ca/cwtch.im/cwtch-ui), [rapport annuel 2022](https://openprivacy.ca/reports/2022-eoy-report/), [fiche Play](https://play.google.com/store/apps/details?id=im.cwtch.flwtch).

| # | Catégorie | FACT — documenté/observé | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN / réserve |
|---:|---|---|---|---|---|---|
| 1 | Architecture | Apps clientes et bibliothèque Go; connexions inter-nœuds par onion services Tor v3. P2P privé nécessite les deux pairs en ligne; l’asynchronisme des groupes repose sur serveur volontaire. | « Pas de service/réseau Cwtch », infrastructure non fiable et résistance aux métadonnées. | Papier de conception 2018, protocole publié, code ouvert; pas de validation indépendante actuelle des propriétés complètes. | La topologie réduit les points centraux mais déplace le risque vers Tor, appareils, serveurs de groupes et distribution. | Modèle de déploiement réellement utilisé par les groupes et versions différentes de l’app. |
| 2 | Protocole crypto | Profils avec clé Ed25519 compatible onion v3; authentification P2P de type 3DH, KDF et chiffrement de session. Paquets 8192 octets rembourrés puis Secretbox libsodium; signatures de messages de groupe Ed25519. | La documentation présente P2P comme authentifié, chiffré, déniable après session; groupes chiffrés par clé de groupe. | Détails algorithmiques publiés dans le handbook; aucune analyse cryptographique indépendante récente retrouvée. | Le rembourrage fixe réduit la fuite de taille du paquet Tapir, mais pas les horaires, fréquences ou corrélations réseau. | Paramètres KDF/Secretbox exacts par commit, gestion/rotation de clé de groupe et propriétés formelles de la release stable. |
| 3 | Création d’identité | Création locale d’une paire aléatoire Ed25519 par profil; l’adresse onion v3 est l’identifiant partageable. | Identité pseudonyme sans compte central. | Source et docs concordent sur le format/identifiant; aucune preuve d’entropie mesurée sur chaque plateforme. | Réutiliser le profil/adresse crée une identité persistante et linkable. | RNG matériel/OS, garanties par version et protection du secret en mémoire. |
| 4 | Découverte de contacts | Pas de recherche globale par numéro/e-mail; les adresses doivent être échangées hors bande ou par conversation déjà connue. | Contact « sans consentement explicite » absent du répertoire central. | Architecture et modèle onion visibles dans les docs. | L’OSINT d’une adresse divulguée devient une attaque ciblée; l’adresse est un identifiant longue durée. | Collecte réelle de carnet local par chaque build; pas d’audit manifeste/traffic ici. |
| 5 | Métadonnées serveur | Serveur de groupe stocke messages chiffrés et sert les clients; les docs décrivent une inférence par signatures uniques et demandes de nouveaux messages; le projet reconnaît ne pas garantir une résistance totale. | Serveur non fiable, sans identité de membres, groupe ni contenu en clair. | Les propres spécifications du projet exposent les inférences et le risque de censure/DoS. | Serveur peut constater des sessions, synchronisations, volume et cadence même si l’app ne donne pas de noms. | Schéma exact des logs, rétention, observabilité opérateur et état des serveurs réels. |
| 6 | IP utilisateur | Transport via Tor v3; le FAI voit une connexion Tor/volumes/horaires, pas l’adresse onion destinataire en clair dans une utilisation nominale. | Tor empêche le serveur de connaître l’IP réelle du client. | Architecture technique Tor documentée; aucun test de fuite réseau sur build 1.17.2 réalisé. | Une corrélation multi-points, un terminal compromis ou un Tor binaire/process malveillant peut réduire la protection. | Fuites DNS/IPv6, comportement en panne de Tor, télémétrie au démarrage et différences par OS. |
| 7 | IP exposée au correspondant | Échange via onion services plutôt que socket public direct; aucune IP publique du client n’est prévue dans le protocole d’identité. | Les contacts ne reçoivent que l’adresse onion. | Conception publiée; pas de test paquet sur Android/Desktop courant. | Tor masque l’IP réseau au pair dans le fonctionnement attendu, mais ne protège pas contre logiciel/OS compromis ou erreur de configuration. | Résultat pcap client→client v1.17.2, et effet d’un proxy Tor externe/Whonix/Tails. |
| 8 | Messages | P2P synchrone; historique facultatif/local. Groupes expérimentaux via serveur, messages récupérés depuis la dernière synchro; suppression par défaut au shutdown selon ancien réglage global, réglable dans les versions ultérieures. | E2EE et déniabilité. | Manuel technique décrit les formats, signatures, padding et modèle de serveur; pas d’audit indépendante. | Les groupes et P2P n’ont pas le même régime de livraison ni les mêmes fuites. | Comportement exact du défaut « save history » en 1.17.2 et tous clients. |
| 9 | Groupes | Legacy groupes via serveur onion non fiable, participation opt-in; Hybrid Groups introduits en 1.17, également expérimentaux et distincts. L’hôte Hybrid de confiance voit contenu et métadonnées. | Legacy server ne devrait pas apprendre l’identité/contenu/groupe; Hybrid fait un compromis de confiance explicite. | Changelog 1.17/1.17.2 et handbook énumèrent les risques, limites de cohérence/censure. | Une invitation Hybrid change le modèle de menace : l’opérateur-hôte est un destinataire de confiance, pas un serveur aveugle. | Examen indépendant du protocole Hybrid, stabilité et comportement réel des fonctions expérimentales. |
| 10 | Appels | Aucun appel audio/vidéo documenté dans le client standard consulté. | Pas d’affirmation vérifiée pour une capacité d’appel. | Fiche Play et docs examinées; aucun appel décrit. | Exposition de médias d’appel non applicable à la version/produit documenté. | Plugins/bots tiers ou forks de protocole peuvent ajouter des appels. |
| 11 | Fichiers | Fonction expérimentale opt-in; contenu transféré onion-à-onion directement, expéditeur en ligne nécessaire. Offre de groupe (nom, taille, hash, nonce) publiée dans message de groupe; manifeste Android dans cache. | Le serveur de groupe ne reçoit pas le contenu fichier. | Docs reconnaissent l’offre, métadonnées de fichier, cache et EXIF/PDF pouvant révéler identité/localisation. | Le contenu peut être E2EE mais offre et pièce jointe peuvent révéler des métadonnées aux membres et à l’endpoint. | Chiffrement de stockage de chaque fichier/cache par OS, nettoyage après réception, reprise et comportement de métadonnées pour chaque format. |
| 12 | Multi-device | Export/import de profil disponible; même profil/key material peut être déplacé; pas d’état « cloud account » central. | Contrôle local par l’utilisateur. | Docs et changelog confirment export/import. | Export accroît l’exposition et peut dupliquer un secret long terme. | Sync simultanée, clones concurrents et notifications entre appareils selon versions. |
| 13 | Push | Pas de preuve d’APNs/FCM pour le client Cwtch examinée; l’app Android utilise des capacités de service/notification système. | Play déclare aucune donnée collectée/partagée par l’app. | Déclaration Google Play auto-fournie; elle ne remplace pas inspection du binaire/flux. | L’absence de serveur Cwtch n’empêche pas les métadonnées OS, stores ou Tor. | FCM/APNs réellement embarqués, payloads, token, permissions, notification preview et réseau du binaire 1.17.2. |
| 14 | Stockage local | Profils SQLite chiffrés avec clé dérivée du mot de passe via PBKDF2; profil « sans mot de passe » utilise un mot de passe par défaut codé en dur. Passage en 1.16.1 à nouveau backend chiffré go-sqlcipher et crypto Go mémoire sûre. | Le mot de passe fort protège contre accès au système de fichiers. | Handbook et changelog explicitent le défaut faible et la migration du backend. | Sans mot de passe choisi, copie du profil peut être déchiffrable; chiffrement DB n’efface pas les caches, swaps, journaux ou états en mémoire. | Paramètres PBKDF2, chiffrement exact du backend courant, mémoire, fichiers temporaires, protection par Keychain/Keystore. |
| 15 | Sauvegardes | Export local; aucun service de sauvegarde fournisseur établi. Fichier téléchargé/exports peuvent contenir données en clair selon choix OS. | L’utilisateur contrôle l’export. | Documentation officielle. | Copie hors appareil multiplie les lieux d’exposition. | Processus backup téléphone, cloud d’OS et suppression des anciennes copies. |
| 16 | Analytics/SDK | Repo Flutter, Go, Tor; Play indique « aucune collecte/partage » selon déclaration du développeur. Aucun inventaire SDK dynamique réalisé. | Pas de données collectées/partagées (Play); privacy policy Cwtch dit ne pas collecter l’usage, hors feedback. | Politique et fiche Play sont primaires mais auto-déclarées; le code public est inspectable, non inspecté ici fichier par fichier. | Feedback volontaire peut associer e-mail/clé publique à un rapport; store/CDN/build restent tiers. | Crash analytics, Flutter telemetry dans app, SDKs/permissions effectifs, trafic réseau et iOS inexistant. |
| 17 | Code source | Core Go et UI Flutter/Dart publics sur Gitea Open Privacy; activité observée : core 1 330 commits, latest listé 24 sept. 2026; UI 1 554 commits, latest 8 oct. 2026; releases et tags publics. | Process review-driven/open. | Pages repo, commits, Drone CI et handbook consultés. | Activité soutenue mais petit noyau apparent (Erinn/Sarah/Dan identifiables dans l’historique affiché); compter les mainteneurs exige une analyse des contributions. | Nombre exact de mainteneurs actifs par sous-composant et règles de signatures de release. |
| 18 | Reproductibilité | Scripts repliqate permettent de reproduire les bindings; documentation officielle dit que seuls les bindings sont reproductibles aujourd’hui, pas l’application/UI intégrale. macOS dépend SDK Apple; app embarque Tor et libCwtch téléchargés par scripts. | Reproducible builds comme objectif. | Documentation de release, scripts et communiqué 1.17 identifiant libCwtch v0.3.0. Aucun rebuild indépendant mené ici. | Le hash SHA-512 confirme le fichier téléchargé contre checksum publié, pas la correspondance code/binaire. | Résultat bit-à-bit pour binaires 1.17.2 toutes plateformes, provenance/signature des Tor/lib, intégrité de pipeline. |
| 19 | Supply chain | Go, Flutter, Tor empaqueté, SQLCipher/go-sqlcipher, dépendances Dart et outils Drone; CI requiert approbation membre de l’équipe; trois staff autorisés à outrepasser trunk selon handbook. | Ouverture et tests automatisés réduisent le risque. | Pipeline et risques propres reconnus dans handbook; Windows installer signé, checksums SHA-512 publiés. | Compromission d’un membre autorisé, runner, domaine de téléchargement, toolchain ou dépendance peut viser les binaires. | SBOM complet courant, signatures vérifiées, attestations, pinning intégral, audit de runners et résultats des rebuilds. |
| 20 | Infrastructure | Pas de serveur de messagerie central; domaines de code/téléchargement, CI et site Open Privacy sont des points d’administration. Serveurs de groupes sont opérés volontairement sous onion service. | « Pas de réseau Cwtch » au sens d’un service central. | Code/doc officiel, aucune résolution DNS/ASN passive horodatée faite dans cette phase. | Le plan de données décentralisé n’élimine pas la centralisation de distribution des binaires et du code. | IP/ASN/hébergeurs/cloud/CDN/régions des domaines/serveurs opérés, logs Tor, fournisseurs et redondance. |
| 21 | Juridiction | Open Privacy Research Society est une organisation sans but lucratif incorporée en Colombie-Britannique, Canada. Les serveurs de groupes peuvent être partout. | L’organisation affirme ne pas pouvoir collecter l’usage ordinaire. | Politique vie privée et rapports annuels Open Privacy. | Autorités peuvent viser l’organisation (distribution/feedback) ou administrateur du serveur (ciphertext/traffic), ou utilisateur/terminal. | Politique légale actuelle détaillée par service/hébergeur, rétention d’un opérateur de groupe type. |
| 22 | Demandes policières | Pas de law-enforcement guide, transparency report ni formulaire public repéré pour Cwtch/Open Privacy. | Politique confidentialité : pas de logs IP uniques du site, uniquement journaux agrégés déclarés. | Source primaire; ne prouve pas l’absence d’autres journaux chez tiers/serveurs bénévoles. | Les demandes contre Open Privacy peuvent viser les données volontairement fournies au support/store; serveur de groupe différent. | Demandes, réponses, preservation, emergency disclosure, saisies de serveurs et données effectivement remises. |
| 23 | Affaires judiciaires | Aucun cas primaire reliant une demande judiciaire à Cwtch et à des données produites localisé. | Aucune revendication publique de « zéro cas » retrouvée. | Recherche dans décisions/affidavits/reportages ciblés n’a pas identifié de cas. | Non trouvé n’est pas preuve qu’aucun cas n’a existé. | Dossiers non indexés, ordonnances secrètes ou enquête sans décision publique. |
| 24 | Audits | Aucun audit indépendant formel du protocole/client n’a été localisé. Rapport Open Privacy 2022 dit qu’un audit formel dépasserait 10 % des revenus et n’a pas été commandé. | Handbook, tests, fuzzing et transparence sont présentés comme mesures de sécurité, pas audit tiers. | Déclaration financière du projet documente l’absence d’audit formel à cette date; pas rapport d’audit à analyser. | Le handbook de l’éditeur est une bonne documentation de risque, mais pas une assurance indépendante. | Existence d’un audit privé ou récent après 2022, scope et findings éventuels. Aucun organisme/durée/retest ne peut être renseigné faute de rapport identifié. |
| 25 | Vulnérabilités | Release 1.17.2 du 2 oct. 2026 corrige: attributs publics divulguables à demande non acceptée (1.16–1.17.1); DoS par invitation fabriquée, serveur legacy malveillant, fichier malveillant (versions 1.1–1.17.1, certaines options opt-in); rétrogradation de rôle Hybrid sur 1.17.1. | Éditeur recommande mise à jour; pas de CVE référencée dans le changelog. | Changelog/version et conditions d’exploitation publiques, rapportées par l’éditeur; pas de reproduction indépendante. | Les failles prouvent une exposition versionnée, pas une exploitation constatée. Certains DoS exigent interaction et expérimentations. | CVE, incidents exploités, tickets détaillés/PoC, sévérités externes, retest indépendant. |
| 26 | Recherche académique | Papier Cwtch 2018 présente l’extension de Ricochet pour groupe/asynchronie et le problème de métadonnées. | Objectif académique « metadata resistant ». | Papier de conception accessible; ce n’est pas une analyse indépendante de la release 2026. | Le papier établit motivation/modèle, pas propriétés éprouvées de build actuel. | Analyses formelles/mesures contemporaines sur protocole Hybrid 1.17 et trafic réel. |
| 27 | Incidents historiques | Corrections de sécurité récentes et régressions de stabilité signalées dans changelog; pas d’incident de fuite externe documenté trouvé. | Éditeur indique plusieurs fixes et remercie le chercheur déclarant. | Release notes primaires; aucun rapport d’incident utilisateur indépendant identifié. | Les défauts connus ne prouvent pas qu’ils aient été exploités. | Étendue d’exploitation éventuelle et notification aux utilisateurs touchés. |
| 28 | Gouvernance/financement | Open Privacy est une association canadienne; dons/Patreon et petits effectifs publiquement décrits. | Mission non-profit et soutenue par la communauté. | Site, rapport annuel et demandes de dons primaires. | Ressources financières réduites peuvent affecter audits, support et disponibilité; ne mesure pas qualité technique. | Bilan 2025/2026 vérifié, dépendance financière actuelle, succession et procédures de réponse vulnérabilités. |
| 29 | Résistance à la censure | Tor v3 est le transport obligatoire; aucun service central d’acheminement de messages. | Conçu pour surveillance/résistance à la censure. | Tor et architecture constituent un mécanisme concret; pas de mesure de disponibilité/filtrage pays par pays. | Bloquer Tor, distribuer l’app/domaines ou supprimer l’accès au site de groupes peut interrompre l’usage. | Bridges/obfs intégrés/configuration réellement supportée, tests par pays/FAI et disponibilité Tor. |
| 30 | Maintenance actuelle | v1.17.2 publiée 2 oct. 2026; Tor 0.4.9.13 intégré; core et UI ont des commits récents. | Maintenance et sécurité actives. | Repos, tags et changelog consultés; pour v1.17.2 releases UI sont récentes. | Activité réelle jusqu’en octobre 2026; politique de support de versions et SLA restent faibles/inconnus. | Durée supportée par release, calendrier de sécurité, processus CVE coordonné et capacité de release urgente. |

### Cwtch — audits, vulnérabilités, mobile, droit, matrices

- **Audits** : aucun rapport de sécurité tiers identifié; donc aucun organisme/date/version/scope/findings/retest ne peut être honnêtement attribué. Le compte rendu 2022 du projet dit qu’un audit formel n’a pas été acheté en raison du coût. Ce n’est pas un audit lui-même.
- **Reproductibilité/release** : CI Drone et tests d’intégration décrits. Le projet maintient repliqate; seuls les bindings sont déclarés reproductibles dans la doc courante. En 2023, bindings Linux/Windows ont été dits entièrement reproductibles, Android ensuite; l’UI reste distincte. La release stable 1.17.2 embarque le binding libCwtch v0.3.0. Aucun hash-match n’a été exécuté ici sur APK, DMG, EXE ou UI complète.
- **Play/mobile** : Cwtch Play déclare aucune donnée collectée/partagée, mise à jour 2 sept. 2026; déclaration éditeur et pas audit. Cwtch n’a pas de client iOS officiel; le projet explique cette absence par contraintes plateforme. Permissions, Android manifest, SDK, push payloads, caméra/photos/localisation et trafic n’ont pas été comparés à un APK 1.17.2 inspecté.
- **Forensics** : connaissance observée limitée à SQLite chiffré par PBKDF2 selon documentation, choix de mot de passe, profil par défaut au mot de passe codé en dur, manifests fichier Android dans cache. Aucun résultat Cellebrite/GrayKey/Magnet avec outil+OS+version+build Cwtch exact trouvé. Une extraction d’un appareil déverrouillé ou d’un profil ouvert n’est pas équivalente à une extraction d’un appareil verrouillé.
- **Law enforcement** : aucune divulgation effective dans un cas Cwtch documenté retrouvée. Ce que le fournisseur pourrait posséder : feedback volontaire, données web agrégées selon sa politique; l’opérateur d’un groupe peut posséder blobs de groupe chiffrés et logs système/serveur inconnus. Données qu’il peut techniquement obtenir ≠ données annoncées ≠ données effectivement remises. Aucun document public vu dans la recherche ne démontre une remise réelle.

#### Cwtch — matrice métadonnées

Légende : CONFIRMÉ / PROBABLE / POSSIBLE / NON ACCESSIBLE PAR DESIGN / INCONNU. « Fournisseur » = Open Privacy; un opérateur de groupe est une partie distincte.

| Métadonnée | Fournisseur Open Privacy | Contact | ISP | Apple/Google | Autorités |
|---|---|---|---|---|---|
| IP | POSSIBLE via site/feedback; politique dit pas de log IP unique sur site, app usage inconnu | NON ACCESSIBLE PAR DESIGN en trafic onion nominal | CONFIRMÉ : IP vers relais/guard Tor et volumes | PROBABLE par compte/store/installation; app déclare aucun data collection Play | INCONNU; potentiellement fournisseur/store/FAI par procédure valide |
| Téléphone | NON ACCESSIBLE PAR DESIGN pour compte normal | POSSIBLE si communiqué hors app | NON ACCESSIBLE PAR DESIGN via accès Internet seul | POSSIBLE lié au compte store/OS | INCONNU selon saisie/réquisition tiers |
| E-mail | POSSIBLE si fourni au support; pas requis pour identité | POSSIBLE si échangé | NON ACCESSIBLE PAR DESIGN via TLS/Tor seul | POSSIBLE compte store | INCONNU |
| Identifiant | NON ACCESSIBLE PAR DESIGN : aucun annuaire central de comptes déclaré | CONFIRMÉ : adresse onion/clé de profil partagée | POSSIBLE par corrélation réseau, pas ID onion directement | POSSIBLE via app/store | POSSIBLE via saisie, support ou serveur local |
| Graphe social | NON ACCESSIBLE PAR DESIGN dans le service central inexistant | CONFIRMÉ pour contacts/groupes acceptés | POSSIBLE par corrélation globale | POSSIBLE via notifications OS/backup; exact inconnu | POSSIBLE par saisie, appareil ou serveur ciblé |
| Timestamps | INCONNU pour web/app de soutien; pas de logs uniques revendiqués pour site | CONFIRMÉ côté conversation | CONFIRMÉ côté flux/temps | POSSIBLE via notifications/sauvegarde | POSSIBLE si logs ou terminal saisis |
| Volumes | INCONNU côté fournisseur app; possible sur hébergement web | CONFIRMÉ pour échanges reçus | CONFIRMÉ | POSSIBLE via système/store | POSSIBLE via logs FAI/serveur |
| Groupes | NON ACCESSIBLE PAR DESIGN au fournisseur central; POSSIBLE serveur de groupe pour timing/sessions | CONFIRMÉ | POSSIBLE par motifs trafic Tor | POSSIBLE via backup local | POSSIBLE : serveur peut remettre ciphertext; contenu dépend clés terminal/membres |
| Appareils | INCONNU côté Open Privacy; pas de télémétrie testée | POSSIBLE par disponibilité/session | POSSIBLE par corrélation de flux | PROBABLE par identifiants store/OS | POSSIBLE par extraction terminaux/logs |
| Push tokens | INCONNU; Push externe actuel non établi | NON ACCESSIBLE PAR DESIGN | POSSIBLE destination/service utilisé | INCONNU; confirmer sur build/manifest | INCONNU |

#### Cwtch — TM1 à TM15

| TM | Résistance provisoire | Justification factuelle courte |
|---|---|---|
| TM1 fournisseur curieux | ✅ | Pas de fournisseur central pour le trafic; Open Privacy ne voit par conception pas les conversations. Site/support et distribution restent hors de cette promesse. |
| TM2 fournisseur compromis | ✅ | La compromission de l’organisation ne donne pas à elle seule l’accès aux sessions onion; sites, téléchargement et éventuels services tiers restent attaquables. |
| TM3 fournisseur malveillant | ✅ | Pas de compte/serveur de routage central; binaire ou Tor modifié à la distribution peut toutefois renverser cette propriété. |
| TM4 ISP/Wi-Fi | 🟡 | Tor masque les destinations/protocoles applicatifs mais IP du guard, timing, volume et censure Tor restent observables. |
| TM5 observateur passif multi-points | 🟡 | Pas de mixnet démontré; corrélation à travers chemins Tor/serveurs volontaires demeure possible. |
| TM6 observateur global passif | 🟠 | Aucun mécanisme contre corrélation globale n’a été démontré sur release actuelle. |
| TM7 contact malveillant | 🟡 | Clé/identité authentifiée et permissions existent; contact peut lire ce qui lui est envoyé, fuir contenu, exploiter contact requests ou groupe. Fix 1.17.2 récent. |
| TM8 doxxer OSINT | 🟡 | Pas de numéro/e-mail ni répertoire central; adresse onion persistante et fichiers avec EXIF/PDF peuvent relier identité. |
| TM9 demande légale ordinaire | ✅ | Pas d’historique central de messages/utilisateurs établi; demandes peuvent viser feedback, store, FAI, hôte de groupe ou terminal. Cas de remise inconnu. |
| TM10 police sophistiquée | 🟡 | Serveur de groupe/circuit Tor, endpoint, saisie appareil et corrélation restent surfaces; pas d’étude cas réel Cwtch. |
| TM11 appareil verrouillé saisi | 🟡 | Mot de passe de profil protège si robuste; profils sans mot de passe utilisent secret fixe. Aucun test commercial actuel. |
| TM12 appareil déverrouillé | 🔴 | Profil et messages sont accessibles à l’app/processus; chiffrement de DB ne protège plus un profil chargé. |
| TM13 spyware ciblé | 🔴 | Endpoint peut capter clair, frappes, captures et clés mémoire avant/après réseau. |
| TM14 supply-chain | 🟡 | Code/CI publics et bindings reproductibles; UI entière n’est pas déclarée reproduite et Tor/UI pipeline reste critique. |
| TM15 censure étatique | 🟡 | Pas de centre d’acheminement, mais Tor et distribution peuvent être bloqués; bridges et résultats pays restent inconnus. |

Contradictions et tests Cwtch : « aucune métadonnée » est une ambition, pas une propriété totale; la propre doc admet que les signatures/sync permettent des inférences et ne garantit pas full metadata-resistance. « Le groupe est sûr contre l’hôte » ne s’applique qu’aux groupes legacy non fiables; Hybrid Groups confient contenu et metadata à l’hôte. Expériences à mener : rebuild exact 1.17.2 multi-OS; trafic APN/Play et inventaire SDK/permissions APK; données observables sur serveur legacy vs Hybrid; extraction base/manifests sur appareils verrouillés/déverrouillés; test réseau Tor DNS/IPv6 et corrélation; retest externe des fixes 1.17.2.

## Jami — dossier de preuves (situation au 13 octobre 2026)

Sources primaires : [politique de confidentialité](https://www.jami.net/privacy-policy/), [réseau distribué](https://docs.jami.net/en_US/user/jami-distributed-network.html), [FAQ officielle (IP, push, crypto)](https://docs.jami.net/en_US/user/faq.html), [modèle Swarm](https://docs.jami.net/developer/jami-concepts/swarm.html), [gestion des comptes](https://docs.jami.net/en_US/developer/jami-concepts/account-management.html), [fiche Android](https://play.google.com/store/apps/details?id=cx.ring), [F-Droid / permissions / rebuild](https://f-droid.org/en/packages/cx.ring/), [iOS App Store](https://apps.apple.com/us/app/jami/id1306951055), [repos GitHub miroir Gerrit](https://github.com/savoirfairelinux), [annonce Euclid](https://www.jami.net/euclid/).

| # | Catégorie | FACT — documenté/observé | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN / réserve |
|---:|---|---|---|---|---|---|
| 1 | Architecture | OpenDHT/Kademlia distribué pour établissement de connectivité/routage de messages; connexions P2P ICE/TLS; bootstrap.jami.net par défaut; DHT proxy mobile, TURN facultatif, name server optionnel. | Politique décrit communication « sans serveur ». | Docs réseau actuelles distinguent clairement DHT, proxy, TURN, noms; code sous miroir GitHub/Gerrit. | Architecture distribuée, mais services publics de bootstrap/push/nom/relay sont des points opérés et observables. | Proportion réelle des sessions utilisant chaque service et variation par plateforme, NAT et version. |
| 2 | Protocole crypto | Compte certificat X.509 avec GnuTLS. FAQ actuelle dit messages chiffrés par RSA; calls/files TLS 1.3 PFS et média SRTP. Swarm annonce TLS 1.3 PFS pour canal/transport; historique stocké séparément. | E2EE/PFS pour toutes communications. | Détails primaires sont publics mais la documentation peut être hétérogène; aucune analyse indépendante récente de protocole/app n’identifiée. | Ne pas transposer le PFS du transport TLS à l’historique persisted ou au schéma de groupe. | Taille/encodage RSA, padding, rotation de clés messages, signatures, chiffrement d’historique, appels de groupe précis et statut des docs de Swarm. |
| 3 | Création d’identité | Compte/key/certificat X.509 généré localement; Jami ID partageable; aucune adresse mail/téléphone requise pour compte standard. | Compte privé/local, pas d’autorité centrale. | Docs développeur et source du projet décrivent certificat/clé. | Clé à long terme réutilisée ou exportée peut lier les appareils et conversations. | RNG/algorithme et paramètres par build; comportement comptes SIP/JAMS distinct. |
| 4 | Découverte de contacts | Addresse connue directement ou recherche username via name server; invitations via DHT; bootstrap DHT par défaut. | Identité sans information personnelle obligatoire. | Document réseau + FAQ détaillent le chemin. | La recherche username fait une association publique durable entre alias et ID; identifiants bruts ne sont pas une recherche anonyme garantie. | Indexation, journaux et rétention concrets du nameserver; éventuellement JamiNS on-chain actuel. |
| 5 | Métadonnées serveur | Nœuds OpenDHT stockent/acheminent valeurs chiffrées, observation de source IP et rythme possible; DHT proxy agit pour mobile; TURN relay media quand nécessaire; nameserver publie alias. | Politique promet absence de logs/personnal data sur proxy/TURN et affirme aucun flux ne transite par serveur. | FAQ officielle confirme nœuds DHT voient IP, proxy voit IP utilisateur, TURN relaye, FCM/APNs pour push; contradiction factuelle de périmètre avec phrase marketing. | Nœud DHT peut connaître adresse source et valeurs/IDs de routage sans nécessairement déchiffrer corps. | Journalisation et durée réelle côté Jami, opérateurs DHT tiers et TURN; champs effectivement conservés. |
| 6 | IP utilisateur | Le client OpenDHT utilise IP réelle en mode direct; en mode DHT proxy le proxy reçoit l’IP; ISP voit échanges DHT/peer et service push/TURN. | Proxy/TURN ne conserveraient aucun log. | Documentation FAQ officielle affirme quelle IP est vue dans les deux modes. | Mode direct expose la présence utilisateur au réseau DHT plus largement qu’un serveur central ciblé. | Observations passives DNS/ASN/traffic et politique rétention vérifiée par mesure, non par déclaration. |
| 7 | IP exposée au correspondant | ICE candidates incluent adresses réseau/public/VPN/TURN dans call/file; documentation dit que l’adresse est dans ICE message. DHT-message initial n’expose pas nécessairement l’adresse au contact, mais révèle aux nœuds DHT. | Une politique VPN/Tor peut réduire l’IP réelle, selon configuration. | FAQ officielle décrit IP locales et candidates; elle avertit que VPN/Tor requis si l’on veut éviter fuite directe. | Contact peut apprendre IP public ou VPN pendant appels/transfert direct; TURN substitue l’IP du relay pour media, mais TURN voit extrémités. | Comportement de chaque version mobile, IPv6, mDNS, WebRTC/ICE; valeurs exactes à vérifier par pcap. |
| 8 | Messages | Messages de texte peuvent passer par canal SIP/peer actif ou DHT si hors canal selon FAQ; Swarm synchronise un dépôt Git pair-à-pair et notifie/récupère via DHT. | Chiffrés de bout en bout, sans stockage central durable. | Docs réseau/FAQ et concepts Swarm disent parfois différents mécanismes (doc FAQ général vs Swarm); cela reflète générations/features. | Il ne faut pas appliquer un unique flux à toutes versions/types de conversation. | Durée des valeurs DHT, remise si hors ligne, historique et mécanisme exact sur clients actuels. |
| 9 | Groupes | « Swarm » est un repo Git répliqué entre appareils et membres; membership, clés/certificats, commits, CRLs, métadonnées de groupe. Calls de groupes démarrent une session avec URI annoncée. | Pas de central authority; historique synchronisé et signatures vérifiées. | Modèle technique officiel documente commit/Merkle-ish, membre/device/call metadata; page est documentation interne de conception. | Un membre autorisé reçoit historiquement messages, signatures, metadata et peut les exporter; révocation ne reprend pas les copies. | Cryptoscheme de groupe exact dans build 2026, PFS de l’historique, tailles pratiques et comportements clients. |
| 10 | Appels | SIP/RTP, TLS/SRTP; P2P si ICE réussi, TURN relay si non; conférence Swarm via rendez-vous URI et hôte. | E2EE appels/PFS. | FAQ officielle décrit cipher families et IP ICE; docs Swarm indiquent PFS canal TLS et messages commits pour call start/end. | TURN transporte flux chiffré en transport mais centralise métadonnées réseau; participants voient relation d’appel. | Doublement E2EE media, ciphers négociés sur chaque OS, signaling/call metadata exposés et mix/sfu exact. |
| 11 | Fichiers | Fichiers Swarm annoncés par commit avec displayName, taille, SHA3sum; disponibilité P2P par appareils hôtes; doc indique algorithme courant par TURN dans une partie de la doc. | Transfert chiffré, P2P; aucun stockage public de contenu. | Protocole et chemin local décrits dans docs developer; FAQ IP dit IP incluses dans ICE. | Hash/nom/taille sont des metadata synchronisées; device qui a téléchargé peut héberger plus tard. | Relation actuelle entre vieux transfert direct et Swarm, chiffrement du payload au travers TURN exact, métadonnées EXIF et purge. |
| 12 | Multi-device | Liens d’appareils par export d’archive; archive peut être chiffrée si mot de passe; archive passe quelques minutes sur DHT pour link feature selon FAQ, ou transfert P2P selon nouvelle doc. | Synchronisation multi-appareil et compte contrôlé localement. | Docs compte/link décrivent processus, champs peer address, états. | DHT association token↔archive peut permettre corrélation temporaire pendant le lien; mot de passe peut être vide. | Rétention et chiffrement exact de chaque implémentation, appareils révoqués/cache. |
| 13 | Push | Android/iOS peuvent utiliser Firebase, APNs ou UnifiedPush; mobile peut utiliser DHT proxy pour réveil/push. | Un identifiant seul transmis et inutilisable sans accès au compte. | FAQ et docs LAN déclarent fournisseurs et rôle de DHT proxy; cette affirmation sur l’identifiant reste éditeur. | Push ajoute Apple/Google et opérateur proxy comme métadonnées, même si contenu chiffré/absent. | Payload exact, token, ID, timestamps, IP, association compte et push SDK versions. |
| 14 | Stockage local | Archive de compte est gzip avec clés/certificats et contacts; si mot de passe fourni, AES via OpenDHT/nettle GCM; versions récentes ne demandent pas mot de passe par défaut. Les conversations sont SQLite selon anciennes observations du forum; chiffrement courant non établi. | Données de compte locales et chiffrables avec password; protection OS recommandable. | Docs officielles confirment archive AES optionnelle; forum utilisateur 2021 rapporte history.db non chiffrée, sans vérification de build 2026. | Archive sécurisée ≠ base historique chiffrée; device unlocked/OS compromise expose local plaintext. | Test build 2026 sur Android/iOS/macOS/Windows/Linux, encryption sqlite et files/cache; protection hardware key. |
| 15 | Sauvegardes | Archive exportable, éventuellement AES sous mot de passe; link archive sur DHT pendant appairage; copie database nécessaire pour historique selon guide desktop. | Récupération sous contrôle utilisateur. | Docs officielles d’account management. | Les backups non chiffrés ou faible password peuvent être un artefact forensic simple; DHT temporaire accroît visibilité. | Durée DHT/archive, génération password automatique de link, cloud OS, test de révocation/effacement. |
| 16 | Analytics/SDK | Site jami.net contient Matomo SFL, pas preuve de SDK app. Fiche Play auto-déclare collecte Personal info, rien partagé; App Store déclare User ID non lié et signale localisation possible même app fermée. | Politique « no personal data » pour app. | Fiches Google/Apple et code public sont sources observables/déclaratives; divergence fiche-vs-politique à résoudre par tests. | Les store labels ne sont pas une capture d’exécution; fonctionnalités SIP/location, media et push changent les permissions. | SDK tiers, Firebase analytics/crash, réseau au repos/usage, permissions exactes du build Play/iOS; photos/contact/location intention et usage. |
| 17 | Code source | Lic. GPLv3+; projet core, clients et OpenDHT sont publics; GitHub est miroir Gerrit. Organisation: 17,737 commits core; activité jusqu’au 12 oct. 2026, quelques dizaines d’auteurs observés dans métriques GitHub annuelles par repo. | Libre et auditable. | Repos publics + docs review-driven sur Gerrit. | Un miroir GitHub n’est pas nécessairement source canonique; revue sur Gerrit est un contrôle, pas audit sécurité. | Inventaire détaillé mainteneurs/ownership branches, composants propriétaires/fermés, divergence store vs Gerrit. |
| 18 | Reproductibilité | F-Droid reconstruit Jami Android : build 20260619-01 (code 498) reproduit; plusieurs builds 2025–26 échouent dans historique visible. F-Droid signe son propre APK et le lie à source tarball. | Code libre, build transparent. | F-Droid Verification Server est contrôleur indépendant de l’APK F-Droid, non preuve pour Play/App Store ou desktop. | On ne peut pas généraliser la reproductibilité F-Droid aux binaires éditeur ou toutes versions. | Repro exacte de dernière APK 20260807-01, Google Play, iOS, desktop; signatures officiels et provenance des SDK. |
| 19 | Supply chain | Dépendances visibles : Qt, C/C++, OpenDHT/DHTNet/GnuTLS/PJSIP, ffmpeg/media et frameworks mobiles; CI GitHub mirror/Gerrit, build store distinct. | Développement public, revues/pipelines. | Repo public et changements de version Euclid 2026. | Surface large en code natif, media, crypto et build; multi repo et store credentials. | SBOM et pinning par release; CVE en composants réellement atteignables; attestations/signed tags; audits CI. |
| 20 | Infrastructure | Docs publient `bootstrap.jami.net`, `dhtproxy.jami.net`, `turn.jami.net`, `ns.jami.net`; DHT/OpenDHT peut être auto-hébergé. [Documentation](https://docs.jami.net/user/lan-only.html) | Aucune autorité/serveur central au sens architecture. | Snapshot A/AAAA/BGP du 14 oct. 2026 : les IP IPv4 observées pour `bootstrap`, `dhtproxy`, `turn` et `ns` relèvent surtout d’AS16276 (OVH SAS); `192.99.0.8` n’a pas de préfixe RIPEstat vérifié dans cette passe. [RIPEstat AS16276](https://stat.ripe.net/AS16276) | Cela attribue des routes à l’ASN au moment de l’observation; ne prouve ni le titulaire des services, ni région, logs, ni opérateur de chaque composant. DHT évite une dépendance unique pour les pairs déjà en réseau, pas nécessairement pour bootstrap/naming/push. | DNS/IP/ASN historiques, propriétaires réels, CDN/cloud/régions, nombre/rotation des TURN nodes, opérateurs, rétention et trafic effectivement utilisé. |
| 21 | Juridiction | Produit dirigé par Savoir-faire Linux Inc., entreprise basée à Montréal, Québec, Canada; services infra/operators may be elsewhere; stores/cloud US or region dependent. | Projet GNU/FOSS/Quebec-based. | Docs officielles et page org. | Une demande à l’éditeur peut viser données service web/push infrastructure, mais l’éditeur déclare pas de compte central de messagerie. | Filiales/hosting contracts, legal processors and cross-border disclosure procedure. |
| 22 | Demandes policières | Pas de transparency report, guide law enforcement ou cas de remise Jami trouvé. | Politique dit « ne collectons pas » identifiant/téléphone/email, et proxy/TURN sans logs. | Pas de source primaire décrivant demandes spécifiques ou data productions. | Nœud DHT, TURN, Google/Apple, opérateur de nom, appareil/FAI chacun possèdent des données différentes. | Données effectivement remises dans un cas (aucun exemple vérifié); legal process policy, preservation, emergency and foreign requests. |
| 23 | Affaires judiciaires | Aucun jugement, subpoena, affidavit ou criminal case documentant disclosure Jami retrouvé dans recherche ciblée. | Aucune déclaration publique « zéro demandes » recensée. | Recherche web/documents publics, négative mais limitée. | Absence de cas indexé n’établit pas absence de demande secrète ou saisie terminal. | Cas non publiés, dossiers de saisie, registres canadiens non indexés. |
| 24 | Audits | Aucun audit indépendant du protocole Jami/release courante identifié. Forum 2022–23 demande audit public; ce fil ne constitue pas preuve de toute absence, ni audit. | Source publique/review-driven est présentée en garantie. | Repos/doc consultés; aucune publication d’audit analysable. | Code public permet inspecter mais ne garantit pas que le code courant/protocole complexe a reçu review compétente. | Si audit privé existe, dates, commits, scope, findings, sévérités, corrections/retest. Aucun détail disponible faute de rapport. |
| 25 | Vulnérabilités | Ubuntu USN-6422-1 (2023) corrige plusieurs vulnérabilités du paquet Ring/Jami-daemon downstream; ne permet pas d’extrapoler à build actuel. Aucun advisories sécurité courant du projet trouvé. | Updates par releases; projet encourage issues/reporting. | Avis Ubuntu primaire; paquet affecté est distribution/versionnée. | La maintenance de dépendances et paquets tiers est importante; CVE n’implique pas version mobile 2026 atteignable. | Liste CVE upstream et mapping à chaque build app, exploitation observée, KEV/EPSS et retests. |
| 26 | Recherche académique | Pas d’analyse formelle publique récente Jami E2EE identifiée lors de recherche ciblée; référence OpenDHT et protocoles publics subsistent. | Le projet se revendique E2EE/PFS. | Publication historique d’OpenDHT et standards TLS/SRTP contextualisent certains composants; pas d’audit intégral. | Absence de publication identifiée n’est pas faiblesse prouvée, mais limite la preuve indépendante. | Formalisation moderne du protocole Swarm, crypto message RSA, DHT traffic-analysis et groupe. |
| 27 | Incidents historiques | Bugs de performance/connexion signalés dans changelog et store; notes Euclid 2026 fixent drop connexions et transferts. Pas de brèche serveur confirmée trouvée. | Mises à jour et release Euclid présentées comme fiabilité accrue. | Changelog et notes de release primaires; avis stores ne prouvent pas cause généralisable. | Expérience réseau instable peut pousser des usagers à des services alternatifs et changer exposition. | Incidents sécurité/confidentialité internes, duration and users affected. |
| 28 | Gouvernance/société/financement | Savoir-faire Linux Inc (Québec) dirige; communauté mondiale, financement par dons et offres JAMS/enterprise. | Projet GNU libre, sans publicité, reçoit dons. | Docs projet et page contribution/donation. | Soutien société peut concentrer la gouvernance technique, même si protocole décentralisé. | Part des revenus/financement Jami vs entreprise, bus factor, gouvernance release, JAMS ownership/source. |
| 29 | Résistance à la censure | DHT public configurable, nœuds nombreux, LAN possible sans Internet; bootstrap, ports UDP, DNS nameserver, TURN and push endpoints can be filtered. | Docs affirment meilleure résilience et absence de point unique. | Les docs décrivent concrètement ports/dépendances et alternatives auto-hébergées. | Filtrer l’UDP/bootstraps/domaine/app store peut gêner initialisation; pas de fallback Tor natif général garanti (FAQ dit appels via Tor ne marchent pas). | Mesures pays/FAI, alternatives bridges, disponibilité publique DHT, domaine IP-blocks. |
| 30 | Maintenance actuelle | Release Euclid 1 avril 2026; GitHub mirrors core/Android/Qt updates 12 oct. 2026; F-Droid version 20260807-01 publiée 11 août; iOS App Store version visible récente. | Projet maintenu et multi-plateforme. | Pages release/repo/store, activité récente mesurée. | Maintenance active; cadence de version peut diverger fortement par OS/canal et audit not présent. | Version/build précis du Play/iOS/desktop au 13 oct, maintenance JAMS, politiques de support. |

### Jami — observation DNS/BGP d’endpoints documentés

Snapshot de résolutions A/AAAA le 14 octobre 2026 vers 00:29–00:32 heure de Paris (13 oct. UTC); préfixes IPv4 recherchés ensuite via RIPEstat. Le résolveur local n’est pas identifié. Aucun port n’a été contacté. La documentation indique que `bootstrap.jami.net` sert au démarrage, `dhtproxy.jami.net` peut fournir un proxy DHT et `turn.jami.net` un relais TURN; ces rôles ne sont pas déduits des seuls noms DNS. [Documentation Jami](https://docs.jami.net/user/lan-only.html)

| Nom | A observées | AAAA observées | RIPEstat IPv4 | Lecture bornée |
|---|---|---|---|---|
| `bootstrap.jami.net` | `158.69.23.138`, `144.217.10.53` | `2607:5300:60:7c8a::1`, `2607:5300:204:4035::1` | `158.69.0.0/16`, `144.217.0.0/16`, AS16276 (OVH SAS) | Deux adresses publiées dans les réponses; pas la liste de bootstrap complète ou stable. |
| `dhtproxy.jami.net` | `141.94.96.2` | `2001:41d0:403:4702::` | `141.94.0.0/16`, AS16276 | Une seule réponse A dans ce snapshot; aucun test n’a vérifié une session proxy. |
| `turn.jami.net` | `198.27.70.179`, `192.99.0.8` | `2607:5300:60:1fb3::1`, `2607:5300:60:3108::1` | `198.27.64.0/18`, AS16276; pas de préfixe RIPEstat vérifié pour `192.99.0.8` | DNS renvoie deux IP; le terme TURN publié n’établit pas quel serveur est choisi par un appel donné. |
| `ns.jami.net` | `158.69.197.55` | `2607:5300:205:200::2841` | `158.69.0.0/16`, AS16276 | Observation limitée au DNS; ne prouve pas les services DNS effectivement interrogés par chaque client. |

Les IPv6 sont notées mais leurs préfixes/ASN ne sont pas rapportés, faute de résultat vérifiable conservé pour ces requêtes. Le TTL était généralement de 300 s, sauf `turn.jami.net` à 60 s. Une route OVH ne permet pas d’inférer la région physique, le détenteur contractuel ni la rétention. Les sites, téléchargements, services tiers push et domaines `dhtproxy.2/.3`, `dl.jami.net` restent hors de ce snapshot.

### Jami — audits, vulnérabilités, mobile, droit, matrices

- **Audit** : recherche de rapport indépendant de protocole/crypto/source n’a rien localisé. Les sujets du forum appelant à audit en 2022 et 2025 ne fournissent ni scope ni rapport. Aucun organisme/date/version/commit/durée/findings/retest n’est attribuable à ce stade.
- **Repos & versions** : pages GitHub déclarent que repositories sont miroirs de Gerrit. Core, Android, iOS et Qt restent actifs en octobre 2026. F-Droid (version 20260619-01) reproduit une version de l’APK; plus récentes versions ont des réussites et échecs de rebuild listés. La version F-Droid 20260807-01 a été construite/signée par F-Droid à partir d’un source tarball; ce résultat ne valide pas les builds Play, Apple ou desktop.
- **Mobile** : la fiche Play 2026 déclare Personal info potentiellement collectée et rien partagé; fiche App Store déclare User ID non lié et signale possible localisation en arrière-plan, déclarations développeur non vérifiées par Apple. F-Droid APK 20260807-01 déclare permissions localisation approximative/précise au premier plan, Wi-Fi/réseau, Bluetooth, caméra, microphone, foreground services camera/dataSync/location/mediaProjection/phoneCall/remoteMessaging, full network access et call routing. Cela peut servir à appels, partage localisation/camera/media et présence; la liste de permissions n’établit pas qu’elles sont utilisées en arrière-plan. Aucun manifeste/dynamic traffic du binaire store inspecté.
- **Contradiction de périmètre** : politique dit « aucun flux via un serveur »/« all communications P2P »; FAQ officielle expose DHT nodes, DHT proxy, Firebase/APNs/UnifiedPush, name server, TURN; ces composants peuvent voir metadata ou relayer traffic. Cela n’implique pas automatiquement qu’ils voient le texte ou media en clair : la couche E2EE/transport et la métadonnée doivent être évaluées séparément.
- **Forensics** : source accessible montre fichiers archive account; documentation historique d’utilisateur testait history.db plaintext en 2021, mais aucun test reproductible 2026 sur version d’appareil actuelle n’a été retrouvé. Aucun résultat Cellebrite/GrayKey/Magnet associant outil + OS/build + Jami build + date n’a été identifié. L’acquisition doit distinguer archive chiffrée avec mot de passe, database des messages, export DHT temporaire, caches et mémoire sur appareil unlocked.
- **Law enforcement** : aucun guide law-enforcement, transparency report ou cas Jami présentant des champs réellement remis trouvé. En théorie/selon docs, Jami (entreprise) peut connaître données site/support; DHT proxy/TURN possèdent IP et sessions selon rôle; FCM/APNs voient leur partie push; opérateur nameserver voit alias↔Jami ID public; FAI voit connexions; appareil contient comptes/historique. Effectivement remis dans un cas : **aucune preuve publique spécifique retrouvée**, pas preuve qu’aucune remise n’ait eu lieu.

#### Jami — matrice métadonnées

| Métadonnée | Fournisseur Jami/SFL | Contact | ISP | Apple/Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ pour services auxquels on se connecte; PROBABLE par bootstrap/proxy/TURN; journaux allégués absents | CONFIRMÉ pour ICE calls/files en direct; DHT messaging ne donne pas nécessairement IP au contact | CONFIRMÉ par connexion DHT/peer/VPN | POSSIBLE via store/app push/device signals | POSSIBLE par FAI/service/terminal; divulgation réelle inconnue |
| Téléphone | NON ACCESSIBLE PAR DESIGN compte Jami standard; SIP/Tel features peuvent différer | POSSIBLE si donné dans chat/SIP | NON ACCESSIBLE PAR DESIGN juste via IP sauf corrélation tiers | POSSIBLE compte Play/Apple | POSSIBLE auprès opérateur/store/saisie; Jami disclosure inconnue |
| E-mail | NON REQUIS compte; POSSIBLE si newsletter/support/achat | POSSIBLE si fourni | NON ACCESSIBLE PAR DESIGN à travers réseau Jami seul | POSSIBLE au store | POSSIBLE via stores/support si conservé |
| Identifiant | CONFIRMÉ pour username mapping du nameserver public; IP/session via endpoints selon rôle | CONFIRMÉ Jami ID/certificat et nom affiché | POSSIBLE par corrélation DHT | POSSIBLE ID utilisateur d’app déclarée App Store / compte store | POSSIBLE auprès nameserver/terminal/store |
| Graphe social | POSSIBLE par valeurs DHT et opérations push; logs officiels inconnus | CONFIRMÉ groupes/contacts visibles et invitations | POSSIBLE par timing/flux | POSSIBLE via push tokens/contacts OS? non vérifié | POSSIBLE par appareils/DHT/relay, disclosure cas inconnu |
| Timestamps | POSSIBLE/PROBABLE services DHT/TURN/push, logs non établis | CONFIRMÉ commits/signatures/présence/messages | CONFIRMÉ via flux | PROBABLE timestamp push/app/store | POSSIBLE si logs détenus, aucun cas documenté |
| Volumes | POSSIBLE via relay/transit, données détails inconnus | CONFIRMÉ fichiers/appels/messages répliqués | CONFIRMÉ octets/durée | POSSIBLE via métadonnées push | POSSIBLE via ISP/relay; remise inconnue |
| Groupes | POSSIBLE via DHT IDs/transactions, contenu group repo n’est pas centralisé | CONFIRMÉ membership, metadata, history et call URI | POSSIBLE corrélation | POSSIBLE notifications/conversation IDs | POSSIBLE via endpoint/membre/relay ciblé; pas de remise réelle connue |
| Appareils | POSSIBLE IDs d’appareils dans Swarm/certificates; IP/proxy activity | CONFIRMÉ dispositifs d’un contact/groupes et certificats associés selon contexte | POSSIBLE nombre de flux | CONFIRMÉ/PROBABLE via comptes push/store/device | POSSIBLE par dossier service ou acquisition terminal |
| Push tokens | POSSIBLE/PROBABLE proxy/Push backend; l’éditeur dit identifiant unique transféré | NON ACCESSIBLE PAR DESIGN pour token du contact | NON ACCESSIBLE PAR DESIGN sauf réseau vers endpoint | CONFIRMÉ par APNs/FCM/UnifiedPush participant selon configuration | POSSIBLE via Apple/Google/proxy; cas divulgation inconnu |

#### Jami — TM1 à TM15

| TM | Résistance provisoire | Justification factuelle courte |
|---|---|---|
| TM1 fournisseur curieux | 🟡 | Pas de base centrale de messages; mais présence DHT proxy/TURN/push/name service et IP/logs annoncés sans preuve indépendante. |
| TM2 fournisseur compromis | 🟡 | Un serveur central ne détient pas seul l’historique, mais bootstrap/name server/push/TURN compromis peut dégrader disponibilité/routage ou fournir metadata. |
| TM3 fournisseur malveillant | 🟡 | Les clés de compte et vérification réduisent MITM simple; code/distribution et DHT/username mapping peuvent encore être manipulés selon scénario. Pas d’audit protocole. |
| TM4 ISP/Wi-Fi | 🟠 | TLS masque corps, mais DHT IP/volumes et ICE peuvent exposer IP du client/contact; VPN réduit mais ne supprime pas métadonnées. |
| TM5 observateur passif multi-points | 🟠 | Candidats ICE, DHT, push et TURN créent flux corrélables; aucun mixnet de protection observé. |
| TM6 observateur global passif | 🔴 | Aucune résistance documentée contre analyse globale de trafic et endpoints individuels. |
| TM7 contact malveillant | 🟠 | Contact reçoit IP via ICE en appel/fichier direct, contenu/message, metadata groupe; peut copier/relayer tout ce qu’il voit. |
| TM8 doxxer OSINT | 🟡 | Pas de téléphone requis; identité peut se lier au username blockchain public, aux échanges ou IP directe. |
| TM9 demande légale ordinaire | 🟡 | SFL a peu de données message serveur par design, mais DHT/proxy/TURN/push/name stores et website peuvent être demandés; aucun cas de remise Jami documenté. |
| TM10 police sophistiquée | 🟠 | Collecte ISP/endpoint/correspondant/nameserver/push peut assembler identité, IP, timestamps et contents saisis; pas de preuve de cas Jami. |
| TM11 appareil verrouillé saisi | 🟡 | Archive compte optionnellement chiffrée mais mot de passe non obligatoire; historique DB semble historiquement séparé, aucun test forensic actuel. |
| TM12 appareil déverrouillé | 🔴 | Clés/historiques localement disponibles au processus et à l’utilisateur; backup archive/API; crypto transport n’aide pas. |
| TM13 spyware ciblé | 🔴 | Peut lire contenu/clefs et micro/caméra, et permissions F-Droid confirment capacité média selon consentement/usage. |
| TM14 supply-chain | 🟡 | Source ouverte, Gerrit review, F-Droid rebuild partiel; nombreuses dépendances C++/media, clients/store diffèrent et audit absent. |
| TM15 censure étatique | 🟡 | DHT et LAN/auto-hostage apportent résilience, mais bootstrap/ports UDP/domains, TURN, push, DNS/store peuvent être filtrés; pays non mesurés. |

Contradictions et tests Jami : « zéro serveur » est vrai seulement au sens absence de serveur central unique d’historique/acheminement; c’est faux au sens absence de relais ou services réseau. « E2EE/PFS pour tout » ne doit pas confondre TLS/SRTP pour call/file, RSA pour message (selon FAQ) et encryption at rest. « No data collected » dans la politique app est en tension avec labels Play/Apple. La doc Swarm décrit de la sécurité en évolution et une réserve sur crypto historique; ne pas traiter un statement marketing comme validation de groupe. Expériences nécessaires : Pcap DHT/direct/proxy/TURN et ICE, IPv4/6/VPN/Tor, extractions push payload (Android Play/F-Droid/iOS), store binary manifest et SDK/permissions, rebuild de la toute dernière version et compare signatures, examiner DB/archive local sur chaque OS, vérifier DNS/ASN des domaines, analyser commits/certs/rotation de clés Swarm, rechercher décisions/cas judiciaires propres à SFL/alias Ring/Jami.

## Tox / qTox — dossier de preuves (situation au 13 octobre 2026)

**Périmètre à ne pas mélanger.** Tox est un protocole/réseau P2P; toxcore est une bibliothèque cliente/protocolaire; qTox est un client desktop; les nœuds bootstrap sont des opérateurs distincts. Les propriétés réseau ci-dessous sont celles de toxcore/Tox; interface, sauvegarde et historique sont qTox. Les clients Android aTox/TRIfA sont des produits différents et ne sont pas assimilés à qTox.

Sources primaires principales : [README et avertissement de sécurité c-toxcore](https://github.com/TokTok/c-toxcore/blob/master/README.md), [FAQ officielle Tox](https://tox.chat/faq.html), [liste officielle des clients et téléchargements](https://tox.chat/download.html), [protocole de référence (spécification communautaire, ancienne et incomplète)](https://zetok.github.io/tox-spec/), [manuel qTox](https://github.com/qTox/qTox/blob/master/doc/user_manual_en.md), [releases qTox du fork actif TokTok](https://github.com/TokTok/qTox/releases), [changelog toxcore](https://github.com/TokTok/c-toxcore/blob/master/CHANGELOG.md), [advisory GHSA-42vg-9mg3-399f](https://github.com/TokTok/c-toxcore/security/advisories/GHSA-42vg-9mg3-399f), [issue KCI #426](https://github.com/TokTok/c-toxcore/issues/426), [code de chiffrement du profil toxencryptsave](https://github.com/TokTok/c-toxcore/blob/master/toxencryptsave/toxencryptsave.c), [étude forensique qTox (Meier, Choo, Le-Khac, 2022)](https://doi.org/10.1007/978-3-031-16127-8_4).

| # | Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---:|---|---|---|---|---|---|
| 1 | Architecture | Tox est P2P, avec DHT de découverte/routage, connexions UDP directes et relais TCP disponibles; des nœuds bootstrap publics servent d’entrée dans la DHT. | « serverless », distribué, sans autorité centrale. | La FAQ précise qu’un bootstrap public peut être utilisé et que les amis sont joints directement; la spécification note que le pair reçoit l’IP du contact. | « Sans serveur central » n’élimine ni bootstrap, ni observation par pairs, ni analyse de trafic; le coût est reporté vers les terminaux et opérateurs volontaires. | Quelle proportion réelle des installations utilise quel bootstrap, et quel routage selon client/NAT/proxy/version. |
| 2 | Protocole cryptographique | Toxcore s’appuie sur libsodium/NaCl; FAQ: Curve25519, XSalsa20, Poly1305. Le chiffrement du profil toxencryptsave utilise une dérivation scrypt-Salsa20/256 et un chiffrement authentifié NaCl/crypto_box selon le code. | La FAQ affirme E2EE avec forward secrecy pour les messages. | Le README c-toxcore reconnaît que le modèle de sécurité n’est pas complètement spécifié et que la bibliothèque n’a pas d’audit crypto externe formel. La référence du protocole laisse la description PFS comme TODO; issue KCI demeure ouverte. | Les primitives sont connues, mais cela ne suffit pas à prouver l’authentification, le ratchet, PFS, PCS ou déniabilité de chaque flux/version. | Propriétés formelles exactes du handshake et de PFS sur les clients actuels; protections PCS, déniabilité, transparence de clés et changements silencieux d’identité. |
| 3 | Création d’identité | La clé publique est l’adresse; Tox ID encode la clé publique, un champ anti-spam NoSpam et un checksum. Profil/clé sont générés et conservés localement par le client. | L’identité reste contrôlée par la clé privée locale et ne requiert pas de numéro/e-mail. | Manuel qTox et code toxcore décrivent le profil local; l’étude forensique 2022 retrouve compte et contacts à partir d’artefacts/mémoire. | L’ID public est pseudonyme mais stable et corrélable lorsqu’il est réutilisé ou publié. | RNG sur chaque plateforme/build, rotation de clé en usage réel, mécanisme cross-signing et migration d’identité. |
| 4 | Contact discovery | L’ajout se fait en échangeant manuellement le Tox ID; les lookups DHT utilisent des clés temporaires et des tunnels onion selon la FAQ. | La recherche d’un ami ne révélerait pas directement la paire de contacts aux nœuds DHT. | La FAQ documente ce mécanisme mais n’est ni audit ni mesure réseau; la spécification elle-même appelle à davantage de détails sur les données révélées. | Cela réduit le lien direct « ID durable ↔ requête DHT » mais ne protège pas l’IP contre un ami accepté. | Données et rétention de chaque nœud; résilience à Sybil/éclipse et efficacité de l’onion routing sur les builds actuels. |
| 5 | Métadonnées serveur | Il n’existe pas d’opérateur de stockage des messages; nœuds DHT/bootstrap voient une IP source pour leurs connexions et les données nécessaires au routage. | Pas de serveur central qui puisse établir le graphe social. | La documentation Tox reconnaît les bootstrap publics; la référence décrit clé temporaire/onion comme mitigation du lien social, pas une suppression de toute observation. | Plusieurs nœuds contrôlés ou l’observation du réseau peuvent relier événements et utilisateurs par temps/volumes, sans déchiffrer le corps. | Journaux effectivement conservés par nœuds bénévoles, champs observables par rôle et visibilité DHT actuelle. |
| 6 | IP utilisateur | Un nœud auquel le client se connecte reçoit l’adresse réseau source, sous réserve d’un proxy/Tor correctement configuré. | Tox peut fonctionner via proxy; la FAQ recommande Tor comme contournement à l’exposition directe. | La FAQ et la spécification avertissent que le protocole n’essaie pas de cacher l’IP lors des communications avec les amis. | Un SOCKS/TCP-only peut réduire l’exposition, mais ne transforme pas Tox en mixnet et peut créer d’autres fuites si mal configuré. | Comportement DNS, IPv6, WebRTC/ICE local, fallbacks et proxys par client/build; non mesuré dans ce rapport. |
| 7 | IP exposée au correspondant | La FAQ dit explicitement que l’IP est révélée à un contact lorsqu’on l’ajoute; les communications P2P directes rendent le chemin IP observable par les pairs. | Une connexion via proxy/Tor peut modifier ce que le pair voit. | La référence protocolaire précise que l’IP des amis est exposée et qu’ils peuvent la relier directement à l’ID. | Appels et transferts directs ont le même risque d’adresse réseau que la présence en ligne; un pair peut conserver/corréler cette IP. | Différence exacte par fallback relais TCP, groupe, système et paramètres de chaque client. |
| 8 | Messages | Messages chiffrés entre pairs; pas de store-and-forward central. qTox offre des « faux messages hors ligne » en conservant/réessayant localement les messages jusqu’au retour du correspondant. | Communication E2EE par défaut; pas de serveur d’historique. | Manuel qTox confirme que cette fonction est locale et liée à l’historique; l’advisory de sécurité démontre que le réseau traite aussi des paquets adversariaux non authentifiés dans certains sous-systèmes. | Message non livré lorsque l’émetteur et destinataire ne peuvent se croiser; sauvegarde locale d’un message sortant n’est pas une boîte serveur. | Fenêtre exacte de conservation/retry et sémantique de livraison pour versions récentes; PFS des messages effectivement observée. |
| 9 | Groupes | qTox annonce groupes/conférences; toxcore contient groupes et annonces DHT (GCA/NGC), avec évolutions et corrections fréquentes. | Group chat intégré au réseau Tox sans serveur central unique. | Le changelog 0.2.23 corrige notamment un débordement dans les annonces GCA; aucun audit crypto de groupe n’a été identifié. | Membres, clés, synchronisation et signaux de présence forment une surface distincte du chat 1:1; l’E2EE par membre ne prouve pas l’absence de métadonnées groupe. | Modèle exact des clés de groupe, accès des nœuds DHT, visibilité de membership/présence, rekey et confidentialité passée. |
| 10 | Appels | toxav prend en charge voix/vidéo; codecs publiés: Opus et VP8; transport géré par toxcore, généralement P2P. | Appels chiffrés via la même infrastructure cryptographique Tox. | Le changelog 2026 inclut des corrections de dépassement de tampon RTP/vidéo et de logique audio; aucun audit externe d’appel n’a été trouvé. | Le pair peut connaître l’IP et les horaires; codecs et protections de transport ne constituent pas à eux seuls une preuve d’E2EE de groupe ou de PFS média. | Clés et chiffrement exacts pour appels/conference, relay effectif, IP candidates, appels de groupe, risques de fuite audio et versions affectées. |
| 11 | Fichiers | qTox prend en charge les transferts de fichiers; dans Tox le transfert se fait entre clients, pas par un serveur d’archivage. | Transfert privé via Tox. | Manuel qTox confirme transfert et auto-acceptation configurable; l’étude qTox 2022 documente des artefacts de communication/fichiers, pas les propriétés crypto modernes. | Nom, taille, activité et temps sont visibles au pair; les fichiers remis peuvent contenir EXIF et contenu actif. | Chiffrement exact, résumés, reprise partielle, fragments sur disque et protection anti-malware par version. |
| 12 | Multi-device | qTox n’offre pas de synchronisation cloud/multi-appareils comparable à un compte serveur; il sait exporter/importer le profil. | Profil exportable entre clients compatibles. | Manuel décrit export et sauvegarde du fichier .tox; aucun service de synchronisation central n’est documenté. | Copier un même profil réplique la clé/identité, sans protocole fiable de gestion multi-device; concurrence peut causer désynchronisation ou exposition de la clé. | Compatibilité cross-client à chaque version et comportement quand plusieurs copies du même profil sont simultanément actives. |
| 13 | Push | qTox est desktop; pas de APNs/FCM requis par le client qTox standard. Les clients mobiles Tox sont séparés. | Pas de fournisseur push pour qTox desktop. | Les pages officielles listent aTox Android séparément; aucune fiche de confidentialité mobile unique ne peut être attribuée au protocole Tox. | Les apps mobiles pourraient dépendre de FCM ou d’une présence permanente, mais cela dépend entièrement du client. | Push, tokens, payloads, permissions et labels Play/App Store pour chaque client Android/iOS distinct; non transposable à qTox. |
| 14 | Stockage local | Profil et historique restent sur l’appareil; qTox documente SQLCipher pour l’historique et l’option mot de passe pour chiffrer le profil/l’historique. | Les données sont localement contrôlées; mot de passe disponible. | Code/documentation qTox décrivent SQLCipher et toxencryptsave; étude Meier et al. reconstruit données à partir d’image disque et mémoire sous Windows/Linux. | Sans mot de passe robuste, la protection au repos est nulle ou très réduite; une session déverrouillée expose texte et clés au processus. | Paramètres KDF/SQLCipher exacts du build livré, protection OS/hardware, copies WAL/cache, nettoyage des suppressions et chemin exact de chaque OS. |
| 15 | Sauvegardes | L’utilisateur peut exporter le profil .tox; l’historique peut être sauvegardé localement. | Pas de sauvegarde cloud imposée par le protocole. | Manuel qTox recommande une copie manuelle; toxencryptsave utilise une clé issue d’un mot de passe et avertit qu’un mot de passe oublié rend les données irrécupérables. | La copie de profil non chiffrée déplace la clé privée vers tout support où elle est déposée. | Sauvegardes OS automatiques, exclusions du dossier, cryptage des volumes et pratiques de l’utilisateur. |
| 16 | Analytics / SDK | Client desktop open source; aucune télémétrie réseau centralisée n’est inhérente au protocole. | La documentation met en avant absence d’autorité centrale; aucun dossier analytique produit exhaustif trouvé. | Dépôts publics et dépendances sont consultables; aucune inspection binaire dynamique indépendante n’a été effectuée ici. | Un protocole sans serveur n’empêche pas une distribution/client modifié d’inclure des analytics. | SDK, crash reporting, endpoints intégrés dans binaires distribués, diagnostics Windows/macOS et différence entre packages tiers. |
| 17 | Code source | qTox est GPL et c-toxcore est public; le dépôt qTox historique a été archivé en 2025, puis le fork actif du projet TokTok a publié v1.18.5 en juin 2026. | Le projet se décrit ouvert et communautaire. | Releases v1.18.5 et commit sont signés GPG/GitHub; c-toxcore avertit de l’absence d’audit externe crypto. | Le code public permet inspection, pas preuve que chaque binaire de chaque OS correspond au code. | Client exact du téléchargement officiel Tox, paramètres de build et différence des packages de distributions. |
| 18 | Reproductibilité des builds | CI et jobs de build publics existent; les releases contiennent archives/sommes/signatures. | Les utilisateurs peuvent compiler depuis les sources. | Aucun résultat attestant de reconstruction bit-à-bit du binaire qTox 1.18.5 n’a été trouvé. Une signature confirme l’origine selon une clé, pas la reproductibilité. | Signatures/release tags améliorent la traçabilité mais ne prouvent pas à eux seuls l’équivalence source-binaire. | Correspondance binaire exacte pour Windows/macOS/AppImage/Flatpak et dépendances système. |
| 19 | Supply chain | toxcore documente libsodium, cmp en sous-module, opus/libvpx pour A/V; qTox ajoute Qt, SQLCipher, FFmpeg/scaling et packaging par plateforme. | Build ouvert et releases signées. | Changelog montre correctifs upstream et audits manuels ponctuels; l’advisory GHSA prouve qu’une faille peut persister dans une bibliothèque réseau ancienne. | Surface C/C++ et dépendances compilées importante; les clients communautaires peuvent embarquer des versions différentes. | SBOM complet signé, provenance CI, dépendances vendored dans chaque binaire et procédure de réponse au compromis de mainteneur. |
| 20 | Infrastructure OSINT | Des nœuds publics sont listés pour bootstrap; des opérateurs séparés exploitent nœuds DHT/relays et l’éditeur de liste fournit un annuaire. | Le réseau n’a pas de serveur central. | Le site Tox expose publiquement liste de nœuds; la FAQ indique que des clients les utilisent pour bootstrap. | Les listes et domaines peuvent être bloqués/altérés même si le réseau DHT n’a pas de centre unique. | Cartographie passive actuelle par ASN/hébergeur, pays, indépendance opérationnelle et journaux des nœuds; non mesurée ici. |
| 21 | Juridiction | Pas d’opérateur central du service de messages identifié; bootstrap, hébergeur de l’annuaire et mainteneurs ont leurs propres juridictions. | Aucun propriétaire central du réseau. | Pas de société opérant tous les utilisateurs ni conditions de service centrales identifiées. | Une demande légale doit viser le bon opérateur ou les appareils; la décentralisation n’empêche pas une demande aux nœuds/FAI/store. | Entités des nœuds connus, demandes juridictionnelles à leurs opérateurs et juridiction de distribution des binaires. |
| 22 | Demandes policières | Aucun law-enforcement guide ou rapport de transparence Tox/qTox trouvé. | Pas de fournisseur central d’historique à qui demander les messages. | Aucun cas documenté de remise de messages par TokTok/Tox dans le corpus consulté; l’étude forensique montre la voie terminale, pas remise fournisseur. | Les opérateurs peuvent potentiellement produire leurs propres journaux; FAI peut détenir IP/temps; terminal contient les messages. | Données effectivement remises par opérateurs de nœuds ou stores dans une affaire identifiable. |
| 23 | Affaires judiciaires | Aucune décision publique trouvée montrant une donnée remise par Tox/qTox dans un cas réel. | — | Sources judiciaires consultées ne relient pas spécifiquement une remise toxcore à une procédure documentée. | L’absence de cas trouvé ne démontre ni absence de demandes ni invulnérabilité. | Recherches nationales non exhaustives et dossiers non publics. |
| 24 | Audits | README toxcore indique explicitement qu’aucun audit formel par un tiers crypto/cryptanalyse n’a été effectué. | Une « manual audit » par un contributeur a identifié la faille corrigée en 0.2.23. | Advisory public donne scénario, sévérité High et version corrigée; ce n’est pas un audit indépendant global. | Le correctif ciblé ne valide ni protocole cryptographique, ni clients, groupes, A/V et builds. | Durée, commit exact de toute revue manuelle, tests de retest indépendants; audit externe complet absent des sources publiques trouvées. |
| 25 | Vulnérabilités | GHSA-42vg-9mg3-399f (3 juin 2026, High): débordement de pile à distance dans GCA onion announce, versions ≥0.2.18; toxcore 0.2.23 corrige. CVE-2021-44847: overflow UDP historique, versions 0.1.9–0.1.11 / 0.2.0–0.2.12, corrigé 0.2.13. | Mainteneurs publient les correctifs et avertissements. | Advisory GitHub et bulletin officiel du projet documentent portée et version; aucun exploit en campagne observé n’est établi ici. | Gravité annoncée High pour un sous-système activé: risque surtout disponibilité/mémoire, sans preuve de RCE exploitable. | Prévalence des versions vulnérables en clients distribués, exploitation publique et impact exact selon compilation/configuration. |
| 26 | Recherche académique | Meier, Choo et Le-Khac (2022) décrivent la reconstruction forensique qTox; Tobias Buchberger a publié travail/thèse sur remplacement du handshake par Noise IK. | Projet Tox publie les pistes académiques et un prototype d’orientation Noise. | Étude forensique teste des machines virtuelles Windows/Linux et dumps mémoire; elle n’est pas une validation crypto. | Il existe une recherche ciblée, mais pas de preuve publiée d’une analyse formelle complète du protocole actuel. | Adoption effective du nouveau handshake Noise dans la release stable et évaluation indépendante de sa sécurité. |
| 27 | Incidents historiques | KCI handshake signalé en 2017; problème de VBR Opus avant c-toxcore 0.2.20; failles mémoire historiques 2021 et 2026 corrigées en versions ultérieures. | Le blog 2023 dit que la situation du KCI n’est pas exploitable avec le client courant sans implémenter un toxcore personnalisé; aucun PoC de production n’est revendiqué. | Issue KCI reste ouverte avec milestone v0.2.25 au 13-10-2026; RC c-toxcore .24 n’implique pas que le point est résolu. | KCI est un problème de modèle/handshake, distinct des dépassements mémoire; ne pas fusionner ni extrapoler la condition d’attaque. | Version cible d’intégration Noise, exploitabilité sur clients stock actuels et incidents non publiés. |
| 28 | Gouvernance / financement | TokTok maintient toxcore et le fork qTox; le repo qTox courant publie six fingerprints de maintainers actifs. | Organisation communautaire et contribution publique. | Activité des dépôts/releases et signatures observables; aucune société propriétaire ou rapport financier central n’est identifié. | Concentration probable sur un petit nombre de mainteneurs malgré la base de contributeurs historique. | Mainteneurs actifs en équivalent temps plein, fonds, contrôle des clés de signature et plan de succession. |
| 29 | Résistance à la censure | P2P et DHT évitent un serveur message unique; nœuds bootstrap, UDP/ports, domaines d’annuaire et protocoles peuvent être filtrés. | Réseau décentralisé. | FAQ recommande plusieurs nœuds bootstrap et cite proxy/Tor; pas de mesure pays ou DPI trouvée. | Résilience partielle: distribution du code, répertoire de nœuds et ports demeurent points de blocage. | Efficacité de Tor/SOCKS/TCP-only et couverture géographique sous censure DPI moderne. |
| 30 | Maintenance actuelle | qTox TokTok v1.18.5 (2-06-2026); toxcore stable v0.2.23 (3-06-2026), RC v0.2.24-rc.2 (30-09-2026). | Page officielle indique encore développement important et avertit que les logiciels peuvent contenir des vulnérabilités. | Releases signées et changelog récent incluent correctifs; la branche qTox originelle archivée en 2025 et remplacée par le fork TokTok actif. | Maintenance courante attestée, mais architecture crypto reste explicitement expérimentale/non auditée. | Cadence/compatibilité exacte des versions installées depuis chaque dépôt de distribution. |

#### Tox/qTox — audits, forensics et sécurité (détails)

- **Audit crypto externe:** aucun rapport ni organisme tiers pour c-toxcore/Tox trouvé. Le README de l’éditeur le nie explicitement. Pour l’événement 2026, c-toxcore attribue la découverte de GHSA-42vg-9mg3-399f à un audit manuel par le contributeur « iphy »; portée: fonction GCA onion announce de toxcore, pas durée, engagement contractuel, version/commit audité complet ou méthodologie formelle publiés. Finding: buffer overflow stack à distance, non authentifié, scénario exigeant une GCA initialisée et liste GCA/DHT assez remplie; risque déclaré High, crash DoS le plus probable, corruption mémoire adjacente possible; fix 0.2.23, aucun retest externe publié. Ce n’est pas un audit complet du protocole.
- **KCI:** issue #426 ouverte depuis 2017, priorité P1/security, milestone v0.2.25. Elle décrit l’usurpation d’un contact par un attaquant qui a compromis la clé privée statique de la victime et peut construire le handshake/réseau nécessaire. Le billet du projet (2023) nuance l’exploitation stock: l’attaque discutée requiert de personnaliser toxcore; cela ne clôt pas le problème de conception et n’est pas une preuve de fix. Au 13-10-2026, issue toujours ouverte, aucun retest indépendant identifié.
- **Autres advisories:** CVE-2021-44847 affectait le chemin UDP de versions toxcore 0.1.9–0.1.11 et 0.2.0–0.2.12; le projet publiait le correctif 0.2.13 et une mitigation TCP-only. Historique, ne décrit pas une version actuelle. Le changelog antérieur à 0.2.20 mentionne aussi le risque de transcription lié à VBR Opus.
- **Forensics qTox:** Meier, Choo et Le-Khac (2022), Windows et Linux en VM, images système + dumps mémoire, analyse du code et de la base SQLite/SQLCipher chiffrée; étude dit que les outils forensiques standards ne détectaient pas/reconstruisaient pas correctement qTox et fournit une approche pour retrouver comptes, amis et conversations. Le résumé public ne précise pas la version exacte du client ni une version Cellebrite/GrayKey/Magnet; le chapitre complet est accessible sous DOI, pas de test 2026. Les données accessibles par mot de passe/session mémoire ne doivent pas être confondues avec une extraction sans clé.
- **Forensics commerciaux:** aucun résultat public daté reliant précisément Cellebrite/GrayKey/Magnet + modèle/OS/build + qTox version n’a été trouvé. L’article académique n’est pas une validation d’un parseur commercial actuel.

#### Tox/qTox — matrice métadonnées

| Métadonnée | Fournisseur / nœud | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ aux nœuds DHT/bootstrap/relays auxquels on se connecte; journaux inconnus | CONFIRMÉ pour amis ajoutés, direct; VPN/proxy/Tor peuvent substituer l’IP | CONFIRMÉ adresse/temps/volume des connexions réseau | POSSIBLE pour téléchargement/compte store; qTox n’utilise pas de push mobile standard | POSSIBLE via FAI, nœud ou terminal; remise spécifique inconnue |
| Téléphone | NON ACCESSIBLE PAR DESIGN du protocole; pas de compte numéro | POSSIBLE si divulgué séparément | POSSIBLE via données d’abonnement/corrélation, pas par Tox ID | POSSIBLE au compte store/opérateur, pas à qTox de manière inhérente | POSSIBLE chez opérateur/appareil; aucun cas qTox documenté |
| E-mail | NON ACCESSIBLE PAR DESIGN pour Tox ID; POSSIBLE pour services de distribution/support | POSSIBLE si communiqué dans la conversation | NON ACCESSIBLE PAR DESIGN via Tox seul | POSSIBLE au store/distribution | POSSIBLE par store, support ou terminal; pas de disclosure tox documentée |
| Identifiant | POSSIBLE bootstrap reçoit clé temporaire; pas de compte central stable connu | CONFIRMÉ Tox ID/public key et nom choisi | POSSIBLE par corrélation de flux | POSSIBLE par identité de store/app installée | POSSIBLE chez contacts, store, nœuds ou acquisition terminal |
| Graphe social | PROBABLE limité par onion lookup/keys temporaires; journaux des nœuds INCONNUS | CONFIRMÉ pour contacts/groupes locaux et ceux avec qui l’on communique | POSSIBLE timing/volume multi-flux | POSSIBLE via identité store/backup, non démontré pour qTox | POSSIBLE par contacts, devices, ISP/nœuds corrélés; remise réelle inconnue |
| Timestamps | POSSIBLE aux nœuds qui voient un flux; conservation inconnue | CONFIRMÉ dans historiques/états en ligne selon client | CONFIRMÉ pour sessions/flux | POSSIBLE via distribution/app activity/store | POSSIBLE si logs détenus; aucun cas Tox trouvé |
| Volumes | POSSIBLE à chaque nœud/relay | CONFIRMÉ par trafic reçu et fichiers/calls | CONFIRMÉ octets/durée | POSSIBLE selon télémétrie OS/store, non établi qTox | POSSIBLE via FAI/nœuds ou endpoint |
| Groupes | POSSIBLE via DHT/annonces selon protocole, contenu exact INCONNU | CONFIRMÉ membership, messages et clés visibles aux pairs du groupe | POSSIBLE par timing/volumes | POSSIBLE pour clients mobiles séparés | POSSIBLE via pairs, DHT et appareil; data remise inconnue |
| Appareils | INCONNU côté nœuds; aucune gestion de compte | POSSIBLE par présence/duplicata d’identité et messages, selon client | POSSIBLE par motifs de connexion | CONFIRMÉ au niveau de l’écosystème store si app installée | POSSIBLE via saisie/extraction et données compte stores |
| Push tokens | NON ACCESSIBLE PAR DESIGN pour qTox desktop; clients mobiles hors périmètre | NON ACCESSIBLE PAR DESIGN | NON ACCESSIBLE PAR DESIGN sans accès terminal | INCONNU pour aTox/TRIfA séparés; non imputable à qTox | POSSIBLE auprès du push provider du client mobile concerné, aucun cas établi |

#### Tox/qTox — TM1 à TM15 (provisoire, justification par la matrice ci-dessus)

| TM | Résistance | Justification |
|---|---|---|
| TM1 fournisseur curieux | 🟡 | Pas de stockage central; les nœuds auxquels le client se connecte peuvent voir IP/temps/volume. |
| TM2 fournisseur compromis | 🟡 | Pas de backend unique de messages, mais nœuds bootstrap/annonces et distribution peuvent être compromis ou surveillés. |
| TM3 fournisseur malveillant | 🟠 | La clé publique authentifie un pair, mais absence d’audit externe, issue KCI ouverte et distribution/client sont des surfaces. |
| TM4 ISP / Wi-Fi | 🟠 | Connexions IP directes/DHT et horaires visibles; proxy/Tor peuvent réduire, pas prouver une protection complète. |
| TM5 observateur passif puissant | 🟠 | Routage P2P, flux directs et horaires corrélables; pas de mixnet ni padding global documenté. |
| TM6 adversaire global passif | 🔴 | Aucun mécanisme Tox connu ne vise la résistance à une corrélation globale. |
| TM7 contact malveillant | 🔴 | Un ami reçoit l’IP selon la FAQ; il peut enregistrer messages, appels, fichiers et liens d’identité. |
| TM8 doxxer OSINT | 🟡 | Pas de téléphone requis, mais Tox ID stable et réutilisation du pseudo/IP permettent corrélation. |
| TM9 demande judiciaire classique | 🟡 | Pas de fournisseur central pour les messages; FAI/nœud/store/terminal peuvent toutefois avoir des données. |
| TM10 police sophistiquée | 🟠 | Combiner ISP, nœuds, correspondant et endpoint peut relier IP et compte; aucun cas de remise fournisseur identifié. |
| TM11 appareil verrouillé saisi | 🟡 | Profil/historique peuvent être protégés par mot de passe et SQLCipher; sans mot de passe ou avec copies non chiffrées, exposition. |
| TM12 appareil déverrouillé | 🔴 | Données sont ouvertes au client et mémoire; étude forensique qTox reconstruit des artefacts depuis disque/mémoire. |
| TM13 spyware ciblé | 🔴 | Terminal compromis lit contenu, clé, microphone/caméra et activité avant chiffrement. |
| TM14 supply-chain compromise | 🟡 | Code ouvert, releases signées et CI, mais pas de rebuild exact indépendant; dépendances compilées et petit noyau de mainteneurs. |
| TM15 censure étatique | 🟡 | DHT distribué mais bootstrap/domains, UDP, ports, magasins et distribution peuvent être filtrés. |

Contradictions/tests Tox : « aucun serveur » ne signifie pas absence de nœud d’entrée et d’opérateur; « IP cachée dans la DHT » ne couvre pas l’IP révélée aux amis; la revendication PFS de FAQ n’est pas vérifiée par le protocole de référence, qui marque ce point TODO, et coexiste avec un handshake KCI encore ouvert. Expériences nécessaires : capture réseau qTox 1.18.5 (bootstrap/direct/TCP-relay/proxy/Tor, IPv4/IPv6/DNS); test en comptes isolés d’exposition IP selon l’ajout, appels, fichiers et groupes; reconstruire binaire d’archive et comparer; inspection permissions/SDK de chaque client mobile séparément; analyse mémoire et DB sous sessions verrouillée/déverrouillée avec version actuelle; vérifier l’intégration réelle de la correction GCA .23 et du handshake prévu pour .25.

## Ricochet Refresh — dossier de preuves (situation au 13 octobre 2026)

**Séparation cruciale des versions.** Version stable Ricochet Refresh 3.0.46, publiée le 23 septembre 2026; elle embarque Tor 0.4.9.13. La branche maint-3.0 est la branche de release. Une 3.1.0-alpha.0 séparée expérimente une réécriture Rust du backend Tor/protocole et n’est pas traitée comme stable. Le Ricochet historique (v2 onion, dernier développement ancien) n’est pas Ricochet Refresh v3. L’audit NCC de 2015 porte sur le Ricochet historique, pas sur 3.0.46.

Sources primaires principales : [site et version 3.0.46](https://www.ricochetrefresh.net/), [release 3.0.46 / hashes / signatures / composants](https://github.com/blueprint-freespeech/ricochet-refresh/releases), [branche stable, code et historique](https://github.com/blueprint-freespeech/ricochet-refresh/tree/maint-3.0), [conception](https://github.com/blueprint-freespeech/ricochet-refresh/blob/main/doc/design.md), [protocole v3](https://github.com/blueprint-freespeech/ricochet-refresh/blob/maint-3.0/doc/protocol.md), [déclaration du projet sur les attaques médiatisées de 2019–2021](https://www.blueprintforfreespeech.net/en/news/statement-from-ricochet-refresh-regarding-recent-stories-in-german-medianbspabout-alleged-timing-attacks-affecting-our-users), [audit NCC original / PDF 24 pages](https://www.nccgroup.com/research/ricochet-security-assessment-public-report/), [miroir PDF lisible](https://roselabs.nl/files/audit_reports/NCC_Group_-_Ricochet.pdf), [registre australien Blueprint for Free Speech Inc.](https://abr.business.gov.au/ABN/View/38162740131).

| # | Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---:|---|---|---|---|---|---|
| 1 | Architecture | Client desktop peer-to-peer sur Tor Onion Services v3; chaque utilisateur héberge un service onion local, les contacts se connectent au travers du rendezvous Tor. | Pas de serveur de chat, ni d’entité centralisée qui stocke ou relaie les messages; ne s’affilie pas au Tor Project. | Le protocole maint-3.0 décrit une connexion par service onion et channels chat/contact/fichier; la release 3.0.46 inclut Tor 0.4.9.13. | Le réseau d’application n’a pas de broker central, mais dépend du réseau Tor, de ses autorités/consensus/relays, et de l’intégrité des clients. | Disponibilité selon NAT/OS, dépendance exacte aux autorités/HSDirs/guards et comportement de reprise, non mesurés ici. |
| 2 | Protocole cryptographique | Identité v3 service onion Ed25519; preuve de contact signée avec clé privée Ed25519-v3. Transport protégé par Tor onion-service; pas d’E2EE applicative distincte clairement documentée dans le protocole 3.0. | Communications chiffrées E2EE et « private by default ». | Le protocole décrit l’authentification de service onion et les channels, sans Double Ratchet; l’audit historique recommandait justement couche crypto applicative, mais il portait v2/2015. | Confidentialité dépend essentiellement du chiffrement Tor entre endpoints et du poste; point de terminaison compromis, mauvais client ou vulnérabilité Tor peuvent atteindre contenu/métadonnées. | Primitives/paramètres exacts et garanties PFS de la version Tor embarquée; app-level encryption supplémentaire éventuellement présente ailleurs que dans le protocole public. |
| 3 | Création d’identité | Profil produit un identifiant stable dérivé de l’adresse onion v3; pas de téléphone/e-mail/compte de connexion requis. | Anonymat sans identité civile, ID partagé au choix. | Le site indique que l’adresse onion est l’identité; la branche stable stocke un fichier profil local. | Pseudonyme stable, non identité civile; si publié/réutilisé, l’ID devient un pivot permanent de corrélation. | Génération du secret privé, protection matérielle OS, rotation, duplication/copie de profil et mécanisme de récupération. |
| 4 | Contact discovery | L’ajout se fait en transmettant l’ID onion par un canal externe puis en acceptant une demande entrante; pas de recherche centralisée de carnet. | Aucun annuaire de comptes ou synchronisation de contacts. | Le guide de conception et le protocole décrivent la demande de contact authentifiée au service onion. | Le canal par lequel l’ID est partagé (Discord, e-mail, site) peut faire le lien entre pseudonymes; le contact connaît l’ID reçu. | Indexation externe d’IDs onion, découverte secondaire et protection réelle des demandes non sollicitées. |
| 5 | Métadonnées serveur | Pas de serveur applicatif central; Tor transporte circuits et onion descriptors. Contacts savent leur propre connexion et le statut en ligne/offline observé. | « Nobody knows who you talk to or when » / aucune métadonnée. | Protocole et site établissent l’absence de serveur applicatif, pas l’absence d’observation par relay, guard, correspondant ou adversaire multi-points. | « Sans serveur » réduit les logs centraux, mais ne supprime ni timestamps locaux, ni état en ligne visible au contact, ni corrélation Tor. | Visibilité exacte des HSDirs/guards/points d’introduction, champs et rétention de données Tor en condition réelle. |
| 6 | IP utilisateur | Le client se connecte à Tor; le guard voit l’IP source; l’ISP voit la connexion au guard. | Aucun contact ne voit l’emplacement/IP. | Site et modèle Tor décrivent routage multi-hop; fournisseur affirme que l’IP utilisateur est masquée aux contacts. | Tor déplace la confiance d’un serveur vers le chemin réseau, sans effacer l’observation du premier relais et les corrélations de trafic. | Fuites DNS/IPv6, erreurs de configuration du Tor embarqué, journaux locaux et variabilité par OS. |
| 7 | IP exposée au correspondant | Les messages/fichiers traversent le service onion plutôt qu’une connexion IP directe déclarée par l’app. | Le contact ne peut pas connaître IP ou localisation de l’utilisateur. | L’architecture Tor et le protocole n’annoncent pas de candidate ICE/STUN/directe au contact; aucun test pcap indépendant de 3.0.46 effectué ici. | Protection contre divulgation IP directe au contact plausible par design, mais pas contre dé-anonymisation par timing/collusion/global observer. | Fuite involontaire hors Tor dans 3.0.46, liens ouverts dans navigateur externe, métadonnées de fichiers et appels OS. |
| 8 | Messages | Chat texte direct, maintenu dans une connexion active via Tor; protocole v3 contient texte, acknowledgement et delta de timestamp; aucun store-and-forward serveur. | Seulement le destinataire peut lire le message. | Protocole public décrit les champs message et transport Tor; guide annonce temps réel et données locales. | Le pair sait que la connexion/activité a lieu; le service n’a pas de boîte offline centrale. | Persistance exacte des conversations dans profile, crash dumps, logs et caches dans stable v3.0.46. |
| 9 | Groupes | Pas de groupe/chatroom multi-participants documenté dans le protocole stable; usage 1:1. | Produit présenté comme chat privé, non comme plateforme de groupes. | Le protocole documente un canal chat par contact et ne liste pas de canal de groupe. | Peu d’exposition de membership de groupe par application; pas un outil de groupe. | Fonctionnalité éventuelle dans branche 3.1 ou extensions non officielles. |
| 10 | Appels | Aucun audio/vidéo décrit pour Ricochet Refresh 3.0.46 stable. | — | README et protocole stable détaillent chat/fichiers, pas appels. | Pas de risque ICE/STUN de call selon documentation actuelle, mais pas d’usage VoIP. | Fonction appels dans forks/alpha; permissions éventuelles intégrées à des builds tiers. |
| 11 | Fichiers | Le protocole stable inclut un file-transfer channel sur même liaison onion; filename, taille et hash sont dans l’en-tête; transport par chunks avec ACK. | Transfert sécurisé intégré, sans serveur central. | Protocole maint-3.0 décrit metadata du fichier et transfert séquencé; aucune analyse indépendante du fichier système actuel trouvée. | Le contact destinataire connaît nom/taille/hash; le corps fichier traverse la couche Tor, mais métadonnées internes/EXIF persistent. | Chiffrement additionnel, quotas, répertoire temporaire, suppressions, comportement antivirus et intégrité côté UI dans v3.0.46. |
| 12 | Multi-device | Pas de compte cloud/multi-device documenté; l’identité est un onion service et un profil local par installation. | Profil local sur son propre ordinateur. | Avertissement officiel de l’alpha 3.1 conseille sauvegarde du profil avant essai; post officiel donne le chemin ricochet.json par OS. | Copier le profil peut dupliquer la même identité privée, pas établir un protocole de synchronisation multi-device sûr. | Comportement d’export, import, concurrence de profils et usage simultané sur différentes machines. |
| 13 | Push | App desktop Windows/macOS/Linux; pas d’APNs/FCM recensé; présence online requiert service onion et Tor actif. | Pas de dépendance push mobile. | Site/release ne proposent pas d’app mobile. | Pas de fournisseur push pour l’app desktop officielle; présence permanente expose des fenêtres d’activité à des observateurs. | Télémétrie système OS, notifications desktop et éventuels services tiers du site. |
| 14 | Stockage local | Profil local stable identifié comme ricochet.json dans les emplacements Windows/macOS/Linux communiqués par l’éditeur; ID/contacts/clé nécessaires au service localement. | Les données de compte résident sur l’ordinateur, pas sur un serveur. | L’audit NCC 2015 trouvait contacts/config/Tor cookie/.torrc non chiffrés sur disque, mais ce constat cible le Ricochet historique. | Une saisie peut révéler au minimum l’ID et les contacts si l’actuelle version n’a pas de chiffrement OS; cela doit être retesté sur 3.0.46. | Chiffrement des profils actuels, stockage historique messages, caches, fichiers reçus, logs, mémoire et permissions par OS. |
| 15 | Sauvegardes | Export/back-up du profil est recommandé avant l’alpha 3.1; pas de backup cloud propriétaire connu. | Données restent sous contrôle local; profil sauvegardable. | Les releases alpha avertissent d’une migration incompatible potentielle de profil; l’éditeur demande d’en faire une copie. | Backup non chiffré emporte identité onion et contacts; elle doit être traitée comme une clé d’identité. | Mécanisme d’encryption, recommandations de backup chiffré et inclusion par OS backups. |
| 16 | Analytics / SDK | Source de l’app est public; code de release dépend de Qt, OpenSSL et Tor; aucune app mobile/tracker Play/App Store pour le stable officiel. | Produit ouvert, pas d’enregistrement/centralisation d’usage. | Repositories publics et logs des releases; pas d’analyse de binaire/traffic de télémétrie effectuée ici. | Pas d’analytics central inherent au protocole; site download, OS et système de mise à jour restent des canaux distincts. | SDK analytics/crash reporting dans binaires actuels; scripts build et site web; privacy labels mobiles n/a. |
| 17 | Code source | Dépôt public C++/Qt; branche maint-3.0 stable et branche main alpha. Dossier séparé ricochet-build publie les scripts de build. | Open source; développeurs invitent aux contributions. | Repos montrent source, documentation et CI, mais code ouvert n’est pas une review actuelle. | App déployée comprend Tor embarqué, Qt, OpenSSL et pipeline; dépôt app seul ne couvre pas la supply chain complète. | Revue complète et version source commitisée précisément pour les binaires 3.0.46, provenance des sous-modules. |
| 18 | Reproductibilité des builds | Assets 3.0.46 incluent hash et signatures .asc; page confirme signatures GPG des releases. | Releases signées; hashes fournis. | Tag v3.0.46-release/commit 154f32b annoncé comme signé « verified », mais la clé était signalée expirée; aucun rebuild bit-à-bit tiers trouvé. | Hash/signature aident intégrité, mais une clé expirée accroît la nécessité de vérifier fingerprint/historique; cela n’équivaut pas à une build reproductible. | Expiration à la date de signature, révocation éventuelle, provenance CI complète et équivalence source-binaire multiplateforme. |
| 19 | Supply chain | 3.0.46 a mis à jour Tor 0.4.9.13 et tor-expert-bundle 15.0.23; versions stables anciennes cassent avec évolution Tor du 1 septembre 2026; site dit installer >3.0.43. | Publication régulière « monthly-ish » pour suivre Tor/OpenSSL/Qt. | Changelog décrit dépendances et signatures; la nécessité de versions récentes a été annoncée par l’éditeur avant coupure Tor. | Dépendance forte au bundle Tor et au rythme d’update; une version obsolète perd la capacité de connexion et garde des bugs upstream. | SBOM signé complet, build workers, approbation à deux mainteneurs, vulnérabilités héritées restantes. |
| 20 | Infrastructure OSINT | Pas d’infrastructure applicative de messages à résoudre; sites d’information/téléchargement ricochetrefresh.net et GitHub; trafic client passe sur le réseau Tor. | Aucune organisation/infrastructure centralisée à attaquer pour héberger les données. | Site officiel et GitHub sont publiquement identifiés; réseaux Tor ont autorités de directory et opérateurs relay distincts. | Compromettre le site/GitHub/update peut substituer les binaires; ce n’est pas la même chose que compromission d’un serveur de messages. | DNS actuel/registrar/ASN/CDN/région du site et GitHub release assets; non résolu par observation passive dans ce dossier. |
| 21 | Juridiction | L’opérateur de développement est Blueprint for Free Speech Inc., organisme australien inscrit au registre des charities; pas d’opérateur de messagerie central. Le site parle aussi d’une branche allemande distincte (e.V.). | Organisation non gouvernementale/nonprofit soutenant la liberté d’expression. | ABN Lookup/ACNC australien confirment l’entité australienne; mentions allemandes ne prouvent pas l’entité contractante du logiciel. | Une injonction à l’entité australienne peut viser site/builds/données de support qu’elle possède, pas un historique de messages central inexistant. | Structure juridique contractuelle entre Inc., e.V., projet, hébergeurs, clés de release et obligations précises de conservation. |
| 22 | Demandes policières | Aucun guide law-enforcement/transparency report Ricochet Refresh trouvé; aucun backend central de chat à remettre par design. | Aucun serveur de données; pas d’inscription. | Cas Boystown documenté par enquête journalistique à partir de dossiers: l’attaque a utilisé Ricochet historique et les données du fournisseur téléphonique, pas une remise de contenu par Blueprint. | Autorités peuvent viser ISP, relays, distribution, site, correspondant ou appareil; l’absence d’entreprise de stockage ne neutralise pas une enquête réseau. | Dossiers judiciaires complets non ouverts ici; demandes reçues par Blueprint/hosting, conservation effective et remises de données administratives. |
| 23 | Affaires judiciaires | Affaire Boystown (Allemagne, activité d’enquête 2019–2021) a lié une cible utilisant Ricochet historique aux entry guards Tor; un ordre judiciaire a demandé à Telefónica d’identifier quels clients O2 s’y connectaient. | Blueprint affirme ne connaître aucun utilisateur dé-anonymisé avec la version actuelle Ricochet Refresh; dit que les faits rapportés concernent 2019–2021 et l’ancienne application, et que les preuves détaillées ne lui ont pas été fournies. | Tagesschau/Panorama rapporte l’identification répétée de Tor entry nodes et l’ordonnance du tribunal de Francfort au fournisseur; ce n’est pas une preuve de contenu obtenu depuis Ricochet ni de break cryptographique. | Données effectivement obtenues rapportées: mapping IP/entry-node et identité d’abonné par FAI, après corrélation ciblée. L’ID Ricochet/activité servait à cibler; aucun message en clair n’est annoncé. | Affidavit complet, méthode exacte et portée judiciaire; si d’autres utilisateurs furent collectés incidemment; résultat final applicatif exact et détails techniques non publiés intégralement. |
| 24 | Audits | Un audit public NCC Group existe pour Ricochet original en 2015, version de rapport 1.2 du 15-02-2016; **aucun audit public de Ricochet Refresh 3.x identifié**. | L’éditeur présente le produit Refresh comme amélioré et annonce mises à jour fréquentes. | Le PDF NCC peut être lu; son périmètre n’est pas le client Refresh/Tor onion v3 actuel. | L’audit constitue une leçon historique, pas une garantie de l’actuel binaire. | Aucun commit précis du code historique dans rapport; aucun rapport Refresh indépendant ni retest trouvé. |
| 25 | Vulnérabilités | L’audit historique trouva une faille High de validation de demande contact pouvant exposer l’IP lors de l’acceptation, une Medium sur liens Unicode, et six notes informatives; l’app actuelle met à jour Tor en versions récentes. | Le projet dit vanguards-lite inclus depuis 3.0.12 (juin 2022) rend les attaques de guard-discovery plus difficiles; mises à jour régulières des dépendances. | L’enquête allemande rapporte désanonymisation de l’ancien Ricochet via timing/guard discovery, pas bris du chiffrement du message; rapports médias n’apportent pas toutes pièces techniques publiques. | La protection évoluée et le modèle onion v3 atténuent certaines attaques, mais ne prouvent pas l’immunité aux corrélations globales, ciblées ou endpoint. | CVE/retest spécifiques du stable 3.0.46, exploitation observée post-3.0.12 et effet exact de vanguards-lite contre la méthode Boystown. |
| 26 | Recherche académique | La recherche Tor sur les attaques de traffic analysis décrit classe de corrélation; pas d’évaluation académique actuelle publiée pour Refresh 3.0.46 identifiée. | L’éditeur réfute les garanties absolues et qualifie les attaques puissantes de coûteuses/étatiques. | Documents journalistiques indépendants et travaux Tor sur traffic analysis établissent que Tor n’est pas résistant à un adversaire global; aucune mesure de l’app stable trouvée. | Le chat temps réel produit des timings reconnaissables, donnant un signal actif/corrélable même si contenu reste chiffré. | Analyse formelle du protocole Refresh contre adversaire global/passif, simulation vanguards/traffic padding et étude indépendante après 2022. |
| 27 | Incidents historiques | Ricochet original a eu protocole v2 à identité RSA/SHA-1 tronquée et une dé-anonymisation de contact request auditée en 2015; Refresh a porté Tor onion v3 et ajouté vanguards-lite. | Développeurs disent que l’ancien Ricochet est abandonné car technologie Tor v2 retirée, et que Refresh est mis à jour. | Cas Boystown concernait une version de Ricochet déclarée par sources comme abandonnée/ancienne, pas preuve d’une compromission de Refresh. | Histoire montre que la résistance aux métadonnées peut échouer sans casser E2EE; il faut distinguer famille applicative, versions et Tor. | Liste chronologique complète des incidents mineurs/bugs par release, retests de l’ancienne faille High et éventuels incidents non publics. |
| 28 | Gouvernance / financement | Projet soutenu par Blueprint for Free Speech Inc.; organisme australien nonprofit/charity et branche allemande e.V. distincte; financement d’un projet NGI/NLnet antérieur documenté. | Organisation non gouvernementale, nonprofit; projet pour journalistes/whistleblowers. | Registre ACNC/ABN australien, site Blueprint, crédits NGI établissent la gouvernance générale mais pas comptes opérationnels du produit. | Structure nonprofit et financement connus n’impliquent pas de contrôle indépendant du code ni assurance de continuité. | Budget, nombre exact de mainteneurs rémunérés, possession/rotation clé release, responsabilités juridiques du site hébergeur. |
| 29 | Résistance à la censure | Utilise Tor, donc accès peut être bloqué par filtrage Tor, guards/IP, téléchargements GitHub/site et magasins desktop; pas de mobile. | Résiste au monitoring/censure locale selon les objectifs de conception; aucun bridge n’est une propriété explicite du protocole de chat. | Cas de Tor, consensus et vanguards sont documentés; l’app a modifié les versions Tor en fonction des changements network. | Censorship circumvention dépend de la configurabilité du Tor intégré et de bridges; architecture P2P n’empêche pas le blocage du transport. | Configuration bridge/obfs4/Snowflake dans 3.0.46, comportement dans pays censurés et possibilité de modifier relay/ports par utilisateur. |
| 30 | Maintenance actuelle | Stable 3.0.46 (23-09-2026), Tor 0.4.9.13; 3.1.0-alpha.0 est une réécriture Rust distincte destinée aux tests et sauvegarde recommandée. | Le site indique releases « monthly-ish » suivant mises à jour amont; le mainteneur publie des mises à jour. | Releases septembre 2026 et commit/tag signés visibles; comptes GitHub affichent 1,612 commits mais ce total couvre l’historique et ne mesure pas les mainteneurs actifs. | Maintenance récente démontrée; néanmoins la portée des audits externes actuels n’est pas démontrée. | Mainteneurs actifs par composant, tests automatisés/coverage, retest et date de disponibilité de 3.1 stable. |

#### Ricochet Refresh — extraction du PDF NCC et limite de portée

**Organisme/commanditaire/version/méthode.** NCC Group Security Services, Inc.; projet Ricochet + Open Technology Fund; deux consultants à l’engagement, auteurs nommés Jesse Hertz, Patricio Jara-Ettinger, Mark Manning; rapport v1.2 du 15 février 2016. Le tableau de bord du PDF donne dates 16–22 novembre 2015 et 16 person-days; page OTF indique 16–25 novembre (écart de date documentaire). Source code review white-box C++, Qt, Protocol Buffers; revue de code et documents de design, fuzzing AFL et analyse dynamique qualifiée de cursory. Exclusions explicites: fichiers de layout QML hors périmètre; Tor lui-même hors périmètre; tests additionnels recommandés. Pas de hash commit/version source commitée dans le rapport; aucun retest NCC public trouvé.

**Résultats (sévérités NCC, pas CVSS):**

| ID | Sévérité NCC | Finding, impact, recommandation | Correction/retest public |
|---|---|---|---|
| 007 | High (impact High, exploitabilité Medium) | HTML/unicode dans nickname/message de contact request; si victime accepte, rendu peut déclencher requête révélant l’IP réelle ou phishing/homographe. Whitelist stricte/validation encodage. | Le rapport indique des tickets de bug déjà connus; pas de preuve de retest NCC. Modern v3 transporte la demande par Tor, mais un navigateur/lien externe ou endpoint reste un chemin à tester. |
| 006 | Medium (impact Medium, exploitabilité Medium) | Unicode dans liens peut produire homographe vers site attaquant; visite révèle IP et métadonnées de navigateur; clipboard peut exposer à bug OS. Restreindre caractères/encoder. | Rapport signale un pull request ouvert, mais ne confirme pas merge/retest dans Refresh actuel. |
| 001 | Informational (impact High, exploitatibilité Low) | HMAC supplémentaire dans l’authentification client jugé cryptographiquement complexe et inutile; simplifier par preuve de propriété de clé déjà utilisée côté serveur. | Pas de mapping documenté vers code Refresh ou retest. |
| 002 | Informational (impact Low, exploitabilité Low) | Processus local pouvant usurper socket Tor control et demander un cookie 32 bytes arbitraire; valider chemin/répertoire allowlist ou référence opaque. | Le rapport recommande; pas de statut public de correction/reretest. |
| 003 | Informational (impact High, exploitabilité Low) | Ricochet v2 utilisait hostname fondé sur 80 bits de SHA-1 de clé RSA 1024; adversaire étatique pouvait chercher collision/impersonation. Renforcer vérification/identifiant. | L’architecture Refresh v3 utilise ED25519-v3 et adresse onion v3; la vieille faiblesse précise est historiquement dépassée, sans audit de migration. |
| 004 | Informational (impact Medium, exploitabilité Low) | Messages protégés seulement par le transport Tor, pas d’encryption applicative indépendante; recommander layer crypto additionnelle. | La documentation 3.0 décrit encore le transport onion comme couche de confidentialité; aucun audit Refresh ne valide une couche ajoutée. |
| 008 | Informational (impact High théorique, exploitabilité None dans code observé) | Buffer overread dans CryptoKey::loadFromData, alors appelé avec QByteArray terminé NUL et format DER dans chemin considéré non exploitable; borner la longueur ou retirer code mort. | Pas de correspondance ou retest Refresh établi. |
| 005 | Informational (impact Low, exploitabilité Low) | Fichiers config/metadata en clair: contacts, config Ricochet/Tor, cookies d’auth Tor, .torrc; recommander chiffrement local/OS. | Chemin profile actuel connu mais chiffrement stable 3.0.46 non vérifié; aucun retest. |

Le PDF qualifie l’application d’ensemble comme de bonne qualité dans son périmètre, mais note input validation insuffisante, cryptographie conçue « needs improvement » et stockage au repos en clair pour l’ancien Ricochet. Cela ne doit être ni résumé comme « Ricochet Refresh a passé NCC », ni comme preuve que la version actuelle présente toujours les huit findings.

#### Ricochet Refresh — forensics et law enforcement

- **Forensics:** aucune étude publique de Cellebrite, GrayKey ou Magnet nommant Ricochet Refresh stable + version d’appareil, OS exact et date d’acquisition n’a été trouvée. Le profil ricochet.json et les clés onion locales sont une cible forensique évidente; c’est une inférence à partir de l’architecture, pas un test d’extraction testé. Les logs/chat history/caches de 3.0.46 doivent être examinés directement sur Windows/macOS/Linux, locked/unlocked et avec chiffrement disque activé/désactivé.
- **Affaire documentée:** enquêtes presse Panorama/STRG_F et Tagesschau (18 septembre 2024) sur Boystown rapportent que, pendant 2019–2021, le BKA/Généralstaatsanwaltschaft Frankfurt a utilisé une corrélation active de trafic Tor contre une cible utilisant Ricochet historique: activité de chat connue, observation de relais, découverte d’entry guards, puis ordonnance judiciaire au tribunal de Francfort demandant à Telefónica/O2 de retrouver les abonnés connectés à des nœuds identifiés. L’information effectivement obtenue rapportée est une attribution réseau/abonné par fournisseur télécom après corrélation; aucune remise de plaintext par Ricochet/Blueprint n’est décrite. Les articles s’appuient sur des pièces d’enquête, mais le dossier judiciaire complet et les données brutes de mesure ne sont pas publiés ici.
- **Réponse de l’éditeur:** Blueprint dit ne connaître aucun utilisateur de la version actuelle Refresh dé-anonymisé; affirme que l’affaire concernait l’ancien Ricochet, avant migration v3 et vanguards-lite (introduit par l’app 3.0.12 en juin 2022), et que les détails techniques/éléments de preuve ne lui ont pas été transmis. C’est la position éditeur, non une preuve indépendante d’immunité. Vanguards-lite vise la difficulté de guard discovery; ne neutralise pas toutes formes de correlation globale/timing.
- **Demandes et autorités:** aucun rapport de transparence/guide légal de Blueprint pour Ricochet Refresh trouvé. Le service applicatif ne dispose pas d’historique central documenté; l’affaire montre cependant le rôle effectif d’un opérateur téléphonique sous ordonnance. Une demande à hébergeur GitHub/site peut viser visiteurs de téléchargement/logs de support selon ce qu’ils conservent, mais aucun cas de remise associée à Refresh n’est établi.

#### Ricochet Refresh — matrice métadonnées

| Métadonnée | Fournisseur Blueprint / app | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | NON ACCESSIBLE PAR DESIGN au service de messages; POSSIBLE au site/support/distribution si logs existants, inconnus | NON ACCESSIBLE PAR DESIGN par connexion onion selon l’architecture; POSSIBLE via lien ouvert navigateur, contact externe ou endpoint | CONFIRMÉ: connexions à guards Tor, IP source et temps; PROBABLE corrélations multi-points | N/A pour app desktop officielle; compte store possible pour téléchargement indirect | CONFIRMÉ/POSSIBLE via FAI/ordonnance: Boystown a rapporté une identification d’abonné après correlation Tor; aucun IP conservé par Blueprint démontré |
| Téléphone | NON REQUIS; POSSIBLE support/financement si utilisateur fournit lui-même | POSSIBLE si donné hors bande | POSSIBLE par l’abonnement identifié après IP/session | POSSIBLE via compte Apple/Google pour téléchargement, pas via Ricochet | POSSIBLE auprès FAI/store ou terminal |
| E-mail | NON REQUIS; POSSIBLE support/contact éditeur | POSSIBLE si donné hors bande | NON ACCESSIBLE PAR DESIGN via Tor seul | POSSIBLE au store ou service e-mail | POSSIBLE chez store/éditeur/FAI si corrélé, aucune remise Refresh connue |
| Identifiant | POSSIBLE site/download may log account/IP, rétention INCONNUE; pas de compte chat | CONFIRMÉ ID onion stable; qui contacte qui peut être observable par le pair | POSSIBLE par timing et activité Tor | POSSIBLE identité install/store (hors messagerie) | POSSIBLE ID onion public + corrélation traffic; cas Boystown rapporté |
| Graphe social | NON ACCESSIBLE PAR DESIGN au serveur app; Tor metadata/observateurs peuvent aider, UNKNOWN exact | CONFIRMÉ par contacts enregistrés et connexions actives | POSSIBLE par analyse corrélative; cas historique ciblé montre un chemin | NON ACCESSIBLE PAR DESIGN directement; possible compte/store activity séparée | POSSIBLE par appareil, correspondants, traffic timing/ISP; incident historique établit ciblage d’un contact/ID |
| Timestamps | UNKNOWN données Blueprint; Tor réseau observe timing à chaque point où il voit flux | CONFIRMÉ état online/connexion, heure des messages côté client | CONFIRMÉ sessions Tor/durée; données historiques peuvent exister chez opérateur | POSSIBLE store/OS de lancement/téléchargement | POSSIBLE; cas de timing analysis documenté par presse à partir d’actes |
| Volumes | NON ACCESSIBLE PAR DESIGN au service message; POSSIBLE hébergeur download si logs | CONFIRMÉ tailles et trafic/messages/fichiers reçus | CONFIRMÉ octets/durée Tor | POSSIBLE metadata OS/store | POSSIBLE FAI/relay/terminal; contenu n’est pas nécessairement connu |
| Groupes | N/A pour protocole stable documenté | N/A | NON ACCESSIBLE PAR DESIGN comme membership explicite, corrélation possible | N/A | N/A |
| Appareils | POSSIBLE données support/website s’il y en a; aucun compte app | CONFIRMÉ même ID/contact, pas nécessairement matériel exact | POSSIBLE empreinte timing/réseau, pas preuve d’appareil | CONFIRMÉ Apple/Google pour l’installation si store utilisé | POSSIBLE par saisie, FAI et store |
| Push tokens | NON ACCESSIBLE PAR DESIGN (pas de push mobile officiel) | NON ACCESSIBLE PAR DESIGN | NON ACCESSIBLE PAR DESIGN | N/A app officielle desktop; OS notification local seulement | NON ACCESSIBLE PAR DESIGN via fournisseur de push; terminal/OS possible |

#### Ricochet Refresh — TM1 à TM15 (provisoire)

| TM | Résistance | Justification |
|---|---|---|
| TM1 fournisseur curieux | ✅ | Pas de serveur central de messages; les données de site/support restent hors du protocole et non auditées. |
| TM2 fournisseur compromis | 🟡 | Compromettre Blueprint ne livre pas le chat côté serveur, mais update/site/repository signés sont une surface de ciblage. |
| TM3 fournisseur malveillant | 🟡 | Pas d’autorité de compte; néanmoins app/updates peuvent être ciblés, et le chat s’appuie sur Tor plutôt que sur un ratchet vérifiable séparément. |
| TM4 ISP / Wi-Fi | 🟡 | Tor masque destinations onion mais ISP voit guards, horaires, volume et peut contribuer à une corrélation. |
| TM5 adversaire passif puissant | 🟡 | Tor évite qu’un relais isolé voit l’origine et la destination simultanément; observations multiples/timing peuvent corréler. |
| TM6 adversaire global passif | 🔴 | Pas de mixnet/padding global; l’affaire historique illustre la possibilité de relier activité connue et réseau, même si version ancienne. |
| TM7 contact malveillant | 🟡 | Le contact ne reçoit pas l’IP directement via onion transport, mais connaît l’ID stable, messages/fichiers et peut piéger via demande/lien externe. |
| TM8 doxxer OSINT | 🟡 | Pas de numéro/e-mail requis; IDs onion stables, réutilisation pseudo, contenus de fichier et divulgation de l’ID sont des pivots. |
| TM9 demande judiciaire classique | 🟡 | Pas d’historique central; service site/hébergeurs, FAI/Tor usage et terminal restent saisissables ou requis. |
| TM10 police sophistiquée | 🟠 | Corrélation réseau + ordres au FAI + saisie endpoint peuvent révéler identité/IP; cas historique de l’ancienne app rapporté. |
| TM11 appareil verrouillé saisi | 🟡 | Pas de chiffrement actuel du profil confirmé; fichier profil et contacts sont locaux. Protection dépend du chiffrement disque/OS et de verrouillage. |
| TM12 appareil déverrouillé | 🔴 | Clé onion, contacts, messages/caches locaux potentiellement ouverts au processus; aucune protection au repos protège un profil chargé. |
| TM13 spyware ciblé | 🔴 | Malware local observe messages, frappes, IDs, fichiers, microphone/écran et clés avant/après Tor. |
| TM14 supply-chain | 🟡 | Code et tags/releases/hashes publics, mais pas de rebuild reproductible indépendant; signature clé release déclarée expirée et dépendances bundle Tor/Qt/OpenSSL. |
| TM15 censure étatique | 🟡 | Tor apporte contournement potentiel, mais guards, bootstrap, téléchargement et binaire peuvent être bloqués; bridges/obfsf4 dans le client stable non vérifiés. |

## XMPP / OMEMO — dossier individuel d’investigation (13 octobre 2026)

**Périmètre précis.** XMPP est un protocole fédéré, pas un fournisseur ni une application. La fiche ci-dessous prend comme client de référence Conversations pour les éléments de l’application, et OMEMO XEP-0384 pour le chiffrement. Les constats réseau, conservation, juridiction et demandes dépendent du serveur XMPP choisi, des extensions activées et du client. « XMPP/OMEMO » ne décrit donc pas un produit uniforme.

| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1 Architecture | Fédération XMPP client–serveur puis serveur–serveur; compte de type JID sur un domaine. | Conversations indique que l’utilisateur peut choisir un serveur ou en exploiter un. | XEP-0384 et XEP-0166 décrivent les couches d’extension; les docs Conversations recensent MAM, MUC, PEP, push et upload selon le serveur. | L’opérateur du domaine de compte, les serveurs de groupe et de fichiers peuvent être différents. | Quel serveur, client et ensemble exact d’extensions pour un utilisateur concret. |
| 2 Protocole cryptographique | OMEMO v2 XEP-0384, version 0.9.1 datée du 6 avril 2026; XEP toujours au statut « Experimental ». Établi au-dessus de XMPP/PEP; X3DH et Double Ratchet, clés de message et enveloppe SCE. | Les clients compatibles le présentent comme chiffrement de bout en bout pour conversations et groupes. | La spécification publie la liste d’appareils et les bundles public keys/prekeys dans PEP; les recommandations de confiance et de traitement des devices sont explicitement normatives. | Chiffrement effectif seulement si les deux clients le prennent en charge, si la session est vérifiée/confiée et si aucun fallback en clair n’est accepté. | Interopérabilité et version OMEMO négociée entre deux versions précises; propriétés cryptographiques indépendamment formalisées/auditées pour la version 0.9.1. |
| 3 Création d’identité | JID choisi/créé chez un serveur; identité de compte liée au domaine et aux appareils OMEMO publiés. | Conversations dit ne pas exiger un numéro de téléphone ou un carnet de contacts. | JID, ressources et listes device/bundles sont définis dans les protocoles XMPP/XEP. | Un domaine de JID persistant est un identifiant OSINT; compte sans numéro n’est pas anonyme si réutilisé. | Exigences d’inscription, anti-abus, vérification et données d’inscription propres à chaque serveur. |
| 4 Contact discovery | Ajout par JID/QR/lien ou découverte par serveur/clients; pas de répertoire global obligatoire au niveau XMPP. | Conversations affirme que le carnet n’est pas envoyé comme liste complète. | La découverte OMEMO requiert la lecture des listes d’appareils et bundles publics via PEP; le roster XMPP est transmis au compte serveur. | La liste de contacts complète peut être connue par l’opérateur via le roster, même si le carnet OS n’est pas téléversé. | Comportement de chaque app, contact sync optionnel, extensions de répertoire et retention sur chaque serveur. |
| 5 Métadonnées serveur | Au moins JID expéditeur/destinataire/domaine, présence/connexion, horaires, routage, taille approximative; MAM peut stocker l’historique; PEP héberge device lists, bundles/prekeys. | Conversations dit que le corps OMEMO n’est pas lisible du serveur et que son hébergement optionnel minimise les données. | XEP-0384 rend device IDs, device labels signés et bundles publiés consultables selon modèle PEP; XMPP standard expose les stanzas de routage au serveur. | Les métadonnées peuvent révéler les contacts, les appareils, l’activité et l’appartenance aux salons même si le payload OMEMO est chiffré. | Journaux et rétention effectifs, MAM activé, extraction de groupe par un serveur donné. |
| 6 IP utilisateur | Le serveur de compte voit l’IP lors de la connexion; serveur de salon, upload, STUN/TURN voient celle des sessions auxquelles ils participent. | Certains hébergeurs annoncent minimisation/rétention courte; ce n’est pas une propriété générale de XMPP. | Architecture client–serveur et protocoles ICE/TURN impliquent ces observateurs. | Domaine fédéré ne masque pas l’IP d’origine à l’opérateur auquel le client se connecte. | Politique de logs et fronting/CDN actuels de l’hébergeur choisi. |
| 7 IP au correspondant | Jingle/ICE peut négocier une voie directe; TURN peut masquer l’IP au pair en remplaçant l’adresse de transport. | Aucune affirmation universelle applicable à tous clients/serveurs. | XEP-0166/ICE/TURN définissent les voies possibles; pas de capture réseau effectuée dans cette mission. | Contact peut obtenir IP publique en appel direct ou partage de fichier direct selon client/configuration. | Candidats ICE exacts et comportement actuel de Conversations et d’un autre client choisis. |
| 8 Messages | OMEMO rend le payload illisible au serveur pour les appareils destinataires; transport XMPP reste TLS indépendamment. | Conversations affirme E2EE quand OMEMO est actif. | Spécification indique les enveloppes chiffrées et destinataires/device IDs; les messages hors OMEMO restent sous le régime du serveur. | Le sujet, JID, tailles, heures, statut de remise et éventuels éléments non enveloppés restent exposés. | Implémentation exacte des extensions par client; textes de notification; fallback déclenché par erreur ou ancien contact. |
| 9 Groupes | MUC/MIX permet des salons; OMEMO prévoit chiffrement de groupe/device selon compatibilité. | Le client peut signaler E2EE dans un salon OMEMO. | XEP-0384 illustre l’inclusion d’une clé par appareil participant; la composition du salon et les présences restent gérées par le serveur. | Le serveur peut connaître les participants, horaires et changements de membership; l’E2EE ne cache pas ce graphe au serveur du salon. | Négociation/membership consistency par implémentation et niveau de résistance aux changements malveillants non testés ici. |
| 10 Appels | VoIP via Jingle/WebRTC et extensions; OMEMO messages n’implique pas E2EE des médias. | Certains clients annoncent chiffrement d’appel ou DTLS-SRTP. | XEP-0166/ICE décrit négociation, mais pas une garantie universelle d’E2EE interopérable. | Le service TURN peut observer IP/temps/volume; appel direct peut révéler IP au correspondant. | Client, version, audio/video encryption et relais sélectionné; aucun test de capture. |
| 11 Fichiers | XEP-0363 HTTP File Upload peut envoyer un fichier vers un service web puis partager un lien; transferts P2P sont aussi possibles selon clients. | Certains clients annoncent chiffrement de fichier ou upload privé; ce n’est pas commun à toutes les implémentations. | Conversations documente les uploads XMPP et clients; la spec OMEMO n’enveloppe pas nécessairement chaque lien/binaire de la même manière. | Serveur d’upload peut voir IP, taille, heure et parfois contenu/titre si fichier non chiffré avant upload. | Pour un chemin donné, chiffrement préalable, EXIF, URL, rétention, antivirus/CDN et suppression. |
| 12 Multi-device | OMEMO est conçu avec un appareil par device ID; clients publient devices et bundles. | Conversations prend en charge les appareils OMEMO. | XEP-0384 décrit la publication device list et une clé pour chaque device du destinataire et de l’expéditeur. | Nouvel appareil et ajout de device modifient la surface de confiance et peuvent exposer l’historique synchronisé. | Consistance du roster OMEMO, révocation effective et ré-enrôlement sur versions précises. |
| 13 Push | XEP-0357 permet push par serveur; Conversations utilise Firebase Cloud Messaging dans sa distribution Google selon sa documentation. | Le fournisseur affirme que la notification ne divulgue pas le texte chiffré; une autre distribution peut utiliser un autre transport. | La spec OMEMO ne garantit pas le contenu du push; APNs/FCM sont opérateurs externes. | Un push silencieux/token révèle installation, appareil et horaire; payload contient au minimum un signal de réveil et peut dépendre du client. | Payload réel, tokens, configuration FOSS/Google Play, Firebase SDKs et collecte dans la release actuelle. |
| 14 Stockage local | Conversations conserve conversations/messages/identifiants et clés localement pour fournir l’historique; chiffrement d’appareil/OS change l’accès hors-ligne. | Le client recommande la protection de l’appareil; E2EE concerne le transport de conversation. | Rapport ROS 2025 a constaté SQLite contenant JID, mots de passe, conversations, messages et clés OMEMO en clair dans l’état analysé (test Android 15 Pixel 7). | Un terminal déverrouillé ou un accès au processus révèle les contenus après déchiffrement. | Généralisation au build actuel, iOS/desktop, paramètres de backup et protections hardware. |
| 15 Sauvegardes | Conversations offre un export/chiffrement de sauvegarde; Android Auto Backup configuré par l’app peut exiger un backup système chiffré. | Rapport de sécurité dit que l’export manuel est protégé par AES-GCM. | ROS 2025: backup local observé gzip + AES-128-GCM, clé dérivée du mot de passe de compte via PBKDF2-HMAC-SHA1 à 1 024 itérations; recommandation Argon2. | Une phrase de passe faible ou faible KDF augmente l’attaque hors ligne; le support du mot de passe de compte comme clé lie les risques. | Statut corrigé dans les versions après rapport, politique de récupération et exactes exclusions backup Android/iOS. |
| 16 Analytics / SDK tiers | FCM et bibliothèques Android sont des composants tiers possibles; dépend du build/variant. | Politique Conversations datée du 22 novembre 2023 affirme ne pas collecter de données applicatives hors informations fournies. | Rapport ROS 2025 contient inventaire logiciel/SBOM et revue de dépendances, mais ne constitue pas une mesure complète de trafic runtime. | « Pas de telemetry éditeur » ne signifie pas absence de métadonnées chez push, store, OS ou serveur XMPP. | SDKs de la version 2.20.4+, appels réseau runtime et permission par variant. |
| 17 Code source | Conversations Android et serveurs XMPP publics sont open source selon le produit choisi; XMPP est un protocole ouvert. | Conversations indique que le dépôt est la source de l’app officielle. | Repository GitHub, XEPs, F-Droid et rapports ROS rendent les éléments inspectables. | Source publique améliore auditabilité mais ne prouve pas le binaire livré ni l’infrastructure. | Clients commerciaux, plugins, serveurs et services tiers utilisés par l’utilisateur. |
| 18 Builds reproductibles | F-Droid reproduit certains builds Conversations; page de vérification rapportait dernier build vérifié 2.19.16+free le 11 sept. 2026, alors que 2.20.4+free était listé le 29 sept. | Conversations/F-Droid rendent les logs et APKs téléchargeables. | F-Droid publie les résultats de vérification, échantillon versionné et statut. | Ne pas transférer le résultat 2.19.16 à 2.20.4; aucune reproduction de 2.20.4 effectuée ici. | Build précis de 2.20.4, Play Store/iOS et signature du binaire observé chez un utilisateur. |
| 19 Supply chain | APK, dépôts et dépendances sont disponibles pour l’inspection; le rapport ROS a relevé Guava 31.1-jre et CVE connus mais fonctions vulnérables non utilisées dans le périmètre inspecté. | Le projet expose le code et l’app F-Droid. | Audit ROS 2025 a recommandé des audits de dépendances futurs; F-Droid builds aident la comparaison mais ne couvrent pas toutes distributions. | Client, build system, FCM, store, librairies et serveur constituent des chaînes distinctes. | SBOM actuelle complète, attestations, signatures de release applicables à chaque plateforme et état de dépendances. |
| 20 Infrastructure OSINT | Infrastructure est choisie par domaine XMPP; le service conversations.im est une option, non le réseau entier. | L’offre Conversations mentionne un hébergement en Allemagne et des fonctions de serveur XMPP. | Docs d’hébergement et XEPs établissent rôles; aucun instantané DNS/ASN/CDN actif n’a été acquis pour un compte ciblé. | Hébergement propre change l’opérateur de compte mais pas les serveurs d’upload/push/contact utilisés. | Domaines/IP/ASN/hébergeurs/régions actuels par instance, peering, sous-traitants et logs. |
| 21 Juridiction | Juridiction suit le fournisseur de compte, fichiers, push et l’utilisateur; pas de juridiction globale XMPP. | conversations.im indique son implantation dans l’UE/Allemagne. | Identité de l’opérateur et documents contractuels sont plus probants que le protocole; aucune analyse juridique par pays menée ici. | Serveur fédéré contacté peut être soumis à sa propre loi et traité transfrontalier. | Entité contractante, sous-traitants, conservation et demandes du serveur choisi. |
| 22 Demandes policières | Un opérateur serveur peut techniquement détenir compte/JID/IP/metadata et archives MAM; contenus OMEMO pas directement lisibles sans clés, si implémentation correcte. | Des hébergeurs XMPP publient parfois politique ou guide mais pas de procédure homogène. | Aucun rapport/transparency guide universel; pas de cas individuel de remise d’un serveur précis établi pour cette fiche. | Les données récupérables varient avec serveur/historique, fichiers, paiement, support et saisie endpoint. | Volume de demandes et champs réellement remis par conversations.im/serveur arbitraire. |
| 23 Affaires judiciaires connues | Aucune remise de données attribuée à un serveur XMPP nommé et vérifiée dans les sources examinées. | — | Pas de preuve positive ni preuve d’absence; aucun dossier public spécifique au serveur retenu. | Dossier criminel mentionnant « Jabber » n’établit pas que l’opérateur a remis des données. | Requêtes FOIA/dossiers européens et autres juridictions, serveur/client précis. |
| 24 Audits | Trois travaux ROS pertinents: OMEMO historique 2016, Smack-OMEMO 2018, Conversations Android 2025. | ROS et Conversations ont publié des rapports. | Les périmètres, versions et findings sont détaillés dans le sous-dossier ci-dessous. | Ils couvrent protocole ancien, bibliothèque Smack ancienne et un build Android; pas le réseau XMPP entier ni la version actuelle. | Retests publics après correction et engagement pour le client actuel. |
| 25 Vulnérabilités | Findings historiques incluent device inactif/read-only, prekey lifecycle, path traversal Smack; audit 2025 a relevé validations TLS et révocation. | L’éditeur a corrigé des éléments et décrit la posture actuelle. | ROS reports are dated/primary; fixes exactes et retests doivent être vérifiés release par release. | L’âge d’un CVE/finding ne prouve pas sa présence aujourd’hui. | CVEs/advisories actuels pour la release choisie et statut des remédiations. |
| 26 Recherche académique | Protocoles XMPP/OMEMO et Signal ont des travaux académiques indépendants; OMEMO client-side remains implementation-sensitive. | XMPP Foundation publishes XEP, not a product-wide security result. | Reports ROS and protocol specifications provide technical material; no modern end-to-end comparative forensic study found. | Findings protocolaires ne valent pas audit d’interface, serveur ou sync. | Corpus exhaustif et versionnement académique des implémentations actuelles. |
| 27 Incidents historiques | Les audits 2016/18 documentent faiblesses; XMPP historically permits cleartext/server-visible metadata when no E2EE. | — | Primary reports and protocol history. | « incident XMPP » sans service/version n’est pas attribuable à Conversations ou à chaque serveur. | Breaches/compromises d’instances spécifiques et éventuelle exploitation en production. |
| 28 Gouvernance / société / financement | XMPP Standards Foundation gouverne les XEPs; Conversations is maintained by a small independent project; server operators are independent. | Project describes its maintainer/community. | Code, foundation governance, releases, license and hosted-service entity are public. | No single vendor liable for the entire federated network. | Active maintainer counts, revenue, grants, volunteer succession and ownership of each backend. |
| 29 Résistance à la censure | Fédérer/self-hosting permits domain migration; each server can be independently blocked. | XMPP community offers alternate servers/ports. | Protocol documents don’t quantify national filtering; no OONI/censorship tests performed. | Federation helps against provider shutdown but not blocked DNS/IP/ports, app stores or push. | Country-by-country connectivity, bridge support, alternate ports and block history. |
| 30 Maintenance actuelle | Conversations 2.20.4+free appeared on F-Droid 29 Sep 2026; OMEMO XEP 0.9.1 updated Apr 6 2026. | Project shows current releases. | Release pages/F-Droid logs and XEP lifecycle are direct observations. | Protocol maintenance and client maintenance are distinct; server extensions may lag. | Exact deployment adoption, patch latency across chosen server/client and 2.20.4 reproducibility. |

### XMPP / OMEMO — détail des audits

| Organisme / date / version / commit | Durée | Scope / méthode / exclusions | Findings / sévérité / recommandations / correction et retest |
|---|---|---|---|
| ROS, **OMEMO Cryptographic Review**, rapport 1.0, 1 juin 2016; OMEMO v0.4-era; commit cité `cc209af` pour le code de référence. | Effort exact non indiqué dans le PDF. | Analyse crypto de protocole historique et implementation de référence; le client moderne, backend XMPP, UI, appels et versions OMEMO 0.9.x sont hors périmètre. Rapport signé par Sebastian Verschoor, reviewed/approved by Melanie Rieback. | Faiblesse mineure Unknown Key Share/liaison de clé; devices inactifs ou read-only peuvent compromettre forward/future secrecy; lifecycle de signed prekeys et absence de one-time prekeys. Recommandations: rotation après usage, désactivation devices dormants/heartbeat et comparaison fingerprint OOB. Le rapport indique fix du cas de prekey via `cc209af`; aucun retest moderne public établi. Sévérité du finding UKS qualifiée minor; le PDF ne fournit pas un CVSS. |
| ROS, **Smack OMEMO Code Pentest**, v0.2, 10 sept. 2018; Smack v4.3 / range du 5 au 29 août 2018. | Person-days non indiqués; période d’examen publiée. | Pentest code ciblant `Smack-omemo/src/main` et `Smack-omemo-signal/src/main`; pas Conversations actuel, serveur ou clients complets. Méthode revue de code/validation logique et filesystem. | 6 findings au barème PTES de ROS: GSO-001 High, devices inactifs gardent chain keys et affectent PFS; GSO-002 Elevated path traversal via BareJid susceptible de lecture/écriture arbitraire selon app; GSO-003 Elevated stale keys sur device read-only; GSO-004 Elevated signed prekey non renouvelée; GSO-005 Moderate opération fichier non sûre/path traversal; GSO-006 Low MAM/prekey exhaustion DoS. Recommandations: retrait/rotation clés et validation des chemins/IDs. Retest public par finding non établi. Les sévérités ne sont pas CVSS. |
| ROS, **Conversations Android Security Assessment**, 10 mars–7 avril 2025, Android 15 / Pixel 7; build/commit précis non publiés dans rapport. | 5 person-days. | Crystal-box pentest code; SBOM, crypto/TLS/SCRAM/SSDP, Android backup, SQLite et Janus. App Android uniquement; serveur XMPP, autres plateformes, protocole complet, infra/push externe et dépendances exhaustives exclus. | CLN-005 Moderate: validation wildcard TLS hostname imparfaite, recommandation appliquer règles hostname strictes; risque dépend d’un scénario MITM/certificat correspondant et E2EE limite l’impact contenu. CLN-006 Low: vérification CRL/OCSP et SCT manquante, hardening recommandé. Observations: DB SQLite contient JID, mots de passe, messages et clés OMEMO en clair; backup export observé gzip + AES-128-GCM mais PBKDF2-HMAC-SHA1 1 024 itérations, recommandation Argon2. Guava 31.1-jre/CVE-2020-8908/CVE-2023-2976 relevés mais fonctions vulnérables considérées non utilisées dans le scope. Remédiation/retest public post-audit non trouvé. |

**Repositories, mobile, droit, infrastructure, forensics.** Dépôts publics à vérifier avec le service choisi: [Conversations Android](https://github.com/iNPUTmice/Conversations), [Smack](https://github.com/igniterealtime/Smack), [F-Droid build verification](https://verification.f-droid.org/). La fiche F-Droid observée listait Conversations 2.20.4+free à partir du 29 septembre 2026, avec permissions réseau et localisation foreground selon listing; cette investigation n’a pas extrait le manifeste 2.20.4 installé. Les libellés Apple/Google du client n’ont pas été archivés ni vérifiés, et les permissions caméra/micro/contacts/photo varient selon client/OS. Aucune mesure de Firebase/analytics/crash runtime n’a été faite. Pas de cartographie DNS/ASN active: le domaine choisi doit faire l’objet d’une observation passive ciblée. Pas d’étude vérifiée associant **Cellebrite/GrayKey/Magnet + OS/build + Conversations/OMEMO version + date**; la base SQLite du rapport ROS indique les artefacts pertinents, sans constituer une extraction forensic commerciale. Aucun guide LE universel, aucune réquisition nommée avec données réellement remises par le fournisseur retenu. Sources: [XEP-0384 0.9.1](https://xmpp.org/extensions/xep-0384.html), [XEP-0166 Jingle](https://xmpp.org/extensions/xep-0166.html), [Conversation hosting](https://account.conversations.im/), [privacy policy](https://conversations.im/privacy.html), [ROS OMEMO 2016 PDF](https://conversations.im/omemo/audit.pdf), [ROS Conversations 2025 PDF](https://conversations.im/2025_audit_conversations.pdf), [F-Droid listing](https://f-droid.org/packages/eu.siacs.conversations/).

### XMPP / OMEMO — matrice des métadonnées

| Métadonnée | Fournisseur (serveur de compte / groupe / upload) | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ par connexion au serveur; logs/rétention inconnus | POSSIBLE appels ou upload direct | CONFIRMÉ | POSSIBLE données de compte/store distinctes | POSSIBLE chez serveur/ISP sous procédure |
| Téléphone | INCONNU; dépend inscription | POSSIBLE si communiqué hors app | NON ACCESSIBLE PAR DESIGN au seul FAI réseau | POSSIBLE compte store indépendant | POSSIBLE si inscription/facturation existante |
| Email | PROBABLE/CONFIRMÉ selon serveur choisi | POSSIBLE par profil/message | NON ACCESSIBLE PAR DESIGN | POSSIBLE compte store | POSSIBLE chez opérateur si collecté |
| Identifiant | CONFIRMÉ JID, resource/device et roster visibles au serveur | CONFIRMÉ JID communiqué | POSSIBLE par DNS/traffic, pas le JID en général sous TLS | POSSIBLE lien d’installation/store séparé | CONFIRMÉ si obtenu du serveur/contact |
| Graphe social | PROBABLE roster, presence, MUC membership et destinataires | CONFIRMÉ échanges directs/membres visibles | POSSIBLE corrélation d’IP/temps | INCONNU | POSSIBLE depuis serveur/terminaux |
| Timestamps | CONFIRMÉ transport/presence; MAM peut stocker | CONFIRMÉ messages/présence locale | CONFIRMÉ connexion | POSSIBLE événements push | POSSIBLE selon logs conservés |
| Volumes | CONFIRMÉ approximativement si TLS/serveur observe stanzas | CONFIRMÉ tailles/fichiers | CONFIRMÉ octets | POSSIBLE push/usage | POSSIBLE |
| Groupes | CONFIRMÉ au serveur MUC/MIX | CONFIRMÉ aux membres selon salon | POSSIBLE par patterns seulement | NON ACCESSIBLE PAR DESIGN au seul store | POSSIBLE serveur/contact |
| Appareils | CONFIRMÉ OMEMO device IDs/bundles, session clients | PROBABLE liste de devices publiée | POSSIBLE empreinte TLS/réseau | CONFIRMÉ compte store pour appareil | POSSIBLE |
| Push tokens | CONFIRMÉ au service push et probablement app/backend | NON ACCESSIBLE PAR DESIGN au correspondant ordinaire | NON ACCESSIBLE PAR DESIGN | CONFIRMÉ chez FCM/APNs si utilisés | POSSIBLE via ordre au provider |

## Telegram — dossier individuel d’investigation (13 octobre 2026)

**Périmètre.** Telegram est un service cloud centralisé. Sauf indication explicite, « Telegram » ci-dessous signifie Cloud Chats/Groups, et non Secret Chats. Les bots, canaux, mini-apps, Premium et appels ont des frontières et tiers supplémentaires.

| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1 Architecture | Service cloud centralisé, pas de fédération/self-hosting; synchronisation depuis le cloud. | Telegram dit utiliser un réseau/datacenters qu’il possède et exploite; la politique évoque une infrastructure de datacenters tiers loués. | FAQ Telegram dit que le code serveur n’est pas publié et qu’il ne serait pas possible de vérifier le code effectivement exécuté. | Centralisation donne au service une vue sur comptes, routage, cloud chats et communautés publiques. | Composition actuelle des régions/backend, sous-traitants et séparation des rôles techniques. |
| 2 Protocole cryptographique | MTProto 2.0; chiffrement client–serveur pour Cloud Chats, Secret Chats E2EE individuels et liés à des appareils; appels ont mécanisme E2EE selon la doc. | Le fournisseur annonce AES-256 et sécurité des Secret Chats; code protocolaire documenté. | Revue académique du protocole existe (p. ex. analyse formelle publiée 2020); elle ne certifie pas serveurs ni déploiement actuel. | MTProto 2.0 ne rend pas les Cloud Chats E2EE: Telegram peut déchiffrer leur contenu dans son architecture. | Version précise des implémentations en production, paramètres effectifs, audit indépendant complet de 2026 et garanties pour tous formats. |
| 3 Création d’identité | Numéro de téléphone requis à l’ouverture; nom/profil et username facultatifs. | Telegram présente le numéro comme identifiant nécessaire au compte, configurable en visibilité. | Politique courante liste phone number/basic account data. | Numéro lie compte/appareil à l’opérateur télécom même si les contacts ne le voient pas. | Identité réellement vérifiée, noms supplémentaires, paiement Premium et identité des numéros virtuels. |
| 4 Contact discovery | Import/synchronisation de contacts optionnelle; recherche username et ajout par numéro; les paramètres contrôlent visibilité. | Télégram affirme que contacts synchronisés sont chiffrés/stockés pour retrouver les amis et peuvent être effacés. | Étude NDSS de discovery a crawlé 10% des numéros US WhatsApp et 100% Signal et relevé API Telegram révélant données sensibles même pour des numéros non inscrits; paper soumis 2021, versions alors mesurées. | Numéro requis et lookup créent un risque d’énumération, mais résultats historiques ne démontrent pas le taux de vulnérabilité en 2026. | Rate limits et champs visibles après protections actuelles; nouveau test autorisé sur comptes contrôlés nécessaire. |
| 5 Métadonnées serveur | Numéro, IP, appareils/apps, changements de username et autres métadonnées anti-abus peuvent être collectés; politique max 12 mois pour cette catégorie lorsqu’elle est collectée. | La politique limite la rétention de métadonnées citées à 12 mois et décrit cloud chats synchronisés. | Politique versionnée fait foi pour la déclaration, non preuve indépendante de la pratique réelle. | La plateforme peut relier graphe de contacts, groupes, sessions et activité via un compte centralisé. | Logs exacts, champs conservés par région, query/search logs, rétention pour messages et groupes. |
| 6 IP utilisateur | Serveur voit l’IP de connexion; politique liste IP comme métadonnée de sécurité. | Fournisseur dit conservation max 12 mois si IP/device metadata collectée; policy annonce possibilité de remise sous ordre valide. | Cour documents US 2025 cite les réponses Telegram aux autorités depuis septembre 2024 comme généralement numéro + IP du login le plus récent. | VPN/Tor masque l’IP d’accès directe mais ne rompt pas le lien avec numéro/compte et timing. | Historique IP par session, durée de conservation actuelle et éventuels logs non inclus dans 12-month wording. |
| 7 IP au correspondant | Réglage P2P d’appel; autorisé, IP directe peut être communiquée au pair; relay forcé l’évite vis-à-vis du pair. | API Telegram documente P2P et réflecteurs; paramètre « Peer-to-Peer Calls ». | Documentation développeur officielle, pas de pcap effectué. | Relais déplace visibilité au service au lieu de supprimer l’IP. | Quel mode est actif par défaut dans versions et si exceptions/régions changent les candidates. |
| 8 Messages | Cloud chat messages/media/files stored and synced; Secret Chat is E2EE and device-specific. | Telegram affirme stockage cloud chiffré; Secret Chat E2EE. | FAQ reconnaît distinction; formal analysis treats MTProto but no broad audit of current app/service. | Cloud text/messages can be available to backend and legal disclosure, while Secret Chat ciphertext should not. | Exact key custody and internal access controls for cloud chats; moderation/AI processing paths per feature. |
| 9 Groupes | Cloud groups/channels are not Secret Chats and not E2EE; very large communities and bots exist. | Telegram describes end-to-end encryption only Secret Chat; public content moderates under policy. | API/FAQ semantics and server-side searchable community support establish backend access. | Membership, public posts, administrator graph and messages in groups can be visible to server. | Detailed history retention, server-side scanning scope and content deletion behavior per group. |
| 10 Appels | 1:1 voice/video calls, peer-to-peer if setting/network allows, relay otherwise. | Telegram claims call encryption and offers IP-hiding P2P setting. | API docs define P2P and reflectors, but no call cryptanalysis or runtime capture in this phase. | Direct call potentially reveals IP to other party; service relay sees session metadata. | Whether all calls share same cryptographic protocol and metadata logging/retention. |
| 11 Fichiers | Files/media in Cloud Chats are retained/synced through service; Secret Chat media follows device-specific chat semantics. | Telegram calls cloud history accessible from devices without third-party backup. | Official FAQ and policy. | Cloud storage allows service-side access/deletion/moderation and legal process; Secret Chat attachment still endpoint-exposed. | Encryption at rest/key management, exact object regions and retention after delete. |
| 12 Multi-device | Cloud Chats synchronized on many sessions; Secret Chats are per device and lost on logout according to FAQ. | Vendor presents cloud sync as feature and secret chat as device local. | Official FAQ documents difference. | Device list links multiple endpoints to one number and creates correlation data. | Device session metadata, history window, linked web clients version and key distribution details. |
| 13 Push | APNs/FCM or other OS push paths are expected on mobile; notification payload behavior may vary. | Public client source and FAQ describe notifications/settings; privacy docs do not completely characterize all payloads. | No live push capture or current build SDK manifest review completed. | Push provider sees token/time and may see message preview if configured/notification content sent. | Per-platform payload encryption, token linkage/retention, current third-party SDKs and notification preview behavior. |
| 14 Stockage local | Test data from Telegram iOS 11.1.1 was found under `telegram-data/.../postbox/db/db_sqlite` and a media directory; WAL may hold transactions not reflected in the main DB. | Desktop/mobile apps expose local chat data/cache; vendor describes secret chats as device-specific. | Jaeckel et al. (2025) used UFED Touch full-file-system acquisition and source-guided BLOB decoding; they report the database data they analyzed was not encrypted at the app layer. iOS build, UFED version and phone lock state are unreported. [Study PDF](https://dfrws.org/wp-content/uploads/2025/03/Forensic-analysis-of-Telegram-Messeng_2025_Forensic-Science-International-D.pdf). | Shows that endpoint artifacts from that build could be read after extraction; not that locked-device protection is bypassed, nor that deleted data survives. | Current db schema/media/keychain by platform, iOS Data Protection class, lock-state constraints, deletion recovery and present-day UFED/GrayKey/Magnet support. |
| 15 Sauvegardes | Cloud Chats live on Telegram cloud; Secret Chats are not cloud-restored; vendor says default system backups disabled in FAQ. | Telegram says secret chats are not part of backup and phones use cloud sync. | FAQ and client settings; no independent restore test. | A device’s OS backup may differ from in-app cloud storage and build/platform. | Current iCloud/Android backup exclusions, export files, encryption and logout recovery. |
| 16 Analytics / SDK tiers | Product has optional translation; chosen messages may be shared with Google/Microsoft; Telegram claims providers do not retain/use unrelatedly. Voice transcription option documented with provider in product FAQ (exact path/version-dependent). | Policy identifies these optional third-party processing paths. | Public source lets some SDK/client code be reviewed; no installed binary traffic measurement/SDK inventory this phase. | Features selected by a user can expose plaintext beyond Telegram client/server. | Complete analytics/crash SDK list, remote config and actual data payload/retention. |
| 17 Code source | Mobile/desktop clients and TDLib open source; server backend closed; API/protocol docs public. | Telegram offers source and claims client transparency. | GitHub repos are public; FAQ itself states server source cannot prove code execution. | Source allows client review but not confirmation of backend operation. | Every platform/client version current commit and backend code/security controls. |
| 18 Builds reproductibles | Telegram publishes a build verification guide for Android/iOS starting 5.13, calls it experimental. | Vendor says binaries from App Store/Play can be independently compared to GitHub source. | Instructions exist; no reproducible build run or current version comparison done. | Reproducibility is achievable only for exact build/channel/toolchain and does not cover server. | Current verified versions, result per store, differences in encrypted iOS frameworks and signed distribution. |
| 19 Supply chain | Builds require Android SDK/NDK, Docker/toolchains and platform dependencies; signatures/source releases are publicly inspectable. | Telegram calls client apps open source and verifiable. | No independent build artifact comparison completed; published guide explicitly labels workflow experimental. | Third-party libraries, updates/store account and uninspectable backend remain trust surfaces. | Current dependency audit, maintainer activity, signed-tag coverage, SBOM and supply-chain attestations. |
| 20 Infrastructure | Central cloud; policy says for EEA/UK user data stored in leased third-party datacenters in Netherlands, with Telegram owning/operating servers/network. | Official privacy policy. | Policy is source for claim; this review did not query current DNS/ASN/route/hosting logs. | Leased location does not show where all backups, global metadata or support copies live. | Current domains, ASN, CDN, anycast, cloud/region mapping, redundancy and third-party access. |
| 21 Juridiction | Corporate policy names entities/regions; legal reach depends user’s location, processing entity, infrastructure and process. | Telegram identifies operating entities and policies; exact applicant legal entity varies. | Official policy/terms are first-party claims; no contract or cross-border transfer audit. | EEA data storage in NL does not by itself immunize against all external legal process or disclose actual legal control. | Entity for specific account, beneficial control, subprocessors, government-to-government transfer and challenge practice. |
| 22 Demandes policières | Current policy says after valid judicial order confirming a suspect in TOS-violating criminal case, Telegram may disclose IP + phone; transparency available via in-app regional bot. | Policy and legal guide define policy; DOJ affidavit says US requests started being answered around Sep 2024, generally phone + most recent login IP. | DOJ affidavit is sworn case-file description; official transparency bot aggregates count, not data fields per matter. | Cloud-chat content may be technically available under backend control, but statement does not establish routine disclosure of plaintext. | Exact data returned in each US criminal request, contents disclosed, preservation practices, legal rejection rates. |
| 23 Affaires judiciaires connues | Delhi High Court copyright case Neetu Singh v Telegram (2022): Telegram filed a compliance affidavit and sealed data; the Court says it reviewed a chart with administrator names, phone numbers and IP addresses for some channels. Telegram said some channel data was unavailable after statutory retention periods. In Dec. 2023, the plaintiff said the delivered information contained only names and IPs, an unresolved apparent discrepancy. | The policy then published by Telegram described a narrow terrorism-suspect exception; Telegram also argued that Singapore privacy law barred disclosure. Current policy now describes possible phone/IP disclosure under qualifying criminal-case orders. | Delhi High Court orders of 30 Aug. and 24 Nov. 2022 plus follow-up of 1 Dec. 2023; the Nov. order confirms the sealed production and categories the judge observed. [30 Aug. order](https://dhccaseinfo.nic.in/jupload/dhc/PMS/judgement/31-08-2022/PMS30082022SC2822020_121640.pdf), [24 Nov. compliance order](https://indiankanoon.org/doc/119238688/), [1 Dec. 2023 follow-up](https://indiankanoon.org/doc/2402568/). | Confirms judicially ordered provider production and data actually examined by the Court and supplied to plaintiffs’ counsel; the order permitted—but does not prove—police disclosure. A civil copyright case is not a criminal-prosecution return. | Exact values/accounts and complete field set remain sealed; whether police received the data; criminal-case return fields; ordinary Cloud Chat text supplied in a specific case. |
| 24 Audits | No whole-product independent public audit of current Telegram client+backend located. Academic protocol analyses are not equivalent to product audit. | Telegram says experts are welcome and source/protocol public. | Academic analysis of MTProto 2.0 and client source are independent scrutiny, not release assurance. | Proprietary server makes deployment/data-flow claims harder to verify externally. | Current independent app/backend penetration tests, audit report scope, version/commit, fixes and retest. |
| 25 Vulnérabilités | Client security bugs/third-party advisories may arise; exact currently exploitable findings should be mapped to builds. | Vendor maintains security contact and bug reporting. | No current critical advisory with verified 2026 affected build included in evidence set. | Absence from this search is not evidence of no vulnerabilities. | Complete NVD/GitHub advisory inventory, exploitation evidence and patch rollout. |
| 26 Recherche académique | Work includes MTProto formal analysis, contact discovery/scaling and protocol analyses. | — | [All the Numbers are US (NDSS)](https://www.ndss-symposium.org/ndss-paper/all-the-numbers-are-us-large-scale-abuse-of-contact-discovery-in-mobile-messengers/); protocol formal analysis [arXiv 2012.03141](https://arxiv.org/abs/2012.03141). Findings are scoped/versioned. | Research on an old API/build can motivate tests but not establish current exploitability. | Full systematic research inventory after MTProto 2.0 implementation revisions. |
| 27 Incidents historiques | 2022 disclosure litigation; 2024 policy shift and 2024–25 US data sharing; Durov arrest/intermediary cases concern company/legal context, not cryptographic break. | Telegram publicly describes policy changes. | Court orders, DOJ affidavits and current privacy policy are primary records; press reports contextualize aggregates. | Do not confuse legal data requests with a breach or E2EE failure. | Any unreported breach, security incident or secret-process disclosure. |
| 28 Gouvernance / société / financement | Private centralized company and founder-led governance; no federation. | Company describes mission and management in public materials. | Corporate registries, official legal terms and policy are separate evidence; independent governance structure is limited. | Concentrated service ownership means company policy, executive decisions and jurisdiction matter. | Audited financials, beneficial ownership, controls, independent oversight and staff access. |
| 29 Résistance à la censure | No federation; central domains, app stores, phone/SMS, network endpoints and payment/Premium can be blocked. | Telegram positions itself as censorship resistant and clients support proxies. | Protocol supports MTProto proxies; no systematic current country-by-country OONI test in this phase. | Proxy option may improve connectivity but relay can observe IP/timing and state may block stores/SMS. | Actual blocking rates and stealth effectiveness by country/ISP/build. |
| 30 Maintenance actuelle | Official clients/releases and API docs continue; version varies by store and platform. | Release notes / app pages. | Repositories, current policy and store listings establish active distribution. | Active development does not answer patch latency/security review. | Release-by-release signed commit and reproducible match; exact versions across regions/stores. |

### Telegram — audits, repositories, mobile, forensics et droit

- **Repository/builds:** official Android client [`TelegramOrg/Telegram-Android`](https://github.com/DrKLO/Telegram) and iOS [`TelegramMessenger/Telegram-iOS`](https://github.com/TelegramMessenger/Telegram-iOS) (fork/repository ownership differs by client); [reproducible-build guide](https://core.telegram.org/reproducible-builds) says supported from 5.13 and experimental. It prescribes exact release tag/build matching and APK/IPA comparison. No current build was rebuilt here. GitHub source is not a server audit: the official FAQ explicitly says published server code cannot prove what is running.
- **Activity/dependencies/CI:** repository activity, signed tag reach, current dependency inventory and active maintainer count have not been normalized across Android/iOS/web/desktop in this turn; mark unresolved rather than inferring from stars or commits. Client OSS does not cover Bot API backend, cloud server, moderation or hosted file storage.
- **Mobile:** [Google Play listing](https://play.google.com/store/apps/details?id=org.telegram.messenger) and [Apple listing](https://apps.apple.com/us/app/telegram-messenger/id686449807) expose developer-provided Data Safety / App Privacy disclosures. Those are declaration surfaces; the actual manifests, APK SDK list, runtime analytics/crash traffic, FCM/APNs payload, permissions and contact upload were not independently inspected in this phase. Official FAQ says camera is requested upon user actions and describes source-based check, but that remains vendor explanation until build-specific analysis. No assertion here that Firebase/analytics is absent.
- **Forensics:** a 2025 peer-reviewed DFRWS/FSI paper now documents Cellebrite UFED Touch full-file-system extraction of Telegram iOS **11.1.1** data on iPhone SE/iPhone 7 test devices, followed by decoding of `db_sqlite`, WAL and media. It does **not** report the iOS version, exact UFED build or lock state; it does not demonstrate an unlock bypass, current-build extraction or recovery of deleted data. This replaces the earlier blanket “no versioned tool result found” wording only for this dated test. [PDF](https://dfrws.org/wp-content/uploads/2025/03/Forensic-analysis-of-Telegram-Messeng_2025_Forensic-Science-International-D.pdf). Cloud chat also differs: data may be obtainable via Telegram/backend process rather than device bypass.
- **Law-enforcement evidence ladder:** (i) **technically available**: server-controlled Cloud Chat data, subscriber account and metadata; (ii) **officially declared**: privacy policy allows phone/IP disclosure upon valid order in a qualifying criminal case; privacy policy says metadata may be retained up to 12 months if collected; (iii) **actually documented**: in the 2022 Indian civil copyright case, Telegram filed account-identification data under seal and the Court reviewed a chart listing administrator names, phone numbers and IP addresses for some channels; plaintiffs later said only names/IPs were supplied and some information was unavailable. The record permits disclosure to police but does not establish a police transfer. A 2025 U.S. affidavit says Telegram began responding around Sep 2024 with subscriber details, typically phone number and last-login IP, but this is an agent’s description of current practice, not proof of the exact return in that case. 2024 aggregate transparency counts (900 U.S. cases / 2,253 users) were publicly reported from bot output, not itemized returns. No verified case here establishes that Telegram delivered ordinary Cloud Chat plaintext in a criminal matter. [Delhi HC order 24 Nov. 2022](https://indiankanoon.org/doc/119238688/), [follow-up 1 Dec. 2023](https://indiankanoon.org/doc/2402568/), [DOJ affidavit, filed 31 Jul. 2025](https://www.justice.gov/usao-ndil/media/1409806/dl?inline=).
- **Sources:** [Telegram FAQ](https://telegram.org/faq?setln=en), [privacy](https://telegram.org/privacy), [MTProto](https://core.telegram.org/mtproto), [reproducible builds](https://core.telegram.org/reproducible-builds), [NDSS contact discovery](https://www.ndss-symposium.org/ndss-paper/all-the-numbers-are-us-large-scale-abuse-of-contact-discovery-in-mobile-messengers/), [Delhi High Court order, 30 Aug. 2022](https://dhccaseinfo.nic.in/jupload/dhc/PMS/judgement/31-08-2022/PMS30082022SC2822020_121640.pdf), [Delhi High Court compliance order, 24 Nov. 2022](https://indiankanoon.org/doc/119238688/), [follow-up order, 1 Dec. 2023](https://indiankanoon.org/doc/2402568/), [US DOJ affidavit](https://www.justice.gov/usao-ndil/media/1409806/dl?inline=), [official transparency bot](https://t.me/transparency), [DOJ/US court case archive, Telegram seizure warrant 2026](https://www.justice.gov/usao-dc/media/1437596/dl?inline=).

#### Telegram — matrice des métadonnées

| Métadonnée | Fournisseur Telegram | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ à la connexion; retention policy max 12 months if collected; US legal responses typically last login IP per DOJ affidavit | POSSIBLE appel P2P | CONFIRMÉ | POSSIBLE login/store/network metadata separate | CONFIRMÉ : observée par la Cour pour certains canaux dans la production civile indienne; police effectivement destinataire **NON ÉTABLI** |
| Téléphone | CONFIRMÉ (account registration) | POSSIBLE selon visibility/privacy setting | NON ACCESSIBLE PAR DESIGN to ISP except carrier/SIM records | POSSIBLE account identity | CONFIRMÉ : noms/numéros figurent dans le tableau scellé examiné par la Cour en 2022; remise à la police **NON ÉTABLIE** |
| Email | POSSIBLE (optional/recovery) | POSSIBLE profile | NON ACCESSIBLE PAR DESIGN | CONFIRMÉ Apple/Google account separately | POSSIBLE if registered/account metadata |
| Identifiant | CONFIRMÉ user ID, username changes, device/app metadata | CONFIRMÉ username/profile, groups | POSSIBLE correlation only | POSSIBLE installation account | CONFIRMÉ subscriber/account information if requested |
| Graphe social | PROBABLE cloud contacts/chats/groups/channels/administrators | CONFIRMÉ chats/groups/channel membership | POSSIBLE patterns | NON ACCESSIBLE PAR DESIGN directly from store | POSSIBLE via account records, public channel data, device |
| Timestamps | CONFIRMÉ service processes cloud-chat delivery/session | CONFIRMÉ local message/time | CONFIRMÉ connection/session | POSSIBLE push events | POSSIBLE, scope/retention unknown |
| Volumes | CONFIRMÉ storage/routing sizes, not exact retained logs | CONFIRMÉ content/media size | CONFIRMÉ byte counts | POSSIBLE app activity metrics | POSSIBLE if logs/cloud data retained |
| Groupes | CONFIRMÉ server-maintained Cloud Groups/channels | CONFIRMÉ to members/admins | POSSIBLE by traffic only | NON ACCESSIBLE PAR DESIGN from store alone | POSSIBLE service data/legal process |
| Appareils | CONFIRMÉ sessions/devices/apps metadata | POSSIBLE presence and profile | POSSIBLE fingerprinting | CONFIRMÉ account/device association | POSSIBLE last login/session data |
| Push tokens | PROBABLE/CONFIRMÉ integration-specific backend delivery | NON ACCESSIBLE PAR DESIGN to ordinary contact | NON ACCESSIBLE PAR DESIGN | CONFIRMÉ APNs/FCM token if used | POSSIBLE with provider legal process |

## WhatsApp — dossier individuel d’investigation (13 octobre 2026)

**Périmètre.** WhatsApp Messenger grand public: contenu personnel et appels annoncés E2EE sur le Signal Protocol, mais client/service Meta centralisés et fermés. Business Platform, interactions avec bots/IA, interopérabilité DMA et sauvegardes dépendent de réglages/chemins distincts et ne doivent pas être agrégés sans qualification.

| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1 Architecture | Service centralisé Meta, identification historique par téléphone; serveur distribue ciphertext, identité et metadata; app mobile et appareils liés. | Meta dit que le chiffrement s’applique aux conversations personnelles; politique décrit infrastructure et sous-traitants Meta. | Meta engineering explique l’interopérabilité E2EE appuyée sur Signal Protocol dans l’UE; backend/client complets non ouverts. | La centralité donne à Meta comptes, réseau de delivery, contact-graph signalétique et surfaces de sauvegarde/business même sans message clair. | Cartographie backend actuelle, segmentation par régions, différences exactes interop/bots/Business. |
| 2 Protocole cryptographique | Signal Protocol dérivé, X3DH/PQXDH selon implémentation/version puis Double Ratchet; Sender Keys pour groupes, E2EE media/calls. | WhatsApp affirme E2EE par défaut pour messages et appels personnels, hors frontières produit explicites. | Étude 2026 modélise WhatsApp Web et observe conformité aux modèles symboliques des exécutions capturées; vérifie authentification/confidentialité au niveau modélisé, trouve des différences non documentées au fork libsignal. | Propriété du protocole Signal n’est pas preuve d’équivalence complète à Signal app ni de sécurité de toutes features. | Version précise et algorithmes actifs pour chaque client/device/business/interoperability; audit de backend; détails des differences post-publication. |
| 3 Création d’identité | Numéro de téléphone requis dans flux compte classique; nom/profil facultatif; mécanisme de username pourrait réduire l’exposition à l’échange de numéro dans les nouveaux flux, sans supprimer l’identité du compte. | Politique dit numéro nécessaire pour fournir service et trouver les utilisateurs. | Play listing et help center/Meta policies; pas de test enrollment courant fait. | Une SIM réelle permet corrélation opérateur–compte et numéro facilite enumeration. | Déploiement global des usernames, exigences par nouveau type compte / parent-managed accounts / linked devices. |
| 4 Contact discovery | App propose retrouver contacts via répertoire et phone matching; autorisation OS facultative côté accès local, mais flux précis dépend mode et réglages. | WhatsApp dit utiliser les numéros de contacts pour fournir la fonction et ne pas partager sa liste avec Meta « pour ses propres fins ». | NDSS 2021 paper a crawlé 10% de numéros US; NDSS 2026 a rapporté enumeration de milliards de comptes puis indique issue de rate-limiting corrigée en collaboration. Deux dates distinctes, anciennes mesures ne prouvent pas vulnérabilité courante. | Téléphone requis et availability checks créent une surface OSINT; du hachage seul n’empêche pas lookup des numéros à faible entropie. | Release/endpoint actuel, rate-limit et champs répondus; test contrôlé post-fix, nouveaux usernames et privacy settings. |
| 5 Métadonnées serveur | Compte, téléphone, contacts upload/lookup, appareil, groupe, heure de connexion et données routage; WhatsApp dit ne pas garder un registre complet de qui parle à qui en routine. | Politique: aucune conservation normale des messages remis et des journaux de transaction; les logs targeted peuvent être collectés sur ordre PRTT valide. | Government guide en français détaille les informations de base et collecte prospective; Meta transparency fournit demandes par région/catégorie, pas trace complète des données livrées dans chaque cas. | E2EE ne chiffre pas identité, destinataire, horaires, group membership, IP de connexion ou logs légalement ciblés. | Journaux internes actuels, logs de routage/rétention par feature, volumes et audience analytics. |
| 6 IP utilisateur | Service voit connexions/IP; une PRTT peut déclencher collecte targeted d’IP/timestamps/type/sens de communication d’un compte. | Guide LE indique ces données pour un ordre valable; politique générale décrit traitements IP/diagnostics. | U.S. affidavit 2025 associe les PRTT records WhatsApp d’un compte à groupe/senders/volume/communications; underlying response not public. | VPN déplace observation IP vers VPN; numéro/compte reste un pivot. | Historique IP passif retenu et durée; relation entre service logs ordinaires et collecte prospective. |
| 7 IP au correspondant | Appel 1:1 peut utiliser P2P; “Protect IP address in calls” impose relais; appels groupe sont relayés d’après Meta. | Meta dit que le relais cache l’adresse IP au pair tandis que média reste chiffré E2EE. | Meta Engineering annonce déploiement du réglage et architecture; aucune capture faite ici. | En mode direct le pair peut obtenir l’IP, en relayé l’opérateur du relay voit les IP/temps. | Candidats ICE effectifs, exceptions et état par défaut selon versions/regions; comportement lors d’appel link/interop. |
| 8 Messages | Messages personnels 1:1 E2EE par défaut; service détient ciphertext pour remise temporaire, supprime quand livré selon LE guide; messages non remis supprimés après 30 jours. | WhatsApp/Meta disent ne pouvoir lire les messages privés E2EE. | Model-monitoring paper 2026 fournit une preuve indépendante partielle sur WhatsApp Web protocol execution, pas une inspection de backend ou binaire store-wide. | Un participant, endpoint, backup non chiffré, report par receveur ou notification peut exposer texte malgré E2EE réseau. | Les messages interactifs/IA, business, report flags, endpoints de backup/interoperability et exceptions spécifiques. |
| 9 Groupes | Group messages E2EE; serveur gère delivery et group membership. | Meta dit que groupes privés restent chiffrés; metadata de qui participe ou quand peut être nécessaire au service. | Research on Sender Keys and formal-model study; PRTT case records establish messages/group metadata available under law. | Participants peuvent exfiltrer/capturer et group key update/compromise changes trust. | Exact group sender-key implementation/version and membership metadata retention/server log fields. |
| 10 Appels | E2EE audio/video; WebRTC network can be direct or relay; group defaults relay. | Meta claims E2EE calls; Protect IP setting for 1:1. | Protocol design & help docs; no independent live packet capture/current call audit in this phase. | Media secrecy against server does not hide IP/timing/network endpoints. | Call signaling logs, selective recording/transcription, interoperable and business call paths. |
| 11 Fichiers | Attachments sent in encrypted message; client encrypts media before server delivery; business/cloud integrations can introduce other endpoints. | Help center says photos, docs, voice notes and location are E2EE between personal senders/recipients. | Signal-derived design public; no app binary/traffic test of all attachment formats. | Metadata such as sizes/time and media local preview/caches survive; recipient can save. | Thumbnail/index/key handling, AI scan boundaries, CDN retention, link/interop exceptions. |
| 12 Multi-device | Linked devices including web/desktop and companion devices; independent session keys/device synchronization. | WhatsApp says linked devices E2EE and account’s primary phone not required continuously. | 2026 academic monitor targeted WhatsApp Web specifically, finding model-compatible observed executions and differences from upstream libsignal. | Every linked device is an added endpoint/key and compromise surface; account management metadata exposes device set. | Cross-device history sync details, credential rotation, app version floor and sync artifact protections. |
| 13 Push | Mobile push via OS provider; push may signal new message and app fetches ciphertext; exact payload may vary. | Vendor says notifications do not reveal private content unless user preview settings expose locally. | No live APNs/FCM payload capture in this phase; current SDKs not inspected. | Apple/Google see token, app/device/time and network signals; lock-screen preview is user-controlled risk. | Push payload keys, token linkage/retention, SDK versions and regional behavior. |
| 14 Stockage local | App keeps database, encrypted message/attachment data or decrypted presentation/cache as needed; client/OS keys and linked devices matter. | WhatsApp relies on OS/device security; E2EE is transport/session guarantee. | Public forensic literature covers legacy Android/iOS builds; no contemporary commercial-tool test (versioned) established here. | Unlocked device/app process can access plaintext; disk encryption/device passcode governs seized locked case. | Current database schema/keychain/Keystore behavior and media cache by platform/version. |
| 15 Sauvegardes | Optional E2EE cloud backup exists; enable with password/key/passkey-style recovery as product supports; ordinary iCloud/Google backup historically has different trust. | WhatsApp says E2EE backup prevents WhatsApp/Apple/Google from accessing the backup if feature properly enabled. | Help/Meta engineering docs; not independently tested by restoring current builds. | Backup ciphertext protection does not repair plaintext already held by an unlocked endpoint; weak password permits offline guessing if format allows. | Default state per user/platform, passkey rollout details, metadata retained by cloud provider and recovery workflow. |
| 16 Analytics / SDK tiers | Meta apps integrate analytics/diagnostic/product and business services; store labels list categories. | Meta says private messages/contacts are not shared with Meta for its own purposes while some metadata/device/business service info is shared within Meta companies. | Apple App Privacy / Google Play Data Safety are developer-submitted disclosures; Google explains labels depend developer disclosure and have scope exceptions. No current binary SDK/runtime measurement made. | Labels, policy and code manifest can differ; neither store label alone establishes no collection. | Exact embedded SDK inventory, crash logs, attribution signals, data-flow per feature and actual Play vs App Store behavior. |
| 17 Code source | WhatsApp client app/backend closed source; upstream Signal `libsignal` is public but WhatsApp uses a fork. | Meta describes Signal Protocol implementation and certain open-source dependencies. | 2026 paper reports previously undocumented differences between WhatsApp fork and libsignal; no source of client fork available for public review. | “Uses Signal Protocol” does not imply client parity; auditor/runtime evidence increases confidence only on studied Web execution. | Current precise fork version, proprietary verification code and code review scope. |
| 18 Builds reproductibles | No official public reproducible client build process for WhatsApp established. | Store publisher does not claim public exact-match reproducible builds in sources reviewed. | Closed app plus platform signatures means independent source-to-binary comparison unavailable in this evidence set. | Store attestation/signing identifies publisher/channel, not source semantics. | Internal build provenance, SBOM, in-toto/SLSA attestations, independent reproducibility program. |
| 19 Supply chain | Meta maintains closed clients/backend; Android/iOS app stores and FCM/APNs are dependencies; libsignal-derived implementation not equivalent to public libsignal. | Meta bug bounty/advisories demonstrate external report path. | 2026 CVEs listed below show recent patched client issues; academic 2026 found fork differences. | Signed update from legitimate vendor can still change implementation; store policy and dependency operations matter. | Full SBOM, active maintainers, signed release/tag, dependency pinning, patch latency by platform. |
| 20 Infrastructure OSINT | Central global Meta infrastructure, CDN/object/region services and push; no per-domain DNS/ASN snapshot captured. | Meta says globally distributed infrastructure / service providers. | Public infrastructure docs and transparency only; this investigation did not query passive DNS or ASN history. | Anycast/CDN/region routing cannot be inferred from brand; WhatsApp server may be separate by feature. | Exact current hostnames, ASN, regions, transit/cloud vendors, routing, retention and backup copies. |
| 21 Juridiction | WhatsApp LLC serves much of world; WhatsApp Ireland Limited handles EEA/UK region per corporate policies; data transfers subject to applicable law. | Policy and LE guide identify entity/address and processing; Meta global companies support service. | Court files show US PRTT process; official policies are first party. | Entity and physical storage do not alone dictate which legal process applies. | Case-specific data controller, cross-border transfer route, US/Irish objection and retention orders. |
| 22 Demandes policières | LE guide distinguishes preservation/basic account/subscriber/PRTT/emergency and says messages normally not retained once delivered; legal targeted collection may begin prospectively. | Meta says it reviews and responds to valid legal processes, may challenge overbroad requests. | Official guide includes examples of available data; official transparency report counts requests and compliance. | Authorities can obtain metadata even where they cannot request server-held E2EE plaintext; endpoint and cloud backup are separate routes. | Per-case actual fields, preservation details, emergency edge cases, content from report messages. |
| 23 Affaires judiciaires connues | U.S. v. [case 2:25-mj-30673-DUTY / 25-CR-?] 2025 amended complaint cites court-authorized PRTT records for account, group, senders and ~125 communications, range/timestamps and media types. | — | DOJ complaint is a primary affidavit but underlying company return is not attached. It demonstrates actual use of WhatsApp-returned records at least for communication metadata/group activity; some content wording's provenance cannot be independently separated from other investigative sources. | Count/media-type and participant/timing data were available from records; do not claim WhatsApp gave plaintext body based only on this affidavit. | Exact fields provided by WhatsApp, prospective vs retrospective interval and whether every excerpted message body came from handset/recipient/other source. |
| 24 Audits | No publicly established end-to-end independent audit of all current messenger app/backend/crypto found. Trail of Bits’ 2025 report covers **Private Processing for AI**, not ordinary WhatsApp conversations: 28 findings, 16 resolved, 4 partial, 8 open in that review’s final fix-status table. | Meta commissioned the scoped review; report also records its own point-in-time positive observations about enclave processing and post-processing retention. | Full [ToB report with fix review](https://github.com/trailofbits/publications/blob/master/reviews/2025-08-meta-whatsapp-privateprocessing-securityreview.pdf); independent runtime/model research is separate and scoped. | Findings about Private Processing cannot be translated into a weakness or assurance for the main WhatsApp chat protocol; they do document insider/TEE, logs, metadata, supply-chain and transparency risks in the AI feature. | Current rollout/version, whether open findings were fixed after Aug 2025, and audit coverage of ordinary messaging/backend. |
| 25 Vulnérabilités | Meta advisories 2026: CVE-2026-23866 (AI rich-response arbitrary URL/custom scheme handling; iOS <=2.26.15.72 / Android <=2.26.7.10 listed range) and CVE-2026-23863 Windows attachment filename NUL spoofing before 2.3000.1032164386.258709. | Meta says no evidence of in-the-wild exploitation for these advisories. | Advisory primary source; current deployed versions/rollout not independently checked. | CVSS severity should be combined with prereqs/surface/patch status, not read as observed exploitation. | All current advisories and exact OS/app version mapping outside 2026 list; uptake on installed devices. |
| 26 Recherche académique | Contact-discovery abuse, Sender Keys, runtime monitoring of Signal/WhatsApp Web, and targeted prekey depletion research. | — | NDSS 2026 paper reports past number enumeration and says rate-limiting issue was resolved collaboratively; WOOT 2025 Prekey Pogo found targeted depletion risk affecting PFS/availability in tested builds; 2026 runtime paper verifies scoped model. | Research findings are scoped/time-specific; no proof of ongoing exploit after fix or E2EE general break. | Current prevalence/remediation, production code mapping, device/app versions on current channel. |
| 27 Incidents historiques | Number/contact enumeration, 2021 Facebook phone-number scrape, legal PRTT data and software CVEs are documented; these are distinct incident classes. | Meta says PRTT and platform protections evolve. | Peer-reviewed/publication and court/advisory evidence. | Historical phone exposure may enable social engineering even if account protections later change. | Breach notification details and whether current contact discovery has additional undisclosed issues. |
| 28 Gouvernance / société / financement | Owned by Meta Platforms, publicly traded parent with advertising business; WhatsApp operating entities under Meta. | Meta says WhatsApp retains boundaries on private messages while shares service/security/business-related data. | Meta privacy policy, SEC/court/regulator filings and EU regulatory actions provide external records; no internal governance audit here. | Commercial incentives and integration are relevant to non-message data; they do not by themselves prove E2EE deception. | Internal access controls, employee review policy, cross-company joins and product roadmap. |
| 29 Résistance à la censure | Central domains, app stores, SIM/SMS enrollment, Meta infra and push are blocking points; no federation. | Meta does not position WhatsApp as a circumvention tool. | No systematic country/ISP blocking study in this phase. | VPN can route around some IP blocks but not registration dependency, store removal or targeted lawful block. | Country-by-country service availability, registration bypass, protocol obfuscation. |
| 30 Maintenance actuelle | Official security advisories/releases continue through 2026; multiple client/platform channels. | Meta states supported versions and security patches via app stores. | 2026 advisory dates and app stores establish active maintenance; no installed-device patch survey. | Users on old versions remain exposed until store rollout/adoption. | Release cadence, percent patched, Android sideload/business versions and post-patch test. |

### WhatsApp — audits et recherche approfondis

| Organisme / date / version / commit | Durée | Scope / méthodologie / exclusions | Findings / sévérité / recommandations / correction / retest |
|---|---|---|---|
| Moustafa Said, Aurora Naska, Kevin Morio, Robert Künnemann, **From Specs to Apps: Verifying and Monitoring Models of Signal and WhatsApp**, preprint 10 sept. 2026 / révision 12 sept.; WhatsApp Web, commit/build de production exact non publié dans abstract. | 3 person-weeks pour modèle WhatsApp Web, instrumentation, fuzzing/expériences selon le papier. | Instrumentation du runtime réseau/cryptographic components; modèles Tamarin compatibles; validation observée vs modèle symbolique, abstraction dépend d’extraction fidèle des événements. Pas audit du serveur, de toutes plateformes, du binaire mobile ou preuve mathématique du déploiement global. | Observed traces conform to model under stated abstraction; vérifie auth/secrecy des components core; découvre différences précédemment non documentées entre libsignal upstream et fork WhatsApp. Ce n’est pas une vulnérabilité démontrée ni une rupture E2EE. Publication [arXiv 2609.11882](https://arxiv.org/abs/2609.11882); corrections/roadmap non identifiées dans le preprint résumé; retest inconnu. |
| **Trail of Bits, Meta WhatsApp Private Processing Security Assessment with Fix Review**, rapport final daté **26 août 2025** ([PDF canonique](https://github.com/trailofbits/publications/blob/master/reviews/2025-08-meta-whatsapp-privateprocessing-securityreview.pdf); l’index ToB le classe août 2025, 12 engineer-weeks). Six consultants; travail 3–28 févr. 2025 : 2 engineer-weeks design/threat model, 6 infra, 4 code; fix reviews 23–25 avr. et 22–23 mai (5 engineer-days au total), confirmation partielle additionnelle le 12 août. | Le PDF ne donne pas de commit/SHA client pour les cibles; il couvre clients iOS/Android, libs C++, TEE server libs/infrastructure, transparency. Les identifiants de correction `D…` sont des références internes de changement Meta, pas des Git commit publics. | Revue design + infra déployée dans le réseau interne Meta + code; accès sources, docs, hôtes/guests confidential-computing déployés. Révision manuelle, statique/dynamique, fuzzing interfaces host/TEE, vérification dépendances/CVE. Exclusions : canaux physiques/attaques de tampering non testés; extensions proposées non implémentées; Fastly OHTTP relay, Cloudflare transparency monitor, firmwares/drivers AMD/NVIDIA, analyse complète stack Llama exclus. C’est Private Processing/IA, **pas** un audit de WhatsApp Messenger ou Signal Protocol dans son ensemble. | Résumé et inventaire finding par finding ci-dessous. Le rapport dit avoir validé, pour l’implémentation observée, le traitement dans les enclaves et l’absence d’indication de conservation post-traitement; cela reste un résultat temporel/scopé, avec résiduels et exclusions explicités. [PDF ToB](https://github.com/trailofbits/publications/blob/master/reviews/2025-08-meta-whatsapp-privateprocessing-securityreview.pdf), [article ToB sur l’audit](https://blog.trailofbits.com/2026/04/07/what-we-learned-about-tee-security-from-auditing-whatsapps-private-inference/). |
| Meta Bug Bounty, CVE-2026-23866 et CVE-2026-23863, avis 2026. | Non publié. | Triage incident et correctif par éditeur, pas audit indépendant; versions affectées indiquées par plateforme. | iOS/Android AI rich responses pouvaient traiter une URL arbitraire et custom URL scheme; Windows NUL byte attachment extension mismatch pouvait afficher un type mais exécuter un fichier. Meta dit ne pas voir exploitation in the wild. Corrections: after listed version thresholds; aucune vérification indépendante du retest/rollout. [Advisories 2026](https://www.whatsapp.com/security/advisories/2026). |

#### Trail of Bits — inventaire des 28 findings Private Processing

Sévérités et états repris des tableaux de synthèse et de fix review du PDF. Les `D…` sont les identifiants de changements Meta rapportés par ToB, **pas des hashes de commit vérifiables publiquement**. « Résolu » désigne la conclusion du fix review, sans démontrer la version déployée en octobre 2026.

| ID / finding | Sévérité | Recommandation ou mitigation indiquée | Fix review / statut rapporté |
|---|---|---|---|
| WAPI-1 ACS key rotation peut dé-anonymiser | Medium | Rendre la configuration ACS cohérente entre clients (clé racine embarquée, dérivation à attributs, ou cache Fastly); signer et vérifier les preuves; éviter une rotation qui réduit l’anonymat. | Résolu : configuration/keys via Fastly et clé publique Meta codée côté client (`D71515247`, `D71773542`). |
| WAPI-2 ACS peut fournir des tokens aveuglés invalides | Medium | Fournir une preuve d’équivalence discrete-log et la vérifier au client. | Résolu : preuves servies et vérifiées iOS/Android (`D69822878`, `D69829118`, `D70011790`). |
| WAPI-3 rotation OHTTP peut dé-anonymiser | Medium | Configurer les clés HPKE de manière cohérente et authentifiée; utiliser un cache de configuration fiable. | Résolu selon rapport : clé/config via Fastly et signature Meta (`D71515247`, `D71773542`). |
| WAPI-4 ciblage géographique des clients | Informational | Séparer privilèges de changements clients/logs des privilèges de routage PoP→datacenter; randomiser durées/réutilisation des tokens pour réduire la corrélation. | **Non résolu** dans le tableau final; Meta dit évaluer les mitigations à l’échelle/steady-state. |
| WAPI-5 données sensibles d’inférence loguées côté client | Low | Détecter les formes de tokens et réponses sensibles dans les logs; alerter équipe produit et sécurité; contrôles dans hooks/CI. | **Non résolu**; Meta répond par principes généraux de code review/minimisation, sans correctif spécifique vérifié. |
| WAPI-6 attributs suivis permettant ciblage | Informational | Minimiser collecte/rétention d’attributs identifiants de temps, lieu, latence et usage; expliciter le risque dans le threat model interne. | **Non résolu**; Meta dit ne pas avoir observé de preuve que ces logs brisent la non-targetability. |
| WAPI-7 attestation sans fraîcheur | High | Lier l’attestation à un nonce client/TLS par session. | Résolu : `client_random` inclus et comparé (`D74603096`). |
| WAPI-8 TCB SEV-SNP non vérifié contre certificat VCEK | High | Vérifier les niveaux bootloader/TEE/SNP/microcode signés dans les extensions X.509 VCEK, pas uniquement les champs reportés par firmware. | Résolu : validation des champs VCEK étendue (`D69724419`). |
| WAPI-9 politiques Guest SEV-SNP non toutes appliquées | Informational | Imposer flags de politique guest stricts (debug, migration, SMT et protections disponibles). | **Partiel** : SMT désactivé au niveau hôte, contrôles client MIGRATE_MA/DEBUG; les autres flags n’étaient pas supportés par le kernel/KVM testé. Confirmation partielle datée du 12 août 2025. |
| WAPI-10 attestation non liée aux machines Meta | High | Restreindre l’attestation aux hôtes réellement contrôlés par Meta, par CA/provisionnement ou allowlist hardware ID vérifiée. | **Partiel** : enrollment trust-on-first-use et publication de digest VCEK; ToB dit que provenance/intégrité hardware ne sont pas entièrement garanties (`D73932854`, `D73827419`). |
| WAPI-11 TLS 1.2 et suites permissives | Informational | Passer à TLS 1.3; planifier le post-quantique pour résister au SNDL. | Résolu pour TLS : clients RA-TLS n’utilisent que TLS 1.3 (`D69931378`, `D70004593`); PQ traité séparément en WAPI-12. |
| WAPI-12 vulnérabilité SNDL post-quantique | Informational | Plan public de transition vers TLS et primitives PQ-hardened. | **Non résolu** au rapport final; Meta dit travailler à la transition et juge l’attaque moins probable avec ses protections d’anonymat. |
| WAPI-13 injection de variables d’environnement dans CVM | High | Parser/allowlister les variables et valider/quoting stricts, plutôt qu’accepter un fichier arbitraire. | Résolu : allowlist fixe et valeurs validées (longueur max 50, charset borné) (`D72583676`, `D72805813`). |
| WAPI-14 usage rsync non sûr | Informational | Éviter dereference symlink; `--safe-links`; séparateurs de fichiers NUL; éviter glob imprévisible. | Résolu : copie temporaire sans `-L`, fichiers séparés par NUL et glob supprimé (`D69858604`, `D71784233`). |
| WAPI-15 modèles chargés comme pickle | Informational | Utiliser un format sérialisé moins dangereux / chargement poids seuls, ou retirer le chargement pickle de production. | Résolu : migration de la pile vers vLLM, les `torch.load` concernés ne sont plus exécutés en production (`D70305933`). |
| WAPI-16 taille de sortie LLM non masquée | Low | Padding de réponses (p. ex. Padmé) et plafond de longueur pour réduire fuite par taille chiffrée. | **Non résolu**; Meta reconnaît l’impact faible mais conserve un travail d’endurcissement. |
| WAPI-17 hyperviseur injecte des ACPI SSDT | High | Lier les tables ACPI à la mesure de boot et vérifier leur digest dans CVM. | Résolu : bootloader Stage0 custom, SSDT incluse dans measurement/digest attendu (`D73804542`, `D73937575`). ToB recommande de rendre QEMU command/artifacts publics. |
| WAPI-18 absence de reproductibilité des images CVM | High | Construire artefacts depuis sources versionnées, contrôler binaires mis en cache et publier provenance/digests reproductibles. | **Partiel** : dépendances contrôlées/manifests et sources plus ouvertes, mais images pas encore pleinement reproductibles; audit tiers depuis source seule impossible. |
| WAPI-19 digests artifacts privés ne préservent pas l’arborescence | Low | Hacher un paquet qui préserve structure/noms/metadata (ex. tar) et ajouter un namespace de domaine. | **Non résolu** dans le rapport final. |
| WAPI-20 namespace de transparence non imposé | High | Épingler namespaces attendus dans client et orchestrateur; lier le type TEE au certificat. | Résolu sur la protection principale par restriction de namespaces (`D70708182`); ToB recommande encore de distinguer explicitement le type TEE via SAN. |
| WAPI-21 artifacts de transparence sans expiration | Informational | Version minimale côté client et durée de preuve limitée. | Résolu : expiration selon type; image CVM expirait après 3 semaines (`D70813884`). |
| WAPI-22 ports I/O inutiles accessibles à hyperviseur malveillant | Medium | Allowlist explicite des ports; ne pas exposer le chargement firmware/blobs non mesurés. | Résolu : allowlist noyau pour ports, hors mode debug (`D72410416`). |
| WAPI-23 échec vérification transparency peut être silencieux | Low | Faire dépendre le démarrage CVM de la vérification et tester chemin négatif. | Résolu : dépendance systemd; startup échoue si preuve invalide (`D70925617`). |
| WAPI-24 versions Mbed TLS/OpenSSL avec CVE | Informational | Mettre à jour les dépendances et suivre les divulgations, notamment side-channel local. | **Partiel** : Mbed TLS 3.6.0 sur composants concernés; OpenSSL restait non corrigé à la revue (Meta invoquait coût perf/absence d’exploit concret). |
| WAPI-25 protections Spectre absentes | Informational | Ajouter les flags noyau recommandés et désactiver SMT lorsque requis. | Résolu selon rapport : options mitigations ajoutées au kernel CVM (`D70646271`). |
| WAPI-26 fuite tokenizer LLM via cache side-channel | Informational | Réduire SMT; tokenizer avec accès mémoire moins dépendants du secret/hash rerandomisé, ou tokenisation côté client; étude dédiée. | **Non résolu**; aucun side-channel n’a été exécuté pendant l’audit; risque et capacité réelle restent à mesurer. |
| WAPI-27 transparency dépend d’une partie centrale honnête | Informational | Lier cryptographiquement les epochs et utiliser un journal append-only/Merkle vérifiable. | **Non résolu**; Meta envisage une vérification cryptographique dans une itération future. |
| WAPI-28 LLM GPU sans vérification attestation NVIDIA | High | Vérifier preuves GPU/attestation avant chargement du service. | Résolu : utilitaire NVIDIA `nvtrust` vérifie rapports avant lancement (`D70814218`); RIM encore embarqués dans build, provisioning/révocation runtime futurs. |

**Résultat agrégé ToB au 26 août 2025 :** 16 résolus, 4 partiellement résolus, 8 non résolus. Aucun des statuts n’atteste l’état déployé aujourd’hui. Les quatre « partiels » sont WAPI-9, -10, -18, -24. Les huit ouverts sont -4, -5, -6, -12, -16, -19, -26, -27. Cet audit ne doit pas servir à caractériser le chiffrement des chats ordinaires : il concerne une fonctionnalité distincte de traitement IA sous TEE.

**Recherche vulnérabilité protocol-level.** *Prekey Pogo* (USENIX WOOT 2025) décrit une attaque ciblée d’épuisement des one-time prekeys d’un appareil WhatsApp pouvant dégrader PFS pour certains messages et disponibilité/confidentialité sous conditions; cela n’équivaut pas à déchiffrer toutes conversations. [Papier WOOT](https://www.usenix.org/system/files/woot25-moratti.pdf). *Hey There! You Are Using WhatsApp* (NDSS 2026) a énuméré >100 M numéros/heure dans un test avant correction, réutilisation/prekeys multi-comptes observées; version mise à jour déclare que les auteurs ont collaboré et rate-limit sous-jacent corrigé. [NDSS 2026](https://www.ndss-symposium.org/ndss-paper/hey-there-you-are-using-whatsapp-enumerating-three-billion-accounts-for-security-and-privacy/). Ne pas présenter ces anciens états comme vulnérabilité active le 13-10-2026.

**Mobile/privacy labels.** [Apple listing](https://apps.apple.com/us/app/whatsapp-messenger/id310633997) et [Google Play Data Safety](https://play.google.com/store/apps/details?id=com.whatsapp) sont les déclarations éditeur. Le Help Center répond à l’étiquette Apple et affirme que contact list n’est pas partagée avec Meta pour ses propres fins; Apple regroupe certaines catégories sous “linked to you”; Google documente que les développeurs soumettent les catégories et certaines collectes transitoires/non stockées sont hors-scope. Ce n’est pas une analyse binaire. Manifestes, permissions actuelles, Firebase/APNs/SDK list, camera/mic/location/photos permissions, diagnostics, contact discovery payload et crash runtime n’ont pas été mesurés dans cette phase. Sources: [WhatsApp privacy label explainer](https://faq.whatsapp.com/1455645071585052/?locale=fr_FR), [Google Data Safety methodology](https://support.google.com/googleplay/answer/11416267?hl=en), [Apple developer privacy disclosure](https://developer.apple.com/app-store/user-privacy-and-data-use/).

**Repos/builds/infrastructure.** Main client binaries, server and official apps are proprietary; protocol lineage is documented but no source-to-store deterministic build is provided. `signalapp/libsignal` is not WhatsApp’s complete fork. Full dependency inventory, SBOM, signature verification and active maintainer count of private repositories unavailable. Meta global infrastructure and partner disclosures are public at high level; exact WhatsApp domain DNS/ASN/CDN/regions were not passively snapshotted here. Store labels and policy cannot establish exact FCM/APNs payload or analytics SDK behavior.

**Forensics and legal evidence.** No reproducible literature result in this dossier names **Cellebrite UFED/PA, GrayKey or Magnet + exact OS version + WhatsApp build + extraction date** and proves present capability. Public forensic papers mostly concern older builds/OS; must be treated as historical, not current. The 2025 U.S. affidavit/court-file excerpt for 2:25-mj-30673-DUTY reports court-authorized PRTT records associated with an account, group, participants, approximate 125 communications and transmission date/type data. The actual underlying company return is not public; the complaint’s message excerpts could derive from other sources. The government guide confirms prospective metadata collection, while saying normal operations do not retain messages after delivery or transaction logs; this is not contradictory if the PRTT order triggers targeted collection. It does **not** establish that WhatsApp handed over E2EE plaintext in that matter. [WhatsApp LE guide FR](https://faq.whatsapp.com/444002211197967/?category=5245250&locale=fr_FR), [DOJ case record](https://www.justice.gov/usao-edmi/media/1416961/dl).

#### WhatsApp — matrice des métadonnées

| Métadonnée | Fournisseur Meta / WhatsApp | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ service sees; PRTT can collect prospective targeted IP/time | POSSIBLE direct 1:1 call | CONFIRMÉ network sees | POSSIBLE store/push/IP account separate | CONFIRMÉ where valid PRTT/record exists; exact log interval unknown |
| Téléphone | CONFIRMÉ in legacy account; usernames may alter contact presentation | CONFIRMÉ or POSSIBLE by privacy/new username feature | CONFIRMÉ carrier knows subscriber/SIM, not app chat | POSSIBLE by store account separate | POSSIBLE/CONFIRMÉ as subscriber info if request |
| Email | POSSIBLE account/support/backup/business | POSSIBLE profile | NON ACCESSIBLE PAR DESIGN | CONFIRMÉ store identity if supplied | POSSIBLE if retained/account-linked |
| Identifiant | CONFIRMÉ account/device IDs and phone | CONFIRMÉ profile/name/number as shown | POSSIBLE traffic correlation | CONFIRMÉ app install/device/account signals | CONFIRMÉ basic subscriber records and device info when available |
| Graphe social | PROBABLE contacts/delivery/groups; WhatsApp says not routinely logging who everyone messages | CONFIRMÉ conversation participants | POSSIBLE traffic correlation | NON ACCESSIBLE PAR DESIGN except app-store usage | CONFIRMÉ in documented PRTT case for a group/participants |
| Timestamps | PROBABLE delivery/session metadata; targeted PRTT confirms time | CONFIRMÉ message/call time | CONFIRMÉ IP session/time | POSSIBLE push/install events | CONFIRMÉ targeted PRTT time; normal history retention varies |
| Volumes | POSSIBLE/PROBABLE store/metadata; exact fields unknown | CONFIRMÉ message counts/media size | CONFIRMÉ bytes | POSSIBLE app diagnostics | PROBABLE from record types; underlying disclosure not fully public |
| Groupes | CONFIRMÉ membership/routing data may be returned; policy/account info can include groups | CONFIRMÉ group members | POSSIBLE only traffic patterns | NON ACCESSIBLE PAR DESIGN by store | CONFIRMÉ group data referenced in 2025 PRTT affidavit |
| Appareils | CONFIRMÉ linked devices / device type | POSSIBLE linked sessions/status | POSSIBLE fingerprint | CONFIRMÉ store device association | POSSIBLE device/basic account fields under process |
| Push tokens | PROBABLE APNs/FCM and Meta delivery backend | NON ACCESSIBLE PAR DESIGN to peer | NON ACCESSIBLE PAR DESIGN | CONFIRMÉ token holder provider, exact token retention unknown | POSSIBLE via Meta/provider process |

## Discord — dossier individuel d’investigation (13 octobre 2026)

**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](https://github.com/trailofbits/publications/blob/master/reviews/2024-08-discord-dave-protocol-designreview.pdf)). 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](https://github.com/trailofbits/publications/blob/master/reviews/2024-09-discord-dave-protocol-codereview.pdf)). 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](https://github.com/trailofbits/publications/blob/master/reviews/2025-06-discord-e2eewebassembly-securityreview.pdf)). 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](https://github.com/discord/dave-protocol) and [discord/libdave](https://github.com/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](https://apps.apple.com/gb/app/discord-talk-play-hang-out/id985746746), [Google Play listing](https://play.google.com/store/apps/details?id=com.discord) and [Discord policy](https://discord.com/privacy) 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](https://www.justice.gov/usao-wdwa/media/1464546/dl), [Discord law enforcement guide](https://discord.com/safety/360044157931-working-with-law-enforcement), [transparency hub](https://discord.com/safety-transparency), [DAVE protocol](https://daveprotocol.com/), [Cloudflare edge engineering post](https://discord.com/blog/how-we-moved-discord-voice-to-the-edge).

#### 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 |
| Email | 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](https://xmpp.org/extensions/xep-0384.html). |
| TM2 fournisseur compromis | 🟡 | Chiffrement limite contenu historique; serveur peut altérer devices/bundles, bloquer, observer MAM et metadata; OMEMO XEP + [ROS 2016](https://conversations.im/omemo/audit.pdf). |
| 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](https://xmpp.org/extensions/xep-0384.html). |
| TM4 ISP/Wi-Fi | 🟠 | TLS masque corps mais pas IP, timing/volume; ICE/Jingle direct peut exposer IP pair; [XEP-0166](https://xmpp.org/extensions/xep-0166.html). |
| TM5 passif multi-points | 🟠 | Serveur fédéré, push, upload/TURN et FAI peuvent corréler metadata; pas de mixnet documenté; [XEPs/extensions](https://xmpp.org/extensions/xep-0384.html). |
| 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](https://xmpp.org/extensions/xep-0384.html). |
| TM8 doxxer OSINT | 🟡 | JID stable/domain/pseudo et profils corrélables mais pas téléphone/e-mail universel requis; [Conversations account model](https://conversations.im/). |
| 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](https://account.conversations.im/). |
| TM10 enquête sophistiquée | 🟠 | Combinaison serveur/ISP/push/contact/endpoint contourne protections de contenu; [ROS 2025 storage findings](https://conversations.im/2025_audit_conversations.pdf). |
| 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](https://conversations.im/2025_audit_conversations.pdf). |
| TM12 appareil déverrouillé | 🔴 | Messages/keys en SQLite en clair dans le build audité; endpoint chargé livre le contenu; [rapport ROS 2025](https://conversations.im/2025_audit_conversations.pdf). |
| 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](https://verification.f-droid.org/). |
| TM15 censure | 🟡 | Federation/self-hosted domain helps migration; DNS/IP/ports/stores/push can be blocked; [XMPP federation docs](https://xmpp.org/about/technology-overview/). |

### 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](https://telegram.org/faq?setln=en). |
| TM2 fournisseur compromis | 🔴 | Cloud chat content and account data remain in centralized service; Secret Chats reduce this only per-device; [privacy/FAQ](https://telegram.org/privacy). |
| TM3 fournisseur malveillant | 🔴 | Server closed and no federation; Cloud Chat depends on provider; Secret Chat is a narrower exception; [FAQ](https://telegram.org/faq?setln=en). |
| TM4 ISP/Wi-Fi | 🟠 | TLS/MTProto transport masks content in transit, not source IP/time/volume; [MTProto](https://core.telegram.org/mtproto). |
| TM5 multi-points | 🟠 | Central cloud, push, ISP and direct-call ICE create metadata correlation points; [privacy policy](https://telegram.org/privacy). |
| 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](https://telegram.org/faq?setln=en). |
| TM8 OSINT | 🟠 | Required phone and username-change metadata plus lookup surface enable correlation; rate-limits need current testing; [privacy](https://telegram.org/privacy), [NDSS discovery study](https://www.ndss-symposium.org/ndss-paper/all-the-numbers-are-us-large-scale-abuse-of-contact-discovery-in-mobile-messengers/). |
| TM9 demande légale | 🟠 | Policy allows phone/IP disclosure after qualifying order; India court case directed account/channel operator data; [policy](https://telegram.org/privacy), [Delhi HC](https://dhccaseinfo.nic.in/jupload/dhc/PMS/judgement/31-08-2022/PMS30082022SC2822020_121640.pdf). |
| 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](https://www.justice.gov/usao-ndil/media/1409806/dl?inline=). |
| 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](https://dfrws.org/wp-content/uploads/2025/03/Forensic-analysis-of-Telegram-Messeng_2025_Forensic-Science-International-D.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](https://core.telegram.org/reproducible-builds). |
| TM15 censorship | 🟠 | Central service can be blocked despite proxies; proxy is another trust/routing point; [API/FAQ](https://core.telegram.org/api). |

### 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](https://www.whatsapp.com/legal/privacy-policy). |
| TM2 fournisseur compromis | 🟡 | E2EE reduces server content access; service controls delivery/client-update and E2EE backups are optional; [E2EE backup](https://faq.whatsapp.com/490592613091019). |
| TM3 fournisseur malveillant | 🟡 | E2EE and safety-code verification help, but closed client/fork and updates remain trust boundary; [2026 model study](https://arxiv.org/abs/2609.11882). |
| 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](https://engineering.fb.com/2023/11/08/security/whatsapp-calls-enhancing-security/). |
| 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](https://www.ndss-symposium.org/ndss-paper/hey-there-you-are-using-whatsapp-enumerating-three-billion-accounts-for-security-and-privacy/). |
| TM9 demande légale | 🟠 | Court records show PRTT group participants/timing/types; exact WhatsApp return not public; [DOJ affidavit](https://www.justice.gov/usao-edmi/media/1416961/dl), [LE guide](https://faq.whatsapp.com/444002211197967/?category=5245250&locale=fr_FR). |
| 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](https://www.whatsapp.com/security/advisories/2026). |
| 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](https://discord.com/blog/every-voice-and-video-call-on-discord-is-now-end-to-end-encrypted). |
| TM2 fournisseur compromis | 🔴 | Central service stores/readable text, memberships and files; actual records returned in 2026 case; [DOJ complaint](https://www.justice.gov/usao-wdwa/media/1464546/dl). |
| TM3 fournisseur malveillant | 🔴 | Operator can access text and control signal paths; CVE shows DAVE depends on trusted signaling integrity; [GHSA](https://github.com/advisories/GHSA-3q99-x36r-rchh). |
| TM4 ISP/Wi-Fi | 🟠 | TLS/media encryption hides payload but network sees IP/time/volume; Cloudflare and SFU are observable points; [edge post](https://discord.com/blog/how-we-moved-discord-voice-to-the-edge). |
| 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](https://discord.com/privacy). |
| TM9 demande légale | 🔴 | 2026 warrant obtained historical DMs absent from device; [DOJ case](https://www.justice.gov/usao-wdwa/media/1464546/dl). |
| 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](https://github.com/advisories/GHSA-3q99-x36r-rchh). |
| 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.

## Matrice transversale TM1–TM15 — synthèse 18 solutions

**Lecture:** ces 15 lignes reprennent les mêmes scénarios TM1–TM15 définis dans la mission originale. Chaque case donne uniquement la notation normalisée; la justification courte, ses limites et les liens de preuve figurent dans le tableau TM1–TM15 propre au produit immédiatement après son dossier (pour XMPP, Telegram, WhatsApp, Discord ci-dessus; pour les 13 autres, plus haut). Cette grille est une vue croisée, pas un ordre de préférence. Les cases ne sont pas des résultats de laboratoire; certaines décrivent une inférence d’architecture explicitement signalée dans les fiches.

Colonnes abrégées: **Sig** Signal; **Sx** SimpleX; **Olv** Olvid; **Ses** Session; **Thr** Threema; **Cwt** Cwtch; **Bri** Briar; **Jam** Jami; **Tox** Tox/qTox; **Mx** Matrix/Element; **XMPP** XMPP/OMEMO; **TG** Telegram; **WA** WhatsApp; **Dis** Discord; **Wir** Wire; **Delta** Delta Chat; **RR** Ricochet Refresh; **Status** Status App/Waku.

| Menace | Sig | Sx | Olv | Ses | Thr | Cwt | Bri | Jam | Tox | Mx | XMPP | TG | WA | Dis | Wir | Delta | RR | Status |
|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| TM1 fournisseur curieux | 🟡 | 🟡 | 🟠 | 🟡 | 🟡 | ✅ | ✅ | 🟡 | 🟡 | 🟡 | 🟡 | 🔴 | 🟡 | 🔴 | 🟠 | 🟡 | ✅ | 🟠 |
| TM2 fournisseur compromis | 🟡 | 🟡 | 🟡 | 🟡 | 🟡 | ✅ | ✅ | 🟡 | 🟡 | 🟡 | 🟡 | 🔴 | 🟡 | 🔴 | 🟡 | 🟡 | 🟡 | 🟡 |
| TM3 fournisseur malveillant | 🟡 | 🟡 | 🟡 | 🟠 | 🟡 | ✅ | 🟡 | 🟡 | 🟠 | 🟡 | 🟡 | 🔴 | 🟡 | 🔴 | 🟡 | 🟡 | 🟡 | 🟡 |
| TM4 ISP / Wi-Fi | 🟠 | 🟠 | 🟠 | 🟡 | 🟠 | 🟡 | 🟡 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟡 | 🟠 |
| TM5 observation passive multi-points | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟡 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟡 | 🟠 |
| TM6 adversaire global passif | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🟠 | 🟠 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🟠 |
| TM7 contact malveillant | 🟡 | 🟡 | 🟡 | 🟠 | 🟠 | 🟡 | 🟡 | 🟠 | 🔴 | 🟠 | 🟠 | 🟠 | 🟠 | 🔴 | 🟠 | 🟠 | 🟡 | 🟠 |
| TM8 harceleur / doxxer OSINT | 🟡 | 🟡 | 🟡 | 🟡 | 🟡 | 🟡 | 🟡 | 🟡 | 🟡 | 🟡 | 🟡 | 🟠 | 🟡 | 🟠 | 🟡 | 🟡 | 🟡 | 🟠 |
| TM9 demande judiciaire classique | 🟡 | 🟡 | 🟡 | 🟡 | 🟠 | ✅ | ✅ | 🟡 | 🟡 | 🟠 | 🟠 | 🟠 | 🟠 | 🔴 | 🟠 | 🟡 | 🟡 | 🟠 |
| TM10 enquête policière sophistiquée | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟡 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🔴 | 🟠 | 🟠 | 🟠 | 🟠 |
| TM11 appareil verrouillé saisi | ❓ | ❓ | ❓ | ❓ | ❓ | 🟡 | 🟡 | 🟡 | 🟡 | ❓ | ❓ | ❓ | ❓ | ❓ | ❓ | ❓ | 🟡 | ❓ |
| TM12 appareil déverrouillé | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 |
| TM13 spyware ciblé | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 |
| TM14 supply-chain compromise | 🟡 | 🟡 | 🟠 | 🟠 | 🟠 | 🟡 | 🟡 | 🟡 | 🟡 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟡 | 🟡 | 🟠 |
| TM15 censure étatique | 🟠 | 🟡 | 🟠 | 🟠 | 🟠 | 🟡 | 🟡 | 🟡 | 🟡 | 🟡 | 🟡 | 🟠 | 🟠 | 🟠 | 🟠 | 🟠 | 🟡 | 🟠 |

**Citations / source de la grille:** les faits différentiels proviennent de la politique/protocole/étude/cas liés dans chaque justification détaillée; pour Olvid, l’élément déterminant nouvellement intégré est l’[analyse formelle 2026 lue intégralement](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf); pour Discord, l’actualité déterminante est le [dossier DOJ 2026](https://www.justice.gov/usao-wdwa/media/1464546/dl) et [CVE DAVE](https://github.com/advisories/GHSA-3q99-x36r-rchh); pour WhatsApp, le [guide forces de l’ordre](https://faq.whatsapp.com/444002211197967/?category=5245250&locale=fr_FR), la [recherche NDSS 2026](https://www.ndss-symposium.org/ndss-paper/hey-there-you-are-using-whatsapp-enumerating-three-billion-accounts-for-security-and-privacy/) et l’étude [runtime 2026](https://arxiv.org/abs/2609.11882); Telegram: [policy](https://telegram.org/privacy) et [Delhi HC](https://dhccaseinfo.nic.in/jupload/dhc/PMS/judgement/31-08-2022/PMS30082022SC2822020_121640.pdf); XMPP: [XEP-0384](https://xmpp.org/extensions/xep-0384.html) et [ROS 2025](https://conversations.im/2025_audit_conversations.pdf). Pour les autres services, voir leurs cases-source inline dans leurs tables TM. Un scoring qui change de threat-model, version ou réglage doit être recalculé.

## Contradictions matérielles, inconnues restantes et essais nécessaires

### Contradictions et distinctions à conserver

| Sujet | Déclaration / résultat apparent | Preuve indépendante ou limite | Conclusion non excessive |
|---|---|---|---|
| « E2EE » pour une plateforme | Telegram, WhatsApp et Discord utilisent tous le terme de chiffrement mais la portée n’est pas la même. | Telegram Cloud Chats ne sont pas E2EE; WhatsApp conversations personnelles standard sont E2EE mais sauvegarde/Business/AI/interop changent le périmètre; Discord DAVE ne chiffre que média A/V éligible, pas ses textes. | Comparer uniquement le même type de flux; un badge E2EE n’est pas un attribut global du compte. |
| Audit WhatsApp « sécurité de WhatsApp » | Le rapport ToB 2025 porte sur WhatsApp Private Processing, un service IA/Tee, et non sur les chats ordinaires ou le protocole Signal. | Le PDF liste 28 findings et fixe explicitement les limites: certains relais/services tiers, firmwares, side channels physiques et stack Llama hors scope. | Créditer l’audit pour ce périmètre seulement; ne l’utiliser ni comme audit complet du messager ni comme preuve que les chats E2EE sont compromis. |
| Telegram — politique pénale vs production civile 2022 | La politique actuelle et l’affidavit DOJ 2025 décrivent les remises de données d’abonné en réponse à une procédure pénale qualifiante; le dossier indien de 2022 porte sur une ordonnance civile de copyright et une production sous scellés. | Les bases juridiques, destinataires et catégories demandées diffèrent. Le dossier 2022 confirme une production, mais ne révèle ni les valeurs sous scellés ni un transfert effectif à la police; le DOJ décrit une pratique générale, non le retour propre au dossier Woodsley. | Ne pas comparer ces affaires comme une série longitudinale homogène ni inférer que tous les ordres produisent les mêmes champs. Aucune remise de Cloud Chat plaintext établie par les cas cités ici. |
| Telegram — périmètre de la divulgation judiciaire indienne | L’ordonnance du 24 nov. 2022 dit que le tableau remis et examiné par le juge contenait, pour certains canaux, noms d’administrateurs, numéros et IP; la demanderesse a déclaré en déc. 2023 n’avoir obtenu que noms et IP. L’ordonnance précise que la transmission aux autorités était permise. | Le retour et les identifiants concrets restent sous scellés; les décisions ne disent pas qu’une police a effectivement reçu les éléments. L’écart entre la description judiciaire et celle de la demanderesse n’est pas résolu. | Compter comme production fournisseur effectivement constatée par la Cour et aux demandeurs, mais pas comme remise policière prouvée. Les champs disponibles semblent varier par compte/canal; ne pas généraliser à tous les abonnés. [Delhi HC, 24 nov. 2022](https://indiankanoon.org/doc/119238688/), [1 déc. 2023](https://indiankanoon.org/doc/2402568/). |
| WhatsApp absence de journaux vs PRTT | Guide dit pas de transaction logs de routine après livraison; même guide décrit collecte prospective targeted sous PRTT; 2025 affidavit s’appuie sur PRTT records. | Retention ordinary vs targeted order is different scope/time. Underlying WhatsApp return is not public; message body provenance in affidavit ambiguous. | Metadata group/participant/timing was demonstrably available; do not claim provider delivered plaintext bodies without underlying return. |
| Discord E2EE vs warrant | Discord affirme calls audio/video E2EE; la plainte DOJ 2026 expose DM historiques remises par Discord. | Different data classes. DAVE doesn’t cover text DMs. | Actual plaintext DMs were returned from service; does not contradict DAVE for eligible media. |
| DAVE “audited” vs new CVE | Vendor public material calls DAVE audited; Oct 2026 advisory records a signaling-validation bug in `libdave`. | Three ToB PDFs (design 2023 report body / index Aug 2024, code 2024, WASM 2025) were read. Their commits/scopes differ; code report fix-review prose says 12 resolved/1 partial/2 unresolved while its status table and detailed remediation say all 15 resolved. CVE patch version is `libdave` v1.2.0, but deployment mapping is unknown. | “Audited” never means bug-free or current. No conclusion on exploitation in the field, deployed affected versions, or complete rollout until client versions and independent retest are established. |
| Dates des audits DAVE | ToB publications index lists design review under Aug. 2024; the PDF’s cover says 16 Nov. 2023 and its project timeline says work Sep. 25–Oct. 6, 2023, with fix review Nov. 9. | Both are primary artifacts from ToB; the index page has no explanation for the discrepancy. | Keep both dates visible; do not invent a republication/versioning explanation. |
| SimpleX — dates et portée des audits | L’annonce 2024 situe la revue en juillet 2024 et dit « over a week »; le PDF ToB donne un engagement du 24 au 28 juin, une semaine-personne, rapport résumé du 12 août. Le même PDF décrit uniquement une revue de conception/documentation. | Les commits-cibles et le calendrier viennent du PDF; l’annonce est une source fournisseur. En 2022, le rapport ToB distingue explicitement le noyau audité, les exclusions et un fix review indépendant. | Garder la discordance juin/juillet ouverte; ne pas présenter la revue 2024 comme audit du client mobile/backend ni confondre les corrections revendiquées en v6.1 avec un retest. Pour 2022, le finding mémoire était encore non résolu lors du fix review de janvier 2023; son état 2026 reste à établir. |
| Olvid — « anonymat » et métadonnées | Le discours grand public présente Olvid comme anonyme et dit que le serveur ne sait pas qui parle à qui; le papier indépendant 2026 formalise/observe des clés publiques destinataires, tailles et timing visibles côté serveur. | Les auteurs rapportent que l’équipe distingue son usage non technique d’anonymat (serveur ne connaîtrait pas nom/contact) et reconnaît les clés publiques comme identifiants. L’analyse concerne un modèle et le code Android v3.6, pas mesure de journaux en production. | Le désaccord est en partie sémantique, mais le routage par clé publique et les métadonnées taille/timing sont explicitement établis par le papier. Cela invalide l’interprétation forte d’un serveur sans observables sociaux, sans prouver l’identité civile universelle. [PDF](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf) |
| Matrix.org — « ne pas profiler » vs journaux/analytics | Notice effective 25-08-2025 dit que matrix.org ne profile pas les utilisateurs, mais aussi qu’il collecte des IP (≤180 jours), device/session IDs, user-agent, temps, et mesure l’usage du compte de façon agrégée à partir du MXID via PostHog. | La notice présente PostHog comme agrégé et orienté performance, et ses logs IP comme anti-abus/diagnostic/mesure de trafic. | C’est une politique primaire, non une capture indépendante de télémétrie ni vérification de purge. | Pas nécessairement une contradiction stricte: « profilage » peut signifier profil publicitaire ou inférence comportementale; les champs déclarés établissent néanmoins une observabilité compte/session plus riche que « aucune métadonnée ». [Notice](https://matrix.org/legal/privacy-notice/) |
| OMEMO interoperability/security | Current XEP version 0.9.1 is still Experimental; older ROS audit discovered lifecycle/device issues; Conversations current build advances beyond last F-Droid verified build. | Different artifacts and years. 2025 client audit exposed local storage issues rather than an OMEMO protocol break. | Protocol encryption and storage/build status must be assessed separately. |
| App privacy labels vs runtime | App Store / Data Safety disclose broad categories and provider claims, but current binaries not captured. | Google explicitly describes Data Safety as developer-provided and Apple labels are also based on developer-submitted privacy data. | Labels are useful disclosures, not independent network captures or verified manifest inventories. |
| forensic legacy writeups vs current devices | Older Android/iOS forensic papers show artifacts in older versions. | No modern report pinned by tool + OS + app version + date for several services; no commercial forensic extraction run in this task. | A historical extraction is not evidence of current GrayKey/Cellebrite capability; unknown remains ❓. |
| source-open vs reproducible | Telegram client open/build instructions, Conversations F-Droid builds, DAVE library and many decentralized projects publish source. | No current rebuilt hash check for each store artifact; server/API/CI/update chains may be closed. | Source availability is not proof that binaries running on user device match published source. |
| Olvid — étiquettes de région TURN | FAQ Olvid associe `ap.turn.olvid.io` à « North Virginia » et `us.turn.olvid.io` à « Singapore »; le DNS de ce contrôle donne respectivement `13.214.105.6` et `3.93.110.92`. | Le fichier IP ranges officiel AWS attribue ces IP aux network border groups `ap-southeast-1` et `us-east-1`; RIPEstat attribue les annonces aux réseaux Amazon. La troisième adresse `eu.turn` concorde avec `eu-west-3`. | Discordance documentation/routage daté, non preuve de lieu de traitement ou de stockage; faire confirmer au fournisseur et répéter depuis d’autres résolveurs/régions avant toute conclusion forte. [FAQ Olvid](https://www.olvid.io/faq/for-administrators/), [AWS IP ranges](https://ip-ranges.amazonaws.com/ip-ranges.json), [régions AWS](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html) |

### Inconnues de haut impact non remplacées par des suppositions

1. **DNS/ASN/passive OSINT:** aucun inventaire complet horodaté n’existe encore pour les domaines de production des 17 services. Des snapshots A/AAAA et BGP/ASN sont consignés pour Matrix/Element, Signal, quelques presets SimpleX, Wire, Jami, Olvid et deux endpoints Delta Chat. Une bibliothèque tierce cite `api.threema.ch/identity` comme endpoint de répertoire, mais la résolution DNS n’a pas abouti ici et cela ne confirme pas l’API de chat courante; aucun mapping complet des domaines Threema n’est établi. Ce sont des résolutions du moment, non du passive DNS historique; elles ne prouvent pas le propriétaire contractuel, l’origin, la région des données, la rétention ou le trafic réel. Pour Signal, `turn3.voip.signal.org` n’a pas retourné d’adresse au résolveur testé; cela n’établit pas son indisponibilité générale. Discord a une migration Cloudflare voice annoncée par l’ingénierie, pas une cartographie complète. Aucun scan ni intrusion.
2. **Actual mobile binaries:** no current APK/IPA from all 17 finalistes was decoded for manifest, entitlements, SDK/trackers, permission rationale, FCM/APNs payload and live traffic. Store labels are not substitutes. Names like Firebase/Sentry remain UNKNOWN except where directly documented in a cited app/release.
3. **Forensics:** no laboratory device acquisition was run. For many 2026 builds the open record still does not connect Cellebrite/GrayKey/Magnet product+version to a specific OS patch, app build and date. Unknown does not mean impossible or safe.
4. **Law enforcement:** public transparency totals rarely expose exact fields/case ID; an order is not proof a provider complied; a complaint’s quoted chat may originate from a device, witness or service export. In Telegram’s 2022 Indian civil case, compliance and a sealed return were confirmed; the judge describes names, phone numbers and IPs for some channels, while the plaintiff later described receiving only names and IPs. The actual values remain sealed and a police transfer is not established. WhatsApp PRTT case documents usable metadata but not the full provider export.
5. **Current remediation:** CVE/advisory does not prove uptake. Need installed client build hashes, library linkage, version floors, rollout per OS/app store and independent retest—especially Discord DAVE CVE, WhatsApp 2026 CVEs and contact-discovery mitigations.
6. **Audit completeness:** findings may be private, reports may be unavailable, or one engagement may exclude clients/servers. “No audit found” is a bounded search result, not “never audited.” The three public Discord DAVE/WebAssembly PDFs, both public SimpleX ToB PDFs, and Olvid’s two CSPN RTEs plus the full 2026 formal-analysis paper were read for versions, scope, findings/results and remediation evidence. Discord’s code report contains a contradictory fix-status summary; SimpleX 2024 has no public fix log, while its 2022 fix review leaves the memory finding unresolved. Olvid’s academic paper is not a product audit; current corrective commits/releases and retest remain unknown. Independent current-build retesting, other private audits, deployed commits and platform-by-platform rollout remain unknown.
7. **Legal/regulatory conditions:** this dossier maps documented technical and public case facts, not advice on admissibility, lawful basis or legal challenge in a specific country. Jurisdiction and process need case-specific counsel.

### Expériences qui permettraient de fermer les inconnues

| Test contrôlé | Données nécessaires / procédure | Résultat attendu / garde-fou |
|---|---|---|
| Contact discovery | Deux comptes contrôlés par équipe, permission contacts on/off, exact Android/iOS build; observe DNS/API and rate-limit with fixed small list. | Enumerated fields, lookup behavior, salt/blinding and rate limits; no querying third-party numbers. |
| Push/privacy SDK | Rebuilt/test devices with test accounts, APNs/FCM instrumentation, certificate pinning-aware test proxy only on owned devices; compare notification variants locked/unlocked. | Token linkage, payload plaintext vs wake signal, SDK endpoints and crash telemetry. |
| Direct-call IP | Two controlled endpoints on separate networks; test default/relay toggles and group modes; packet capture at owned interfaces/STUN/TURN. | Whether counterpart, relay, ISP receive public IP, timing, candidate list; record app/build/OS. |
| Storage/backup | Clean Android/iOS/desktop snapshots across locked/unlocked states; export and restore; note app version, OS patch, backup options. | DB paths, key stores, caches, notifications, media/EXIF and delete retention; no inference from older extraction tools. |
| Discord DAVE patch | Verify current app linked libdave version/hash; run protocol test against crafted unrecognized-member Welcome in authorized test harness; retest all platform releases. | Whether production clients reject attack; does not target public Discord users or live calls. |
| WhatsApp Private Processing follow-up | Obtain current client/CVM versions and transparency artifacts; verify open WAPI findings against deployed configuration, test nonce freshness, guest-policy enforcement, artifact expiry/namespace/fail-closed startup, output-size effects, dependency CVEs, reproducible build claims, and client logging on controlled test accounts. Evaluate tokenizer cache side-channel only on owned test hardware. | Distinguish an observed regression test from vendor status; never use real users’ AI requests or target live production traffic. |
| Telegram/WhatsApp message boundaries | Controlled Cloud/Secret WhatsApp backups, Telegram Cloud/Secret chats, business/AI and interop paths; packet and local artifact capture. | Precisely which plaintext is processed by server/third party and what metadata persists. No third-party accounts. |
| XMPP release and OMEMO | Conversations 2.20.4+free exact F-Droid/Play artifacts; reproducible build; current OMEMO pair/grouproster clients on disposable server; simulate malicious PEP device-list change. | Match binary/source, trust prompt behavior, public bundle metadata, fallback and revocation. |
| Legal data reproducibility | Obtain complete unsealed provider-return appendices/FOIA records and transparency methodology; pair with affidavit timestamps. | Separate order scope from exact disclosed columns and source provenance of message bodies. |
| Passive infrastructure inventory | Resolve official documented hostnames using public DNS/CT/passive DNS/RDAP/BGP, timestamp every result and limit to public observations. | Domain/IP/ASN/CDN/regions; preserve source/time/TTL, avoid port scans or requests that exceed ordinary web/DNS use. |
| Reproducible builds and release signing | For each exact store version, fetch official source/tag and binary, independent clean build, compare digests/signatures and map SDK SBOM. | Positive/negative reproducibility result per platform/version; no universal claim based on one variant. |

### Sources primaires — nouvelles fiches

- XMPP: [XEP-0384 OMEMO](https://xmpp.org/extensions/xep-0384.html), [XEP-0166 Jingle](https://xmpp.org/extensions/xep-0166.html), [Conversations privacy](https://conversations.im/privacy.html), [F-Droid app/version](https://f-droid.org/packages/eu.siacs.conversations/), [F-Droid verification](https://verification.f-droid.org/), [ROS 2016 OMEMO](https://conversations.im/omemo/audit.pdf), [ROS 2025 client audit](https://conversations.im/2025_audit_conversations.pdf).
- Telegram: [FAQ/source disclosure](https://telegram.org/faq?setln=en), [privacy policy](https://telegram.org/privacy), [MTProto](https://core.telegram.org/mtproto), [reproducible builds](https://core.telegram.org/reproducible-builds), [Delhi High Court 2022 order](https://dhccaseinfo.nic.in/jupload/dhc/PMS/judgement/31-08-2022/PMS30082022SC2822020_121640.pdf), [US DOJ 2025 affidavit](https://www.justice.gov/usao-ndil/media/1409806/dl?inline=), [official transparency bot](https://t.me/transparency).
- WhatsApp: [privacy policy](https://www.whatsapp.com/legal/privacy-policy), [law enforcement guide](https://faq.whatsapp.com/444002211197967/?category=5245250&locale=fr_FR), [Meta government request reports](https://transparency.meta.com/data/government-data-requests/), [CVE advisories 2026](https://www.whatsapp.com/security/advisories/2026), [Trail of Bits Private Processing audit + fix review, 2025](https://github.com/trailofbits/publications/blob/master/reviews/2025-08-meta-whatsapp-privateprocessing-securityreview.pdf), [Signal interoperability technical post](https://engineering.fb.com/2024/03/06/security/whatsapp-messenger-messaging-interoperability-eu/), [model monitoring research 2026](https://arxiv.org/abs/2609.11882), [NDSS 2026 enumeration paper](https://www.ndss-symposium.org/ndss-paper/hey-there-you-are-using-whatsapp-enumerating-three-billion-accounts-for-security-and-privacy/), [2025 DOJ PRTT case file](https://www.justice.gov/usao-edmi/media/1416961/dl).
- Discord: [privacy](https://discord.com/privacy), [law enforcement guide](https://discord.com/safety/360044157931-working-with-law-enforcement), [transparency](https://discord.com/safety-transparency), [DAVE protocol/code](https://daveprotocol.com/), [GitHub advisory CVE-2026-104480](https://github.com/advisories/GHSA-3q99-x36r-rchh), [CVE patch commit](https://github.com/discord/libdave/commit/9686fbaea864aa19f0675e486672b6a77811b6a1), [Trail of Bits reports index](https://github.com/trailofbits/publications), [DOJ case file 2026](https://www.justice.gov/usao-wdwa/media/1464546/dl), [Discord voice infrastructure](https://discord.com/blog/how-we-moved-discord-voice-to-the-edge).
- SimpleX: [Trail of Bits 2022 assessment and fix review](https://github.com/trailofbits/publications/blob/master/reviews/SimpleXChat.pdf), [SimpleX 2022 response/v4.2](https://simplex.chat/blog/20221108-simplex-chat-v4.2-security-audit-new-website.html), [Trail of Bits 2024 design review summary](https://github.com/simplex-chat/simplex-chat/blob/stable/docs/SimpleX_Design_Review_2024_Summary_Report_12_08_2024.pdf), [SimpleX 2024 findings and v6.1 response](https://simplex.chat/blog/20241014-simplex-network-v6-1-security-review-better-calls-user-experience.html), [2026 crowdfunding/audit statement](https://simplex.chat/blog/20260819-simplex-chat-crowdfunding.html), [security policy](https://github.com/simplex-chat/simplex-chat/security).
- Olvid: [ePrint 2026/1622](https://eprint.iacr.org/2026/1622), [PDF intégral des auteurs](https://www.cryptojedi.org/papers/olvidgbu-20260805.pdf), [artefact Tamarin/PoC DOI 10.5281/zenodo.20647106](https://doi.org/10.5281/zenodo.20647106), [dépôt client Android](https://github.com/olvid-io/olvid-android), [dépôt backend public](https://github.com/olvid-io/olvid-aws-server), [certificat iOS CSPN et RTE](https://www.olvid.io/assets/documents/Synacktiv-Olvid-CSPN-Olvid-0.8.2-RTE-public.pdf), [certificat Android CSPN et RTE](https://olvid.io/assets/documents/Synacktiv-Olvid-CSPN_Olvid-0.9.2-RTE-v1.2.pdf).

**Limite de phase:** ce registre fournit une base de preuves et des incertitudes explicites pour les 17 services; il ne désigne pas de gagnant et ne constitue pas la Phase 3.

## Dossier de preuve complémentaire — Status App / Waku (au 14 octobre 2026)

**Périmètre.** Status est ajouté comme candidat supplémentaire parce que l’app combine identité sans téléphone/e-mail, messagerie, portefeuille et réseau Waku/Logos. Cette fiche ne l’ajoute pas rétroactivement aux 17 colonnes de la matrice de base et ne constitue pas un classement. Status a publié une annonce de version 2.39 le 8 octobre 2026; le dépôt GitHub consulté affichait encore 2.39.0-rc.7 et 2.38.2. Distinguer annonce produit, tag public et version effectivement servie sur chaque store. [Annonce 2.39](https://status.app/blog/status-2-39-reliable-message-delivery-new-token-swap-bridge-browser-incognito-mode-robinhood-chain-and-more-2), [releases](https://github.com/status-im/status-app/releases).

| # / catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | Clients pair-à-pair Waku/Logos Delivery; rôles Store, Bootstrap, Filter et Light Push. Status exploite une flotte de nœuds. | Messagerie décentralisée, relais ne lisant pas le plaintext. | Docs Waku/Status publiques; propre page d’infrastructure confirme la flotte et les métadonnées vues selon les rôles. | P2P réduit la dépendance à un serveur unique, sans supprimer opérateurs, nœuds gérés, stores et push. | Part du trafic 2.39 passant par la flotte Status et topologie réellement utilisée. |
| 2. Protocole cryptographique | Spec 1:1 2026 autorise échanges de clés Waku X3DH ou Noise; spec Communities indique X3DH et ratchet de groupe re-clé lors des changements de membres. Payloads signés. | Status dit que Double Ratchet protège les chats directs, groupes et communautés. | Spécifications publiques; aucune analyse indépendante actuelle du protocole complet Status 2.39 identifiée. | Le protocole dépend du type de chat/version; le claim Double Ratchet ne prouve pas une suite uniforme. | Algorithme réellement choisi par conversation, paramètres, ratchet et mapping au code stable. |
| 3. Création d’identité | Profil créé à partir de clés générées localement, sans téléphone/e-mail obligatoires; clés chat et wallet dérivées du matériel maître. | Identité cryptographique pseudonyme et clés locales. | Le code client est public; spécifications décrivent les identifiants publics. | Clé stable, pseudonyme/ENS ou adresse wallet rendent l’identité corrélable si réutilisés. | Lien exact profil↔wallet dans les builds courants et séparation effective des sous-clés. |
| 4. Contact discovery | QR/chat key et ENS sont documentés; échange hors bande sert à initialiser et vérifier l’identité. | Pas d’annuaire central ni de PII obligatoire. | Spec 1:1 de février 2026 décrit QR/Identicon, vérification d’identité et échange asynchrone des clés. | QR réduit l’exposition d’un annuaire; recherche ENS/profil public accroît la corrélabilité. | Découverte optionnelle par contacts externes et endpoints/permissions associés. |
| 5. Métadonnées serveur | Store voit IP et content-topics; Status annonce 15 jours de logs IP Store/Bootstrap. Filter voit IP et topics; Light Push voit IP/topic. | Contenu chiffré et aucun identifiant de correspondant en transport. | Déclaration primaire Status d’octobre 2026 reconnaît IP↔topic; telemetry opt-in retient jusqu’à 30 jours des métriques. | Un opérateur peut inférer intérêts, présence, cadence et topics sans nécessairement lire le plaintext ou connaître le nom civil. | Logs réellement produits, retention par nœud et mapping du topic par version. |
| 6. IP utilisateur | IP visible du nœud Waku contacté; certaines IP annoncées loguées 15 jours. VPN/Tor proposés comme masquage possible. | Status annonce des options futures de nœuds de confiance/autohébergés. | Aucune capture réseau de 2.39 faite. | VPN/Tor déplace l’IP visible vers le point de sortie, sans masquer forcément topic/timing. | Fuites DNS/IPv6 et nœuds exacts choisis par session. |
| 7. IP exposée au correspondant | Waku utilise relay/Store; exception documentée: CHS legacy via BitTorrent crée des connexions IP directes entre membres. | Status recommande VPN pour CHS; 2.39 propose Logos Storage comme option plus privée. | La doc CHS confirme l’IP exposée; 2.39 permet Logos Storage, Torrent ou désactivation. | Ne pas extrapoler l’exposition BitTorrent des archives à tout message 1:1. | Choix par défaut de protocole en 2.39 et fuite IP directe dans les autres modes. |
| 8. Messages | Réseau conserve temporairement les messages jusqu’à 30 jours selon FAQ; les clients les stockent localement. Suppression/modification ne retire pas forcément les copies déjà reçues. | E2EE; réseau incapable de lire le contenu. | Specs Status publient Store, payloads et logique de suppression. | Un Store peut garder ciphertext et métadonnées topic; copie locale destinataire peut persister. | Expiration et purge réelle par type de chat/build. |
| 9. Groupes | Petits groupes privés maintiennent une session avec chaque membre; Communities ont une gestion et un ratchet distincts. | E2EE en groupes/communautés. | Specs décrivent coût pair-à-pair, rekey, membership; le propriétaire d’une communauté est un point unique de défaillance. | Membership, rôle, révocation et propriétaire ajoutent des risques propres; contenu chiffré n’anonymise pas les membres. | Taille max, type exact des groupes et metadata leakage de la version courante. |
| 10. Appels | Aucun protocole d’appel vocal/vidéo établi dans la documentation de messagerie actuelle consultée. | Aucune garantie actuelle d’appel établie. | Aucun protocole/appel public dans les sources examinées. | Ne pas supposer qu’un appel est disponible. | Fonctionnalité expérimentale/roadmap par plateforme et exposition IP. |
| 11. Fichiers | Docs listent partage d’images/audio; CHS traite également des archives chiffrées. | Partage privé lorsqu’il est dans un chat chiffré. | Specs de payload et docs d’archives publiques; binaire non examiné. | EXIF, thumbnails, cache et stockage de pièces jointes peuvent différer du texte. | Limites, EXIF, chemins, chiffrement et purge par plateforme. |
| 12. Multi-device | Jusqu’à trois appareils appariés/synchronisés selon doc; sync de profil séparée du contenu; sync d’historique locale et opt-in. | Synchronisation chiffrée sous contrôle utilisateur. | Guide officiel décrit codes temporaires, appairage et Wi-Fi par défaut. | Chaque appareil ajouté accroît le nombre d’endpoints détenteurs de clés. | Transport/crypto exacts, comportements sur LAN hostile et logs d’appairage. |
| 13. Push | v2.38: Android via service local selon Status; iOS via APNs et serveurs push Status pour un signal. | Messages E2EE non transmis à Apple ni aux serveurs push. | Déclaration éditeur; payload APNs et binaires non inspectés. | iOS associe token/installation/temps avec APNs/Status; Android évite un fournisseur tiers selon le claim. | Payload, mapping token↔profil, rétention et permission par build. |
| 14. Stockage local | Messages consultables hors ligne; clés conservées localement et protégées par mot de passe selon guide. | Contrôle local et phrase de récupération. | Status décrit des backups chiffrés locaux automatiques toutes les 30 min; aucun forensic du binaire réalisé. | Session déverrouillée permet au processus d’afficher le plaintext; le chiffrement disque ne protège pas un appareil compromis. | DB/KDF, Keychain/Keystore, caches, fichiers temporaires et traces après suppression. |
| 15. Sauvegardes | v2.36: backup local chiffré; message backup direct/groupe/communauté facultatif; sync locale opt-in. | Copies restent sur appareil et sous contrôle de l’utilisateur. | Modalités documentées par Status, sans validation du comportement réel. | Phrase de récupération et archive de conversations sont deux secrets/sauvegardes différents. | Inclusion de clés, backup OS/cloud et suppression sur chaque plateforme. |
| 16. Analytics / SDK | Waku telemetry opt-in: succès message, peers, bande passante, versions; ID aléatoire par lancement, jusqu’à 30 jours. Proxy RPC wallet annonce loguer IP, URL, timestamp, code, user-agent et latence jusqu’à 15 jours. | Status dit ne pas collecter PII via telemetry et ne pas loguer le corps proxy. | Déclaration primaire d’infrastructure, non mesurée indépendamment. | Corrélation potentielle IP/topics/temps/RPC wallet sans identifiant civil explicite. | Inventaire Firebase/Sentry/SDK tiers et endpoints exacts des apps courantes. |
| 17. Code source | Client Nim/Qt/QML public; status-go et projets Logos publics; client sous MPL-2.0; dépôt security liste audits/bounty. | Status présente toute la stack comme ouverte et vérifiable. | Dépôts inspectables; étoiles/forks ne mesurent pas les mainteneurs actifs. | Code client ouvert ne prouve pas que binaire/store, infrastructure et SDK correspondent au source. | Composants tiers/fermés embarqués par canal et correspondance binaires-source. |
| 18. Reproductibilité | Guide Desktop propose vérification GPG facultative du tarball Linux; instructions de build Desktop/Mobile sont publiques. | Le code ouvert est annoncé comme vérifiable. | Aucun build indépendant comparé au binaire distribué dans cette enquête. | Signature GPG authentifie une distribution, pas sa reproductibilité ni son lien au commit. | Reproductibilité par plateforme et version de store. |
| 19. Supply chain | Dépendances Nim, Qt/QML, Go historique, Logos Delivery Nim et push Apple; Status annonce migration Go→Nim du transport en 2.39. | Livraison ouverte/protocole standardisé. | Repo/release publics; aucun audit moderne de CI/provenance complet identifié. | Migration majeure peut modifier bugs et observabilité; mesurer la version exacte est essentiel. | SBOM, provenance CI, signatures stores, clés de signature et composants réellement livrés. |
| 20. Infrastructure | Nœuds Waku gérés Status, Store/Bootstrap/Filter/Light Push, proxy RPC et APNs iOS décrits. | Le réseau est ouvert et tout utilisateur peut participer; nœuds Status améliorent la fiabilité. | Page infrastructure confirme nœuds et quelques logs; DNS/ASN n’a pas été échantillonné. | Nœuds Status sont un point de corrélation opérationnel parmi plusieurs opérateurs. | Domaines, DNS passif, ASN, cloud/CDN, régions et concentration réelle. |
| 21. Juridiction | Status Research & Development GmbH est donnée comme société suisse sise à Zug dans les Terms. | N/A. | Terms/policy identifient l’entité; cela ne prouve pas que serveurs et sous-traitants sont en Suisse. | Obligations varient selon entité, fournisseur cloud, stores, APNs et lieu de la demande. | Entités contractantes, régions des données et transferts internationaux. |
| 22. Demandes policières | Des logs IP/topic/proxy sont techniquement annoncés; clés privées sont déclarées locales. | Aucun guide police/rapport de demandes identifié. | Recherche publique ciblée sans cas primaire trouvé, résultat borné. | Une demande peut viser Status, ISP, Apple/Google, cloud ou appareils, pas seulement messages E2EE. | Politique de réponse, données demandées/reçues/remises, notifications et contestations. |
| 23. Affaires judiciaires connues | Aucun dossier public de divulgation effective par Status n’a été établi dans cette recherche. | Inconnu. | Aucun affidavit/retour fournisseur attribuable identifié. | Absence de cas public trouvé ne prouve pas absence de demandes/remises. | Dossiers scellés, graphies alternatives et cas non indexés. |
| 24. Audits | Index Status-security liste Deja Vu mobile beta (2018), Sigma Prime ENS (2018), Trail of Bits v1 (2019). | Status annonce programme HackenProof. | Sigma Prime a un billet détaillé; ToB a un résumé éditeur; PDF Deja Vu/ToB non récupéré. | Audits historiques ne valident pas la messagerie 2026; contrat ENS est un périmètre séparé. | Audits modernes Status App/Logos, commits exacts, findings privés et retests. |
| 25. Vulnérabilités | Incident TestFairy 2018: bug nightly pouvait enregistrer les phrases de récupération par écran/log; status dit retirer le SDK et supprimer captures. | Status a indiqué n’avoir aucune preuve d’exploitation. | Publication primaire éditeur, aucune validation forensic indépendante de l’incident. | Incident d’endpoint et supply chain de tests, pas cassure du protocole E2EE. | Advisories et vulnérabilités courantes, population concernée, suppression vérifiée. |
| 26. Recherche académique | Papier Waku 2022 traite du protocole et compromis réseau, non du build Status 2.39. | Status présente Waku comme préservant anonymat/métadonnées. | [Papier Waku](https://arxiv.org/abs/2207.00038); pas d’étude indépendante actuelle du build trouvée. | Propriété du protocole ne prouve pas le déploiement sans fuite ni comportement client. | Mesures actuelles de topic/IP et flotte de production. |
| 27. Incidents historiques | Oct. 2018, bug d’occultation TestFairy dans nightly mobiles révélait phrases de récupération via captures/logs; Status annonçait retrait du service et effacement. | L’éditeur disait que l’incident ne visait pas les installs Play/TestFlight sauf réutilisation de phrase et n’avait pas été exploité à sa connaissance. | Avis primaire éditeur; l’exploitation n’est pas confirmée. | Incident de confidentialité important mais ne doit pas être extrapolé aux versions courantes. | Nombre d’utilisateurs, étendue et validation indépendante de purge. |
| 28. Gouvernance / financement | Société suisse, token SNT, dépôts publics, security repo et roadmap. | Produit présenté comme communautaire et décentralisé. | Existence de dépôts/société publique; pas d’audit financier ou de contrôle de gouvernance. | Gouvernance token, logiciel, société et opérateurs d’infrastructure sont des couches différentes. | Capitalisation/financement, contrôle de flotte, concentration mainteneurs et décision actuelle. |
| 29. Résistance à la censure | Réseau P2P et choix de nœuds; la FAQ reconnaît qu’une coupure totale d’Internet arrête aussi le service. | Une panne/blocage d’un nœud ne devrait pas arrêter l’ensemble. | Specs publiées, mais pas de mesure OONI/pays/ASN menée. | Changer de nœud aide face à certains blocages, pas contre store, bootstrap, DNS, app store ou coupure réseau. | Filtrage IP/SNI/DPI, bootstraps alternatifs préchargés et adoption hors flotte Status. |
| 30. Maintenance actuelle | Annonce 2.39 datée 8 oct. 2026; GitHub affichait 2.39 RC.7 le 29 sept. et 2.38.2. | Rollout SDS, Logo Storage et livraison fiable annoncés. | Dates/repo vérifiables; déploiement effectif par store non contrôlé. | Maintenance active mais architecture en migration; évaluer un build exact. | Version stable réellement distribuée par OS/pays et niveau de rollout. |

### Audits Status — findings et limites d’accès

| Audit | Version / commit / durée | Scope, exclusions, méthode | Findings, sévérités, recommandations et fixes | Retest / limite |
|---|---|---|---|---|
| **Deja Vu Security, beta mobile, Q1–juin 2018.** L’index status-security contient le dossier 2018-05; post de résultat daté 21 juin. | Version, commit, durée et équipe: UNKNOWN dans le matériau récupéré. | Post disponible: revue code et test d’intrusion manuel de Status React et Status Go; signatures/autorisation transaction, dApps malveillantes, écrans de confirmation et fuite de données. | Finding-level, sévérité, recommandations et corrections non récupérés; dépôt GitHub du dossier inaccessible via l’outil de recherche. | Retest UNKNOWN; ne concerne pas Status 2.39. |
| **Sigma Prime, ENS UsernameRegistrar, sept.–oct. 2018.** Auditeurs Adrian Manning et Mehdi Zerouali. | Commit initial eaefa92; retest 30ce35c; durée exacte UNKNOWN, mission time-boxed. | Contrat UsernameRegistrar seulement; tous autres contrats et app mobile exclus. Revue sécurité Solidity et recommandations qualité; suite de test associée annoncée. | 9 issues: 3 Medium, 1 Low, 5 Informational. Findings détaillés: réentrance pouvant permettre au contrôleur de voler des dépôts (M); verrouillage retraits (M); sous-domaines non révocables/gratuits (M); front-running du bounty slashing (L). Recos checks-effects-interactions, gas stipend, suppression de sous-nœuds, commit-reveal. Corrections référencées commits fbd0e3a, a1fe1f0, 51a7010, 1855141. Sigma Prime dit les issues corrigées. | Retest annoncé; retest détaillé 9/9 à confirmer dans PDF complet, non récupéré; sans pertinence directe pour sécurité des chats. [Article Sigma Prime](https://sigmaprime.io/blog/status-ens-review/). |
| **Trail of Bits, Status v1 mobile/code, 30 sept.–20 nov. 2019.** 4 ingénieurs, 9 person-weeks. | Repos: status-protocol-go, status-go, whisper, status-react; commit/version exacts absents du résumé public. | Objectifs: résistance DoS, confidentialité, spam/malicious messages, propriétés Whisper. Méthode: revue manuelle, tests automatisés, fuzzing et fault injection. Exclusions détaillées non récupérées. | Résumé Status: 0 Critical, 7 High, 5 Medium, 9 Low, 11 Informational, 6 Undetermined. Catégories: access control 3, logging 1, crypto 3, data exposure 2, validation 16, DoS 5, error reporting 4, timing 2, undefined behavior 2. Status annonce correction générale mais dit que seuls les problèmes critiques sécurité/UX seraient priorisés avant v1, reste après lancement. Recommandations itemisées inconnues faute de rapport complet. | Pas de fix review ou retest global établi. Le rapport ToB n’a pas été récupéré dans les dépôts publics consultés; aucun de ces résultats ne couvre le client 2026. [Résumé Status](https://status.app/blog/status-mobile-app-security-audit-complete-ahead-of-v1-launch). |

### Matrice de métadonnées Status

Les cases indiquent l’accès possible/annoncé, non une preuve que toutes ces données ont été conservées ou remises. Aucun cas public de divulgation par Status n’a été trouvé dans la recherche menée.

| Métadonnée | Fournisseur Status | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | **CONFIRMÉ** Store/Bootstrap; 15 j annoncés; Filter/LightPush voient IP selon rôle. | **POSSIBLE** CHS/Torrent révèle l’IP aux membres; DM standard non mesuré. | **CONFIRMÉ** IP/horaires/destinations selon accès réseau. | **CONFIRMÉ** pour connexion APNs iOS; **POSSIBLE** Google Play; FCM Android déclaré absent. | **PROBABLE** via fournisseur/ISP/APNs sous procédure; cas Status **INCONNU**. |
| Téléphone | **NON ACCESSIBLE PAR DESIGN** à la création standard; **POSSIBLE** si ajouté/partagé volontairement. | **POSSIBLE** si révélé par profil/autres canaux. | **CONFIRMÉ** dans dossiers abonné, lien app **INCONNU**. | **POSSIBLE** via compte store/facturation, pas forcément transmis à Status. | **PROBABLE** via opérateur/store si identifiant connu; cas **INCONNU**. |
| E-mail | **NON ACCESSIBLE PAR DESIGN** obligatoire; **POSSIBLE** via feedback/compte tiers volontaire. | **POSSIBLE** s’il est communiqué. | **NON ACCESSIBLE PAR DESIGN** au flux app; connu séparément de l’ISP si adresse client. | **PROBABLE** comme donnée de compte Apple/Google ayant installé l’app. | **PROBABLE** via store/autres comptes; cas **INCONNU**. |
| Identifiant | **CONFIRMÉ** clés/chat key/topics selon conversations. | **CONFIRMÉ** clé partagée, ENS, profil. | **POSSIBLE** par corrélation réseau, pas nécessairement identifiant lisible. | **POSSIBLE** identifiant installation/token; mapping au profil Status non établi. | **PROBABLE** si clé connue; remise réelle **INCONNUE**. |
| Graphe social | **POSSIBLE/PROBABLE** IP↔topic; certains metadata de groupe/community. | **CONFIRMÉ** dans contacts/groupes locaux. | **POSSIBLE** par timing, volume et destinations. | **POSSIBLE** via timing APNs iOS. | **PROBABLE** via données Status, participants et OSINT; disclosure **INCONNUE**. |
| Timestamps | **CONFIRMÉ** logs de service/proxy, rétention variable; 15 j annoncés pour certains. | **CONFIRMÉ** historique local. | **CONFIRMÉ** trafic réseau. | **POSSIBLE** signal APNs iOS; pas FCM Android selon claim. | **PROBABLE** selon rétention fournisseur/ISP; cas **INCONNU**. |
| Volumes | **PROBABLE/CONFIRMÉ** telemetry opt-in (bandwidth/success) et requêtes nodes. | **CONFIRMÉ** au niveau conversation/appareil. | **CONFIRMÉ** octets/rythme. | **POSSIBLE** notifications iOS; détail **INCONNU**. | **PROBABLE** via journaux opérateur/store; disclosure **INCONNUE**. |
| Groupes | **POSSIBLE** topics/IDs/membership metadata; contenu chiffré selon type. | **CONFIRMÉ** pour groupes connus. | **POSSIBLE** motifs de trafic. | **POSSIBLE** notifications mention/réponse; mapping inconnu. | **PROBABLE** depuis logs/appareils/participants; cas **INCONNU**. |
| Appareils | **CONFIRMÉ** profils sync jusqu’à 3 appareils; token iOS possible par push. | **CONFIRMÉ** si appareil/appairage partagé. | **POSSIBLE** nombre de sessions/empreintes réseau. | **CONFIRMÉ** appareils liés compte Apple/Google, lien Status non confirmé. | **PROBABLE** via saisie, Apple/Google ou logs push; cas **INCONNU**. |
| Push tokens | **CONFIRMÉ** service push Status pour iOS selon architecture; Android tiers déclaré absent. | **NON ACCESSIBLE PAR DESIGN** à un contact ordinaire. | **NON ACCESSIBLE PAR DESIGN** token, mais timing/IP push possible. | **CONFIRMÉ** APNs iOS; FCM Android **NON ACCESSIBLE PAR DESIGN** selon claim, non vérifié binaire. | **POSSIBLE** auprès Apple/Status selon procédure; champs remis **INCONNUS**. |

### Matrice provisoire Status TM1–TM15 (candidat séparé; sans rang)

| TM | Valeur | Justification courte |
|---|---|---|
| TM1 — fournisseur curieux | 🟠 | Status admet IP/topic visibles à plusieurs rôles et logs IP 15 jours; contenu reste chiffré. |
| TM2 — fournisseur compromis | 🟡 | Nœud compromis observe IP/topic ou perturbe livraison; clés E2EE censées rester endpoint. |
| TM3 — fournisseur malveillant | 🟡 | QR/clé et vérification peuvent détecter mauvaise identité si employés; distribution/build actuel non testé. |
| TM4 — ISP/Wi-Fi | 🟠 | IP, destinations, heures et volumes visibles; payload chiffré. |
| TM5 — adversaire passif multi-points | 🟠 | Plusieurs nœuds, APNs iOS, ISP et topics peuvent se corréler; pas de défense globale mesurée. |
| TM6 — adversaire global passif | 🟠 | Pas de mixnet établi; Waku masque certains champs mais non toutes IP/timings/topics selon rôle. |
| TM7 — contact malveillant | 🟠 | Contact voit et peut copier le contenu; E2EE ne protège pas contre participant légitime. |
| TM8 — doxxer OSINT | 🟠 | Chat key/profil/ENS et wallet public peuvent être linkés si réutilisés. |
| TM9 — demande judiciaire classique | 🟠 | IP/topic/proxy logués possibles; aucun cas de remise Status trouvé; ciphertext n’est pas plaintext. |
| TM10 — enquête sophistiquée | 🟠 | Corrélation ISP/store/wallet/APNs, endpoint et appareils possibles; résultat forensic actuel inconnu. |
| TM11 — appareil verrouillé saisi | ❓ | Aucune preuve publique outil+version+OS+build Status actuelle identifiée. |
| TM12 — appareil déverrouillé | 🔴 | Appareil ouvert expose au processus app les messages/clés nécessaires; DB et extraction exactes non testées. |
| TM13 — spyware ciblé | 🔴 | Malware avec écran/processus/mémoire lit avant/après chiffrement; ratchet ne protège pas endpoint contrôlé. |
| TM14 — supply chain compromise | 🟠 | Source public, signature Desktop possible, aucune reproduction mobile; transport en migration. |
| TM15 — censure étatique | 🟠 | P2P permet de changer de nœud mais dépend d’Internet; bootstraps, stores, DNS et APNs peuvent rester filtrables. |

### Contradictions, lacunes et tests ciblés Status

- **« Aucun serveur ne voit de métadonnées » contre la déclaration d’infrastructure.** Le blog dit qu’aucun nœud ne voit les métadonnées de conversation; la page Status d’octobre 2026 déclare IP + content-topic visibles par Store/Filter/LightPush et 15 jours de logs IP pour certains nœuds. Peut-être des couches/identifiants différents, mais la formulation absolue n’est pas soutenue. [Infrastructure](https://status.app/help/getting-started/privacy-with-status-infrastructure-and-insights), [architecture marketing](https://status.app/blog/building-the-web3-anonymous-chat-stack-how-peer-to-peer-protocols-replace-servers).
- **Crypto variable selon les sources.** Les anciens billets décrivent X3DH + Double Ratchet; la spec 1:1 de 2026 permet X3DH ou Noise; Communities décrit un ratchet de groupe. Il faut associer le code exact aux versions 2.39 avant d’affirmer une suite et des garanties uniformes.
- **Wallet key/chat key.** Le guide des clés emploie une formulation où la clé publique identifie profil et wallet, puis précise que chat key et adresse wallet sont des keypairs dérivées distinctes. Séparation/linkage à confirmer dans code et build.
- **Community History.** Guide CHS dit BitTorrent activé par défaut et expose l’IP aux membres; 2.39 ajoute Logos Storage mais laisse le choix Torrent/Storage/désactivé. Le défaut effectif et la migration des communautés sont à tester.
- **Version/audit.** Billet 2.39 daté 8 oct. tandis que release GitHub consultée affiche RC.7 et 2.38.2. Audit public de l’app remonte essentiellement à 2019; finding-level du rapport ToB non disponible.
- **Forensics/légal/OSINT.** Pas de manifeste app décompilé, DNS/ASN passif, label store, rapport public de demandes, cas de disclosure Status, ou test d’acquisition forensique contrôlé dans cette étape.
- **Tests pour fermer ces inconnues.** Reproduire un build 2.39 par OS; mapper commit Logos Delivery et dépendances; capturer flux IP/topic, APNs, backup/sync, CHS Torrent vs Logos Storage avec comptes contrôlés; lire labels stores, manifests, entitlements, SDK et permissions de la version exacte; tester acquisition verrouillée/déverrouillée avec OS+patch+outil+app notés; récupérer les rapports Deja Vu/ToB ou obtenir confirmation d’indisponibilité.

### Sources Status à reprendre en Phase 3

- [Client Status et instructions build](https://github.com/status-im/status-app), [releases](https://github.com/status-im/status-app/releases), [status-security/audits](https://github.com/status-im/status-security), [organisation Logos Messaging](https://github.com/logos-messaging).
- [Spec 1:1 Status](https://status.app/specs/status-1to1-chat), [spec Communities](https://status.app/specs/status-communities), [payloads/routing](https://status.app/specs/status-payloads), [papier Waku](https://arxiv.org/abs/2207.00038).
- [Infrastructure/privacy](https://status.app/help/getting-started/privacy-with-status-infrastructure-and-insights), [clés/récupération](https://status.app/help/profile/understand-your-status-keys-and-recovery-phrase), [sync multi-device](https://status.app/help/profile/sync-your-profile-across-devices), [backup local v2.36](https://status.app/blog/status-mobile-v2-36), [push iOS/Android](https://status.app/blog/status-v2-38-mobile-browser-private-notifications-new-l2-networks-and-a-faster-app-experience), [CHS et IP](https://status.app/help/communities/about-the-community-history-service).
- [Trail of Bits 2019 — résumé Status](https://status.app/blog/status-mobile-app-security-audit-complete-ahead-of-v1-launch), [Sigma Prime ENS 2018](https://sigmaprime.io/blog/status-ens-review/), [incident TestFairy 2018](https://status.app/blog/testfairy-issue-report), [Terms / entité suisse](https://status.app/legal/terms-of-use).