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

181–190 of 314 posts

Re: Transparent telemetry for open-source projects

#181

Post by JohnFen »

mananaysiempre wrote: post #170
JohnFen wrote: post #168

Earlier quoted context omitted.

Thank you for the thoughtful response. We disagree on much, but I respect your opinion nonetheless. > Not giving the users a choice or manipulating them into making the one I think is right would absolutely be wrong, though. I'll pull out just this point, though, to perhaps illustrate how different our worldviews are. I consider opt-out to be a manipulative approach.

> I consider opt-out to be a manipulative approach. So do I, which is why I wrote I’m unwilling to implement it :) The original (and, to be clear, purely theoretical) point was, opt-out is too manipulative while opt-in is likely useless. Ah shoot. Did you take that to mean that I’m unwilling to implement an off switch at all? That wasn’t it, sorry for the confusion.

Perhaps we aren't so far apart after all.

The struggle is real. As a developer, more data is obviously desirable and can make development much easier. I just can't think of a way to do telemetry that, if I were a user, I would accept. And I don't want to produce software that I wouldn't personally use.

I just don't know how to have my cake and eat it too.

Re: Transparent telemetry for open-source projects

#182

Post by JohnFen »

BonoboIO wrote: post #175
wrldos wrote: 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…

It really all boils down to meaningful consent.

> if you spy on your Users

In my opinion, any data collection about me or my machines that occurs without my active informed consent is "spying". This is my fundamental problem with opt-out mechanisms. They do not indicate or imply that active consent was obtained.

Re: Transparent telemetry for open-source projects

#183

Post by wrldos »

candiddevmike wrote: post #89

Is this even up for debate, or is this post more of a FYI?

No it's not up for debate at all. Much like when Microsoft did this with .Net core, the Github thread is clearly a misguided post by RSC expecting the community to conform or support it. They didn't so now it's a damage control exercise. It will happen.

Any corporate controlled project on this scale is prone to this failure mode.

Re: Transparent telemetry for open-source projects

#184

Post by oneplane »

userbinator wrote: post #3

Nope, nope, and more nope. You're not moving the Overton Window any more on me. In fact it seems there's a clear correlation between the quality of software and how much spyware there is embedded in it. It's often merely another way to justify unpopular changes with "but the data says so". IMHO if you want to collect any information, it should never be anything but opt-in, a conscious decision.

So how would you design a well-working system to make data-driven decisions rather than guesses? Most collection methods are notoriously bad, but partial collection is also bad since we now have to somehow put a weighing factor on presumed absent data, which turns choices into guesses again.

I think this is a really hard problem, and simply trying to guess in the dark as to what people want isn't the smartest way to go about finding the path forward / priorities / improvements / defects.

It also isn't something that we had in the past, because when we used to buy the IDE, buy the compiler, and then build software, sell that software, and let everyone know what cool tools we used, you'd have sales figures that would inform the creators how the tools were used. Now, the tools are available to everyone, anonymously, and everyone has an opinion on how well it works for them, but doesn't have the time to write a well-written report every time a release happens.

Re: Transparent telemetry for open-source projects

#185

Post by JohnFen »

agwa wrote: post #136
alyandon wrote: post #116

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…

> I think the best suggestion I've seen is that 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.

This is a nonstarter, as DNT demonstrated in spades.

Re: Transparent telemetry for open-source projects

#186

Post by JohnFen »

jodrellblank wrote: post #151
Macha wrote: post #144

Earlier quoted context omitted.

I wouldn't be so sure it's not also a technical problem, the limit of execve can be as low as 128kb which for 4,000 strings gives a maximum of 32 characters per NAME=VALUE environment value

Free disk space can be as low as zero, but we don't blame the tool makers for adding an extra 100Kb or 20MB, we blame the computer owner for not having enough disk space to install the thing they chose. Wrapper scripts for every utility to do UTIL_TELEMETRY_OPT_OUT=1 util ... so they don't need to be set all at once.

> we don't blame the tool makers for adding an extra 100Kb or 20MB

Honestly, I do. Code bloat is a real thing.

Re: Transparent telemetry for open-source projects

#187

Post by JohnFen »

oneplane wrote: post #184
userbinator wrote: post #3

Nope, nope, and more nope. You're not moving the Overton Window any more on me. In fact it seems there's a clear correlation between the quality of software and how much spyware there is embedded in it. It's often merely another way to justify unpopular changes with "but the data says so". IMHO if you want to collect any information, it should never be anything but opt-in, a conscious decision.

So how would you design a well-working system to make data-driven decisions rather than guesses? Most collection methods are notoriously bad, but partial collection is also bad since we now have to somehow put a weighing factor on presumed absent data, which turns choices into guesses again. I think this is a really hard problem, and simply trying to guess in the dark as to what people want isn't the smartest way to…

Telemetry or no, a certain amount of guessing is inescapable.

Re: Transparent telemetry for open-source projects

#188

Post by IanCal »

remus wrote: post #167
masklinn wrote: post #155

Earlier quoted context omitted.

Because that goes against informed consent. Opt-out is generally rejected by European privacy laws.

> Opt-out is generally rejected by European privacy laws. ...where personal data is involved. It strikes me that this proposal goes to considerable lengths to avoid collecting anything that could be considered personal data.

I agree it does do that though for context of others reading the thread personal data is a very broad topic:

https://gdpr.eu/eu-gdpr-personal-data/

You have to be very careful to do it properly.

Re: Transparent telemetry for open-source projects

#189

Post by balena »

remus wrote: post #167
masklinn wrote: post #155

Earlier quoted context omitted.

Because that goes against informed consent. Opt-out is generally rejected by European privacy laws.

> Opt-out is generally rejected by European privacy laws. ...where personal data is involved. It strikes me that this proposal goes to considerable lengths to avoid collecting anything that could be considered personal data.

IANAL but European law is nuanced over whether IP addresses are PII. If I'm not mistaken it's been ruled they are for ISPs, rationale being they have enough other data points that once correlated with IP addresses allow to identify individuals. Whether the same applies to Google (I suppose) is definitely not clear to me.

Re: Transparent telemetry for open-source projects

#190

Post by mbnull »

wrldos wrote: post #161
schmichael wrote: post #12

> the vast majority of projects, even large ones that would benefit, stay away from telemetry. Nomad is one of these projects. We support a dizzying array of platforms (32bit Intel Linux?!). We have no idea how popular our Consul service mesh integration is. Are bug reports a sign of use or just failed experiments? Is anyone running on macOS in production or just ephemeral dev agents? Surveys about this are just aski…

This is an incorrect assertion. We have to ask for permission on our SaaS products to collect this data as it's not necessary to collect it for the product to function. The EU GDPR mandates this. Russ Cox is suggesting that there is no permission step and that the data is collected by default. That is the issue.

From my reading focused on this specific issue of the GDPR and the national laws of member states, this is not the case. Opt-in is specifically required for personal information. The telemetry data outlined in the proposal would not fall under this requirement. You can even retain time-limited IP logs with some special caveats. The GDPR is actually quite reasonable and fair.

Russ Cox is a very intelligent and effective engineer. He has a history of projects where he first analyses the problem space, then arrives at great solutions. He puts a lot of effort into discussing the problems and proposal with the community, especially after the widely criticized go mod decision by the go team (which is now mostly accepted as unfortunate, but in the end, the correct decision, I would think).

My point is: We all suspect Google and telemetry to be bad. But can we be charitable enough to separate the Go project, that is run by individual humans, and telemetry from our superficial cliches to actually read the proposal?

Post reply on HN