Google plans to add telemetry gathering to the Go programming language toolset and to enable data collection by default. The telemetry will cover command-line tools developed by the Go development team, such as the 'go' utility, compiler, and applications gopls and govulncheck. The data collection will be limited to gathering information about the operational features of the tools, meaning that telemetry will not be added to user applications built with the toolset.
The motivation for collecting telemetry is to gain information about the needs and operational characteristics of developers that cannot be captured through feedback methods like bug reports and surveys. Collecting telemetry will aid in identifying anomalies and unusual behavior, assessing developers' interaction with the toolset, and understanding which options are most popular and which are hardly used. It is expected that the accumulated statistics will enable modernization of the toolset, improve efficiency and usability, and emphasize the features that developers most need.
A new architecture called 'transparent telemetry' has been proposed for data collection, aimed at enabling independent public auditing of the data collected and gathering only the minimally necessary aggregated information to prevent leaks of detailed user activity data. For example, when assessing the traffic consumed by the toolset, metrics such as the total data counter in kilobytes for the entire year will be considered. All collected data will be published openly for inspection and analysis. To disable telemetry sending, you need to set the environment variable 'GOTELEMETRY=off'.
Key principles of transparent telemetry construction:
- Decisions on the metrics to be collected will be made within an open public process.
- The configuration for collecting telemetry will be automatically generated based on a list of actively monitored metrics, without collecting data unrelated to these metrics.
- The telemetry collection configuration will be managed in a transparent audit log with verifiable records, complicating the selective application of different collection settings for different systems.
- The telemetry collection configuration will be designed as a cacheable proxyable Go module that can be automatically applied in systems that already use local Go proxies. The telemetry configuration download will be initiated no more than once a week with a 10% probability (i.e., each system will download the configuration about 5 times a year).
- The information sent externally servers will only include aggregated counters, reflecting statistics over a full week and not tied to specific times.
- The sent reports will not include any forms of system and user identifiers.
- The reports sent will contain only strings that are already known to the server, such as counter names, standard program names, recognized version numbers, and function names in built-in toolkit utilities (when sending stack traces). Non-string data will be limited to counters, dates, and line counts.
- an IP address Requests made to telemetry servers will not be logged.
- To obtain the necessary sample, it is planned to collect 16,000 reports per week, which under the condition of having two million tool installations will require sending reports from only 2% of systems each week.
- The collected metrics in aggregated form will be publicly published in graphical and tabular representations. Complete raw data accumulated during the telemetry collection process will also be published.
- Telemetry collection will be enabled by default but a simple way to disable it will be provided.
Source: opennet.ru
