Security & Transparency Report

When you send a message, it is encrypted on your own device before it leaves, and can only be decrypted on the recipient's device. VOIDEX uses a hybrid design · a classical algorithm and a post-quantum algorithm are combined, so the encryption is never weaker than today's standard and additionally resists a future quantum computer.

• Direct messages use a post-quantum Double Ratchet: the key agreement combines X25519 (classical) with ML-KEM-768 (NIST post-quantum), identities are signed with Ed25519 + ML-DSA-65, and the session periodically re-keys with fresh post-quantum material for forward secrecy.
• Groups and channels use MLS (RFC 9420) with a hybrid post-quantum ciphersuite · X-Wing (X25519 + ML-KEM-768) key encapsulation and ML-DSA-87 signatures · giving forward secrecy, and post-compromise security when members are added or removed (a removed member is cryptographically evicted; anything sent afterwards is unreadable to them).
• Every message, file and voice note is sealed with AES-256-GCM; the keys are derived with HKDF-SHA-256. Only you hold your recovery key.

"Harvest now, decrypt later" is the real threat: an adversary can record encrypted traffic today and decrypt it once quantum computers mature. The defence is post-quantum cryptography. Here is an honest, side-by-side look at where the major platforms stand today · verified from each one's own published protocol documentation (September 2026).

Voice and video calls are peer-to-peer and encrypted end-to-end by DTLS-SRTP · mandatory in the underlying WebRTC standard, with no unencrypted mode. The small "let's connect" handshake is additionally sealed under your conversation (or channel) key so it can't be tampered with (anti-impersonation) · if it cannot be sealed, the call does not connect rather than falling back to an unsealed handshake. When two devices can't reach each other directly, media is relayed through VOIDEX's own relay, which only ever forwards already-encrypted packets it cannot open, using short-lived credentials, in relay-only mode so the two callers never even learn each other's IP address. Call encryption today is strong classical end-to-end encryption · the same standard every major platform uses for calls · and extending post-quantum protection to live calls is on our roadmap.

Encryption hides what you say. It cannot hide that your device is connected, because the internet is built on addressing: to deliver anything to you, something has to know where you are. Every service you have ever used works this way. Most do not say so.

• No advertising. There is no ad network in VOIDEX, no ad profile, and nothing about you is sold, rented or shared with data brokers. We are not funded by knowing things about you.
• No third-party trackers. No analytics SDK, no tracking pixel, no social login beacon. The app talks to our servers and to nothing else.
• No enrichment. We do not combine your address with outside datasets to infer who or where you are.

• Regional news is tagged by turning an address into a country name in memory. The address itself is not stored for it.
• No public post, profile or Phantom page carries an address field of any kind.
• A remote image on a public page is fetched by our servers and re-served from our own domain · so someone who posts content cannot use it to collect the IP addresses of everyone who scrolls past.
• Relayed calls run in relay-only mode, so the two people on a call never learn each other's address either.

End-to-end encryption has one classic weak point: your app learns your contacts' public keys from the service. A dishonest or hacked service could hand you a key it controls and read along. VOIDEX closes this with a public, append-only key-transparency log:

• Every key our directory ever hands out · every device enrolled, every device removed · is written to a Merkle log (RFC 6962, the same construction behind Certificate Transparency) in the same database transaction as the directory change itself.
• The log's signed tree heads and cryptographic proofs are public, no account needed. Anyone can verify the log only ever grows and never rewrites history.
• Your app refuses a contact's keys unless every one of their devices is proven to be in the log with exactly those keys. A device that exists only in the directory · the "ghost device" attack · is rejected, not merely flagged.
• Every message you send carries your app's current view of the log; the receiver checks it against theirs. If VOIDEX ever showed two people different logs, their apps find out when they talk.
• Your own account is watched too: a device the log lists for you that your app has never seen raises an alert.
• An independent witness on separate infrastructure keeps its own copy of every head and alerts if the log shrinks, forks, or changes its key. We will add outside witnesses after the third-party audit.

This is the whole point, and the strongest check no longer needs a browser, an account, or anything from us at all.

1. Open your browser's developer tools and watch the Network panel while you send a message.
2. Inspect the request your device sends. The message body travels as ciphertext · an opaque encrypted blob · not readable text. That request is exactly what our servers receive and exactly what they store. Compare it against the send path above: what you see on the wire is what that code produces.
3. Inside any chat, open Security → Preview Live Encryption to see every message exactly as our servers hold it · ciphertext only, labelled by scheme (MLS, post-quantum Double Ratchet, or AES-256-GCM). That is the view an operator or a subpoena gets.
4. Compare a safety number with the person you are talking to, then verify the derivation yourself against src/crypto/safety.js.
5. Follow the public key-transparency log (§6) and check the tree maths against src/crypto/merkle.js.
6. For calls, the media never passes through our servers in a readable form; when relayed, it is encrypted SRTP the relay cannot decode.

Private messaging is a solved shape: lock the content, hand out no keys. Speaking publicly without being traceable is a different and harder problem, because everything you post is meant to be seen. In VOIDEX Space you can act as an anonymous Phantom alongside your real Face, and the standard we hold it to is the same one we hold the encryption to: real anonymity, not "anonymous but guessable."

• Capture metadata inside your own media. A phone writes GPS coordinates, altitude, device model and a timestamped timezone into the file itself · on an anonymous post, that is a home address travelling with the picture. Every upload is stripped before it is stored, and a file we cannot clean is refused rather than kept as it arrived. Full detail in §9, because this one protects everybody, not only Phantoms.
• Your address, to other members. Covered in §5: remote media is proxied by us, so viewing an anonymous post cannot expose the viewer, and posting one cannot expose the poster.
• Proximity signals. No location tagging, no friend-graph suggestions built from a Phantom, and no surface that ranks or reveals Phantoms by who they are near.

This one is not about encryption, and it protects every member · your Face exactly as much as your Phantom, across Space, Orbits, comments and profile media alike. Files carry far more than their contents, and almost nobody looks.

• Images are rebuilt, not edited. The file we store is re-encoded from the pixels alone, so there is no metadata block to carry across · nothing is carried across. An image we cannot process is refused with an error, never quietly stored as it arrived.
• Video is stripped at every level, before it is published. Container tags, chapters and per-stream metadata are all discarded, and only the picture and sound tracks survive · the extra timecode and sensor tracks a phone attaches are dropped entirely. That last part matters: once the obvious tags are gone, a separate track is exactly where location data tends to still be hiding. If a file cannot be cleaned, the post is refused rather than published dirty.
• Animated uploads are converted. A GIF posted in a comment, or used as a profile banner, is re-encoded into a silent looping video on the way in. The GIF format has no field for capture data in the first place · no camera writes one · so there is nothing there for a phone to have left behind.
• The original is not kept. Once the processed versions of a video exist, the source file is deleted · the stripped copies are the only copies that remain. There is no pristine original sitting in our storage waiting to be asked for.
• The filename never travels. A filename says more than people expect: the device that made it, sometimes the exact second, sometimes a name a person typed.

Any company that tells you it's "perfectly secure" is lying. Here is where the guarantees end:

• Your device. Encryption protects data in transit and on our servers · it cannot protect a phone that has malware on it or is handed over unlocked. After a message is decrypted for you to read, it lives on your screen.
• Scope of post-quantum. Post-quantum protection covers your end-to-end message and group content. Live calls today use strong classical end-to-end encryption (post-quantum calls are on the roadmap), and the hybrid design means content is always at least as safe as today's standard encryption.
• Trusting the delivered code. Like any web app, you are trusting that the code your browser receives is the honest code. Three things narrow that. The app ships with an enforced Content-Security-Policy (only our own scripts can run · no inline script, no injected script, no framing), which shuts the classic script-injection route to your keys. The cryptographic core is now published (§7), so the code that decides what leaves your device can be read and tested independently of anything we serve. And comparing a person's safety number confirms nobody is intercepting your keys regardless of any of the above. The gap that remains, stated plainly: because the published repository is the cryptographic core rather than the entire application, you cannot yet build it and hash-compare the result against the bundle we serve. Reproducible builds are a real gap and they are on the roadmap · we would rather name it than let a published repository imply more than it proves.
• Metadata. As noted, the fact that a conversation happened · and the network addresses involved · is visible to the operator, even though the content is not.
• Key directory trust. Every device signs its own keys with an account identity only your devices hold, contacts pin it, and every key must additionally be proven present in the public transparency log (§6). What remains: a swap of your whole account identity at first contact would still be flagged rather than blocked, and the log's independent witness is currently run by us on separate infrastructure · outside witnesses and a public log mirror come after the audit. Comparing safety numbers in person remains the definitive check.
• Keys on your device. Your keys are sealed on the device under a key the browser itself keeps non-exportable; with a PIN enabled, that device key exists only wrapped under your PIN, so a copied profile is useless without it. None of this protects against malware or someone holding your unlocked phone. Your recovery key can restore your identity and open your encrypted history, so treat it like a master key: it is the one secret that reaches the past.
• What is in the frame. As §9 says: we strip what a file says, never what a photograph shows. No cryptography touches a street sign, a house number or a reflection in a window.
• How you write. We build no stylometric tooling and deliberately expose no surface for it. But a person with a distinctive voice can be recognised by other people, and that is outside what any platform can engineer away.
• Our own position. Face/Phantom separation is enforced on the server, in our code and our database · which means the published client (§7) does not evidence it, and you are trusting that we built it as described and run it that way. That is exactly the trust an independent audit exists to replace with evidence · see §11 · and until then it is a claim about us, not a proof.
• The VOIDEX Support chat. The built-in "VOIDEX" conversation is a chat with us — naturally, a message you send to support is received by support so we can help you. Every other conversation is end-to-end encrypted and unreadable to us.

Found something? We want to hear it. Report security issues to security@voidex.us. We do not pursue good-faith researchers, and we credit those who help us harden the platform.