Define threat model and privacy invariants #43

Merged

lost-rob0t merged 2 commits from agent/issue-2-threat-model into main

2026-07-18 01:30:15 +00:00

lost-rob0t commented

2026-07-18 01:21:41 +00:00

(Migrated from github.com)

What changed

Added docs/threat-model.md as the authoritative v0.1 security and privacy model.
Defined protected assets, attacker profiles, explicit security limits, trust boundaries, and a Mermaid data-flow diagram.
Inventoried every planned persistent artifact and documented permitted plaintext metadata.
Defined the only approved capture/query data path and a fail-closed matrix for lifecycle, policy, redaction, encryption, storage, provider, IPC, backup, deletion, and test failures.
Added a detailed threat registry spanning lifecycle state, policy, metadata, raw data, redaction, cryptography, storage, IPC, model providers, retrieval, backups, operations, supply chain, and test integrity.
Mapped every Critical and High threat to controls, requirement IDs, planned automated verification, and owning implementation issues.
Added a verification plan for all 15 product privacy invariants.
Documented accepted residual risks, including root/kernel compromise, malicious same-UID processes, Xorg isolation limits, transient plaintext memory, redaction false negatives, and explicitly authorized remote disclosure.
Linked the threat model from README.md.

Why

Issue #2 requires a concrete security model before architecture choices are made. Local Recall handles screenshots, OCR, activity metadata, credentials, model prompts, and personal history, so generic statements such as “encrypt the database” are insufficient. This model fixes the trust boundaries and failure behavior that issue #3 must design around.

Security decisions

Missing or uncertain critical controls deny capture or persistence.
Unsupported or uncertain session types remain non-recording.
Policy parse/evaluation failure denies capture.
Redaction uncertainty rejects the complete record.
Missing or invalid keys prevent persistence; GPG is never a silent fallback.
Local-provider failure never selects a remote provider automatically.
Owner-only IPC protects against other local users but does not claim full protection from a compromised same-user session.
Xorg client isolation, privileged compromise, memory acquisition, and redaction false negatives are explicit residual risks rather than hidden claims.

Validation

Compared the branch directly against merged main from PR #42.
Confirmed the branch changes only README.md and adds docs/threat-model.md.
Confirmed the document includes the required trust-boundary and data-flow diagrams, persistent-artifact inventory, fail-closed matrix, attacker assumptions, residual risks, and invariant-to-test mapping.
Confirmed every Critical and High threat entry includes planned controls and automated verification ownership.
No production implementation was introduced. Per TDD-001 through TDD-015, executable security tests begin after the test harness is established in issue #4.

Closes #2

## What changed - Added `docs/threat-model.md` as the authoritative v0.1 security and privacy model. - Defined protected assets, attacker profiles, explicit security limits, trust boundaries, and a Mermaid data-flow diagram. - Inventoried every planned persistent artifact and documented permitted plaintext metadata. - Defined the only approved capture/query data path and a fail-closed matrix for lifecycle, policy, redaction, encryption, storage, provider, IPC, backup, deletion, and test failures. - Added a detailed threat registry spanning lifecycle state, policy, metadata, raw data, redaction, cryptography, storage, IPC, model providers, retrieval, backups, operations, supply chain, and test integrity. - Mapped every Critical and High threat to controls, requirement IDs, planned automated verification, and owning implementation issues. - Added a verification plan for all 15 product privacy invariants. - Documented accepted residual risks, including root/kernel compromise, malicious same-UID processes, Xorg isolation limits, transient plaintext memory, redaction false negatives, and explicitly authorized remote disclosure. - Linked the threat model from `README.md`. ## Why Issue #2 requires a concrete security model before architecture choices are made. Local Recall handles screenshots, OCR, activity metadata, credentials, model prompts, and personal history, so generic statements such as “encrypt the database” are insufficient. This model fixes the trust boundaries and failure behavior that issue #3 must design around. ## Security decisions - Missing or uncertain critical controls deny capture or persistence. - Unsupported or uncertain session types remain non-recording. - Policy parse/evaluation failure denies capture. - Redaction uncertainty rejects the complete record. - Missing or invalid keys prevent persistence; GPG is never a silent fallback. - Local-provider failure never selects a remote provider automatically. - Owner-only IPC protects against other local users but does not claim full protection from a compromised same-user session. - Xorg client isolation, privileged compromise, memory acquisition, and redaction false negatives are explicit residual risks rather than hidden claims. ## Validation - Compared the branch directly against merged `main` from PR #42. - Confirmed the branch changes only `README.md` and adds `docs/threat-model.md`. - Confirmed the document includes the required trust-boundary and data-flow diagrams, persistent-artifact inventory, fail-closed matrix, attacker assumptions, residual risks, and invariant-to-test mapping. - Confirmed every Critical and High threat entry includes planned controls and automated verification ownership. - No production implementation was introduced. Per `TDD-001` through `TDD-015`, executable security tests begin after the test harness is established in issue #4. Closes #2

lost-rob0t (Migrated from github.com) reviewed

2026-07-18 01:30:08 +00:00

lost-rob0t (Migrated from github.com) left a comment

Looks good, alot of covered ground in this one.