Privacy-Period-Tracker/docs/security/SECURITY_CHECKLIST.md

# Security checklist — Privacy: Period Tracker

```
Status: Current
Owner: _null
Last reviewed: 2026-08-18
Governs: the checks run before a Play release, and what each one proves
Review trigger: A new SDK; a new class of input; a change to what is logged,
                exported or backed up; any finding that got past this list
```

## Why this is separate from SECURITY.md

[`SECURITY.md`](SECURITY.md) is the threat model: what is protected and from
whom. It is read carefully once and revisited rarely.

This is the list somebody actually works through before pressing publish.
Keeping them apart means the model can stay stable while the checks change, and
it means the release list stays short enough to finish rather than skim.

## Before a release

- [ ] `bash scripts/secrets.sh --tracked` is clean — proves no credential shape is in the tracked tree
- [ ] `git log -p` searched for keystore, `.jks`, service-account JSON and `local.properties` — proves nothing secret is in the **history**, which a directory listing cannot tell you
- [ ] The release APK/AAB is signed by the upload key from outside the repository — proves signing config never needed a tracked secret
- [ ] `./gradlew test` passes with the prediction acceptance tests included — proves the forecast still behaves at the boundaries §51 names
- [ ] Play **Data Safety** declaration re-read against what the app actually sends — proves the declaration is a description rather than an aspiration
- [ ] Play **Health apps** declaration completed as applicable — proves the category rules were checked, not assumed
- [ ] Store listing carries no medical or contraceptive claim — proves the copy did not drift past what the app can support
- [ ] Current Play target-API requirement confirmed **at submission time**, not from this document — proves the deadline was checked rather than remembered
- [ ] `./gradlew checkPermissions` passes and every permission it reports is one somebody decided on — proves the Play listing and the Data Safety form describe a chosen set rather than whatever the dependencies brought

## Standing checks

- [ ] No secret in the repository, in a log line, or in an error message
- [ ] Every input that reaches a query or a filesystem path is validated at the boundary
- [ ] Dependencies reviewed, and any accepted advisory recorded with a reason
- [ ] Every third-party SDK in the build is in [`SECURITY.md`](SECURITY.md)'s third-parties table — proves a dependency did not arrive without a decision

### Health data never reaches advertising

The one group that is not generic. Every item proves part of
[`../planning/PRODUCT_PLAN.md` §34](../planning/PRODUCT_PLAN.md).

- [ ] `core:ads` is included in `settings.gradle.kts` and declares **no** Gradle project dependency at all — the rule is `":core:ads" to emptySet()` in the root `build.gradle.kts`, stricter than "nothing from core/database or `domain/*`" — and the boundary guard was **proved to fail** this release — proves the check is evidence rather than decoration, and that it examined the module rather than a rule matching nothing
- [ ] No health-derived value appears in an ad request extra, user property, or callback log — proves targeting cannot happen by accident
- [ ] Ad requests are non-personalized/contextual, with region-appropriate consent — proves the default is the private one
- [ ] The ads provider is not initialised for entitled (ad-free) users where practical — proves the purchase removes the SDK, not just the view
- [ ] The built AAB inspected for the ad SDK's declared collection — proves the scan reached the artifact users receive, not only the source

### What the device and the lock screen expose

- [ ] Cycle history is in app-private storage only — proves nothing landed in shared or external storage
- [ ] With the app lock on, the recents card is a solid colour and `adb exec-out screencap` returns a black frame — proves `FLAG_SECURE` is actually applied, which no source check can establish
- [ ] Killed with `adb shell am kill` and reopened from recents, the app lands on the lock screen — proves the unlock flag is not in saved state, which is the one bug that would make the lock look fine and never engage
- [ ] A reminder action tapped while locked writes nothing until after the unlock — proves a bystander cannot record an answer in someone's history from the phone's own lock screen
- [ ] In fingerprint-only mode, removing every fingerprint in phone settings leaves the app **closed**, showing how to get back in — proves an unavailable sensor does not switch the lock off, which would make it removable by anyone who knows the phone's own PIN
- [ ] In fingerprint-only mode, `am kill` and reopen shows one prompt, and cancelling leaves a button rather than an empty screen — proves the auto-prompt cannot loop and cannot strand
- [ ] Switching to fingerprint-only with no fingerprint enrolled is refused before anything is written — proves the method with no fallback is offered only where it demonstrably works
- [ ] An install upgraded from a PIN-only build still opens with that PIN, and one with the fingerprint shortcut on offers both — proves the migration gave every old install the method it already had
- [ ] A fingerprint enrolled on API 26 or 27 opens the app through the compat dialog — proves the pre-API-28 path `USE_FINGERPRINT` exists for is real, and is the one biometric route no current emulator exercises
- [ ] An OEM biometric overlay that stops the activity does not relock the app under its own prompt — proves the `authInProgress` guard holds on the devices it was written for; without it a successful scan returns to a locked screen forever
- [ ] Rotating the phone and setting font scale to 2.0 while unlocked does not relock — proves the gate tells a configuration change apart from a real backgrounding
- [ ] TalkBack reads the lock screen as a password field and announces the wait after a wrong PIN — proves the one screen a person may meet without ever having opened the app is usable without sight
- [ ] No `FLAG_SECURE` flicker on first launch — proves the flag is set before anything can be drawn, rather than after a frame of real content has reached the recents thumbnail
- [ ] `KeystoreVerifierTest` run on `PeriodMinSdk26` as well as a current image — proves `PBKDF2WithHmacSHA256` and a non-auth-bound Keystore key exist at the oldest supported version, which is the one algorithm choice here with no margin
- [ ] The erase behind "Forgot your PIN?" leaves the app openable — proves the Keystore key went with the records, and the user is not erased *and* still locked out
- [ ] No shipped string, illustration, screenshot or store listing says the cycle database is **encrypted** — proves the product does not claim a control [`SECURITY.md`](SECURITY.md) records as deliberately out of scope. It is on this list because the claim is attractive, easy to draw, and was already sitting in an artwork brief before anybody checked whether it was true
- [ ] Lock-screen text in **Discreet** and **Maximum privacy** modes contains no menstrual detail, checked on a real lock screen at every mode — proves the notification privacy feature actually works, which is the breach most likely to happen
- [ ] The health database's inclusion in platform auto-backup is a **recorded decision**, not a default — proves the local-first promise is not undone by the OS
- [ ] Release build has verbose logging off and no raw cycle date in any crash payload — proves §45's logging rule survived the build type
- [ ] Delete My Data removes the rows and is irreversible after confirmation — proves the promise in Settings is true
- [ ] Export produces only the user's own data, to a location they chose — proves export is not an accidental leak path
- [ ] The export run once on a device, end to end through the system save dialog — proves the Storage Access Framework path works against a real document provider, which no Robolectric test reaches
- [ ] The exported file opened and read — proves it is the human-readable archive §35 asks for, and that the dates in it are the dates the user entered
- [ ] An export attempted while the app lock is on, returning through the lock screen — proves the destination is written only after the unlock, and written once
- [ ] A file that is **not** this app's archive, chosen for a restore, changes nothing and says so — proves the only untrusted input this app takes is identified by its contents rather than by its name, extension or MIME type
- [ ] A restore attempted while the app lock is on, returning through the lock screen — proves the archive is read only after the unlock, and read once. Without it, whoever took the phone during the file dialog could overwrite the owner's history without passing the lock
- [ ] A restore with **Replace what is here** chosen cannot be reached without the confirmation dialog, on a device — proves the one irreversible choice in this feature is two taps and names what it deletes
- [ ] An archive carrying `"biometricUnlock": true` leaves the app lock exactly as it was — proves a file cannot turn on a fingerprint shortcut for a lock set on this phone

### The compliance bar, which is not the launch bar

- [ ] The privacy policy is published, reachable from the app, and matches what the app does
- [ ] The privacy promise appears in onboarding, in Settings → Privacy & Security, and on the public privacy page — proves the promise is where §4 says it must be

*(Not applicable here, and deleted rather than carried as permanently skipped:
authorisation and IDOR checks — there are no accounts and no server; browser
bundle and cookie checks — there is no browser; rate limiting and spend
ceilings — there is no endpoint of ours to exhaust.)*

## What got past this list

Add an entry whenever a real finding was not caught here, and then add the check
that would have caught it. A checklist that never grows is one nobody is honest
with.

| When | What was missed | The check now added |
| --- | --- | --- |
| — | — | — |