Project · Saas Lifebot

SAAS-Lifebot — Security Design

type referencestatus activelifebot · security · e2ee · gdpr

Scope

Controls for multi-user health data on a home ThinkCentre before friends sync real HAE/Hevy data. Complements SAAS-Lifebot/HLD and is verified by SAAS-Lifebot/runbooks/pre-invite-security-gate and later SAAS-Lifebot/security-review.

Threat model

Threat Control
User A reads user B ownerId on every query; no client-supplied user id for auth
Admin reads DB/backups Per-user E2EE sealed payloads; no health DEK on server
Stolen disk LUKS + ciphertext rows
Ingest key brute force High entropy keys; HMAC store; rate limit 401s
Log leakage No bodies/metric values in logs
Public Postgres Docker internal only
LLM training Paid Anthropic; aggregate summaries; prefer client call
Lost vault Recovery code once; else crypto-shred unrecoverable

Encryption

Layer Mechanism
Transit TLS (Cloudflare Tunnel) or WireGuard (Tailscale)
Disk LUKS on ThinkCentre data volume
Health at rest Seal to user public key
Merge state AES under key derived from presented ingest secret (ephemeral)
Ingest key HMAC-SHA256 with APP_SECRET pepper; raw shown once
Backups Encrypted pg_dump (age/gpg)

APP_SECRET must not decrypt health. If a design uses it as health DEK, reject.

GDPR product features

  • Consent timestamps (consentHealthAt, consentAiAt) before processing/AI.
  • Privacy page: controller (you), subprocessors (Clerk, Anthropic), encryption, rights.
  • Export / delete / key rotate; audit_events without health values.
  • Retention default documented (e.g. 730 days).

Residual risks (document to users)

  • Malicious root can instrument live ingest to capture plaintext briefly.
  • Metadata (ownerId, dates, optional metric names) visible to admin.
  • Friends trust you as infrastructure operator not to backdoor the app binary.
Compiled from wiki/projects/SAAS-Lifebot/security-design.md · git is the source of truth