Hacker News Reader

Comment by sophacles | Hacker News Reader

So, is it time to fork the go codebase and have a telemetry-free version?

I understand that there are uses for such data to help make the tooling better.

I don't understand how Google and its cult can be so disingenuously surprised that people are wary of it in 2023. This makes me trust them even less than normal - i suspect they'll follow the MS playbook and "accidentally" make the opt-out fail and eventually the idea of opt-out will be completely removed from the product because "everyone seems to be happy with it... No one turns it off anyway".

View on HN

The idea would include an opt-out. It would probably be easier to use the opt-out rather than maintaining a fork.

But the feature should be opt-in to begin with. Opt-out is an anti/dark-pattern that should rightfully be derided.

Opt-in greatly reduces the statistical quality of the data. That said, there are many forms of Opt-out. It's one thing to show a checkbox in the setup of a desktop applicatoin saying "send anonymous usage data" and have the checkbox pre-checked. That's a form of opt out, but it's not hidden.

It's quite different to have a system enabled which is only possible to switch off by googling a solution or digging in a settings menu. That's also opt-out, but it's a much darker pattern than the pre-checked checkbox.

Obviously, a command line tool doesn't have the luxury of an interactive setup, so the same patterns don't apply, but whether or not something is "opt out" or "opt in" isn't the entire story. I find the "default" to be the important thing. Developers need "the default" to be enabled to get reasonable coverage. That doesn't mean it needs to be "secretly" enabled.

This doesn't change what the parent comment said. Opt-out is inherently a dark pattern. The hope is that the person installing the software doesn't actually read and uncheck the box. It's no different to "install bing toolbar" for example being pre-checked and snuck in to directx.

> The hope is that the person installing the software doesn't actually read and uncheck the box

Yes. Because you have the "don't care" group being the important group. The users are split into a small group being positive (The would-opt-ins) and a small group being negative (the people arguing it must be opt in) and a large group who don't care.

The central "don't care" group is so large that the data is almost useless without them - i.e. you could just as well not have the system at all if you were going to do a full opt-in. So the unchecked box alternative really isn't an alternative.

You've missed out a group there, it's:

  * Would-opt-ins
  * Would-opt-outs
  * Don't-cares
  * Did-not-know-that-google-are-going-to-run-telemetrys

By making it opt-out Google will be conveniently hoovering up the people that would say objects if they knew along with the don't cares.

Yes my 3-group would be the case for the checkbox-during-installer-of-desktop-app.

Xcode command line tools require a one-time license agreement. FreeBSD ports will open an ncurses based configuration dialog if there are new options. Plenty of Java tools will prompt for JAVA_HOME if they can’t figure out where it is and the JVM forces providing arguments for enabling some license restricted features.

Telemetry from a private system should always be opt-in. I find it concerning that developers think they have some default right to data on systems they don’t own without explicitly getting permission. It may be technically possible, it may be statistically necessary, but it’s morally bankrupt and erodes the peer relationship that should exist in open source software.

> Telemetry from a private system should always be opt-in.

I have to disagree. I think it should be visibly communicated (not snuck in under the radar) but such cases default on should be acceptable so long as it is clearly communicated. Command line systems ARE inherently more difficult than the installer checkbox I'm used to (but by no means impossible to work with).

> Xcode command line tools require a one-time license agreement > plenty of Java tools will prompt for JAVA_HOME if they can’t figure out where it is

This is easy enough if done from the start, but it's hard to do without breaking existing users's scripts if you have the requirement that "We don't stop and ask for permission in v2.0 if we didn't in v1.0 given the same arguments and environment, as that will break people's builds". And as a user of a command line tool I have to say that requirement seems much more important... This is why it's a good idea to have a /noninteractive switch for command line tools. You can state from v1.0 that without it, it might block at any point in any later version , so any script that doesn't use it made a mistake.

> developers think they have some default right to data on systems they don’t own without explicitly getting permission

What is explicitly asking here? Is the checked state of a checkbox part of whether it's explicit?

> it’s morally bankrupt and erodes the peer relationship that should exist in open source software.

Yes, OSS has their nuances, command line tools have their nuances. Having Google be the company at the receiving and has it's own set of complications. I don't think all the objections apply in all cases.

The point is that altering the existing social contract of software updates is an attempt to enclose the commons Open Source established and created.

The checkbox being pre-checked is still not legal in some countries, exactly because it favors the non privacy protecting option.

> The checkbox being pre-checked is still not legal in some countries exactly because it favors the non privacy protecting option

I think you are confusing this with systems that gather any PII, and regulations such as the GDPR and similar. This is about collecting data without any PII so any privacy regulation wouldn't apply here.

If the telemetry data is associated with the IP or contains anything that can be used to identify or track the particular Go installation (similar to a browser fingerprint), then it can be considered PII.

Of course. But then it's not "anonymous usage statistics" at all is it?

I don’t know how they can collect useful statistics when they cannot distinguish between 1000 invocations by the same user/environment vs. one invocation by 1000 different users/environments. And when they can distinguish, then that tracking is prone to fall under personal data processing.

Most off the shelf systems work with random pseudonyms: You generate a unique random number and store it only on the end user's system. Then you tag each data value with the random id one. These random identifiers do not count as PII so long as it is not possible to tie them to a real identity. So while you are of course required to follow data processing regulations, pseudonymous usage statistics with random identifiers is not against any regulation I know about at least. The lifespan of the pseudonym can be as long or short as you want e.g. last one session, one week, one version etc. But even when completely persistent, they will not constitute PII.

You should read the proposal. It collects a batch of per user statistics (counters).

So there is no issue of per-invocation tracking.

Seems like the simplest compromise is to just force the user to answer the question one way or the other. No default - ask them "do you want to enable telemetry? We'll use it for X..." and only continue the upgrade or install or first-run once they have provided an answer one way or another.

Will it cause friction, with users and with tooling and automations? Absolutely. But I think the costs of that friction is not a tremendous ask in terms of avoiding the dark pattern that is defaulting to yes.

In a perfect world, at least. In this one, end users are never going to win an argument about telemetry with google-borne systems, and definitely not for actually benign telemetry systems like this.

> Obviously, a command line tool doesn't have the luxury of an interactive setup,

Why would the command line tool not have the option of an interactive setup?

Many command line tools ask you to say yes/no to things the first time they are run. Even if you want to reconfigure a tool it shouldn't be difficult to retrigger a decision tree.

> Why would the command line tool not have the option of an interactive setup?

Typically because (at least if it's already shipped) there are hard expectations about what it will do. E.g. that it shouldn't block waiting for input.

That might screw headless/CI uses. A shipped product probably also doesn't have the luxury of using a /noninteractive or /noTelemetry or requiring an env car or similar to block it, because the CI scripts are already written.

You can have it ask the user (block waiting for input) if its given a NEW command line option. But you can't do it in the absence of that option. That's why, for a shipped product, it's so much easier to make it opt out. The alternative would be to make it opt in via command line switch or env var - which would obviously be so rare that there is no point in doing it at all.

How many CI environment are (or at least should be) connected to the internet to begin with? That almost certainly eliminates the possibility of reproducible builds but also opens all kinds of security issues.

(I know sandboxes builds are not common place, but they really should be.)

> How many CI environment are (or at least should be) connected to the internet to begin with

No idea. If I had to make a guess I'd say 99%?

> So, is it time to fork the go codebase and have a telemetry-free version?

Why is maintaining a fork and remembering to use it everywhere easier than just setting an environment variable?

> ... product because "everyone seems to be happy with it... No one turns it off anyway".

How would they know who turns it off?

20 years ago no software had telemetry (any reporting back was "spyware")

in 20 years from now will I need 700 environment variables, one for nearly every piece of software on my machine?

LS_TELEMETRY=off VI_TELEMETRY=off BASH_TELEMETRY=off CAT_TELEMETRY=off

You joke, but I already have a couple telemetry env variables in my env file because of various tools using them for opt-outs.

It's infuriating.

There's a proposal for DO_NOT_TRACK=1 https://consoledonottrack.com

Unfortunately it's not been widely adopted. My guess is this is running into the same problem that DNT=1 in the browser did, which is that different people mean different things by "tracking" and it's very hard to come to agreement on where to draw the lines.

AdBlock/PrivacyBadger for the shell. What a nightmare.

20 years from now?

Try disabling all telemetry in Firefox.

This argument is nonsense. Everywhere you have to remember to use the non tracking compiler and everywhere you have to remember to set the variable are at best the exact same set. More likely it's actually more places that require remembering to set the variable since various build environments and tools tend to strip out variables in all sorts of places.

It also assumes setting the variable actually works - even without malicious intent, it's an approach that assumes there are never any bugs.

The fork is created out of thin air, and maintained invisibly, for free?

We'll have to see the implementation of course, but it shouldn't be a huge effort to replace the telemtry reporting function with `return success`.

The complexity of the patch isn't the issue, it's keeping up-to-date with the upstream code. This can be done but it requires constant work, discipline, and it probably would need funding.

But the worst part is that it sends the message that we as a community will tolerate megacorps injecting telemetry tracking into our compilers, and our response will be not only to stay in their ecosystem, but to do extra work for them to keep us there. That's not the the message I want Google to hear; I want them to hear us tell them where they can take their telemetry and shove it. We do that with our feet.

This hypothetical Go fork/distribution (with telemetry disabled by default), should have an option to send bogus telemetry data to the Google servers. :)

So the occasional person that doesn't mind sending data to Google can leave it on, but enabled in that way instead.

Not quite sure what the logic of "I want to use this tool because it provides me value, but I also want to sabotage the development process of this tool" is meant to be.

Quite simply to "Stick it to the man".

If this group of dev's are going to violate the privacy of their Community members, they're asking for stuff like this.

Maybe once they realise the telemetry they collect is utterly useless, they'll actually do the right thing and remove it.

Sabotage of the specifically mass surveillance part of the development.

I luw<3 this tool so I help it to be better *-* :3 =^.^=

Also can work as a general protesting against a harmful trend.

To answer both questions: because the variables don’t always work.

If the code doesn’t exist, it can’t run. It’s the only way.

At the very least, it should be a compiler compiler flag and all code with telemetry should be in a separate library to make it easy to be sure no mistakes caused it to sneak it’s way in.

> Why is maintaining a fork and remembering to use it everywhere easier than just setting an environment variable?

1) Presumably, you're just deleting a few bits of code here and there.

2) It's not going to stop at one lil ENV var, eh?

In practice, I can imagine the software packagers of various Linux distributions would set an environment variable to disable the offending behavior. This may be good enough for the majority of the software's stakeholders (users).

The go devs discuss this, they intend on adding a Go env file that package managers and users can use to set global flags for Go.

That would rely on installing Go from the distro repositories, though, and that's not what the official Go docs tell you to do.

I hope software packagers for the various Linux distributions will disable this behavior, one or way or another, with or without the assistance of the Go developers. The official Go documentation can say whatever it wants, but in my experience the installation on Linux mostly happens via the distribution's package manager. The result would be that the software running for the majority of users will not send information to Google. It's not perfect, and won't do for some people (like me; I will remove Go and not write Go code in the future), but I think that'll remove the need for a fork for many people.

I've met quite a few (junior) devs who will follow guides instead of using their package manager because they come from Windows and aren't used to using their distro's tools.

I expect many professionals who do use Linux to run on stable possibly LTS versions of their distribution of choice and those rarely come with up to date tools for languages like Go or Rust or even Docker.

I wish installation would only come through package managers, but the amount of people I've had to help upgrade their Ubuntu to a newer version because they added a whole bunch of external repositories without realising the impact has taught me otherwise.

It's possible that distros will come out if the box with a /usr/share/go/env file even if Go isn't installed, but that'll take a while.

Good points, I could definitely be wrong in my estimate of the proportion of installations coming from the package manager. It may be that enough utility will be found in a fork. Nothing but to wait and see ;)

> So, is it time to fork the go codebase and have a telemetry-free version?

Or you know, be reasonable and set the GO_DISABLE_TELEMETRY=1 env variable, IF telemetry actually ends up being added some day.

I'm not in favor of any kind of telemetry in my devtools but there's no reason to go nuclear at this point.

Honestly the proposal by rsc is even reasonable to me, I'm mostly against it because I have no trust in Google regarding any kind of data, personal or not.

> eventually the idea of opt-out will be completely removed from the product

That's never happened anywhere, and it's entirely illegal.

Google isn't particularly well known for caring about the laws related to privacy.

Besides, opt out via env var is a broken idea. It forces me to go through all sorts of dockerfiles, ci config, dev machine scripts, etc to make sure its set. Not to mention the ongoing maintenance of keeping it that way. Id rather just use the go-with-at-least-some-minimal-respect fork and write scripts to verify that's the base docker image, installed golang, etc. It actually seems easier to do that than verify every environment that runs golang has that env var set.

> That's never happened anywhere, and it's entirely illegal

Jokes on you... Open source software is provided as is

That's my problem too. I have a website, then A LOT of companies know a lot about my users. From their ISP to Microsoft (I host on github) they all know when my users poop, when my users go on vacation, or when my users are cheating their husbands and checking in from someone elses computer.

It is so hard to create something, because of the dangers lurking everywhere. I think I need a reasonable creators license.

"to the extent permitted by law"

Reply on news.ycombinator.com