What telemetry actually sends, and why software collects it

There is a short answer about telemetry and a useful one, and they are not the same. What follows is the useful one.

Three different things wear the same name

Crash reporting captures the state of a program when it failed, which may include memory contents and file paths containing your name. Usage analytics records which features were used, in what order and for how long, usually tied to a device or installation identifier.

Performance monitoring records timings and resource use, which is generally the least sensitive of the three. Settings frequently bundle them together, which prevents the sensible choice of allowing one and refusing another.

Why developers want it

Without usage data, decisions about what to build rest on the loudest feedback rather than on what people do. Crash data reveals failures that users never report, and a defect affecting a fraction of a per cent of launches is invisible any other way. Performance data reveals which real-world configurations are slow, which laboratory testing does not reproduce.

The short version: these are legitimate engineering needs rather than a pretext, which is why the argument is about scope rather than existence.

The difference between aggregate and identified

A counter recording that a feature was used ten thousand times reveals almost nothing about any individual. A stream of timestamped events tied to a stable identifier is a behavioural record and is a fundamentally different thing.

Techniques that add calibrated noise to individual reports so only population statistics are recoverable are deployed by several large platforms. Differential privacy of this kind is a genuine mathematical guarantee whose strength depends on parameters that are not always published.

What leaks unintentionally

Crash dumps have been found to contain document contents, file names, credentials held in memory and search queries. Error messages and stack traces routinely include file paths containing user names and directory structures. Screenshots attached to feedback reports capture whatever else was on screen.

These are accidents of implementation rather than intent, and they are common enough to assume rather than doubt.

Consent regimes and their limits

Several data protection regimes require a lawful basis for collection and treat some telemetry as requiring consent rather than legitimate interest. Enforcement has focused on whether consent was freely given and whether refusing was as easy as accepting. Operating systems increasingly present a choice at first setup, where almost everybody accepts the default.

Requirements vary substantially by jurisdiction, so what is offered depends partly on where the device thinks it is.

Implementations differ, and vendors are not obliged to document the differences.

Reducing it in practice

Review the diagnostics settings on your operating system, browser and major applications once, since defaults differ and change between versions. Prefer basic or required-only levels where offered, which usually retains security-relevant reporting. Network-level blocking of known telemetry destinations is possible and can break software in ways that are hard to diagnose.

Reset advertising identifiers periodically, since those are what allow separate collections to be joined.

The takeaway

Aggregated counts are cheap to give away. Identified event streams are a different transaction entirely.

The constraint is almost always physical, and marketing rarely mentions which one.