56 → 89: what one host_permissions edit looked like through ReviewArmor
ReviewArmor (reviewarmor.dev) is a free pre-submission audit for Chrome MV3 extensions — paste a manifest.json, get a risk score and a list of likely review flags in about 30 seconds. It's aimed at indie devs who don't want to discover a permission problem from a CWS rejection email two weeks after submitting. V1.1 just shipped, and it's a rubric release rather than a feature release.
The case study
Suhaib ships InfoBlend, a real Chrome dictionary extension. He ran it through ReviewArmor, dropped one overly broad host_permissions entry from the manifest, and the numbers moved like this:
Before → After
riskScore: 56 → 89verdict:likely_rejected→submission_ready_with_notes
Full diff, the exact manifest line that moved, and how V1.1's scoring weighted it: /case-studies/infoblend. Suhaib opened a discussion thread on the InfoBlend repo where anyone can verify the manifest changes against the source, and he and I will post the actual CWS review outcome there when it lands — so this turns into a longitudinal data point, not just a one-shot screenshot.
The rubric redesign
The redesign came out of Suhaib's feedback. His framing: severity should track what the developer can actually do about it.
- HIGH = code or manifest fix required
- MEDIUM = documentation / justification fix
- LOW = FYI, no action needed
Previously, findings got lumped by category, which meant a host_permissions problem and a missing privacy URL could both surface at the same weight even though only one of them needs a code change. Full notes: /changelog/v1-1.
What it doesn't do
Manifest-only static scan. It doesn't execute your extension, doesn't read your background script logic, and doesn't predict CWS approval — reviewers still do things no rubric catches. It catches the boring stuff before a human has to.
Ask
Try it: paste a manifest at reviewarmor.dev. No signup, no email.
And a genuine question for the IH crowd — how have you handled the gap between what automated checks flag and what CWS reviewers actually push back on? I'm specifically curious whether anyone's tracked their own rejection reasons over time.
— Yuan
Great write-up, Yuan!
As the dev behind InfoBlend, seeing that score jump from 56 to 74 just by deleting redundant code was crazy.
Catching those AI localization hallucinations before the V1.1 fix was a huge win. Static manifest analysis just isn't enough, so I'm stoked you shipped the grounding update so fast. It makes the boilerplate actually useful.
Highly recommend extension devs run their code through this. Saves a ton of review headache.
Suhaib — really appreciate you showing up under the post.
Quick correction for anyone reading: it was 56 → 89 in V1.1
(the 56 → 74 was the pre-V1.1 rubric, before the
broad_host_access split turned acknowledged docs-fixes into the
score they actually deserve). That score honesty is exactly what
your reply #7 forced into the design.
And the localization-hallucination catch — that one nearly went
out the door as a TODO. You pushing on whether the boilerplate
could be trusted with no grounding was the call that made V1.1
ship verified rather than just generated.
If you do submit InfoBlend to CWS, I'd love to hear how the
reviewer-notes paragraph the kit drafted holds up. That's the
loop I can't close from my side yet.
— Yuan