Severity should track what the dev can actually do about it

Suhaib ran his manifest through ReviewArmor before and after a single-field change. These are the raw scanner outputs:

Delta: −1 HIGH eliminated, +33 score, the verdict crossed two band boundaries (passed straight through risky into the upper band).

One edit. Suhaib removed the broad http://*/* and https://*/* entries from host_permissions. He kept content_scripts.matches as http://*/* and https://*/*— InfoBlend's core interaction is double-click on a word: select any word on any page to see its definition. For that to work, the content script has to be attached on every site at page load — narrowing the match pattern would break the product on whatever sites it excluded.

The HIGH findings that disappeared were the standalone broad_host_permissions (which V1.1 still flags as code-fixable when broad URL entries appear there) and permission_redundancy_double_broad (which fires only when the same broad scope appears in both host_permissions AND content_scripts.matches). Once host_permissions no longer carried the broad entries, both findings had nothing to fire on.

What remained: one MEDIUM (broad_content_scripts_matches, which Suhaib will address in reviewer notes) and one LOW (broad_war_matches, informational — no .js/.htmlis gated behind it, so there's nothing to act on).

You can verify the manifest changes against the source, and follow the eventual CWS review outcome, in the discussion thread Suhaib opened on the InfoBlend repo: github.com/RIxiV1/InfoBlend/discussions/3.

Pre-V1.1, broad URL scope was tracked under a single broad_host_permissions HIGH that fired whenever any broad URL pattern showed up anywhere in the manifest. That was wrong. It lumped together a code-fixable problem (a redundant host_permissionsdeclaration) with a structurally-broad pattern (a dictionary tool's content script) under the same severity. A developer in Suhaib's position couldn't drop the HIGH no matter what they did — narrowing the content script was off the table for legitimate product reasons.

V1.1 splits broad URL scope into three distinct findings, plus a fourth that fires only on redundancy:

• broad_host_permissions — HIGH, code fix exists (remove the line)
• broad_content_scripts_matches — MEDIUM, docs fix (explain in reviewer notes)
• broad_war_matches — LOW, FYI (only matters if .js/.html is exposed behind it)
• permission_redundancy_double_broad — HIGH, fires only when both host_permissions and content_scripts.matchesare broad ("delete one, halve your finding count")

The split is built on a framing Suhaib gave us during the V1.1 design conversation:

Severity should track what the developer can actually do about it. HIGH means a code fix exists. MEDIUM means a docs fix — you explain it to the reviewer. LOW is FYI.

This is what makes the 3-way split honest. The old single finding violated this principle: it assigned HIGH to situations where no code fix existed. The split restores the property that a HIGH finding is always actionable, and a developer who does the right thing sees the score move accordingly.

ReviewArmor does not predict CWS approval. The scanner reads manifest.jsonand flags patterns that historically draw reviewer attention; it does not run your code, audit your remote endpoints, or guarantee anything about what the review team will decide. The 1 MEDIUM and 1 LOW remaining in InfoBlend's post-tightening report are real findings — Suhaib still has to write the reviewer-notes paragraph for the broad content-script match, and source-code verification (no remote eval, no obfuscation, declared APIs match actual usage) is still the developer's job. The scanner is a checklist that catches the cheap mistakes before a human reviewer has to.