amethyst/docs/play-data-safety.md

Play Console — Data safety form

Source text for the Data safety form (Play Console → Monitor and improve → Policy and programs → App content → Data safety). Keep this file and the form in sync, the same way health-connect-play-declaration.md tracks the Health apps declaration. Google cross-checks the two against each other and against PRIVACY.md; a disagreement between them is what a reviewer finds first.

Why this file exists

The form previously said "App doesn't collect or share data" and "Data isn't encrypted". The first is wrong. The second is right, but only became defensible once the first was corrected: with nothing collected there is no encryption answer to give, so the pair was self-contradictory.

The error came from reading "collect" as "the developer receives it". Google does not define it that way:

"Collect" means transmitting data from your app off a user's device. This includes data transmitted by libraries/SDKs and webviews controlled by your app.

Amethyst has no server, and that remains true and worth saying in the listing — but the test is whether data leaves the phone, not who receives it. PRIVACY.md § "Data sent off-device" already lists six categories that do.

The trap: Google's user-initiated transfer and service provider carve-outs are exceptions to sharing, not to collection. A user tapping Post is a transfer they expect, so it need not be declared as sharing — but it is still collection and must be declared.

Two exemptions Amethyst genuinely earns

• Private DMs — end-to-end encryption. "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." NIP-17/NIP-44 qualifies. Do not declare DM contents.
• The My Fitness dashboard — on-device only. "User data accessed by your app that is only processed locally on the user's device and not sent off device does not need to be disclosed." The dashboard reads Health Connect, computes on device, displays, and transmits nothing. Only a workout the user publishes is collected.

1. Overall questions

Question	Answer
Does your app collect or share any of the required user data types?	Yes
Is all of the user data collected by your app encrypted in transit?	No — see § 4
Do you provide a way for users to request that their data is deleted?	Yes — see § 5

2. Data types — collected

Everything below is optional (the user chooses to post, to upload, to enable push, to connect Health Connect) and its purpose is App functionality only. Amethyst ships no analytics, crash reporting, advertising or attribution SDK — verified: no Crashlytics, Firebase Analytics, AppsFlyer, Adjust, Sentry or Bugsnag anywhere in libs.versions.toml or any module's build.gradle.kts. So never tick Analytics, Advertising or marketing, Fraud prevention, or Personalization.

Category	Type	Collected	Shared	Why
Location	Approximate location	Yes	No	A geohash the user attaches to a post or a location chat. ACCESS_COARSE_LOCATION only — never precise.
Personal info	Name	Yes	No	Display name in the user's published kind-0 profile, if they set one.
Personal info	User IDs	Yes	No	The Nostr public key accompanies every published event and the push registration.
Personal info	Other info	Yes	No	Profile bio, picture and website, if set.
Financial info	Other financial info	Yes	No	Zap amounts appear in published zap events; NWC relays payment instructions to the user's own wallet.
Health and fitness	Health info	Yes	No	Heart rate, only in a workout the user chooses to publish.
Health and fitness	Fitness info	Yes	No	Exercise, distance, steps, calories, elevation, only in a published workout.
Messages	Other in-app messages	Yes	No	Public posts, replies, articles. Private DMs are excluded — E2EE exemption.
Photos and videos	Photos / Videos	Yes	No	Uploads to the media server the user selects.
Audio	Voice or sound recordings	Yes	No	Voice notes, and speaking in a NIP-53 audio room.
Calendar	Calendar events	Yes	No	NIP-52 calendar events the user publishes.
Device or other IDs	Device or other IDs	Yes	See § 3	(Play build, push enabled) FCM registration token.

3. Data types — not collected

Contacts (follow lists are Nostr public keys, not device contacts) · Web browsing history · App info and performance (no crash or analytics SDK) · Files and docs (covered by photos, videos and audio) · Personal info → Email address · Financial info → payment info or purchase history · Precise location · App activity.

The one item needing your decision

The push token path is the only place a third party plausibly receives data outside a user-initiated publish: PRIVACY.md says the token, public key and a preferred relay are "registered with Google Firebase Cloud Messaging so a notification proxy can wake the app."

• If that proxy processes the data on your behalf, the service provider exception applies → Shared: No.
• If it is an independent operator, it is a third party → Shared: Yes for Device or other IDs.

Decide this from how the proxy is actually operated. Everything else in the table is No because publishing to relays is a user-initiated transfer the user reasonably expects.

This is the judgment call in the whole form. Answering "shared with third parties" for Health and fitness would make the public label read that Amethyst shares health data with third parties — which is precisely the prohibited use the Health Connect policy names, and would undercut the declaration. "Collected, not shared" is both accurate under Google's definition and the answer to defend. Be ready to defend it: the user takes a deliberate action, sees the post, and confirms it.

4. Encrypted in transit — answer No, deliberately

Amethyst's own traffic is encrypted: relays are wss://, media uploads are HTTPS, and private DMs are NIP-44 on top of that. But amethyst/src/main/res/xml/network_security_config.xml sets cleartextTrafficPermitted="true" on the global base-config, because a user must be able to connect to any relay they choose, including a ws:// one. That is a deliberate product decision, not an oversight: narrowing it to loopback and .onion would let this answer be "Yes", and it was considered and rejected — cutting off plain ws:// relays is not an acceptable price for a nicer label.

Google only permits "yes" when encryption covers all collected data, so the honest answer is No.

That answer is not the problem, and it never was. What made the old form incoherent was pairing it with "App doesn't collect or share data" — with nothing collected there is no encryption question to answer at all. Once § 2 declares collection truthfully, a "No" here is simply accurate, and it is defensible in one sentence if anyone asks:

Amethyst connects over TLS by default. Cleartext is possible only for a relay address the user typed in themselves, because the user chooses their own relays and the app does not override that choice.

Say the same thing in PRIVACY.md if it is ever queried, so the two agree.

Known consequence, for a health reviewer

A user who configures a ws:// relay and then publishes a workout sends that kind 1301 in cleartext. Nothing in § 2 hides this, and the "No" above is what discloses it. If this is ever raised in review, the options that preserve ws:// entirely are to warn at the point a cleartext relay is added, or to warn before publishing a health-derived event to one. Neither is implemented today — recorded here so the choice is a choice rather than an oversight.

5. Data deletion

The developer runs no server and holds nothing, so there is no developer-held copy to request deletion of. Users can:

• wipe everything local by clearing app storage or uninstalling (PRIVACY.md § "Data stored on your device");
• delete an account's data in-app;
• request deletion of published events with NIP-09 — noting, as PRIVACY.md already says, that relays may not honour it and public content should be assumed permanent.

Say this plainly rather than claiming deletion guarantees the protocol cannot give.

6. Keep these three in sync

The Health apps declaration, this form, and PRIVACY.md are one statement split across three places. A reviewer reads all three. Before any resubmission, check that each data type here also appears in PRIVACY.md, and that nothing here contradicts health-connect-play-declaration.md § 4.