Vérifiez en 2 minutes
Appuyez sur F12 dans votre 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 |
| Votre historique vit dans votre navigateur | Application → IndexedDB → solo2-vault-{userId}. Tous vos messages et fichiers sont là. Le serveur n'a rien. |
Application |
| Liste de contacts uniquement locale | Application → IndexedDB → store pares. Vos contacts n'existent que dans votre 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érifiez l'horodatage d'expiration. Il n'est jamais supérieur à 24h depuis la création. |
Application |
| Vous pouvez voir quel type de connexion vous utilisez | Dans l'interface de chat : indicateur P2P (vert) vs Mirror/TURN (orange) visible en permanence. | UI |
| Umami est sans cookies | Application → Cookies → aucun cookie de stats.menzuri.com n'apparaît. Umami compte les visites sans vous identifier. |
Application |
| Votre 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 votre mot de passe — c'est une clé indépendante avec 256 bits d'entropie réelle | Application |
Si vous savez utiliser les DevTools
Vérifications qui nécessitent des connaissances techniques. Si vous comprenez HTTP, WebRTC et la cryptographie de base, vous pouvez vérifier ceci vous-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 relay. Inspectez 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. Vous ne pouvez pas vérifier quel algorithme le serveur utilise (Argon2id), mais vous pouvez voir que votre mot de passe original ne quitte jamais le navigateur. |
| Les demandes de jumelage expirent en 3 jours | Créez une demande, n'y répondez pas, vérifiez 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). Vous pouvez voir le payload chiffré dans l'onglet Network. |
| Connexion P2P directe vs relay | chrome://webrtc-internals/ → affiche les candidats ICE et le type de connexion actif. Si les deux pairs sont sur le même réseau, vous devriez voir des candidats host (direct, sans relay). |
Vous ne pouvez pas vérifier ceci
Nous serions hypocrites si nous disions que tout est vérifiable. Ces affirmations nécessitent que vous nous fassiez confiance dans une certaine mesure — ou que vous attendiez 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. Vous pouvez voir que 24 mots sont générés, mais vous ne pouvez 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 est « complètement aveugle » | Vous pouvez 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 | Vous ne pouvez pas vérifier ce que le serveur enregistre dans ses logs. |
| Les clés tournent à chaque message | Se produit à l'intérieur de WASM. Vous voyez les messages envoyés, mais vous ne pouvez pas observer la rotation des clés. |
| Les données supprimées disparaissent vraiment | Vous pouvez supprimer d'IndexedDB local, mais vous ne pouvez 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 votre 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 vous pouvez lire la logique. WASM ne l'est pas : c'est du code machine compilé, comme une application native. Vous pouvez voir qu'il s'exécute, mais pas comment il fonctionne à l'intérieur.
Nous disons que c'est Double Ratchet avec X25519. Vous pouvez nous faire confiance, ou vous pouvez 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 vous puissiez 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 du coffre-fort) et rotation Double Ratchet. Chaque couche est indépendante et vérifiable dans notre Manifeste de Transparence.