Transparent telemetry for open-source projects

Can you configure openSUSE to use apt instead of zypper? I mean, sure, probably, it's open source.

Is it going to be straightforward? I don't know. I suspect it's going to be harder than it's worth, and you might need to rebuild the operating system image to change the directory layout to work with apt's assumptions or something.

So in practice, even though these things are all open source, people who bundle complex software lay down the paths that 99.9% of people will take.

I wasn't proposing "disabling telemetry" as the primary business proposition.

Instead I was suggesting that open-source companies spend a lot of time dealing with issues from people who use the open-source software in unanticipated ways. If "the beaten path" for using the software without support includes telemetry, they get value from that.

If people want to use the software without telemetry, then they're paying for a support license, so the issues they run into which the supporting company has no telemetric insight into are at least better aligned with their support resource allocation.

Frankly, that crap should be expunged from the Go toolchain as well. :(

It's technically not unavoidable. The Go authors could have made use of the proxy opt-in rather than opt-out, making the tool less usable as a result. A similar argument applies here, I think.

> Second, the Go telemetry would apparently create a unique, persistent user ID

Where did you see this? I scanned through the "Telemetry Design" article reasonably carefully and couldn't find any mention of this concept, and the type definition for the posted JSON (the `Report` type) doesn't seem to include any such user ID.

In the end, ISTM that you're not complaining about something that actually affects your privacy in any way, but just the _idea_ of telemetry. Is that really something worth taking such a hardline stance on?

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!

Is there an example of a program that was crap, implemented telemetry and then got better afterwards? (and of course controlled for factors that might have improved the program anyway)

I mean since telemetry advocates are so into how useful data is, surely they must have data on whether telemetry itself works?