Signal — dossier probatoire approfondi (état au 13 octobre 2026)¶
Registre de preuves — Phase 2
Ce dossier est une pièce de recherche datée. La conclusion canonique est celle du rapport final 1.0. Les synthèses antérieures et renvois à la Phase 3 restent historiques. UNKNOWN reste UNKNOWN.
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 | 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, 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 | 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 | 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 | « 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 | 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 | 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 [accès à vérifier] | 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 | 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, manifest, iOS 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, support | 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 | 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, anti-spam | 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 | 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 |
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 |
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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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, 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, RIPEstat AS13335, RIPEstat 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.
- 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.
- 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.
- 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¶
- 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.
- 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.
- 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.
- 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.
- 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. |
| 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, réponse judiciaire 2026, username/visibilité numéro, manifest Android, dépendances Android, private groups.
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 |
| 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 |
| 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 |
| 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, calls |
| 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 |
| 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 |
| 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 |
| 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 |