🔒 AI Extension Security Methodology

A security disclosure on this site is a plain-language, automated analysis of a Chrome AI extension's publicly available package — its manifest permissions, the external domains its code references, its published privacy policy, and its Chrome Web Store listing. It is not a formal security audit, penetration test, or certification, and it cannot detect everything a hostile update might do. We take a deliberately restrained, professional-review stance: we disclose facts with hedging and do not render a verdict. We do not tell you a tool is "safe" or that you should "avoid" it — we describe what it requests, what that can support, and how it compares to other tools of its kind, then let you decide. Every factual claim we publish is tied to a dated scan and is independently verifiable.

Why we disclose instead of scoring

Broad permissions are not automatically bad. An AI sidebar has to read the page you're on to answer questions about it; a translation tool has to rewrite text on any site; a writing assistant has to see the editable field you're typing in. The right question is not "how many permissions?" but "does this tool request more than tools of its kind normally need, and what could the extra access support?" So instead of collapsing everything into a single 0–10 number, we compare each extension to a published baseline for its category and disclose anything beyond it as a hedged fact.

The disclosure model

There is no composite score, no weighting formula, and no safe/caution/avoid band. Each extension gets a two-tier, category-relative permission profile:

"Broader than typical" is not a warning to avoid the tool. It flags that the tool asks for more reach than its peers, and each extra permission is disclosed as a fact with a neutral, hedged note about what it can support — never a claim about intent.

What makes a permission "notable"

A requested permission only flips the profile to "broader than typical" when it is both:

• beyond the category baseline — not part of the expected toolkit for that kind of extension; and
• high, medium, or unclassified risk — capable of meaningful access.

Ubiquitous low-risk conveniences (side panel, notifications, alarms, unlimited local storage, and the like) are never treated as notable, even when they're beyond the baseline — surfacing them would be noise, not disclosure. Unexpected access to all websites is always notable.

Category baselines

A baseline is the set of permissions an extension of a given kind legitimately needs to do its job. Baselines are data, not judgment — they're published in the scanner (scripts/extscan/categories.py) and applied by a scoring engine that contains no category logic of its own, so the same input always yields the same profile.

Disclosed facts that stay separate from the profile

Two more findings are published on every page as standalone facts. They are deliberately not folded into the profile — they inform your judgment, they don't become a score:

• Data flow. We statically extract the external domains an extension's code references and label each first-party (vendor-owned) or third-party. This is alower bound: obfuscated, minified, or dynamically constructed URLs may be missed, so a short list never means "sends nothing." Domain lists are always labelled as a static-analysis lower bound.
• Privacy-policy score. A 0–10 figure summarising how well the published policy addresses 11 fixed criteria (below). It measures the policy, not the extension's behaviour, and it is a disclosed fact — not a safety verdict.

The 11 privacy criteria

The privacy-policy score rates an extension's published policy against 11 fixed criteria. Each is scored 0–2 (higher = better for the user), for a maximum of 22 points, rescaled to a 0–10 policy_score. It is reported on its own, never blended into the permission profile.

1. Data collection scope — collects only what the feature needs
2. Third-party sharing — sharing with third parties disclosed and limited
3. Data selling — does not sell user data
4. Retention period — retention period specified
5. Deletion rights — user can request deletion
6. Anonymization — anonymization/pseudonymization practices stated
7. Policy clarity — readable, specific, not boilerplate
8. Jurisdiction compliance — GDPR/CCPA handling stated
9. Change notification — notifies users of policy changes
10. Children's data — children's data addressed
11. Training on user data — states whether user content trains AI models

How we scan

The pipeline behind every disclosure is deliberately transparent:

1. Download the public CRX. We fetch the extension's publicly distributed package from the Chrome Web Store — no private access, no reverse-engineering of paid features.
2. Parse manifest permissions. We read the declared permissions and host permissions and classify each by risk, with a plain-language explanation of what it allows.
3. Compare to the category baseline. We flag notable permissions beyond the baseline and any unexpected all-sites access, and attach a hedged note on what each can support — this produces the permission profile.
4. Statically extract external domains. We scan the bundled code for external domains it references. This is a lower bound: obfuscated, minified, or dynamically constructed URLs may be missed, so a clean data-flow result never means "sends nothing." Domain lists are always labelled as a static-analysis lower bound.
5. LLM-assisted privacy-policy scoring. A language model scores the published policy against the 11 criteria and quotes the evidence for each score. If the policy can't be reached, the scan is marked partial:policy.
6. Human final review. A person reviews the machine output before a page is published — the one-liner, alternatives, and editorial notes are human-owned and are never overwritten by an automated re-scan.

Legal & fair comment

The facts we state (permissions declared, domains found, policy language quoted) are verifiable, and the category baselines are public — anyone can apply the same baseline to the same package and check our arithmetic. We describe behaviour, not motive: "version X contains code that sends browsing data to Y" is a fact we will state; "this company steals your data" is an intent claim we will not. Where a permission is broader than typical, we describe what it can support("can support reading the page to answer questions about it"), never what the vendor intends.

We do not present the word "safe" — or "unsafe", "avoid", or "risky" — as a conclusion. The profile ("Typical for its category" / "Broader than typical") describes how a tool's requests compare to its peers as of that scan's date. It is not a future guarantee: an extension can change hands or ship a hostile update (a "rug pull") after a scan, so every finding is stamped with the date it was true.

If you believe a finding is wrong or out of date, email[email protected]. We commit to a re-review within 48 hours: factual errors are corrected, and a new version that changes behaviour is re-scanned with an updated date.

How we make money

Some outbound links — including "alternative" suggestions on a disclosure page — are affiliate links: if you install or buy through them, we may earn a commission at no extra cost to you. One hard rule keeps this honest: affiliate status is never an input to the profile. The permission profile is derived only from the scanned facts — declared permissions versus the category baseline, and whether all-sites access is requested — and a documented fact is never removed for commercial reasons. An extension with no affiliate program is disclosed identically to one that pays. If you ever spot a conflict between our data and our links, email[email protected] and we'll investigate publicly.