Learn

On Facebook Messenger, Instagram DMs, Snapchat, Discord, Slack, or Telegram's default chats, your message goes from your phone to the company's servers, is stored there, and is then delivered. In that middle step the company holds a readable copy of what you wrote.

That copy powers search, backups, and syncing between your phone and laptop. It also means the message is only as private as the company's promise not to look, and as secure as the systems behind that promise. The copy can be:

Read to target ads or train models. Who you talk to, about what, and how often is valuable to platforms that make money from knowing about you.

Handed over on demand. A company that can read your messages can be compelled to share them with a government or law enforcement, including for reasons unrelated to any crime. Journalists, activists, protesters, and ordinary people have had private messages pulled this way. (For background, see the Guardian's NSA Files and the 2013 global surveillance disclosures, and the EFF's ongoing coverage of surveillance.)

Stolen in a breach. When a company is hacked, the attacker can read whatever the company could.

None of this requires a malicious company. A well-meaning one can be bought, breached, or served a court order, and "we won't look" can change with a new owner or a new law. The fix is a system where the company cannot read your messages, even if it wanted to or were forced to. That is what Pollis does.

On most messaging apps, your privacy rests on a company keeping a promise. A company can be hacked, bought, or handed a court order regardless of what it promised. Pollis is built so that we are unable to read your messages, rather than merely choosing not to. Here is who can see what.

Your device sees everything. You type and read there, so that is the only place messages are decrypted. Someone who gets into your unlocked device can read what is on it; no cryptography prevents that.

Our servers see the envelope, not the letter. They carry sealed messages they cannot open, because the keys never leave your devices. They do see delivery information: that an account sent something, roughly when, roughly how big, and to which conversation. Even under a court order, that metadata is all a server can produce. Your messages, calls, and keys never exist on our side in readable form.

Getting the right key to the right person takes care. Encryption only helps if the key your app uses really belongs to the person you meant. Safety numbers (Topic 6) and our public key logs (Topic 9) let you confirm that yourself.

Calls are covered too. Voice and video go through a media server, but each audio and video frame is encrypted on your device with a key derived from the conversation's MLS group. The media server forwards frames it has no key for, and the key rotates whenever the group's membership or keys change.

Encryption is what removes the readable copy. It scrambles a message so that only someone with the right key can turn it back into text (see Wikipedia's definition). Done end to end, the message is scrambled on your device and unscrambled only on the recipient's, so the servers in between carry noise (see end-to-end encryption, and how Signal describes the same idea).

The same technology protects online banking, the padlock in your browser's address bar, your phone's storage, and your password manager. Surveillance of private citizens is documented, not hypothetical: the 2013 disclosures documented bulk collection of ordinary people's communications, and the EFF tracks cases where private messages were demanded for reasons unrelated to any crime.

Four terms appear on every page that follows. None needs math.

A key is a very large, randomly chosen number. Large enough that trying every possibility is out of reach. A symmetric key (the kind AES-256 or ChaCha20 uses) is one of 2²⁵⁶ possible values. By Bruce Schneier's thermodynamic argument, a perfect computer running at the theoretical minimum energy per step would need more energy than the Sun will emit in its remaining lifetime just to count through 2¹²⁸ values. Public-key algorithms use different math: a 256-bit elliptic-curve key like the X25519 keys Pollis uses gives roughly 128 bits of security, still far beyond any feasible attack. "A key never leaves your device" means that number stays in your device's secure storage and is never sent to us.

Encryption is a lock that scrambles. Your message plus a key gives noise; the noise plus the right key gives your message back. The wrong key gives you nothing, not a partial or blurry version.

A key can come in two different halves. One is public, one private. Anything locked with the public half can only be opened with the private half, so you can publish the public half while the private half stays on your device. Anyone can then send you something only you can open, without agreeing on a secret in advance.

Signatures run the same idea in reverse. Sign something with your private half and anyone with your public half can confirm it came from you and was not altered. Change one character and the check fails.

A hash is a fingerprint for data. Any input, of any size, gives a short string. The same input always gives the same fingerprint, changing one character gives a completely different one, and you cannot work backwards to the input. That lets you say "this is exactly the file I meant" without publishing the file. The long root codes on our artifacts page are hashes.

The algorithms. For scrambling a message with a shared key, common ones are AES and ChaCha20; Pollis's group messages use ChaCha20-Poly1305. For agreeing on a shared key over an untrusted network, Pollis uses X25519, an elliptic-curve key exchange, carried inside MLS by HPKE, paired with ML-KEM-768, a key exchange designed to resist quantum computers. The two are combined by a construction called X-Wing, so an attacker has to break both. Large quantum computers do not exist yet, but someone can record traffic today and wait. For the same reason, Pollis signs with ML-DSA-44 rather than Ed25519, which most of the internet still uses. (A signature scheme signs; it does not encrypt. RSA is an older algorithm that can do both.) For fingerprints, Pollis uses the SHA-2 family: SHA-256 in the transparency logs and for attachments, SHA-384 inside MLS. All of these are public and well studied; their security depends on keeping the key secret, not the method.

The obvious way to encrypt for a group is to encrypt each message separately for every member: four copies for five people, ninety-nine for a hundred. That gets slow and expensive, and when someone leaves, everyone needs fresh keys from everyone else.

Pollis uses MLS, Messaging Layer Security (RFC 9420), which arranges the group as a tree. Every member is a box along the bottom. Boxes pair up into boxes above them, up to a single box at the top. Each box holds a key, and you know the keys on the line from your box to the top. The top key is shared by everyone and protects the group's messages.

When something changes, whoever makes the change sends one small update along their line, and each part of the group derives the piece it needs from what it already knows. The cost drops from one message per member to about the height of the tree: roughly seven steps for a hundred people, about ten for a thousand.

Two terms used throughout Pollis. An epoch is the group's version number; it increments every time the keys change. A commit is the update that increments it, such as adding someone or refreshing keys. Every device must apply commits in the same order. Keeping that order right across devices and reconnections is one of the hardest parts of Pollis, and it is why every commit is recorded in a public log (Topic 9).

To add you to a group, someone has to lock the group's current keys so only you can open them, even while you are offline. So every Pollis device publishes small lockboxes in advance, called key packages: anyone can drop something in, only that device can open it. When someone adds you, they seal the group's current state into one and send you a welcome. You open it with your private key, and you are in.

The welcome carries the keys as they are now, not the keys from before you joined. It cannot, because MLS is designed so that new keys reveal nothing about old ones; that is the same property that makes removal work. So you cannot read messages sent to a group before you joined. The app is not hiding them; the keys do not exist on your device. Every app built on this standard behaves the same way.

Leaving. When a member is removed, everyone else moves to fresh keys and the removed device cannot read anything new. What it already saw stays on it. Removal is enforced by the keys, not by a server setting you have to trust.

Your own devices work the same way. Your phone and laptop are separate members of each group, with their own keys. Keys are never copied between them, since a key in transit can be stolen. Adding your laptop is like adding a person.

That leads to the sharp edge: a new device starts empty. There is no history backup. Your old messages live on your old device and nowhere else. Our servers only ever held sealed envelopes, and we do not make a backup.

The usual backup design stores your history on the server behind a PIN or passphrase. That puts a copy of your conversations on our infrastructure, guarded by something short and guessable, which is what Pollis exists to avoid. If you want your history on a new device, keep the old one.

Suppose someone copies a key off your device today. What do they get, looking backward in time and forward?

The past: forward secrecy. Nothing. Each new key is derived from the previous one by a one-way step that cannot be reversed, and used keys are deleted. A key stolen today opens today's messages; the material for yesterday's no longer exists. (To handle messages that arrive out of order, the protocol briefly keeps a small, bounded set of recent message keys, so the boundary is that window rather than a hard line.)

Forward secrecy protects recorded network traffic, not your device. Your messages are stored decrypted in a local database so the app can show them instantly, and that database is protected by a key in your operating system's keystore. Someone inside your unlocked device can read your history directly. What forward secrecy guarantees is that traffic recorded months ago stays sealed, even with a key stolen today.

The future: post-compromise security. Normally a stolen key keeps working until you notice and start over. In MLS the group heals on its own. Ordinary updates, such as adding a member or a routine key refresh, replace keys along part of the tree. Once a member the attacker does not control makes an update, the stolen key stops working, without anyone having to notice the theft.

This is the payoff of the tree from Topic 3: rekeying is cheap, so it happens often, and the window in which a stolen key is useful stays short. It does not open backward, and it closes on its own.

Photos, voice clips, and PDFs follow the same rule as text: the operator never sees the contents. They take a slightly different path, though.

Before anything leaves your device, it takes a fingerprint of the file (a SHA-256 hash of the exact bytes), derives a key from that fingerprint, encrypts the file with AES-256-GCM, and uploads only the encrypted result to Cloudflare R2, an S3-style object store. Your device never holds storage credentials: it asks the Delivery Service for a short-lived, pre-signed upload link.

The fingerprint goes inside the encrypted message, so MLS protects it along with the text. Only people in the conversation learn which stored blob a message points at, and only they can re-derive the key to open it.

Why derive the key from the file? So identical files cost storage only once. If two people send the same 8 MB slide deck, both uploads produce the byte-for-byte identical encrypted blob, and the second upload is skipped. This is called convergent encryption.

Most chat apps search your messages on their servers. Pollis cannot: the server only holds ciphertext, so there is nothing for it to search. A server-side search box would prove the encryption did not work.

Search runs on your machine instead. Pollis keeps a full-text index inside the same encrypted local database that holds your decrypted messages, updates it as messages arrive, change, or are deleted, and queries it locally. What you searched for and what you found are never sent anywhere.

The consequence: search covers what this device holds, which is less than everything you have ever been part of. A message can be missing for reasons unrelated to your search terms:

Encryption does not, on its own, tell you who is on the other end. When you first message someone, your app fetches their public key from our servers. If the wrong key were handed over, a message could be read in the middle while both sides still saw a padlock, because the encryption works perfectly on the wrong key. Every encrypted messenger has this gap. Pollis addresses it two ways.

Safety numbers. Your app combines your key and your contact's key into a 60-digit code, shown as twelve 5-digit blocks. You both compute the same code from the same pair of keys; different keys give different codes. Compare them over a channel an eavesdropper cannot touch (side by side, read aloud on a call, or by scanning a QR code) and a mismatch shows up immediately.

That only helps if you compare, and most people never do. The second safeguard works even when nobody checks.

A public key log. Every identity key Pollis lists for an account goes into an append-only public log (Topic 9). Your app checks that the key the log shows for you matches the key you hold, and alerts you if they disagree. A substituted key would sit in a permanent public record, and the real owner's device would flag it. The log is republished daily, so a swapped key surfaces within about a day, the same bound Certificate Transparency uses for web certificates.

Trust on first use. The first time you talk to someone, your app remembers their key and flags any later change. Changes are usually innocent (a new phone, a reinstall), so a flag is a prompt to re-check before sharing anything sensitive, not an accusation. Pollis shows a shield next to verified contacts and a distinct warning when a remembered key has changed.

Compare safety numbers once with the people who matter, and let the log cover the rest.

If no company can read your account, no company can open it for you either, including us. Recovery is built around two things only you hold.

Your PIN protects a device. Your Secret Key protects your account. The PIN is a short code, local to one device, that unlocks the keys in that device's keychain; it is never sent anywhere. The Secret Key is a long random recovery code (it looks like A3-9XK4Q-7MTP2-…) shown once when you sign up. Write it down and keep it somewhere safe.

How recovery works. The server keeps a copy of your account key so you can get back in on a fresh device, but encrypted so only your Secret Key opens it: HKDF-SHA256 turns the Secret Key into an unwrapping key, and AES-256-GCM decrypts the stored copy. The server never holds your Secret Key, so neither we nor anyone who steals the stored copy can open your account.

Adding a device. The easy path is approving it from a device you already have. The new device shows an eight-character code, you type it into the existing device, and the two complete an X25519 key agreement (Topic 2) through the server without revealing the key to it. The code is the human-checked part, so even a server that tampers with its own database cannot slip in a fake approval. The other path is your Secret Key, which needs no second device. Either way the new device joins your groups from today forward, with no back-history (Topic 4).

With your Secret Key kept safe, losing a device just means signing in on a new one.

Suppose we publish a list, say every identity key we have ever issued, and promise only to add to it, never edit or delete. How could you confirm that without taking our word for it?

Downloading the whole list every day and comparing does not scale, and it fails if you miss a day. The answer is a Merkle tree.

Hash each entry in the list. Hash those hashes together in pairs, giving half as many. Repeat until a single hash is left.

That final hash is the root. When this page was written, the binaries log's root on our artifacts page was:

root: 37945cb2f61ee43782259a3893336b8ba8b8679d3af1612742deeec75e46cc0c

The root depends on every entry. Change one character anywhere and that entry's hash changes, then its parent's, all the way up, and the root is completely different. Keeping the root the same after an edit would require two different inputs with the same hash, which is what hash functions are built to prevent.

So the root fingerprints the whole list in sixty-four hex characters. Instead of downloading a list that grows forever, you compare one short root, and any claimed version of the list either matches it or does not.

Given a root, two questions follow.

Is my entry in there? An inclusion proof answers this without the whole list. You get the hashes of the neighbours along the path from your entry to the root. Hash your entry, combine it with the first neighbour, hash again, and keep climbing. If you land on the published root, your entry is in the tree; if not, it is not.

For a thousand entries that is about ten hashes; for a million, about twenty. Doubling the list adds one step, so proofs stay small as the log grows.

Is this the same list as before, only longer? A consistency proof answers this, and it is what makes "append-only" checkable. Given last week's root and today's, it is a small set of hashes showing last week's list sits unchanged inside today's, with new entries only at the end. If an old entry had been edited or removed, no such proof could exist.

Who says which root is the real one? We sign it. Each signed tree head covers the root, the number of entries, and a timestamp. The Pollis apps and the verifier carry the public half of the signing key built in. The scheme is ML-DSA-44, which is post-quantum, because a signature over history has to stay meaningful for as long as anyone might re-check the past.

The key is built in, not downloaded, because a bad server could otherwise hand over its own key together with a self-consistent fake list, and everything would check out.

The key is 2,624 hex characters, built into every app and published on the artifacts page. An app with no pinned key reports that it could not check rather than trusting whatever the server sends. The current key is newly generated: the earlier key and its seed were retired, not re-encoded into the new format.

56ab128f3f10107382802e69d3de8659d0127c711feb9c849f5b213c6f2d0af3…

Could different people be shown different lists? This is called equivocation. A signed, append-only log could still show one list to auditors and a slightly different one to a single person, each internally consistent. Any two people who compare the signed heads they were shown will spot the difference, and because both heads are signed, the difference is proof of misbehaviour. Our publishing job checks what is actually being served for this.

In sum: the root fingerprints the list, an inclusion proof puts your entry in it, a consistency proof shows it was not rewritten, the signature under a built-in key shows it is ours, and comparing heads catches two versions being served.

Three append-only logs, one signing key, one public site at verify.pollis.com. Each protects against a different problem.

Log 1, account keys: the wrong key being used for you. Every identity key we list for an account goes in here, in order, with a version number. A swapped key would have to be published here, in a record your own device audits. Versions only move forward, so an older key cannot be slipped back in and history cannot be renumbered.

Log 2, commits: a group's history being rewritten. Every device must apply a group's updates in the same order, and that order is what a bad server might try to reorder or split. So every commit is logged, under one rule: each epoch of a conversation appears once, and two different commits can never claim the same epoch. The log refuses a split, and if one were recorded anyway, both entries would stay in the signed public log for anyone to find.

This log never contains message content: each entry stores only the hash of a sealed commit the server cannot open. The entry is public, though, and carries some structure: a conversation pseudonym, a sender pseudonym, the epoch number, and a sequence number. The pseudonyms are hashes of the real ids that change every 1,024 log entries, and the sender's is different in every group, so an outsider reading verify.pollis.com/v1/entries.json cannot follow a person across groups or a conversation across windows. Within a window they can still see that some conversation had a burst of membership or key changes.

Log 3, binaries: a tampered app shipped to one person. The fingerprints of every released installer go in here, and the same release and platform can never come to mean different files later. A version built for a single person would either appear in the public log or be missing from it. Either way it is detectable.

Why three logs. A signed statement about one log must never pass as a statement about another, so each log signs under its own label and a statement from one fails to verify against the others. They share one key and one site, so what you have to trust is still a single built-in key.

Everything else on these pages assumes the app on your machine is the app whose source you can read. A tampered app defeats everything else.

Code signing, the check your operating system runs before starting an app, proves less than people assume. An Apple or Windows signature proves the holder of the signing key produced these bytes, not what the bytes do. A tampered build signed with the right key passes every check your system makes.

So we publish the fingerprint of every release into a public log. The question becomes "is this the same app Pollis published to everyone?" rather than "did Pollis sign this?"

Each release is recorded at three levels, because "the app" is not one file. The payload is the program and its resources before any signature; an independent person can rebuild this from source and compare. The signed level is what you download after Apple or Windows wraps it; signing mixes in unique data, so two builds never produce an identical signed file. The installed program level is the fingerprint of the main program as it sits on your machine, which is what a running app can measure about itself. The app's "verify this build" check compares the running program against that fingerprint.

What this buys you. If a different build were made for one person, its fingerprint would either be missing from the log, which that person's app would notice, or appear in the public log next to the normal release.

Reproducible builds. A logged fingerprint proves we published these bytes, not that they came from the source you can read. That needs reproducible builds, where anyone compiling the source at a given version gets a byte-for-byte identical result. Ordinary builds bake in timestamps, file paths, and ordering that vary between machines, so this is hard.

The Linux AppImage is reproducible. An independent rebuild from the public source and the published build recipe, with none of our secrets, produces the fingerprint we logged, and it runs automatically after every release. macOS and Windows are not there yet. The signing wrapper is never reproducible on any platform.

Every release also carries a build provenance record in a public log we do not run, showing which automated workflow produced the bytes; checking it involves no Pollis key. Provenance says who built it; reproducibility says whether it matches the source. Having both means one compromised key does not undo everything.

This topic has you check the logs on your own machine, in about two minutes, two ways: reading the files directly, and running the verifier.

The verification data is just files. verify.pollis.com serves a folder of plain JSON files, with no server-side logic or database lookup. A service that computes answers could give different people different answers; files written in advance cannot. Our daily job re-reads what is being served to confirm it matches what was signed.

/v1/<log>/sth/latest.json is the current signed statement and /v1/<log>/entries.json the log's entries, where <log> is binaries or account-keys (the commit log sits directly under /v1/). /verify/release/<tag> is a ready-made report for one release. /v1/<log>/public_key.json is the signing key, served for convenience only: real verification compares against a key you already have (Topic 8).

Fetch the current statement from any terminal:

curl -s https://verify.pollis.com/v1/binaries/sth/latest.json

The verifier does the checking. The JSON tells you what is claimed. pollis-verify, a small standalone program, checks it: it re-hashes entries, rebuilds the tree, checks the proofs against the signed statement, checks the signature against a key built into the program, and re-runs the rules the log enforces. It uses the same verification code as the app.

Checking in the browser. The log signs with ML-DSA-44, so that its statements about history stay valid even after a quantum computer could forge an Ed25519 signature. Browsers do not ship ML-DSA, so a page that checks it has to bring its own cryptography. The Key Transparency page does: it runs the same checks as pollis-verify group in your browser, against the static log files and the pinned key, using a pinned copy of an audited ML-DSA library. The command-line verifier remains the check that does not depend on code a web page hands you.

The signature covers the root, so changing one character of the history changes the signed bytes and no edited log keeps a valid signature. The verifier takes the base URL first, then what to check:

# are the commit and account-key logs consistent and append-only?
pollis-verify remote  https://verify.pollis.com

# what keys have we published for this user, in what order?
pollis-verify account https://verify.pollis.com <user-id>

# is this conversation's history a single unbroken line?
pollis-verify group   https://verify.pollis.com <conversation-id>

# are this release's files in the log, with valid proofs?
pollis-verify release https://verify.pollis.com v1.5.3

A real run of the last command against the live log, captured 2026-07-23:

$ pollis-verify release https://verify.pollis.com v1.5.3

Release: v1.5.3
Found:   yes
STH:     tree_size 60  root 37945cb2f61ee43782259a3893336b8ba8b8679d3af1612742deeec75e46cc0c
Artifacts (publish order):
  darwin   aarch64  dmg       payload  payload 774c8f…ea92  artifact 774c8f…ea92  [included ✓]
  darwin   aarch64  dmg       signed   payload 774c8f…ea92  artifact eef7ae…c155  [included ✓]
  darwin   aarch64  dmg       exe      payload 774c8f…ea92  artifact 77fc24…bea5  [included ✓]
  windows  x86_64   nsis      payload  payload 88547f…7926  artifact 88547f…7926  [included ✓]
  windows  x86_64   nsis      signed   payload 88547f…7926  artifact 16edeb…e92b  [included ✓]
  windows  x86_64   nsis      exe      payload 88547f…7926  artifact 0f4c0f…73a6  [included ✓]
  linux    x86_64   appimage  payload  payload 9b1ab1…e653  artifact 9b1ab1…e653  [included ✓]
  linux    x86_64   deb       payload  payload 7f19ec…1a5a  artifact 7f19ec…1a5a  [included ✓]
  linux    x86_64   deb       exe      payload 7f19ec…1a5a  artifact 5d9281…55b5  [included ✓]
  linux    x86_64   rpm       payload  payload 586cfa…cbaa  artifact 586cfa…cbaa  [included ✓]
  linux    x86_64   rpm       exe      payload 586cfa…cbaa  artifact e45d0c…400b  [included ✓]

PASS: release binaries tree is valid

tree_size 60 and the root are the signed statement from Topic 8, the same one the curl above returns. Each [included ✓] is a proof your machine recomputed, not a stored status. The payload / signed / exe levels are from Topic 10. PASS means the whole tree replayed cleanly under the built-in key with every rule holding.

What a failure means. A FAIL is not necessarily an attack. The log may be mid-rebuild, or the release may be newer than the last rebuild (Topic 9). The result that would matter is a valid signature over a tree that disagrees with one someone else was served: the two-versions case from Topic 8. That is why comparing results with someone else running the tool is the most useful thing you can do with it.

After every release, a separate workflow rebuilds the Linux payload from public source and checks it against the log; each verdict, including two releases that were never checked, is recorded on the assurance page. Your run of pollis-verify is the independent check.

Where it comes from. pollis-verify ships as a standalone binary with checksums, and its built-in key is printed in the release notes. If you are auditing us seriously, build it from source and read what it does first.

On the website: the artifacts page. Latest releases shows the current version of each thing we ship, with download links.

Release proofs shows, for the current release, whether it was found in the binaries log, whether the tree checked out, and what is in it. Each row is one file with the fields from Topic 10: platform, package, level, and two fingerprints, each with a tick meaning "a proof was checked". The tree size and root are the signed statement from Topic 8, the same root the command line and the verifier return. Not in log yet usually means the log has not been rebuilt since the release (Topic 9).

Daily transparency self-audit shows the current signed statement for all three logs. The one key you trust is the built-in signing key everything above depends on. The page notes that its in-browser key check is a convenience; real verification uses a key you obtained independently (Topic 11).

In the app: the Security page. This build shows a version, a commit, and a verdict from the in-app check (Topic 10), one of four. Build publicly verified: this exact app's fingerprint is in the public log for this release. Build publication pending: the release is not in the rebuilt log yet, which is normal right after a release. Verification unavailable: the check could not run, because the log was unreachable or this release predates the installed-program record. Build not in public log: the release is published with comparable fingerprints, and this one is not among them.

The last two differ as "could not check" differs from "checked, and something is wrong."

Below that, account key is your device confirming that the key the log shows for you matches the key you hold (Topics 6 and 9). Devices and security events records enrollments and resets. Safety numbers per contact show the shield states from Topic 6, including the warning for a changed key.