WeBlocker: Take Control of Your Digital Focus

We all have that one site, or maybe five, we keep promising ourselves we won’t visit again. And yet, we’re back there every other hour, doom-scrolling or mindlessly clicking through.

I was fed up with it. Not just the distractions, but with the tools claiming to help, while quietly doing things I never agreed to. So I built WeBlocker. It’s my open-source, no-BS Chrome extension to block time-wasting domains and URLs. No tracking. No sneaky permissions. Just control, back where it belongs: in your hands.

Let me walk you through why I built it, how it works, the struggles I faced with Manifest V3 (thanks, Google), and what happens behind the scenes when you block something.

The Trust Problem No One Talks About

Site blockers are nothing new. The Chrome Web Store is flooded with them. But most of them raise the same red flag:

Why does a simple blocker need permission to “read and change all your data on all websites”?

It didn’t sit right with me. Also, the bloated UI, analytics scripts, and occasionally ad injections, and you begin to realize you’re trading one problem for another. I wanted to fix the issue for myself. Not just slap a UI on it. I needed something:

• Simple and minimal

• 100% private

• Effective under Chrome’s latest extension policies

A Clean Approach to Blocking

I designed WeBlocker with one goal: to give users full control over what gets blocked, and do it fast, without compromising privacy. Instead of depending on background scripts or hidden APIs, I built the logic using Chrome's Manifest V3 declarativeNetRequest API. The frontend is kept lean using Tailwind CSS.

The extension lets you:

• Block websites by domain (like facebook.com)

• Block any URL containing certain keywords (like ?q=adult_keyword)

• Whitelisting a specific path of the blocked website

• Redirect to the default or custom “blocked” page

• Toggle blocking on/off

• Import/export your settings

• Usage stats of the most used websites

All data stays in chrome.storage.local. Not a single thing gets sent outside your browser. No account required. No server-side logic. No hidden network requests.

And the interface? Minimalist. Just a clean sidebar, some input fields, and a status display. No fluff.

What Happens Under the Hood?

Most of the blocking logic relies on Chrome's declarativeNetRequest API. You define a set of rules that the browser uses to decide whether a request should go through or be blocked.

When you add a domain or keyword:

1. The extension dynamically creates a blocking rule.

2. It registers this rule using the API.

3. If a URL matches the rule, it’s either blocked or redirected.

This ensures the process is instant and secure because Chrome handles the request itself. There's no need for JavaScript to intercept traffic anymore.

For tracking stats, I hook into tab activity events, monitor the active domain, and log the time spent locally. You get a clear, real-time view of how long you’re spending on each domain, without needing a cloud sync or backend database.

Manifest V3: The Elephant in the Room

Now let’s talk about the messy part: Chrome’s Manifest V3.

It’s marketed as a more secure extension framework, but what it does is limit what developers like me can build.

With MV3:

• You lose the traditional background pages. They’re replaced with service workers, which are stateless and shut down frequently.

• You’re limited to 150 dynamic rules at a time. If you want to block 500 domains? Sorry, not possible, unless you hack around it.

• You can’t use the full power of webRequest anymore. So, no real-time request modifications or regex-based matching.

• Redirecting users isn’t flexible either. You’re confined to predefined redirect rules

Even building a redirect page that works smoothly across all blocked domains was a hassle. MV3 doesn't allow tabs.update() from background scripts like before, so we had to get creative with static block pages and declarative redirects.

Despite all this, I had to stick with MV3, because that’s the future (whether we like it or not). And it still lets me achieve my core mission: local-first blocking with zero tracking.

Open Source. No Secrets. Your Code.

One major reason I trust WeBlocker? Because I wrote it. But you don’t have to take my word for it. The full source code is on GitHub, MIT licensed. You can change the logic, add your own filters, tweak the UI, or just audit the code line by line. I built it not just for myself, but for anyone else tired of handing over trust to random extensions with god-mode permissions.

Build What You Want to Use

At its core, WeBlocker is a reflection of a simple belief:

If you can’t trust the tools you’re using, build your own, and make it trustworthy.

WeBlocker might not have machine learning, daily productivity charts, or some fancy, tricky tagline to catch your attention. But it gives you control. It does what you tell it to do. And it never talks behind your back.

If that sounds like the kind of blocker you’d use, go ahead and give it a try. Or clone it, improve it, and make it your own.

Stay focused. Stay in control.

— Reajul Hasan Raju (Jun 14, 2025)