Civic Tech Privacy Architecture

Instructions

Design privacy-preserving system architectures for civic technology products where users may face retaliation from powerful adversaries — including governments, employers, or abusive partners — for their use of the product. The threat model assumes nation-state-level adversaries with legal authority to compel data disclosure.

Threat Model

Define adversaries and their capabilities:

Adversary	Capabilities	Goal
Nation-state (domestic)	Subpoena/warrant authority, ISP cooperation, device seizure	Identify users, their activities, and associates
Nation-state (foreign)	Network surveillance, DNS poisoning, certificate forgery	Monitor dissidents, journalists, activists
Employer/institution	Device management, network monitoring, physical access	Identify employees using civic tools
Intimate partner	Physical device access, shoulder surfing, account credentials	Monitor and control partner’s civic engagement
Platform compromise	SQL injection, API exploitation, social engineering	Exfiltrate user data in bulk

Zero-PII Architecture

Design systems that cannot reveal user identity even if fully compromised:

• No PII at rest: The database, if dumped, must not contain names, emails, phone numbers, IP addresses, or any data linkable to a real identity
• Anonymous accounts: Authentication via cryptographic tokens, not email/password. Support WebAuthn/passkeys without email recovery
• Ephemeral sessions: Session tokens rotate frequently. No persistent session cookies
• No behavioral fingerprinting: Do not collect or store browser fingerprints, device IDs, or usage patterns that could re-identify anonymous users
• Aggregate-only analytics: If analytics are needed, use differential privacy techniques. Never store individual event streams

Anonymous Authentication

Implement authentication that proves authorization without revealing identity:

• Token-based registration: User generates a keypair locally. Public key registers on server. No email, no phone, no name
• Recovery via secret shares: Split a recovery key into N shares using Shamir’s Secret Sharing. User stores shares in separate locations
• Group credentials: Where applicable, use group signatures that prove “this user is a member” without revealing which member
• Deniable authentication: In contexts where users may be compelled to reveal credentials, support deniable authentication schemes where a coerced login shows a sanitized view

Log Sanitization

Prevent logs from becoming a liability:

• IP stripping: Strip source IPs at the load balancer before they reach application logs. Log only country-level geolocation if needed for abuse prevention
• Request sanitization: Remove or hash all query parameters, headers, and body content from access logs
• Timestamp coarsening: Round timestamps to 15-minute windows to prevent correlation with external surveillance data
• Retention limits: Access logs deleted after 48 hours. Application logs deleted after 7 days. No archival
• Audit log separation: If an audit log is legally required, store it in a separate system with strict access controls and document exactly what it contains

Metadata Stripping

Metadata is often more dangerous than content:

• EXIF removal: Strip all EXIF data from uploaded images before storage
• Document sanitization: Remove author names, revision history, and embedded metadata from uploaded documents
• Email header stripping: If the platform sends email, use a shared sending address with no per-user identifiers in headers
• Link decoration removal: Strip UTM parameters, click tracking IDs, and referrer data from all URLs

Network Security

• Certificate transparency monitoring: Monitor CT logs for unauthorized certificates issued for the platform’s domains
• MITM detection: Implement certificate pinning in native apps. For web, use HSTS with long max-age and preload
• Onion service: Provide a .onion address for Tor users. Do not block Tor exit nodes
• DNS-over-HTTPS: Recommend or enforce DoH/DoT for users to prevent DNS-level surveillance
• CDN considerations: Evaluate CDN providers for their response to government data requests. Prefer providers with strong transparency reports

Adversarial Testing

• Red team the architecture: Before launch, engage security researchers to attempt de-anonymization using only data the system stores
• Compelled disclosure simulation: Simulate receiving a subpoena/warrant and verify that the data you could produce does not identify individual users
• Network analysis resistance: Verify that traffic patterns do not reveal user identity (e.g., consistent packet sizes, timing obfuscation)
• Device seizure scenario: If a user’s device is seized, what can an adversary learn from local app data? Minimize this surface

Inputs Required

• Adversary threat model (which adversaries, what capabilities)
• Product type and core user journey
• Jurisdictions where users and servers operate
• Legal compliance requirements (data retention laws, lawful intercept mandates)
• Platform targets (web, native mobile, desktop)

Output Format

• Adversarial threat model document with capability matrix
• Zero-PII architecture diagram showing data flows and storage boundaries
• Anonymous authentication specification
• Log sanitization policy with retention schedule
• Metadata stripping checklist by data type
• Network security configuration guide
• Adversarial test plan with red team scenarios

Anti-Patterns

• Security theater: Implementing encryption but logging plaintext data elsewhere in the stack
• Email-based identity: Requiring email for account creation in a system designed for anonymity
• Trust the CDN: Assuming CDN/hosting providers will resist government requests without evaluating their track record
• Compliance over safety: Implementing data retention mandated by law without designing the retained data to be non-identifying
• VPN recommendation as architecture: Telling users to “use a VPN” instead of building privacy into the system architecture
• Metadata blindness: Encrypting content but ignoring metadata (timestamps, IP addresses, access patterns) that reveals just as much
• Single point of failure: Storing all privacy-critical data in one system where a single compromise exposes everything