Jami — dossier de preuves (situation 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.
Sources primaires : politique de confidentialité, réseau distribué, FAQ officielle (IP, push, crypto), modèle Swarm, gestion des comptes, fiche Android, F-Droid / permissions / rebuild, iOS App Store, repos GitHub miroir Gerrit, annonce 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 |
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 |
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
| 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 |
| 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.