Mobile privacy / déclarations de magasins — contrôle ponctuel, 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.
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, fiche Signal App Store.
| 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, App Store. |
| 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, App Store. |
| 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, App Store, FAQ appels. |
| 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, transparence. |
| 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. |
| 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, privacy policy. |
| 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. |
| 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 | 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 | 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 | 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, Play | É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 | 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 | 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, Apple | 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 | 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, Apple | 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 | 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 | 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, Apple | 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, Apple | 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 [accès à vérifier] |
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 [accès à vérifier] |
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 [accès à vérifier] |
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 [accès à vérifier] |
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.