rubyforgood / rubyforgood/alongwithyou
Decide unlock behaviour on a device with no lock screen (ADR 0018)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 9
- Forks
- 4
- Avg merge
- 9h 34m
- Merged PRs (30d)
- 16
Description
ADR 0018 (lands with #128) is deliberately Open and needs a named owner to close it, in the same way #23 does for 0009.
0007 settled what happens when the biometric fails — fall back to the device passcode. It was written about lockout, and it assumes there is a device lock to fall back to. Some phones have neither a biometric nor a passcode set, and then there is nothing to prompt with.
This is not a rare edge case for this audience: a passcode is one more thing to remember, and people who find technology difficult are exactly who this app is for.
What ships today is a placeholder, not a decision. The unlock gate explains the situation and lets the user continue. It was chosen because silently doing nothing and hard-refusing both seemed worse than saying something true. The journal is still encrypted at rest either way — the device lock is a second layer, not the only one.
Options (from 0018)
- Refuse to open until a device lock is set. Strongest, and locks someone out of their own medical information over a phone setting they may not know how to change. Hard to square with "keep technology in a supporting role".
- Continue, with a plain explanation. What is built today.
- Prompt once, remember the answer. Nudges without trapping. More UI, and needs somewhere to store the answer.
- Continue, and offer a shortcut into the OS settings screen. Same, with a lower barrier to actually fixing it.
What is needed
- A named owner to pick one
- A decision on whether onboarding says anything about it — #117 already commits to one honest line about backup being the user's responsibility, and this is adjacent to it
- 0018 updated from Open to Accepted with the outcome
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with docs/decisions/0018-no-device-lock-behaviour.md and compare its context with 0007-authentication-recovery-deletion.md. Review the related decisions in #23 and #117, then identify and document an agreed unlock outcome, including whether onboarding addresses it. Done means 0018 moves from Open to Accepted with a named owner and recorded outcome.
Written by the indexing model from the issue text.
Assessment
- Domain
- authentication, documentation, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100