Transparent telemetry for open-source projects
There&#x27;s a lot of confusion in these comments about opt-out vs opt-in. The debate isn&#x27;t settled, but a lot of the issues raised here have been addressed. Reposting Russ&#x27; comment:<p>&gt;Longer answer about opt-out generally, copied from mail I sent to golang-dev.<p>&gt; I wrote a little about this at <a href="https:&#x2F;&#x2F;research.swtch.com&#x2F;telemetry-design#opt-out" rel="nofollow">https:&#x2F;&#x2F;research.swtch.com&#x2F;telemetry-design#opt-out</a>. Just to quote the beginning:<p>“An explicit goal of this design is to build a system that is reasonable to have enabled by default, for two reasons. First, the vast majority of users do not change any default settings. In systems that have collection off by default, opt-in rates tend to be very low, skewing the results toward power users who understand the system well. Second, the existence of an opt-in checkbox is in my opinion too often used as justification for collecting far more data than is necessary. Aiming for an opt-out system with as few reasons as possible to opt out led to this minimal design instead. Also, because the design collects a fixed number of samples, more systems being opted in means collecting less from any given system, reducing the privacy impact to each individual system.”<p>&gt; To elaborate, one of the core things I believe about designing a system like Go is that it needs to ship with the right defaults, rather than require users to reconfigure the defaults to get best practices for using that system. For example, Go ships with use of the Go module mirror (proxy.golang.org) enabled by default, so that users get more reliable builds out of the box. Similarly, Go ships with the use of the checksum database also enabled by default, so that users get verified module downloads out of the box. We know that most users don&#x27;t want to and probably won&#x27;t spend time reconfiguring the system: they trust us to set it up right instead. Of course, that implies a responsibility to actually look out for users&#x27; best interests, and we take that very seriously. There are important privacy concerns about the module mirror and about the checksum database, despite their clear benefits, so we designed those systems to address as many of those concerns as possible. Among the decisions we made to improve privacy there: (1) GOPROXY can proxy both the module mirror and the checksum database, (2) we published a very clear privacy policy (proxy.golang.org&#x2F;privacy), (3) we introduced the concept of a tiled transparency log to keep log fetches from exposing a potential tracking signal.<p>&gt; Moving back to telemetry, enabling telemetry does not confer the same kind of direct benefits to users as the module mirror and the checksum database do. Instead the direct benefits it confers fall on other users: (1) allowing your Go installation to participate in the system means other installations participate just a little bit less, thanks to sampling, and (2) allowing your system to send usage information strengthens the signal from others with similar usage. There is still an important indirect benefit: one system opted out won&#x27;t have much of an impact, but 99% of systems opted out has a huge impact, and that leads to mistakes like the ones I mentioned in the first blog post, which do make Go worse for you.<p>&gt; Like with the module mirror and checksum database, there are good privacy concerns to telemetry despite the clear benefits, so the design of transparent telemetry aims to address as many of those as possible. The bullet list in the GitHub discussion (also at the end of the blog post) enumerates the most important ones.<p>&gt; Most people leave defaults alone or make intuitive guesses about what they want. That&#x27;s totally reasonable: no one wants to spend half an hour learning the details of each specific setting. But my goal for the system is that if I did spend half an hour explaining how the system worked, then the vast majority of users would agree with the default and see no reason to opt out. Of course, some people will always opt out on general principle, and perhaps there are others who would opt in to some systems but not this one. For those people, my goal is simply to make the opt-out as easy and effective as possible. That&#x27;s why opting out is just an environment variable (GOTELEMETRY=off) or a single command (go env -w GOTELEMETRY=off), and there&#x27;s a quiet period of at least a week after installation to give plenty of opportunity to opt out before there&#x27;s any chance of data being sent.<p>&gt; I expect that this will not change your mind, and that you and a few others will still believe the telemetry should be opt-out. I accept that: I don&#x27;t expect to convince everyone about this point. But I hope this helps explain how I am thinking about the decision.