PlainApp — Sécurité en profondeur
Comment PlainApp protège vos données sur le réseau Wi-Fi local — preuves à l'appui dans le code open source.
Pourquoi la sécurité du réseau local est-elle importante ?
Lorsque vous utilisez une application pour gérer votre téléphone Android depuis un navigateur sur PC, vos SMS, photos, contacts et fichiers transitent par votre réseau Wi-Fi. La plupart des applications envoient tout cela en texte clair, lisible par quiconque se trouve sur le même réseau.
Vous pensez peut-être : « C'est mon Wi-Fi personnel, qui pourrait espionner ? » Mais réfléchissez :
- Wi-Fi public — Cafés, aéroports, hôtels — n'importe qui à proximité peut capturer le trafic
- Réseaux partagés — Colocataires, invités ou appareils IoT compromis
- Vulnérabilités du routeur — Firmware obsolète avec des failles connues
Si une application envoie vos SMS en texte clair via HTTP, n'importe qui disposant d'un outil gratuit comme Wireshark peut les lire. Ce n'est pas théorique — c'est d'une simplicité triviale.
La plupart des applications de gestion de téléphone font exactement cela. Ouvrez Chrome DevTools (F12 → onglet Network) pendant que vous utilisez leur interface web, et vous pouvez lire chaque appel API en JSON — corps des SMS, chemins de fichiers, noms de contacts, tout.
Ce qui distingue PlainApp
PlainApp applique plusieurs couches de chiffrement et d'authentification. Voici ce que fait chaque couche, en termes simples.
API GraphQL — Ne demander que ce dont vous avez besoin
La plupart des applications utilisent des API REST classiques : une URL par ressource, renvoyant tout, que vous en ayez besoin ou non. PlainApp utilise GraphQL — une approche moderne où le navigateur demande exactement les données nécessaires, rien de plus.
Pourquoi c'est important :
- Moins de données exposées — Si vous n'avez besoin que du nom d'un fichier, c'est tout ce qui est envoyé
- Un seul endpoint — Il n'y a qu'une seule URL /graphql au lieu de dizaines, ce qui réduit la surface d'attaque
- Permissions par requête — Chaque requête vérifie ses propres permissions (par ex., la lecture des SMS nécessite la permission READ_SMS même après connexion)
Appels API chiffrés (XChaCha20-Poly1305)
C'est la plus grande différence entre PlainApp et la plupart des concurrents.
Chaque requête et réponse API — y compris le trafic HTTP et WebSocket — est chiffrée avec XChaCha20-Poly1305, en mode HTTP comme HTTPS. C'est un algorithme de chiffrement AEAD moderne utilisé par WireGuard VPN, Cloudflare et la bibliothèque Tink de Google.
En termes simples :
- 1Votre navigateur construit une requête (par exemple « montre-moi mes SMS »)
- 2Il ajoute un horodatage et un nonce aléatoire pour la protection anti-rejeu
- 3Il chiffre l'intégralité du payload en données binaires illisibles avec XChaCha20-Poly1305
- 4Le binaire chiffré est envoyé sur le réseau — pas de base64, pas de JSON, du binaire pur
- 5Seul votre téléphone peut déchiffrer et valider
Même si quelqu'un intercepte le trafic, il ne voit que des données binaires sans signification — pas du JSON lisible.
À propos du chiffrement :
- Clé de 256 bits (extrêmement robuste)
- Nonce de 192 bits (prévient certains types d'attaques qui affectent d'autres algorithmes)
- Détection d'altération intégrée — si quelqu'un modifie les données en transit, le déchiffrement échoue
- Côté Android : basé sur Google Tink
- Côté web : basé sur @noble/ciphers (une bibliothèque JavaScript de cryptographie bien auditée)
Signatures numériques (Ed25519) — Appareil à appareil
Lorsque deux appareils PlainApp communiquent entre eux (par exemple, chat téléphone à téléphone), le chiffrement seul ne suffit pas — chaque appareil doit vérifier que le message provient bien de l'autre appareil et n'a pas été falsifié.
horodatage
L'appareil récepteur vérifie la signature à l'aide de la clé publique de l'expéditeur et rejette toute requête dont l'horodatage dépasse 5 minutes. Cela empêche à la fois la falsification et les attaques par rejeu.
Appairage sécurisé des appareils (échange de clés ECDH)
Lorsque deux appareils PlainApp s'appairent (par ex., deux téléphones), ils ont besoin d'une clé de chiffrement partagée. Mais envoyer une clé sur le réseau annulerait tout l'intérêt.
PlainApp résout ce problème avec l'échange de clés ECDH (Elliptic Curve Diffie-Hellman) — le même principe mathématique utilisé dans TLS, le Secure Enclave d'Apple et WebAuthn :
- 1Chaque appareil génère une paire de clés (publique + privée)
- 2Ils n'échangent que leurs clés publiques
- 3Chaque appareil combine sa propre clé privée avec la clé publique de l'autre
- 4Les deux aboutissent au même secret partagé — sans qu'il ne transite jamais par le réseau
URL chiffrées — Masquer les chemins de fichiers
Voici un détail que la plupart des gens ne remarquent pas : les chemins d'URL révèlent aussi des informations.
Lorsque vous téléchargez un fichier, l'URL indique au serveur quel fichier vous souhaitez. Dans de nombreuses applications, l'URL ressemble à :
/fs?path=/sdcard/DCIM/Camera/photo_2024.jpgToute personne qui intercepte le trafic (ou qui consulte l'historique du navigateur) peut voir exactement quel fichier vous avez consulté et l'arborescence de votre téléphone.
PlainApp chiffre le chemin du fichier dans l'URL :
/fs?id=AxK9f2mQ7vR3xP8nWz...Le paramètre id est le chemin du fichier chiffré avec XChaCha20-Poly1305 à l'aide d'une clé aléatoire appelée URL Token. Par défaut, cette clé est permanente et persiste après un redémarrage de l'application, de sorte que les liens partagés continuent de fonctionner. Sans la clé, personne ne peut deviner le vrai chemin, énumérer vos fichiers ou forger des URL de téléchargement.
HTTPS avec certificats auto-signés
PlainApp génère un certificat TLS auto-signé sur votre téléphone. Cela crée un tunnel HTTPS chiffré — la même technologie utilisée par les banques et les sites web.
Le certificat utilise :
- ECDSA avec courbe P-256 (identique aux grands sites web)
- Signature SHA256
- Stocké dans le répertoire privé de l'application
Combiné au chiffrement XChaCha20 au niveau applicatif, vous bénéficiez de deux couches de chiffrement indépendantes. Casser l'une ne sert à rien sans casser l'autre.
Protection de la connexion
PlainApp limite les tentatives de connexion pour empêcher la devinette de mot de passe :
- 5 tentatives par tranche de 60 secondes par adresse IP
- Au-delà, les connexions sont rejetées
- Les enregistrements de limitation expirés sont automatiquement nettoyés
HTTP vs HTTPS : un point honnête
PlainApp propose les modes HTTP et HTTPS. Voici la différence en toute transparence :
| Mode HTTP | Mode HTTPS | |
|---|---|---|
| URL des fichiers | Chiffrées (XChaCha20) | Chiffrées (XChaCha20) |
| Appels API | Chiffrés (XChaCha20) | Chiffrés (XChaCha20 + TLS) |
| Téléchargement de fichiers | Non chiffré en transit | Chiffré par TLS |
| Pour qui | Débutants (pas d'avertissement SSL) | Utilisateurs soucieux de la confidentialité |
Les deux modes chiffrent les appels API avec XChaCha20-Poly1305 — vos SMS, contacts et autres données sont toujours chiffrés, que vous utilisiez HTTP ou HTTPS.
Le mode HTTP existe parce que les certificats auto-signés déclenchent un avertissement du navigateur (« Votre connexion n'est pas privée »). Pour les utilisateurs moins techniques, cet avertissement est déroutant et inquiétant. Le mode HTTP évite cette friction.
Cependant, le mode HTTP ne chiffre pas les transferts de fichiers. Si vous êtes sur un réseau partagé ou public, utilisez toujours HTTPS.
Recommandation : utilisez HTTPS dès que possible. Acceptez l'avertissement du certificat auto-signé dans votre navigateur — c'est normal et attendu pour une application en réseau local.
Sécurité de la chaîne d'approvisionnement — Moins de dépendances, moins de risques
Une menace à laquelle beaucoup d'utilisateurs ne pensent pas : les attaques de la chaîne d'approvisionnement. Quand une application utilise des centaines de bibliothèques tierces, n'importe laquelle peut être compromise — injectant du code malveillant qui vole des données, mine de la cryptomonnaie ou ouvre des portes dérobées.
C'est particulièrement dangereux dans l'écosystème JavaScript. Ces dernières années, des paquets npm populaires comme event-stream, ua-parser-js et colors ont été détournés pour injecter du code malveillant dans des millions de projets. Si l'interface web d'une application de gestion de téléphone importe des centaines de paquets JS, chacun représente un vecteur d'attaque potentiel.
PlainApp adopte une approche délibérée : utiliser le moins de dépendances possible et développer du code sur mesure quand c'est pertinent.
Application Android (plain-app)
- Aucun framework d'injection de dépendances (ni Hilt, ni Dagger) — utilisation de simples singletons
- La cryptographie repose sur seulement 3 bibliothèques reconnues : Google Tink, Bouncy Castle et l'extension Java Cryptography Extension intégrée
- Le serveur tourne sur Ktor (framework Kotlin officiel de JetBrains) — pas de bibliothèques serveur tierces obscures
Interface web (plain-desktop)
Seulement 28 dépendances en production — bien moins que les applications web classiques. Plusieurs fonctionnalités qui nécessiteraient normalement des paquets npm sont développées de zéro :
| Fonctionnalité | Application classique | PlainApp |
|---|---|---|
| Sons de notification | howler.js / tone.js | Synthétiseur Web Audio API personnalisé |
| Génération d'UUID | paquet npm uuid | Implémentation RFC 4122 écrite à la main |
| Upload de fichiers | uppy / axios | Upload personnalisé par morceaux avec file d'attente |
| Vidéo WebRTC | SDK Twilio / Daily.co | Code PeerConnection écrit à la main |
| Client HTTP | axios / ky | fetch natif du navigateur |
La cryptographie côté web utilise @noble/ciphers — une bibliothèque JavaScript de cryptographie bien auditée et sans dépendance — au lieu de recourir à des alternatives volumineuses et surchargées.
Pourquoi c'est important
Chaque dépendance ajoutée est du code que vous ne contrôlez pas. L'approche de PlainApp signifie :
- Moins d'endroits où du code malveillant peut se cacher
- Surface d'attaque réduite
- Plus facile à auditer (l'intégralité du code source est open source)
- Aucun risque lié à des paquets npm abandonnés ou détournés
Les erreurs courantes chez de nombreux concurrents
Il ne s'agit pas de citer des applications précises, mais de souligner des pratiques répandues dans cette catégorie :
| Aspect sécurité | PlainApp | Courant chez les concurrents |
|---|---|---|
| Trafic API | Chiffré (XChaCha20) en HTTP et HTTPS | JSON en clair via HTTP |
| Trafic WebSocket | Trames binaires chiffrées (XChaCha20) | JSON en clair ou pas de WebSocket |
| Gestion du token d'auth | Utilisé comme clé de chiffrement, jamais dans les en-têtes | Envoyé dans les en-têtes HTTP (fuite facile) |
| URL des fichiers | Identifiants de chemin chiffrés | Chemins en texte clair exposés |
| Échange de clés | ECDH (P-256) | Aucun |
| Signature des requêtes | Ed25519 (appareil à appareil uniquement) | Aucune |
| Protection anti-rejeu | 30 s + nonce (Web) ; 5 min + signature (appareil) | Aucune |
| Protection de connexion | Limite de tentatives + confirmation à deux facteurs | Tentatives illimitées |
| Routage des données | 100 % local, aucun cloud | Certains transitent par le cloud |
| Dépendances | Minimales, bibliothèques reconnues | Des centaines de paquets npm |
| Code source | Open source (GPL-3.0) | Majoritairement fermé |
Le moyen le plus simple de vérifier une application : ouvrez Chrome DevTools (F12) → onglet Network pendant que vous utilisez l'application. Si vous pouvez lire les réponses API en JSON, l'application n'a aucun chiffrement.
Vérifiez par vous-même
PlainApp est entièrement open source. Chaque affirmation de cet article peut être vérifiée dans le code.
github.com/plainhub/plain-app (GPL-3.0)Pipeline de publication automatisé, traçable et résistant aux altérations
Tous les paquets d’installation sont compilés automatiquement par l’infrastructure GitHub et F-Droid. Les builds sont traçables, sûrs et sans intervention manuelle. PlainApp fait partie des rares applications Android qui offrent à la fois des builds vérifiables (SLSA) et des versions analysées par VirusTotal.
Builds automatisés sur GitHub et F-Droid
Les artefacts de publication sont générés par des pipelines CI au lieu d’un empaquetage manuel local. Chaque artefact est traçable jusqu’aux commits sources et aux workflows reproductibles.
SLSA Provenance (Niveau 3) + scan VirusTotal
Chaque version inclut des attestations SLSA et des résultats d’analyse VirusTotal, rendant la chaîne d’approvisionnement auditable et permettant de vérifier l’intégrité avant installation.
Foire aux questions
PlainApp est-il vraiment chiffré en mode HTTP ?
Oui. Tous les appels API (SMS, contacts, liste de fichiers, etc.) sont chiffrés avec XChaCha20-Poly1305 en mode HTTP comme en mode HTTPS. Le mode HTTP laisse uniquement les téléchargements de fichiers non chiffrés. Pour une protection complète, utilisez HTTPS.
Pourquoi mon navigateur affiche-t-il un avertissement de sécurité ?
PlainApp utilise un certificat TLS auto-signé pour le chiffrement. Comme il n'est pas émis par une autorité de certification publique, votre navigateur affiche un avertissement. C'est normal et attendu pour une application en réseau local. Cliquez sur « Avancé » puis « Continuer » pour poursuivre.
Quelqu'un sur le même Wi-Fi peut-il voir mes données ?
Avec PlainApp, non. Les appels API sont chiffrés avec XChaCha20-Poly1305, et en mode HTTPS les transferts de fichiers sont également chiffrés par TLS. Avec la plupart des applications concurrentes, oui — leurs appels API sont envoyés en JSON en texte clair.
Comment PlainApp se compare-t-il à un VPN ?
Un VPN chiffre le trafic entre votre appareil et le serveur VPN. PlainApp chiffre le trafic entre votre téléphone et votre navigateur sur le réseau local. Ils répondent à des besoins différents — PlainApp sécurise la gestion locale de l'appareil, tandis qu'un VPN sécurise le trafic internet.
Le code est-il vraiment open source ?
Oui. PlainApp est distribué sous licence GPL-3.0. Le code source complet est disponible sur github.com/plainhub/plain-app. Vous pouvez inspecter chaque implémentation de chiffrement, compiler depuis les sources ou contribuer.
Reprenez le contrôle de votre téléphone.
Aucun intermédiaire cloud. Pas de frais mensuels. Juste votre téléphone et votre navigateur.