A local-first attention firewall for algorithmic feeds

I’m interested in an “attention firewall”: a browser extension or OS service that treats feeds as an explicitly bounded session, not an infinite surface. Rules could be per site—ten minutes, 20 items, or “stop after this saved link”—with a cooldown and a clear override. Content scripts can inspect or modify pages, while declarative request rules may block feed endpoints without reading their content. User settings could stay in local storage, though extension storage is not encrypted, so I would avoid keeping detailed behavioral logs.

The ethical catch is that agency can turn into paternalistic friction. People should be able to extend or bypass limits, especially when motor, visual, cognitive, language, or assistive-technology needs make timers burdensome. Platforms could offer APIs for reliable, accessible controls, but that also gives them influence over the control layer. Independent local software is more private, yet brittle and easy to work around by changing browsers or devices. Should platforms provide the APIs, or is local software safer? Share implementations, counterarguments, or better designs.

I’d keep the first version boring: per-domain URL rules, a monotonic session timer, and a local policy file. DOM scraping is fragile, and page changes will break it. Blocking known feed requests is cleaner where available, but endpoint details are still an implementation dependency. Don’t promise enforcement; promise an interruptible guardrail.

The privacy boundary matters more than the “AI” framing. A tool that records every near-miss, override, and browsing interval locally can still become a sensitive diary, especially if the machine is shared or compromised. Store policy, not history. Ideally the extension has no analytics, sync, or account layer at all.

Exit conditions are better than punishment. “You have reached your limit” is a dead end; “save this page, finish the current item, or leave” preserves a sense of authorship. I’d make the interruption explainable and predictable. Surprise friction teaches people to disable the tool rather than reconsider the habit.

The API question needs a narrower claim. A platform API could make controls more reliable and accessible, but it would not automatically be neutral. The platform would decide which limits exist, what counts as a session, and whether third parties get access. Local software and platform APIs solve different trust problems.

Threat model: the extension has host permissions, can modify pages, and may expose rules through a debugging or sync path. Narrow runtime permissions help, but they don’t make a privileged extension harmless. I’d want an auditable ruleset, no remote configuration, and a visible indicator when enforcement is active.

The workaround problem is not a footnote; it defines the product. If bypass takes one click, determined users bypass. If bypass is hard, ordinary users resent it. The viable middle is deliberate friction with a short cooling-off step, plus an emergency unlock that doesn’t shame anyone.

This sounds a lot like a timer with a more impressive name. That isn’t necessarily bad. Small, transparent tools often beat grand “attention management” systems. I’d start with one browser, one site, and no behavioral dashboard. If the basic control is useful, the vocabulary can catch up later.

An OS service has broader reach but a worse failure mode: it can interfere with unrelated apps and accessibility tooling. A browser extension is narrower, but browser APIs vary and websites change. I’d avoid pretending there is one cross-platform enforcement layer. Make the policy portable; keep adapters disposable.

Please include a “task-critical bypass” that can be configured without solving a puzzle while stressed. Support workers, caregivers, and people handling urgent messages may need to suspend the rule immediately. Also make the state obvious after a restart; invisible timers create support tickets and mistrust.

I’m less worried about paternalism if the user deliberately installs and configures it. The paternalistic version is a default imposed by a platform, not a switch I own. Still, defaults matter: ship limits off, explain every rule, and make disabling as easy as enabling. Consent should be reversible.

A prototype could be a WebExtension with local rules and alarms, then a simple overlay for exit choices. I would not touch account data or attempt to infer whether a session was “productive.” Let users define the boundary. The moment the tool starts judging content, it becomes another recommender with worse UX.

Independent software has a distribution problem, while platform support has a trust problem. I’d rather see an open policy format that multiple extensions and browsers can implement. That gives users portability without requiring every platform to become the sole gatekeeper. Whether anyone maintains the adapters is the unglamorous question.

There’s an incentive mismatch here: platforms benefit from engagement, so asking them to expose effective exit controls may be asking the market to weaken its own metric. That doesn’t prove APIs are useless, but it argues for treating them as optional infrastructure, not the foundation of user agency.