A good blocked-install message says why the extension is blocked, what to do next, and how long a decision takes. Chrome and Firefox both support custom text through blocked_install_message in their ExtensionSettings policies, so the message can send people to a request form instead of leaving them guessing.
Where the message appears
Chrome's ExtensionSettings schema describes blocked_install_message as text displayed to the user in the Chrome Web Store if installation is blocked. Mozilla's documentation says the Firefox field adds text to Firefox's standard error message and can direct users to a help desk.
A silent block creates a bad pattern. The person sees an error, assumes it is a glitch, and tries another browser or a personal laptop. A message that explains the process turns that moment into a request.
What to include
- A plain reason. "Extensions must be reviewed before use on company devices."
- The next step. A link or short path to the request form.
- A timeframe. "Most requests are answered within two working days." Only state a number you can keep.
- A contact. A team alias a real person watches.
Examples
Weak: "Blocked by administrator."
Better: "This extension has not been reviewed yet. Request a review at the IT portal. We usually reply within two working days."
For a rejected extension, say so: "This extension was reviewed and is not approved for company devices. Contact the security team if you believe the decision should change."
Practical rules
- Keep it short. The text sits inside an error message and long text gets cut or ignored.
- Do not include secrets. Messages are visible to anyone who hits the block. Avoid internal hostnames you would not want shown.
- Use one request link. Do not scatter instructions across chat channels.
- Do not blame. People are doing their job, and a neutral tone gets more honest requests.
- Update it with the process. A stale link teaches users to ignore the message.
Per-extension messages
Chrome's schema allows blocked_install_message under the default * entry and per extension ID, so you can give a specific reason for a specific extension. That is useful for a rejected one: "This extension was removed after a publisher change." Be careful with detail, though. Do not name individuals or make claims about a publisher that you cannot back up.
Track what the requests tell you
Each request is data. If many people ask for the same extension, review it first. If requests are slow, you will see workaround attempts. Review request volume monthly, and tie it back to the exception process.
Test the message
Open the store page on a pilot machine as a normal user and try to install a blocked extension. Read the message as someone who has never seen your process. Does it say what happened? Does it say who to ask? Does the link work from a phone, in case the person is away from the desk? Fix what fails, then ask two colleagues outside security to read it and say what they would do next. If their answer is not what you hoped, reword it. A thirty second test saves weeks of confused tickets.
Quick check
Does the message replace a request process?
No. It only points to one. You still need an owner who answers requests and a record of each decision.
Can the message be different for each extension?
In Chrome's schema, yes: the field appears in both the default entry and per extension entries.
Sources
Last reviewed: 19 October 2026.
