Defense in Depth

Defense in Depth

This page is a walkthrough of the manifest and the surrounding architecture, with each entry's contribution to the safety posture spelled out. Read it next to extensions/manifest.json.

manifest_version: 3

Opts into Chrome's tightened security model: no inline scripts, no eval, no Function('...'), no remotely-hosted code. Service worker rather than persistent background page. This is foundational — almost every other defense relies on Manifest V3's constraints.

permissions: ["activeTab", "downloads"]

Smallest reasonable set:

• activeTab is a grant on user gesture, not a standing capability. It activates only when the user clicks the toolbar action, gives the script access to the current tab for one invocation, and then drops. Compare to tabs (always granted) or <all_urls> (always granted, all sites).
• downloads is the only way for an extension to write a file to disk. Chrome surfaces the destination to the user via the standard "Save As" dialog.

host_permissions: three exact origins

Each host pattern is an explicit, narrow grant:

• https://gemini.google.com/*
• https://claude.ai/*
• https://chatgpt.com/*

If a future supported site is added, it must be added here, visibly, in a PR. There is no wildcard fallback.

content_scripts: one entry per site

Each content script is bound to its origin and runs at document_idle. Two implications:

• The same extension code cannot accidentally attach to a different LLM-like site that happens to load fast.
• Each site has its own selectors-*.js file. DOM selectors are scoped per provider; a Google DOM change cannot affect Claude extraction and vice versa.

background.service_worker

Minimal coordination logic. Does not hold conversation content. The service worker exists primarily to wire up the popup-to-content-script messaging. It is not the place where extraction happens.

What is not in the manifest, by design

• No tabs — Clio does not need to enumerate all tabs
• No cookies — Clio does not touch authentication state
• No webRequest — Clio does not intercept or inspect network traffic
• No storage — Clio does not persist anything in the extension (current versions; Clio 2.0 will revisit this and the addition will be deliberate)
• No identity — Clio does not authenticate the user to anything
• No notifications — keeps the surface small
• No <all_urls> — never

Each absent permission is intentional, and each future addition requires an explicit justification in the PR.

What this purchases

A user who installs Clio is taking on a small, knowable risk:

If Clio's code, or the extension itself, were to become malicious, the worst it could do is degrade the accuracy of conversations extracted from the three declared LLM sites, and write something bad to the user's local disk under the user's confirmation.

That's the maximum blast radius. The user cannot have their browsing history exfiltrated, cannot have their cookies stolen, cannot have arbitrary network traffic inspected, cannot have other extensions interfered with. The manifest does not grant the permissions any of those attacks would require.

Related

• Privacy Architecture — how this enforces the privacy commitment
• Threat Model — the attack scenarios these defenses target
• Connection to sentinel-rfc — broader research on capability-bound extensions