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 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'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.

• 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 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

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
—	—	—