From 33ac2f336d45cfcc0fad639d5da56d93c5b5a2bb Mon Sep 17 00:00:00 2001 From: null Date: Wed, 15 Jul 2026 02:53:52 -0500 Subject: [PATCH] docs(future): mark security items #1-#3 built (deploy-gated) with commit refs Co-Authored-By: Claude Opus 4.8 --- Future.md | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/Future.md b/Future.md index de327348..69b11974 100644 --- a/Future.md +++ b/Future.md @@ -23,14 +23,23 @@ Non-blocking ideas: things that work today but could be better, plus feature ide defeats the on-screen identity check does NOT defeat this). Needs mail infra (SendGrid / a Firebase Auth action) — deferred for that reason. R24-b shipped the on-screen identity + confirm + owner self-alert as the pragmatic interim. -- **Restore-request lifecycle cleanup.** A `restore_requests` doc left at `READY` (partner wrapped the key but the - recipient never completed) leaves an ECIES `keybox` — ciphertext sealed only to the recipient, useless to - anyone else, but untidy. Add a **scheduled cleanup** of expired requests (and their keyboxes). R24-b already - enforces expiry at fulfil time and deletes any stale request before a re-request. -- **Owner-alert precision.** The R24-b "was this you?" self-alert also reaches the *requesting* device (harmless). - Optionally exclude it via a client-written token hint on the request (would add a rules-allowed field). -- **Couple-key rotation / forward secrecy.** A couple-key compromise exposes all history incl. backups (no FS - today). Add rotation (both devices re-key) — hard but the right long-term hardening. +- **Restore-request lifecycle cleanup — BUILT 2026-07-15 (commit `8496bbed`), deploy-gated.** Hourly + `cleanupExpiredRestoreRequests` (collectionGroup on `expiresAt`, catches orphans under deleted couples; + delete-first then a quiet expiry nudge to the requester through the house pipeline). Awaiting: + `firebase deploy --only firestore:indexes` + `--only functions:cleanupExpiredRestoreRequests`, then live verify. +- **Owner-alert precision — BUILT 2026-07-15 (commit `2dd09d5d`), deploy-gated.** Requesting device embeds its + FCM token (create-only optional field, best-effort); both self-alerts skip that one device, partner push + untouched. Awaiting: `firebase deploy --only firestore:rules` + + `--only functions:onRestoreRequested,functions:onRestoreFulfilled`, then live verify. +- **Couple-key rotation / forward secrecy — PHASE 1 BUILT 2026-07-15 (commit `2c44cc6f`), deploy-gated; PHASE 2 + PLANNED (own checkpoint).** Phase 1 = rotate-forward: new Tink key primary + old retained (history readable, + zero wire/`isCiphertext` changes), same-phrase re-wrap + strictly-increasing `keyGeneration` on the couple doc, + partner adopts automatically on Home load, 🔑 alert via `onCoupleKeyRotated`, Settings → Security row. + Fail-closed path VERIFIED LIVE pre-deploy (PERMISSION_DENIED → "nothing changed", app healthy). Protects + FUTURE content only. Awaiting: rules + `--only functions:onCoupleKeyRotated` deploys, then 2-device happy-path + verify (throwaway couple first). Phase 2 (forward secrecy for history) = per-family idempotent re-encrypt + sweeps + backup re-snapshot under the new key + both-devices K1-destruction handshake — plan in + `/home/kaspa/.claude/plans/i-want-you-to-recursive-clover.md`, NOT started (pre-execution review checkpoint). - **Server-independent anti-rollback freshness.** A malicious server could serve a stale manifest to hide recent messages; today mitigated by the `generation` counter + a Phase-1 Firestore cross-check. Add a signed/monotonic freshness signal for the Option-B world.