Telemetry is one of the biggest controversial topics in the Linux community. Many people believe that telemetry is entirely meaningless, because developers can “just” ask their users. Some people also argue that users can opt into telemetry if they want to participate, but most of these users are in consensus that opt-out telemetry shouldn’t be there in the first place. However, I don’t believe that asking users or explicitly opting into telemetry helps to a degree where developers and designers can form educated conclusions, as both methods share many issues regarding gathering data accurately. In this article, we’re going to explore the issues around asking users and opting into telemetry, and then I will explain why opt-out telemetry is a better approach to gather accurate data and forming educated conclusions.

From planet Gnome

  • Agility0971@lemmy.worldEnglish
    21·
    11 months ago

    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:

    1. not de-anonymize anyone
    2. 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.