Privacy Hardening Action Plan — opened 2026-05-11

Master tracker: #523 — Privacy & Security Hardening — Master Tracker. One issue, one PR. This doc is the canonical status surface; the issue is the canonical reference point.

Working doc. Captures the May 2026 privacy audit findings AND tracks the open work driven by them. Updated as items ship and as new findings surface.

Origin: This started as a point-in-time audit at docs/audit/AUDIT_2026-05-11.md and got reframed as a working action plan on 2026-05-14 — the dashboard table made it the canonical tracker for follow-up engineering, counsel, and sprint work. Audit findings (§2–§5, §9) stay frozen below; ongoing tracking lives in the dashboard at the top.

Author: privacy workstream Last updated: 2026-05-14 Companion docs: docs/privacy/PRIVACY_HARDENING_ROADMAP.md (living strategic roadmap — sprint-level), docs/privacy/SEALED_IDENTITY.md (brief)

Action items at a glance

Single-table summary of every open action item surfaced by this audit. Detail in the section linked in the See column. Status conventions: 🟦 open · 🟡 in progress · 🟢 done · ⏸ blocked.

Phase legend

Phases are sequencing groups, not deadlines. P1 should land before P2 (so cleanup work doesn't regress). P2 and P3 can overlap. P4 (counsel) runs in parallel throughout. P5 covers pre-launch hardening and post-launch ongoing.

Phase	Theme	Rough timing	Effort estimate
P1	Foundation — CI defense + roadmap accuracy. Lock in regression protection BEFORE cleanup so future PRs can't reintroduce the patterns.	This week	~2 days
P2	Cleanup — mechanical fixes, no design decisions blocking. Batchable into one or two PRs.	This / next week	~2–3 days
P3	Design-dependent — items that need a product/UX/architectural decision before code can ship.	1–2 weeks (incl. design conversation)	varies
P4	Counsel track — privacy policy, ToS, sub-processor enumeration, DPIA prep. Runs parallel to engineering, doesn't block.	Ongoing	counsel time
P5	Pre-launch & beyond — pen test, type-safety hardening, architectural sprints, ongoing defense, future audits.	Pre-launch onward	varies

Engineering (code changes)

Phase	Priority	Status	Item	Effort	See
P3	CRITICAL	🟢	Non-biometric IndexedDB device-key exposure. When a user skips biometric enrollment, the AES device key is stored plaintext in IndexedDB next to the wrapped entropy. Local malware / forensic access on the device can decrypt all "encrypted" profile data. Server-side guarantee intact; device-side claim conditional on biometrics. Mitigation: strongly encourage biometric enrollment + warning UI for non-biometric users + (long-term) derive device key from PIN. ✅ 0d3140d8 (on unmerged claude/privacy-hardening chain, pending roll-up PR to dev)	~1 day, design needed	§10.1
P3	HIGH	🟢	Encrypt chat messages client-side (Olm/Megolm). messageService.sendMessage() writes plaintext to Firestore today. Design landed 2026-05-26, re-baselined 2026-05-30 in docs/privacy/CHAT_ENCRYPTION.md: Double Ratchet (Olm) for 1:1, Megolm foundation for bonfires, via the audited @matrix-org/matrix-sdk-crypto-wasm (pivoted off the GPL libsignal TS port). PIN-encrypted backup + recovery phrase; server-driven session rotation for bans; leave existing plaintext to TTL-expire. ✅ Phases 1–3 + 5 (e28f7481, a6b4958e, fc4f9de5, 26dd29af, 1445b42c, 236a3339); Phase 4 (bonfire group sessions) deferred (on unmerged claude/privacy-hardening chain, pending roll-up PR to dev)	~1.5–2 weeks (Phases 1–3 + 5)	CHAT_ENCRYPTION.md
P2	HIGH	🟢	Strip auth headers from pinoHttp logs across all API services (auth, analytics, merchants, venues). Default serializer logs Authorization: Bearer <token>. ✅ c4cb1273 — PINO_REDACT_CONFIG across all 8 API services (pending roll-up PR to dev)	~30 min	§9.1
P2	HIGH	🟢	Encrypt email at email-passphrase signup (apps/web/src/lib/auth.js:126, 140). Call the existing emailEncryption library or /auth/email/encrypt endpoint. ✅ c4cb1273 (pending roll-up PR to dev)	~30 min	§9.4
P2	HIGH	🟢	Replace targetEmail with targetUserId in adminActions audit log writes across merchantHandlers.js + adminUsers.js. ✅ c4cb1273 (pending roll-up PR to dev)	~1 hr	§9.4
P2	HIGH	🟢	Add metadata: { vibe, interests } to lantern_lit tracking to unlock venue-scoped mood/interest analytics. ✅ e0abe788 (pending roll-up PR to dev)	~10 min	§3 + §6
P3	HIGH	🟢	Add lantern-form privacy disclosure near submit button: "visible to nearby users for 48h + aggregated for venue analytics." ✅ 6a5027b1 (LightLanternForm.jsx, pending roll-up PR to dev)	~30 min	§4 + §6
P3	MEDIUM	🟢	Profile settings copy clarification — distinguish encrypted-at-rest from plaintext-when-lit; add tooltip near mood. ✅ 6a5027b1 (ProfileSettings.jsx, pending roll-up PR to dev)	~30 min	§4 + §6
P2	MEDIUM	🟢	Bin radius_km (<5km, 5-25km, 25km+) and hash city in venue_searched events. ✅ Radius binning c4cb1273 (merged via #544); city hashing done — venue_searched now logs a peppered HMAC city_hash (venues/utility.js hashCity), fail-closed to omit when CITY_HASH_PEPPER unset so the readable name never lands. Activating the groupable hash needs the CITY_HASH_PEPPER secret provisioned for venues-api.	~20 min	§3 + §6
P2	MEDIUM	🟢	Hash phone in phoneReclaims collection (currently plaintext via phoneRecycling.js:113). ✅ c4cb1273 (pending roll-up PR to dev)	~30 min	§9.4
P5	MEDIUM	🟢	Protect adminProfiles.phone and merchantProfiles.phone at rest. ✅ ENCRYPTED (reversible AES-256-GCM, reusing EMAIL_ENCRYPTION_KEY), not hashed — these are contact numbers the admin UI displays/edits, so they must round-trip; one-way hashing (the original wording) would break display. Merchant: encrypted at all server writers + decrypted in getMerchantDetail. Admin: phone read/write moved server-side (/auth/admin/profile/phone, encrypt + peppered phoneHash); the deprecated phoneAdmin check-admin now matches by phoneHash (indexed) with a decrypt-scan fallback for un-migrated rows; client rules forbid client-side phone/phoneHash writes. Follow-ups: backfill existing admin/merchant phones (re-save migrates them); the users.phoneHash-style hash here is parallel, not a replacement.	~half day each	§9.4
P2	HIGH	🟢	adminInvites plaintext email + phone — hash or delete-on-redemption. 7-day invite window currently exposes admin invitees' PII. ✅ e0abe788 (pending roll-up PR to dev)	~1 hr	§10.3
P3	HIGH	🟢	Anthropic admin assistant PII redaction. Design landed 2026-05-26 in docs/privacy/ADMIN_ASSISTANT_REDACTION.md: two-layer model (client block-and-warn + server request-layer sanitizer). Scrubs phone/email/JWT/card; UIDs explicitly preserved as recommended identifier. ✅ 9a57866b (pending roll-up PR to dev)	~half day	ADMIN_ASSISTANT_REDACTION.md
P2	MEDIUM	🟢	Extend Sprint D.1 cascade to frens, featureRequests (non-anonymous), offers.createdBy. Currently a deleted user's userId orphans in these collections. ✅ e0abe788 (pending roll-up PR to dev)	~half day total	§10.3
P1	MEDIUM	🟢	Correct PRIVACY_HARDENING_ROADMAP.md §2 / §3 threat-model rows to reflect reality (chat msgs plaintext; legacy phone surfaces). ✅ §3 chat row corrected in this commit (chat now E2EE, not plaintext)	~10 min	§9.5
P2	LOW	🟢	Sanitization sweep on app_crash / action_failed error message logging to belt-and-suspenders against PII bleed via thrown errors. ✅ e0abe788 (pending roll-up PR to dev)	~20 min	§3 + §6
P5	LOW	🟦	Audit-verify k-anonymity ≥ 3 enforcement on every merchant-surfaced metric. Constant exists; confirm enforcement on every report path.	~1 hr	§6

Counsel / product (non-engineering)

All P4 — runs in parallel to engineering, doesn't block code work.

Phase	Priority	Status	Item	Owner	See
P4	HIGH	🟡	ProfileSettings.jsx references a non-existent "our privacy policy." ✅ Decision (2026-06-01): keep the line but add an explicit in-code NOTE/TODO flagging the missing policy (so it's not silently shipped as if one exists) — the retention list is the de-facto disclosure until then. Still need to write the policy (below) and link it.	Product + counsel	§5 + §6
P4	HIGH	🟦	Write a public privacy policy. Use PRIVACY_HARDENING_ROADMAP.md §2 + §3 as source of truth (corrected per §9.5 first). Required for GDPR Art. 12–14, CCPA notice-at-collection, app-store nutrition labels.	Counsel	§5 + §6
P4	HIGH	🟦	Write Terms of Service. Same compliance bucket.	Counsel	§6
P4	HIGH	🟦	Enumerate sub-processors in the privacy policy when written: Resend (email), Anthropic (admin assistant), GitHub (feature requests), Discord (internal monitoring), Cloudflare/Railway (admin billing). Resend + Anthropic require GDPR Data Processing Addendums (DPAs).	Counsel	§10.2
P4	MEDIUM	🟦	Subpoena response playbook — per-request-shape doc of what we can/cannot produce.	Counsel	§6
P4	MEDIUM	🟦	DPIA prep if EU market entry is on the roadmap. Sealed identity helps the DPIA; document the model.	Counsel	§6

Architectural (future sprint work)

All P5 — pre-launch hardening or post-launch sprint work.

Phase	Priority	Status	Item	Source
P5	HIGH	🟦	Sprint E — Stage B (seal phoneHash → userId resolution with encryptedUserIdBlob). Multi-PR architectural commitment.	Roadmap §4
P5	MEDIUM	🟦	Sprint D.3 — admin panel UI + user self-delete flow wiring up the existing deleteUserCompletely callable.	Roadmap §4
P5	LOW	🟦	Differential privacy on aggregate queries (combined-query inference defense). Future Phase 3+ item.	Roadmap §6

Continuous defense (recurring infrastructure)

Phase	Priority	Status	Item	Effort	See
P1	HIGH	🟢	Gitleaks in CI — block PRs that introduce secrets. Fast, low-false-positive. Single highest-leverage move. ✅ 53f21a4a (pending roll-up PR to dev)	~30 min	§11.2
P1	HIGH	🟢	Semgrep with 10 custom rules drawn from this audit (users-plaintext-pii, adminActions-targetemail, console-log-user, messages-plaintext, lantern-coord-untruncated, etc.). Encodes dashboard findings as CI gates. ✅ 53f21a4a (pending roll-up PR to dev)	~1 day	§11.2
P1	HIGH	🟢	CODEOWNERS for privacy-critical paths — require privacy review on auth.js, services/api/auth/, userDeletion.js, flash.js, sanitize.js. ✅ 53f21a4a (pending roll-up PR to dev)	~30 min	§11.2
P1	MEDIUM	🟢	PR template with privacy checklist — three questions about new Firestore fields / log calls / event metadata. ✅ 53f21a4a (pending roll-up PR to dev)	~30 min	§11.2
P2	HIGH	🟦	Cloud DLP scheduled scan — daily inspection job against Firestore + BigQuery. Alerts on unexpected PII patterns. Mechanical setup once; runs forever after.	~half day	§11.3
P5	MEDIUM	🟦	TruffleHog weekly scheduled deep scan with --only-verified flag. Complements Gitleaks; catches what regex misses.	~30 min	§11.2
P5	MEDIUM	🟦	Type-safe encrypted-field wrappers — branded EncryptedField<T> type so wrong-type writes fail to compile. Architectural defense.	~half sprint	§11.1
P5	MEDIUM	🟦	safeWriteUser() helper — allowlist-based write helper for users/{uid}. Forces opt-IN for any new field.	~half day	§11.1
P5	LOW	🟦	Canary data — synthetic test user with known fingerprint; periodically grep BigQuery + Cloud Logging for leaks.	~half day	§11.3
P5	HIGH	🟦	Pre-launch pen test scoped to privacy claims (Trail of Bits / Cure53 / NCC Group / Bishop Fox).	$15–30k, ~2 weeks lead	§11.4
P5	MEDIUM	🟦	Bug bounty post-launch with explicit privacy tier (HackerOne / Bugcrowd).	$5k starter + payouts	§11.4
P5	MEDIUM	🟦	Quarterly internal privacy audit — re-run BQ verification commands in §8, grep audits, compare to baseline. New findings get dated supplemental sections.	~half day / quarter	§11.4

Supplemental audit — 2026-06-01 (post-#544 follow-up)

New findings from a follow-up audit after the #544 roll-up merged, focused on the newer service / Firestore-rules / chat-E2EE surface area (most of the original baseline is now 🟢). Verified items are noted. Tracked here per the maintenance discipline below.

Phase	Priority	Status	Item	Effort	Notes
P1	HIGH	🟢	Scheduler/cleanup endpoints authenticated on a spoofable header. /analytics/scheduled (publicly reachable via the /api/analytics/* worker proxy) + /lanterns/cleanup treated presence of X-CloudScheduler-JobName as auth — an unauthenticated caller could trigger BQ aggregation, user-id pseudonymization, and TTL deletion. ✅ FIXED: new requireSchedulerOrAdmin guard accepts a constant-time SCHEDULER_SECRET bearer (Cloud Scheduler) OR a verified admin token; the spoofable header path is gone. Secure on deploy — with no secret set, only the admin path works (scheduler pauses, never falls back). Infra to activate: set SCHEDULER_SECRET on analytics-api + lanterns-api and configure the Cloud Scheduler jobs to send Authorization: Bearer <secret>.	done (code); ~30 min infra	§11
P1	HIGH	🟡	connections rules integrity. Any user can create a connections doc pairing themselves with an arbitrary victim uid (no accepted-wave check) → unsolicited message-thread injection; and either party can mutate user1Id/user2Id on update (no pin). Fix: require an accepted wave (or server-create) + pin participant ids on update.	~half day	§9.5
P1	HIGH	🟡	Duplicate waves rules blocks with conflicting schemas (fromUserId/toUserId vs senderUserId/recipientUserId); rules OR them, so the looser block bypasses the stricter create validation. Fix: consolidate to one canonical block.	~30 min	§9.5
P1	HIGH	🟡	Retire dead Cloud Functions writing plaintext PII. Legacy modules/adminUsers.js + modules/merchantUsers.js CFs (superseded by Cloud Run, no client calls them) still write plaintext phone + email. Retire like the phoneRecycling CF.	~30 min	§9.4
P2	HIGH	🟡	App Check enforced only on auth-api. ✅ Gated verifyAppCheck added to analytics/venues/lanterns/merchants, before verifyFirebaseToken on user-facing routes (health/openapi/public-event-schemas/scheduler excluded). MONITOR by default (logs missing/invalid, allows through); flip per-service to ENFORCE via APP_CHECK_ENFORCE=true after confirming clients send valid tokens. Bypassed outside production. To finish: watch the appcheck_missing/appcheck_invalid logs per service, then set APP_CHECK_ENFORCE=true.	done (code, monitor); enforce = config	§11
P2	MEDIUM	🟦	claim-otk not scoped to connected peers — any authed user can drain anyone's one-time-key pool / enumerate the device directory. Add a connection check in the claim handler.	~1 hr	§9.5
P2	MEDIUM	🟦	Plaintext-fallback chat messages not surfaced to recipients or monitored. encryptionFailed rides only the sender's return value; a systemic encrypt outage writes plaintext at scale silently (no alert, normal 30-day TTL). Propagate the flag to recipients + add monitoring; consider a shorter TTL for fallback plaintext.	~half day	§9.1
P2	MEDIUM	🟦	merchantPasswordResetTokens.email plaintext, never deleted (no TTL) — persists indefinitely. Encrypt + add TTL / delete-on-use.	~1 hr	§9.4
P2	MEDIUM	🟦	users.email written plaintext on admin/merchant create — inconsistent with the encryptedEmail model elsewhere. Switch these creates to encryptedEmail.	~1 hr	§9.4
P2	MEDIUM	🟢	merchants-api has no rate limiter — offer/audience enumeration & scraping. ✅ Added a per-user limiter (shared USER_RATE_LIMITS.offers_browse = 60/min) on GET /offers/active (the lat/lng-grid scrape vector); 429 over-limit. Business-data/cost concern, not user-PII.	done	§11
P1	MEDIUM	🟡	No HSTS header on web + admin. Add Strict-Transport-Security to _headers (also backstops the privacy-correct Referrer-Policy).	~10 min	§11
P5	HIGH	🟦	No device verification / safety numbers (chat). No cross-signing → an active key-substitution MITM by a compromised server/admin is not prevented; the threat-model table overstates insider protection. Add a §2 row + plan cross-signing / safety-number UX.	~half sprint	§11
P3	MEDIUM	🟦	Retire the deprecated check-admin enumeration oracle (phone→admin yes/no) once admins are on invite links; remove the PhonePinSignup call.	~1 hr	§10.3
P5	LOW	🟡	Chat E2EE nits. ✅ toDevice create rule now has a field allowlist + type checks (no arbitrary fields); ✅ restoreFromBackup rejects an unrecognized version; ✅ PIN-change-doesn't-rekey-backup caveat documented (CHAT_ENCRYPTION.md §8). Remaining: bind the backup canary to the bundle (AAD) — deferred, deeper change.	done (3/4)	§9.5
P5	LOW	🟦	CSP hardening: scripts allow unsafe-inline/unsafe-eval (both apps); admin loads Sveltia CMS from unpkg.com (pin/SRI or self-host). Plus optional COOP/COEP.	~half day	§11
P3	LOW	🟢	frens contact-injection — a saver could broadcast their lantern to an arbitrary uid with no prior interaction. ✅ Decision (2026-06-01): require a prior connection. Rule now requires the fren to reference a real connections doc whose participants are exactly {saver, saved} (frens are saved from the chat screen, which passes connection.id).	done	§10.3

Maintenance discipline

When closing an item, change 🟦 → 🟢 and add a link to the PR / commit that closed it in the Item column (or as a footnote). Don't delete rows — historical completion is useful context. New findings get added to the relevant section (§6 or §9.4) AND mirrored here.

1. Why this doc exists

Three roles in one doc:

1. Audit baseline (§2–§5 + §9): point-in-time findings from the May 2026 three-layer privacy audit (architecture / analytics integration / UI copy / privacy-policy gap) plus the supplemental Cloud Logging + Firestore PII audit added 2026-05-14. These sections are frozen — don't rewrite history; future audits get their own dated doc that compares against this baseline.
2. Action tracker (dashboard at the top): single-table summary of every open task surfaced by the audit, with status, effort, and back-link to the detail section. This is the part that gets updated as work ships — mark items 🟢 with a PR link when closed.
3. Operating manual (§7, §10): how to keep the doc honest as the work progresses.

Companion to docs/privacy/PRIVACY_HARDENING_ROADMAP.md (the strategic, sprint-level living roadmap). This plan is more tactical — individual fixes and gaps, not whole sprints.

2. Layer 1 — architectural privacy posture (STRONG)

10 PRs merged 2026-05-10 → 2026-05-11. Summary state:

Surface	Posture
users.phone plaintext	✅ Removed on new signups (Stage A phase 4). Migration script ready for existing rows (Sprint C operator step).
users.phoneHash	✅ HMAC-SHA-256 + KMS pepper (Stage A phases 1–3).
users.encryptedSeed / encryptedBirthDate / encryptionCanary	✅ AES-GCM ciphertext, key derived from user's PIN. Server cannot decrypt.
users.encryptedMood / encryptedInterests	✅ AES-GCM (Sprint A). Server cannot decrypt.
lanterns.lat/lng	✅ Truncated to ~111m precision (Sprint A).
banned_accounts	✅ Hashes only, server-only Firestore rule.
lanterns/* retention	✅ 48h via scheduled Cloud Function (Sprint B.1).
waves/* retention	✅ 7d via scheduled Cloud Function (Sprint B.1).
connections/* + messages	✅ 30d via scheduled Cloud Function, sub-collection cascade (Sprint B.1).
BigQuery raw events	✅ 90-day partition expiration enforced by BigQuery itself.
BigQuery aggregated event_counts_daily	✅ No user_id, no per-user breakdown. Indefinite retention is safe.
GDPR cascade deletion	✅ deleteUserCompletely callable + BQ pseudonymization-on-deletion (Sprint D.1 + D.2).

Outstanding architectural items:

• 🟦 Sprint D.3 — UI integration: callable exists, but no admin panel button or user-self-delete flow yet.
• 🟦 Sprint E — Stage B: phoneHash → userId resolution is still server-resolvable. The brief calls for sealing this with encryptedUserIdBlob. Multi-PR architectural commitment (~8–10 days).
• 🟦 Firebase Auth phone-number residual: Firebase Auth itself maintains phoneNumber on user records (used for SMS verification). Stage B closes the Firestore phoneHash → userId path but not auth.getUserByPhoneNumber(X). Structural to using Firebase Auth's phone provider. Document as residual.

3. Layer 2 — analytics integration (CLEAN with two nits)

Verified against the actual code + actual BigQuery contents on lantern-app-dev.

What works

• Dual-layer metadata sanitizer (packages/forge/sanitize.js:12-38, apps/web/src/lib/flash.js:112-127): client and server both strip email, phone, name, address, ssn, token, session. Strings truncated to 500 chars. Nested objects flattened.
• BigQuery partition expiration: verified 7776000 seconds (90 days) in tooling/scripts/setup-bigquery.sh:89 and confirmed live in BQ (expirationMs = 7776000000).
• Aggregated table has zero PII: tooling/schemas/bigquery-event-counts-daily.json — only (day, event_name, event_tier, environment, count, aggregated_at).
• user_id is server-derived: pulled from verified Firebase ID token (services/api/analytics/src/routes/tracking.js:61). Client cannot inject it.
• Mood/interest events are user-elected publication only: every interest_added and mood_adjusted event in BQ has source: lantern_form. Zero events from profile-settings updates. Profile mood/interest stays encrypted in Firestore; the lantern form is the explicit consent surface.

Gaps worth flagging

1. lantern_lit metadata is null today. Verified across 120 events. Mood/interest exist on the lantern Firestore doc (profileVibe, profileInterests) but aren't denormalized into the event for venue-scoped analytics. Implication: merchant analytics cannot slice "moods at venue X" from BQ today. Trivial fix (~10 min client-side tracking change) — see open items §5.
2. venue_searched includes city + radius_km (packages/shared/analytics/index.js). Not a per-user-precise leak, but in low-density cities + small radius this narrows location. Worth binning radius (<5km, 5-25km, 25km+) or hashing the city if rare-locale users matter.
3. app_crash / action_failed log truncated error messages and stack traces (apps/web/src/lib/flash.js:582-599). Unlikely to leak PII if upstream error handling is clean, but worth a one-time sanitization sweep.

Side-effect surfaces

• Cloud Logging (Pino HTTP middleware) logs request headers/method/path/status. No event metadata in URL paths. Error handler should not log req.body or req.user — quick check warranted.
• BigQuery write-failure logs in packages/forge/bigquery.js:76-84: log eventName, eventId, eventTier only on failure. No metadata, no user_id. Clean.

4. Layer 3 — user-facing UI copy (INCOMPLETE)

The architecture is honest; the UI is silent on the key transitions. Users can't reasonably understand the consent model from the existing copy alone.

Signup (apps/web/src/screens/auth/PhonePinSignup.jsx)

• ✅ Lines 713–717 disclose: "Your birth date and phone number are encrypted on your device. We only verify you're 18+ for venue access."
• ✅ Lines 825–829 disclose the PIN-derived encryption key model.
• ✅ Lines 939–960: "Lantern servers only receive encrypted data (gibberish without your PIN)."
• ❌ No warning that lighting a lantern will publish mood + interests in plaintext for 48h + aggregate for venue analytics. The phrase "all your data" misleads.

Lantern lighting form (apps/web/src/screens/... — LightLanternForm.jsx)

• ⚠️ Line 148: "People nearby will see your interest, but your identity remains hidden until you meet." — technically true, structurally incomplete.
• ❌ No disclosure that mood goes plaintext for 48h.
• ❌ No disclosure that mood + interests + free-text are aggregated for venue analytics.
• ❌ No tooltip / info icon / fine print near mood, interests, or the free-text quote field.

Profile mood/interest settings (apps/web/src/screens/profile/ProfileSettings.jsx)

• ⚠️ Line 566: "Interests — top interests show on your lantern card." Correct for interests, but no equivalent disclosure for mood.
• ⚠️ Lines 690–697: "Privacy Guarantees" box mentions encryption of sensitive data. Doesn't distinguish "encrypted at rest" from "plaintext when lit."
• ❌ The Preview UI (lines 483–489) does not clarify whether what's previewed is the encrypted profile state or what'll get published.
• ❌ ProfileSettings.jsx also references "our privacy policy" but no policy document exists — see §5.

Honesty scorecard

Flow	Privacy-critical copy present?	Architecturally honest?	Top gap
Signup	✅ Yes	Partially	No mention of lantern-lighting publication
Lantern form	Minimal	Partially	Mood becomes plaintext; not disclosed
Profile settings	Partial	Partially	No "encrypted at rest vs. plaintext when lit" distinction

5. Layer 4 — privacy policy / ToS (DOES NOT EXIST)

This is the biggest gap and the one with real legal exposure.

What exists today

• ⚠️ apps/web/src/screens/profile/ProfileSettings.jsx references "our privacy policy" in user-facing copy. No such document exists, public or internal.
• ✅ Internal architectural docs: this roadmap, SEALED_IDENTITY.md, HOW_ENCRYPTION_WORKS.md, PRIVACY_PRESERVING_ADVERTISING.md, LOG_HYGIENE.md. These are engineering-facing, not user-facing.
• ⚠️ docs/business/legal/LEGAL_COMPLIANCE.md lines 269–274 flag the privacy policy as required. Box is unchecked.
• ⚠️ docs/TODO.md tracks: "Create privacy policy aligned with zero-knowledge encryption" and "Create terms of service." Not started.

Risks

• Over-claiming: ProfileSettings UI references "our privacy policy" and claims TTL retention (48h/7d/30d) for check-ins/waves/chats. Sprint B.1 only just shipped — until operators verify the scheduled Cloud Functions are deployed and running on dev, this is an aspirational claim in user-facing copy.
• Under-claiming: nothing in any user-facing copy mentions the actual privacy strengths — phone hashing, profile encryption, 90-day BQ retention, cascade deletion on Art. 17 requests. Significant marketing + legal-defense loss.
• Compliance: no privacy policy = no GDPR Art. 12–14 disclosure, no CCPA notice-at-collection, no Apple/Google app-store privacy nutrition label backing.

6. Open items / next batch of work

Ordered by leverage × urgency.

Code (engineering)

Priority	Item	Effort	Why
HIGH	Add metadata: { vibe, interests } to lantern_lit event tracking	~10 min	Unlocks venue-scoped mood/interest analytics. Trivial code change.
HIGH	Add lantern-form privacy disclosure ("visible to nearby users for 48h + aggregated for venue analytics") near the submit button	~30 min	Closes the biggest UI honesty gap. Cheap.
MEDIUM	Add "this is your private profile mood — published only when you light a lantern" copy in ProfileSettings	~30 min	Closes the encrypted-at-rest vs. plaintext-when-lit ambiguity.
MEDIUM	Bin radius_km and consider hashing city in venue_searched events	~20 min	Closes the low-density-locale fingerprint.
LOW	Sanitization sweep on app_crash / action_failed error message logging	~20 min	Belt-and-suspenders against accidental PII bleed via thrown errors.
LOW	Audit-verify k-anonymity ≥ 3 enforcement on every merchant-surfaced metric	~1 hr	The constant exists but should be confirmed on every report path.

Counsel / product (non-engineering)

Priority	Item	Owner	Why
HIGH	Remove the "our privacy policy" reference from ProfileSettings until a policy exists, OR write a minimal interim policy. Current state is a liability.	Product + counsel	Hard claim with no backing document.
HIGH	Write a public privacy policy. Use PRIVACY_HARDENING_ROADMAP.md §2 + §3 as source of truth.	Counsel	GDPR Art. 12–14, CCPA notice-at-collection, app-store compliance.
HIGH	Write a Terms of Service.	Counsel	Same compliance bucket.
MEDIUM	Subpoena response playbook (roadmap §5)	Counsel	Per-request-shape doc of what we can/cannot produce.
MEDIUM	DPIA prep if EU market entry is on the roadmap	Counsel	Sealed identity helps the DPIA; document the model.

Architectural (future engineering sprints)

Priority	Item	Source
HIGH	Sprint E — Stage B (seal userId resolution)	Roadmap §4
MEDIUM	Sprint D.3 — admin / self-delete UI integration	Roadmap §4
LOW	Differential privacy on aggregate queries (combined-query inference defense)	Roadmap §6

7. Recommended sequencing

1. Now (this week): Remove the "our privacy policy" UI reference (or stub the policy to an honest "we don't yet have a written policy; here's our engineering doc" link). Add the lantern-form disclosure. Close the over-claim gap.
2. Within the month: Write the privacy policy + ToS. Use this audit + the roadmap as source material for counsel.
3. Pre-launch: Sprint D.3 UI integration; verified k-anonymity ≥ 3 enforcement. Audit-verify the operator runbooks (Sprint C migration, Cloud Scheduler job for B.2).
4. Stage B (Sprint E): Scope and start when there's capacity.

8. Verification commands (for future audits)

Keep these handy — they're how the BQ side of this audit was verified.

# Confirm 90-day partition expiration on raw events
bq show --format=prettyjson lantern-app-dev:analytics.events | jq '.timePartitioning'

# Confirm aggregated table has no PII columns
bq show --schema --format=prettyjson lantern-app-dev:analytics.event_counts_daily | jq -r '.[].name'

# Distribution of user_id lengths (raw UID ≈ 28; pseudonymized = 64 hex)
bq query --use_legacy_sql=false "SELECT LENGTH(user_id) AS len, COUNT(*) AS n FROM \`lantern-app-dev.analytics.events\` WHERE user_id IS NOT NULL GROUP BY len ORDER BY len"

# What metadata gets logged with lantern lighting and mood/interest
bq query --use_legacy_sql=false "SELECT event_name, TO_JSON_STRING(metadata) AS meta FROM \`lantern-app-dev.analytics.events\` WHERE event_name IN ('lantern_lit','mood_adjusted','interest_added') ORDER BY timestamp DESC LIMIT 10"

# Verify no other dataset has user_id columns
for ds in analytics billing_attrib billing_marts billing_norm billing_raw ops logs; do
  bq ls --max_results=50 lantern-app-dev:$ds 2>/dev/null | tail -n +3 | awk '{print $1}' | while read t; do
    [ -z "$t" ] && continue
    bq show --schema --format=prettyjson "lantern-app-dev:$ds.$t" 2>/dev/null \
      | jq -r '.[].name' 2>/dev/null \
      | grep -qiE "^(user_id|userid|uid)$" && echo "⚠ $ds.$t has user_id"
  done
done

9. Supplemental — Cloud Logging + Firestore PII audit (2026-05-14)

Follow-up to §3 (analytics integration) and §4 (UI copy), specifically asked: could GCP logs or Firestore accidentally pick up PII beyond what we've accounted for?

Two parallel sub-audits run. Findings below — some material, surfaced here rather than buried in the open-items section because they affect the privacy claim accuracy.

9.1 Cloud Logging — one medium-severity exposure

• MEDIUM: pinoHttp is mounted without a custom request serializer in services/api/auth/src/index.js:63, services/api/merchants/src/index.js:22, and the other API services. Default pino-std-serializers includes req.headers in the logged request object, which means Authorization: Bearer <Firebase ID token> and any custom auth headers go to Cloud Logging on every request. Not strictly PII, but token capture is a security concern bordering on PII bleed. Fix: add a serializers.req to each pinoHttp config that excludes headers and body:

  pinoHttp({
    logger,
    serializers: {
      req: (req) => ({ method: req.method, url: req.url }),
    },
  })

• Otherwise: clean. Sprint A's lazy migration in apps/web/src/lib/profileService.js logs only userId (and devLog suppresses in production). Sprint C's drop-plaintext-phone.mjs only logs row counts and skip reasons. Cloud Functions logger calls in phoneRecycling.js, adminUsers.js, etc. all log opaque UIDs only post-#479. Error handlers log err.message/err.stack, not req.body.

9.2 Firestore — six findings, four contradicting the §2 threat-model claims

The §2 table claims certain things are encrypted that are not. Listed by severity:

1. HIGH — connections/{cid}/messages/* are written PLAINTEXT. apps/web/src/lib/messageService.js:46–60 sendMessage() writes { senderId, senderName: 'You', text: text.trim(), timestamp, status } to Firestore via addDoc with zero encryption call. The roadmap's §3 threat-model row "chats.* message bodies | encrypted client-side | No" is inaccurate. This is the single biggest privacy gap in the codebase right now — every message a user has ever sent is sitting plaintext in Firestore, bounded only by the 30-day TTL Sprint B.1 just added.

2. HIGH — Email-passphrase signup path writes plaintext email to users/{uid}.email (apps/web/src/lib/auth.js:126, 140). An emailEncryption.js library exists at services/api/auth/src/lib/, and the /auth/email/encrypt endpoint is correctly called by PhonePinSignup post-creation, but the legacy email-passphrase signup flow bypasses it. Affects admin/merchant accounts that signed up via this path.

3. HIGH — adminActions.targetEmail plaintext. Multiple write sites in services/api/auth/src/handlers/merchantHandlers.js:493 and services/api/auth/src/routes/adminUsers.js:151, 261, 425, 640 write targetEmail as plaintext in the audit log. LOG_HYGIENE.md prescribes userId-only references in audit rows; these violate it. Tracked separately in #308 but worth flagging here.

4. HIGH — merchantPasswordResetTokens.email plaintext (services/api/auth/src/handlers/merchantHandlers.js:462). userId alone would be sufficient; storing the email plaintext duplicates an identifier that's already encrypted elsewhere.

5. MEDIUM — phoneReclaims.phoneNumber plaintext (services/functions/firebase/modules/phoneRecycling.js:113). Inconsistent with Sprint C's hashing strategy. Should write phoneHashOldOwner only.

6. MEDIUM — adminProfiles.phone and merchantProfiles.phone plaintext — not enumerated in the §2 threat model at all. Separate collections from users. Phone is stored plaintext because of merchant/admin lookup-by-phone flows that were never migrated to hashed lookups.

9.3 Implications for the privacy claim

The strongest defensible privacy claim from §2 should be revised to remove the "chats encrypted" assertion until it's actually true. Today the accurate claim is:

"User profile fields (mood, interests, birth date, recovery seed) are encrypted with keys derived from each user's PIN — Lantern cannot decrypt. Chat messages, audit logs, and reset tokens contain plaintext content; chat messages are bounded by a 30-day TTL, audit logs by Cloud Logging retention (30d), reset tokens by their own short expiry. Phone numbers are hashed in users/ but remain plaintext in adminProfiles, merchantProfiles, and phoneReclaims — three legacy surfaces that need follow-up."

9.4 New open items (added to §6 implicitly)

Priority	Item	Effort
HIGH	Encrypt chat messages client-side via Olm/Megolm (Double Ratchet for 1:1, Megolm for bonfires) through the audited @matrix-org/matrix-sdk-crypto-wasm. Full design in docs/privacy/CHAT_ENCRYPTION.md — schema, flows, phasing, library choice (pivoted off GPL libsignal). Bonfire foundation + server-driven rotation baked in from v1.	~1.5–2 weeks (Phases 1–3 + 5), design landed
HIGH	Strip auth headers from pinoHttp logs across all API services	~30 min
HIGH	Encrypt email at auth.js email-passphrase signup path (call the existing emailEncryption library or /auth/email/encrypt)	~30 min
HIGH	Replace targetEmail in adminActions with targetUserId only across the merchantHandlers + adminUsers write sites	~1 hr
MEDIUM	Hash phone in phoneReclaims collection	~30 min
MEDIUM	Migrate adminProfiles.phone and merchantProfiles.phone to hashed (same KMS pepper as users.phoneHash)	~half day each
MEDIUM	Correct the §2 / §3 threat-model rows in PRIVACY_HARDENING_ROADMAP.md to match reality	~10 min

9.5 What this means for the architecture

The privacy architecture for profile data is solid — that's what Sprint A shipped and verified. The privacy architecture for chat content, audit logs, and legacy admin/merchant surfaces has known gaps that the roadmap previously claimed were closed. Worth a corrective sprint before any marketing or counsel-facing privacy claim references the roadmap.

10. Supplemental pass 2 — outbound services, client storage, remaining Firestore, GCP surfaces (2026-05-14)

Four parallel sub-audits run on 2026-05-14 to sweep surfaces the original audit didn't fully cover. One critical finding on the device side, three high-severity findings on outbound services or new collections, several medium-severity gaps in the cascade-deletion coverage.

10.1 Client-side storage — one CRITICAL device-side finding

• CRITICAL — Non-biometric path stores the device key plaintext in IndexedDB. apps/web/src/lib/keyCache.js:139-141. When a user signs up WITHOUT enrolling biometrics, the AES-256 device key used to wrap their entropy is exported as raw bytes and stored in IndexedDB alongside the wrapped entropy. A process with local IndexedDB read access (malware, browser extension, forensic access to a stolen device, shared-device co-user) can read both, decrypt the entropy, derive the encryption key, and read all the user's "encrypted" profile data. The server-side privacy guarantee remains intact — Lantern still cannot decrypt anything. But the user-facing claim "even on your device, your data is encrypted" is conditional on biometric enrollment.

  This is documented in the code as a "convenience vs. security" tradeoff. Mitigations:

  • Strongly encourage biometric enrollment during signup (currently optional Step 4 per Phase 4 plan).
  • On non-biometric devices, surface a clear warning: "Without biometric protection, your data is recoverable on this device if compromised."
  • Long-term: derive the device key from a user-provided second factor (PIN) rather than storing it.

• Otherwise client-side is clean:

  • localStorage: feature flags + pseudonymous IDs only. No phone, email, mood, interests.
  • sessionStorage: 30-minute biometric entropy cache (keyCache.js:276). Standard practice; cleared on tab close.
  • URL hash routing: pseudonymous IDs and server-opaque tokens only. No ?email= or ?phone= patterns.
  • Cookies: none custom; Firebase Auth uses server-side session cookies.
  • window.* globals: gated to import.meta.env.DEV. Production-safe utilities like window.lanternForceRefresh only.
  • React component state: auth-flow PII cleared after submission. No "stale PII" lingering.
  • devLog: properly suppressed in production via isDevelopment check (apps/web/src/lib/devLog.js).

10.2 Outbound third-party services — three HIGH-severity, all undocumented in any privacy policy (which doesn't exist)

Severity	Service	Data sent	Surface
HIGH	Resend (email transactional)	Recipient email, display name, subject context, recovery backup encrypted blob (opaque to Resend)	services/api/auth/src/lib/email.js, services/api/auth/src/routes/email.js:45–100 — admin invites, merchant invites, password resets, recovery delivery
HIGH	Anthropic Claude API (admin assistant)	Admin-typed messages with no automated redaction; conversation history; tool-call outputs (which can include user data the admin queried)	services/api/assistant/src/services/anthropic.js; admin-only surface gated by verifyFirebaseToken + requireAdmin
HIGH	GitHub API	userId (Firebase UID), user-typed feature request title/description/use-case, collaborator email	services/functions/firebase/modules/featureRequests.js:140–200, githubAccess.js
MEDIUM	Discord webhook (internal monitoring)	userId or "Anonymous", feature request body, environment	featureRequests.js:218–290
LOW	Cloudflare API, Railway API (admin billing)	Account/workspace IDs only — no user PII	billing.js, billingShared.js

Clean (verified absent): Twilio (Firebase Auth handles SMS natively), Sentry, Datadog, Loggly, Mixpanel, Amplitude, PostHog, OpenAI in prod, any non-admin LLM calls, any webhook outbound besides Discord.

Implication: When the privacy policy is written, it needs to enumerate Resend, Anthropic, GitHub, Discord, Cloudflare, Railway as sub-processors. Resend and Anthropic specifically require Data Processing Addendums (DPAs) under GDPR.

10.3 Remaining Firestore collections — three new gaps

Severity	Collection	Finding	File
HIGH	adminInvites	Stores admin email + phone plaintext for the 7-day invite window. Not covered by Sprint D.1 cascade deletion.	services/api/auth/src/routes/adminInvite.js:61–69
MEDIUM	frens	userId pairs (saverId, savedId) persist after user deletion. Sprint D.1 cascade does not clean this. Relationship graph orphans.	services/functions/firebase/modules/frens.js:65–68
MEDIUM	featureRequests	submittedBy = userId orphans on user deletion (when not flagged anonymous). Not in cascade.	services/functions/firebase/modules/featureRequests.js:161–178
MEDIUM	offers	createdBy = userId orphans on user deletion. Not in cascade. (Admin/merchant content, but still a userId trail.)	services/api/merchants/src/routes/offers.js:134

Clean (verified safe):

• userInvites — token only, no PII, 7-day TTL.
• appConfig — system config only.
• merchants (top-level) — venueIds array; PII lives in merchantProfiles (already flagged in §9.2).

10.4 GCP infrastructure — clean

No new findings. Cloud Storage rules explicitly deny users/{userId}/* paths; only avatars/{userId}/* is used and is covered by Sprint D.1 cascade. Cloud Tasks / Pub/Sub / custom Cloud Scheduler payloads not used. Secret Manager holds operational secrets only. CI/CD workflows don't echo user data. Firebase Hosting cache headers are standard. Cloud Run access logs are structural to GCP and outside our seal (already noted as residual in §6).

10.5 New action items (mirrored into the dashboard at the top)

Added to the dashboard:

• CRITICAL — biometric-or-warning UX on signup for the IndexedDB key exposure (~1 day, design needed)
• HIGH — adminInvites hash phone + email, or delete-on-redemption (~1 hr)
• HIGH — Resend / Anthropic / GitHub / Discord sub-processors enumerated in the privacy policy when written (counsel)
• HIGH — Anthropic admin assistant PII redaction policy (~half day) — design landed: docs/privacy/ADMIN_ASSISTANT_REDACTION.md
• MEDIUM — Extend Sprint D.1 cascade to frens, featureRequests (where not anonymous), offers.createdBy (~half day total)

11. Continuous privacy defense — keep the posture from decaying

The audit findings above are point-in-time. Without ongoing defense, six months from now someone adds a feature that quietly leaks data and the architectural guarantee evaporates. Four layers of defense, each cheap on its own and strong in aggregate.

11.1 Architectural — make leaks structurally hard

Already in place (extend, don't replace):

• Dual-layer metadata sanitizer in packages/forge/sanitize.js and apps/web/src/lib/flash.js. Forbidden-key list strips email, phone, name, etc. before BQ write. Every new sensitive field name should be added to this list.
• Firestore security rules in firestore.rules. Already locks down banned_accounts/* server-only. Extend the same allow read: if false pattern to any new sensitive collection.

Worth adding:

• Type-safe encrypted-field wrappers. Define a branded type EncryptedField<T> (TypeScript or zod). Any function writing to users/{uid} takes a typed payload requiring encryptedMood: EncryptedField<string> etc. The wrong-type write fails to compile. ~Half a sprint to implement; pays dividends forever.
• safeWriteUser() helper that takes only an allowlist of fields. Trying to pass email fails. Forces every contributor to opt INTO writing a new field rather than out of forgetting one.

11.2 CI / PR gates — catch leaks before merge

Highest-leverage layer. Code-review humans miss things; CI doesn't.

Tool	Role	Setup effort	Cost
Semgrep with custom rules	Pattern linter that fails PRs on known-leak patterns	~1 day to write 10 rules from this audit	OSS
Gitleaks in CI	Block PRs that introduce secrets	~30 min	OSS
TruffleHog weekly scheduled	Deep scan with verification (only-verified mode) — catches what gitleaks misses	~30 min	OSS
CODEOWNERS for privacy paths	Require privacy-team review on changes to apps/web/src/lib/auth.js, services/api/auth/, services/functions/firebase/modules/userDeletion.js, etc.	~30 min	Free
PR template with privacy checklist	"Did you add a Firestore field / log call / event metadata? If yes, is it encrypted/hashed/explicitly safe?"	~30 min	Free
Pre-commit hooks (gitleaks-pre-commit)	Local-machine grep before commit — defense in depth, bypass-able	~15 min	Free

Custom Semgrep rules I'd bootstrap with, drawn directly from this audit's findings:

# 1. Block plaintext phone/email writes to users collection
- id: lantern-users-plaintext-pii
  pattern-either:
    - pattern: setDoc(doc(db, 'users', $UID), { ..., email: $X, ... })
    - pattern: setDoc(doc(db, 'users', $UID), { ..., phone: $X, ... })
  message: "Writing plaintext phone/email to users/{uid}. Use encryptedEmail/phoneHash."
  severity: ERROR

# 2. Block plaintext PII in adminActions writes
- id: lantern-adminactions-targetemail
  pattern: db.collection('adminActions').add({ ..., targetEmail: $X, ... })
  message: "adminActions audit rows should reference targetUserId only, never targetEmail."
  severity: ERROR

# 3. Block console.log on user-derived data outside devLog
- id: lantern-console-log-user
  pattern: console.$METHOD($X.email, ...)
  paths:
    exclude: ["**/*.test.*", "**/devLog.js"]
  severity: WARNING

# 4. Block message writes without encryption wrapper
- id: lantern-messages-plaintext
  pattern: addDoc($MESSAGES_REF, { ..., text: $X, ... })
  message: "Chat message text must be encrypted before write. Use encryptMessageText()."
  severity: ERROR

# 5. Block lantern doc writes without coord truncation
- id: lantern-lantern-coord-untruncated
  pattern-either:
    - pattern: addDoc($LANTERNS_REF, { ..., lat: $LAT, lng: $LNG, ... })
    - pattern: |
        $DOC = { ..., lat: $LAT, lng: $LNG, ... }
        ...
        await addDoc($LANTERNS_REF, $DOC)
  pattern-not-inside: |
    truncateCoord(...)
  message: "Lantern coords must be truncated via truncateCoord() before write."
  severity: ERROR

Plus the analogous rules for phoneReclaims, adminInvites, merchantPasswordResetTokens, and the pinoHttp request-header redaction. ~10 rules total; one-time write.

11.3 Runtime — observe what actually lands

Static checks catch known patterns. Runtime checks catch what slips through.

• Cloud DLP (Data Loss Prevention) API — GCP-native. Schedule a daily inspection job against Firestore + BigQuery. Looks for unexpected PII patterns (phone numbers, email addresses, SSNs, etc.). Alerts on findings to a Slack channel or Cloud Monitoring alert. Strongest single ongoing-defense move. ~half day to set up, free-ish (charged per scan, but Lantern's volume is small).
• Canary data — Create a synthetic test user (canary-{YYYY-MM-DD}@lantern.local) with a known fingerprint. Periodically grep BigQuery, Cloud Logging, and any exports for that fingerprint. If it shows up where it shouldn't, you have a leak. Optional but effective for paranoid systems.
• Extend the dual-layer sanitizer — every new sensitive field name added to forbidden-keys list. Already in place; just keep it current.

11.4 External — assume internal eyes miss things

When	What	Cost
Pre-launch (one-time)	Pen test firm scoped specifically to privacy. Trail of Bits, Cure53, NCC Group, Bishop Fox. ~1 week focused engagement on "find PII anywhere it shouldn't be."	$15–30k
Pre-launch (one-time)	Privacy-specific SAST — Privado.ai (privacy-focused) or TerraTrue (privacy lifecycle management). Cheaper alternative to a full pen test.	$$$
Post-launch (ongoing)	Bug bounty with explicit privacy tier (pay 2–5x normal rates for privacy bugs). HackerOne or Bugcrowd handle logistics.	$5k starter pool + payouts
Quarterly (internal)	Recurring privacy audit — this doc is the template. Re-run the BQ verification commands in §8, the file-grep audits, compare against the baseline. New findings get a dated supplemental section.	Internal time, ~half day per quarter

11.5 What NOT to do

• Don't rely on developer discipline alone. "Everyone knows not to write email: data.email to Firestore" is exactly how the chat-message-plaintext bug shipped.
• Don't ingest user data into a privacy-watching SaaS. A service that watches your data IS your data. Stick to pre-deploy CI checks and infrastructure-level scans (Cloud DLP runs inside your project).
• Don't buy a privacy-management SaaS at $$$$ pricing until you've outgrown the free tools. Semgrep + Cloud DLP + Gitleaks + a quarterly audit gets you 80% of value at <10% of cost.

11.6 Recommended bootstrap order

If starting from zero today:

1. Gitleaks in CI (~30 min) — blocks accidental secret commits at PR time. Highest leverage single move.
2. Semgrep with 10 custom rules drawn from this audit (~1 day) — encodes the dashboard findings as CI gates so future regressions get blocked.
3. CODEOWNERS for privacy-critical paths (~30 min) — apps/web/src/lib/auth.js, services/api/auth/, services/functions/firebase/modules/userDeletion.js, etc.
4. PR template with privacy checklist (~30 min) — three questions, mostly cultural.
5. Cloud DLP scheduled scan (~half day) — daily runtime check across Firestore + BQ.
6. TruffleHog weekly cron (~30 min) — deep scan complement to gitleaks.
7. Pre-launch pen test (~2 weeks lead, $15–30k) — schedule when feature-complete on dev.
8. Bug bounty + quarterly audit cadence (post-launch).

Steps 1–4 are < 2 days total and close most of the practical "regression risk" surface. Steps 5–6 add the runtime layer. Steps 7–8 are the external assurance layer.

12. How to use this doc

• Refer to the dashboard at the top when picking up the next piece of privacy work.
• Close items in the dashboard by changing 🟦 → 🟢 and adding the closing PR link inline in the row. Don't delete rows — historical context is useful for the next audit.
• New findings between audits get added to the dashboard AND mirrored to the appropriate detail section (§6 or §9). Date the addition.
• For a full new audit (e.g., post-Stage-B or post-launch), create a new dated doc in docs/audit/ that compares findings against this plan as the baseline. Don't rewrite this one.
• Sections §2–§5, §9 are frozen as the audit baseline. If something changes architecturally (Sprint E lands, etc.), reflect that in PRIVACY_HARDENING_ROADMAP.md, not by rewriting history here.