The answers below describe what the app and its relay do, checked against the code on 30 September 2026 (J1800). They are written so that whoever fills in the live Play Console form does not have to re-derive anything. Play Console's wording and categories change; check each answer against the live form before submitting, and re-read this document whole before every store submission rather than trusting that a feature change updated it.
The Console declaration matches these answers as of 2 October 2026 (submitted that day and in Google's review): data collected, encrypted in transit, no account, deletion at channelmessenger.net/privacy.html#delete; Name, Email address, Phone number, SMS or MMS, Other in-app messages and Device or other IDs each collected, optional, not shared, not ephemeral, for App functionality; nothing shared. Read it back after any change to what the app sends.
---
Google's guidance (read live 29 September 2026 on Play's "Provide information for Google Play's Data safety section" page): "User data that is sent off device, but that is unreadable by you or anyone other than the sender and recipient as a result of end-to-end encryption does not need to be disclosed."
That exemption covers what CHANNEL seals: messages, photos, video, voice messages, files, locations sent to a contact, contact cards, call media, and a formal group's posts. It does not cover anything that leaves the phone unsealed, and three things do:
Everything else in this document follows from that split.
---
Does your app collect or share any of the required user data types? Yes. The wake registration alone makes this Yes for almost every user, because Push is what a new install uses (Preferences.wakeOnMail defaults to true on both platforms), and Fetch registers too. Only a phone set to On Demand registers nothing.
Is all of the user data collected by your app encrypted in transit? Yes. Every request to the relay is HTTPS. Sealed content carries end-to-end encryption underneath that. A message to somebody not on CHANNEL goes from the sender's own Messages app and never reaches our relay.
Do you provide a way for users to request that their data be deleted? Yes. There is no account. What the relay holds for a user is deleted from inside the app or expires on its own:
Point the form's deletion link at the contact address in the privacy policy.
---
Anything not listed here is not collected.
The wake registration: an identifier the app generates (notifyId), held by the relay against the device's push token so Apple or Google can be asked to wake it. Not a hardware identifier and not an advertising ID. It is stable while wake-ups stay on, so it is a durable pseudonym at the relay, and while wake-ups are on for a formal group it is also held against that group (group-follows, seven days at a time, renewed daily).
Optional: On Demand turns it off. Purpose: App functionality. Google's and Apple's push services deliver the wake as service providers, which Play does not count as sharing; if the live form says otherwise, declare it shared, purpose App functionality, not for advertising.
CHANNELPairingPayload.encodedWithName) -- and waits on the relay for up to seven days (invite.mts).Purpose: App functionality. The delivery providers are service providers.
An invitation to somebody not yet paired carries the sender's chosen name, so the name leaves the device unsealed. Purpose: App functionality.
J2260: CHANNEL sends no text message from our number except a verification code, and the relay holds no text. A message to somebody not on CHANNEL is handed to the sender's own Messages app (or WhatsApp, Signal, Telegram) and never reaches us. The Play Console answer is the owner's to change.
Everything CHANNEL seals falls under the exemption above. The one open case is an AI request: when the user asks for one, the app sends the words the sheet showed them, possibly including the other person's, from the device to the user's own AI provider account. It never passes through us. Play counts data the app transmits off the device as collected, and treats a transfer the user initiates and reasonably expects as not sharing. The conservative answer is collected, optional, not shared, purpose App functionality, with the free-text field saying it goes to the user's own provider account only when the user asks.
Read only when the user sends it, and sent sealed to a contact. Under the exemption.
Sealed on the device and relayed only as ciphertext. Under the exemption. A formal group's photos and an Update's video or voice note are sealed once for their audience and kept on the relay as ciphertext (30 days and one day), which is the same case.
The address book is read in memory to draw the Phone contacts screen, with permission, and never written, hashed or transmitted. If the form asks about access as distinct from collection, the app does access contacts.
Subscriptions go through Google Play Billing; the app holds no purchase data of its own.
No analytics, no crash reporting, no advertising code. The Performance screen's figures stay on the device.
---
Encrypted in transit: Yes. Encrypted at rest: sealed content is ciphertext on the relay; the relay holds no plaintext message. On the device, every store is sealed under a key held in the phone's secure hardware, and the app's data is excluded from automatic device backups.
---
Read back on 29 September 2026: "no data collected". Changed on 2 October 2026 to the list below (item 6 answered collected, optional, not shared). Kept as the record of what each answer is:
Play Data safety, 6 October 2026: SMS or MMS unticked (J2260); Messages now declares only "Other in-app messages". Saved, not sent for review: it rides with the first production release.
English is the reference text; any translation is a convenience.