F40 Change Request: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[catanzaro (Michael Catanzaro)]

@joshstrobl

Just so everyone is on the same page and things are crystal clear: Is this a decision that Fedora is taking for strictly for Workspace (as in, the builds of Fedora which ship with GNOME Shell), with telemetry being disabled for all other spins? Or is this being enforced in a really “non-contained” way that impacts all spins?

I want to be absolutely, abundantly clear that I do not approve of opt-out metrics / telemetry gathering for Fedora Budgie Spin, which is the spin I develop with the Budgie SIG, nor the components it uses. Will those developing spins have the configuration capabilities to be able to ensure all metrics are disabled by default, as we may value the privacy of our users differently.

It is my view that metric / telemetry gathering should be primarily left to the purview of the respective applications or desktop environments. I understand some use cases, for example types of disks / storage devices where the impact of any change without metrics would be system-wide. Metric gathering in those circumstances should be opt-in, even if that means impacting the overall dataset you can work with. But by the sounds of the post, you’re already limiting your dataset anyways by making it Workstation-specific, so why not retain user trust by making it opt-in?

This proposal is for Fedora Workstation (i.e. GNOME) only. You can simply not install the telemetry components (specifically eos-event-recorder-daemon) on the Budgie spin. Other spins will have to decide for themselves what they wish to do.

If Budgie uses GNOME components, then you might have to do some work to prevent eos-event-recorder-daemon from being installed. But as long as that package is not installed, there will be no telemetry.

Accordingly, we want to know things like which IDEs are most popular among our users

That sounds more like a decision Red Hat should take with their commercial offerings and engagement with business partners.

We want data from Fedora users, not data from RHEL users. If we were to use RHEL user data to develop Fedora, you would not like the result because RHEL users are very different from Fedora users.

which runtimes are used to create containers using Toolbx

This should be opt-in telemetry that they implement for their given use cases should they desire this.

Opt-in telemetry is garbage. I’m going to stop responding to comments that are requesting opt-in because I’ve made my position clear: users who opt-in are not a representative sample, and that opt-in data will not be accurate or useful.

We also want to know how frequently panels in gnome-control-center are visited to determine which panels could be consolidated or removed, because there are other settings we want to add, but our usability research indicates that the current high quantity of settings panels already makes it difficult for users to find commonly-used settings.

This should be implemented, opt-in, by GNOME, should they want it. Why does Fedora need this information over the project itself? Or is this data, allegedly “anonymized and aggregated”, going to be shared with third-parties to make these sorts of actionable decisions? Is it then going to be communicated to users that data they are sending will be shared with third-parties?

Hm, I hadn’t considered this. I guess we’ll have to figure out how to communicate this in the Fedora data collection policy, but Fedora Workstation is a GNOME desktop and of course we’ll need to share data with GNOME developers for this to be useful.

[catanzaro (Michael Catanzaro)]

@verdigris

My suggestion is, when you add this, you also start some sort of scheduled blog post or newsletter about what the telemetry information says. And also the conclusions you derive from them, as well as what you plan on doing to improve user experience based on this information.

I will make a note to add this to the feedback section of the change proposal. Blog posts are a lot of work, but it seems worth doing to show some actual successes.

[raxel-pepi (Lucas Varsky)]

I had to make an account here, as this is too important, and I choose Fedora to be my main OS for me and after some convincing, my parents.
After reading the beginning post (not comments made later), I have a few concerns to how telemetry should be approached.

First, Fedora should know pretty well that one of the main reasons it’s chosen as an Operating System is the promise to be privacy and freedom respecting as explained in Fedora’s Mission and Foundations :: Fedora Docs , as quoted from “Our Vision”: “the user should be in control of their computing.”

Any form of telemetry should, for all users, be OPT-IN, not only for existing installations. Users who freshly install Fedora shouldn’t be forced to an OPT-OUT method.
I’m not saying that Fedora is an evil organization controlled by Big Tech. But the average user without the technical understanding of telemetry (they likely know that telemetry = bad) would likely get suspicious if they see it on a project that sells itself as private and secure.
A majority of users don’t have the need to know exactly what happens to their OS, they just want their computer to work reliably, to open Firefox to watch baby kittens. If this is approached without informing the user, you are essentially lying to them.

Honestly, the best form to add telemetry without causing an uproar (that already happened due to poor communication and yellow journalism) is to make the telemetry OPT-IN, likely copying KDE’s already existent telemetry method making it understandable to all users and not forcing anyone to give data.
If it’s clearly communicated what you will collect in an anonymized way (with a toggle to see the raw data) before giving access (for example: package list and version, usage time, copr repositories) most users would trust the telemetry.

Second, locking this to GNOME technologies is a bad idea. With the variety Fedora offers, it’s likely that telemetry would be turned on by default on users with Window Managers or more traditional Desktops like XFCE or MATE.
I would either make a universal Fedora utility or include the telemetry information inside the Anaconda Installer with an explanation like “if you change your mind, run this command on the terminal: fedora-telemetry off”.

Third, if the main goal for this is to gather data for Red Hat, why not start with RHEL first?

It fits their goals to be the top players in the Enterprise World, if I’m paying for the support I want them to gather telemetry so when I ask for help they already know the crucial information about my deployment of RHEL, removing some of the bureaucracy of troubleshooting.
Not enabling this in RHEL first makes me question what’s the difference from Rocky and Alma.
It’s not like Red Hat is giving me the extra care, why pay them?

I can’t help but feel enslaved by this, it’s almost like Red Hat is forcing telemetry on us (it’s not the case, hence why we are here, but it gives me that feeling, even more with the recent backlash of Rocky/Alma).

TLDR: Please make it OPT-IN, universal for all of Fedora, and with a good explanation for every kind of user.

[uraeus (Christian F.K. Schaller)]

I am not going to rehash all the general arguments about opt-in vs opt-out, but I will answer your question about tying it to GNOME. So the short answer is that it isn’t inherently tied to GNOME, but if any other spin wants to include this they will have to write some tooling for their desktop of choice to do so. There is no good way of doing this that is completely uncoupled from the desktops.

As for telemetry in RHEL, as I think Michael mentioned that is already done through something called Red Hat Insights. This is about Fedora and how to make Fedora better and also how to justify even more investment into Fedora and thus collecting RHEL data doesn’t really help with that.

[steiner (Daimar Stein)]

@gotmax23

Whose objective is this? Red Hat’s? FESCo? Counsel? I’m not saying I don’t agree with this objective. I’m just asking who we is .

Beyond Michael’s answer, it’s also part of Fedora’s 5 year plan:

Fedora Strategy 2028: Focus area review (Technology Innovation & Leadership)

We’re working on Fedora Strategy 2028 — our next five-year plan. We are now reviewing those Objectives and their associated Impact. Read this guide for details on the current planning phase. Focus Area: Technology Innovation & Leadership This continues the theme of leadership — this time, technical leadership, embracing the “Features” and “First” foundations. As with the previous focus area under this theme, there are many different things we could do. We’ve selected some which we think will h…

[fweimer (Florian Weimer)]

@catanzaro

But actually, I had not considered this because I had no idea that Fedora packages already collect data beyond dnf better counting. What packages do you know of that currently have their own private data collection?

Fedora’s Firefox defaults to:

• Allow Firefox to send technical and interaction data to Mozilla
  • Allow Firefox to make personalized extension recommendations
• Allow Firefox to install and run studies

It also uses the Google Safe Browsing service, which sends statistically sampled URLs to Google (with a probability configured by Google). I expect most web browsers in Fedora to do this, and they probably have metrics gathering similar to Firefox. I would expect various online crash reporters in complex packages to be active in Fedora as well (not just ABRT, which presumably falls under GNOME in this context?).

[uraeus (Christian F.K. Schaller)]

The problem is that if we send out a poll asking for example 'should we continue shipping Firefox in Fedora (random example) the chance is that the people who choose to respond is the people using Firefox, while it will tell us nothing about if they represent 1% of Fedora users, 10% of Fedora users, 50% of Fedora users or 100% of Fedora users.

[raxel-pepi (Lucas Varsky)]

Good to see making each spin decide to include/not include.
Why is not adding a “Privacy” option to Anaconda that requires the user to select an option before installing a bad idea? It’s universal (the argument for opt-out is to increase numbers) and it almost guarantees that users will read how their data is used.

[yump (R Haley)]

I don’t like polling and prefer forced-opt telemetry, however it seems you could ask the user whether they were willing to participate in a poll and either submit results or an explicitly empty result, before showing them what the poll was about.

That way you’d have counts for

A - Keep distributing Firefox
B - Stop distributing Firefox
C - No response

[uraeus (Christian F.K. Schaller)]

Maybe because understanding if Fedora Workstation users are using GNOME Terminal or Terminator isn’t in any way or form comparable to killing people with a gun?

[uraeus (Christian F.K. Schaller)]

That poll would only be valuable if I could know how representative of Fedora users it is and also if people have considered the tradeoffs possible. Ie. could the investment in Firefox be moved to VS Code for example. The telemetry data, if representative, could give us quite strong data to make such a decision, while a poll would most likely be distorted by self selection ie. the people wanting to keep firefox is a lot more motivated to participate than the people who don’t care.

[uraeus (Christian F.K. Schaller)]

There is no abuse here, there is only an attempt at gathering data that would allow Fedora to become a better operating system for its users.

[nadb]

My point was not to make this about whether the data is a matter of life or death, but simply to show that the options presented are either an open assault on a persons privacy, or a choice they are making. Being assaulted is never pleasant.

[glitch9138 (Stew Cassidy)]

Is it worth the loss in trust, though? Just like there are no numbers on how many will leave, there are also no numbers on how quantifiable the improvements will be from implementing this. It is just a promise right now