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

The design of transparent telemetry

research.swtch.com

Post reply on HN
Print view View original

41–50 of 74 posts

Re: The design of transparent telemetry

#41

Post by mynameisvlad »

none_to_remain wrote: post #35
mynameisvlad wrote: post #28

Earlier quoted context omitted.

How? The telemetry is still only present in the toolchain. A library would be imported and built, and could trigger the telemetry collection, sure, but in what way would that be considered "part of their code". If another developer is using their library, then it would ostensibly be a go developer who themselves has chosen to opt in or out of the telemetry, so they wouldn't be pushing it onto their users either.

If there are a wide variety of well-maintained libraries available in Go, people are more likely to pick Go, or even feel compelled to choose it, and possibly be subject to telemetry. If the bulk of developers cease to create or maintain Go libraries, fewer people will use Go and be subject to its telemetry.

I'm sorry, but that's an absurd argument.

Your argument is that one user publishing a library in a sea of libraries which enriches the ecosystem is equivalent to directly pushing telemetry onto their users.... Because people are enticed by golang as a whole?

One library isn't going to be the deciding factor in someone choosing a language, and they'll likely have to deal with telemetry well before they get to a random library.

And that still doesn't answer the question on how that possibly means telemetry gets injected into their code.

Re: The design of transparent telemetry

#42

Post by traceroute66 »

verdverm wrote: post #39
traceroute66 wrote: post #26

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

> 1. Overreacting without reading the proposal and blog posts and making inaccurate conclusions

As was pointed out multiple times during the ensuing "discussion":

    1. The proposal and blog posts were heavily biased, if not one-sided (highlighting only "pros", no "cons", pushing towards the only option being "opt-out" etc. etc.)

   2. Posts in opposition to the proposal were being moderated in a heavy handed fashion through the Github hide function etc.

   3. Valid answers were not being provided to those in opposition to the proposal, instead the answers were largely brushed aside with dismissive waffle.
Thus the only conclusion it was locked is because the discussion was not going in the desired direction, i.e. supportive of the proposal.

Re: The design of transparent telemetry

#43

Post by TeMPOraL »

AeroNotix wrote: post #33
mort96 wrote: post #27

Earlier quoted context omitted.

I'm not sure if you're aware, but the official Go tooling is developed and managed by Google; the decision makers and core developers are Google employees. Go is deeply died to Google. I'm not comfortable asking my users to send telemetry information to Google. The exact details aren't very important. People can make their own decisions about whether they're fine with it or not, but I'm not going to push people towar…

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

Re: The design of transparent telemetry

#44

Post by traceroute66 »

verdverm wrote: post #37
ls65536 wrote: post #34

Earlier quoted context omitted.

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…

From the issue on GitHub, Russ believes it would be "clearly inappropriate" to push telemetry into user code, so yes, they have communicated their opinion on this > To be clear, I am only suggesting that the instrumentation be added to the Go command-line tools written and distributed by the Go team, such as the go command, the Go compiler, gopls, and govulncheck. I am not suggesting that instrumentation be added by…

> Russ believes it would be "clearly inappropriate" to push telemetry into user code, so yes, they have communicated their opinion on this

Erm, not quite....

Somebody explicitly asked (on one of the moderator hidden posts, I might add) "@rsc Can you guarantee that this will always be the case?"[1]

The answer was wishy-washy to put it politely:

"I can't guarantee we'll all still be here tomorrow. But for as long as Go exists and is developed, I expect that interested open source contributors like yourselves will notice and flag changes that move backward. That seems to me a more useful check on the future evolution of Go than anything I promise."

Saying "you'll have to notice and flag it" is not exactly reassuring. Especially given the way the Go team have been reacting to the "flagging" on the telemetry discussion itself !!

[1] https://github.com/golang/go/discussions/58409#discussioncom... [2] https://github.com/golang/go/discussions/58409#discussioncom...

Re: The design of transparent telemetry

#46

Post by none_to_remain »

mynameisvlad wrote: post #41
none_to_remain wrote: post #35

Earlier quoted context omitted.

If there are a wide variety of well-maintained libraries available in Go, people are more likely to pick Go, or even feel compelled to choose it, and possibly be subject to telemetry. If the bulk of developers cease to create or maintain Go libraries, fewer people will use Go and be subject to its telemetry.

I'm sorry, but that's an absurd argument. Your argument is that one user publishing a library in a sea of libraries which enriches the ecosystem is equivalent to directly pushing telemetry onto their users.... Because people are enticed by golang as a whole? One library isn't going to be the deciding factor in someone choosing a language, and they'll likely have to deal with telemetry well before they get to a random…

OK, I was imprecise, writing a library in this hypothetical future Go would not add telemetry to developers' code, but it would contribute to inducing those developers to use the hypothetical telemetry-enabled Go toolchain. One library is probably not the deciding factor, but an ecosystem of libraries is just many thousands of instances of "one library".

Re: The design of transparent telemetry

#47

Post by verdverm »

traceroute66 wrote: post #42
verdverm wrote: post #39

Earlier quoted context omitted.

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

> 1. Overreacting without reading the proposal and blog posts and making inaccurate conclusions As was pointed out multiple times during the ensuing "discussion": 1. The proposal and blog posts were heavily biased, if not one-sided (highlighting only "pros", no "cons", pushing towards the only option being "opt-out" etc. etc.) 2. Posts in opposition to the proposal were being moderated in a heavy handed fashion throu…

> Posts in opposition to the proposal were being moderated in a heavy handed fashion

> brushed aside with dismissive waffle

> Thus the only conclusion ...

It's hard to take your response seriously when you only offer

> heavily biased, if not one-sided

opinions.

If you want to make an argument that can convince people, it is best to not use polarizing language.

Most of the hidden comments are of very low quality or do not add to the discussion. Others are off topic. Many dissenting comments remain. So this "heavy handed moderation" you describe is not really accurate

Re: The design of transparent telemetry

#48

Post by verdverm »

traceroute66 wrote: post #44
verdverm wrote: post #37

Earlier quoted context omitted.

From the issue on GitHub, Russ believes it would be "clearly inappropriate" to push telemetry into user code, so yes, they have communicated their opinion on this > To be clear, I am only suggesting that the instrumentation be added to the Go command-line tools written and distributed by the Go team, such as the go command, the Go compiler, gopls, and govulncheck. I am not suggesting that instrumentation be added by…

> Russ believes it would be "clearly inappropriate" to push telemetry into user code, so yes, they have communicated their opinion on this Erm, not quite.... Somebody explicitly asked (on one of the moderator hidden posts, I might add) "@rsc Can you guarantee that this will always be the case?"[1] The answer was wishy-washy to put it politely: "I can't guarantee we'll all still be here tomorrow. But for as long as Go…

Saying he cannot guarantee in no way invalidates the team's stance and beliefs on the matter.

Citing toxic users does not help your argument

Re: The design of transparent telemetry

#49

Post by mynameisvlad »

none_to_remain wrote: post #46
mynameisvlad wrote: post #41

Earlier quoted context omitted.

I'm sorry, but that's an absurd argument. Your argument is that one user publishing a library in a sea of libraries which enriches the ecosystem is equivalent to directly pushing telemetry onto their users.... Because people are enticed by golang as a whole? One library isn't going to be the deciding factor in someone choosing a language, and they'll likely have to deal with telemetry well before they get to a random…

OK, I was imprecise, writing a library in this hypothetical future Go would not add telemetry to developers' code, but it would contribute to inducing those developers to use the hypothetical telemetry-enabled Go toolchain. One library is probably not the deciding factor, but an ecosystem of libraries is just many thousands of instances of "one library".

This:

> but it would contribute to inducing those developers to use the hypothetical telemetry-enabled Go toolchain.

does not follow from this:

> One library is probably not the deciding factor, but an ecosystem of libraries is just many thousands of instances of "one library".

An ecosystem becomes enticing due to a number of factors. Availability of libraries is one thing, but so is the language, tooling, and general popularity. Those are all interdependent as a thriving ecosystem will generally mean better tooling and more focus being put on the language development, which boosts the language's popularity.

A user is going to choose a language based on all these factors, and while a large number of libraries would be one of the factors in favor, telemetry would be one against. It's up to the developer choosing the language to weigh these factors, not the individual library developers. Nor does writing a library for a particular language "push telemetry onto their users" unless the library is actually pushing telemetry directly onto their users. The language or tooling doing it does not equate to the library itself doing it.

Re: The design of transparent telemetry

#50

Post by verdverm »

none_to_remain wrote: post #46
mynameisvlad wrote: post #41

Earlier quoted context omitted.

I'm sorry, but that's an absurd argument. Your argument is that one user publishing a library in a sea of libraries which enriches the ecosystem is equivalent to directly pushing telemetry onto their users.... Because people are enticed by golang as a whole? One library isn't going to be the deciding factor in someone choosing a language, and they'll likely have to deal with telemetry well before they get to a random…

OK, I was imprecise, writing a library in this hypothetical future Go would not add telemetry to developers' code, but it would contribute to inducing those developers to use the hypothetical telemetry-enabled Go toolchain. One library is probably not the deciding factor, but an ecosystem of libraries is just many thousands of instances of "one library".

The more Go grows, the lower the probability that any one installation will send data, per the proposal.

https://research.swtch.com/telemetry-intro#summary > sampling bullet point

Post reply on HN