Comment by gavinhoward | Hacker News Reader

Comment by gavinhoward | Hacker News Reader

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

What others have said in this thread about telemetry becoming an "accelerant" will happen. Abuse will happen. Data will be put up for sale. IP's will be logged because users can't verify that they're not.

The only thing users can verify is what is sent and to whom. And only if they run packet inspection. Most users don't.

(Edit: I just realized that users may not even be able to tell who data is sent to because of proxies or the original collector selling the data.)

I have no reason to believe your personal motives are anything but pure; however, this capability will not just be in your hands. It will be in the hands of anyone with less-than-pure motives.

I applaud your efforts to make telemetry more transparent, but they are destined to fail.

When it comes to figuring out how users use software, the only thing to do legwork. Ask your users. Watch them if they'll let you do user studies. Pay non-users to use the software for a user study and put them through all situations, including rare ones.

This is the same thing we programmers tell the police to do when the police whine about end-to-end encryption: do old-fashioned legwork. Why should we, as programmers, demand that of police when we give ourselves tools to violate the privacy of users in the exact same way that police want?

Yes, that's right, the exact same way. Telemetry is a backdoor on a private conversation between a user and a machine.

Just do the work. I'm pretty sure Google has the money to do so.

You may respond that this is for Open Source developers to get data on their users. Well, if those developers are hobbyists, they don't have time to crunch data, and they're probably scratching an itch. If they are not hobbyists, they are paid and should do the legwork.

There is no excuse for telemetry. Just do the work.

> @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?

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

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

> 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!

What world do you live in?

All browser have telemetry in them, but he probably used netcat to post that message.

A custom-built Gentoo that uses the Awesome Window Manager for a minimal install, builds Firefox from source, and uses OpenSnitch to sniff everything.

My machine is locked down hard.

Oh, and I checked what depends on Go on my machine. The one kicker was libcap, which won't depend on Go if I tell it not to build captree. So I did that.

I uninstalled Docker.

That leaves:

* `arduino-builder` (for my custom keyboard).

* Hugo (for my websites).

* An unnamed program.

* Gitea.

Besides `arduino-builder`, I have a plan to get rid of all three of those. For two, Hugo and Gitea, I had already planned to. The unnamed program is harder, but someone has already done one. Unfortunately, it's in Go, so I'm going to have to do something else myself.

`arduino-builder`, though, that's tough.

Reply on news.ycombinator.com