majorhelmet (u/majorhelmet)

majorhelmet commented on Making Go telemetry opt-in is a mistake twi.github.io/blog/making... · Posted by u/m90

PaulKeeble · 3 years ago

For those conscious of the security implications of that code even existing it all comes down to whether you trust Google, I would argue at this point you definitely shouldn't. Given that if you program in Go now and have code you really wouldn't just give Google then you probably need to run all your go executions in a VM without network access. This alone is going to be ardious enough from a security point of view to make other languages more interesting.

The entire idea is bad, the defaulting reduces the impact to many but the very existence of this telemetry is enough to take more significant security defence against the tool. Once you start doing that as an organisation Go becomes legacy with a strong desire to replace it. Its definitely a mistake to make it opt in, the data will be lower quality and it will still drive security concerns.

majorhelmet · 3 years ago

> all comes down to whether you trust Google

Not true. The code is open source and everyone can trivially with minimal effort check that they are sending only the data they said they would send.

majorhelmet commented on Making Go telemetry opt-in is a mistake twi.github.io/blog/making... · Posted by u/m90

jonhohle · 3 years ago

`telemetry-on` flag. Sending data to third parties should _never_ be implicit or the default. Every PM, marketer, and mid-level manager needs to be firmly reminded that this is grossly invasive, user-hostile, impolite, and creepy.

Without an explicit agreement, it could even run afoul of wiretapping laws (unresolved in courts, as far as I’m aware).

majorhelmet · 3 years ago

I still think it depends on the telemetry itself. Companies knowing my location at all times? Disgusting and creepy. Company knowing I ran `go help` 200x as opposed to running `go build` 10x is fine imho.

majorhelmet commented on Making Go telemetry opt-in is a mistake twi.github.io/blog/making... · Posted by u/m90

speedgoose · 3 years ago

Respecting the users wishes isn’t a mistake. For sure it may have a few digits less of accuracy in some dashboards but who cares.

The consensus was that opt-in was the best solution, and thankfully Google went with the best solution.

majorhelmet · 3 years ago

Users wishes would be respected in both opt-in and opt-out scenarios.

majorhelmet commented on Making Go telemetry opt-in is a mistake twi.github.io/blog/making... · Posted by u/m90

yalue · 3 years ago

Here's an idea for how to maintain Go moving forward: keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward. Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem, they can fix it and upstream a patch. That's how open source software is always supposed to work. Telemetry does nothing to improve this situation. If the Go team at google no longer has any ideas for what to work on (as must be the case if they're wasting their time on dumb crap like forced google spyware in a compiler) then they should just stop. Maybe focus on accepting PRs from people with ideas and strong enough motivation to work on them. I mean, there are 5000+ issues and 330 open PRs on the go github right now, so that should be plenty to keep them occupied. On top of that, how can literal thousands of issues not be a strong enough source of actionable usage information that they saw fit to try to get more? Do they plan on wrapping up all the open issues before looking at telemetry?

majorhelmet · 3 years ago

> Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem, they can fix it and upstream a patch.

Inbefore I go to a new job and find out that they are using outdated, custom patched go compiler.

> I mean, there are 5000+ issues and 330 open PRs on the go github right now

How do they know which ones are affecting the most users?

> forced google spyware in a compiler

go is open source, feel free to compile it yourself without the telemetry. Which distros will do if any major promises would be broken

majorhelmet commented on Making Go telemetry opt-in is a mistake twi.github.io/blog/making... · Posted by u/m90

greatgib · 3 years ago

I think that the author has kind of a Stockholm syndrome.

"Users are liars, so let's spy them directly to know what we want to know".

It is mind blowing how, as an user/the target, you can support that.

Nothing is really anonymous and your anonymous data can say a lot about you.

Telemetry coming from this IP, so company x is using go. A pattern of data coming every 2 days, so their build nodes rebuild every 2 days. That kind of build pattern is there, so they are using the xxx crypto library...

And when they say, let's trust Google, I would propose to Google to accept the opposite:

Now they will transmit to the public telemetry of their internal systems: how many users, what do they do, how many users they block, for what reason, how many build nodes they have, how many commits, how long the go team is spending looking at telemetry reports, which website are the more visited by Google employees,...

And let's see if they will accept. It's for the good of the world, why they would refuse?

majorhelmet · 3 years ago

Look, I hate large corps too but this paranoia hinders open source's ability to self-cooperate.

> Telemetry coming from this IP, so company x is using go. A pattern of data coming every 2 days, so their build nodes rebuild every 2 days.

Not true. Even if Google lied about collecting IPs, the data would be sent only every ~ year with aggregated counts so no real time usage data. And even if one could see the patterns from the data, everyone will be able to, not just Google.

Let's not trust Google. But let's not shoot ourselves in the foot by refusing any automated cooperation.

Additionally, majority of distros use package managers, so if any of the major promises of the upstream would be broken, distro packages could patch it out. This isn't forced, there are several points where anyone can stop the telemetry.