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

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.

2 Likes

I support this and I would leave it on. I trust Fedora, Fedora infra, and want Gnome Software or Settings to be more relevant to how people are using it.

4 Likes

To me it seems that we miss the transparency part before we start arguing unknown details. We do not know the scope (what data), the purpose (who is gonna use it and for what purposes) and the protection (how data is transferred, stored and shared).

I do not trust corporations (yes, Fedora is a community project but heavily funded, supported and steered by RedHat which is owned by IBM). I cannot remember cases where big tech made right choice for users/community if they face moral dilemmas. Why should we believe that RedHat+IBM are different ?

On the other hand, I fully understand that getting proper amount of statistical data is very hard if said data is very limited because of low engagement through opt-in. Having anonymized stats should help make the FW better through more effective bug fixing and improvements/optimizations.

I think, we need a compromise. And I believe that the full transparency would help build up trust in the opt-out. That transparency has to be audited yearly and the report must be made available publicly to the community, which has right to know what data were used by&shared with whom for what exact purposes.

My personal take on the situation is this - if opt-out is chosen and transparency is not provided, I’ll opt-out. That would be sad, very sad decision, but I prefer to be better safe than sorry. Because corporations are not people.

3 Likes

The way I see it is:

  • Decisions need to be made
  • I believe that decisions based on data are likely to be better decisions (but that’s a belief)
  • I would prefer my use case to be taken into account in those decisions (I see it as a form of vote)

If the UI shows a clear way to disable telemetry, then I think the most privacy-focused people will easily be able to disable it, right? It would certainly be easier than switching distributions.

I’m not sure if this has been answered already (I did read the thread! :slight_smile: ) but I wonder whether the collected data would be accessible to everyone in the community (not just the database schema, all the final data). It may be interesting to let our community run analytics on it and unearth some facts that the Display Systems team hasn’t yet thought of. It would be empowering to the whole community, I think. And since our server configuration is accessible to all in the Ansible repo, it would help build trust that there is no personally identifiable data hidden somewhere for secret purposes.

4 Likes

What about packages which already collect metrics and report them somewhere (not necessarily to Red Hat)? Would these packages need to change under this proposal? If not, how do we explain this to our users?

1 Like

I think that would be extremely difficult to enforce. I think this proposal should cover the basic set of installed packages under Fedora Workstation.

I guess we could ask reviewers to provide the package’s telemetry policies but to me that looks like hell waiting to happen, and would make the reviewing/packaging situation very difficult.

1 Like

Canonical is not the bar we should be striving to reach. Ubuntu has lost substantial market share over the years due due to various changes including their anti-privacy policies.

This is a matter of perspective. I would consider collecting any type of application usage detail highly intrusive. From your perspective, this may not seem intrusive.

Until someone makes a mistake and accidentally creates a way to correlate/track that data. This is not some radical improbable idea. There have been plenty of high-profile examples of data from various organizations being leaked and/or used in ways that wasn’t intended.


Here is the core problem in my opinion. Linux has a higher percentage of privacy-centric users than other operating systems because many people come to Linux specifically for that reason. None of us know exactly what that percentage is. It is not 80+% as some people have implied but it also isn’t some insignificant minority as other have implied. I would guess that on a distro like Fedora it is probably somewhere in the 25-40% of users range.

That portion of the Fedora community will be completely alienated by opt-out metrics. Even if it doesn’t make sense to you personally that this would be the case, it is clear from the comments here and elsewhere that this portion of the community feels strongly about it.

Ultimately, Fedora has a decision to make. Is collecting this data via an opt-out mechanism valuable enough to warrant isolating and alienating that portion of the community?

4 Likes

I don’t know about other members here, but I came from Windows and one of the major reasons why I even went through the trouble of switching was to get away from Microsoft’s mandatory telemetry that’s now peppered all over the OS…

2 Likes

Which part would be difficult to enforce? Surely we need to come up with a way to describe the scope of the opt-out and make it clear that it only applies to a subset of the data collected by Fedora Workstation.

If Fedora was comprised of software only made by fedora (Like in Windows for example) then yes we’d have perfect control.

But Fedora is comprised of thousands and thousands of independant parts. It would be extremely difficult to force them all to fall in line, if not impossible. That’s how I understand it anyway.

2 Likes

I have not found a mention of it in this thread so I’ll mention it here: We already have an opt-out telemetry mechanisms and it’s massively useful:

It let’s us see which versions/spins/editions are popular, how fast user updates, compare architecture adoption, etc.

And this is a very limited telemetry system. Adding a framework as is proposed here to include some other data points would be very interesting.

5 Likes

Metrics uploading will be opt-in for users who upgrade from previous versions of Fedora Workstation, because we don’t yet have a mechanism to ask the user to consent to data collection after a system upgrade like we do for new installations, but metrics collection will be opt-out.

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?

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.

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.

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?

To retain user trust, we need an easy way for users to understand exactly what data we are collecting.

Here is an idea for retaining user trust: Opt. In.

However, we also want to ensure that the data we collect is meaningful, so gnome-initial-setup will default to displaying the toggle as enabled

Yikes.

these users would not be representative of Fedora users as a whole

Nor would it be if it’s just Fedora Workstation in the first place?

7 Likes

I fully support this-- but for one thing I’m really curious about what it would change.

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 would say one of the only reasons people don’t want this idea, is because it was used to siphon unneeded information off of users in other services, which is obviously not being done here. But also because in people’s eyes there is no upside to this. All sorts of projects ask for this information but people don’t notice any change that occurs because of the telemetry.

I think that if you make a frequent summation of what the telemetry says-- like the hardware that most people use, or a certain feature that is most used… or what you conclude from the telemetry and what you want to change in the project to improve the experience of the people, and have that published, it would solidify telemetry in people’s eyes. At least as something that can have a positive effect.

Additionally, this is also way more transparent as well. You’re saying everything that the development team is thinking, and what you’re trying to do with this information.

Other than that, I’m just really curious about how much you folks will make use of telemetry and all the changes that’ll happen because of it, and it might inspire me to add telemetry into my own projects as well if you get a lot of bang out of the telemetry info.

5 Likes

This appears to be collecting data I would personally describe as non-intrusive. Counting installs is much different than tracking which applications are used and when.

2 Likes

Relying on telemetry is a weakness and shows a lack of clear direction or vision. Decide what you want to work on and ship it, instead of relying on stats that won’t actually give you a clear picture. You know what they say - lies, damned lies, and statistics.

Want to know about your users? Ask your users. You’re getting plenty of feedback here. This seems like a great place to gather data. Yes, this is a discussion forum that’s usually only frequented by those who care about their operating system, so you’ll only get one side of the picture. But statistics will never get you a human perspective. You can’t go “deeper” with them because there’s nobody to ask - they’re just numbers. They provide an incomplete picture. What I know from my experience assisting users with computers is that they often do things in a way you don’t expect, and that data won’t show you - many years ago I “corrected” the resolution of an employee’s monitor and she asked for me to put it back to its previous value - she had set the resolution lower at one point because of poor eyesight.

Telemetry seems, ultimately, not very useful beyond counting active users, and you already get that from repo stats - we can’t really opt out of your httpd logs. Maybe scrape those instead of installing a daemon on a user’s machine that consumes CPU time and bandwidth.

At least it’s nice you’re willing to ask here, but in the future, you could stand to wait a month or two between controversial announcements, for optics, and a better reception. As people have already said, emotions are higher than normal right now.

8 Likes

Let’s be honest: the timing for such a proposal is very, very unfortunate, and this is going to add to the bad advertising all Red Hat-related products are under now. This is to suggest that the entire proposal should be crafted and announced very carefully.

I realize that the proposal authors wanted as much data as possible to drive their decisions and development, and I respect that desire: however, this proposal in this original form is really going to backfire.

I believe no one here truly neglects the importance of telemetry when it comes to gather insights about a representative portion of the population of users. Data in general is always useful, either in the present or in the future, and allows novel insights that weren’t simply possible before. No one questions the importance of data when driving decisions.

However, it seems to me that the way such a representative portion of consenting users is obtained is disappointing, to say the least. The idea that a representative portion of consensus can only be achieved through an opt-in button literally suggests that the users are considered uncapable of deciding, or are expected to mindlessly scroll through the menus and leave the telemetry button turned on, be it by mistake or not: otherwise, users would simply turn it on in the case they agreed, and that’s something the original proponents seem to know the users will not do.

From a privacy-respecting, and most importantly, user-respecting operating system as Fedora Linux is, I frankly expect the user privacy rights to to be actually protected by design.

My idea is the following, and is summarizable with this principle: don’t decide for the users, let the users decide for themselves. Do not present the positive, agreeing choice by default, but neither present the negative choice. Instead, show the user two equal-standing buttons: an ‘I agree’, and an ‘I do not agree’ button. Those buttons should not be preselected by default. Those buttons should not even hide behind dark patterns or resort on any similar well-known or novel trick. They should be perceived as equal in strength. They should be unequivocably clear, and should be accompanied by a simple and straightforward explanation that – if too long – should link to a “further informations” section for the more meticulous. Explanation should be simple and everything should be crystal clear. Users should not be made feel guilty in the case of no consent. And, very importantly, buttons must not be skippable: user cannot jump to the next section unless they established a decision. This means that no user can press ‘next next next’ and find their telemetry enabled. Users should be trusted, not tricked in any way, subtle or not.

I think the problem here is not the telemetry itself: the issue here is the lack of trust on end-users, and the resort on opt-out strategies to collect meaningful telemetry data. I strongly believe the users should be trusted (and, in this case, forced) to decide ‘Yes’ or ‘No’, clearly and with no obscure wording we typically witness in some user-disrespecting commercial products. There is no justification for a lack of respect towards users, no matter what is at stake.

12 Likes

2 posts were split to a new topic: Thoughts about the proposal to use Discourse for Change discussion

Yes.

No, spins decide for themselves what they want to ship and what features to enable.

1 Like

Fedora and GNOME have been fine with next to no telemetry so far. Why does it need it now, all of a sudden?

2 Likes