From planet Gnome
Opt-in telemetry leads to biased sample. Not useful at all.
Opt-out is way better regarding development.
People have deserted whole projects over telemetry. Audacity comes to mind. Telemetry is obviously not popular with people who are already sacrificing so much over privacy.
There’s no point in trying to sway linux users in favor of telemetry, because most of us already know it’s only a privacy risk and doesn’t do much. Does Gnome really listen to its users feedback anyway? If yes, why is there still no typeahead in Nautilus despite constant user feedback? Why is there still no way to have a dash to dock without extensions?
Opt-out is not a solution because you’re asking people to scrub every package and figure out how to opt out. It’s time consuming and must be done with every fresh install.
A good example of the uselessness of telemetry is Firefox. They keep removing features used by advanced users in Firefox because Mozilla thinks those features aren’t used a lot. Turns out, most advanced users of firefox don’t enable telemetry because they seek privacy from their browser.
The only way to ensure correct statistics is to never give the user a choice in the matter, but opt-in vs opt-out have nothing to do with that debate, opt-in is user centric, opt-out is not.
Users have to opt in to compromise their privacy (and computer resources) for helping out some project. Otherwise you’re compromising privacy of all users that are subject of opt out telemetry. “users can always opt-out” is not a valid argument because once they don’t get enough data, they will just make opting out harder or more confusing. Opt in telemetry should be asked by DE not by individual applications.
In this day and age it’s hard to ask users for feedback or telemetry because of all mistrust with the big tech companies. Telemetry collectors have to prove their use of data is genuine. They need to prove that their data will:
- not de-anonymize anyone
- strictly help the project
First point is easy. If the data you collect is public for everyone and you’re not getting sued then you’re probably fine. However if you are collecting sensitive data and there is a change you’ll get hacked (and you will) then this is not fine. For the second point there needs to be a few conditions in place:
- Presentation of a problem: What are you trying to find out?
- Hypothesis. What are your assumptions that you need to be confirmed with telemetry?
- exact data points to be collected
- some sort of collection period or maybe until some confidence value is reached
- a discussion about the collected data (optional?)
- result and findings of the collected data (optional?)
When talking about opt-in vs opt out, author has a point and I agree. The data cannot be collected without it being biased. So they should not collect any. Until a proper telemetry solution with good reputation gets created.
We need one centralized project that can collect telemetry that users can trust and support. Likewise there needs to be created an API for application developers so that telemetry is easier to collect through that system than coding in their own custom solution. This API should guide the developers into collecting correct and justified data.
Desktop environments can integrate this service in such a way that encourages users to opt in. Users can for instance get an overview that links each unique crash on their system to an Git[hu|la]b issue. If an issue does not exists then some sort of encouragement to enable telemetry fits in here. Users do want their issues to be fixed so this provides a clear and transparent usage of data. Just a suggestion.
If we get only one open telemetry service that over time proves to be reliable, transparent and safe then it will get recommended because it brings value for everyone in the community. Right now everyone is getting taught that all telemetry is bad and needs to be disabled if possible. A new rumor has to take place that telemetry is bad, except on Linux.