Document user-data trust boundaries and decide the E2EE architecture

[Medformatik]

Problem

OpenMapX is adding increasingly sensitive user data: timeline connections, saved places/routes, parked location, public/private sharing, and potentially live location. “Use E2EE” is not yet an implementable requirement because server-side search, routing, sharing, recovery, self-hosting, and multi-device sync impose different trust and key-access needs.

Current state

• Service credentials and linked-account tokens have server-side encryption-at-rest paths.
• Dawarich timeline data passes through the application server.
• Mangrove review signing keys support client-side passphrase/WebAuthn wrapping, but only for that keypair use case.
• Better Auth/passkeys protect authentication; they do not provide general user-data E2EE.
• SECURITY.md exists, but there is no comprehensive user-data inventory or trust-boundary/cryptography ADR.

Proposed solution

Publish a user-data trust model and an E2EE feasibility ADR before implementing a general encryption layer. Inventory data flows and classify which fields need confidentiality from other users, operators, backups, infrastructure providers, or a compromised server. Evaluate a client key hierarchy, device enrollment, passkey-assisted wrapping, recovery, sharing, and migration against concrete product operations.

Acceptance criteria

• A data inventory covers accounts, saved content, routes, vehicles/parking, timeline, integration credentials, reviews, shares, social graph, and live location.
• For each item, document storage, processors, logs/caches/backups, retention, deletion, current encryption, and required server operations.
• Threat actors and trust boundaries distinguish hosted, self-hosted, database-only, operator, infrastructure, stolen-device, and compromised-server scenarios.
• Existing at-rest, TLS, passkey, token-vault, and Mangrove protections are described accurately without calling them E2EE.
• Candidate client key hierarchy covers devices, rotation, revocation, backup/recovery, account reset, and loss of every device.
• The ADR evaluates passkey PRF/WebAuthn wrapping portability and a non-passkey recovery path.
• A feature matrix identifies which search, sync, sharing, federation, notifications, and server processing remain possible for each encryption option.
• Metadata leakage, traffic analysis, key directory authenticity, replay, rollback, and malicious-client behavior are considered.
• Migration/versioning and cryptographic agility are specified; custom cryptographic primitives are explicitly prohibited.
• The decision records fields to encrypt now, fields to defer, and conditions for a full E2EE implementation issue.
• User-facing privacy/security documentation matches the selected trust model.
• Security review/sign-off is required before implementation begins.

Alternatives considered

Declaring all user data E2EE without a processing/recovery model would be misleading. Relying only on disk/database encryption does not address operator or application-server access.

Area

Security architecture, accounts, storage, sync, documentation.

Non-goal

This issue produces an auditable decision and bounded follow-up work; it does not implement a new cryptosystem.

[Medformatik]

Implemented on main in signed commit d5e5d40.

This publishes the accepted user-data trust model and selective E2EE architecture, documents the present data inventory and threat boundaries, and adds the operational safeguards identified during the review: durable pseudonymous erasure requests, residual identifier and browser-data cleanup, automatic log/verification/backup retention, and fail-closed restore-time erasure replay before the API restarts.

The database indexes are included in the properly named 0019_user_erasure_retention migration. Cryptographic deletion was deliberately not added for ordinary synchronized data because historical plaintext backups have no per-user key to destroy; bounded retention plus restore replay is the effective control for the current architecture.

Verification: Drizzle migration check, type checks, lint, policy gates, and the full suite (1,358 files / 14,666 tests passed). Classified as a Task because the issue is a bounded architecture/documentation decision with supporting controls, not a standalone user-facing feature.