← Back to Home Browse All Principle Deep-Dives →

Getting Started

A practical guide to adopting Protective Computing in your systems and organization.

What You're Adopting

Protective Computing is not a framework you impose. It's a discipline you practice. It asks: What changes when you design for human vulnerability instead of assuming stability?

This guide walks you through the mindset shift and gives you concrete steps to apply Protective Computing principles.

1. Understand the Core Assumption

Most software assumes infrastructure, connectivity, power, and cognitive bandwidth are abundant.

Protective Computing rejects this. It assumes:

• Networks will fail (or be hostile, or censored)
• Devices will be compromised (stolen, coerced, confiscated)
• Users will face pressure (coercion, surveillance, institutional threat)
• Time and cognitive resources are scarce (crisis, displacement, illness)
• Data is liability (minimize it; defend what remains)

Once you internalize this, the principles follow naturally.

2. Audit Your Current System

Before applying Protective Computing, understand where your system is vulnerable:

3. Apply the Principles — In Order

✓ Start with Reversibility

Make destructive actions undo-able. This is the easiest win and has broad impact.

• Implement undo / redo for user-facing changes
• Keep deletion logs; allow recovery within a reasonable window
• Design workflows so users can pause, verify, and proceed
• Avoid cascading destructive operations

✓ Add Exposure Minimization

Collect, store, and transmit only what is essential.

• Document what data you currently hold and why
• Delete data that is no longer needed
• Process sensitive data locally when possible; avoid cloud storage for non-essential details
• Encrypt data at rest; use TLS for transit
• Consider zero-knowledge architectures (user holds the key, not you)

✓ Implement Local Authority

Users should retain control even when disconnected from your infrastructure.

• Build offline-capable features where mission-critical
• Cache essential data locally on the user's device
• Allow users to use the system even if your servers are down
• Sync gracefully when connectivity returns
• Don't require authentication for every action; support local-first workflows

✓ Add Coercion Resistance

Make it hard for attackers (or authorities) to extract information forcibly.

• Support strong authentication (e.g., passphrase-based encryption)
• Implement option to wipe sensitive data remotely or via dead-man's switch
• Don't store cleartext backups of sensitive information
• Consider plausible deniability features (decoy accounts, obfuscation)
• Document security assumptions clearly; don't claim perfect security

✓ Design for Degraded-Infrastructure Functionality

The system must work when resources are scarce.

• Test on low-bandwidth connections (2G, satellite, mesh networks)
• Minimize power consumption; support low-power modes
• Design for small screens and limited RAM
• Gracefully degrade feature-rich UX when resources are constrained
• Include keyboard-only navigation; don't depend on mouse, touchscreen, or animations

✓ Prioritize Essential Utility

When resources are limited, optimize for survival tasks — not engagement or monetization.

• Identify your critical path: what does the user *need* this system to do?
• Strip away secondary features that compete for resources
• Make the critical path faster and more reliable than convenience features
• Avoid dark patterns, attention capture, or incentive misalignment

---

4. Adopt a Design Review Lens

For each new feature or system change, ask:

5. Engage with the Community

Protective Computing is a growing discipline. Share your work:

• Submit research or implementations to the Zenodo Community
• Contribute code, design docs, or case studies to the GitHub organization
• Reference the foundational Canon (DOI) in your work
• Help refine the discipline by sharing what you learn

6. Measure Impact

Success in Protective Computing means:

• Resilience: How does the system behave under stress (low power, no network, compromised device)?
• User agency: Can users understand and control their data?
• Recovery: How quickly can users undo errors or recover from incidents?
• Minimal data footprint: What's the smallest dataset you can retain and still deliver utility?

These metrics matter more than performance benchmarks or feature count.

---

Common Patterns to Avoid

• Cloud-first architecture: When all data lives on your servers, you're not practicing Protective Computing
• Mandatory internet: If the app can't run offline, it can't serve vulnerable users
• Maximal data collection: Don't collect first, ask permission later
• Single point of failure: If one server outage breaks the whole system, you've failed under degradation
• Attention capture: Dark UX patterns are hostile in crisis contexts

---

Formal Specification

This guide is practical. For formal requirements, threat model, and compliance criteria, see:

Protective Computing Specification v1.0 — Normative standard with RFC 2119 language, formal threat model, and compliance levels (Level 1–4).

Reference Implementation: PainTracker Compliance Mapping — Honest assessment of a real system's compliance against the specification. Use as a template for auditing your own implementations.

Spec Annex (for reviewers): MUST Justifications — Auditable ledger mapping each MUST to threat alignment, downgrade failure mode, and verification method.

---

Next Steps

1. Read the Canon: The Overton Framework (v1.3)
2. Review the Reference Implementation: See how PainTracker is audited against the specification
3. Audit one system: Apply the questions above to a project you own
4. Share your findings: Document what you learn and contribute to the community

---

Protective Computing — back to home