Is it not consent if you tell the user that it's on, how to turn it off, and the user confirms the prompt having decided to not disable telemetry?

Because that's how OP framed it. There is an ethical way to track how your app is used, with user consent.

Putting text on the screen which would inform the user if the user was to read and comprehend it is not consent, no. (I mean, try to apply that logic to any other situation. You put a post-it note somewhere noticeable which says that you will silently mix some medication into your coworker's lunch unless they write some text on another post-it note placed on the kitchen fridge. When you then notice the absence of that second post-it note, and mix in some medication into their food, is that "consent"?)

Furthermore, looking at the asciinema from OctoSQL, users apparently have to edit their profile files on every single machine they intend to use Go on, then remember to verify that the profile applies and has no typos, make sure to never ever accidentally run the program in a context where environment variables aren't respected (would you remember to always use `sudo -E` if you need to use the tool as another user for example?). The danger seems extremely high that the user would, at some point, accidentally run the command without the env var set, even if they were technically proficient and did their best to opt out.

This is not how consent works.

No because consent is required for it to be on in the first place.

How would you use compiler telemetry to spy on people?

Working hours, work location, home location, favourite cafes, sick days, vacations, hotels, wealth level. And that's just from IP addresses and timestamps alone, and without cross-referencing with all the data that Google vacuums over other channels.

That ship has already sailed. The Go tool already by default makes network requests to the Go proxy, which potentially allows everything that you're talking about there. What's significantly different about this telemetry proposal?

A couple things IMO.

First, making network requests when downloading packages is necessary for the tool to function and unavoidable. People who care about this will be using a VPN of some kind. It's just how the Internet works. But telemetry is something the tool author is choosing to add, not something that's necessary due to the architecture of our computing infrastructure.

Second, the Go telemetry would apparently create a unique, persistent user ID. Normal Internet use doesn't, there's just the IP address which is different from location to location, shared by a bunch of people behind the NAT, and can be masked using common tools.

And yeah, I know this is "anonymised"... but if you have one user ID which uses Go sometimes with an IP address from a particular apartment complex land sometimes from a particular office space, finding out which individual that user ID belongs to is trivial.

> First, making network requests when downloading packages is necessary for the tool to function and unavoidable.

It's technically not unavoidable. The Go authors could have made use of the proxy opt-in rather than opt-out, making the tool less usable as a result. A similar argument applies here, I think.

> Second, the Go telemetry would apparently create a unique, persistent user ID

Where did you see this? I scanned through the "Telemetry Design" article reasonably carefully and couldn't find any mention of this concept, and the type definition for the posted JSON (the `Report` type) doesn't seem to include any such user ID.

In the end, ISTM that you're not complaining about something that actually affects your privacy in any way, but just the _idea_ of telemetry. Is that really something worth taking such a hardline stance on?

> The Go tool already by default makes network requests to the Go proxy

Frankly, that crap should be expunged from the Go toolchain as well. :(