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

61–70 of 74 posts

Re: The design of transparent telemetry

#61

Post by ad404b8a372f2b9 »

alkonaut wrote: post #60
josephcsible wrote: post #38

Earlier quoted context omitted.

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

Most users don’t want to send telemetry. But most users also want a system built by people who understand how users use it.

You can achieve 99% of that by using your own product and talking to your customers, and everybody managed to do just that and to make useful products long before telemetry became ubiquitous.

Re: The design of transparent telemetry

#62

Post by TeMPOraL »

dewey wrote: post #59
TeMPOraL wrote: post #58

Earlier quoted context omitted.

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…

A set of static, anonymous metrics, updated _once_ a year from a tiny fraction of developers is not worth the effort to even ingest into some targeting system. 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.…

There are many other applications for data than just ad targeting.

The pushback here may seem paranoid for the specifics of this particular case, but that's because it comes from a more generic and IMHO perfectly justified position of treating all telemetry as risky by default, and all attempts at making it opt-out as wrong, dangerous, and likely malicious.

The arguments "for" are all based on assertions about this particular case at this particular point in time. The data to be collected is benign. Collecting it will translate to meaningful improvements being delivered faster. The people behind the project are all nice and reputable. And so on. In contrast, the arguments "against" cover the possible future evolution of the telemetry itself, as well as the project and the people behind it. The set of metrics and reporting frequency can change. The goals behind it can change. The nice people might turn naughty, or be replaced by scoundrels.

The arguments "against" include, in particular, building the precedent and infrastructure. From that point of view, you saying:

> set of static, anonymous metrics, updated _once_ a year from a tiny fraction of developers is not worth the effort to even ingest into some targeting system

sounds to me like me saying "this browser extension, which code I audited myself, is only reading the account numbers and names from my banking page - it's really not worth anyone's effort to do anything naughty with it, so there's no reason I should be afraid of giving it full read and write permissions for the banking page, and no reason I shouldn't leave the 'auto-update' checkbox on".

Re: The design of transparent telemetry

#63

Post by eestrada »

ad404b8a372f2b9 wrote: post #61
alkonaut wrote: post #60

Earlier quoted context omitted.

Most users don’t want to send telemetry. But most users also want a system built by people who understand how users use it.

You can achieve 99% of that by using your own product and talking to your customers, and everybody managed to do just that and to make useful products long before telemetry became ubiquitous.

I would argue that using your own product and talking to your customers is the only way to make good and useful products. Telemetry may have a good use case (although I struggle to find one), but it isn't a substitute for dogfooding and direct customer interaction.

Re: The design of transparent telemetry

#64

Post by vlovich123 »

> The server would necessarily observe the source IP address in the TCP session uploading the report, but the server would not record that address with the data, a fact that can be confirmed by inspecting the reporting server source code (the server would be open source like the rest of Go) or by reference to a stated privacy policy like the one for the Go module mirror, depending on whether you lean more toward trusting software engineers or lawyers. A company could also run their own HTTP proxy to shield individual system’s IP addresses and arrange for employee systems to set GOTELEMETRY to the address of that proxy. It may also make sense to allow Go module proxies to proxy uploads, so that the existing GOPROXY setting also works for redirecting the upload and shielding the system’s IP address.

I wonder if Apple’s Private Relay [1] mechanism might be a safer path that doesn’t rely on operators actually running the open source version verbatim nor on the privacy policy.

Disclaimer: I work at Cloudflare.

[1] https://blog.cloudflare.com/icloud-private-relay/

Re: The design of transparent telemetry

#65

Post by musicale »

typical182 wrote: post #52
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…

FWIW, people had started to post obscene ASCII drawings, were using various curse words, and there were many, many repetitive comments across the ~400 comments posted. 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…

> people had started to post obscene ASCII drawings, were using various curse words, and there were many, many repetitive comments across the ~400 comments posted

Sounds like an appropriate and commensurate response to this terrible idea.

Re: The design of transparent telemetry

#66

Post by deafpolygon »

stonogo wrote: post #56
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... )

Russ Cox gave his reasons in the Google Group. https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/twcLx...

> * Can we trust the server or Google to not track IP addresses?

Well, no. I think we all know the answer to that. Telemetry and tracking is in their culture. Their culture is embedded in advertising - why trust anything an advertising company wants to do?

Re: The design of transparent telemetry

#67

Post by deafpolygon »

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.

https://en.wikipedia.org/wiki/Boiling_frog

Re: The design of transparent telemetry

#68

Post by deafpolygon »

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…

That's pretty common. It's what you say to your kid when they want to go to the amusement park this weekend, but you don't want to disappoint them right that second so you say something to push it off until you figure it out.

Re: The design of transparent telemetry

#69

Post by deafpolygon »

eestrada wrote: post #63
ad404b8a372f2b9 wrote: post #61

Earlier quoted context omitted.

You can achieve 99% of that by using your own product and talking to your customers, and everybody managed to do just that and to make useful products long before telemetry became ubiquitous.

I would argue that using your own product and talking to your customers is the only way to make good and useful products. Telemetry may have a good use case (although I struggle to find one), but it isn't a substitute for dogfooding and direct customer interaction.

The true use case here is to get you used to the idea of telemetry in your tool chain, then move the goal post further down the road. In a few years, it'll be encouraged to put telemetry in your library ("Why?" "We've already had it in the tool chain this isn't any different!") then eventually, have every application sending telemetry data to Google's servers.

If you think this is ridiculous, remember they built Chrome with telemetry embedded .. why? Not for improving services. To build better targeted advertising.

Remember Android OS? Yes.

But there's still push back and the primary group of people resisting this at large are developers and the more technically inclined.

Re: The design of transparent telemetry

#70

Post by deafpolygon »

orbital223 wrote: post #31
dewey wrote: post #8

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.

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

Let's not forget the https://en.wikipedia.org/wiki/Boiling_frog
Post reply on HN