Public store policies describe enforcement as a ladder: reject a submission, warn on a live item with a deadline, take it down or block it, then act on the account. Chrome, Mozilla and WordPress.org each use a version of it. The differences, mainly in notice and reversibility, are worth copying or avoiding when you design your own.
The three ladders side by side
| Step | Chrome Web Store | Mozilla add-ons | WordPress.org plugins |
|---|---|---|---|
| New submission fails | Rejected, emailed with policy and appeal guidance, live listing unchanged | Rejected or blocked, corrections requested | Plugins with security issues are closed until resolved |
| Live item has a minor problem | Warning, typically 7 to 30 days to fix | May contact developer and allow reasonable time | Plugin closed until resolved for security issues |
| Item stays unfixed | Takedown from store and search, later disabled for users | Version or whole add-on blocked | Removal of plugin or plugin data |
| Serious abuse | Removed without notice, account may be suspended, users cannot re-enable | Immediate block if intentional, repeated or developer unreachable | Removal of all the author's plugins and a hosting ban for repeat violations |
| Public safety | Not described in the pages read | Block may be immediate | Directory may change a plugin without developer consent |
Sources for each column are the pages listed below. Treat the table as a summary of those pages, not a complete description of any store's practice.
Four design questions the ladders answer
- Is there a grace period? Chrome gives a stated window for minor issues. Mozilla says it may allow reasonable time. A fixed number is easier for developers to plan around.
- Are users told? In Chrome, a rejection does not notify end users, because nothing live changed. A takedown eventually disables the extension for users. Decide when your users hear about a problem.
- Is the action reversible? Takedowns in Chrome are usually reversible with a compliant version. Malware actions are not. Separate the two cases clearly.
- Does it reach installed copies? A store listing removal does not always remove installed copies. VS Code's documented block list does, since it uninstalls automatically. Your kill switch design should say.
What to copy
- Two tracks: a slow, fair one for ordinary violations and a fast one for malware.
- A named policy in every notice, so developers know what to fix.
- An appeal route with a limit, so it cannot be used to stall.
- A rule against evading enforcement by using new accounts. Chrome's policy lists it explicitly.
What to avoid
- Silent removal with no contact route for good faith developers. Even for malware, publish a way to ask questions afterwards.
- Warnings with no deadline, which become permanent exceptions.
- Public pages that leave out how to report abuse.
Using this as a buyer
If you rely on extensions or plugins from a store, ask what happens between a policy violation and removal. The gap, from warning to takedown, is exposure time. Chrome describes 7 to 30 days for warnings. During that window an extension with a violation remains installed on your machines. Your own inventory and monitoring close that gap faster than store enforcement can.
Safeguard's policies, gates and guardrails and continuous monitoring are designed for this kind of owner-side control over what enters and stays in your environment.
Quick check
Do stores always tell users when they act?
No. Chrome says rejections leave the live listing unchanged and do not notify end users, while takedowns and later disabling affect users.
Is a takedown permanent?
Often not. Chrome says takedowns are usually reversible with a compliant version, but malware removals are handled differently.
Can a directory change a plugin without the developer?
WordPress.org guidelines say it may, in the interest of public safety.
Sources
- Chrome Web Store: Review process
- Chrome Web Store: Program policies
- Mozilla Extension Workshop: Add-on policies
- WordPress.org: Detailed plugin guidelines
Last reviewed: 19 October 2026.
