Administrators
Force-install it, pin the settings you care about, and leave the rest to the user. Everything below uses the browser's own extension policy — there is no agent, no installer and no licence key to distribute.
Use the browser's existing extension policy. On Windows this is the ExtensionInstallForcelist Group Policy setting under Google Chrome → Extensions; the same key exists for Edge and in the Google Admin console.
cjijlgnefahbmcogbhacnnnlnaeolmjg;https://clients2.google.com/service/update2/crx
Users cannot remove a force-installed extension, which is usually what you want for a measured pilot — a rollback then means removing the policy rather than chasing devices.
Policy is delivered through the 3rdparty section of the browser's managed policy, keyed by extension ID. Only the keys you set are enforced — anything you leave out stays under the user's control, so you can lock image blocking on and still let people switch video blocking off themselves.
| Key | Type | What it controls |
|---|---|---|
ads | boolean | Block ads and trackers |
images | boolean | Block images |
media | boolean | Block video and audio |
consent | boolean | Answer cookie banners with the most private option |
popups | boolean | Block popups not opened by the user |
allowlist | array | Sites where blocking is switched off entirely |
siteProfiles | object | Per-site overrides, keyed by domain |
Ads and images blocked, video left alone, and two internal applications exempted so nothing breaks on the first morning:
{
"3rdparty": {
"extensions": {
"cjijlgnefahbmcogbhacnnnlnaeolmjg": {
"ads": true,
"images": true,
"media": false,
"allowlist": ["intranet.example.org", "erp.example.org"],
"siteProfiles": {
"docs.example.org": { "images": false }
}
}
}
}
}
In that example allowlist switches blocking off entirely for two internal systems, while siteProfiles keeps ads blocked on the documentation site but lets its images through — the narrower fix, and usually the better one.
| Platform | Mechanism |
|---|---|
| Windows | Group Policy, or the registry under HKLM\Software\Policies\Google\Chrome\3rdparty\extensions\cjijlgnefahbmcogbhacnnnlnaeolmjg |
| macOS | A configuration profile or plist in /Library/Managed Preferences/com.google.Chrome.plist, pushed by Jamf, Intune or equivalent |
| Linux | A JSON file in /etc/opt/chrome/policies/managed/ |
| ChromeOS | Google Admin console → Devices → Chrome → Apps & extensions → the extension → Policy for extensions |
chrome://policy on a target device and check the extension's policy appears with the values you set.Anything you have not pinned. They can also always stop blocking on the page they are looking at — a button at the top of the popup and Alt+Shift+D. That is deliberate and we would advise against trying to remove it: when a site breaks and there is no visible way out, people uninstall the extension instead, and on a managed device they raise a ticket with you. The escape hatch is what keeps the deployment quiet.
If a specific site must never be exempted, pin it through siteProfiles rather than relying on users not touching it.
Remove the extension ID from ExtensionInstallForcelist and the browser uninstalls it at the next policy refresh. No files are left behind, and nothing needs to be cleaned up on the device — all state lived in the browser's own extension storage.
Deployment not applying, or a site behaving oddly under policy?
Ask a question