Go accepts telemetry with explicit consent and public collection rules

Go's telemetry proposal changed its default before the proposal review group accepted it. Russ Cox's original February design enabled collection by default, with an opt-out. Community discussion led him to revise that choice to explicit opt-in. The April 12 acceptance approves the revised proposal and makes the issue a tracker for implementation. It does not announce a released telemetry system.

The interesting engineering question is how much information a toolchain needs to make better maintenance decisions. A bug report can describe a failure someone recognized. It is a weaker way to discover that many users encounter slow builds without knowing those builds are unusually slow. The proposal argues that surveys and bug reports leave some usage and performance questions unanswered.

I am sympathetic to that problem because Go's value depends heavily on the quality of its tools. Improving those tools requires evidence about how they behave outside the maintainers' own environments. The accepted design is worth examining because it tries to make that evidence collection specific enough for users to inspect.

Consent changes the design's operating assumptions

In the February 24 revision, Cox explains why he changed the default. Feedback favored opt-in, including from people who considered the proposed collection reasonable. He also raised the possibility that Go's opt-out decision might justify less careful collection elsewhere. Consent became an explicit requirement without expanding the information requested.

That last choice matters. An opt-in checkbox can become an excuse to collect everything a user has nominally authorized. Cox rejects that approach in the revision. The intended purpose remains a limited set of measurements that can inform development decisions. Agreeing to participate does not eliminate the need to justify each collected metric.

Opt-in also changes the statistical situation. A system can only sample from installations that participate. Fewer participants require each participant to report more often to obtain the same number of reports. Cox's revision describes that increased reporting burden as a cost of the change, even though the contents of each report remain restricted.

It also introduces selection bias. People who read release notes or encounter an invitation in an editor may participate at different rates from people who install Go through a package manager. If those groups differ in a characteristic being measured, the collected distribution can differ from the whole user population. More precise sampling within the participating group does not automatically correct that difference.

The proposal discusses comparing technical demographics against developer surveys to identify skew. That is a limited claim about interpretation. Telemetry can provide useful evidence without becoming a complete census of Go installations, and a decision still needs context about which users the evidence may miss.

Weekly counters restrict what can be reconstructed

The design document begins with counters maintained locally by toolchain programs. A named counter increments when an event occurs. Counts accumulate in weekly files, so the reported unit is a total for a period, without an ordered sequence of individual events.

This distinction constrains the questions the system can answer. A histogram of build-cache miss rates can describe how often invocations fell into particular buckets. It does not require uploading the command line for every build or the files that build touched. The aggregation removes detail before reporting, which also limits the detail available for later analysis.

The proposed implementation stores counters directly in a memory-mapped file and uses atomic operations to update them. It does not first create a detailed event log and then summarize that log for upload. That choice reduces local storage and update costs while avoiding a richer local record whose existence would need its own justification.

A weekly total still conveys information. The privacy argument is about limiting that information to the measurement's purpose, rather than claiming that aggregation makes every observation meaningless. Knowing the count associated with a rare configuration can have implications even without a name attached. Cox's opt-in revision acknowledges concerns about identifying an installation through an unusual combination of characteristics.

I prefer this explanation to a broad claim that anonymous telemetry has no privacy cost. The design describes specific omissions and the remaining limits. That gives a user something concrete to evaluate when deciding whether to participate.

Public metrics determine upload configuration

The proposal puts another restriction between local counters and uploaded reports. A publicly reviewed configuration defines the metrics the project intends to publish. The reporting configuration derives the exact required counters and their sampling rates from those metrics. Local collection does not automatically authorize uploading every locally available counter.

The design illustrates the consequence with import paths. A counter that incorporated an arbitrary package path could record a private module name locally. The upload configuration would still need to list that exact counter before reporting it. The configuration does not permit a wildcard request for every counter with a chosen prefix.

That is a meaningful restriction on accidental disclosure. A newly introduced local counter does not silently become an unrestricted string channel to the server. Public review of the reporting configuration provides a separate opportunity to reject an inappropriate name or metric. The proposal still depends on correct implementation and review, but the stages have distinct responsibilities.

Configuration travels as a cacheable Go module with a tamper-evident log. Existing module proxies can therefore mediate the configuration download. The log also makes it harder to quietly serve a special collection configuration to a selected installation. Transparency here concerns what clients have been instructed to report, in addition to the source code implementing the instruction.

This makes the configuration part of the system's public contract. A metric needs an explanation for why its counters are necessary. Removing a counter from configuration stops its reporting under the proposed model, even when older tool binaries still know how to count the event locally.

The proposal also gives a numerical sampling target of roughly 16,000 reports for one-percent accuracy at a 99-percent confidence level. That target concerns the accuracy of a sampled measurement under its assumptions. It does not mean that sampling one percent of installations automatically produces one-percent accuracy, and it does not eliminate participation bias. As the participating population grows, a fixed target number of reports can be obtained by asking any individual installation to report less often.

Reports avoid persistent identifiers

The accepted proposal says reports contain no user or machine identifiers. Uploaded strings must already be known to the collection system, such as configured counter names and tool versions. Reports can also include stack information from specified unmodified toolchain programs, where the function names are known in advance.

That qualification on stack collection is important. Arbitrary application stacks could contain private package names. The design instead limits the relevant programs and versions, and identifies frames using import paths with function-relative line information. It is intended to describe the toolchain's own execution without collecting the path where a user checked out its source.

The upload connection necessarily exposes an IP address to the receiving server. The proposal says the server does not record that address with reports. That statement describes an operational and implementation obligation. Removing identifiers from the JSON alone cannot prevent the network endpoint from observing connection metadata.

Reports combine selected counters for the week without a persistent key linking one week's upload to another. The design also preserves an inspectable local representation of the JSON sent. This gives participants a way to examine the actual report, alongside the public rules that determined which counters it could contain.

Publication makes the evidence independently available

The proposal requires publication of both computed metrics and the raw collected reports. Maintainers do not receive a private dataset unavailable to other contributors. An outside participant can examine the same reported observations and question the conclusions drawn from them.

That publication increases the importance of restraint before upload. Once raw reports are public, the collection system cannot rely on keeping them within a trusted analysis group. The limits on strings and identifiers must therefore apply before the data reaches publication. Public access is useful for accountability precisely when the published material has been selected for that role.

My support for opt-in telemetry depends on these continuing constraints. Consent answers whether a particular installation participates. Public configuration answers which counters the project may request, and publication lets others inspect the resulting evidence. Acceptance gives the implementation work a defined set of obligations, including the default-off behavior that emerged from the discussion.