Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transparent telemetry for open-source projects

research.swtch.com

Post reply on HN
Print view View original

91–100 of 314 posts

Re: Transparent telemetry for open-source projects

#91

Post by userbinator »

JohnFen wrote: post #37

> When you hear the word telemetry, if you’re like me, you may have a visceral negative reaction to a mental image of intrusive, detailed traces of your every keystroke and mouse click headed back to the developers of the software you’re using. But that's not my only objection to telemetry. Equally important to me is that so many bad decisions are justified based on telemetry. It's very easy to misunderstand the data…

Or they use the data as an accelerant: move rarely used features to places where they're even less discoverable, making them even less used, and then remove them altogether. The justification then becomes a self-fulfilling prophecy.

Re: Transparent telemetry for open-source projects

#93

Post by agwa »

alyandon wrote: post #54

Oh Google - never stop being you. Not only is it going to be opt-out (because of course it would be coming from Google), I really like the whole "wait a week before sending telemetry" part that just coincidentally has the benefit of sneaking right past people that actively look for suspicious network activity when they've freshly installed something. Am I being uncharitable?

Since you asked, yes you are being uncharitable. It's rather hard to imagine that the people who are details-oriented enough to look for suspicious network activity after installing something wouldn't notice the disclosure on the download page (edit: or the release notes). On the other hand, the explanation given by Russ for delaying a week (so people have ample time to opt-out) makes sense.

Do you actually think Russ' explanation is just a pretext so they can evade detection by people who monitor for suspicious network activity (yet don't notice the disclosure on the download page)?

Re: Transparent telemetry for open-source projects

#94

Post by silisili »

Very much against this. Sure, it sounds naive enough, and can give reasons why. But I have 3,436 items in /usr/bin. What if -every- one of these started doing their own telemetry, their own envvars, etc?

If we have to deal with telemetry, then I'd instead hope that there can exist a single telemetry systemwide interface. Not sure how that would be designed or implemented, but would be better than everyone doing their own bespoke thing. Plus easier for me to disable them all in one go.

Re: Transparent telemetry for open-source projects

#95

Post by marginalia_nu »

nine_k wrote: post #88
marginalia_nu wrote: post #71

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.

The features that are like fire extinguishers are the ones most likely to be unjustly removed with the rationale of looking at telemetry.

See for example Mozilla's bizarre decision to remove the ability to change the override the character encoding of a webpage with some half-baked detector.

Re: Transparent telemetry for open-source projects

#96

Post by guessmyname »

r2vcap wrote: post #75

I have set DOTNET_CLI_TELEMETRY_OPTOUT=1 as an environment variable in my .profile file. What should I do for golang?

> To opt out, users would set GOTELEMETRY=off in their environment or run a simple command like go env -w GOTELEMETRY=off; The first telemetry report is not sent until at least one week after installation, giving ample time to opt out. Opting out stops all collection and reporting: no “opt out” event is sent. It is simply impossible to see systems that install Go and then opt out in the next seven days.

Source: https://research.swtch.com/telemetry-intro

Re: Transparent telemetry for open-source projects

#97

Post by msla »

cube2222 wrote: post #69

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…

> opt-in telemetry doesn't work.

Then don't do telemetry at all.

Google doesn't have a right to data.

Re: Transparent telemetry for open-source projects

#98

Post by userbinator »

taveras wrote: post #18

I wish there was a standard way of disabling telemetry across software dependencies. While I leave it turned on for personal projects, several projects at work require disabling it. I have spent hours auditing through transitive dependencies to turn it off. It should not be this painful.

A firewall is probably your best bet. Don't allow network traffic originating from anything other than a short whitelist.

Re: Transparent telemetry for open-source projects

#99

Post by mseepgood »

sidewndr46 wrote: post #77
4ad wrote: post #65

Earlier quoted context omitted.

Because this proposal has not yet been implemented.

So is there a way to disable this ahead of time? Or do I have to install the version with telemetry first?

Yes, you can set an environment variable at any point in time.
Post reply on HN