Security & Threat Model

An honest account of what we protect, how we protect it, and where the limits are.

privis.app is built so that the people running it — us — can read as little of your data as is technically possible. This page explains exactly how that works, and is honest about what encryption can and cannot do. If a claim here is not backed by the way the software actually works, it does not belong on this page.

(privis.app and its beta site seku.chat run the same software; everything below applies to both.)

In one screen

What we protect

• We never ask for a phone number or email. To sign up you choose only a username and a password — and both are secret.
• The only thing other people see is a nickname you also choose; that is how they find and message you. (Tip: don’t make your nickname your real name.)
• We never store your username — only a one-way hash of it that we cannot turn back into plaintext.
• Your password never leaves your browser.
• In Medium and Hard mode, your messages are encrypted with keys that never reach our servers — so we cannot read them, and neither can anyone who seizes or breaches the server.
• In Hard mode the encryption keys are generated on your device and never leave it (true end-to-end encryption).
• All traffic is protected by TLS, and the app reads no data directly from the database — every request goes through an identity-checked server function.

What we do not claim

• Easy mode is for convenience, not secrecy. Its key is held server-side, so in Easy mode we can technically read messages. But even then we do not know who you are: we collect no name, email or phone number; your login username is stored only as a hash we cannot reverse; and Easy-mode messages auto-delete within 24 hours. Use Medium or Hard for anything sensitive.
• We can still see metadata — which nickname messaged which, and when (the message content stays unreadable in Medium and Hard mode). This only points back to you if your nickname or messages reveal it — so don’t use your real name as your nickname.
• End-to-end encryption cannot protect a device that is already compromised (malware, or someone with your unlocked phone).
• We have completed a thorough internal and AI-assisted security review, but not yet a formal third-party audit (see the roadmap below).

Threat model

This table is the heart of the page: who might want to read your messages, and whether the design stops them.

How it works (the technical part)

Identity without phone or email

You register with a username and a password — nothing else, and both are secret. The only piece of your identity that is, by necessity, public is a nickname you also choose; that is how other people find and message you. Choose a nickname that does not reveal your real name — it is the one identifier we, and anyone else, can see in plaintext.

• The username is never sent to us in the clear. Your browser computes SHA-256(username) and only that hash is stored and used for lookup. We cannot turn the hash back into your username, and we hold no list of who our users are. (Honest limit: a hash of a guessable username can be confirmed by an attacker who already guesses the name — this stops us from holding your identity, not a determined guess of a known name.)
• The password never leaves your browser. The browser sends SHA-256(password + username), which the server stores bcrypt-hashed. We never see, log, or store your actual password.
• The nickname is stored in plaintext, because people must be able to find and message you by it. It is the single public part of your identity — so keep it unconnected to your real-world name.

Three encryption modes

You choose the trade-off per conversation.

• Easy — AES-256-GCM with a key stored server-side. Encrypted in transit and at rest, convenient and recoverable — but we hold the key, so it is not secret from us. Good for low-sensitivity chat.
• Medium — AES-256-GCM with a key derived from a passphrase that you and your partner share, via PBKDF2-SHA-256 (600,000 iterations). The passphrase and key never leave your devices. We cannot decrypt Medium messages.
• Hard — true end-to-end encryption. Each device generates an ECDH P-256 key pair; the private key never leaves the device. Sender and recipient derive a shared secret, run it through HKDF-SHA-256 (bound to the conversation), and encrypt with AES-256-GCM. The keys are generated on-device and never sent to us.

Verifying your Hard-mode partner (resisting a man-in-the-middle)

A malicious or compromised server could try to hand you the wrong public key. Two defences:

• Trust-on-first-use pinning — the first key seen for a partner is pinned locally; any later change is flagged so you can re-verify before trusting it.
• Safety number — both sides can compare a 160-bit code derived from both public keys. If the codes match, no one is in the middle.

Storing the Hard-mode key on your device

The private key stays on your device, wrapped with a PIN via PBKDF2-SHA-256 (600,000 iterations) → AES-256-GCM. Honest limitation: a numeric PIN is brute-forceable offline by anyone who steals the device, so the PIN is a convenience guard, not a substitute for device security.

Backups & account recovery

Your message archive is encrypted with a master key that is wrapped twice — once with your password, once with a set of recovery words you keep yourself — using PBKDF2-SHA-256 (600,000 iterations). We can help you restore your account without ever being able to read the archive, because you hold the recovery phrase, not us — we keep only a hash of it, to check it. Set your recovery phrase and keep it safe: if you lose it, no one — including us — can recover your archive.

Architecture: the app reads nothing directly

• The browser app makes zero direct database reads. Every operation goes through a server function that re-derives who you are from your session and checks access on the spot — the server never trusts an identity claimed by the client.
• Anonymous database access is revoked at the database level: an unauthenticated request is rejected outright, not merely returned empty.
• Real-time updates arrive as metadata-only broadcasts (message and sender identifiers, read receipts) — never message ciphertext. New content is fetched through the same identity-checked path.

Where your data lives

The service runs on infrastructure in the EU (Frankfurt), operated by Zumitomi Oy, a company based in Vantaa, Finland — so your data sits under EU/GDPR jurisdiction. Encrypted daily backups are kept for recovery.

What you can do to protect yourself

Security is a shared job, and the strongest steps are yours to take:

• Don’t use your real name as your nickname — it is the one part of your identity that is public.
• Lock your device and use a strong device passcode. End-to-end encryption cannot protect a phone someone else can open.
• Sign out of privis.app when you are not using it.
• Use a strong PIN for your Hard-mode key.
• Delete what you no longer need. You can delete any message, a whole conversation, or your entire account at any time — and it is removed from your chat partner’s side too. Every message also has a maximum lifetime and auto-deletes on its own; Easy-mode messages always disappear within 24 hours.

Honest limitations & non-goals

• Easy mode is not private from us — by design; it exists for convenience. This is how most mainstream messengers work too — except they usually also require your phone number or email, and keep your messages indefinitely. We require neither, and Easy-mode messages auto-delete within 24 hours.
• Metadata is minimised, not eliminated. Delivering a message requires knowing the sender and recipient accounts (by nickname) and the time. We never see your real username (only a hash), phone or email — so if your nickname is not your real name, this metadata does not identify you. For security we also record the IP address and browser of each login; you can review it in your login history — and clear it yourself at any time — in Settings.
• No per-message forward secrecy yet. Hard-mode keys are long-lived per device, so a future compromise of a device’s key could expose that device’s past Hard-mode messages in a conversation. Moving to ephemeral per-message keys is on the roadmap.
• Hard mode is one device per account at a time — the private key lives on a single device.
• A compromised device defeats any messenger. Keep your device locked and clean.
• No formal third-party audit yet. What exists today is a thorough internal and AI-assisted review.

Roadmap to verifiability

Trust should not require taking our word for it. The following is our planned direction — clearly labelled as planned, not yet shipped:

• Open-source the client. The browser-side code is the part that actually performs the encryption, so it is where the security-critical work happens. We intend to publish it, so anyone can read exactly what your device does with your messages and keys.
• A browser verification extension. Inspired by published “code verify” approaches, an optional extension would let technically-minded users confirm that the code their browser runs matches the published open source. That closes the gap between “the source is open” and “the open source is what is actually running.”
• A formal third-party security audit, once the above is in place.

We will update this page as each step lands.

Prefer the plain-language version? Read How Encryption Works.