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

97 posts were merged into an existing topic: Opt-in / Opt-Out? A breakout topic for the F40 Change Request on Privacy-preserving telemetry for Fedora Workstation

I’m not proposing to collect any of these particular metrics just
yet, because a process for Fedora community approval of metrics to be
collected does not yet exist.

Right. Also, to start discussion of how particular metrics should be approved. I don’t intend to propose collection of any particular metrics until we have some agreement on how exactly metrics should be approved.

For example: we’ve been investing in developing tools like GNOME Builder and Toolbx. How much are these tools being used? Do we need to increase or reduce investment in these areas?

We already have a separate telemetry system for RHEL (Red Hat Insights) that, among other purposes, is used to prioritize RHEL development. But the system I’m proposing here would be for Fedora, not for RHEL. RHEL users are very different from Fedora users, and desktop development should primarily prioritize the needs of Fedora users.


A post was merged into an existing topic: Decision-Making, Governance, Council, Red Hat — a breakout topic for the F40 Change Request on Privacy-preserving telemetry for Fedora Workstation

First of all, are we talking on imposing this on users or will users have the possibility to opt out/in?

Especially the latter is very probabilistic, and sufficient of the first can still achieve clear profiles. You can create a lot of mistrust in European countries, especially if it is complemented by points like this:

I think this proposal is very dangerous in many non-US countries and its impact is hard to foresee. With that, I mean if and how many users will leave, but also what happens to their data. That the GDPR and such regulations are a “must” and no “should” is a personal opinion, not a fact. Please do not impose an opinion on others, making it a fact the community shall not discuss about.

Be aware that data collection in the US has on itself a problematic reputation especially in Europe. This is also an issue of different cultures.

Additionally, I am not sure how many people use Fedora also for work/business and related data: this may force them to switch to another system if this is not cared for. This has to be transparent, too. It is not acceptable imho to tell them that it is their problem to care for GDPR.

However, if the community agrees to that, I think a user should have the possibility to opt out during installation (better: opt in), and it should not be automatically enabled on updates or so.

Also, this is a matter of nudging: if you force people, they will often reject things they would accept if you leave them the choice during installation, and add good points about how this serves the community and is controlled by public policies of the community and such triggers to convince (and add a clear policy).

In either case, I think before bringing this to the community to make a decision, it needs to be much clearer what data is collected and so on: a policy (what, when, how, if, options) should be part of the proposal, not its next step after the decision. The same for what can happen to the data and about what anonymous or non-invasive is. Especially the latter two are critical and complex tasks…

Given the proposal as it is, I have to say that I do not see the responsibility from the owners I would expect for collecting any data. It asks for a general agreement without answering the related questions, and even excludes some (making it the problem of the users). Thus, the proposal already excludes …

… during the ask for agreement.


I understand that you’re trying to move in a step-wise direction, but I think some more transparency on what you expect to end up collecting and how you intend to use this data would make the discussion more productive.


35 posts were merged into an existing topic: Decision-Making, Governance, Council, Red Hat — abreakout topic for the F40 Change Request on Privacy-preserving telemetry for Fedora Workstation

What, if any, impact is there if the community said no to a specific metric?

I read this proposal as a “cart before the horse” type of issue - the problem statement (i.e. the metrics that need to be gathered) should be what defines the ask for telemetry to solve for X and if there is an alternative path to gather the needed data, that should be reviewed and proposed.


My expectation is that Fedora community members who want access to particular data for some particular purpose should be able to request access. But that is something we’ll need to discuss (this thread is a good place) and figure out.

The timing is mostly a coincidence; I wrote most of this change proposal in August 2021, and it just took a very long time before I felt ready to propose it. At the time we were hoping that having telemetry would make it easier to justify increased investment in Fedora. Unfortunately, with the way things have been going, that seems unlikely now. :frowning:

Red Hat Display Systems Team

I have a slightly different goal: Fedora Workstation should be the premier Linux workstation operating system, period. :wink: That position is undisputedly held by Ubuntu currently.

That was the goal of the “What data might we collect?” section (above), which describes various metrics that I’ve seen requested thus far. I fully expect we would wind up collecting much more than this, but what exactly we collect would be up to the Fedora community to determine. My expectation is that Fedora packagers and other community members will have lots of use cases for data collection that I don’t know about yet.

It’s very common for developers to ask “how many of our users are doing X, Y, or Z?” and then complain that we don’t know. E.g. earlier today a user was requesting feed reader integration in Epiphany. I wanted to know how many users have a feed reader installed (because otherwise, it would be useless). A couple weeks ago, GNOME wanted to drop support for systems that don’t support SSE4 instructions (for GNOME OS and the GNOME Flatpak runtimes); we asked Endless to show us CPU data, and learned that a significant amount of their users would be unable to run Flatpaks, and so dropped that plan.

For avoidance of doubt, I don’t have any secret plan for what additional data to collect beyond what’s already mentioned in the change proposal. But I’m sure others at Red Hat and also Fedora developers who do not work for Red Hat do have some ideas. This thread would be a good place to informally propose particular metrics that you might want to collect.

What’s really important to me is that however we wind up deciding what data to collect, it should be done publicly via some sort of Fedora community process, and not wind up with Red Hat making these decisions in secret on its own. This thread is also a good place for proposals on how exactly that would look. In this change proposal I wound up proposing that FESCo would approve metrics, but there are many other ways we could do it.

Edit: This post originally said “SSE3” but it was really SSE4.


I like your idea. But I am not sure how to achieve that with such metrics? Ubuntu can be modified by vendors so that it can be easily put on their hardware, also its kernel is modified in a way that can make things easier for the users. I love that Fedora retains the stability and security guarantees of the vanilla kernel, but the majority of average users focus on the more obvious things. There are several reasons why superseding Ubuntu ain’t that easy.

I expect that in Europe, any imposition of data collection with data transfers to the US (and any data collection at all) will deter a noteworthy amount of people, may it be for rational and/or irrational reasons. So I do not see how this means will support that goal. The opposite could be the case in some parts of the world.


47 posts were merged into an existing topic: Approaches to data handling, safety, and avoiding individual identification — a breakout topic for the F40 Change Request on Privacy-preserving telemetry for Fedora Workstation

Well that depends on each particular metric. E.g. if we don’t collect gnome-control-center panel usage data, then the GNOME design team has less information to use to make design improvements. They’ve been trying to move frequently-requested settings from Tweaks into gnome-control-center but have been having trouble because user studies indicate users are already having difficultly navigating the high number of settings. So some consolidation of panels is needed. But (a) what settings to consolidate or remove? how do we decide without usage metrics? And (b) how do we know that the design changes were successful after they have been implemented? With respect to (a) specifically, I’ve seen proposals to remove most of the Sharing settings. So let’s say those settings are at risk without telemetry. (I don’t remember offhand if the Sharing settings are actually still at risk, but it’s a real non-hypothetical example of a design change where telemetry would be helpful.)

Sticking with the example of gnome-control-center panels: how else would you gather panel usage data from a representative sample of users? (i.e., not from users who choose to respond to a survey, since those users are not going to be representative of typical Fedora users.)

9 posts were merged into an existing topic: What data will be collected, exactly? — a breakout topic for the F40 Change Request on Privacy-preserving telemetry for Fedora Workstation

So, I was initially wary of this change myself, and wanted to scream “Hell No” from the rafters. If you haven’t, I highly recommend reading the linked blog post, Endless OS’s privacy-preserving metrics system – Will Thompson

Data is valuable. That’s why everyone has opinions about their privacy, and what they want to do with their personal data. And the problem is this data is valuable to different groups in different ways.

While yes, technically a Red Hatter is proposing this change, this is one team member from a single small team inside Red Hat (Red Hat Display Systems Team). This can hardly be considered “Red Hat forcing a change,” especially since Red Hat gives us autonomy on our involvement in upstream projects, even if it goes against the interest of Red Hat. I believe that the author has a positive intent, and an inherent desire to truly improve the situations they can affect.

There is immense power here, to improve the average user interaction with Fedora and improve user retention and success. A better Fedora is (imo) in the best interest of everyone. Using data to identify and guide development investments is a significant win.

“But at what cost” - This is the scary part. Telemetry is not inherently bad, evil, etc… and can be used in very negative ways. But for it to be valuable, it has to be truly representative of the situation. Simple feedback surveys and opt-in metrics will never get you statistically significant data to apply to the broad user base and guide design decisions.

Opt-out is, unfortunately, the best way to get this representative sample. A significant amount of people will just install the defaults and go about their day. They just won’t care if telemetry is collected or not.

But what does opt-out mean? In my mind, along the lines of the example in the provided blog. A blatantly obvious installer step that is direct and explicit, and explains in sufficient but terse detail what’s going on. Then, another simple and obvious option for post-install to explicitly disable it.

As far as the stored data, I don’t think it should be viewable in detail by the general public, I’m worried that enough granularity would provide those with the time and resources the ability to find weaknesses. (Something else I changed my mind on thinking about it). BUT I do think reporting and an interface to query parts of the data will be beneficial in putting the general public at ease that this data is being used correctly and appropriately.

As already evident by the chatter on this thread and the mailing list, people have STRONG opinions about this, and if approved, we would want to ensure we took great care in doing this the right way and for the right reasons.

In summary, I do think telemetry would be valuable to Fedora, and would only be truly usable in an opt-out state. But the devil will be in the details of implementation and metrics, and a very fine line would need to be walked early on to ensure success.


(Copying from devel@, as I think this is useful here)

On Thu Jul 6, 2023 at 20:17 CDT, Michael Catanzaro wrote:

I’m attaching a screenshot to give an idea of what this would look like in
gnome-initial-setup. I don’t have a gnome-control-center screenshot handy, but
it would be similar, except there it would default to off.


Telemetry is great and useful, just ask nicely, explain what information you’re collecting, and don’t enable it by default. It would also be helpful to say that collection of this data is to improve the users’ experience when asking for it.

Honestly, love that post. You basically outlined what I thought, and am thinking, to a T. And I agree that telemetry would be important to Fedora, but that the line here would be very thin.


Does this concern only GNOME? Whatever the new default is, will it be applied on spins as well?

I think telemetry is not a bad thing at its core however it is not preferable. An implementation like KDEs could work better where the user can control the “level” of data shared rather than a true/false toggle, this will give users more control and allow them to share more or less depending on personal views.

The default level could be a low level which shares little data so it is still “opt-out”.

My biggest concern with this (other than a reiteration of the plea to make this opt-in or at least make the user decide explicitly without a default), is the PR disaster this is going to be.

I can already see the headlines and the outrage on social media: “Fedora now collects metrics at the request of Red Hat, enshittification continues.” It doesn’t matter that it’s not true because Fedora makes the call, it will be bad PR for Fedora in any case, which will actively work against the stated goal of making Fedora the premier developer platform.

Given the amount of goodwill Red Hat has recently burned in the community and its fallout on Fedora (just go and see how many people are posting that they’re switching distributions because of what Red Hat did; I’m aware none of the recent announcements affect Fedora, and Fedora isn’t in any danger, but that message either does not arrive at or does not resonate with users), I think this is not the time for this proposal.

I think you should come back with this in a year. At the moment, this is just very bad timing.