Go and telemetry

4,247 views
Skip to first unread message

Russ Cox

unread,
Feb 8, 2023, 8:15:50 AM2/8/23
to golang-dev
Hi all,

I'd like to start a conversation about Go and telemetry and wanted to make sure people here saw it. I've published a blog post and a GitHub discussion. Please see those for more information.

Best,
Russ

Jan Mercl

unread,
Feb 8, 2023, 8:47:01 AM2/8/23
to Russ Cox, golang-dev
On Wed, Feb 8, 2023 at 2:16 PM Russ Cox <r...@golang.org> wrote:

> I'd like to start a conversation about Go and telemetry and wanted to make sure people here saw it. I've published a blog post and a GitHub discussion. Please see those for more information.

I have skimmed the first blog post and I agree with most of it and I
like the approach. Except for, as you may expect:

"The system is on by default, but opting out is easy, effective,
and persistent."

Opt out is a non-starter for me, sorry.

Russ Cox

unread,
Feb 8, 2023, 10:02:53 AM2/8/23
to Jan Mercl, golang-dev
Hi Jan,

Thanks for the feedback around opt-in versus opt-out. I wrote a little about this at https://research.swtch.com/telemetry-design#opt-out. Just to quote the beginning:

“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.”

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't want to and probably won'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' 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/privacy), (3) we introduced the concept of a tiled transparency log to keep log fetches from exposing a potential tracking signal.

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'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.

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.

Most people leave defaults alone or make intuitive guesses about what they want. That'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's why opting out is just an environment variable (GOTELEMETRY=off) or a single command (go env -w GOTELEMETRY=off), and there's a quiet period of at least a week after installation to give plenty of opportunity to opt out before there's any chance of data being sent.

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't expect to convince everyone about this point. But I hope this helps explain how I am thinking about the decision.

Best,
Russ

Yissakhar Beck

unread,
Feb 8, 2023, 2:50:07 PM2/8/23
to golang-dev
Instead of opting out, why not require the variable to be set? Maybe print a warning on any use of the `go` command if `GOTELEMETRY` isn't set explicitly that the user needs to set it to either `on` or `off` with example commands for how to do so using `go env -w`.

stephen.t....@gmail.com

unread,
Feb 8, 2023, 2:52:09 PM2/8/23
to golang-dev

Hello,

I can see the benefit of this and the design is interesting. What concerns me is that the results you receive will be skewed towards installations that build often.

The use case that interest me is (from the third blog post)


For example, I develop on one architecture/os and I provide the source for people to build the binaries for their own machines. Those people do that three or four times a year, maybe. From what I can see, the chances of those builds being caught by the telemetry system is quite small - a lot smaller than my own builds, for sure.

How can you conclude therefore, that a GOOS/GOOARCH combination is used less frequently from the build statistics? I get that this about the tool-chain but I can't help thinking that in this case it would be a misleading metric.

My own project is tiny and insignificant but I can't imagine the general scenario is unusual for open source projects.

Regards Stephen

U Cirello

unread,
Feb 8, 2023, 5:02:21 PM2/8/23
to Russ Cox, golang-dev
Sorry for inserting myself in this conversation. First, I want to thank Russ Cox for the hard work. And I appreciate this comes from a good place, and I am grateful Go is open-source, because should this change cause me problems, I can just build my own compiler with this feature turned off (like RedHat).

Personally, I do not mind this feature. But as a professional using the Go tool, I see few hard problems with this proposal. 

Technically is impeccable, but in terms of compliance is a big no-no.

1) The justification that a reproducible build is source of truth to know whether a certain feature is disabled or not, in my experience, doesn't work. Compliance folks always pushed to say: "make sure this is impossible to happen". So if there's a chance of someone forgetting opting-out, this might not be enough for compliance requirements.

2) This walks on shaking ground regarding consent. Go is mostly sponsored by Google, and the fact is that Google retains control of what happens to Go (Go is open-source, but not open-collaboration) could end up putting me in the impossible position of having to ask Google or Google employee to sign NDA with the data that my company might (or not, because it is random) share with Google. Anonymization is not enough in a lot of cases.

3) This walks on shaking ground in terms of consent part II - I am not sure how Go can be compliant with things like CCPA or GDPR with an opt-in like that. And worse, it infects companies using Go. I know my program follow the rules, but the tools I use may not and depending on how you interpret GDPR, for example, I might have to seek consent from my consumers saying basically: "because you use a software that is built with a software that shares data with Google, and this same software also touches your data, and I cannot prove intransitivity without disclosing details, I need you to consent to keep me using the tool I use because it phones Google every time I make an update of the software that you use to operate your data."

Tough situation I know - but I really hope that Go team does not implement this feature at all in any sense. If the goal is improve where to focus efforts, I strongly encourage the Go team to try something else than phoning home (or not, it's random) every time `go build` is called.

Thanks for reading Russ! And Good Luck!



--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAA8EjDRUNF%2B9t0XLxgcTQgCWecXt7mWbv50iyzuZipRdD6iFrw%40mail.gmail.com.

Nathan O

unread,
Feb 8, 2023, 6:02:38 PM2/8/23
to golang-dev
Hi Russ,

We've seen how even the slightest amount of information can be leveraged by malicious actors to compromise systems. While I'm personally ok with the design you've suggested, I don't see how any security team at any company would be ok with any telemetry baked into the runtime like this.

Please consider making a package that can be included optionally, with tunables that organizations can optionally set to satisfy their security concerns. 

I realize this defeats some of your goals, but it also defeats my goal of expanding the use of Go at my company. People will not be as rational as you'd hope when you use the word "telemetry". They will be reactionary.

Thanks,
Nathan.

Dan Kortschak

unread,
Feb 8, 2023, 6:36:25 PM2/8/23
to golan...@googlegroups.com
On Wed, 2023-02-08 at 12:55 -0800, 'Nathan O' via golang-dev wrote:
> I don't see how any security team at any company would be ok with any
> telemetry baked into the runtime like this.

The telemetry would not be in the runtime. The proposal is for addition
to the tool chain.

Russ Cox

unread,
Feb 8, 2023, 8:47:08 PM2/8/23
to stephen.t....@gmail.com, golang-dev
On Wed, Feb 8, 2023 at 2:52 PM stephen.t....@gmail.com <stephen.t....@gmail.com> wrote:
I can see the benefit of this and the design is interesting. What concerns me is that the results you receive will be skewed towards installations that build often.

The use case that interest me is (from the third blog post)


For example, I develop on one architecture/os and I provide the source for people to build the binaries for their own machines. Those people do that three or four times a year, maybe. From what I can see, the chances of those builds being caught by the telemetry system is quite small - a lot smaller than my own builds, for sure.

How can you conclude therefore, that a GOOS/GOOARCH combination is used less frequently from the build statistics? I get that this about the tool-chain but I can't help thinking that in this case it would be a misleading metric.

My own project is tiny and insignificant but I can't imagine the general scenario is unusual for open source projects.

Hi,

The design doesn't segment the build data by which package is being built, so anyone building anything on that GOOS/GOARCH combination would be counted together as one bucket. People may build your binary only a few times a year, but it is likely that they build other things, as do the others who use that GOOS/GOARCH combination. It's true that if some GOOS/GOARCH combination is used by less than 1% of users, we'd perhaps want to sample at a higher rate to get a good signal, or perhaps we'd be comfortable with saying it's <1% and leave it at that. Telemetry data can only ever be an input into decisions, not the sole factor.

Best,
Russ

Russ Cox

unread,
Feb 8, 2023, 9:07:49 PM2/8/23
to U Cirello, golang-dev
On Wed, Feb 8, 2023 at 5:02 PM U Cirello <ulderi...@gmail.com> wrote:
Sorry for inserting myself in this conversation. First, I want to thank Russ Cox for the hard work. And I appreciate this comes from a good place, and I am grateful Go is open-source, because should this change cause me problems, I can just build my own compiler with this feature turned off (like RedHat).

Personally, I do not mind this feature. But as a professional using the Go tool, I see few hard problems with this proposal. 

Technically is impeccable, but in terms of compliance is a big no-no.

1) The justification that a reproducible build is source of truth to know whether a certain feature is disabled or not, in my experience, doesn't work. Compliance folks always pushed to say: "make sure this is impossible to happen". So if there's a chance of someone forgetting opting-out, this might not be enough for compliance requirements.

Today for the proxy you can always run 'go env GOPROXY' to query the effective GOPROXY setting and confirm that it's what you want it to be. If we adopt a design like the one I posted, you will be able to run 'go env GOTELEMETRY' to check on that setting as well. You could also arrange that the Go installed on your computers contains this setting in its $GOROOT/go.env.

2) This walks on shaking ground regarding consent. Go is mostly sponsored by Google, and the fact is that Google retains control of what happens to Go (Go is open-source, but not open-collaboration) could end up putting me in the impossible position of having to ask Google or Google employee to sign NDA with the data that my company might (or not, because it is random) share with Google. Anonymization is not enough in a lot of cases.

3) This walks on shaking ground in terms of consent part II - I am not sure how Go can be compliant with things like CCPA or GDPR with an opt-in like that. And worse, it infects companies using Go. I know my program follow the rules, but the tools I use may not and depending on how you interpret GDPR, for example, I might have to seek consent from my consumers saying basically: "because you use a software that is built with a software that shares data with Google, and this same software also touches your data, and I cannot prove intransitivity without disclosing details, I need you to consent to keep me using the tool I use because it phones Google every time I make an update of the software that you use to operate your data."

I am not a lawyer, and this is not legal advice, but your description sounds wrong to me. The tool you use already connects to Google servers to download dependency modules and verify their checksums, unless you've disabled that explicitly. And that tool is sharing the names of those modules with the servers, because they have to include the name to ask "can I have the module (or checksum) with this name please?" The telemetry is strictly less data. In fact it has no strings at all that are not already known to the server. The only entropy in those reports is in the counters and the stacks and the dates.

In addition to not being a lawyer, I am certainly not an expert about CCPA, GDPR or other privacy regulations. I learned many years ago that engineers pretending to be lawyers works about as well as lawyers pretending to be engineers, so I won't try. (I do know at least three people who are trained and have worked professionally in both jobs, but I am not one of them!) I have discussed the design with Google's lawyers, and I will continue to do so. We will follow all applicable legal requirements. If there is more I can share about these concerns around "infection", I will.

Best,
Russ

stephen.t....@gmail.com

unread,
Feb 9, 2023, 3:05:28 AM2/9/23
to golang-dev
Hi,

The design doesn't segment the build data by which package is being built, so anyone building anything on that GOOS/GOARCH combination would be counted together as one bucket. People may build your binary only a few times a year, but it is likely that they build other things, as do the others who use that GOOS/GOARCH combination.

I agree that that is likely but in my specific scenario, I know that that isn't true. Users of my software have installed Go solely for the purpose of building binaries I cannot supply. In any case, I appreciate your answer and can see that you have considered the potential for small sample sizes.

U Cirello

unread,
Feb 9, 2023, 9:24:26 AM2/9/23
to Russ Cox, golang-dev
Russ, thanks for the answer and for taking my input in consideration. In any case, this is one of these situations that I look forward to be wrong. And again, thanks for the hard work. Best, Ulderico 

Rui Craveiro

unread,
Feb 9, 2023, 2:24:50 PM2/9/23
to golang-dev
I don’t know about CCPA, but if no personal data is collected, GDPR does not apply. From what I understood, there is no personal data, or even any form of identifier.

The only grey area is the collection of IP addresses on a separate log. Names, addresses, age, gender and so on are personal data. Are IP addresses considered personal data? If we consider that an IP address can be indirectly traced back to a user, then eventually yes, it may be considered personal data. However, because they are meant to be used for security, I think that that could be the required legal justification for that data processing. Let’s imagine, however, that Google used those collected IP addresses to target developer related ads. The only legal justification I can see for that kind of personal data processing is explicit user consent (always with opt-in). Without explicit consent, that would definitely be a no-no.

Still, from what I understood about their intentions, I don’t think GDPR would be much of an issue here.

Daniel Martí

unread,
Feb 10, 2023, 4:55:41 AM2/10/23
to golang-dev
Hi Russ,

The discussion has had hundreds of reactions and replies in less than
two days, presumably due to it being shared widely and the word
"telemetry" in the title causing many to come in with a negative bias.

The thread is probably not going to be useful for much longer,
given that we're already past the "load more" GitHub pagination stage,
causing the same arguments and questions to be posted again and again.

Still, it seems to me like we could collect FAQs for the most common
arguments, questions, and misconceptions. From what I've seen:

* Why is opt-in telemetry not a viable option?

* Why are other forms of opt-in metrics not enough, like surveys or bug reports?
(should also mention the third blog post)

* Can we trust the server or Google to not track IP addresses?
(we can't truly, but mention proxies like the second blog post,
the privacy policy, and the possibility for neutral third parties to
run their own servers for GOTELEMETRY, GOPROXY, or GOSUMDB)

* Does the system conform to privacy laws like GDPR in the EU?

* How is transparent telemetry better than nothing if data can be faked?

* How will the project use the data given that there may be significant
opt-out bias, such as Linux distros which already turn off GOPROXY?

* Can we trust that the system won't share more data in the future?
(client is limited to a set of event counters, which go through code review)

I realise that most of these are already covered in the blog post, but
some are mentioned in passing and I think they all deserve clear answers.

Perhaps a new discussion or proposal with such a FAQs section would be
less prone to being repetitive with the same handful of points.
We can't force users to read all blog posts carefully before responding,
but at least we can reference the FAQs on repetitive comments.

Russ Cox

unread,
Feb 10, 2023, 9:49:58 AM2/10/23
to Daniel Martí, golang-dev
Hi Daniel,

I agree that the discussion is getting too long for GitHub and starting to repeat itself. There have been some truly helpful comments in among the large amount of noise, and I am grateful for those helpful comments. I am going to take some time to investigate some of the suggestions. I will probably lock the GitHub discussion at the end of the day so we can all have a quiet weekend. 

Best,
Russ



--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

Russ Cox

unread,
Feb 24, 2023, 9:24:58 AM2/24/23
to golang-dev
Hi all,

Thanks for the feedback for the past two weeks. We've spent a while considering it and decided to change the system to be opt-in.

Best,
Russ
 

Jan Mercl

unread,
Feb 24, 2023, 9:27:03 AM2/24/23
to Russ Cox, golang-dev
On Fri, Feb 24, 2023 at 3:24 PM Russ Cox <r...@golang.org> wrote:

> Thanks for the feedback for the past two weeks. We've spent a while considering it and decided to change the system to be opt-in.

Thanks for the good news, much appreciated!

-j

Hein Meling

unread,
Feb 24, 2023, 10:07:03 AM2/24/23
to golang-dev
I too appreciate this decision Russ. Thank you for your leadership.

U Cirello

unread,
Feb 24, 2023, 2:37:48 PM2/24/23
to Russ Cox, golang-dev
Thanks for the change, Russ! And also for making your thought process public. 

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

Filippo Valsorda

unread,
Feb 25, 2023, 1:44:55 AM2/25/23
to golang-dev
Hi Russ,

Thank you for the thoughtful proposal. I think I understand the decision to switch to opt-in, and I am not trying to change it, but lest it appears all feedback is in favor of an opt-in version, I want to mention I disagree with it and I am disappointed and sad about it.

I think how the discussion developed around this is unfortunate. In the first 24 hours after the design was published I tried to engage with a number of people who objected to it on Mastodon, and the overwhelming majority were arguing against a design that didn't match the reality of what was proposed, or refused to engage with the design at all, taking a stance based on its name and its affiliation with Google. That was starkly different from the reaction from people I actively reached out to or in private communities I'm part of, which was universally positive or lukewarm, with all objections I remember being procedural about how it was proposed.

Reading through all those interactions and some of the comments on the GitHub Discussion (it is too long to have read it all, but I tried to keep up for the first few hours), I found no argument for why anonymous, sampled, weekly counters of cache hits and the like would be personal data. The closest anyone got was pointing out that it occasionally leaks a bit of information about "this machine compiles Go" but surely the network traffic patterns of "go mod download" do that already. (Yes, some environments will do hermetic builds from vendored dependencies, but those will mostly be ephemeral and/or not connected to the network, so won't report telemetry either.)

The outcome from where I sit seems to be that we got shouted into a dramatically less useful and marginally more invasive design, mostly because the proposal came "from Google". I'm not sure what could have been done differently, but it's sad and I wish there was a meta post-mortem on the discussion, even if informal and/or private.

I supported the opt-out design. As for the opt-in system, I am much less enthusiastic. First, it's unclear to me how many of the use-cases are still served by a more limited sample biased towards major platforms and power users. Second, I had found one of the original arguments for opt-out very compelling: we are entrusted to be stewards of the project, and we have a responsibility deploy something that's minimal and privacy-preserving enough that it can ship as default. In other words, I don't know how to answer "if this design is as safe as you say, why is it not on by default?" To be clear, I think it is safe, opt-out or opt-in, but I find the argument for it weaker now, and the project will have to make that argument over and over. Maybe I'm biased by my subject matter, cryptography, where it's especially true that users delegate decisions to us and we should not resolve hard questions by remitting back to them.

I don't intend to engage further with this, and I actually send this reticently, given the amount of vitriol and personal attacks I got last time around. However, I realized that if I didn't I would actually be part of the problem where all positive feedback is silent or private, and the negative feedback is public and loud. Thank you for working through all this, I imagine it was no piece of cake for you either.

Best,
Filippo

Sean Liao

unread,
Feb 25, 2023, 2:59:17 AM2/25/23
to golang-dev
I'd like to echo everything that Filippo said.
From experience, opt-in without a strong incentive skews data too much to be broadly useful.
The `go` tool is currently configured with defaults that rarely need to be changed and benefit the wider ecosystem at the same time,
it would be quite unfortunate for that to change.

- sean


--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

Konstantin Kulikov

unread,
Feb 25, 2023, 5:27:12 AM2/25/23
to golang-dev
Some people disable sumdb[0][1], in the name of privacy of course.
And you want them to have telemetry enabled by default ¯\_(ツ)_/¯

[0]: https://src.fedoraproject.org/rpms/golang/c/29d5602b1965e19c7244a6b12d73c57d29af25a3?branch=rawhide
[1]: https://fedoraproject.org/wiki/Changes/golang1.13#Detailed_Description
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAGabyPp1q3jM7Ex3Z06KkTanLQ0RDYmP6DFb1atyCqBLjEEfVA%40mail.gmail.com.

Josh Bleecher Snyder

unread,
Feb 25, 2023, 10:44:40 AM2/25/23
to Filippo Valsorda, golang-dev
Thanks for raising these procedural questions, Filippo. And thanks to you and Russ and others for patiently and calming responding to the flood.

One possible approach to governance decisions which are likely to be highly controversial and/or attract vocal factions would be to use sortition. (And it is apropos in this case, given that the topic happens to be sampling-related!)

In practice, that might look identical to the current setup, except that only a small subset of Gophers would be randomly selected to have write permissions (ability to comment, vote, etc.). Everything would still be world-readable.

There's a risk of losing long tail input from folks with highly relevant expertise or experience, but I think it'd be worth the improvement in SNR, representativeness, and civility. (And presumably there would still be a non-public forum for individuals to write in, but without being part of the agora.)

Or maybe this would be one (early?) phase in the process? Anyway, it's a tool that might be worth considering.

-josh

P.S. It really shouldn't matter to a meta discussion like this, but I am concerned that my comments above will be written off by some unless I state my position on telemetry. I am weakly in favor of the decision to require opt-in for the toolchain (but not gopls), on the grounds that telemetry and privacy haven't played well in the past, despite good intentions and careful designs. (And yes, I recognize that this is the same exasperating argument that opponents of nuclear power in the US use. Such is life.) Like Filippo, I do not want to discuss this further here.


Mi Tar

unread,
Feb 25, 2023, 3:28:24 PM2/25/23
to golang-dev
Hi!

On Saturday, February 25, 2023 at 11:27:12 AM UTC+1 Konstantin Kulikov wrote:
Some people disable sumdb[0][1], in the name of privacy of course.
And you want them to have telemetry enabled by default ¯\_(ツ)_/¯

I think this is exactly the argument for default opt-in in Go itself. People can use distributions which change the default. They have done this in the past and can do it again.

Given that opt-in in fact increases the rate each (participating) individual will be contacted it is really questionable if opt-in increases privacy.

I think having a known public IP for the collecting server could also be a way for large organizations to simply block any contact to it.


Mitar

Hakan Bayındır

unread,
Feb 25, 2023, 3:28:38 PM2/25/23
to golang-dev
Dear Russ,

Thanks for the good news. It's the best compromise. Thanks a lot for considering the feedback and revisited the decision.

Best regards,

Hakan

P.S.: This decision retained at least two Go developers as of arrival of this message.

Message has been deleted

Carla Pfaff

unread,
Feb 26, 2023, 4:37:41 AM2/26/23
to golang-dev
Maybe a quick update above https://github.com/golang/go/discussions/58409 would be useful so people who come across this discussion late can see the current state of affairs.

Ian Lance Taylor

unread,
Feb 26, 2023, 5:15:31 PM2/26/23
to Carla Pfaff, golang-dev
On Sun, Feb 26, 2023 at 1:37 AM 'Carla Pfaff' via golang-dev
<golan...@googlegroups.com> wrote:
>
> Maybe a quick update above https://github.com/golang/go/discussions/58409 would be useful so people who come across this discussion late can see the current state of affairs.

Done.

Ian

Russ Cox

unread,
Mar 6, 2023, 1:00:54 PM3/6/23
to golang-dev
Hi all,

I've posted the Go proposal for opt-in transparent telemetry at https://go.dev/issue/58894.

To follow up briefly about the decision to change to opt-in and the concerns that Filippo raised, specifically:

> The outcome from where I sit seems to be that we got shouted into a dramatically less useful and marginally more invasive design, mostly because the proposal came "from Google". I'm not sure what could have been done differently, but it's sad and I wish there was a meta post-mortem on the discussion, even if informal and/or private.

It's good to know that's what it looks like. I can tell you that the shouting did not really influence the decision. Long-time Go contributors and supporters commenting quietly or emailing me privately had far greater influence.

It is also definitely true that Go's association with Google influenced some people's reactions, positively for some people, negatively for others (especially the loudest ones). The additional shouting we might have gotten due to a connection with Google did not determine the outcome either.

> In other words, I don't know how to answer "if this design is as safe as you say, why is it not on by default?"

My answer would be that it's not on by default because we decided that even if a system is perfectly safe, the decision to participate in any data collection at all should be up to individual users, not the authors of the software. To the extent that Go sets an example for other open-source projects, I feel good about setting this example.

Best,
Russ

Gergely Brautigam

unread,
Mar 7, 2023, 4:17:28 AM3/7/23
to golang-dev
Thank you, Russ, for listening to people. This is an awesome step in the right direction.
Reply all
Reply to author
Forward
0 new messages