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

31–40 of 74 posts

Re: The design of transparent telemetry

#31

Post by orbital223 »

dewey wrote: post #8
traceroute66 wrote: post #4

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.

> This is very uninteresting data to Google.

It's not about how interesting the data is to them, it's about the hubris of believing they are entitled to every last bit of our data.

Re: The design of transparent telemetry

#32

Post by none_to_remain »

rapnie wrote: post #9

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

Incredibly disrespectful.

At first glance I'm not a big fan of this proposal, but I'm probably less opposed to it per se, and for different reasons, than the typical commenter.

But the behavior of "rsc" and "mvdan" there is just enormously decrementing my opinion of the Golang team.

Re: The design of transparent telemetry

#33

Post by AeroNotix »

mort96 wrote: post #27
verdverm wrote: post #24

Earlier quoted context omitted.

Have you read their proposal and blog posts? A Go installation will send a report ~1 per year on average This is not Google telemetry or analytics, this is independent Go telemetry and is very different I suggest everyone read about Transparent Telemetry before overreacting. It's honestly quite reasonable and will benefit everyone

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.

Re: The design of transparent telemetry

#34

Post by ls65536 »

traceroute66 wrote: post #25
verdverm wrote: post #16

Earlier quoted context omitted.

This is not adding telemetry to your code, it is very minimal telemetry within the go toolchain. They expect a user will send a week's worth of counters to the server once a year on average. It does not push telemetry on your users

> 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 the Golang maintainers that this is where it would stop (have they communicated anything to that effect?), we have no reason to believe it will stop here, and all the more reason to be concerned that this is just the beginning and it will be pushed much further in the future.

Re: The design of transparent telemetry

#35

Post by none_to_remain »

mynameisvlad wrote: post #28
none_to_remain wrote: post #18

Earlier quoted context omitted.

If mort96 is writing libraries it does

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.

Re: The design of transparent telemetry

#36

Post by mort96 »

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.

I know it can be disabled. Whether an environment variable is "trivial" or not is certainly up for discussion. We're talking about, "never ever run the command on a system without the invonment variable set globally or in a context where the environment doesn't apply". (Did you know `sudo` strips most env vars? `sudo -u www-data go build` would send telemetry even if you added the env var to your profile)

It's trivial to disable telemetry for any given invocation, but making sure that no invocation at all, across decades, is far from trivial.

Re: The design of transparent telemetry

#37

Post by verdverm »

ls65536 wrote: post #34
traceroute66 wrote: post #25

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…

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 the Go compiler to all Go programs in the world: that’s clearly inappropriate.

Re: The design of transparent telemetry

#38

Post by josephcsible »

saagarjha wrote: post #3

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.

Re: The design of transparent telemetry

#39

Post by verdverm »

traceroute66 wrote: post #26
speedgoose wrote: post #11

Earlier quoted context omitted.

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…

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

Re: The design of transparent telemetry

#40

Post by verdverm »

none_to_remain wrote: post #32
rapnie wrote: post #9

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

Incredibly disrespectful. At first glance I'm not a big fan of this proposal, but I'm probably less opposed to it per se, and for different reasons, than the typical commenter. But the behavior of "rsc" and "mvdan" there is just enormously decrementing my opinion of the Golang team.

mvdan is not on the Go team, he works on CUE primarily, he has been a volunteer for a long time.

Can you point out specific comments that you find problematic? I have looked and am not sure which ones you are referring to

Post reply on HN