SECURITY.md describes a biometric key that does not exist, and the checklist is missing the rows the log says it has #66

New Issue

Closed

opened 2026-08-20 21:22:38 -05:00 by null · 0 comments

null commented

2026-08-20 21:22:38 -05:00

Owner

What is true now. Two documents describe a BiometricKey — core/security/.../AndroidKeyStoreMacProvider.kt:31 ('The biometric key in [BiometricKey] does set it, correctly...') and docs/security/SECURITY.md:73-79 ('The biometric key is separate and takes the opposite policy'). grep -rn BiometricKey returns exactly those two references and no such class. There is no biometric-bound Keystore key anywhere: BiometricUnlock.kt uses no CryptoObject, and AppLockViewModel.unlockFromBiometric() (:135-138) simply flips the session flag.

Separately, docs/history/DEVELOPMENT_LOG.md:381-385 states that six device checks — a fingerprint enrolled on API 26/27, rotation and fontScale 2.0 while unlocked, a reminder action tapped while locked on hardware, an OEM biometric overlay, a FLAG_SECURE flicker on first launch, and TalkBack on the lock screen — 'are now rows in SECURITY_CHECKLIST.md rather than memory'. grep -in 'biometric|fingerprint|talkback|rotation|fontScale|flicker' over that 87-line file returns nothing. They were never added.

What it costs. A security document that describes protection the code does not have is worse than one that admits the gap: the next reader trusts it. And a checklist that is missing the rows the log says it has means the release gate silently skips them.

What to do. Replace the phantom sentences with what is true — a biometric success flips the session flag and nothing else — and record the enrolment-invalidated key as a filed follow-up for the PIN-and-fingerprint mode only, where the threat (a partner enrols their own finger) is real and the degrade path to the PIN exists. Add the six promised rows to the checklist, plus rows for whatever biometric-only mode ships.

Traps. Do not 'fix' this by implementing a biometric-bound key in a mode with no PIN behind it: a key invalidated by ordinary enrolment would degrade to permanent lockout under the no-recovery policy, which AndroidKeyStoreMacProvider's own KDoc forbids.

Verify: grep -rn BiometricKey returns nothing outside a follow-up note, and docs/security/SECURITY_CHECKLIST.md contains a row for each of the six device checks named in DEVELOPMENT_LOG.md:381-385.

**What is true now.** Two documents describe a `BiometricKey` — `core/security/.../AndroidKeyStoreMacProvider.kt:31` ('The *biometric* key in [BiometricKey] does set it, correctly...') and `docs/security/SECURITY.md:73-79` ('The biometric key is separate and takes the opposite policy'). `grep -rn BiometricKey` returns exactly those two references and no such class. There is no biometric-bound Keystore key anywhere: `BiometricUnlock.kt` uses no `CryptoObject`, and `AppLockViewModel.unlockFromBiometric()` (`:135-138`) simply flips the session flag. Separately, `docs/history/DEVELOPMENT_LOG.md:381-385` states that six device checks — a fingerprint enrolled on API 26/27, rotation and fontScale 2.0 while unlocked, a reminder action tapped while locked on hardware, an OEM biometric overlay, a FLAG_SECURE flicker on first launch, and TalkBack on the lock screen — 'are now rows in SECURITY_CHECKLIST.md rather than memory'. `grep -in 'biometric|fingerprint|talkback|rotation|fontScale|flicker'` over that 87-line file returns nothing. They were never added. **What it costs.** A security document that describes protection the code does not have is worse than one that admits the gap: the next reader trusts it. And a checklist that is missing the rows the log says it has means the release gate silently skips them. **What to do.** Replace the phantom sentences with what is true — a biometric success flips the session flag and nothing else — and record the enrolment-invalidated key as a filed follow-up for the PIN-and-fingerprint mode only, where the threat (a partner enrols their own finger) is real and the degrade path to the PIN exists. Add the six promised rows to the checklist, plus rows for whatever biometric-only mode ships. **Traps.** Do not 'fix' this by implementing a biometric-bound key in a mode with no PIN behind it: a key invalidated by ordinary enrolment would degrade to permanent lockout under the no-recovery policy, which `AndroidKeyStoreMacProvider`'s own KDoc forbids. Verify: `grep -rn BiometricKey` returns nothing outside a follow-up note, and `docs/security/SECURITY_CHECKLIST.md` contains a row for each of the six device checks named in DEVELOPMENT_LOG.md:381-385.