Why Technical Users Bypass Every Blocker They Install

By [author name and credential to be confirmed]

You install the blocker on a Sunday evening, feeling organized. By Thursday you have added an exception for one site you genuinely needed. By the following week it is disabled, or the config is back to how it was, and you are not entirely sure which afternoon that happened.

This is close to universal among people who can read a config file, and it is usually filed under willpower. It is not a willpower problem. It is a predictable outcome of where the block was placed and how much effort stood between you and removing it.

The useful way to think about this is in layers. A block can live in four places, each with different coverage and a different cost to undo, and almost everyone picks a layer for the wrong reason.

Layer one: the hosts file

The first instinct for most technical users is /etc/hosts, or its Windows equivalent. Point the domain at 127.0.0.1 and the browser cannot resolve it.

It is appealing because it is free, it is already there, and it feels like the real solution rather than consumer software. It is also the weakest option available.

Undoing it takes about eight seconds, and you already have the privileges required, because you needed them to add the entry in the first place. There is no asymmetry at all. The same command that created the block removes it.

It is also blind to a great deal. It resolves names, so it has nothing to say about a native application, and it handles subdomains and content delivery networks badly. Blocking a social platform's main domain while its CDN, its API endpoints and its desktop client all continue working produces a block that is both annoying and ineffective, which is the worst combination.

Layer two: DNS

The next step up is usually a Pi-hole on the LAN, or a hosted resolver like NextDNS with categories switched on. This is a genuine improvement. Coverage extends to every device on the network, blocklists are maintained by someone else, and you get logs.

Two problems remain, and one of them is new.

The old problem is that you administer it. The Pi-hole has a web interface and you know the password. Disabling a blocklist for fifteen minutes is a toggle, and fifteen minutes becomes the rest of the evening often enough that it is worth planning for.

The new problem is DNS over HTTPS. Browsers now send DNS queries inside ordinary HTTPS sessions to their own resolvers, which means the query never reaches your Pi-hole and never appears in its logs. Firefox has shipped this by default for US users since 2020, and Chrome upgrades automatically when the configured resolver supports it. You can fight this by blocking known DoH endpoints or pushing policy, but you are now maintaining a list forever, and the browser vendor is iterating faster than you are.

There is also a failure that has nothing to do with encryption. DNS-layer blocking applies on that network. Tethering to a phone, joining different Wi-Fi, or bringing up a VPN leaves it behind completely. For a desktop that never moves this is fine. For a laptop it is a gap you will find without looking for it.

Layer three: the browser extension

Extensions are the most granular option. They can match on URL patterns rather than domains, filter in-page elements, apply time budgets, and distinguish between a site's useful section and its feed.

They also fail for two structural reasons, and both are worth understanding rather than just noting.

An extension runs in a sandbox with no elevated privileges. It can see and modify pages, because you granted it that, but it has no authority over anything outside its own browser process. It cannot stop you opening a second browser, and on any developer machine there are at least three installed.

More immediately, the disable control is a toggle in a settings pane that belongs to you. There is no password, no delay, and no friction. It is two clicks from the page you are trying not to look at.

Granularity is real and worth having. It is just operating on top of a control surface you fully own.

Layer four: the process level

The last layer is a resident process with elevated privileges, enforcing rules at the operating system rather than inside an application.

This is the only layer that reaches a native client. Slack, Steam, a desktop email client, a game launcher and a Chromium-based app that is really a website in a wrapper are all invisible to the three layers above. If what actually pulls your attention has an icon in the dock rather than a tab in a browser, nothing below this layer touches it.

It is also the only layer where the block can apply uniformly across every browser without needing to be configured in each one, and where it can keep applying when the machine changes network.

The cost is that you are installing software with real privileges, which is a decision worth taking seriously on a machine you work on. That is a fair objection, and it should be weighed against what the alternatives are actually delivering.

The thing the layers do not settle

Here is the turn, and it is the part most comparisons of these approaches miss entirely.

Every layer above was described in terms of coverage, which is how these things are normally argued about. Coverage is the easier question and the less important one. The question that decides whether a block survives contact with a Wednesday afternoon is whether the control resists the person who installed it.

By that measure, three of the four layers score close to zero. The hosts file, the Pi-hole and the extension are all administered by you, with no delay, no second party and no cost to reversing them. They are reminders. A reminder is useful, and a reminder is not a block, and conflating the two is why the setup keeps failing.

This is uncomfortable because it implies the solution involves deliberately reducing your own control over your own machine, which runs against most of what technical people are trained to value. But it follows directly from the problem. If the person circumventing the control is also the person who holds the keys, the control is decorative.

What makes a block hold is asymmetry: it should be meaningfully harder to remove than it was to create. That can be a mandatory cooling-off period before a rule will lift, a commitment set for a date you cannot bring forward, a second person holding the unlock, or protection that prevents the enforcing process being killed or uninstalled while a block is active.

None of this is about making a block impossible. Anything you install, you can eventually remove, and a tool claiming otherwise is either lying or doing something you should not permit on your machine. The goal is to insert enough deliberate effort between the impulse and the reversal that the decision becomes conscious. Most of the time, the urge does not survive the delay.

Tools built around this exist, and DigitalZen is a reasonable illustration of the shape: a desktop process covering applications as well as sites across all browsers from one configuration, with the removal path deliberately made slower than the installation path. Whether you use that one, a competitor, or something you write yourself matters far less than whether the thing you choose has any asymmetry in it at all.

How to audit your own setup

If you want a quick test of whatever you currently have running, there are three questions.

How long does it take to undo, in seconds? Not in theory, in practice, from the moment you decide to. If the honest answer is under thirty, you have a reminder.

What does it not cover? Open the thing you are trying to avoid in a second browser, or in its desktop client. If either works, the coverage gap is where your attention will go, because it always finds the opening.

Who else is involved? If the answer is nobody, then the only thing standing between you and the reversal is a version of you who is tired and has a deadline, and you already know how that negotiation ends.

Most setups fail all three, which is why most setups fail. The fix is rarely a better blocklist. It is usually a block placed lower in the stack, with something deliberately inconvenient standing between you and switching it off.