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.