Threat Model

Threat Model

SECURITY.md is the formal threat-model document. This page provides the longer-form discussion: who could be attacking, what they would be after, and what Clio's design does about it.

Scope of this page

This page covers the confidentiality and integrity threats to Clio: adversaries trying to exfiltrate or corrupt the user's data. These threats fit the conventional "attacker against defender" frame and benefit from the conventional STRIDE-style analysis below.

The third leg of the CIA triad — availability, or denial of access — has its own page: Availability and Denial of Access. It is separated because the threat-actor profile is structurally different: the denial-of-access actor is most often the legitimate custodian of the data (the LLM provider acting on policy), not an adversary, and the defense is user-side retention rather than attacker-side prevention. Reading both pages gives the full picture.

Who is in scope (this page: C and I threats)

The realistic threats to Clio's confidentiality and integrity posture, in roughly increasing severity:

1. A future contributor introducing a side channel

This is the most likely vector. Someone adds a "send error reports for debugging" feature, or a "sync to a self-hosted server" option, and the strict-local property silently weakens.

Mitigation: The manifest does not declare permissions that would allow this. Any contributor would need to add a host permission or a broader permission to enable transmission, and that diff is conspicuous in code review. CONTRIBUTING.md calls this out as a load-bearing design principle.

2. A typo-squatted clone

Someone publishes an extension named "Clio" or "Cleo" on the Chrome Web Store with a worse permission posture (or active malice). Users install the wrong one.

Mitigation: Clio is published under a single, documented developer account. README and PRIVACY both link to the canonical store URL. There is nothing Clio itself can do about a determined typo-squatter; this is a Chrome Web Store moderation problem.

3. A hostile DOM on a supported site

A compromised conversation thread (cross-site scripting embedded in a message, for example) could trick Clio into extracting attacker-controlled HTML as if it were a conversation. The extracted JSON would be wrong.

Mitigation: Clio does not execute the page's JavaScript — its content scripts run in Chrome's isolated world. The risk is to the accuracy of the extracted JSON (an integrity issue), not to the user's broader system. The user can read the extracted JSON and notice if something is off.

4. A malicious update pushed through a compromised developer account

If the author's CWS publishing account were compromised, an attacker could push a malicious version of Clio to existing users. This would be silent and high-blast-radius.

Mitigation: This is a CWS supply-chain risk that Clio cannot fully mitigate from within the extension. The minimal-permission posture caps the blast radius — a hostile Clio still cannot read cookies, webRequest, <all_urls>, etc., because those permissions were never granted. Chrome would prompt to re-approve any added permission, which would be visible to the user.

Who is out of scope (on this page)

These threat classes are explicitly not within Clio's confidentiality/integrity defense posture (also stated in SECURITY.md):

• A compromised host browser — if Chrome itself is owned, the extension is owned
• Network observers — Clio operates on already-rendered conversations; transit-layer attacks against the LLM provider are not in scope
• Provider-side attacks — Google's, Anthropic's, and OpenAI's security postures are theirs to maintain; Clio reads the rendered output

For availability threats (provider deletes the user's account, conversation removed post-hoc, provider goes out of business, network outage), see Availability and Denial of Access — those are not on this page because the threat-actor profile and the appropriate defense are different.

What this implies for development

The most leveraged review is on extensions/manifest.json. A change to that file is a privacy/security change first and a feature change second. PR descriptions for manifest changes should justify the permission delta explicitly.

Related

• Privacy Architecture — the structural defenses for Confidentiality
• Provenance and Auditability — the Integrity counterpart
• Availability and Denial of Access — the Availability counterpart (separate threat-actor profile)
• Defense in Depth — concrete manifest walkthrough
• SECURITY.md — the formal document