Last updated: September 2, 2026 This policy describes what Channel Messenger collects, what it does not, and exactly what a fallback delivery path can and cannot see when you choose to use it. We have tried to write it so that every sentence is checkable against how the app is actually built, not just how we would like it to work. Where a claim depends on something outside our control — like how a phone's operating system schedules background work — we say so. If any part of this policy is unclear, or you want more detail than we gave, contact us using the address at the bottom.
of identifying you.
your use of the app is tracked.
at all — not ours, not anyone else's.
instead, if you allow it. That server cannot read your message, and does not know who you are, but it does exist and your message does pass through it. We describe exactly what it can and cannot see below, rather than asking you to take "end-to-end encrypted" on faith.
and, along with our server, will be able to see roughly when you receive messages — that is a real privacy cost of a real convenience, and it is opt-in.
The rest of this document explains each of these in more detail.
Channel Messenger has no account system. There is nothing to sign up for and nothing to log in with, so there is no name, email address, phone number, date of birth, or password for us to hold. We do not request access to your address book. The app cannot read your contacts, and has no feature — "find friends," contact matching, or otherwise — that would need to. Every conversation starts with you deliberately pairing with the other person (see §5). We do not request access to your location, and nothing in the app uses it. We do not include any third-party analytics, advertising, or crash-reporting software. There is no software development kit in this app whose purpose is to observe how you use it, build an advertising profile, or report your device's behavior back to us or anyone else. If the app crashes, we do not find out unless you tell us. We do not know how many people use this app, how often, or for how long — beyond the anonymous purchase and download counts that Apple and Google provide to every developer through their own platforms, which we do not control and which are covered by Apple's and Google's own privacy policies, not this one.
When you and the person you are messaging are within Bluetooth or Wi-Fi range of each other, Channel Messenger delivers your message directly, phone to phone. No server — ours or anyone else's — is in that path. There is no data flow for us to describe here because none exists: the message goes from your device to theirs over a direct radio connection, and that is the entirety of its journey. Because the receiving device is the one that gets the connection and wakes up to handle it, it raises its own local notification. This does not require registering with Apple's or Google's push notification service, and for a conversation that only ever uses direct delivery, no such registration ever happens. Apple and Google are not part of this path in any way. This only works when the two devices are close enough for direct radio contact — in practice, the same room, vehicle, or immediate vicinity. It is not a way to reach someone farther away.
Most conversations are not conducted with both people standing next to each other. When direct delivery is not available and you have allowed it, your message can be queued and delivered through an internet server instead. **We are describing this plainly because it is the one part of the app where a server is genuinely involved**, and a privacy policy that glossed over that would not be an honest one.
A request for the stored content, examined directly, returns unreadable bytes — that is a structural fact about how the server is built, not a policy we are promising to follow.
identifies you. It is meaningless outside that ten-minute window.
— never the exact byte count.
app, and the server was built with no field to hold one.
to it. This is a deliberate operational decision, not an incidental one — logging IP addresses at upload and download would be the one thing that could let us reconstruct who is talking to whom, which is exactly what the design exists to avoid.
A message is deleted the moment your recipient's device confirms it has been received — typically within seconds or minutes of actual delivery, not held any longer than that. For a message nobody ever collects, you choose how long it may wait before it expires automatically: anywhere from one hour to 30 days, with 7 days as the default if you do not choose. **Thirty days is a hard ceiling that applies no matter what you or we choose** — nothing is ever allowed to sit on the server longer than that.
Connecting to any server at all can tell your own internet provider, or anyone watching your network traffic, that you used this app at that moment, from that connection. The rotating token described above hides who you are talking to; it does not hide the fact that you reached out to a server. If that distinction matters to you, using the server only when you choose to, rather than continuously, limits how often it applies.
There is no directory and no way to search for or discover other users. You add a contact by pairing directly with them, using a QR code or by sending a code through a messaging app or channel you already use and trust. That code carries only a public cryptographic key — never anything secret — and both devices display a short confirmation phrase for you to compare, so you can be sure the exchange was not tampered with. None of this involves us or any server; pairing is a transaction between your device and theirs.
Push notifications are not available in this release. Nothing in the current app or server sends them, and no push identifier is created or registered. The rest of this section describes how they are designed to work if and when they ship, so the trade-off is on the record before you are ever asked to make it. Push notifications are optional and off by default. If you leave them off, the app checks for waiting mail on its own schedule — manually, when you open it, or automatically in the background where your operating system allows — and neither Apple nor Google is involved in that process at all. If you turn push notifications on, here is exactly what changes. To wake your device when a message may be waiting, our server needs a stable identifier it can hand to Apple's or Google's push service. Because that identifier has to stay the same to keep working, it is a durable, long-lived handle — not your name and not an account, but a steady thread rather than something that rotates. It is what privacy engineers call a pseudonym. It is not, however, joined to your mailboxes on our side. The person sending you a message supplies the handle along with the message, so our server never stores a table connecting your device to the addresses you collect from. The two meet only for the instant it takes to send the wake, and nothing records it — which means there is no such record for anyone to obtain later. Apple and Google, for their part, already know this app is installed on your device the moment you install it from their store — that is true of every app. What push notifications add is that they, along with our server, can also see roughly how often your device is being woken up, which is a loose signal for how often you are receiving messages. This is a genuine trade-off between convenience and privacy, not a false one, and we would rather you make it knowingly than have it made for you. Leaving push off does not stop messages from arriving — it means the app checks for them on its own initiative instead of being woken remotely, and on some phones, less immediately.
Your conversations and your cryptographic identity are stored locally, on your device, and nowhere else. We do not have a copy. If your device is lost, stolen, or wiped, we cannot retrieve any of it for you, because we never had it. This local data is deliberately excluded from device backups — iCloud Backup on iOS, and the equivalent automatic backup mechanism on Android. We made that choice because a backed-up copy of your conversations would mean your message history existed somewhere other than your device, which would undermine the point of the app. The consequence, stated plainly in §8, is that this also means your data cannot be restored from a backup either. Your cryptographic identity key — the thing that makes you "you" to your contacts — never leaves your device under any circumstance, including in a backup.
Because your identity and your conversations are never stored anywhere but your own device, and are deliberately excluded from backups, replacing your phone means starting over. Your identity key and your message history do not transfer to a new device. You will need to pair again with each of your contacts as if starting fresh. We are telling you this here, plainly, rather than letting you discover it when you next upgrade your phone. It is the direct and currently unavoidable consequence of the design described in §7, not a bug we intend to quietly fix without telling you. If that changes — for example, through a direct device-to-device transfer feature that does not depend on any server — we will update this policy and our in-app messaging to describe exactly how it works and what it does and does not protect.
and connect to a contact's device directly. Used only for that purpose.
delivery or, if you opted in, by push. See §6 for what turning this on changes.
not otherwise access your camera, and does not store or transmit anything the camera sees other than the code you point it at.
We do not request access to your contacts, your location, your photo library, your microphone, or your call history, because nothing in the app uses them.
If we receive a legally valid request for information — for example, a subpoena or court order — our response is limited by what we actually hold, which §§2–4 of this policy describe in full. We cannot produce message content, because we never have it in readable form. We cannot produce an account record, because no accounts exist. We cannot produce your contact list, because we never had access to it. The most a lawful request directed at our internet server could realistically obtain is the limited, short-lived, pseudonymous metadata described in §4 — and, for users who opted into push notifications, the pseudonymous handle described in §6. We do not retain anything beyond what those sections describe.
Channel Messenger is not directed at children, and we do not knowingly collect personal information from anyone, regardless of age — the app's design does not collect personal information from any user, child or adult, as described throughout this policy. If you believe a child has provided us with personal information, contact us at the address below; given that no account or personal data collection exists in the app, we do not expect this to arise, but we will look into any report.
If we change what the app collects, how the internet fallback server works, or any other practice described here, we will update this policy and change the "Last updated" date at the top. We will not make a change that expands what we collect without also updating this document to say so plainly, in the same tone as the rest of it. We encourage you to review this policy from time to time, particularly before enabling a feature — like push notifications — whose trade-offs are described here.
Questions about this policy, or about how Channel Messenger handles your data, can be sent to: de57@me.com
This policy is written in English, and the English version is the one that governs. Any translation we provide is offered for convenience only and is not legally binding. Where a translation and the English text disagree, the English text is correct — and we would be grateful to be told, so we can fix the translation.
We say this plainly because we translate the app's interface far more widely than we translate this document: the interface is cheap to translate and low risk if a word is awkward, whereas a policy is a set of promises, and a promise that says something different in two languages is not one promise.
See also: how Channel Messenger uses encryption.