A local, portable budget for algorithmic feeds

I’d like to see a local “scroll session budget” that browsers or operating systems expose to compatible feed apps. The device would track time spent in algorithmic feeds and publish only a coarse state—say, okay, warn, cooldown, or stop—not URLs, app names, timestamps, or a behavioral history. The app could then insert a pause or stop point without reporting attention data to the platform.

The useful part is portability: the same user-controlled signal could work on a phone, desktop, or VR client instead of being rebuilt per app. Existing activity controls show that on-device measurement is feasible, though today’s interfaces are fragmented.

My hesitation is that friction can become irritating paternalism. A warning might interrupt autopilot; a hard stop might just send me to another browser or an incompatible client. Would a voluntary, transparent standard help, or would it mostly become another setting people disable?

The signal is the easy part. Defining “algorithmic feed” is harder, especially in a browser where a page can mix articles, comments, and an infinite timeline. I’d make the client declare a feed session explicitly, with the user able to correct it. No declaration, no budget burn.

I’d avoid the word “stop” in the default vocabulary. “You have five minutes left” and then a deliberate resumption button creates a social pause without pretending the interface knows what is good for you. The moment the product sounds like a guardian, people will resist it.

The privacy boundary needs to be enforceable, not just promised. A shared state should be local, inspectable, and opt-in, with no remote sync unless the user explicitly chooses it. Even coarse states can become sensitive if an app can query them constantly and correlate the answers.

The evidence supports feasibility more than effectiveness. Apple’s device-activity tools can trigger thresholds with authorization, and Android exposes usage statistics, but that does not establish that a cross-platform budget reduces scrolling. The limited intervention studies described so far also report frustration and context-dependent responses.

Cross-device use is where this gets interesting. I would sync a signed budget token, not an activity log: remaining allowance, expiry, and the user’s policy. That still raises trust questions, but it avoids building a diary of where and when someone looked at a feed.

Compatible apps are the commercial problem. A feed that benefits from uninterrupted sessions has little reason to honor the stop state unless users, app stores, or browsers make compliance visible. Voluntary standards can work, but only when the incentive is not purely altruistic.

People already have timers. The proposed improvement is portability, not novelty. I’d be happy with a boring shared protocol that says “pause now,” provided it doesn’t turn into a dashboard, account, subscription, or wellness-themed notification center.

As an app developer, I’d want a tiny API: query state, receive a state-change event, show my own pause UI. No permission to inspect what else the user does. If the standard requires a full taxonomy of feeds and synchronized identity, small clients will skip it.

Bypassability is not necessarily failure. A speed bump can still help when someone is acting automatically, even if they can walk around it. The mistake would be measuring success as perfect compliance rather than whether the interruption is useful in the moment.

Support would be full of “why did my feed stop?” tickets unless the state is extremely legible. Users need to see which device owns the budget, when it resets, and how to override it. Otherwise a portable standard creates portable confusion.

I’d keep enforcement outside the app where possible. If the app is allowed to report its own feed time, a bad client can simply label everything something else. A browser or OS can measure active use more consistently, but Linux desktops do not currently offer one unified interface for this.

There is an incentive mismatch here that no protocol fixes. Platforms monetize additional sessions; users may value an interruption later than they value the uninterrupted session now. A local standard can shift control, but it cannot make every participant want the same outcome.

I’d use it if the default were gentle and the override took one click. Anything that locks a customer out of a service becomes a support and accessibility headache. The best version feels like a personal preference shared between my devices, not a rule imposed by an app.

The minimum viable version is probably a browser extension plus a simple local protocol, not a grand OS standard. Test whether people keep it enabled, whether apps integrate, and where false positives happen. If those numbers are poor, standardizing the abstraction won’t rescue it.