Telemetry needs a user-controlled data budget

I keep wishing Linux and self-hosted software treated telemetry like a user-controlled data budget. Collect locally by default, show me the categories and storage cost, expire raw events quickly, and send only aggregates I explicitly approve. A crash report might deserve different consent from usage counts, abuse signals, or performance timings.

I understand why small open-source projects need evidence. A stack trace and a few timing measurements can turn “it crashes sometimes” into a fix, but building privacy-preserving infrastructure is expensive. “Anonymous” also makes me wary when a persistent installation or client identifier can connect activity over time; the label does not describe the whole risk.

Would a clear local dashboard, per-feature consent, visible retention deadlines, and automatic expiration be a better compromise than a single switch or a buried opt-out? Disagree, share tools or examples, or propose a better design.

The dashboard matters more than the slogan. I would want the exact outbound payload, identifiers included, destination, and deletion date—not merely “telemetry enabled.” Per-feature consent also prevents a crash-reporting need from becoming permission for behavioral profiling.

As the person who has to fix the bug, I’d take an opt-in crash bundle over a beautifully designed dashboard nobody opens. The useful part is often the stack trace plus environment, not an aggregate. Maybe make the failure prompt concrete: “send this one report,” with redaction visible.

The Firefox example is instructive here: crash pings can contain annotations and stack traces, while other pings include environment and measurement data. That supports separating feature consent rather than debating “telemetry” as one indivisible thing.

A local budget is not automatically a privacy boundary. If the dashboard itself exports identifiers, or a supposedly aggregate report has a tiny cohort, the user still needs threat-model information. I’d add minimum-group thresholds and a hard “never send raw events” mode.

I like automatic expiration, especially for self-hosted installs where nobody remembers old logs. But please include an export button before deletion. Customers often discover the valuable diagnostic detail after the retention timer has done its job.

“Anonymous” has become a decorative adjective. If an installation ID survives upgrades, it is anonymous only in the narrow sense that nobody typed your name into the field.

The operational wrinkle is support. If raw data expires locally and nothing leaves automatically, maintainers need a clear recovery path: reproduce, inspect, then voluntarily attach the relevant window. That is slower, but at least the trade is visible instead of silently permanent.

I’d model it like a local queue with a lease: events stay on-device, are summarized after a short period, and become eligible for export only under a named policy. Policies should be versioned, so an update cannot quietly reinterpret old consent.

The danger is consent fatigue. Per-feature switches can become twenty prompts and nobody reads them. A good default might be a small number of understandable bundles, expandable into details, with one-click review rather than a privacy control panel that feels like tax software.

Aggregates won’t diagnose latency regressions when the interesting variable is the interaction between hardware, workload, and version. I’d keep a bounded local ring buffer and let users attach it to a bug report. That gets engineers detail without making collection continuous.

I’m not convinced “local by default” works for abuse prevention. By the time a maintainer sees an incident, the relevant evidence may be gone. A narrowly defined, separately disclosed security signal could justify immediate export, but it should not be smuggled into general analytics.

Infrastructure cost is real. Self-hosted Sentry documentation alone makes the storage tradeoff obvious: retention consumes disk, and longer retention costs more. Small projects should be allowed to say, “we can support seven days of diagnostics,” instead of pretending unlimited history is free.

The wording will decide whether this succeeds. “Help improve the project” is vague; “send 14 crash events, including OS version and stack traces, expiring after 30 days” is an actual choice. Users can handle a tradeoff when the interface admits there is one.