Should I vibe code
Cross-device website and app blocking for focused work
A blocker only works if it is harder to remove than the urge to remove it. That is a description of malware.
?
Their verdict, the Premium price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-05.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A hosts-file blocker takes fifteen minutes and does not work, because you know how to edit the hosts file. That sentence contains the entire problem: a blocker is only as good as its resistance to the person who installed it, so every honest version of this ends up somewhere software has no business being. Look at what Freedom actually does. On iOS it drives Apple's Screen Time machinery, which needs an entitlement you have to ask Apple for and probably will not get, and layers a local NetworkExtension VPN on top so browsers and in-app webviews are covered too. On the desktop it is a privileged helper that filters traffic and survives a reboot. Your version does the same jobs without the entitlement, which in practice means a system VPN profile you wrote, a launch daemon running as root that updates itself, and — the moment the agent decides it needs to block by URL rather than by hostname — a local certificate authority terminating TLS on the machine you bank from. And the blocklist is not configuration. It is a document about its owner: gambling, alcohol, one specific person's profile. Sync it across devices and you have built a server that holds the single most revealing file its user owns.
What actually breaks
not "if". the specific failures.
- TLS, if the agent reaches for URL-level blocking. Doing that means installing a certificate authority in your system trust store and terminating every connection through code you wrote on a Sunday — including the ones to your bank and your password manager
- The privileged helper, which has to run as root to touch the network stack, has to update itself to stay useful, and is therefore an auto-updating root process whose update channel you also wrote
- Locked mode, which is the feature, and which the first time it has a bug means no internet on your work laptop and a recovery path that involves safe mode and a support forum you are not on
- The blocklist as a data object: a synced list of the sites you cannot be trusted around, sitting in a database with the security posture of a weekend project
- The DNS-level approach, the moment anything you care about is behind a CDN — blocking by hostname takes out one shared IP and a dozen unrelated services with it
- Apple's Screen Time API, which is how app blocking is done properly on iOS and which requires a distribution entitlement you have to apply for; without it, app blocking on iOS is not a hard feature, it is a closed door
- Every OS release, forever. Network extensions, system extensions, signing requirements and accessibility permissions are the parts of macOS, Windows and Android that change most and break most quietly
- The escape hatches, which are the actual product: airplane mode, another browser, a phone hotspot, the DNS setting, and the fact that you have a terminal and administrator rights
It is a Tuesday and the block is working, which is why you have not thought about it in four months. The helper updates itself from a URL in a constant, over HTTPS, verifying nothing beyond the certificate — you meant to add signature checking and it never got written down. What actually happens is duller than a compromise and worse for you: the update server is a bucket you renamed during a tidy-up, the fetch fails, the error is swallowed, and the helper keeps running the old rules with a filter list that no longer matches how anything resolves. It quietly stops blocking. You do not notice for six weeks, because the thing you built the tool to protect you from is exactly the thing you do not notice. The part that stings on review is that the daemon still runs as root, still has your CA in the trust store, and still terminates every TLS connection on the machine — a permanent security cost you are paying for a feature that has not worked since March.
Is that you?
the verdict is a default, not a law
- It is a browser extension or a hosts-file script, and you are honest that its purpose is friction rather than enforcement
- It runs on one machine, is yours, and syncs nothing anywhere
- The block list lives in a plain file you can read, and the off switch is documented and works
- You are blocking by hostname at the DNS layer with something like Pi-hole and never terminating TLS
- It installs a certificate authority in the system trust store — there is no version of this feature worth that
- It ships a privileged helper that updates itself over a channel with no signature verification
- Blocklists or browsing history leave the device, which turns a personal tool into a server holding somebody's most sensitive file
- You are giving it to other people, especially anyone who cannot recover a machine that will not reach the internet
- It is for someone else's device without their knowledge, which is not a productivity tool and has its own name
If you build it anyway
the checklist, then the prompt that enforces it
- Block by hostname, never by URL. Hostname blocking works at DNS or in a local filter without decrypting anything; URL blocking requires TLS interception, and that trade is never worth making.
- Never install a root certificate. If a plan requires one, the plan is wrong — say so out loud and pick a different layer.
- Keep everything on the device. No sync, no analytics, no crash reports containing domains. The blocklist is not telemetry-safe data.
- Give the privileged component the smallest possible job: apply a ruleset, report status. All UI, scheduling and list management runs unprivileged.
- Sign every update and verify the signature in the helper. An auto-updating root daemon with an unverified channel is a backdoor you built for yourself.
- Build the off switch before the on switch, and test it from a machine with no network. A recovery path that requires downloading something is not a recovery path.
- Fail open on error. A filter that cannot load its rules must stop filtering loudly, not block everything silently.
- Keep an allowlist that always resolves — your employer's VPN, your MFA provider, your bank — and make it impossible to add those to the block list by accident.
I am building a website and app blocker for my own machine. The dangerous
part is not the blocking, it is what I have to install to make blocking
stick. Argue me down to the least privileged design that still works.
1. Tell me which layer each feature I ask for actually requires, and push me
to the least privileged one that delivers it.
2. Block by hostname, never by URL. Explain that URL blocking means
terminating TLS, and refuse to build it.
3. Never install a certificate authority in my trust store. If a request
needs one, say the request is wrong and offer the hostname alternative.
4. Build the uninstall routine first — unload the daemon, remove the launch
item, delete the filter profile, restore my DNS — then the off switch,
verified on a machine with no network.
5. The privileged component does one job: apply a ruleset, report status.
UI, scheduling and list editing run unprivileged.
6. Sign every update and verify it inside the helper. An auto-updating root
daemon with an unverified channel is a backdoor I built myself.
7. Fail open. If rules cannot be loaded, stop filtering loudly rather than
blocking everything silently.
8. Keep a permanent allowlist — employer VPN, MFA provider, bank — that
cannot be blocked by accident, and refuse a block-everything mode that
ignores it.
9. Everything stays on the device: no sync, no analytics, no crash reports
carrying domains. Tell me why my blocklist is worse to leak than my
history.
10. Out of scope, and say so plainly: mobile app blocking needs an Apple
entitlement I do not have, and this must never go on anyone else’s
device.
11. Finish by telling me what Freedom costs monthly and that the mobile half
is the part I cannot build at any price.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The moment you want it on a phone. Freedom's iOS blocking rests on an Apple entitlement and a Screen Time integration that you cannot replicate as an individual developer, which makes the mobile half not hard but unavailable — and mobile is where the distraction lives. Nine dollars a month, or a hundred once, buys the two things you cannot build: the entitlement, and someone whose job is to fix it the week after each OS release breaks it. Build the desktop hosts-file version for free if you like the ritual; just do not pretend it is enforcement.
$8.99/mo is cheaper than your weekend.
Uninstalling this is not deleting an app, and that is the whole point of writing an exit plan for it. Ship a removal routine and test it before you ship the blocker: unload the daemon, remove the launch item, delete the VPN or filter profile, restore the DNS settings you overwrote, and — if you ignored the advice above — remove the certificate from the trust store and check it is actually gone rather than merely untrusted. Keep the blocklist as a plain text file so leaving costs you nothing but the file. Then rotate any credential you used while a TLS-terminating proxy of your own construction was in the path, because you cannot prove what it logged.
Free macOS blocker that has solved the hard part — a timer you genuinely cannot cancel, surviving restarts and app deletion.
Network-level DNS sinkhole, which is the blocking layer that does not require a privileged agent on every device.
Questions
Why is a personal productivity app YOUR FUNERAL when the only victim is me?
Because of what you install to make it work, not what it blocks. The band is about a failure that lands on someone who did not choose the code, and that includes your own future self at an inconvenient hour. A root daemon with an unverified update channel and a certificate authority in your trust store is a permanent, invisible security cost carried by the machine you do everything else on. The Transmit entry sits in the same place for the same reason: local software can still be the most dangerous thing you run.
Is the certificate authority really likely, or is that a hypothetical?
It follows directly from a feature request you will make in week two: 'block youtube.com/watch but allow the rest of the site'. Hostnames are visible in a TLS connection; paths are not. The only way to see the path is to terminate the connection, and the only way to terminate it without warnings is to be a trusted CA on that machine. An agent asked for URL-level blocking will reach for mitmproxy and a generated root cert, and it will work on the first try, which is exactly the problem.
What about just using Screen Time or Digital Wellbeing?
Genuinely a good answer, and the one this entry keeps arriving back at. Both are free, both are already privileged, and neither requires you to run anything. What the paid products add is cross-device sessions and a lock that is harder to argue with. If your honest requirement is friction rather than enforcement, the built-in tool plus a browser extension covers it, and nothing on this page applies to you.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Apple hands you the blocking API, then refuses to let your own app read the usage behind it.
The timer is four lines. The unbroken history across three devices is the product, and that's a sync engine.
A launcher is a fuzzy search over things you already have. Nothing here can hurt you.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice