Vérifie en 2 minutes
Appuie sur F12 dans ton navigateur. Pas besoin d'installer quoi que ce soit. Aucune connaissance en programmation requise.
| Affirmation | Comment vérifier | Onglet |
|---|---|---|
| Aucun cookie d'aucune sorte | Application → Cookies → vide. Solo2 n'installe aucun cookie. Ta session est maintenue dans localStorage, pas dans les cookies. Sans _ga |
Application |
| Aucun service tiers dans l'application | Network → filtrer par domaine → uniquement des requêtes vers solo2.net |
Network |
| Analytics uniquement sur le landing, pas dans l'app | Network → uniquement sur le landing (racine), pas sur /app/* |
Network |
| Ton historique vit dans ton navigateur | Application → IndexedDB → solo2-vault-{userId}. Tous tes messages et fichiers sont là. Le serveur n'a rien. |
Application |
| Liste de contacts uniquement locale | Application → IndexedDB → store pares. Tes contacts n'existent que dans ton navigateur. |
Application |
| Pas de CDN externes | Network → tous les JS/CSS se chargent depuis le même domaine. Pas de cdn.jsdelivr.net, pas de googleapis.com, pas de cloudflare.com. Tout est à nous. |
Network |
| Sessions de 24h maximum | Application → localStorage → solo2_session. Vérifie l'horodatage d'expiration. Il n'est jamais supérieur à 24h depuis la création. |
Application |
| Tu peux voir quel type de connexion tu utilises | Dans la liste de contacts : à côté de chaque contact, P2P (vert) ou Miroir (orange) | UI |
| Umami est sans cookies | Application → Cookies → aucun cookie de stats.menzuri.com n'apparaît. Umami compte les visites sans t'identifier. |
Application |
| Ta clé maîtresse est générée aléatoirement | Application → lors de l'inscription, Solo2 génère 24 mots uniques. Ils ne sont pas dérivés de ton mot de passe — c'est une clé indépendante avec 256 bits d'entropie réelle | Application |
Si tu sais utiliser les DevTools
Vérifications qui nécessitent des connaissances techniques. Si tu comprends HTTP, WebRTC et la cryptographie de base, tu peux vérifier ceci toi-même.
| Affirmation | Comment vérifier |
|---|---|
| Messages chiffrés E2E | Network → les requêtes vers /cmd transportent des payloads binaires. Le corps est un blob opaque, pas du JSON lisible. Le serveur reçoit du texte chiffré qu'il ne peut pas déchiffrer. |
| Signaux WebRTC chiffrés E2E | Network → les messages de signal voyagent sous forme de blobs binaires chiffrés. Ce n'est pas du JSON lisible avec candidate ou sdp en clair. |
| Clé maîtresse indépendante du mot de passe | Network → le login reçoit un wrapped_master_key |
| Padding uniforme en mirror | Network → les paquets WebSocket/DataChannel ont une taille fixe lors de l'utilisation du miroir (TURN). Inspecte les tailles dans l'onglet Network — elles doivent toutes être identiques quelle que soit la longueur du message. |
| Mot de passe protégé (ne voyage jamais en clair) | Network → le login envoie un hash, pas du texte en clair. Tu ne peux pas vérifier quel algorithme le serveur utilise (Argon2id), mais tu peux voir que ton mot de passe original ne quitte jamais le navigateur. |
| Les demandes de jumelage expirent en 3 jours | Crée une demande, n'y réponds pas, vérifie après 3 jours qu'elle a disparu. Nécessite de la patience et deux comptes. |
| Notifications push chiffrées | Network → les requêtes push vers le Service Worker arrivent chiffrées (standard Web Push). Tu peux voir le payload chiffré dans l'onglet Network. |
| Connexion P2P directe vs miroir (TURN) | chrome://webrtc-internals/ → affiche les candidats ICE et le type de connexion actif. Si les deux pairs sont sur le même réseau, tu devrais voir des candidats host (direct, sans relay). |
Tu ne peux pas vérifier ceci
Nous serions hypocrites si nous disions que tout est vérifiable. Ces affirmations nécessitent que tu nous fasses confiance dans une certaine mesure — ou que tu attendes que nous publiions le code source.
| Affirmation | Pourquoi ce n'est pas vérifiable |
|---|---|
| Double Ratchet avec rotation des clés | Les opérations cryptographiques se produisent à l'intérieur d'un binaire WASM. L'utilisateur voit qu'il se charge, mais ne peut pas inspecter les algorithmes internes. |
| La clé maîtresse est générée avec de l'entropie réelle (256 bits) | La génération utilise crypto.getRandomValues dans le navigateur. Tu peux voir que 24 mots sont générés, mais tu ne peux pas vérifier depuis F12 la qualité de l'entropie ni que le CSPRNG est sûr |
| X25519 + Ed25519 + ChaCha20-Poly1305 | Même problème : la pile cryptographique est à l'intérieur de WASM. Les courbes et algorithmes utilisés ne peuvent pas être confirmés sans code source. |
| Le serveur ne peut pas lire le contenu de tes messages | Tu peux vérifier que le client n'envoie pas de données lisibles. Ce que le serveur fait avec les métadonnées (IPs, horodatages) n'est pas observable de l'extérieur. |
| Le serveur ne conserve pas les relations après le jumelage | Nécessite l'accès au code et à la base de données du serveur. |
| Les IPs ne sont pas enregistrées | Tu ne peux pas vérifier ce que le serveur enregistre dans ses logs. |
| Les clés tournent à chaque message | Se produit à l'intérieur de WASM. Tu vois les messages envoyés, mais tu ne peux pas observer la rotation des clés. |
| Les données supprimées disparaissent vraiment | Tu peux supprimer d'IndexedDB local, mais tu ne peux pas vérifier que le serveur ne conserve pas de copies (bien que techniquement il n'ait aucune raison de le faire, puisqu'il n'a jamais eu le contenu déchiffré). |
Pourquoi WASM est une barrière réelle
La couche cryptographique de Solo2 est compilée en WebAssembly — un format binaire que ton navigateur exécute mais qui ne peut pas être facilement inspecté ou décompilé en code source lisible.
Le JavaScript minifié (que nous utilisons pour l'interface) est réversible : le navigateur peut le reformater et tu peux lire la logique. WASM ne l'est pas : c'est du code machine compilé, comme une application native. Tu peux voir qu'il s'exécute, mais pas comment il fonctionne à l'intérieur.
Nous disons que c'est Double Ratchet avec X25519. Tu peux nous faire confiance, ou tu peux attendre que nous publiions le code source crypto comme un dépôt public. En attendant, les parties vérifiables (réseau, stockage, cookies, connexions) sont ouvertes à l'inspection de quiconque possède un navigateur.
Ce que nous faisons pour que tu puisses faire davantage confiance
Publier les hashes SHA-256 des fichiers .wasm
Nous publierons le hash cryptographique de chaque fichier WASM en production. Ainsi tout auditeur pourra vérifier que le fichier servi par le serveur correspond à la version compilée.
Ouvrir la couche crypto en open source
Publier le code source de la couche cryptographique (Zig) comme dépôt public. Le même modèle que libsignal de Signal. N'importe qui peut compiler, comparer le binaire avec celui en production, et vérifier que nous exécutons ce que nous disons exécuter.
La sécurité ne dépend pas de l'obscurité
Notre modèle de sécurité est conçu pour fonctionner même si le code source est public. Si l'architecture est solide, publier le code la rend plus forte, pas plus faible. C'est l'objectif.
5 couches de sécurité documentées
Mot de passe (accès au serveur), 24 mots (vraie clé maîtresse), secret d'appareil (protection des données locales) et rotation Double Ratchet. Chaque couche est indépendante et vérifiable dans notre Manifeste de Transparence.