Live data from Hacker News

Transparent telemetry for open-source projects

research.swtch.com

271–280 of 314 posts

Re: Transparent telemetry for open-source projects

#271
post #247
post #245

The Go team at Google would run a collection server. Each week, with 10% probability (averaging ~5 times per year) the user’s Go installation would download a “collection configuration” to find out which counter values are of interest to the server and at what sample rate. If there's interest to use config files to determine how telemetry is done, why can't similar be done about turning telemetry off? I don't want to…

As designed, the system allows an opt-out _either_ by setting GOTELEMETRY=off in your environment or by running 'go env -w GOTELEMETRY=off' which writes a config file. (Specifically the one reported by 'go env GOENV'.) If you prefer to edit the config file directly, you are of course welcome to do that.

Sure, and have to remember to do that every single time you mint a new Docker image for use in CI, every single time you spin up a new Cloud workstation, every single time you get a new physical workstation, every single time you have to run a job in a brand new environment, every single time you... etc, etc, etc.

Thing that work inside the Googleplex often don't work for the rest of us. Not every company is a multi-billion-dollar behemoth that can afford to spend hundreds of millions of dollars annually to work exclusively on internal developer-tooling.

Re: Transparent telemetry for open-source projects

#272
This kind of push is only going to make people want to disable telemetry even more. Privacy is sacrosanct and should be accepted as the norm, not something we need to opt-in.

Go already has some form of telemetry built-in (by way of a google proxy, I suppose) and adding an official one that is opt-out is just going to make me refuse to ever work with it.

Telemetry should always be opt-in, and only opt-in. We have so much issues with telemetry, privacy, and such because the big players and corporations insists opt-out is better (maybe you get more data, but you violate end-users trust as well). Is that really worth it?

There is blow-back and distrust in the industry as a result and it's only going to get worse the more you try to push for opt-out telemetry (or just assuming telemetry should be the default).

Re: Transparent telemetry for open-source projects

#273

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

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

Re: Transparent telemetry for open-source projects

#274

This kind of push is only going to make people want to disable telemetry even more. Privacy is sacrosanct and should be accepted as the norm, not something we need to opt-in. Go already has some form of telemetry built-in (by way of a google proxy, I suppose) and adding an official one that is opt-out is just going to make me refuse to ever work with it. Telemetry should always be opt-in, and only opt-in. We have so…

Have you read the articles? How is this in any way violating privacy?

Re: Transparent telemetry for open-source projects

#275

This kind of push is only going to make people want to disable telemetry even more. Privacy is sacrosanct and should be accepted as the norm, not something we need to opt-in. Go already has some form of telemetry built-in (by way of a google proxy, I suppose) and adding an official one that is opt-out is just going to make me refuse to ever work with it. Telemetry should always be opt-in, and only opt-in. We have so…

Have you read the articles? How is this in any way violating privacy?

Because it's impossible to get telemetry from any source without violating some aspect of the users' privacy.

Re: Transparent telemetry for open-source projects

#276

Earlier quoted context omitted.

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

I fail to see what’s that got to “too much” restore activity doesn’t tell you anything actionable about your software, if anything it’s creepy as hell.

Re: Transparent telemetry for open-source projects

#277
post #113

Earlier quoted context omitted.

You can set env variable for the go toolchain with a command such as: go env -w TELEMETRY=off which will be written to disk and use by the go cli.

What if a new version of go uses TELEMETRY_ENABLED? Do you read all the changelogs, always?

[deleted]

Re: Transparent telemetry for open-source projects

#278

Earlier quoted context omitted.

What if a new version of go uses TELEMETRY_ENABLED? Do you read all the changelogs, always?

Yeah, given go's history with breaking changes (and the habit of OKR-chasing managers and Senior Staff to make Number Go Up to look good on the promo packet), I definitely would not trust any opt-out mechanism to not receive operationally-significant changes in the next five years.

As far as I known go never changed any flags since release ( 2012 ), is it good enough for you?

Re: Transparent telemetry for open-source projects

#279

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…

Telemetry in the Go toolchain:

https://github.com/golang/go/discussions/58409

Re: Transparent telemetry for open-source projects

#280
post #23

I've been a pretty strong advocate of the idea that analytics should always be minimal, 100% anonymous, aggregated, and open to the public - otherwise it’s spying. This is how we do analytics on our websites today[0][1], and how we plan to do it in games we release in the future. Maybe one day I will start a dedicated FOSS service that people can use for exactly this with some trusted reputation/transparency/auditabi…

> 100% anonymous, aggregated, and open to the public

I don't believe the "100% anonymous" is a thing with AI anymore. When AI can identify/fingerprint you by your walk pattern[1], you can't really tell what data can and can't be used to fingerprint you.

[1] https://ieeexplore.ieee.org/document/8275035

Post reply on HN