Métadonnées¶
Échelle : CONFIRMÉ = documentation/architecture/cas établit l’accès; PROBABLE = nécessaire ou fortement impliqué sans preuve de rétention; POSSIBLE = dépend de la configuration ou du fournisseur tiers; NON ACCESSIBLE PAR DESIGN = protégé dans le chemin documenté si code et terminaux intègres; INCONNU = la preuve ne tranche pas. Les autorités n’ont accès qu’aux données détenues par un acteur et remises ou saisies dans un cadre donné; une possibilité technique ne prouve pas une remise réelle.
| Service | Fournisseur / serveurs | Correspondant | ISP / réseau local | Apple / Google | Données autorités déjà documentées |
|---|---|---|---|---|---|
| Signal | CONFIRMÉ : numéro d’inscription et quelques dates de compte; contenu E2EE NON ACCESSIBLE PAR DESIGN côté service pour messages normaux | CONFIRMÉ : contenu/profil partagé; numéro masqué si configuration appliquée et non déjà connu | CONFIRMÉ : IP de connexion, destination/temps/volume | POSSIBLE : installation, compte store/push/device metadata; détails payload non testés | CONFIRMÉ 2026 : dates de création et dernière connexion pour six comptes; pas le contenu. |
| SimpleX | CONFIRMÉ : relais/queues/push et métadonnées transport; corps E2EE NON ACCESSIBLE PAR DESIGN. La société déclare que les relais presets ne loggent pas les IP ordinaires; pas vérifié indépendamment | CONFIRMÉ : contenu/profil transmis; ID de connexion propre à la relation | CONFIRMÉ : destinations relay, horaires/volume; IP visible au premier relais/à l’ISP | POSSIBLE : APNs token et fréquence; la politique décrit ce que le service push et Apple peuvent voir | Déclaration 2025 : 12 demandes sans données responsive communiquées, non vérifiée indépendamment; cas de production concret inconnu. |
| Olvid | CONFIRMÉ : serveurs voient des informations de routage, clés publiques, taille/horodatage selon analyse formelle; contenu E2EE selon modèle | CONFIRMÉ : profil et identité cryptographique présentés; téléphone/e-mail non obligatoires | CONFIRMÉ : IP, endpoints, temps, volume | POSSIBLE : push/store liés au terminal | Aucun cas public de remise individuelle établi dans cette recherche; données d’infrastructure possibles selon rétention inconnue. |
| Session | CONFIRMÉ : nœuds/relais voient le trafic/activité nécessaire; appels beta exposent IP à l’opérateur STUN/TURN | CONFIRMÉ : ID/session, contenu reçu; appels P2P peuvent révéler IP | CONFIRMÉ : IP des nœuds et timing; onion routing pour messages | POSSIBLE : store/push selon plateforme; détail exact inconnu | Aucun cas de remise concret identifié ici; la capacité des nœuds et les obligations exactes restent dépendantes du réseau/juridiction. |
| Threema | CONFIRMÉ : ID et dates de connexion; métadonnées de compte. Contenu chiffré par conception | CONFIRMÉ : ID, contenu, nom/photo rendus publics par l’utilisateur | CONFIRMÉ : IP destination/temps/volume | POSSIBLE : achat, installation, push/device; mapping public inconnu | Rapport agrégé 2025 et S1 2026 : remises de champs de compte pour des IDs; pas de preuve de contenu de message remis par Threema. |
| Cwtch | POSSIBLE : relais onion et disponibilité/activité; pas de profil global annoncé | CONFIRMÉ : identité choisie et messages reçus | CONFIRMÉ : accès Tor/Internet et volume; IP cible masquée à certains points selon Tor | POSSIBLE : magasin et OS; pas de client iOS | Pas de production concrète retrouvée; les pairs/terminaux restent des sources. |
| Briar | POSSIBLE : Tor ou échanges locaux; centralisation moindre | CONFIRMÉ : conversations locales et identité de contact | CONFIRMÉ : connexions Tor/locaux, timing/volume | POSSIBLE : Google Play si installé depuis Play; pas d’app iOS | Pas de cas de remise fournisseur documenté retrouvé; terminal, correspondants, store ou FAI restent hors du cœur Briar. |
| Jami | CONFIRMÉ/POSSIBLE : DHT, bootstrap et relais voient leur portion du réseau | CONFIRMÉ : peer et contenu reçu | CONFIRMÉ : P2P peut révéler IP et trafic | POSSIBLE : stores et push dépendant de la plateforme | Pas de cas concret établi dans cette recherche; dépend des nœuds/terminaux visés. |
| Tox/qTox | POSSIBLE : nœuds DHT/bootstrap et peers observent l’activité qu’ils relaient | CONFIRMÉ : clé/ID, contenu; IP probable en P2P | CONFIRMÉ : IP pair et volumes selon le chemin | POSSIBLE : app tierce/mobile; pas de correspondance universelle | Aucun cas produit identifié; diversité des clients et opérateurs empêche un tableau juridique unique. |
| Matrix/Element | CONFIRMÉ : homeserver voit compte, appareils, IP, membership/rooms, événements/temps; contenu clair hors E2EE, ciphertext dans salons E2EE | CONFIRMÉ : salons, identifiants et contenu accessible au client; membership visible | CONFIRMÉ : IP serveur, horaires/volume | POSSIBLE/PROBABLE : push token/room/event metadata, store identity | Guide matrix.org décrit la procédure; aucun cas public avec champs effectivement remis par Matrix.org établi ici. Autres homeservers distincts. |
| XMPP/OMEMO | CONFIRMÉ : serveur voit JID, présence, connexions et transport; contenu chiffré si OMEMO réellement actif | CONFIRMÉ : JID, contenu et empreinte/clé | CONFIRMÉ : IP serveur/timing; IP pair possible en appels | POSSIBLE : app/store/push selon client | Pas de résultat juridique générique possible sans serveur identifié; remise/cas réels inconnus. |
| Telegram | CONFIRMÉ : numéro, comptes, cloud messages/groupes et métadonnées; Secret Chats diffèrent | CONFIRMÉ : username/numéro visibles selon réglages, messages reçus | CONFIRMÉ : IP/serveurs/temps | PROBABLE : app/push/store/OS; détails de liaison variables | Production judiciaire civile indienne sous pli, comprenant catégories d’IP/noms rapportées; ce n’est pas preuve d’une remise policière de ces champs. |
| CONFIRMÉ : numéro, graphe/horaires/infos de service; contenu E2EE pour chats personnels | CONFIRMÉ : numéro, profil, contenu, groupes | CONFIRMÉ : IP, destination/temps/volume | PROBABLE : APNs/FCM/store/compte OS; payload exact et liaison non entièrement testés | Des données de compte sont recherchables selon procédure; cas détaillés et champs concrets dans la Phase 2; ne pas extrapoler un cas sans dossier primaire. | |
| Discord | CONFIRMÉ : identité de compte, membres/serveurs, messages texte et métadonnées | CONFIRMÉ : profil, messages, appels/groupes | CONFIRMÉ : IP, timing/volume/service voice | PROBABLE : compte OS/store, push, device IDs selon déclarations store | CONFIRMÉ : messages et données de compte remis dans U.S. v. Bryant (2020). |
| Wire | CONFIRMÉ : compte, IP/metadata de service et champs selon offre; contenu E2EE selon périmètre | CONFIRMÉ : messages/profil | CONFIRMÉ : IP/temps/volume | POSSIBLE : store/push | CONFIRMÉ : e-mail d’inscription remis dans le dossier Tsunami Democràtic; pas preuve de contenu Wire remis. |
| Delta Chat | CONFIRMÉ : fournisseur mail voit adresses, headers/horaires/volumes; E2EE dépend de la conversation | CONFIRMÉ : adresse e-mail/clé, contenu | CONFIRMÉ : connexions mail et IP destination; appels P2P éventuels | POSSIBLE : store/push tiers | Fournisseurs mail peuvent remettre leurs données; pas de cas Delta Chat spécifique établi. |
| Ricochet Refresh | POSSIBLE : points Tor et onion service; pas de fournisseur messagerie unique établi | CONFIRMÉ : contact onion, contenu reçu | CONFIRMÉ : FAI voit entrée Tor et activité volumétrique; destination masquée selon Tor | POSSIBLE : store du système d’exploitation desktop; non testé | Aucun cas Refresh documenté retrouvé; ne vaut pas absence de risque Tor/endpoint. |
| Status/Waku | CONFIRMÉ/POSSIBLE : certains nœuds voient IP/topic/activité; rétention varie selon service géré | CONFIRMÉ : profile/clé, messages/groupes | CONFIRMÉ : IP des nœuds, horaires/volumes | POSSIBLE : push/store selon app | Aucun cas de remise individualisé établi; fournisseur/nœud et wallet/clé peuvent permettre corrélations différentes. |
| Métadonnée | Fournisseur | Contact | ISP | Apple/Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ pour services centralisés et points de connexion; dépend d’onion/P2P/relais | POSSIBLE ou CONFIRMÉ en P2P/appel; NON ACCESSIBLE PAR DESIGN au pair si TURN réellement utilisé | CONFIRMÉ au point d’accès; VPN/Tor change l’observateur, ne supprime pas toute observation | POSSIBLE via services push/store et compte OS; mapping à un profil de messagerie souvent INCONNU | PROBABLE si acteur détient logs; les remises constatées sont produit/cas spécifiques |
| Téléphone | CONFIRMÉ pour Signal/WhatsApp/Telegram; facultatif pour Threema; non requis dans SimpleX/Olvid/Cwtch/Briar/Ricochet | CONFIRMÉ si partagé/sauvegardé par le contact; masquage app ne fait pas oublier un numéro déjà connu | CONFIRMÉ par l’opérateur télécom; l’association à un profil dépend des autres données | PROBABLE comme donnée de compte Apple/Google, mais lien avec l’ID de messagerie variable | POSSIBLE via opérateur et fournisseur si conservé; ne pas supposer production automatique |
| CONFIRMÉ sur produits/serveurs qui l’exigent ou si ajouté; dépend de l’offre | POSSIBLE si donné en profil ou en dehors du service | NON ACCESSIBLE PAR DESIGN sous TLS seul, mais fournisseur de mail distinct le voit | PROBABLE pour compte store; lien avec le compte messagerie non systématique | POSSIBLE si conservé; Wire fournit un exemple de remise d’e-mail d’inscription | |
| Identifiant | CONFIRMÉ selon le modèle : numéro, MXID, JID, ID random, clé, queue ou compte | CONFIRMÉ pour chaque identité que le contact contacte | POSSIBLE par corrélation, non nécessairement lisible sous TLS | POSSIBLE via ID d’installation/push; correspondance avec identité sociale dépend du produit | POSSIBLE dans retour de service ou appareil; données concrètes variables |
| Graphe social / groupes | CONFIRMÉ dans systèmes centralisés/fédérés et groupes gérés; plus fragmenté via queues onion/P2P | CONFIRMÉ pour contacts et groupes auxquels il participe | POSSIBLE par timing multi-points; pas forcément les noms | POSSIBLE via push, carnet OS, interactions/labels | PROBABLE si serveur/participants/appareil détiennent l’état; remise réelle à établir cas par cas |
| Timestamps / fréquence / volume | CONFIRMÉ ou fortement probable pour serveurs et relais; padding/retention sont spécifiques | CONFIRMÉ pour messages reçus et statut vu; volume observable | CONFIRMÉ sur lien réseau | POSSIBLE par événements push et activité app; détail de liaison souvent inconnu | POSSIBLE si logs, sauvegardes, appareils ou participants obtenus |
| Appareils / push tokens | CONFIRMÉ au service lorsque multi-device/push les requièrent; payload varie | POSSIBLE via appareils vérifiés/listes selon app | POSSIBLE au niveau connexions, pas l’ID logique sous TLS | CONFIRMÉ pour token/install OS; contenu du payload dépend du produit et de l’OS | POSSIBLE via service push ou saisie; pas un synonyme de lecture du contenu |
Pour la matrice granulaire service × IP/téléphone/e-mail/ID/graphe/timestamps/volumes/groupes/appareils/push × fournisseur/contact/ISP/Apple-Google/autorités, consulter les matrices par service dans le dossier Phase 2. Elles incluent les colonnes statut et les liens de justification; aucune case « inconnu » ne doit être lue comme « aucune donnée ».