Live data from Hacker News

Transparent telemetry for open-source projects

research.swtch.com

171–180 of 314 posts

Re: Transparent telemetry for open-source projects

#171
post #88

Earlier quoted context omitted.

> The idea of telemetry is being able to prioritize the work that will be most widely useful. It does sort of hinge on the highly suspect assumption that usefulness is correlated with use. An obvious counter-example to this is something like a fire-extinguisher, which will in the ideal case just sit on a wall until it's use-by date passes and then it's discarded having never been used; or on the flip side, an incredi…

Most software features are not like fire extinguishers. More than that, the interesting stats may be not even around user-visible features, but around internal mechanisms, like some cache hit rate, or how often is some branch in the compiler invoked. As long as stats are clearly inspectable, reasonably anonymized, and are opt-out, I'd be fine with sending them.

„ Most software features are not like fire extinguishers. „

Amen

Sometimes some pretty niche feature, that is used by one individual that is loud, gets more attention than a feature, used by thousands or millions that are just silent users.

Re: Transparent telemetry for open-source projects

#172

Earlier quoted context omitted.

Totally agree. Telemetry has been around and matured and benefits users. I’m not sure the benefits for Go would be as significant as other software but, really, why not?

> Telemetry has been around and matured and benefits users. Does it? Telemetry mostly seems used to justify removing features I need on grounds that they’re little used. As an other user noted, if telemetry is your yardstick, the average backup software removed the “restore” feature because that’s barely ever used.

I don’t like this example in particular because observing too much “restore” activity is an excellent piece of information.

Re: Transparent telemetry for open-source projects

#173

Earlier quoted context omitted.

Totally agree. Telemetry has been around and matured and benefits users. I’m not sure the benefits for Go would be as significant as other software but, really, why not?

> Telemetry has been around and matured and benefits users. Does it? Telemetry mostly seems used to justify removing features I need on grounds that they’re little used. As an other user noted, if telemetry is your yardstick, the average backup software removed the “restore” feature because that’s barely ever used.

There is a long list of use cases, which go far beyond "removing features": https://research.swtch.com/telemetry-uses

"Is it safe to remove support for X?" is one use case. Right now the strategy more or less amounts to "remove and see if anyone complains, possibly too late to change".

Re: Transparent telemetry for open-source projects

#174
post #159

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

What world do you live in?

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.

Re: Transparent telemetry for open-source projects

#175
post #164

Probably related to[0]. To anybody complaining that this should be opt-in: opt-in telemetry doesn't work. The reason for this is that most people don't care, but they don't care either way. They don't disable it when prompted, nor would they enable it manually. The idea of telemetry is being able to prioritize the work that will be most widely useful. For this you need a good and balanced sample of your users. You do…

But that's wrong. There is no position for this in a civilised society: "If we ask everyone is going to say no, so we will steal it unless someone tells us not to"

I think the comparison of telemetry and stealing is pretty harsh.

Is opt-out telemetry unethical ... depends. If you use it in a privacy preserving way no, if you spy on your Users, sell the data for money or advertising obviously it is unethical.

The hard truth is, nobody reads the manual. Opt in telemetry is often a minority, and you then work with niche data for a minority that influences your development in certain ways.

Re: Transparent telemetry for open-source projects

#176
post #164

Earlier quoted context omitted.

But that's wrong. There is no position for this in a civilised society: "If we ask everyone is going to say no, so we will steal it unless someone tells us not to"

I think the comparison of telemetry and stealing is pretty harsh. Is opt-out telemetry unethical ... depends. If you use it in a privacy preserving way no, if you spy on your Users, sell the data for money or advertising obviously it is unethical. The hard truth is, nobody reads the manual. Opt in telemetry is often a minority, and you then work with niche data for a minority that influences your development in certa…

But is that not the decision of the person who owns the data?

Re: Transparent telemetry for open-source projects

#177
post #88

Earlier quoted context omitted.

Most software features are not like fire extinguishers. More than that, the interesting stats may be not even around user-visible features, but around internal mechanisms, like some cache hit rate, or how often is some branch in the compiler invoked. As long as stats are clearly inspectable, reasonably anonymized, and are opt-out, I'd be fine with sending them.

There are essential, fire-extinguisher-like features. The canonical example is the joke about backup software: if it were developed according to today's standard of telemetry-driven engagement analytics, the restore from backup functionality would be removed because it's used so infrequently. This actually happens sometimes: when developing the demo ".kkrieger", a first-person 3D shooter in 96 KiB, demogroup theprodu…

I think your view of the ways usage stats are used is a bit simplistic. Not everyone remove "underused" features without giving some consideration, even in big corporations.

But since you clearly don't like telemetry, you should have a way to reliably switch it off. Here we are on the same page: there must be a well-documented and easy way to switch any telemetry off.

Re: Transparent telemetry for open-source projects

#178
post #136

Earlier quoted context omitted.

I am jaded and probably being a little uncharitable. However, I don't know Russ personally so I have no reason to place a high level of confidence that a Google employee isn't going to make decisions that align more with Google's interests vs privacy interests. Regardless, there are plenty of ways to upgrade the Go tool chain (snaps, distro packages, fetching latest via curl, etc) that won't result in the changes bei…

> I am jaded and probably being a little uncharitable. However, I don't know Russ personally so I have no reason to place a high level of confidence that a Google employee isn't going to make decisions that align more with Google's interests vs privacy interests. If the nature of this data were different, I would be suspicious too. But it's really hard for me to see how a set of counters (whose names have various pro…

> there should be a single environment variable (e.g. $TELEMETRY) that all programs should respect, to avoid the need to do work for every application.

There was a proposal for that some years ago, but that didn't really go anywhere, partially because of the author's rather unpleasant attitude towards projects he wanted to implement it and their overly broad definition of "tracking" (which includes e.g. update checks).

Some discussions:

https://news.ycombinator.com/item?id=27746587

https://lobste.rs/s/htbkqd/console_do_not_track

Re: Transparent telemetry for open-source projects

#179

Earlier quoted context omitted.

Totally agree. Telemetry has been around and matured and benefits users. I’m not sure the benefits for Go would be as significant as other software but, really, why not?

> Telemetry has been around and matured and benefits users. Does it? Telemetry mostly seems used to justify removing features I need on grounds that they’re little used. As an other user noted, if telemetry is your yardstick, the average backup software removed the “restore” feature because that’s barely ever used.

Microsoft deprecated the disk-image backup in Windows 7 because it was infrequently used... buy random grandparents.

It was basically a "free" wrapper on top of the Volume Shadow Service (VSS) built into the operating system, but only IT professionals ever used it, so... it had to go.

Re: Transparent telemetry for open-source projects

#180

This is not okay. The only ethical way to do telemetry is opt-in . If not enough people are opting in, you need to incentivize them to -- most simply by just paying them for their data. After all, telemetry is "valuable", isn't it? But if you can't figure out how to convince people to opt-in, then tough luck, sucks to be you. Opt-in or GTFO, Google. I'll be patching this out of the Alpine package for Go the day it sh…

You and I may not agree on a lot, but I sure agree with you on this one.
Post reply on HN