Protective Computing: Designing Systems for Human Vulnerability
This article introduces Protective Computing as a systems engineering discipline focused on building software that remains safe, legible, and useful even when users are vulnerable or conditions are unstable. It argues for structural architectural properties over "privacy theater" features, emphasizing that true protection comes from the system's underlying design, not just UI elements or compliance postures. The core idea is to shift from designing for ideal stable conditions to architecting for real-world instability and human fragility.
Read original on Dev.to #architectureIntroduction to Protective Computing
Protective Computing is a systems engineering discipline that moves beyond mere compliance features to embed safety, legibility, and utility into the core architecture of software. It addresses the fundamental question: "Does this system remain legible and non-coercive when the person using it can no longer advocate for themselves?" This necessitates a shift from surface-level UI features to deep structural properties that ensure protection under conditions of instability and human vulnerability.
Key Architectural Properties of Protective Systems
- Local authority: Users retain control over their data, device state, export paths, and ability to leave the system.
- Exposure minimization: Collect, store, transmit, and render the minimum data necessary by default, not as an option.
- Reversibility: Users can recover from mistakes, panic, interruption, or incomplete actions without disproportionate harm.
- Degraded functionality resilience: Core tasks must survive degraded conditions (e.g., no internet, low battery, broken service workers).
- Coercion resistance: The system must not become a tool of surveillance, forced disclosure, or manipulation, even passively.
These are not optional features; they are architectural properties that must be true of the entire system at a structural level. The article highlights that most software operates under a "Stability Assumption," optimizing for users who are rested, online, and in safe environments, which leads to "Stability Bias" – an architectural distortion. Protective Computing aims to counteract this bias.
Distinguishing Structural Protection from Privacy Theater
The article sharply contrasts "privacy theater" (e.g., consent modals that don't change underlying data handling, export buttons that drop encryption metadata) with structural protection. Structural protection ensures that architectural decisions, defaults, failure behaviors, and recovery paths materially support claims like "offline first" or "encrypted." It emphasizes that verifiable system behavior, not rhetorical claims, generates protective legitimacy.
Architectural Examples of Protective Computing
Instead of merely claiming "we never sell your data," a structural approach ensures the app has no server-side storage of sensitive records, enforces `connect-src 'self'` via CSP, and routes all external egress through a strictly controlled, same-origin chokepoint. For "offline first," core writes succeed locally before any sync attempt, and the app does not call remote configuration endpoints on startup.
The article uses the `pain-tracker` app as a reference implementation, demonstrating how to enforce protective invariants at critical architectural chokepoints (e.g., strict origin validation for background sync to prevent data exfiltration, explicit user confirmation for backup imports to resist coercion). This approach makes claimed properties auditable, moving from statements of intent to measurable system behaviors.