Check it in 2 minutes
Press F12 in your browser. No need to install anything. No programming knowledge required.
| Claim | How to verify | Tab |
|---|---|---|
| No cookies of any kind | Application → Cookies → empty. Solo2 does not install any cookies. Your session is maintained in localStorage, not in cookies. No _ga |
Application |
| No third-party services in the app | Network → filter by domain → only requests to solo2.net |
Network |
| Analytics only on landing, not in the app | Network → only on landing (root), not on /app/* |
Network |
| Your history lives in your browser | Application → IndexedDB → solo2-vault-{userId}. All your messages and files are there. The server has nothing. |
Application |
| Contact list is local only | Application → IndexedDB → store pares. Your contacts exist only in your browser. |
Application |
| No external CDNs | Network → all JS/CSS load from the same domain. No cdn.jsdelivr.net, no googleapis.com, no cloudflare.com. Everything is ours. |
Network |
| Sessions last 24 hours maximum | Application → localStorage → solo2_session. Check the expiry timestamp. It's never more than 24h from creation. |
Application |
| You can see what type of connection you're using | In the chat UI: P2P indicator (green) vs Mirror/TURN (orange) visible at all times. | UI |
| Umami is cookieless | Application → Cookies → no cookie from stats.menzuri.com appears. Umami counts visits without identifying you. |
Application |
| Your master key is generated randomly | Application → when you register, Solo2 generates 24 unique words. They are not derived from your password — they are an independent key with 256 bits of real entropy | Application |
If you know how to use DevTools
Verifications that require technical knowledge. If you understand HTTP, WebRTC and basic cryptography, you can check these yourself.
| Claim | How to verify |
|---|---|
| Messages encrypted E2E | Network → requests to /cmd carry binary payloads. The body is an opaque blob, not readable JSON. The server receives cyphertext it cannot decrypt. |
| WebRTC signals encrypted E2E | Network → signal messages travel as encrypted binary blobs. They are not readable JSON with candidate or sdp in plain text. |
| Master key independent from password | Network → login receives an encrypted wrapped_master_key |
| Uniform padding in mirror | Network → WebSocket/DataChannel packets have fixed size when using relay. Inspect the sizes in the Network tab — they should all be identical regardless of message length. |
| Password is protected (never travels in plain text) | Network → the login sends a hash, not plain text. You cannot verify which algorithm the server uses (Argon2id), but you can see that your original password never leaves the browser. |
| Pairing requests expire in 3 days | Create a request, don't respond to it, verify after 3 days that it has disappeared. Requires patience and two accounts. |
| Push notifications are encrypted | Network → push requests to the Service Worker arrive encrypted (standard Web Push). You can see the encrypted payload in the Network tab. |
| Direct P2P connection vs relay | chrome://webrtc-internals/ → shows ICE candidates and the active connection type. If both peers are on the same network, you should see host candidates (direct, no relay). |
You can't verify this
We would be hypocrites if we said everything is verifiable. These claims require you to trust us to some degree — or to wait until we publish the source code.
| Claim | Why it's not verifiable |
|---|---|
| Double Ratchet with key rotation | Cryptographic operations happen inside a WASM binary. The user sees it loading, but cannot inspect the internal algorithms. |
| The master key is generated with real entropy (256 bits) | The key generation happens inside WASM using the system's CSPRNG. You can verify that window.crypto.getRandomValues is called, but not what WASM does with the result internally. |
| X25519 + Ed25519 + ChaCha20-Poly1305 | Same problem: the cryptographic stack is inside WASM. The curves and algorithms used cannot be confirmed without source code. |
| The server is "completely blind" | You can verify that the client doesn't send readable data. What the server does with metadata (IPs, timestamps) is not externally observable. |
| The server doesn't store relationships after pairing | Requires access to the server's code and database. |
| IPs are not logged | You cannot verify what the server records in its logs. |
| Keys rotate with every message | Happens inside WASM. You see messages being sent, but you cannot observe key rotation. |
| Deleted data truly disappears | You can delete from local IndexedDB, but you cannot verify that the server doesn't retain copies (although technically it has no reason to, since it never had the decrypted content). |
Why WASM is a real barrier
Solo2's cryptographic layer is compiled in WebAssembly — a binary format that your browser executes but that cannot be easily inspected or decompiled into readable source code.
Minified JavaScript (which we use for the interface) is reversible: the browser can reformat it and you can read the logic. WASM is not: it's compiled machine code, like a native application. You can see that it runs, but not how it works inside.
We say it's Double Ratchet with X25519. You can trust our word, or you can wait until we publish the crypto source code as an open repository. Meanwhile, the verifiable parts (network, storage, cookies, connections) are open to inspection by anyone with a browser.
What we're doing so you can trust more
Publish SHA-256 hashes of .wasm files
We will publish the cryptographic hash of each production WASM file. This way any auditor can verify that the file served by the server matches the compiled version.
Open the crypto layer as open source
Publish the source code of the cryptographic layer (Zig) as a public repository. The same model as Signal's libsignal. Anyone can compile, compare the binary with the one in production, and verify that we are running what we say we are running.
Security doesn't depend on obscurity
Our security model is designed to work even if the source code is public. If the architecture is sound, publishing the code makes it stronger, not weaker. That's the goal.
5 documented security layers
Password (server access), 24 words (real master key), device secret (vault protection) and Double Ratchet rotation. Each layer is independent and verifiable in our Transparency Manifesto.