Browser Extension
Optional, and it never blocks anything on its own. Filtering is always enforced by DNS — the extension fixes one specific annoyance.
The problem it solves
When DNS Filtering blocks a site, the browser is sent to your block page. Over plain HTTP that works perfectly. Over HTTPS it does not: the browser starts a TLS handshake with the block page server, gets a certificate issued to "Blocked by DashX policy" instead of the site it asked for, and shows a full-page security warning. Your block page only appears after the user clicks "Proceed anyway".
That is worse than it looks. You are teaching people to click through certificate warnings — the exact reflex that phishing relies on.
The extension detects that the navigation failed, asks DashX whether that domain is blocked for your organization, and if so opens your block page directly. No warning, no click-through.
Making the browser trust the block page for any domain would require installing a certificate authority capable of signing for every site on the internet. DashX deliberately does not do this — a leak of that key would mean silent interception of every HTTPS connection on the fleet. The extension achieves the same result without touching TLS at all.
What it can and cannot see
| Reads page contents | No — there are no content scripts |
| Sees browsing history | No — it is only notified when a page fails to load |
| Contacts DashX | Only for a failed navigation, and only to ask about that one domain |
| Blocks anything itself | No — DNS remains the only enforcement point |
| Covers other applications | No — browsers only; other apps still get a connection error |
A successful page load produces no network request from the extension at all.
Requirements
- DNS Filtering entitlement, active on the organization.
- Block page enabled on the policy (DNS Filtering → Policy). With the policy left in plain-DNS-error mode, the extension deliberately does nothing — it will not turn on a feature you did not enable.
- The device must be on a network DashX recognizes, meaning a DashX agent is reporting from the same public IP. Otherwise the extension cannot tell which organization's policy applies and stays silent.
Install it — one user
Get the store links from Secure Access → DNS Filtering → Browser Extension in your DashX console. The same page has a Copy message for employees button that produces a ready-to-send note with the links and a short explanation.
Chrome and Edge use the same package — install from the store, no configuration, no sign-in.
Firefox uses a separate signed package. Install it the same way.
There is nothing to configure. The extension identifies the organization through the network, exactly like the block page itself.
Roll it out to everyone
Pushing it by policy means users cannot remove or disable it, and there is nothing for them to do.
Windows — Intune
Create a Settings catalog profile, add Configure the list of force-installed apps and extensions, and add one entry per browser:
<extension-id>;https://clients2.google.com/service/update2/crx
The extension ID is shown on the store listing and on the console page. Assign the profile to your device groups.
Windows — Group Policy
The Chrome and Edge ADMX templates expose the same setting under:
Computer Configuration → Administrative Templates → Google Chrome → Extensions
→ Configure the list of force-installed apps and extensions
macOS — Jamf or any MDM
Deploy a configuration profile for com.google.Chrome (or com.microsoft.Edge) containing the ExtensionInstallForcelist key with the same value.
Firefox
Firefox reads policies.json (or the org.mozilla.firefox profile on macOS). Two things matter:
{
"policies": {
"ExtensionSettings": {
"web-filter@dashxtech.com": {
"installation_mode": "force_installed",
"install_url": "<url from the console>"
}
}
}
}
In Manifest V3, Firefox treats access to websites as an optional permission and does not grant it on install. Without it the extension sees nothing and silently does nothing. Force-installing through ExtensionSettings grants it; a user who installs manually must enable Access your data for all websites under about:addons → DashX Web Filter → Permissions.
Check that it is working
Click the extension icon. Three lines tell you where you stand:
| Line | Meaning |
|---|---|
| Extension: Active | The extension is loaded and running |
| DashX service | Which DashX region answered |
| Organization: Recognized | DashX matched this network to your organization |
Then open a site you know is blocked, over https://. Your block page should appear immediately, showing the original domain under Site, with a valid certificate in the address bar.
Troubleshooting
The browser still shows a certificate warning. Check the popup first. Organization: Not recognized means no DashX agent is reporting from this public IP — the extension cannot know whose policy applies, so it stays silent by design. DashX service: Unreachable points at a network or firewall problem.
It works for some sites but not others. Once a user clicks through a certificate warning, the browser remembers that exception for the rest of the session and stops reporting the navigation as failed. Test in a fresh window, or with a domain nobody has bypassed yet.
Nothing happens at all, and the popup looks fine. Confirm Block page is enabled on the policy that applies to this device. With it off, the extension intentionally does nothing.
Firefox: the extension disappears after restart.
It was loaded as a temporary add-on through about:debugging. Install the signed package instead.
What is left uncovered
The extension only covers browsers where it is installed. A desktop or mobile application hitting a blocked domain still receives a plain connection error — there is no block page for it, and no way to provide one without intercepting TLS. This is a deliberate trade-off, not an oversight.