Last updated: October 16, 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.
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.
CHANNEL can show you your own address book, so you can find someone without retyping their name, and only if you ask for that screen. Your address book is never stored by CHANNEL and never sent anywhere. If you open that screen, your phone will ask whether to allow it. Say no and the rest of the app works exactly as before. Say yes and CHANNEL reads your address book into memory, to draw the list you are looking at, and for no other purpose. It is not copied into CHANNEL's own storage, not written to disk, not indexed, not hashed, and not transmitted — not to us, not to anyone. Close the screen and it is gone.
You can also add someone without granting anything at all, by typing their name. Nothing reads your address book on that path, and the name is all CHANNEL keeps.
If you do use the phone-contacts screen, CHANNEL shows you what it would keep before it keeps anything: a screen listing that one person's name and the phone numbers and email addresses on their card, with a button to import and a button to cancel. Those are the fields CHANNEL's own contact editor has, and they are what you need in order to reach somebody. No photograph, no birthday, no postal address, no notes, no identifier. What you import is saved on your device exactly as if you had typed it in, and it is never uploaded anywhere.
The Contacts tab also lists the people in your address book with an Invite button beside each, once you have allowed access, and only while you stay on that tab. Tapping Invite keeps only that person's name and the one number or email address you invited, on your phone, as a contact waiting to pair; leaves an invitation for it the same way as writing to any number or address (§7); and opens a text message or an email to them that you send yourself. Nothing else from your address book is kept or sent.
There is no "find friends," no contact matching, and no upload of your address book — not in whole, not in part, not hashed. Every conversation still starts with you deliberately pairing with the other person, or with an invitation you send (see §5).
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 daily count of AI calls described below, and 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.
CHANNEL does measure some things about its own behavior, and we would rather be exact about that than let “no analytics” do more work than it can bear. How long each way of reaching somebody took, how often a Bluetooth or Wi-Fi transfer succeeded, how much room the app is using: these are counted, kept on your phone, and shown to you under Settings. They are not sent anywhere, they are not aggregated with anybody else's, and there is no mechanism in the app that could send them — not a disabled one, not one behind a switch.
There is one exception, and it is narrow. A Mac where you let an AI use a profile sends our server, once a day, how many calls AIs made on that Mac the day before, by kind of call and added up across all its profiles — so many sends, so many reads — and nothing on a day with none. It is used to tune the limits on those calls for performance. Nothing about you or the profile is saved: not who, not why, not what the calls said, not where you are. The report carries no account, profile, count of profiles, device identifier, contact, text or time of day: only the counts, and a random value the Mac makes fresh each day so that a retry is not counted twice. Our server adds up each finished day — per kind of call, the total, how many Macs made it, and the largest count from one Mac — then deletes the reports and keeps those daily totals for 400 days. As with every request, the company that hosts our server sees the address it came from (§4). A phone sends nothing of the kind, and neither does a Mac where no AI uses a profile.
Beyond that count, if we ever wanted a number of that kind from across everybody, it would only be worth having unlinked to any user, profile, account, device or IP address, and we would say so here before it existed rather than afterwards. That is the promise worth making, because it is one that stays true: not that nothing is ever measured, but that nothing measured is ever attached to you.
You can also show us those figures yourself if something has gone wrong — they are on a screen you can read and share. Nothing on it identifies you or your device, and if we needed something that did, we would have to ask you for it.
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 photograph, a video or a large file is not sent as one object. It is cut into pieces, and every piece is padded to one of a few fixed sizes, so nothing about the shape of what you sent is visible in the shape of what the server holds beyond how many pieces there are.
We should be straight about the limit of that, because it is the honest half of the claim. A short message rounds up into a bucket and its true size is genuinely hidden. A very large file is many pieces of the same few sizes, and counting them is a good estimate of how big it was. The server cannot tell a three gigabyte video from a three gigabyte archive, and it still cannot read a byte of either — but it can tell that what you sent was about three gigabytes rather than about three megabytes. If that matters for something you are about to send, sending it when the two phones are near each other keeps it off the server entirely.
The encrypted pieces are held by an object storage service we rent rather than on a machine we own. We use two, Cloudflare R2 and Netlify Blobs, and either can cover for the other: if one stops answering, the next request goes to the other automatically and moves back on its own when the first recovers. We built it that way so an outage at one company does not stop your messages arriving.
Both of them hold exactly what is described above and nothing else — ciphertext, a rotating token, and a timestamp. Neither has the keys, and neither is given your name, your number or an account, because no part of this system has one to give. They are storage for opaque bytes, and that is the whole of their role.
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. A message nobody ever collects waits as long as you have chosen under Settings › Privacy › Undelivered mail waits — a day, a week or 30 days, and 30 days unless you change it — and is then deleted automatically, and the app tells you it was. A slice of a large photo or video waits 48 hours instead, because a transfer nobody is collecting takes room from one somebody is. Thirty days is a hard ceiling the server enforces on anything it is asked to hold — nothing is ever allowed to sit there longer than that, whatever the app asks for.
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 names nobody; 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 browse other users. You add a contact by pairing directly with them: one of you shows a pairing code and the other enters it. That code carries only a public cryptographic key — never anything secret. When somebody pairs by reading your code off your screen, each phone afterwards says so — they were standing there, which is the thing that check is for. The exchange that follows is three signed packets, and they travel over Bluetooth when the two phones can reach each other and through our server when they cannot. Everything in them is public; the key the two phones agree on is in none of them, so a server that kept every byte learns nothing from them. The server is never the thing that decides two people are paired.
You can also reach someone at a phone number or an email address they have proved is theirs, by leaving an invitation for them. What that involves is described in §7.
A phone that is asleep cannot check whether mail is waiting for it, so CHANNEL asks you how you want that handled. There are three choices, and you can change them at any time.
Any single profile can also be set to check only when you open it, in which case nothing about that profile is registered anywhere, whatever the phone-wide setting says.
Here is exactly what a remote wake-up costs. What Apple or Google receive is content-free: no sender, no text, no profile, and not even whether it is a message rather than a housekeeping wake. A call is the one exception, and it is one Apple imposes: an iPhone's silent wake is throttled by Apple to a few an hour, and a call that arrives an hour late is a call that did not arrive, so a call wakes an iPhone the loud way. Apple is then told that something needing immediate attention arrived for that phone. It is still told nothing about who is calling, who is being called, or anything that differs between two people — the words on the screen are a fixed sentence your own phone translates. Android needs no exception; its wake was always the prompt kind. To send it, our server holds one opaque identifier per profile against your device's push token. That identifier is not your name and not an account, but it has to stay the same to keep working, so it is a durable, long-lived handle. 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. Turning the setting off deletes the identifiers at our server immediately.
A registration lives only as long as it is used. Turning remote wake-ups off deletes it at once, and a registration the app has not renewed in 45 days is dropped by our server on its own, because a token that old belongs to a phone that has been wiped, reinstalled or has lost interest. When your phone registers, it proves to our server that the identifier is its own, and our server keeps a note that the identifier is claimed, so that nobody else can point it at a different phone. The note holds only the time of the claim, and it is deleted with the registration.
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 a remote wake-up adds is that they, along with our server, can also see roughly how often your device is being woken up. Under Push that is a loose signal for how often you are receiving messages; under Fetch it is a clock, and says nothing about your messages at all. 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. Choosing On Demand does not stop messages from arriving — it means the app checks for them on its own initiative instead of being woken remotely, and so, less immediately. An Android phone without Google's services can be woken through a UnifiedPush app installed on it instead; that app's server sees that a wake was sent and never a message, a name or a sender.
Everything in this section happens at the moment you choose it, and not otherwise. There is no background version of any of it, apart from the answers of an AI you have switched on to answer for you, described under the AI account below.
You may let people reach you at a number or an address, and to do that you have to prove it is yours. When you ask us to, a six-digit code is sent to that value, by text message, by a phone call that reads the digits aloud, or by email. Sending it means handing the number or the address to the carrier or the email provider that has to deliver it. Our text-message provider, Telnyx, keeps the text of each message for up to ten days and a record of each one (the number, the time and whether it arrived), for a period it sets; we have asked it to keep less. The code is never put in a URL, and nothing about a verification call is stored.
Our server keeps no list of verified people and no list of numbers. An invitation left at a number is addressed to a slot derived from the number itself, and only a device that has proved that number can collect from it. The number is used to compute the address and is never stored. The invitation itself cannot be sealed, because there is no key of theirs yet: it carries the name you chose to show, your public key and a one-time number, readable by our server, and it waits for up to seven days. Leaving an invitation teaches the sender nothing either: it is accepted the same way whether or not anybody will ever collect it.
Here is the part an absolute claim would get wrong. The slot is an ordinary hash of the value, so every phone computes the same one and so can anybody else who has the value. And with Find me by on, your phone leaves a small bundle of public keys at that slot, so a stranger can seal their first message to you without waiting for your phone to be awake. Anyone who already has your number can ask for that bundle and find out whether the number is published on CHANNEL — including us. That is what publishing a value is: you are saying you want to be reachable at it.
The other direction matters when somebody asks us for records, and it needs stating as carefully. The server holds no values, and it does not file anything under a slot either: each record is kept under a second hash of the slot, made with a key the server holds apart from the records. A copy of the records without that key cannot be matched against any list of numbers. Whoever holds both the records and the key — we, or anybody who obtains both — can hash every possible phone number, which is a small enough set to try in full, and match the results. That recovers each number published with Find me by, together with the public keys left at it, and each number with an invitation waiting at it, for the seven days an invitation is kept. An email address or a handle cannot be listed that way, but a guessed one can be tested the same way. What the records do not hold is a number nobody has published or invited: it answers exactly as a value belonging to nobody does. The server also sees the slot in each request while it answers it; it keeps it only in the keyed form above.
Mobile and SMS information is never sold or shared. No mobile information, and no phone number you give us in order to receive a text message, will be sold or shared with third parties or affiliates for marketing or promotional purposes. Your consent to receive a verification text is not shared with anyone. Phone numbers are disclosed only to the carrier or messaging provider that has to deliver the message you asked for, and to nobody else, for no other purpose. We do not send marketing or promotional text messages of any kind. CHANNEL sends one kind of text message: a verification code you asked for by tapping Send code. That is the only text our provider carries for us. You can stop at any time by replying STOP. Message and data rates may apply.
CHANNEL does not send text messages for you, and our server and our text-message provider carry none of them. For a contact whose card has a phone number, Message another way opens your own Messages app, or WhatsApp, Signal or Telegram where they are installed, with the number filled in and, from the write sheet, your words. You press send there, so it leaves from your own number and nothing of it passes through our server. A text message is not end-to-end encrypted: the phone network can read it. WhatsApp, Signal and Telegram protect a message in their own ways. A device that cannot send texts, such as an iPad on Wi-Fi or a Mac, says so and offers the other apps.
A handle is a third way to be reached. Claiming one costs a number or an address you have already proved, so the namespace cannot be enumerated for free. What our server keeps per handle is a keyed hash of the slot it was claimed from and the time of the claim — not the number, not the address, and nothing that can be joined against a list of numbers. There is no route that answers "who is @name", and leaving an invitation at a handle is accepted whether or not anyone holds the name, so that path says nothing either.
A handle is published the same way a number is, though, and carries the same disclosure: somebody who types the name can fetch the bundle of public keys behind it and learn that the name is claimed and reachable. That is the point of choosing a name people can reach you at. A name nobody has claimed answers exactly as a name nobody has published does, and neither answer names a person.
A formal group's handle, and the hidden one behind its invitation link, are handles like these, claimed by the group's admin with the admin's own proven number or address. Our server keeps the same two things for them and does not know they belong to a group.
A formal group's posts and pictures are kept on our server, encrypted so that only the group's members can read them, and deleted 30 days after they arrive. The server keeps no list of a group's members, with one exception you choose. It sees when posts arrive and how large they are, and never what they say, and it sees the network address of each phone that posts or collects, as it does for any mailbox. A group with no new post for four months is deleted. The exception is wake-ups. If you turn on wake-ups for a group, our server keeps your device's wake-up identifier against that group for seven days at a time, renewed while you stay, and deletes it when you turn them off. That identifier is the one held against your phone's push token (§6), so while it is on, our records tie this phone's push registration to the group — a pseudonym, not a name, but one that Apple or Google could connect to a device. With wake-ups off, nothing on our server ties your phone to the group.
Each member's phone holds the group's member keys and the name each member chose for the group, because a post is sealed to every member. A group created in CHANNEL gives each member a key made for that group alone, carrying nobody's number, address or CHANNEL identity. The app shows the whole member list only to admins; that is a choice of what the screens show, and a modified app could read what its own phone holds.
When a member reports a group from inside it, whatever the reason, we keep what we hold about that group, all of it encrypted, for a year instead of 30 days, together with the time of the report and the reason chosen. We cannot read any of it, and the group is not told. When a report tells us the group shares sexual material involving a child, we report what we know — which group, and when — to the National Center for Missing & Exploited Children, as US law requires.
When you pair with someone, the two phones exchange contact cards: the name you chose, a picture if you set one, the numbers and addresses you marked as shareable, and which calling apps your phone has for those numbers, so the other person can call you without guessing. The card travels sealed, phone to phone or through the mailbox, like any message. Our server never reads it and never holds one.
A CHANNEL call is sealed end to end between the two phones, and it goes directly between them wherever they can reach each other. Where they cannot, it is carried by a relay run by Cloudflare. The relay cannot hear or watch the call; it does see that two endpoints passed media to each other and for how long. The relay therefore sees when the media starts and stops. CHANNEL asks our server for the relay's credentials on a schedule of its own, roughly once a day, so tapping Call does not usually tell our server anything; when the credentials are due for renewal, placing or answering a call fetches fresh ones first, and our server sees that request at that moment. Connecting a call directly also means each phone learns the other's network address, which places it within a town and an internet provider; that is ordinary for any app that carries a call without a server in the middle, and Settings › Calls has a switch that prefers mobile data, where the address says less about where you are.
On an iPhone or a Mac that supports Apple Intelligence, or an Android phone that supports Gemini Nano, the AI features answer on the device itself, using the model the system ships with. There is no account to set up, no key, no request over the network, and no server — not ours, not Apple's, not Google's. Nothing you write or receive leaves the phone when it is answered this way. If the phone's own AI is unavailable, or you have turned it off, the feature is simply not offered unless you have added an account of your own, described next.
CHANNEL has no AI service of its own. If you want AI features beyond what your own phone can do, you add your own account with a provider such as OpenAI, Anthropic or xAI, and your key is kept on your device. Our server never sees the key and is never in the path.
When you use one of those features, a request goes from your device to that provider, on your account and under their privacy policy, not ours. Before it goes, CHANNEL shows you exactly what will leave, including the other person's words when you have chosen to include them, and the button you press is the consent. Summaries, suggested replies and translations are sent only when you ask for them: there are no background calls and no automatic summaries. If you switch an AI account on as a contact, then that conversation, and only that conversation, goes to the provider in the same way each time you write in it. Automatic replies is the exception: when you switch it on for a profile, the incoming one-to-one messages of that profile go to the provider you chose, and its answers are sent without you seeing them first.
CHANNEL reads your location only when you send it. You can send a single fix, taken at the moment you tap, or share your position live, for a fixed time that ends by itself or until you stop it, which updates while the app is open. Either way it goes to the person you are messaging, sealed like any other message, and you can stop a live share at any time. CHANNEL does not read your location at any other time and never sends it anywhere else.
A message can be read out to you. The voice is your phone's own, built into the operating system, and the text is spoken on the device. Nothing is recorded, and no audio and no text is sent anywhere — not to us, and not to a speech service. It is listed here only because a feature that talks is the kind of feature people reasonably assume is sending something somewhere, and this one is not.
Opening a shared location draws a map from CHANNEL’s own map service, with OpenStreetMap data. The service sees which pieces of map the screen needs and the network address they come from, and nothing else: each request carries one app key and nothing that names you or your device. Our code keeps no log of those requests; Cloudflare, which hosts the service, sees the request as any host does. That tells the service roughly where you are looking — not who sent the location, and not who you are. If the service cannot be reached, the map falls back to Apple Maps on iPhone and to OpenStreetMap’s public servers on Android, which see the same area and your address instead.
It happens only when you open a location; nothing is fetched for a conversation you are scrolling past. Handing a place to a map app for directions opens that app, which receives the place.
Pictures and videos are sent as sealed attachments, chosen through your phone's own picker, taken with the camera, or recorded in the app by holding the camera button. CHANNEL does not read your photo library. It asks for permission to add to it only if you choose to save something you received. A video you record in the app is prepared on the device and sent like any other attachment: it is not uploaded anywhere else first, and no copy is kept beyond the one in your conversation.
If you make a backup, the file it produces leaves your phone to wherever you send it. §9 describes what is in it.
Settings has a Performance screen showing how long each way of reaching people has taken on this phone. Those figures are computed and kept on your device and are shown only to you. Nothing on that screen is sent anywhere.
On Android the app can offer a Play Store update from inside the app. That is Google's own update mechanism, under Google's policies; we learn nothing from it.
Report blocks the person on your phone and opens your mail app with a message to us that you write and send yourself. The app attaches no messages and sends nothing on its own. If you send it, we receive it as we receive any email: your address and what you wrote. We keep it while we deal with it. When US law requires us to report what it describes to the National Center for Missing & Exploited Children, we keep it for the year that law requires.
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.
On Android, the files holding your conversations and contacts, and every picture, video and file CHANNEL keeps, are encrypted (AES-256-GCM) with a key held in the phone's Keystore, which never leaves it. On iPhone, the files holding your conversations and contacts are encrypted (AES-256-GCM) with a key kept in the iPhone's Keychain for that device only, and pictures, videos and files are protected by the iPhone's own file encryption. On both, this data opens only on that phone, after it has been unlocked once since it started.
This local data is deliberately excluded from automatic device backups — iCloud Backup on iOS, and the equivalent automatic backup mechanism on Android. We made that choice because an automatically backed-up copy of your conversations would mean your message history existed somewhere other than your device without your having decided so. The only way any of it leaves your phone is the backup file you make yourself, described in §9.
You can also set a code of your own to open the app, at least six characters, and a second, different code that wipes everything CHANNEL holds on the device when it is entered instead. Neither code is stored. Where the phone's security chip (the Secure Enclave on iPhone, the Keystore's secure hardware on Android) passes a test the app runs when the code is set, the chip checks the code; otherwise only a slow one-way hash of it (PBKDF2-SHA256, 210,000 rounds) is kept. Nobody, ourselves included, can recover or reset them. The app does not use Face ID, Touch ID, a fingerprint or the device passcode.
There is no account to close, so erasing is something you do on the device. Settings › Erase offers two choices: erase everything, which returns CHANNEL to the state it was in before you first opened it; or erase your conversations, profiles and keys while keeping the names and numbers on your contact cards, in which case every one of those people becomes unpaired and you would each pair again. Both are final and neither can be undone by us, because we never had any of it.
This is what exists about you on our server, and how each goes: your remote wake-up registration, deleted the moment you turn remote wake-ups off; an @handle if you claimed one, freed when you release it; the public keys published at each value you turn Find me by on for, which lapse within 90 days of your phone last renewing them; and, for a formal group, your wake-up identifier while wake-ups are on for it and your posts for their 30 days; an invitation you left for somebody not yet paired, for up to seven days; and a video or voice note you posted as an Update, sealed, for one day. A report of a group keeps that group's records for a year, as §7 says.
A device you linked keeps its own copy. Removing it under Settings › Linked devices stops people writing to it at once; the app can also tell it to erase itself, which reaches it only if it is switched on and online within thirty days.
CHANNEL can seal your profiles, your identity keys, your contacts, your conversations and your settings into a single encrypted file, under a passphrase you choose. It hands that file to your phone's own file picker, so you decide where it goes: a cloud drive, a folder, a computer. We never hold the passphrase and cannot recover it. Lose it and the file is unreadable, by you and by anyone else. We run no backup service and never receive the file.
Restoring that file on another phone replaces everything CHANNEL holds there, and is how you move to a new device. Two things are deliberately left out: disappearing and view-once messages are never included, and photos and other attachments are not included, for size.
Whoever stores the file learns that a backup exists, its size, and when it changed. That is a real disclosure to whatever service you put it on, and it is why nothing is backed up unless you ask for it.
The microphone — used for calls and for recording a voice message, and for nothing else. A call is sealed end to end between the two phones and a recording is sealed before it leaves yours. We do not request access to your call history, and CHANNEL calls are kept out of your phone's own call log deliberately: that log is backed up and readable by any app holding call-log permission, so a record of who called whom would undo what the rest of this app is for. The record of a call is in the conversation instead, on your device.
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 it never leaves your phone and we never receive it. We cannot produce a backup, because we never receive one. The most a lawful request directed at our internet server could realistically obtain is the limited, short-lived, pseudonymous metadata described in §4; for devices set to be woken remotely, the pseudonymous handle described in §6; and, for a number, address or handle somebody already has in hand, confirmation that it is published on CHANNEL, which §7 describes. We cannot turn any of that into a list of people, because we hold hashes and not values. We do not retain anything beyond what those sections describe, except where the law requires us to keep something longer — for example, US law requires us to keep what we report to the National Center for Missing & Exploited Children for a year.
Some records exist outside our control: our host, Netlify, keeps short-lived request logs that include the address a request came from; your DNS provider can see that your phone looked up our server; your internet provider or carrier can see which servers you connect to; and when the app crashes, Apple (for a TestFlight copy, or when the phone shares analytics with app developers) or Google (when the phone shares usage and diagnostics) sends us a crash report showing where the app stopped and the phone's model and system version. None of them can read your messages. The help page "Your connection" describes how to reduce what they see.
When we learn of child sexual abuse material, US law requires us to report it to the National Center for Missing & Exploited Children, and we do. That report carries what we learned and whatever of the above we hold about it, and nothing more exists for it to carry.
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 remote wake-ups, or an AI account — whose trade-offs are described here.
CHANNEL Messenger is published by ELTON SERVICES LLC, a Florida limited liability company, document number L26000469327.
Questions about this policy, or about how CHANNEL Messenger handles your data, can be sent to: support@channelmessenger.net
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: the terms of service · how CHANNEL Messenger uses encryption · the user guide, the same help the app carries · the full documentation.
CHANNEL on X: @channelmsgr · Email: support@channelmessenger.net
CHANNEL