Just Deploy the Ad Blocker | IFIN

Skip to content -->

2026-06-11

by Michael Taggart

#best-practices

Deploying an ad blocker to your users might be the single easiest, most impactful security action you can take in your environment. And it costs you nothing.

Yes, even as news spreads that the older, more powerful ad blockers are getting nerfed by Google, deploying an ad blocker is still worthwhile in the enterprise. You can pay for commercial solutions, but you also don't have to.

The case for an ad blocker is easy to make: prevent malicious ads and JavaScript from loading on sites, protecting users from malvertising attacks. As an added benefit, your network noise will decrease with fewer asset loads per site visit, and your users' general experience of the web will be much more pleasant.

Most of us who work in cybersecurity have an arsenal of tools at our disposal to make our internet tolerable: browser extensions, DNS configurations, custom firewall rules, and more. Most users don't have any of that. I like to recommend to my team that every quarter or so, they browse the internet on a sandboxed VM in "raw" mode, meaning as the computer comes out of the box. No content filters, no extensions, just the browser and the internet.

It's agonizing. That's the internet most users encounter. Just from the ethical position of alleviating suffering, deploying an ad blocker is a benefit. From this standpoint, it's hard to imagine a reason why you wouldn't deploy an ad blocker.

Somehow, the enterprise finds a way. Here are some common arguments against, and how to counter them. I know these work, because I managed to do it. UBlock Origin Lite is a managed install for our organization now, and the impact has been entirely positive.

"It's Not Enterprise-Managed"

The enterprise loves a management console, a way to centrally dictate and monitor configuration state of assets. That's reasonable, and there are plenty of enterprise-ready products that will deliver just that. But hear me out: what if for this one, it's not necessary?

If you're a Google shop, managed browsers can be configured from the Workspace console. For everyone else, policy settings can be applied via registry (and group policy), plist, or JSON file, as appropriate for the platform. These settings allow you to require (and only allow, hint hint) specific extensions. You can even configure those extensions to load or not load on specific sites. That tidbit is how I got an ad blocker past this hurdle. The blocker did prevent the loading of our main site chatbot, but a simple registry addition sorted the problem.

This works for Edge as well, by the way. Likelier than not, your enterprise "approved browser" is one of those two.

"There's No Support Contract"

Is there support for the browser? This argument drives me a little crazy. Enterprises run on open source software, provided as-is and without warranty. But for some reason, officially deploying an open source tool hits this blocker.

The response to this argument is two-pronged. First, emphasize the ubiquity of open source, no-support software already in production. Betcha have some Ubuntu VMs in prod without paying for Ubuntu Pro. Even more likely, you're using SSH or cURL. Not every single pile of code needs a sales rep and service level agreement.

Second, remind folks that the objective is to prevent actually malicious software in the environment, which is by far the greater concern. And while some ransomware does come with a support contract, you really don't want to learn more about the terms.

"What If It Breaks Something?"

What if malware breaks something? There is a chance the ad blocker in default configuration will cause something to not work. You can use the policies described above to fix it for everyone. Also, individual users are free to disable the extension per-site as they see fit. A little user education goes a long way. A single knowledge base article or instructional video can prepare your users for the new extension. In my experience, it takes about 20 seconds to learn.

It can be difficult to explain the downside risk of inaction on threat sources. Until the Bad Thing happens, it's all speculative, whereas a user complaining about a new security control is very real. To overcome this blocker, you must clearly convey that the risk of temporary and fixable user inconvenience is well worth the mitigation of the true risk: malware infection via ads.

Get It Done

Deploying new tools to large organizations can take a looooong time. Pursuing positive security posture change in the enterprise is, to borrow from Max Weber, the "slow boring of hard boards." But it's worth it to keep your users safe. That's what we're really talking about here.

Consider this your official notice from IFIN to send some messages, ask some questions, and get that ad blocker on your users' browsers. It's not exactly an "easy" win, but it's profoundly worth the effort.