Deep work / comparison

Goal based blocker or timer: what should a session protect?

A timer measures time. A blacklist removes known temptations. A goal based allow list gives the time a particular route. Choose the tool according to the problem you want to solve.

Focus timers are popular because time is easy to see. Twenty five minutes passes, then a bell rings. That can help a person begin. It does not say what the time is for, which pages belong, or why a new tab should wait.

A blocker answers a different question. It changes access. A blacklist says these known sites should be unavailable. An allow list says these are the sites that can support this result. Neither choice is always right. The task decides.

What a timer protects

A timer protects a container of time. It can create a start and an end, and it can make a large task feel finite. This is useful when the main problem is beginning or when you want a short experiment. A timer can sit beside a paper, an editor, or a browser without changing the route.

Its weakness is that access remains open. If the first tab becomes hard, a person can look for an easier one. The timer continues while the task changes. That is not a failure. It is simply what a timer measures.

Use a timer when you need a period of attention and the work is broad. Research, planning, and early discovery often need the web to stay open. If a timer is enough, use it. A more forceful tool can add friction where the task needs range.

What a blacklist protects

A blacklist protects against known sinks. You name the sites that reliably swallow time and keep the rest of the web available. It is a good model for a workday with changing obligations. Block social feeds, short video, and shopping, but keep search, documentation, and customer systems reachable.

A schedule can make a blacklist repeat. StayFocusd describes daily time limits, automatic schedules, complete blocking, and a stricter Nuclear Option. Cold Turkey describes continuous and scheduled blocks, multiple lists, and optional allowance rules. These tools suit people who want a recurring rule rather than a new route for every task.

A blacklist can become noisy if you keep adding exceptions. That is a signal to ask whether the task is actually bounded. If the answer is yes, an allow list may be simpler.

What an allow list protects

An allow list protects one route. It starts with a result and asks which domains can support it. An online course may need a lesson page, a repository, and a deployment preview. A writing session may need a document editor and two sources. Everything else can wait without being declared evil.

Focusward uses this model in Chrome. You state the goal, choose the domains, choose a duration and strictness, and start. During the session, navigation outside the route is redirected to a page that keeps the goal visible. The extension has no break function. The session stays active for its chosen duration.

An allow list is strongest when the work graph is known. It is less useful when discovery is the work. You can widen the route, but each new domain should be a deliberate decision rather than a reflex.

Goals give the rule a reason

A goal is more than copy above a timer. It is a test for whether a page belongs. Finish my deployment task can become inspect the build error, fix the environment variable, and check the preview. The route now has a repository, documentation, and a deployment dashboard. A broad feed has no role.

Research on goals supports narrow claims. A 2024 study of sustained attention found that specific, difficult goals reduced long response time lapses in a four choice reaction task. The task was a laboratory measure. It does not show that an extension reproduces the effect. It does suggest that a more specific goal can be easier to act on than a vague command.

Implementation intentions add an if then link. If I start the deployment task, then only GitHub, documentation, package registry, and Vercel remain open. Sheeran, Webb, and Gollwitzer found that implementation intentions helped goal attainment when the underlying intention was strong. Planning is useful. It is not a guarantee.

Three simple choices

Choose a timer when:

• The task is broad or exploratory.
• You need a start and end more than a change in access.
• You can trust the current browser route.

Choose a blacklist when:

• You know the few sites that consume time.
• The day has changing research or support obligations.
• A recurring schedule is useful.

Choose an allow list when:

• The result is clear and the work graph is small.
• Voluntary tab switching is the main problem.
• You want the browser to show what belongs before the session starts.

Use a finite session and a review

Choose a duration that matches the result. Do not use a long session to prove seriousness. Start with the first concrete action. At the end, write what changed. If the result is incomplete, decide whether the route was wrong, the duration was wrong, or the task needs more preparation.

Do not turn the end of a session into a test of endurance. Focusward does not include breaks, but the rest of your working life still needs sensible stopping points. A timer, a blacklist, or an allow list should serve the work rather than become the work.

Review the cost of each model after the session. A timer has almost no setup, but it may leave every route open. A blacklist asks you to know the main sinks and maintain them. An allow list asks you to define the work graph and to handle new domains with care. There is no free boundary. The question is which decision you prefer to make before the work begins.

Check the permission story as well. Chrome explains that host permissions can allow an extension to inspect sensitive tab properties and redirect or modify requests through declarative rules. A blocker should say what it stores and why. The browser boundary is not a reason to hide browsing history in a remote service.

Use the model that leaves the real work visible. A student may need the course, repository, and documentation. A writer may need a source archive and a document. A developer may need GitHub, an issue tracker, and a deployment dashboard. If the model hides one of those, it is protecting the wrong thing.

Test the model with one ordinary task. Write a result, choose the route, set a finite duration, and notice the first moment you wanted to change pages. At the end, keep the boundary if it helped the route stay clear. Change it if it made the work brittle. That small experiment is more useful than a universal promise.

The useful answer

A timer protects time. A blacklist protects against known sinks. An allow list protects a specific route. Start with the problem in front of you. If the browser needs a reason to stay small, give it a goal. If it needs room to discover, leave it room.