play data-safety: PSL_SUPPORT_DATA_DELETION_BY_USER is the general 'can users request deletion?' question; a delete-account URL answers yes (with PSL_DATA_DELETION_URL), dataSafety.dataDeletion for apps without one; check flags a no next to a delete-account URL

This commit is contained in:
CRTkafa 2026-10-12 09:46:58 +08:00
parent e01a27d7b7
commit dbd9f2973c
15 changed files with 95 additions and 66 deletions

View file

@ -38,11 +38,12 @@ deletion requirements" (https://support.google.com/googleplay/android-developer/
`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 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
writes them: the delete-account URL (`PSL_ACCOUNT_DELETION_URL` = `accounts.deletionUrl`) and "Do you provide a way
for users to request that their data is deleted?" (`PSL_SUPPORT_DATA_DELETION_BY_USER`, a single choice). The
delete-account page is such a way, so the answer is yes (`DATA_DELETION_YES`); answering no next to a delete-account
URL contradicts it and `check` flags it. The yes needs a "Delete data URL" (`PSL_DATA_DELETION_URL`):
`dataSafety.partialDeletionUrl` when there is a page that deletes data without deleting the account
(`partialDeletion: true`), else the delete-account page. `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". Play removed the old "users can request deletion" question, so
`dataSafety.deletionRequest` is no longer used (`check` notes it; remove it).

View file

@ -82,11 +82,12 @@ CLI: `storebound` (or `bunx storebound` in a project that has it, or `bun <toolc
omits it: without it the import fails with "Response missing". storebound always writes it.
- Conditional required rows: some questions become required by another answer, and Play refuses the import with
"Response missing for <id>" (400). Account creation not `PSL_ACM_NONE` -> `PSL_ACCOUNT_DELETION_URL` (from
`accounts.deletionUrl`) and `PSL_SUPPORT_DATA_DELETION_BY_USER` ("delete some or all data without deleting the
account?", a single choice: `dataSafety.partialDeletion: true | false | 'auto90'` = `DATA_DELETION_YES` /
`DATA_DELETION_NO` / `DATA_DELETION_NO_AUTO_DELETED` "no, but deleted automatically within 90 days", ask the
owner); that answer true -> `PSL_DATA_DELETION_URL`
(`dataSafety.partialDeletionUrl`, default `accounts.deletionUrl`); `PSL_HAS_OUTSIDE_APP_ACCOUNTS` is refused next
`accounts.deletionUrl`) and `PSL_SUPPORT_DATA_DELETION_BY_USER`, the GENERAL "Do you provide a way for users to
request that their data is deleted?" (single choice `DATA_DELETION_YES` / `DATA_DELETION_NO` /
`DATA_DELETION_NO_AUTO_DELETED`). A delete-account page is such a way, so with `accounts.deletionUrl` storebound
answers yes, and `check` flags anything else next to a delete-account URL. Without one: `dataSafety.dataDeletion:
'yes' | 'no' | 'auto90'`. A yes needs `PSL_DATA_DELETION_URL` ("Delete data URL"): `dataSafety.partialDeletionUrl`
for a page that deletes data without deleting the account (`partialDeletion: true`), else the delete-account page; `PSL_HAS_OUTSIDE_APP_ACCOUNTS` is refused next
to sign-up methods. A selected data type needs collected / shared, ephemeral, required / optional and a purpose
(a sharing purpose when shared). `storebound check` and `play data-safety --dry` name each missing row as
`missing: <id> (<when>; set <config field>)` and the real run stops before sending. Rules:

View file

@ -252,8 +252,9 @@ testers) and answers, in ONE batch at the start, only the facts no file proves (
form's Response IDs: `PSL_SUPPORT_DATA_DELETION_BY_USER` became a single choice (`DATA_DELETION_YES` /
`DATA_DELETION_NO` / `DATA_DELETION_NO_AUTO_DELETED`) and a bare FALSE got 400 "Line 7: Response ID missing";
`PSL_DATA_COLLECTION_USER_REQUEST_DELETE` was removed from the form.
- **Do:** set `accounts.deletionUrl`, ask the owner for `dataSafety.partialDeletion: true | false | 'auto90'` (and
`partialDeletionUrl` when true and it is another page), run `storebound check` / `play data-safety --dry` until no
- **Do:** set `accounts.deletionUrl` (it also answers `PSL_SUPPORT_DATA_DELETION_BY_USER` with yes: that is the
general "can users request deletion?" question, not "without deleting the account"; a no next to a delete-account
URL was a false declaration storebound wrote once), set `partialDeletionUrl` only for a data-only page, run `storebound check` / `play data-safety --dry` until no
`missing: <id>` is left. If Play names an id storebound does not know, export the form (Play Console > App content >
Data safety > Export to CSV) and add the row in `dataSafety.extra` (same id = replaces the generated row).
When Play changes the form, export it empty and save it over `cli/data/play-data-safety-form.csv`.