mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-06 03:38:23 +00:00
Claude
fd32a74575
The Play Console Data safety form said "App doesn't collect or share data" and "Data isn't encrypted". Both are wrong, and the pair contradicts itself: with nothing collected there is no encryption answer to give. The error was reading "collect" as "the developer receives it". Google defines it as transmitting data off the user's device, including by any SDK the app controls - and PRIVACY.md already lists six categories that do. An app requesting seven android.permission.health.* permissions while its public label reads "doesn't collect or share data" is the same kind of contradiction that got the Health Connect declaration rejected twice, and Google cross-checks the two forms against each other. The trap worth writing down: the user-initiated transfer and service provider carve-outs are exceptions to *sharing*, not to *collection*. Publishing a post is a transfer the user expects, so it need not be declared as sharing - but it is still collection. Two exemptions Amethyst genuinely earns and should claim: private DMs under the end-to-end encryption exception (NIP-17/NIP-44), and the My Fitness dashboard under the on-device-only exception, since it computes locally and transmits nothing. Only a workout the user publishes is collected. Verified against the code rather than assumed: no analytics, crash reporting, advertising or attribution SDK exists in any module, so the Analytics and Advertising purposes are never ticked; location is ACCESS_COARSE_LOCATION only; audio covers voice notes and NIP-53 rooms. Two items are left as explicit decisions rather than answered here, because neither is a form-filling choice: - Whether the push notification proxy processes on the developer's behalf (service provider, not shared) or is an independent operator (shared), which decides the Device or other IDs row. - Whether to narrow network_security_config.xml to loopback and .onion so "encrypted in transit" can truthfully be Yes. Today the global cleartextTrafficPermitted="true" keeps user-configured ws:// relays working, so the claim cannot be made unconditionally - but leaving it means the public label reads "Data isn't encrypted" beside a health permission request. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TPShPiTfg16yesupcLgyqf