PainTracker — Protective Computing Compliance Mapping
Honest assessment of PainTracker compliance against Protective Computing Specification v1.0
This is a reference implementation document. It demonstrates how to audit a real system against the specification and how to transparently report partial compliance.
Executive Summary
PainTracker is a health journaling application designed for chronic pain patients to track symptoms, treatments, and environmental triggers. It operates on patient devices (mobile, web, desktop) and optionally syncs to a server.
| Principle | Compliance Level | Status |
|---|---|---|
| Reversibility | Level 2 | ✓ Meets |
| Exposure Minimization | Level 3 | ✓ Meets |
| Local Authority | Level 3 | ✓ Meets |
| Coercion Resistance | Level 2.5 | ~ Partial |
| Degraded Functionality | Level 2 | ~ Partial |
| Essential Utility | Level 3 | ✓ Meets |
Overall Claim: PainTracker achieves Level 2–3 Protective Computing v1.0 compliance with identified gaps in Coercion Resistance and Degraded Functionality. Suitable for production health journaling; not suitable for users under active state surveillance without additional hardening.
Detailed Principle Compliance
1. Reversibility Level 2 ✓ MEETS
What PainTracker Does
- All user edits (entry deletion, tag modification, treatment notes) are reversible via 30-day trash folder
- Local undo/redo stack (Ctrl+Z/Ctrl+Y) for all destructive operations
- Complete entry history: users can view and restore prior versions of journal entries
- Server maintains soft-deleted entries for 30 days; users see "Item will be permanently deleted in X days"
Specification Requirement
Level 2: Undo/redo stack; user can reverse actions within session.
Assessment
✓ MEETS Level 2 — Local undo/redo stack present. Exceeds with 30-day recovery window (Level 2+ feature, approaching Level 3).
How to Verify
Test 1: Delete an entry. Use Ctrl+Z. Entry recovers. ✓
Test 2: Delete an entry. Search trash folder. Entry appears with "30 days remaining" timestamp. ✓
Test 3: Wait 31 days. Entry is permanently deleted. ✓
2. Exposure Minimization Level 3 ✓ MEETS
What PainTracker Does
- Data Minimization: Collects only essential fields: entry date, pain level (0–10), location, treatment, notes. No external tracking, no analytics beyond user request.
- Encryption at Rest: AES-256 GCM for all stored entries. Local database encrypted using device OS native encryption (iOS Keychain, Android Keystore).
- Encryption in Transit: TLS 1.3 for all server communication. Mutual TLS for authenticated endpoints.
- Zero-Knowledge Sync: If users enable optional cloud backup, entries are encrypted before transmission with user-held key (user passphrase derives encryption key via Argon2id). Server stores only ciphertext; PainTracker system cannot decrypt.
- Retention Policy: Local entries kept indefinitely (user control). Server backups auto-delete after 1 year unless user extends; users can manually delete anytime.
- No Data Sharing: Zero third-party access. No ads, no analytics trackers, no data sale.
Specification Requirement
Level 3: Level 2 + zero-knowledge for sensitive data; user holds encryption keys; regular key rotation.
Assessment
✓ MEETS Level 3 — Zero-knowledge backup architecture; user-held keys; AES-256 encryption.
How to Verify
Test 1: Export local database. Attempt to read without decryption key. File is unreadable binary. ✓
Test 2: Intercept server backup traffic (via proxy). Captured payload is ciphertext. Even if server is breached, plaintext is inaccessible. ✓
Test 3: Server admin attempts to query backup. Returns only encrypted blobs; no plaintext access even with admin credentials. ✓
Test 4: Verify TLS 1.3 via openssl s_client. Confirm no weak ciphersuites or downgrade attacks possible. ✓
3. Local Authority Level 3 ✓ MEETS
What PainTracker Does
- Offline-First: All core functionality works completely offline. Users create, edit, delete entries without internet. App is fully functional on airplane mode.
- Local Data Retention: Complete copy of user's journal lives on their device. No requirement to contact server for any core operation.
- Graceful Sync: Changes queue locally. When connectivity returns, sync happens asynchronously without blocking user workflow. Conflicts resolved via last-write-wins with timestamp.
- Multi-Device Sync: CRDT-style vector clocks allow conflict-free replication across user's devices (phone, tablet, laptop). Users can provision new devices without server approval.
- Optional Server: Cloud backup is optional. Users can delete account; local data remains. Even without server, all features work.
Specification Requirement
Level 3: Multi-device sync with automatic conflict resolution (CRDT or operational transforms).
Assessment
✓ MEETS Level 3 — Full offline operation, CRDT-style conflict resolution, server is optional.
How to Verify
Test 1: Disable network. Create new entry. Entry saves locally. ✓
Test 2: Edit entry on phone offline. Enable network. Edit same entry on laptop offline with different content. Enable network on laptop. Sync both devices. Conflict resolved without user intervention. ✓
Test 3: Delete server account. Local data persists. App continues to function. ✓
4. Coercion Resistance Level 2.5 ~ PARTIAL
What PainTracker Does (Level 2 ✓)
- Strong Encryption: AES-256 GCM; user-held keys (passphrase-derived).
- Passphrase-Based: User derives key from passphrase via Argon2id (128-bit work, 2GB memory). Slow enough to resist brute-force.
- No Master Keys: No administrator backdoor. PainTracker team cannot decrypt user entries even with database access.
What PainTracker Does NOT (Gaps)
- ✗ NO Plausible Deniability: No hidden volumes or decoy accounts. If coercer demands "show me your entries," user cannot deny they exist if device is unlocked.
- ✗ NO Dead Man's Switch: If user is detained for 72 hours, data is not automatically destroyed.
- ✗ Metadata Leakage: Server logs connection timestamps, entry creation/modification times, sync activity. Metadata reveals usage patterns even if entry content is encrypted.
Specification Requirement
Level 3: Level 2 + plausible deniability features (decoy accounts, hidden containers).
Level 4: Level 3 + threshold key splitting (Shamir's Secret Sharing).
Assessment
PARTIAL — Meets Level 2, approaches Level 3 on encryption, but lacks deniability features.
Honest Assessment: PainTracker is suitable for users defending against passive surveillance (metadata collection, data breaches). It is NOT suitable for users under active coercion (state interrogation, torture, forced disclosure scenarios). The spec requires Level 3 deniability for those contexts; PainTracker doesn't provide it yet.
How to Verify
Test 1 (Encryption): Derive key from passphrase using Argon2id. Verify work factor takes >1s on modern hardware. ✓
Test 2 (No Master Key): Capture encrypted backup. Demonstrate that even database admin cannot decrypt without passphrase. ✓
Test 3 (Metadata): Query server logs. Confirm that timestamps, IP addresses, and sync activity are visible. ✗ Metadata is NOT encrypted.
Test 4 (Deniability): Attempt to create hidden account with different passphrase. ✗ Feature does not exist.
5. Degraded Functionality Level 2 ~ PARTIAL
What PainTracker Does (Level 2 ✓)
- Mobile Responsive: Works on phones, tablets, desktops. Layout adapts to 320px–2560px widths.
- 2G Tested: Core path (load app, view last entry, create new entry) completes in <3s on simulated 2G (100kbps, 100ms latency).
- Low-Memory Tested: Runs on devices with 512MB RAM; tested on iPhone 6s (1GB RAM).
- No Auto-Media: Images/attachments are never auto-loaded; users explicitly request view.
What PainTracker Does NOT (Gaps)
- ⚠ Progressive Enhancement Partial: App requires JavaScript to function. Plaintext HTML fallback exists but is minimal (login form only). Full journal browsing requires JS.
- ⚠ Keyboard Navigation Incomplete: Tab navigation works for core forms. Some UI elements (date picker, chart) require mouse/touch.
- ✗ WCAG AA Not Yet Achieved: Color contrast ratios are 4.5:1 on text (meets WCAG), but chart legends fail (3.5:1). Screen reader support is partial (main content okay, interactive elements need work).
Specification Requirement
Level 3: Progressive enhancement (HTML baseline works without JS); keyboard-only navigation; WCAG AA compliance.
Assessment
PARTIAL — Meets Level 2 (mobile responsive, 2G tested, low-memory). Does not meet Level 3 (missing progressive enhancement, incomplete keyboard accessibility, WCAG AA gap).
Honest Assessment: PainTracker works well on modern smartphones and tablets. It does NOT work for users on extremely slow networks (satellite, 2G) or users without JavaScript support (which is increasingly rare but not zero). It also has accessibility gaps for users relying on screen readers.
How to Verify
Test 1 (2G Performance): Simulate 2G throttling. Measure load time. <3s for core path. ✓
Test 2 (Low Memory): Deploy on iPhone 6s. No out-of-memory crashes. App remains responsive. ✓
Test 3 (Disable JavaScript): Browser developer console → disable JS. Welcome page loads. Login form works. Full journal browsing: ✗ Does not work without JS.
Test 4 (Keyboard Navigation): Tab through form fields. Use only keyboard to create entry. ⚠ Works for text fields; date picker requires mouse.
Test 5 (Screen Reader): Use NVDA/JAWS on charts and date pickers. ✗ ARIA labels incomplete; users cannot access date picker with screen reader.
6. Essential Utility Level 3 ✓ MEETS
What PainTracker Does
- Documented Essential Use Case: "Chronic pain patients track symptoms, treatments, and triggers offline. System enables pattern identification and medical communication without requiring connectivity or data sharing."
- No Dark Patterns: No notifications (none sent). No streaks or gamification. Features are straightforward: create entry, view entries, export data.
- Minimal Cognitive Load: Main screen shows single action: "New Entry." One tap → simple form (date, pain level 1–10, location, treatment, notes). No confusing menus.
- No Addictive Mechanics: No leaderboards, no achievement badges, no notifications to pull users back. Success metric is user's pain reduction, not app engagement.
- Transparent Funding: Open-source with grant funding (NIH, foundation). No data harvesting, no premium upsell of core features.
- Success Measured by User Outcome: Tracked via: user pain reduction, treatment efficacy discovery, doctor-recommended use. NOT by DAU or time-in-app.
Specification Requirement
Level 3: Level 2 + independent audit for dark patterns; user satisfaction metrics.
Assessment
✓ MEETS Level 3 — No dark patterns, transparent funding, success measured by user outcome, not engagement.
How to Verify
Test 1 (Dark Patterns Audit): Manual inspection of UI/UX. No hidden friction to exit, no manipulative notifications, no surprise paywalls. ✓
Test 2 (Funding Transparency): Check website, GitHub, and legal docs. Confirm grant funding; zero data sales. ✓
Test 3 (User Satisfaction): Survey users: "Does this app help you track pain?" (target: >80% yes). ✓
Threat Model Alignment
Protective Computing specification baseline threat model covers: state surveillance, authoritarian coercion, censorship, device seizure, network tampering.
Threats PainTracker Resists
Threats PainTracker Does NOT Resist
Degradation Scenarios
System behavior under resource/threat stress:
Scenario 1: Network Outage (1 week)
✓ Full Functionality: Users create, edit, delete entries locally. App is 100% functional. Sync queues changes locally. On reconnnection, sync completes.
Verification: Manually test offline for 7 days. Confirm entries persist, undo/redo works, no crash.
Scenario 2: Device Running Out of Storage (500MB remaining)
⚠ Degraded: User can still view/edit existing entries. Creating new entries with large attachments may fail. App shows warning "Low storage; consider deleting old entries or uploading to cloud."
Verification: Simulate low storage via test environment. Confirm app degrades gracefully without crash.
Scenario 3: User on 2G Network (100kbps, 500ms latency)
✓ Functional: Sync is slow but completes. User creates entries, saves locally, and sync happens in background. No blocking.
Verification: Network throttle test. Measure sync time: should be <10s for typical entry even on 2G.
Scenario 4: User Under State Surveillance (IP logging, account freeze)
✓ Encrypted Data: If server is seized, entry plaintext is safe. ⚠ But Metadata Exposed: Timestamps, connection patterns, IP addresses are visible to state actor.
Risk: State can determine usage patterns (when did user access app?) but not content of entries.
Mitigation: Use VPN / Tor for metadata privacy (outside PainTracker's scope; user responsibility).
Honest Gaps & Limitations
Gap 1: Coercion Resistance (Missing Deniability)
Issue: No hidden accounts or plausible deniability. Under torture, user cannot deny entries exist if device is unlocked.
Why It Matters: Dissident users, abuse survivors in hostile custody situations, and people in high-surveillance authoritarian contexts need this.
Roadmap: Level 3 deniability (hidden volumes) planned for v1.2 (Q4 2026). Requires significant UX work and security review.
Gap 2: Accessibility (WCAG AA Incomplete)
Issue: Date picker and charts are not keyboard-navigable. Color contrast ratios on charts are 3.5:1 (needs 4.5:1 for WCAG AA).
Why It Matters: Users with visual disabilities or motor disabilities (relying on keyboard/switch control) cannot access full functionality.
Roadmap: WCAG AA compliance (Degraded Functionality Level 3) planned for v1.1 (Q2 2026).
Gap 3: Progressive Enhancement
Issue: Core app requires JavaScript. Plaintext HTML fallback exists but is minimal.
Why It Matters: Users in environments where JS is blocked (very restrictive corporate networks, some educational institutions) cannot use web version. Mobile/desktop apps work fine.
Roadmap: Progressive enhancement (Degraded Functionality Level 3) is lower priority; mobile/desktop clients provide alternative. Expected v1.2 or v2.0.
Gap 4: Metadata Privacy
Issue: Server logs access timestamps, sync activity, IP addresses. These are NOT encrypted and could reveal usage patterns even if entry content is private.
Why It Matters: State actors can determine when user is accessing sensitive health information without knowing content. For some users, even "pattern of use" is dangerous.
Mitigation: User should employ VPN/Tor for connection-level privacy. PainTracker can encrypt metadata in v1.2 onward.
Roadmap: Encrypted metadata (Coercion Resistance improvement) planned for v1.2.
Gap 5: No Offline Backup Verification
Issue: Users can export data to CSV, but no built-in way to verify backup integrity (checksums, signed exports).
Why It Matters: Users who want to keep offline backups have no way to confirm the backup hasn't been tampered with.
Roadmap: Signed exports (Local Authority improvement) planned for v1.1.
Who Should Use PainTracker
✓ Appropriate For
- Chronic pain patients in stable democracies with strong privacy law (US, EU, Canada, Australia)
- Patients wanting to avoid medical data mining by insurance companies
- Patients with privacy concerns about cloud health apps
- Users wanting offline-first health journaling
⚠ Use With Caution
- Users in countries with weak privacy law or active surveillance (Russia, China, Iran) — PainTracker provides encryption but lacks deniability features
- Users with accessibility needs (visual/motor disability) — gaps in keyboard navigation and WCAG compliance
- Users with extremely slow connectivity (satellite, 2G only) — tested but not optimized for extreme scarcity
✗ Not Appropriate For
- Users under active state torture/coercion (PainTracker lacks deniability features for this threat)
- Users needing complete anonymity (metadata is not encrypted)
- Users in environments where JavaScript is completely blocked
How This Compliance Mapping Was Verified
This document is not self-certification. It is an honest assessment designed to be independently verifiable.
Verification Methodology
- Specification Review: Each claim is mapped to specific RFC 2119 language in Protective Computing Specification v1.0
- Code Inspection: Cryptography implementation reviewed against NIST recommendations; key derivation verified against OWASP guidelines
- Functional Testing: Each checkpoint is reproducible; tests can be run by independent auditors
- Network Analysis: TLS configuration verified via
testssl.sh; no weak ciphersuites - Accessibility Audit: WCAG 2.1 compliance checked via Axe DevTools; gaps documented
- Threat Modeling: Alignment with baseline threat model explicitly assessed; out-of-scope threats identified
Audit Artifacts
- Code repository: github.com/paintracker/paintracker (open-source for transparency)
- Cryptography audit report: [Link to third-party security review, if available]
- WCAG audit checklist: [Detailed checklist available on request]
- Test execution logs: Available in `/test/audit-logs/` directory of repository
Next Steps
For PainTracker Team
- Address Gap 1 (Coercion Resistance deniability) for Level 3 compliance → v1.2 (Q4 2026)
- Address Gap 2 (WCAG AA accessibility) for Degraded Functionality Level 3 → v1.1 (Q2 2026)
- Encrypt server metadata (access logs, timestamps) → v1.2
- Pursue independent security audit for Level 3 certification
For Independent Auditors
- Review this compliance mapping
- Run verification tests from checkpoints above
- Develop additional test cases (fuzzing, adversarial input)
- Issue audit report: confirm, refute, or refine claims
For Other Implementations
Use this template to document your own system's Protective Computing compliance. Be honest about gaps. Transparency builds credibility more than perfection claims do.