Should apps have a weekly telemetry budget?

Consumer apps should offer a user-configurable telemetry budget: a hard weekly limit on behavioral events, interaction timings, device signals, and metadata. More importantly, the SDK should enforce it at the source by allow-listing, aggregating, sampling, or discarding data before it reaches a server—or ideally before it is stored locally. Uploading everything and promising to filter it later is not much of a privacy boundary.

The trade-offs are real. Hard limits can remove the timing and rare context needed for debugging, reduce security and fraud signals, and make recommendations less precise. OpenTelemetry already provides building blocks such as aggregation, sampling, cardinality limits, and dropping, but mainstream app controls are generally disclosures by category, not a user-set weekly quota.

Would a strict collection budget meaningfully curb surveillance capitalism, or just make profiling less convenient? I’m especially interested in tools or architectures already doing data minimization this way.

The hard part is defining what counts. One coarse tap event and one high-resolution location sample are both “events” only if we ignore their information content. I’d want weighted budgets by sensitivity and cardinality, with aggregation happening before durable storage. Otherwise this becomes a neat number attached to a bad abstraction.

I would not make security exceptions invisible. Account takeover detection may need signals the user’s normal personalization budget would reject. That does not justify unlimited collection, but it does mean the system needs a disclosed security lane, strict retention, and an audit trail rather than a magic quota that claims to cover everything.

From a product angle, a quota could be a useful trust control, but most users will not tune twenty counters. A few modes—minimal, balanced, diagnostic—would probably get adoption. Recommendation quality is the easy argument against this because it is visible; the harder question is whether the extra quality is worth the permanent data exhaust.

The evidence supports the narrower claim that minimization reduces what a particular app can collect. It does not establish that quotas would reduce surveillance capitalism overall. A company could compensate with longer retention, inferred attributes, cross-service identifiers, or required account data. Useful policy, not a complete theory of the market.

This fits local-first design better than the usual consent dialog. Keep counters and aggregate state on-device, export only approved summaries, and make deletion happen before logs or backups can capture raw events. The SDK could expose a budget interface, but the operating system is probably the only layer that can stop every embedded SDK from freelancing.

A strict quota may simply move the contest upstream. If personalization is valuable enough, apps will ask for more permissions, make collection part of the service, or collect fewer but more identifying signals. Still, reducing raw event volume could raise the cost of profiling, which is not nothing—it just should not be sold as a cure.

I’d start with boring controls: attribute allow-lists, bounded cardinality, early sampling, and a kill switch that actually drops data. OpenTelemetry has pieces of this already, though not a consumer weekly budget. If anyone has shipped the full loop—visible quota, source-side enforcement, and usable debugging mode—I’d like to see the design.