What is protected, and what is not

1.What our server can see

It does not hold your name, your phone number, your email address, your contacts or a single word you have written. None of it is stored encrypted somewhere for later. It is never sent in the first place.

It also does not learn who sends to whom. Delivering a message needs no proof of who you are: the app presents a token derived from the recipient's own public key, which anyone holding their contact card can compute, and nothing that identifies the sender. The sender's name is encrypted inside the envelope where only the recipient can read it. Asking for someone's keys before a first message works the same way, so even starting a conversation does not tell us who is about to talk to whom. There is no fallback: if the app cannot send anonymously it does not send at all.

What it does hold is the short list below, and that is the whole list. Everything in it is what remains after encryption, kept because delivery cannot happen without it. There is no hidden column.

The honest limit is the network underneath. On a direct connection your anonymous send arrives from the same address as the connection you receive mail on, so an operator willing to compare the two could link them. That is a network fact, not a cryptographic one, and the Tor route removes it: there is no address to compare.

Creator channels change none of this. A post in a paid channel is an ordinary sealed message from the creator to each member; the relay keeps only which account is a member of which channel and until when. A member’s report, which uploads that one message with their consent, is the only way we ever see channel content.

2.The encryption

• Keys are made on your device from a 12-word recovery phrase. They never leave it. We cannot reset them, recover them, or decrypt on your behalf.
• Every message gets its own key. The session agrees a secret with X3DH and moves it forward with the Double Ratchet, the published standard that serious encrypted messaging has settled on. It has been public for a decade and attacked in the open the whole time, which is exactly why it is the floor we start from rather than the feature we stop at. Messages are sealed with AES-256-GCM.
• What we built on top of it. Meeting the standard is where Zero Say begins. There is no phone number and no email address, so an account has no identity to be tied back to. The server answers on a Tor onion address, where we never see where you are connecting from. Sending is anonymous, always: there is no second path that would name the sender, so if the anonymous one is unavailable the app simply does not send. And a second passphrase can open a different profile entirely.
• Forward secrecy and break-in recovery. Stealing today's key does not open yesterday's messages, and the ratchet heals itself after a compromise.
• Attachments are encrypted with a fresh 256-bit key that travels inside the encrypted message, never with the file.
• Verify who you are talking to by comparing a 60-digit safety number, or by scanning each other's QR code in person. The app tells you loudly if a contact's key ever changes.

The implementation is our own, written in-house on audited primitives from the noble cryptography libraries and checked against the published test vectors for each of them. We depend on no third party for any of it.

3.On your computer

• The local database is encrypted with AES-256 through SQLCipher. The key is held by the operating system keychain, not in a file next to the data.
• App lock. Set a passphrase, or use Touch ID on a Mac, and the app locks itself after a chosen idle time, when the machine sleeps and when the screen locks. While locked the database key is dropped from memory, so a locked app genuinely cannot read your messages. A passphrase is the stronger choice: with Touch ID alone the key stays recoverable from the system keychain, which is convenience rather than extra protection.
• Photo metadata removed. GPS position, camera serial and timestamps are stripped from images before they are encrypted. Some formats cannot be scrubbed safely (audio files, PDFs, archives and plain text), and those are sent unchanged with a visible warning rather than a silent promise.
• Deleted means overwritten. The database overwrites deleted rows rather than leaving them in free space.
• Not in your backups. On macOS the data folder is marked so Time Machine and iCloud backups skip it. Copies made before you installed this version stay in whatever backup already holds them.
• No crash reports. Crash reporting is switched off in the build, so nothing about your session is ever sent anywhere.
• A second lock. Three wrong passphrases and the app stops accepting the passphrase at all: only your recovery phrase gets you back in, or an enforced wait, whichever you chose. If you choose the option that erases instead, it allows five attempts and warns you before the last one. The count is kept in the system keychain as well as on disk, so editing a file cannot reset it, and if that record is missing the app assumes the worst and engages the lock rather than starting from zero.
• A second passphrase, opening a different profile. You can set a second passphrase that unlocks a whole other Zero Say: its own account, its own contacts, its own history, and no route back to the first. Someone who makes you unlock the app sees an ordinary working messenger. The app itself will not tell you whether you have set one, because a screen that answered that question would answer it for whoever is holding your laptop. Read the limits below before you use it; in some countries it can make a legal situation worse rather than better.
• Files are read before they are saved. Ask to save an attachment and the app first says what it actually is and what it will be able to do when opened: a document whose contents are really a program, a name ending .pdf.exe, a PDF carrying JavaScript or a launch action, an archive with paths that write outside the folder you unpack into, or macros. Nothing is written until you have seen that and chosen to go ahead. This is not a virus scan: there are no signatures, nothing is sent anywhere, and it can never tell you a file is safe, only what it found.
• Printing is refused. The app has no print feature and the main process blocks the print dialog outright, so a window holding messages cannot be spooled to a print queue where it would sit as a readable file.
• Panic wipe. One shortcut deletes the local database, the keys, the cached media and your account on our server. Used inside a second profile it destroys that profile only, and leaves the other exactly as it was.

4.Disappearing and maximum security chats

Ordinary disappearing messages count down from the moment they are sent, for an hour, a day, a week or ninety days, chosen per chat.

A maximum security chat destroys each message shortly after the recipient reads it, on both devices, with a window of 30 seconds, 1 minute, 5 minutes or an hour. Inside such a chat the app also:

• keeps read receipts on, because your own copy cannot know when to disappear otherwise, and says so;
• never writes media to disk, decrypting it in memory only;
• refuses to copy or save message content, in the app core rather than by hiding a button;
• excludes the window from screen capture, so screenshots, screen recordings and shared screens come out blank on macOS and Windows.

5.On the network

• Certificate pinning. The app only accepts certificates that match a short list pinned into the build. A company laptop or a country that installs its own certificate authority cannot read or alter the connection. It is not absolute: because the certificate authority's own roots are pinned as backups, a certificate wrongly issued by that authority for our domain would still be accepted.
• Our own Tor address, so there is no IP for us to see. The server runs as a Tor onion service. On that route your connection never touches the public internet on its way to us, the address proves who it is by its own key rather than through a certificate authority, and there is no IP address for us to see, to log, or to be compelled to hand over. Switch it on in Settings under Network; a direct connection is the default, and on that route we do receive your address at the moment you connect. Any other SOCKS5 proxy works too, and if the one you chose stops working the app goes offline rather than quietly reconnecting in the clear, which is the part most software gets wrong. The honest limit: this removes your address, not your traffic. Anyone watching the network still sees its timing and shape.
• Presence is blurred, not hidden. The app holds a connection open so messages arrive promptly, which tells the server you are online. Connecting and reconnecting are delayed by a random interval so the exact moments you start and stop are fuzzy, but the fact that a connection exists is visible.
• Padding. Messages are padded to fixed sizes, so the length of what you write does not travel with it. Messages larger than about 16 KB go unpadded because the server caps envelope size, and a 10 MB attachment is still visibly about 10 MB. Padding hides how much you said, not that you said something.
• Timing. Sending is delayed by up to two seconds at random and receipts are batched, which blunts the timing patterns that link two accounts into a conversation. The first message of a conversation goes out immediately so the app feels responsive, so an observer watching both ends can still correlate an opening message.
• Nothing else is contacted. The app talks to our server and to nothing else. No analytics, no crash service, no fonts or scripts from anyone, no link previews, because fetching a preview would tell someone else what you were sent.

6.On a phone

The iPhone and Android apps run the same code as the desktop app for everything on this page that is about messages and keys: the same encryption, the same disappearing rules, the same lock, the same store. What a phone cannot do, or does differently, is listed here rather than left out.

• No Tor and no proxy. A phone app has no raw network socket to route through, so the phone connects to our server directly. We receive its address at the moment it connects, as on the desktop's direct route. The desktop app can use Tor; the phone app cannot yet.
• No certificate pinning yet. The phone trusts the certificate authorities its operating system trusts, and nothing more. The desktop pins.
• Notifications go through Apple or Google, and are off until you turn them on. A phone cannot keep a connection open in the background, so if you want to be told about a message while the app is closed, our server has to ask Apple or Google to wake the phone. The notification is always the same two words, "New message", with no sender and no content. What Apple or Google can see is when: with the batched setting, that something arrived for you inside a 15-minute window, at most once per window; with the instant setting, the moment each message arrived. Turning notifications on also gives our server your phone's notification address next to your account, so it knows where to send the wake-up; turning them off deletes it. This is the one place the phone app talks to anyone but our server.
• Apple and Google know the app is installed. An app from their stores is tied to the Apple ID or Google account that installed it. That is outside our reach and true of every app on the phone.
• Screenshots and screen recordings come out blank on both platforms, unless you allow them in Settings. There is no detection of screen-sharing software and no forensic-tool guard: a phone app cannot see what other apps are doing, so the phone does not claim to.
• The database key passes through a text string when the store is opened, which cannot be overwritten afterwards the way a buffer can. The desktop hands its key over as bytes and zeroes them.
• Presence is blurred less. The phone waits up to three seconds before connecting, not up to twenty: it connects because you opened the app and are waiting.
• Linking the phone to your computer sends your profile through our server once, as one encrypted parcel under a key that only the code on your screen carries, sealed under a passphrase you choose; the parcel is deleted the moment the phone has it. On both devices the profile passes through a scratch file inside the app's private storage for the length of the copy, which is then overwritten and removed. What linking means for the server is under "Several devices" below.
• Kept out of backups. On iPhone the profile is marked excluded from iCloud and computer backups; on Android backups are off for the whole app. The key that opens the profile lives in the phone's secure storage and never leaves the device, so a backup restored onto another phone cannot open it. Your recovery phrase can.

7.Several devices

One account can be signed in on a computer and a phone at the same time, up to eight devices. Every device holds the same identity keys, which come from your recovery phrase, and has its own device number, its own session keys and its own queue on our server. A contact who writes to you encrypts the message once for each device you have; when you write from the phone, the phone also encrypts a copy for your computer. Your own devices talk to each other through exactly the channel contacts use: sealed, end-to-end encrypted, and unreadable to us.

• What the server learns. How many devices your account has, when each was added and last seen, to the day. It still never sees who sends a message, and a message for three devices is three ciphertexts it cannot read.
• What syncs and what does not. Messages, contacts, verification, blocks, timers, pinned and muted chats, and what you have read. Settings do not sync. Secure notes stay on the device they were written on unless you switch on sync for a single note; that note then travels end-to-end encrypted to your own devices only, like a message to yourself, and switching it off removes it from the others again. The same rule holds when you link a new device: only notes with sync switched on are copied to it; the rest never leave the device they were written on.
• Traffic multiplies. A message to a contact with two devices from an account with two is three envelopes. Padding and the random delay apply to each; the server sees the count.
• Every device holds the keys. A device that is lost or taken is the account, exactly as the recovery phrase is, until you remove it under Linked devices. Removing it stops all delivery to it and tells it to erase its own copy the next time it talks to the server. It does not take back what that device had already received.
• The server can tell a device to erase itself. That is how removal works, and it means a dishonest server could send that instruction without you having asked. It is the one thing the server can do to data on your device: erase it, never read it.
• A second computer links the same way as a phone. Settings → Linked devices → Link a device on the computer you use; Link this computer on the new one's welcome screen. The code can be scanned with a camera or copied as text through the app's private clipboard, which clears itself after a minute. Typing your recovery phrase into a second computer instead brings back only the account: chats, contacts and notes live on your devices, never on our server, so they cannot come back that way. The app then asks whether the new computer joins your other devices or replaces one that is lost; replacing signs the lost device out, so your contacts' next messages come to the new one.
• Older versions see one device. A contact still on an app from before this feature sends only to your first device until they update. The desktop app updates itself.

8.What the operating system keeps, outside our reach

Zero Say controls what Zero Say writes. It does not control what macOS or Windows records about the fact that you ran it, and no application can. This is the honest list of what can be left behind on the computer itself, what we remove where we are allowed to, and what only you, the disk and the operating system can settle.

• Disk snapshots and backups. The data folder is marked so Time Machine and iCloud skip it, but macOS also takes automatic local APFS snapshots of the whole disk, and those can hold an older copy of the encrypted store. We cannot delete a system snapshot; removing them needs administrator rights and belongs to you, not to us. With an app-lock passphrase set, what a snapshot holds is ciphertext without the key. With Touch ID alone, or no lock, the key lives in the keychain and a snapshot plus that key is readable — which is the real reason to set a passphrase.
• Swap and hibernation. While the app is unlocked its keys are in memory, and the operating system may page memory to disk or write it to a hibernation file, neither of which an application can prevent. Full-disk encryption — FileVault on a Mac, BitLocker on Windows — is what protects those, and the app shows you whether it is on.
• Records that you ran it. The system keeps its own traces that an app cannot reach: Screen Time and the usage database log when Zero Say was in the foreground, and the unified log notes launches. These name the app and the time, never a message or a contact, and clearing them needs administrator rights we do not ask for.
• The download record — which we do remove. When you download the app, macOS writes a quarantine entry naming where it came from. On every launch, and again when you erase, Zero Say deletes its own rows from that per-user record, and only its own. It cannot remove a copy already captured in a backup or a snapshot taken before then.
• The updater's download, which we also remove. A downloaded update is deleted from its cache on launch, on lock and on quit, so an installer file does not sit on the disk after it has done its job.
• Name resolution on a direct connection. Connecting directly asks the operating system's DNS resolver for our server's address, and that lookup — the hostname, not your messages — can be seen and logged by the resolver, your network or your provider, and cached on the machine. The Tor route avoids it entirely: the address is resolved inside the Tor network, not by your computer. If that matters to you, use it.

None of this touches the contents of your messages, which never leave your device unencrypted. It is about the shadow the operating system casts around any program, and the honest position is to name it rather than to imply we have swept a floor we are not allowed to reach.

9.Who you have to be

Nobody. There is no phone number, no email address, no real name and no contact upload. An account is a random identifier and a key pair made on your device. You can share it as a QR code, as a handle you invent, or as the raw identifier.

Adding someone by handle or identifier means our server hands you their public key, so the app marks that contact unverified until you compare safety numbers. A QR code scanned in person is trusted immediately, because the key never passed through us.

10.No hardware IDs, no fingerprinting, no memory left behind

A great deal of what other software knows about you is not in your messages at all. It is in the identifiers it quietly gathers. Zero Say gathers none of them.

• No hardware identifier. The app never reads or sends a serial number, a MAC address, a disk identifier, a machine name or any other hardware ID. Your account is a random identifier and a key pair, and nothing ties it to the metal it runs on.
• No device fingerprint. No screen size, no fonts, no locale, no time zone, no installed hardware, no advertising identifier. Requests carry a single fixed user agent that says only "ZeroSay", with no version and no platform, so every copy of the app looks the same on the wire.
• No analytics or telemetry of any kind, including crash reports, which are switched off in the build rather than merely defaulted off.
• Nothing readable left on disk. The database is encrypted, and the browser caches that any desktop app of this kind leaves behind are cleared when you lock the app, when you quit it and again when it next starts. We check this by inspecting a real profile rather than trusting the code: after a normal session the folder holds the encrypted database, the lock files, and one browser preferences file whose only identifier is regenerated on every run. The folder is hidden from Spotlight and excluded from backups, and windows are not restored with their contents.
• An ephemeral mode that keeps the database in memory only and deletes the profile when you quit, so a session leaves nothing at all. Its one trade: an in-memory database cannot be encrypted by the driver, so those pages are plaintext inside the app's own memory for the session. Disk encryption is what covers that, which is why we mention FileVault.
• Secrets are wiped as soon as they are used. Keys and decrypted content are held in buffers that are overwritten with zeros the moment they are finished with, and the key that opens your database is dropped entirely when the app locks.
• A released build refuses a debugger. If anyone tries to start it with a debugging port attached, it quits instead, so a running app cannot simply be opened up and read.

What we will not claim: while the app is unlocked, its keys are necessarily in memory, and some values, such as your passphrase and recovery phrase, are held by the programming language in a form that cannot be overwritten. Anyone able to dump the memory of an unlocked app, or read a swap file or a hibernation image, defeats this. Locking the app is what closes that window, which is why the lock exists.

11.Where it stops

Every messenger has a boundary. Here is ours, stated plainly.

• Zero Say refuses to run beside live forensic tools. Before it opens your store, and every few seconds while it runs, it checks whether known examination, memory-capture or reverse-engineering software is running on the same machine, and if it finds any it drops its keys from memory, leaves the note “IT forensics tools found. Zero Say cannot be run.” and quits. The honest edge, which is the whole point of saying it here: this stops a live examination — a tool running at the same time — not the ordinary method of powering the machine off and imaging the disk elsewhere, where the app never runs. That case is what the app-lock passphrase and the encrypted store are for. It also only knows the tools on its list, and plain developer debuggers and sniffers are deliberately not on it.
• Zero Say will not show your messages while screen capture software is running. It recognises the usual recorders and remote-desktop tools and hides the conversation until they are gone. Two honest edges: it only knows the programs on its list, so a tool it does not recognise raises nothing, and it cannot tell whether anything was actually captured. Blocking is what protects you; this is the courtesy on top.
• The window itself cannot be captured on macOS and Windows: screenshots, recordings and shared screens render it blank, enforced by the operating system rather than by us. Linux offers no such control and the app says so rather than claiming protection it does not have.
• A camera pointed at your screen defeats all of it. So does a person reading over your shoulder.
• We cannot protect a compromised computer. Malware with your privileges can read what you can read, whatever we do.
• The person you write to still has the message. Disappearing timers are a courtesy between people who agree, not a guarantee against someone determined to keep a copy.
• We do not block your webcam. A messenger cannot stop other software from using your camera; that is the operating system's job. Zero Say opens the camera only while you are scanning a QR code and releases it immediately.
• A second passphrase buys deniability, not immunity. Anyone who obtains both passphrases gets both profiles. In some countries, including the United Kingdom under the Regulation of Investigatory Powers Act, refusing to hand over a key is itself an offence, and handing an investigator a decoy could be treated as obstruction. The app states this before it will let the feature be switched on. Two further limits we will not paper over: every profile keeps a database in the same folder, and although they are named so that nothing says which is which and their timestamps move together, their sizes still differ, which a forensic examiner can read. And an unused second profile is a tell in itself, so it has to be lived in.
• Panic wipe cannot always reach the server. If the app is locked when you trigger it, the local data goes but deleting the account on our server needs your key, so that part waits until you unlock. The app tells you which parts succeeded.
• Wiping deletes files, it does not scrub the disk. On an SSD, discarded blocks can survive for a while no matter what any application does.
• If you lose your recovery phrase and your devices, your history is gone. That is the cost of us not holding your keys.

12.Why you should not simply trust us

Claims are easy. These are the things that would let you check ours, and where we are with them today.

Until those are done, treat this page as a description of intent backed by a running product, not as proof. Security researchers are welcome: write to hello@zerosay.com with "security" in the subject and we will not take legal action against good-faith research.

The server's Tor address, so you can check it yourself: fgymubkeo5hu2fbnf77dyk5qcjxcpj76l2jm6jvy3xor2aoy42mzrzad.onion

How we handle the little data we do hold is in the Privacy Policy.