CRT/storebound
1
0
Fork 0
Code Issues Pull requests Releases 1 Packages 1 Activity Actions

play data-safety: PSL_SUPPORT_DATA_DELETION_BY_USER as Play's single choice (partialDeletion true | false | 'auto90'), drop the removed PSL_DATA_COLLECTION_USER_REQUEST_DELETE (deletionRequest deprecated, check notes it); ship Google's empty form (cli/data/play-data-safety-form.csv, exported 2026-10-12), take every Answer requirement from it and report pairs not in it (formPairIssues) in check, declarations and play data-safety. Pitfall 21

Browse source
This commit is contained in:
CRTkafa 2026-10-12 09:33:56 +08:00
parent dfc28c15f8
commit b5b8f2da9d
35 changed files with 1824 additions and 859 deletions
Download patch file Download diff file Expand all files Collapse all files

12
skills/account-deletion/SKILL.md
View file

@ -31,19 +31,21 @@ deletion requirements" (https://support.google.com/googleplay/android-developer/
verifies the email), what is deleted and what is kept (and for how long, e.g. invoices for tax law), and how long it
takes. No login wall to read it. `storebound validate --play` checks that it answers.
3. In the app: a clear entry, a confirmation step, then the deletion (or the web page). Sign people out afterwards.
4. Play Data safety: `dataSafety.deletionRequest: true`, `accountCreation` set to the sign-up methods you offer (not
4. Play Data safety: `accountCreation` set to the sign-up methods you offer (not
`PSL_ACM_NONE`). Say how people sign up in `accounts.signUp` and `storebound scan` proposes it: `username` (a name
picked in the app, no password, no email; a server token on the device) is Play's "Username and other
authentication" (`PSL_ACM_USER_ID_OTHER_AUTH`) with User ID as the only account data; `username-password` and
`email-password` are "Username and password" (`PSL_ACM_USER_ID_PASSWORD`); `email-link` and `phone` are
`PSL_ACM_USER_ID_OTHER_AUTH`; `oauth` is `PSL_ACM_OAUTH`; `other` is `PSL_ACM_OTHER`. An account alone never means
an email address: declare Email only when the app asks for one. With accounts Play requires more rows, and storebound
writes them: the delete-account URL (`PSL_ACCOUNT_DELETION_URL` = `accounts.deletionUrl`) and "can people delete
some or all of their data without deleting the account?" (`PSL_SUPPORT_DATA_DELETION_BY_USER` =
`dataSafety.partialDeletion`; ask the owner, never guess), plus its web page when the answer is yes
writes them: the delete-account URL (`PSL_ACCOUNT_DELETION_URL` = `accounts.deletionUrl`) and "can people request
that some or all of their data is deleted without deleting the account?" (`PSL_SUPPORT_DATA_DELETION_BY_USER`, a
single choice = `dataSafety.partialDeletion`: `true` yes, `false` no, `'auto90'` no but the data is deleted
automatically within 90 days; ask the owner, never guess), plus its web page when the answer is yes
(`PSL_DATA_DELETION_URL` = `dataSafety.partialDeletionUrl`, default `accounts.deletionUrl`). `storebound check` and
`play data-safety --dry` say `missing: <id> (... set <field>)` for any of them; without them Play answers 400
"Response missing for PSL_ACCOUNT_DELETION_URL".
"Response missing for PSL_ACCOUNT_DELETION_URL". Play removed the old "users can request deletion" question, so
`dataSafety.deletionRequest` is no longer used (`check` notes it; remove it).
5. Privacy policy: a "Deleting your account" section with both paths (`privacy-policy` skill).
6. Test it on a fresh account before every submission; the reviewer will.