Should you allow telemetry?

I read this interesting blog post from one of my favorite authors. I do agree with most of it, but I still think telemetry should be implemented in open-source projects, and should be an “opt-out” option, if people/company behind such software provides transparency reports. I also agree that telemetry should be disabled in commercial software, but that is not going to happen.

2 Likes

Great article, it perfectly describes the problem when talking about telemetry which is what happens right after the “telemetry-related work” is done. The data collected is not deleted right after it’s being put to use to improve software; and I’m not going to start talking about what “improving” really means (again, the blog post covers this).

So the question really is about what happens with this data after we’ve shared with a very specific purpose in mind. We know it’s being misused worldwide for corporate profit, push political agendas worldwide, enforce freedom-restricting laws, persecute political dissidents, journalists, etc. Even if we trust the entity we are sharing this data with, it still can be leaked due to negligence or unknown vulnerabilities in the software.

I think telemetry should be disabled by default in every project.

First of all non-tech savvy people will very rarely, if ever, modify this setting. Therefore by making it opt-in by default there is a significantly smaller chance of their data being compromised without their consent. Most tech-savvy people are not privacy-aware, so while some people would change this default, still a majority wouldn’t. Assuming, as the article says, that you need large amounts of data to make relevant decision to improve a given software, this leaves us with a scenario where neither the developers nor third parties wanting to profit from this data can take advantage of it.

However, developers can still engage with the community in a myriad of ways. The good old and proven method of market research comes to mind, although I agree this can be costly and therefore not ideal for smaller projects. However cheap options still exist like online surveys and forums such as this one. I for one find it much easier to contact directly the developers when I find a bug on some software, or have a question about something. Many times, other community members will be able to share their thoughts, and the topic may grow in interest. This is a clear indicator for the developers, without any additional cost, that something is going on there.

That all said, not everything is black and white, and there are still a few instances where I selectively allow telemetry data collection. As a rule of thumb, smaller companies/projects I think is very unlikely that this data leaks anywhere (and even if it did not in large enough quantities) while still benefiting the project. Larger companies such as Mozilla or Canonical it’s a big no-no.

1 Like

so thats a lot of english :joy: but i read the conclusion and i think i should have read it when i woke up not while i’m falling asleep. anyways, telemetry is good but if you asked me it’s not that great in FOSS, why? because you literally got issues tab (on github/lab) so why bother record and provide more evidence that i don’t use your data in bad way if you just the user can add your ideas. and if it’s open in FOSS, i think being “opt-in” is more better

Telemetry is not inherently evil. How are developers supposed to improve their product if they have absolutely no clue as to how their customers use their product? Obviously you can try to solicit surveys, but most people don’t want to be bothered by surveys as they see them as a waste of time. What worries me more about a dev collecting usage data is what else they do with that data, retention time, etc. As long as the data is anonymized I guess I really don’t care what they do with it. But at the end of the day we’re really just taking their word for it…

I think a more interesting question would be, should telemetry be opt-in, or opt-out? I don’t have problems with it, but there should be an obvious, easy to use master control switch that enables or disables all telemetry in software.