[rogpeppe1]

> @rsc, if you ever see this, your proposal here means that I will never use any software written in Go ever again, if at all possible.

Have you actually read the articles?

The "data put up for sale" is to be made available publicly.

IP logging can already be done (the Go proxy is enabled by default).

All the source code is open.

What's your actual problem with this, beyond a knee-jerk reaction to the idea?

[gavinhoward]

> The "data put up for sale" is to be made available publicly.

How can users verify this?

> IP logging can already be done (the Go proxy is enabled by default).

Sure, but more data will be attached to it. Also, in his proposal, he said that IP addresses will not be logged. I seriously doubt that.

> What's your actual problem with this, beyond a knee-jerk reaction to the idea?

Putting telemetry in a programming language. Working with a programming language is the number one thing I do on a computer. This means that, except for the fact that I don't work in Go, most of my private conversation with a machine could be backdoored.

[rogpeppe1]

> Sure, but more data will be attached to it. Also, in his proposal, he said that IP addresses will not be logged. I seriously doubt that.

I think it's worth quoting what Russ said in the article, which sounds very reasonable to me:

> The server would necessarily observe the source IP address in the TCP session uploading the report, but the server would not record that address with the data, a fact that can be confirmed by inspecting the reporting server source code (the server would be open source like the rest of Go) or by reference to a stated privacy policy like the one for the Go module mirror, depending on whether you lean more toward trusting software engineers or lawyers. A company could also run their own HTTP proxy to shield individual system’s IP addresses and arrange for employee systems to set GOTELEMETRY to the address of that proxy. It may also make sense to allow Go module proxies to proxy uploads, so that the existing GOPROXY setting also works for redirecting the upload and shielding the system’s IP address.

> This means that, except for the fact that I don't work in Go, most of my private conversation with a machine could be backdoored.

I don't get this. Given the design that the article is describing, how could most of your private conversation with a machine be backdoored? Specifically given that the Go tool is open source and used by millions already. Are you worried about sneaky code hidden inside that source code? If so, you should be worried already, because there's no reason that they couldn't already be doing that if they were so inclined.

[gavinhoward]

> The server would necessarily observe the source IP address in the TCP session uploading the report, but the server would not record that address with the data

Users can't confirm this. In fact, this makes the next part a falsehood:

> a fact that can be confirmed by inspecting the reporting server source code (the server would be open source like the rest of Go) or by reference to a stated privacy policy like the one for the Go module mirror, depending on whether you lean more toward trusting software engineers or lawyers.

Sure, the source code of the server might be available, but you can't confirm that the server wasn't built with modified source code.

Second, as we've seen before privacy policies are empty; companies violate them all the time.

IOW, I don't trust software engineers, and I don't trust lawyers, and I would bet my life savings that there will be instances of companies lying in the ways I mentioned above.

> I don't get this. Given the design that the article is describing, how could most of your private conversation with a machine be backdoored?

Counts are enough. He says that counts are the only thing that will be uploaded, but he forgot that timing will also come into play.

(A week's delay is only an offset to subtract, by the way.)

Here's how it works: the tool reports counts, maybe in batches per hour. The server logs the counts and the hour those counts came from.

Yes, there's already another piece of data they captured, even though the tool ostensibly only sent counts.

Then those counts plus their timings can be used to infer things. For an example outside of Go (this is one I saw somewhere else), imagine a person texting more and more as the weekend approaches, until they are texting frantically. Then they suddenly stop in the evening of Saturday.

You only get the report of counts and the hours they happened in. Can you give some plausible explanations?

I can. They were texting someone they were planning on meeting that weekend, and then meet them. Can you give a few guesses as to why they're meeting them?

I'll let you fill in the blank.

Sure, there might be other reasons, but I would bet there are not many. Enumerate them, and you already know more. Find the similarities between all possibilities, and you know even more.

People forget about side channels all the time. In this case, the side channel was timing, but it doesn't matter what the side channel is; data can be extracted from it. And companies will.

> Specifically given that the Go tool is open source and used by millions already. Are you worried about sneaky code hidden inside that source code?

Yes. Just because there are eyeballs on that code doesn't mean they won't put sneaky stuff in. For example, the counts could be packed in a different order to tell the server more information. Or the tool could time its uploads. Or it could batch some counts and not batch others.

I'm not smart enough to catch all of the tricks they might pull. Are you?

> If so, you should be worried already, because there's no reason that they couldn't already be doing that if they were so inclined.

It's Google. Of course, they are so inclined!