> Source file last changed: 2026-11-02. Dates inside the document record when each part was written, checked or submitted. # Google Play Data Safety form — answers for CHANNEL Messenger 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. --- ## The rule this form turns on 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: 1. **The wake registration** (Device or other IDs). 2. **A verification request** (Phone number, Email address). 3. **A request to an AI provider the user set up** (Messages; see the judgement below). Everything else in this document follows from that split. --- ## Section 1 — Data collection and security **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: - the wake registration, deleted when wake-ups are turned off, dropped after 45 days unrenewed; - a formal group's wake follow, deleted when turned off, lapsing seven days after the last renewal; - an @handle, freed when released; - published public keys at a Find me by slot, lapsing 90 days after the last renewal; - mailbox envelopes, deleted on collection, at most 30 days uncollected; - a formal group's posts, 30 days; a group's records after a member's report, one year; Point the form's deletion link at the contact address in the privacy policy. --- ## Section 2 — Data types Anything not listed here is **not collected**. ### Device or other IDs — **collected**, optional, not shared 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. ### Personal info — Phone number, Email address — **collected**, optional, not shared - **Verifying a value.** The number or address goes to the relay once, which keeps a keyed hash of it for ten minutes and hands the value to the provider that delivers the code (Telnyx for text and voice; an email provider for email). Telnyx keeps the text up to ten days. - **An invitation to somebody not yet paired** (writing to a number, address or handle) cannot be sealed, because there is no key of theirs yet. It carries the sender's chosen name, public key and a one-time nonce -- not the value it was sent to, which only derives the slot it is filed under (`PairingPayload.encodedWithName`) -- and waits on the relay for up to seven days (`invite.mts`). Purpose: App functionality. The delivery providers are service providers. ### Personal info — Name — **collected**, optional, not shared An invitation to somebody not yet paired carries the sender's chosen name, so the name leaves the device unsealed. Purpose: App functionality. ### Messages — SMS or MMS — **not collected** `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.** ### Messages — Other in-app messages — **owner's judgement** 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. ### Location — not collected Read only when the user sends it, and sent sealed to a contact. Under the exemption. ### Photos and videos, Audio files, Files and docs — not collected Sealed on the device and relayed only as ciphertext. Under the exemption. A formal group's photos, video and voice notes are sealed once for their audience and kept on the relay as ciphertext (30 days and one day), which is the same case. ### Contacts — not collected 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. ### Financial info — not collected Subscriptions go through Google Play Billing; the app holds no purchase data of its own. ### App activity, Web browsing, App info and performance, Health and fitness, Calendar — not collected No analytics, no crash reporting, no advertising code. The Performance screen's figures stay on the device. Exception to disclose: Google's ML Kit (on-device translation and language detection) downloads language packs from Google and may send Google usage and performance metrics about the ML Kit components. Message text is translated on the device and is not sent. --- ## Section 3 — Security practices **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. --- ## What the Play Console declaration has to change 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: 1. **Data collection:** Yes. 2. **Device or other IDs:** collected; optional; not shared; App functionality. 3. **Phone number** and **Email address:** collected; optional; not shared; App functionality. 4. **Name:** collected; optional; not shared; App functionality. 5. **Messages ▸ SMS or MMS:** collected; optional; not shared; App functionality. 6. **Messages ▸ Other in-app messages:** the owner's call on the AI request (above). 7. **Data deletion:** Yes, with the privacy policy's contact address. 8. **Encrypted in transit:** Yes. 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.