51–60 of 74 posts
It's a good idea as long as they actually have some good motivation for capturing data. If it's just "we're curious" then I don't think that is good enough.
Many of the questions they hope to answer are here https://research.swtch.com/telemetry-uses
The final link in the post is relevant to mention. Pointing to the Github discussion related to this idea: https://github.com/golang/go/discussions/58409
Locking the conversation and marking many disagreeing comments as spam or off-topic doesn’t look good for Golang. I know that managing a community online is difficult especially when the community is against a decision, but I think Google employees should communicate better. The most straightforward path for them is to announce that they have changed their mind about telemetry. Or everyone should use Rust instead, ob…
From what I understand of the conversation there, the core Go team said they were going to take some time to digest the feedback, including [0]:
> The goal here is a productive conversation that aims at better understanding of different positions. Many comments here have contributed to that, and I am grateful for them. To be extra clear, the people who have been discussing opt-in vs opt-out respectfully and with reasoned arguments are most welcome here and have been an important part of the signal, not the noise. Thank you to them in particular.
> Much of the moderation is being done by volunteer contributors working valiantly to keep the conversation on track, polite, useful, and non-repetitive. I appreciate their efforts.
> This discussion has in fact scaled somewhat beyond what GitHub discussions can reasonably manage (I just spent a while clicking every "load more" link on the page to make ^F work again), which is causing even more repetition, so I will probably lock the discussion at the end of the day and take some time to think about the feedback we've gathered so far.
[0] https://github.com/golang/go/discussions/58409#discussioncom...
Earlier quoted context omitted.
Telemetry can be disabled trivially.
There was a Nobel Prize in Economics awarded specifically for recognizing that things "disabled trivially" generally won't be, and this is a fully generic method of denying people their agency. See [0]. Opt-out, in most cases, is malicious, and you only think about introducing it when you're trying to make a change that leaves your users worse off. -- [0] - https://en.wikipedia.org/wiki/Richard_Thaler#Nobel_Prize
I’m of course not comparing telemetry to organ donation, but I do feel that the problem is often overblown and is not that big of a deal. There is not much evil in trying to find out how many people used your toolings and from which OS approximately. (I dislike the Go language as much as it gets, so I am as unbiased as it gets)
Earlier quoted context omitted.
> This is not adding telemetry to your code Yet .... It could easily be only a matter of time before we see feature creep and another "proposal", this time to insert it into the binaries.
This is a valid forward-looking concern that I think needs to be much more clearly addressed. It's one thing to have default-enabled telemetry in the toolchain itself, but once that window is open it's going to be much more difficult to close it and stem the tide of telemetry features creeping in further elsewhere in the Golang ecosystem where they'd be much more of a privacy concern. Without a strong commitment from…
Opt-out sucks.
Earlier quoted context omitted.
> Locking the conversation and marking many disagreeing comments as spam or off-topic doesn’t look good for Golang. Yes, I noticed that. Particularly given the discussion at hand (telemetry), employing heavy handed moderation tactics is not a good look.
They likely locked it because people are 1. Overreacting without reading the proposal and blog posts and making inaccurate conclusions 2. Violating the Go Community Code of Conduct ( https://github.com/golang/go/discussions/58409#discussioncom... )
https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/twcLx...
Earlier quoted context omitted.
There was a Nobel Prize in Economics awarded specifically for recognizing that things "disabled trivially" generally won't be, and this is a fully generic method of denying people their agency. See [0]. Opt-out, in most cases, is malicious, and you only think about introducing it when you're trying to make a change that leaves your users worse off. -- [0] - https://en.wikipedia.org/wiki/Richard_Thaler#Nobel_Prize
That’s true, but there is another side to this same coin — people won’t do the right thing if it’s opt-in. Organ donation’s percentages are the two ends of the spectrum simply depending on opt-in/out. I’m of course not comparing telemetry to organ donation, but I do feel that the problem is often overblown and is not that big of a deal. There is not much evil in trying to find out how many people used your toolings a…
Now when I first learned about all this, I loved the organ donation and retirements plans examples - this all seemed like a brilliant hack to leverage human nature for greater good! However, my view on this flipped almost 180° over time. Two major reasons for this are:
1. Software industry. I actually deleted the long rant, because I have a specific, highly negative opinion of the business side of the industry - but we could debate that one all night, and it's not the main thing I want to say.
2. I actually brought the organ donation and retirement plan arguments up with family and friends, and was surprised by how much pushback I received in response. The specifics of each counter varied due to individual beliefs on those particular issues and politics in general, however the overall shape of the counterargument was always the same:
"I agree that having more people ${opting to donate organs, having a retirement plan} is good for everyone, and I understand there's a pool of people who don't make that choice simply because they never thought of it, don't care either way, or find opting in too difficult. Personally, ${I'm already signed up, I would consider signing up}.
However,
if they would do a trick like this to me, I would be angry. I have a right to be informed and make a choice on my own. This is denying me that choice, it's patronizing. If this was done to me, I would opt-out out of spite - in fact, just hearing now that people do this makes me want to not participate. After all, if it was all good-intentioned, they'd be up-front about it. Nudging with opt-outs smells like a scam."
Hell, a close family member said plainly to me that, hearing about this idea, they're now very skeptical about organ donation, and will no longer consider signing themselves up.
I tried to respond to people saying this. I tried to find a flaw in the overall spirit of their counter, tried to find a counter-counter of my own. But after many conversations, I instead found that I agree. On paper, opt-outs sound like super useful trick for doing good. In practice, they're predominantly used for bad, to exploit and abuse people. People know it, people feel it, and people also (even if irrationally) feel patronized by such attempts. As a result, even if you're 100% honest and well-intentioned with your opt-outs, whatever good you achieve this way comes at a cost of burning trust in the whole market/problem space.
The organ donation example now haunts me a little. Sure, signing people up by default may save lives in the short term - until enough people realize they haven't been given the respect and consideration that comes with decisions this big. Then those people will opt out, saying they've been used, and then others will follow, and then more people will die because of the bad reputation of the medical system wrt. organ donations.
Earlier quoted context omitted.
> why the option of “we ask the user when they install what they want” is not explored. Because Go == Google, and when has Google "asked the user" before slurping data? If they are going to do it, it should only ever be on an OPT-IN basis.
This is very uninteresting data to Google. They are interested in personal data that you can use to optimize targeted ads, not compiler cache miss counts from your local development workflow. The reasoning for not making this opt-in are in the blog post and I find them reasonable.
In general, when looking at telemetry data, you can't stop at asking "what possible use would the org collecting it have for it right now, in their current business model". You need to also ask what use they could potentially have for it in the future, especially combined with other data they have access to. A year from now, or five years from now, or after a pivot, or after partnering with (or buying) a company in a different industry, or after leaking (or selling) it to third parties.
When you ask these questions, I think you'll also conclude that enabling telemetry by default and pinky swears they're not doing anything naughy with it is not good enough. You may trust the people doing it now, but as experience shows, business priorities change, people in charge change, but the collected data remains.
Earlier quoted context omitted.
This is very uninteresting data to Google. They are interested in personal data that you can use to optimize targeted ads, not compiler cache miss counts from your local development workflow. The reasoning for not making this opt-in are in the blog post and I find them reasonable.
If you think this data is not interesting to Google, I think you're not using your imagination enough. Even "compiler cache miss counts from your local development workflow" could be used as a signal to optimize ads for development tooling. Or hardware. In general, when looking at telemetry data, you can't stop at asking "what possible use would the org collecting it have for it right now, in their current business m…
There's many ways to get valuable data for ad targeting, this is not one of them.
If they want to turn bad, they can just use the dependency proxy.golang.org / sum.golang.org that already exist for a long time. Or gather data on things running in Google Cloud. All of these would be unlikely, and bigger levers than gathering some data from a few Go developers.
IMO the only part of this article that is general enough to discuss is the bit about opt-out telemetry; everything else is just slapping technical solutions and attempts at preserving privacy on top of an opt-out system. On that front, I find it confusing why the option of “we ask the user when they install what they want” is not explored. It’s given as an example in the article, and then there’s a whole section abou…
> I find it confusing why the option of “we ask the user when they install what they want” is not explored. I don't. It's because they know that most people don't want this, and will say no if asked, but won't realize they need to opt out if it's just silently enabled by default.