Accessibility & Security Framework¶
Security measures that exclude users with disabilities or create barriers during moments of crisis are both a legal liability and a mission failure. This framework defines how BNI balances strong security with ease of use for its specific user populations.
The core tension¶
Users need the app most when they are in crisis — cold, injured, intoxicated, cognitively impaired, being watched, or distressed. These are exactly the conditions under which standard authentication fails most often. A security model that locks someone out during a crisis has failed its primary purpose.
flowchart LR
A["User in crisis\n(cold · injured · distressed)"] --> B["Authentication barrier"]
B -->|"fails"| C["Locked out of help"]
B -->|"succeeds"| D["Access to safety tools"]
C --> E["❌ Mission failure"]
D --> F["✅ Mission success"]The design goal is to make the right side of this diagram reliable even in the worst conditions.
Principle 1 — Never lock out, always degrade gracefully¶
Three levels of access, never a hard wall:
| Auth state | Access level |
|---|---|
| Authenticated | Full access — messages, circle, help requests |
| Failed auth (emergency mode) | Emergency tools only — 911, distress beacon, hotlines |
| No auth (unregistered device) | Onboarding flow and emergency contacts only |
Principle 2 — Multiple biometric modalities, user's choice¶
No single biometric works for all users in all conditions.
| Modality | Fails for |
|---|---|
| Fingerprint | Cold/wet hands, manual laborers, skin conditions, elderly users, finger injuries |
| Face ID | Face coverings, low light, facial injuries, users with facial differences |
| Voice passphrase | Laryngitis, noisy environments, speech disabilities, language barriers |
| PIN | Cognitive impairment, low numeracy, fine motor difficulties |
Policy: Users register a minimum of two modalities at onboarding. Any registered modality succeeds. The app never relies on a single method for a population this diverse.
For users who cannot reliably use any biometric, a PIN-only setup is always permitted. Security is reduced but access is preserved. A user who can get help is better served than a user who is locked out.
Principle 3 — Risk-based authentication (contextual)¶
Authentication friction should match assessed risk, not be applied uniformly.
| Context signal | Risk level | Auth required |
|---|---|---|
| Same device, same network, session within grace period | Low | No re-auth |
| Same device, new location, normal usage pattern | Medium | Biometric or PIN |
| Same device, unusual time or circle member flagged concern | Medium-high | Biometric + confirm |
| New device or relay reports new connection | High | Biometric + circle vouch |
| 3+ consecutive biometric failures | Very high | Emergency-only mode |
This mirrors the model used by major mobile OS vendors (Apple, Google) — the phone stays unlocked when risk is low and escalates only when context changes. Users in stable situations experience minimal friction; users in unusual situations face appropriate verification.
Principle 4 — Proximity trust¶
When a trusted circle member's device is within Bluetooth range, reduce auth friction. This is particularly relevant for houseless communities who travel in groups — if a trusted person is physically nearby, the risk of device theft and impersonation is lower.
Implementation: Proximity trust is a soft signal that extends the grace period, not a bypass of authentication. It cannot be used to unlock a device that is already in emergency-only mode.
Principle 5 — Session grace periods calibrated to population¶
Re-authentication frequency must account for how each population actually uses the device.
| Population | Recommended grace period | Rationale |
|---|---|---|
| MPowerUP general users | 15 minutes | Balances security and usability for active users |
| MPowerUP high-risk users (frequent distress signals) | 30 minutes | In active crisis, constant re-auth is dangerous |
| RlivN client tablet | Persistent — no re-auth during waking hours | Dementia patients cannot authenticate; device trust replaces user auth |
| RlivN caregiver portal | 2 hours | Caregiver may step away; session should not persist overnight |
Grace periods reset on successful authentication and are cleared on explicit logout or screen-off (configurable per user).
Principle 6 — Accessible recovery¶
Standard account recovery (email + link) excludes users without reliable email. See Authentication & Lockout — Recovery Paths for the full tiered recovery system.
Summary for accessibility planning:
- Circle vouch works without email, without internet beyond peer connectivity
- Recovery phrase card works completely offline
- BNI support channel is the last resort for total loss scenarios
- No recovery path requires a process a low-literacy or cognitively impaired user must navigate alone
Principle 7 — RlivN client — remove authentication entirely¶
The elderly and dementia care population cannot reliably authenticate with any modality. Forcing authentication on the client tablet creates a barrier that caregivers must constantly manage and that patients find distressing.
Design decision: The RlivN client tablet has no login screen. Authentication is handled entirely at the device level through MDM enrollment at setup. The tablet IS the authenticated identity — physical possession of the enrolled tablet means access.
This shifts the security model from software authentication to physical security: - Tablet is stored in a designated location in the home - MDM enrollment locks the device to the RlivN app (kiosk mode) - If the tablet leaves the home network, an alert is sent to the caregiver and family - All sensitive configuration and data access is gated behind the caregiver portal, which has full 2FA
Population-specific accessibility considerations¶
Houseless and poverty populations (MPowerUP)¶
| Challenge | Design response |
|---|---|
| Wet / cold / calloused hands affecting fingerprint | Multiple biometric options; PIN always available |
| No reliable internet | Offline-capable emergency features; P2P relay with local fallback |
| Device shared with others | Per-profile sessions; clear session on screen-off |
| Low digital literacy | Onboarding flow with visual + audio guidance; minimal text |
| Intermittent device access | Grace period extended if circle member has flagged user as stable |
| Language barriers | Localisation support; icon-based UI for core safety functions |
Addiction recovery populations (MPowerUP)¶
| Challenge | Design response |
|---|---|
| Cognitive impairment during relapse | Grace period prevents lockout during active crisis |
| Coercion by dealer or trafficking network | Duress PIN; distress beacon requires no text or navigation |
| Privacy from recovery community | Per-circle privacy settings; opt-in visibility |
Formerly incarcerated populations (MPowerUP)¶
| Challenge | Design response |
|---|---|
| Device seizure by law enforcement | Auto-lock on screen-off; short grace period option; relay logs not persisted |
| Circle infiltration by probation/parole system | Invitation controls; verified badge system for organisations |
| Distrust of institutional systems | BNI is a foundation, not a government or commercial entity; open source code is auditable |
Elderly and dementia populations (RlivN)¶
| Challenge | Design response |
|---|---|
| Cannot remember PINs | No client-side authentication |
| Shaky hands affecting touch | Large touch targets (64pt minimum for RlivN, exceeding WCAG 44pt); voice primary input |
| Confusion about what the device is doing | Simple, consistent UI with no modal dialogs; device always on, always the companion |
| Caregiver as threat actor | Audit log, family visibility, configuration change notifications |
| Cognitive decline over time | UI adapts to declining capability — fewer options, larger elements, slower pace |
WCAG compliance baseline¶
All BNI interfaces meet WCAG 2.1 AA as a minimum. For the target populations, the following exceed the minimum:
| Requirement | BNI standard | WCAG AA minimum |
|---|---|---|
| Touch target size | 44pt (MPowerUP), 64pt (RlivN client) | 44pt |
| Contrast ratio | 7:1 (AAA) for primary actions | 4.5:1 |
| Timeout warnings | 60 seconds before session expiry | 20 seconds |
| Error identification | Plain language, no technical jargon | Machine-readable |
| Cognitive load | Single primary action per screen on critical flows | No specific requirement |