> Opt-in telemetry. A very rare sight these days. Glad to see.

Ahem. Cough.

Given Google's ties to Go, of course it was NOT opt-in when originally announced.

After, shall we say, a "lively" discussion on the relevant Github topic[1], it was changed to opt-in. :D

Opt-in is the correct stance.

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

there's infinity things to criticise google for, but "the go team want useful metrics" isn't one of them.

There's the "If you have nothing to hide..." guy.

But it is now, and that's good and should be applauded.

I don't believe the Go team deciding not to break GDPR law after massive backlash is anything that should be applauded.

I'm not really understanding the logic here, but you do you bud.

I'd bet you dollars to donuts that the Go team originally asked for opt-in and got overruled by suits.

You have it backwards. The suits are way more comfortable with privacy violation than the Go team.

You have me backwards cos I had it forwards. I was unclear perhaps.

I meant (a) "someone" (suits?) said let's install telemetry, (b) the Go team said well hey come on let's make it opt-in rather than defaulting to "on", (c) suits said no we just sneak in the default "on" (cos google ebil).

Well I can assure you that is not what happened. Our team tried to come up with a telemetry design that set a higher bar for privacy preservation than the norms of the industry (including Google), something so safe that it would be acceptable to enable by default. Of course, the community rejected it and that plan died. But the "suits" at Google afford our team enough autonomy to act in the best interests of the Go community.

Google is not quite the monolithic James Bond villainy of your caricature.

Glad to hear.

FWIW I wasn't suggesting "villainy" so much as "SNAFU". Google's record on privacy in general leaves something to be desired.

I'm open to being convinced otherwise, but I feel like I'm the only one who doesn't get why opt-out telemetry is such a big deal.

Sure, if it's a software library, I don't want it doing random network calls during my runtime. That's just rude.

But if it's a user application (including a compiler), I don't see what the fuss is about. Of all the myriad of ways our data is harvested every single day, telemetry seems very unhelpful to advertisers and hackers, but very helpful to the people whose job it is to make the software you use better. I'd love to help them make the software I use better

Privacy concerns aside, I personally don't appreciate binaries making network requests unless it's strictly required for them to function.

Where is that line for you? Is occasionally checking for security updates strictly necessary? Is reporting a crash to the devs so they can fix it necessary? What about sending system & usage telemetry so they can prevent future bugs?

For me, it's like GP said: Absolutely no unauthorized network traffic unless strictly required for the purpose of the software (e.g. curl). No security updates, crash reporting, telemetry unless you prompt the user and show the user exactly what will be sent (similar to how syncthing does it).

Anything less is voyeurism.*

* extreme language I know, but it's precisely how I feel about these acts.

> Where is that line for you?

None of the above is acceptable. Crash reporting can generate its output locally for people to manually send, if they choose to do so.

Do you know the definition of the word strictly? No, security and upstream convenience are not even remotely necessary for a tool to work

You don’t know what they are sending. Maybe today it is innocuous data. Tomorrow, they ship off your ssh keys.

Better to default deny all.

A program that does not connect to the network at all today can also start shipping off your ssh keys tomorrow. Anything can always be added or changed.

Probably a higher chance of that being noticed though. ;)

There was a lengthy discussion to persuade them to not have it on by default: https://github.com/golang/go/discussions/58409

> Opt-in telemetry. A very rare sight these days.

Because it doesn't work. o:-)

(Introduces a slant/bias to the data.)

https://twi.github.io/blog/making-go-telemetry-opt-in-is-a-m...

Same with opt out.

Just have to accept that you are not going to get perfect data. And it doesn't excuse one to behave like an asshole.

You forget that most people here work at startups that have compulsory telemetry.

Google can already see every installation of every Go program/package in existence, unless you set GOPROXY=direct (or a custom proxy). The default is to use https://proxy.golang.org, which is operated by Google.

The default proxy has a privacy policy: https://sum.golang.org/privacy.

But better than this is would be if my go tooling didn't default to trying to pull codebases through a proxy

Forgive me for being cynical, but I don't like that out of the box the toolchain tries to pull all the code at `example.com/business/logic` through google servers.

It seems like the right way to respect a user's privacy, but opt-in telemetry just doesn't work.

I see the concerns as a user (and disable telemetry wherever I can), but at the same time if I were to add telemetry to my OSS project, I would either make it opt out, or just not add it at all.

The people who actually enable telemetry are a huge minority, and the data collected would be completely useless due to bias.

The best way, in my opinion, is to have completely unidentifiable telemetry (not sure if something like this even exists), or nothing at all.

> The best way...

The best way is not to have telemetry at all. But then that's a user-centric take.

Until they decide it to be enabled by default.

Exactly. Give it a couple of releases and the default "for new installations" will be On. Two more releases and all other installs will be opted in. Classic pattern for shoveling stuff down the throat of resisting gray masses.

At which point us, the Linux packagers and other package maintainers, is just going to patch it out. I wouldn't be very worried.

And Google makes you call it something other than Go, like Firefox did to linux packagers:

> The Go trademark and the Go Logo ( ) – collectively, the “Go Trademarks” – are trademarks of Google and are treated separately from the copyright license grants contained in the BSD-licensed Go repositories, as described below.

> Substantially unmodified distributions¶

> Substantially unmodified distributions may use the Go Trademarks if the derivative work complies with the terms of the Go programming language’s open source license and is made in a good faith attempt to replicate the quality and substance of the original project.

> Examples of modifications that would be considered substantially unmodified include language translation and localization, bug and security patches, and necessary interoperability/compatibility modifications.

> The Go Trademarks may be used in connection with such substantially unmodified distributions following the “Naming Conventions for Authorized Uses”.

> Substantially modified distributions may include explicit changes to functionality, interfaces, or features.

They can modify these trademark terms later too with a "backwards incompatible" change:

> Guideline Version¶

> These Trademark Guidelines are version 1.0 and may be followed by subsequent versions. These Guidelines may be edited for clarity; the major version will be increased when changes introduce new requirements, define new criteria, or otherwise present a backwards incompatible change.

It's not 2006 anymore.

I don't understand what you mean by this. Are you saying you can patch out telemetry in Linux package managers are Firefox doesn't care? What does that have to do with 2006? I think GP has a valid point otherwise as people will just install the thing named Firefox and not check to see if there is a telemetry free version going by a different name.

Sir, you seem to have dropped your tinfoil hat.