Security & Safety¶
BNI builds software for populations whose physical safety depends on the security of their tools — people experiencing houselessness, domestic violence, addiction recovery, incarceration, and cognitive decline. Security is not a feature layer added after launch; it is a foundational design constraint.
This page covers the org-wide security philosophy and the cross-cutting accessibility-security framework. Product-specific security specs — the threat model, authentication and lockout design, and circle-initiated revocation — are MPowerUP-specific and live under that project: see MPowerUP (migrating).
Design principles¶
Never lock out — always degrade gracefully. Full authentication gives full access. Partial or failed authentication gives reduced but still useful access. No authentication gives emergency-only access. A user should never be blocked from getting help.
Device security serves the user, not the platform. Authentication protects the user from others accessing their data. It must not become a barrier between the user and safety.
The attacker is often known to the victim. For this user base, the most likely attacker is an intimate partner, family member, trafficker, or institution — not a remote hacker. The threat model reflects this.
Privacy and security are inseparable. Metadata is as dangerous as content. Knowing who is in someone's circle, when they send messages, and where they are can endanger them even if message content is encrypted.
Legal exposure is a security issue. Law enforcement access, subpoenas, and mandated reporting obligations are part of the threat model, not separate from it.
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"]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. For users who cannot reliably use any biometric, a PIN-only setup is always permitted — security is reduced but access is preserved.
Principle 3 — Risk-based authentication (contextual)¶
Authentication friction should match assessed risk, not be applied uniformly — from no re-auth (same device, same network, within grace period) up to emergency-only mode (3+ consecutive biometric failures). This mirrors the model used by major mobile OS vendors: the device stays unlocked when risk is low and escalates only when context changes.
Principle 4 — Proximity trust¶
When a trusted circle member's device is within Bluetooth range, reduce auth friction — particularly relevant for houseless communities who travel in groups. Proximity trust is a soft signal that extends the grace period, not a bypass; it cannot unlock a device already in emergency-only mode.
Principle 5 — Session grace periods calibrated to population¶
| Population | Recommended grace period | Rationale |
|---|---|---|
| MPowerUP general users | 15 minutes | Balances security and usability |
| MPowerUP high-risk users | 30 minutes | In active crisis, constant re-auth is dangerous |
| RlivN client tablet | Persistent (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 |
Principle 6 — Accessible recovery¶
Standard account recovery (email + link) excludes users without reliable email. Recovery paths: circle vouch (works without email), recovery phrase card (works fully offline), and a BNI support channel as last resort. 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. Design decision: the RlivN client tablet has no login screen — authentication is handled at the device level through MDM enrollment at setup (kiosk mode). The tablet is the authenticated identity; physical possession means access. If the tablet leaves the home network, an alert goes to the caregiver and family. All sensitive configuration 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 with visual + audio guidance; minimal text |
| Language barriers | Localisation; 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 | 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); voice primary input |
| Confusion about what the device is doing | Simple, consistent UI with no modal dialogs; device always on |
| Caregiver as threat actor | Audit log, family visibility, configuration change notifications |
| Cognitive decline over time | UI adapts — 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 |
The external security frameworks BNI references (OWASP, NIST) are catalogued in Software Engineering Policies.