# Google Play Data Safety form — answers for Channel Messenger Written so whoever fills in the live Play Console form does not have to re-derive anything from `DECISIONS.md`, `server/README.md`, or the app's permission requests. **Play Console's own wording and category list change periodically — cross-check each answer against the live form before submitting, rather than transcribing this blind.** Where a category has more than one plausible answer, both are given with the reasoning, because this is a judgment call and not a lookup. Effective as of the current design: no accounts, no analytics, contacts read only in memory when the user opens that screen and never collected (adding someone from the address book goes through the system picker, which the app cannot read), no location access, direct radio delivery with no server, and an optional internet fallback relay with optional push notifications. If any of that changes, this document is stale — update it alongside the code change, not after. --- ## Section 1 — Data collection and security **Does your app collect or share any of the required user data types?** Answer: **Yes**, conditionally — one data type only, and only if the user opts into push notifications. See "Device or other IDs" below. If push notifications are removed or shipped disabled at launch, the honest answer becomes **No** and this whole form simplifies to "no data collected." **Is all the user data collected by your app encrypted in transit?** Answer: **Yes.** All traffic to the internet fallback relay is over HTTPS/TLS. Message content carries a second, independent layer of end-to-end encryption underneath the transport encryption — the relay's own transport connection being encrypted does not mean the relay can read the message; it cannot, under any circumstance, because it does not hold the keys. **Do you provide a way for users to request that their data be deleted?** Answer: **Yes, in the sense that applies here — there is no account-deletion flow because there is no account.** There is nothing tied to a user's identity for us to delete on request, because nothing we hold is tied to an identity in the first place (no name, email, phone number, or account ID exists anywhere in the system). What a user can do: - Delete the app, or clear its local data, to remove everything stored on their own device (§7 of `privacy-policy.md`). - Any message sitting in the relay unclaimed expires automatically within, at most, 30 days (`server/README.md`, `DECISIONS.md` J6) — there is no user request needed for it to be removed. - A user who opted into push notifications can turn push off, which unregisters (deletes) their registration entry rather than merely silencing it (`server/README.md`, endpoint `DELETE /v1/register?id=`). If Play's form requires a formal "request deletion" mechanism (e.g., a support contact or in-app control) regardless of whether an account exists, point it at the contact address in `privacy-policy.md` §13 and note that requests will typically already be moot, since nothing identity-linked is retained. **Independent security review (optional, e.g. MASA badge)** Not yet done as of this writing. Leave unanswered / "No" until (if) `mesh-core-rs` and the relay undergo one. Not a blocker for submission. --- ## Section 2 — Data types Go through Play's categories in order. Anything not listed below is **not collected.** ### Location **Not collected.** No location permission is requested; nothing in the app reads location. ### Personal info (name, email, phone number, address, etc.) **Not collected.** There is no account system and no field anywhere in the app or the relay that holds a name, email address, phone number, or physical address. ### Financial info **Not collected by the app.** If in-app purchase is added later (pricing is not yet settled — `DECISIONS.md` J4), purchase transactions go through Google Play Billing directly; per the F1 design decision, no purchase, receipt, or subscription state is ever passed into the app's own data model or onto the wire. Google's own handling of Play Billing data is covered by Google's policies, not something this app collects independently. Re-confirm this section once a monetization model is implemented — if the app itself ever reads or stores purchase state, this answer must change. ### Health and fitness **Not collected.** Not applicable to this app. ### Messages **Not collected, in the sense Play's form asks about.** Message content transits the internet fallback relay only as end-to-end encrypted ciphertext the relay cannot decrypt; the developer never has access to plaintext message content at any point. Google Play's Data Safety guidance distinguishes data that is merely relayed and inaccessible to the developer (not collected) from data the developer can actually access (collected) — **verify this distinction's current wording in Play Console's help center before answering**, since it is the basis for this answer and policy text has been known to shift. If in doubt, disclose "Messages" as collected-but-not-accessible rather than omitting it, and use the form's free-text explanation field to state plainly that content is end-to-end encrypted and the developer cannot read it. ### Photos and videos **Not collected.** The app does not access the photo library. Camera access exists only for scanning a QR code during pairing (§9 of `privacy-policy.md`); no photo or video is captured, stored, or transmitted. ### Audio files **Not collected.** No microphone access; voice messages are not a feature. ### Files and docs **Not collected.** The app is text-only (`DECISIONS.md` C7); there is no file attachment feature. ### Calendar **Not collected.** ### Contacts **Not collected**, and that answer is unchanged by the Phone Contacts screen — Play's question is about data **leaving the device**, and nothing does. The app *may now read* the address book, with permission, and only when the user opens that screen. It is held in memory to draw the list and is never written to app storage, indexed, hashed, or transmitted. Declining the permission disables that one screen and nothing else; the system contact picker route still needs no permission at all (`DECISIONS.md` A2, G1, J38, J50). **If Play's form asks whether the app *accesses* contacts as distinct from collecting them, answer yes.** Answering "no permission is requested" was true before the browse screen existed and is not true now. A user may add someone *from* their address book, using the platform's **system contact picker** (iOS `CNContactPickerViewController`). That picker runs outside the app: it renders the address book itself and returns only the entry the user taps. Apple states that an app using it "does not need access to the user's contacts and the user will not be prompted for 'grant permission' access." What the app receives is **one display name**, kept on the device, identical to what the user could have typed into "Add by Name". No phone number, email, photo or address-book identifier is read, and nothing derived from the address book is transmitted off the device — so this stays *Not collected* under Play's definition (data is "collected" when it leaves the device). It is also not *shared*. If a future version ever reads the address book directly, requests the contacts permission, or sends anything derived from it anywhere, this answer changes and so does `privacy-policy.md` §2 and §9 — in the same release, not after. ### App activity (app interactions, in-app search history, installed apps, other user-generated content, other actions) **Not collected.** No analytics SDK of any kind is included (`DECISIONS.md` A2). Nothing about how the user interacts with the app is recorded or transmitted. ### Web browsing **Not collected.** Not applicable. ### App info and performance (crash logs, diagnostics, other performance data) **Not collected.** No crash-reporting SDK is included. If the app crashes, the developer does not learn about it unless the user reports it directly. ### Device or other IDs — the one conditional "Yes" **Collected only if the user opts into push notifications**, which are off by default (`DECISIONS.md` J6, J9, J10; `privacy-policy.md` §6). When enabled, the app registers a device-generated identifier (`notifyId`) with the internet relay so it can be woken via Google's push service (or Apple's, on iOS). This identifier: - Is not a persistent hardware identifier (not IMEI, not a serial number, not an advertising ID — none of those are read or used). - Is generated by the app itself, not derived from anything that identifies the user personally. - Is disclosed here because, being stable across sessions rather than rotating, it functions as a durable pseudonym at the relay for as long as push stays enabled (this is explained candidly to users in `privacy-policy.md` §6, not something to soften in this form). **Purpose:** App functionality (to enable optional push wake-ups). Not used for advertising, personalization, or analytics of any kind. **Is it shared with third parties?** It is provided to Google's push notification infrastructure (Firebase Cloud Messaging on Android) purely as the transport mechanism required to deliver a notification — this is standard platform plumbing common to essentially every Android app that offers push notifications, not a data sale or an advertising integration. Play's current guidance on what counts as "sharing" versus "service provider processing" for platform-required push delivery should be checked against the live form; if Play's categorization requires disclosing this as third-party sharing, disclose it, with purpose "App functionality" and explicitly marked not for advertising or marketing. **Is this data type required or optional, and can users opt out?** Optional. Users who never enable push notifications never have this identifier collected at all, and users who disable push after enabling it have their registration deleted, not merely deactivated (`DELETE /v1/register?id=`). --- ## Section 3 — Security practices **Data is encrypted in transit:** Yes (TLS to the relay, plus independent end-to-end encryption of message content underneath it). **Data is encrypted at rest:** The relay stores ciphertext it cannot decrypt; there is no plaintext at rest anywhere on the relay. On-device, message history and identity keys are stored using the device's own file-protection mechanisms and are excluded from device backups (§7 of `privacy-policy.md`; iOS: `completeFileProtectionUntilFirstUserAuthentication` plus backup exclusion; Android: `android:allowBackup="false"`). **Users can request data deletion:** See Section 1 above — there is no account to delete, but every practical form of "delete my data" is already available (uninstall/clear local data; automatic relay expiry within 30 days at most; push de-registration deletes rather than disables). --- ## Summary for whoever fills in the live form If pressed for the one-line version: **this app collects nothing identifying, with a single narrow exception — an opt-in, off-by-default push-notification identifier, disclosed above with its exact purpose and its one real privacy cost stated plainly.** Every other Play Data Safety category is "not collected," and that is a description of the architecture (`DECISIONS.md` section A, F1, F2), not a policy choice made for this form.