Unfortunately this is a bit of a chicken and egg problem, HW vendors are reluctant to invest in Linux without hard data showing there is a market for them to address there and at the same time Linux users want to know that the hardware they are buying is well supported already. That said we know a lot of Fedora users are not in charge of their HW models, often HW is chosen for them by their company for instance and that decision might be more driven by Windows needs than Linux needs, so just showing that a certain percentage of the systems that the vendor today believes is all Windows for instance is actually Linux is valuable in terms of their own internal discussions about how much effort to put into Linux support.
5 Likes
Youâre still only going to get statistics from users who agree to telemetry. It will never be a representative sample of the whole user base. But hey, since I donât agree to Fedora probing my hardware and recording my behavior, then I guess my opinion would not matter anyway.
Iâve prolly expressed enough of my concerns over this proposal. Hope the telemetry thing works out and people are happy with it. Bye!
2 Likes
As a software engineer I very much understand the value of metrics, especially when trying to allocate finite resources to development, so my vote is set to âIn favor, with reservationsâ.
That said, my main reservation involves the problem with the word âtelemetryâ and how this proposal could be catastrophic when it comes to new user adoption, regardless of an excellent, open and transparent implementation. And, frankly, I am surprised that this has not been further discussed and has only been hinted at by a couple of posters.
To further elaborate. Since Windows started using forced telemetry there have been a great number of online publications, some raising valid points, a lot of it clickbait fearmongering boiling down to tin foil hat territory, that âeducatedâ the average computer user on what telemetry is.
As such, thereâs a largely significant number of users who are terrified of telemetry and have equated the term with spyware and privacy invasion, who also have no technical background whatsoever to understand implementation details and a lot of them with no inclination do so too. Theyâre perfectly happy with âtelemetry bad. end of story.â. With the latest Microsoft LLM fiasco and with a major hurdle for the average user now gone (see gaming on linux) we are seeing daily an increasing number of users either switching to linux or contemplating doing so, asking for advice on distros, etc.
The current situation is that I am already seeing people advise others on public forums and social media to stay away from Fedora because it includes telemetry, âlike windowsâ. I have had to write lengthy responses to explain, with citations, that there is no telemetry in Fedora and that it was a proposal that never reached the FESCo voting while also explaining what telemetry actually is and how completely anonymous, aggregate metrics are beneficial to such a project. 4 out of 5 times my responses, although very carefully worded and cited, were largely ignored because the fear of telemetry in the average user has, frankly, blown out to what I consider epic proportions.
If a proposal that never reached the FESCo voting stage, a year ago, did so much damage to Fedoraâs reputation, then I am really afraid what will happen if it actually gets voted in.
I do know that the basis of my argument is anecdotal data but I am pretty sure that everyone working with computers has seen this to at least some extent. We even see the distrust evident in this very discussion (and I really applaud the complete transparency displayed here), stemming from experienced linux users. Not new linux users, who are jumping the windows ship to linux desktop, exactly because they fear of telemetry and LLM training on their private data.
Most of the people here in the discussion, if not all, weâre engineers, developers, power users and we have a better understanding on what is going on and what is being proposed for implementation but I fear that this may prevent us from realizing weâre in an echo chamber and we could be failing to understand the general sentiment out there.
So I guess my question boils down to: Has there been any serious thought and evaluation of the potential damage to Fedoraâs reputation, coming from the average user who is not educated in what all this is and means and is just fearful, propagating inaccuracies and falsities regarding the situation at hand? Any amount of useful metrics would be counterproductive if people stay away from Fedora and if we lose portions of the existing user base in the process as well.
6 Likes
What would help: an easy graphical app to show on the client side what data is being submitted. It does not exist, but thereâs no reason it couldnât exist. Iâm confident that the more transparent we are, the easier it will be to convince people itâs OK.
Currently the easiest way to see what data is being collected from you is to set up your own metrics server. On the one hand, thatâs already radical transparency compared to proprietary software telemetry. But itâs still too hard. If we could get the workflow to âinstall some app from Flathubâ that would be ideal.
1 Like
I think thereâs another segment that arenât worried about the intentions of the initial people working on this, but are worried about the intentions of others in the future who may have malicious intent once the data is collected and sitting somewhere. I have no doubt that the current people involved in this have the best of intentions and have the users best interests in mind. Can you say the same for the people who will be working on this in 2 years? Can you say the same for what a new Executive at RH may decide in the future once thereâs significant data collected. Fact is, no one can make any claims about who will be involved with this in the future. But once data is given⌠it can never be rescinded.
I used to be a Sun customer. I did not like Oracle becoming the owner of my data when that whole saga went down.
An extreme example to illustrate the point, in the early 20th Century the Dutch collected a ton of information on its citizens that the citizenry were happy to provide. No one expected what Mid-Century-Germans would do with that data. At the time it was utterly unimaginable how it would later be used by different people.
There are some, like myself, who are generally cautious about what the data could be utilized by a malicious actor whoâs had years to think about how to utilize such information. Just because you and I cant (at the current time) think of a bad way it can be used⌠doesnât mean a highly motivated person with malicious intent could find a way. Or that some newly hired Exec wont think itâd be a great idea to utilize the data for some other purpose.
Also right now while this is in proposal, thereâs no way for any of us to know how this actually will work. Thereâs a lot of âcouldâ, leaving people to guess what actually âwillâ. Until the code is written, all we have is a general claim of what it will collect and how it will be processed.
With any data collection thereâs always the concern of scope creep. While right now collection may only include, things âAâ through âJâ, what happens when someone decides that âKâ is really needed. Will that collection be auto enabled with an update? Will any future changes of what data is collected revert the system to OFF, until the user explicitly agrees to the new collection, or will the system silently start collecting additional information with a user being unaware?
We all know how badly TOS and EULAâs are abused through updates that users just click through because theyâre trying to get something done and donât have time to read and understand whatâs changing.
I can appreciate how this data can be useful to development efforts. But data is agnostic. Thereâs no way it can ever be âonly used for goodâ. Which is why some people will default to assume the worst.
I would counter that the system information collected reflects the user. Thatâs the entire point of the data collection, to see information on what the users are doing, as the proposal states⌠âDesktop usage patternsâ.
Question, will this collection be bundled as an entire package with a systemd service so users can entirely uninstall this collection capability from their system? That would go a long way in assuring users that its not silently doing its thing in the background without their knowledge. I assume that this will at some point extend into the other desktops spins (KDE, XFCE, etc); will Spin/Labs maintainers be able to completely remove this? I would not want any part of this within the Fedora Security-Lab Spin. To be clear, Iâm not saying that I want it to be disabled by default⌠due to the nature of the Security-Lab Spin, I wouldnât want the code to exist in any manner within an installed system unless a user themselves specifically chose to manually install it.
2 Likes
The only solution I can offer is community control. In the short term, Iâm still looking for more volunteers to join the proposed metrics SIG, which will be responsible for this program. In the long term, I agree thereâs no way to be certain of the motivations of whoever will be in charge in the future. If we start building profiles of users in the future despite my promises to not do this, then I would hope FESCo should push back or even shut the project down entirely. And if Red Hat or another future corporate entity tries to do an end run around FESCo, or if FESCo ever becomes stacked with sycophants who approve whatever Red Hat says, that will be a good warning sign that itâs time to look at other distros. None of this seems likely today, but you never know what the future holds.
Anecdote: some strange company just bought a local newspaper in my city and fired all the reporters. The homepage is currently a bunch of normal articles written by the previous staff plus exactly one new AI spam article. I guess they just wanted a reputable web domain to abuse for SEO optimization purposes, but who knows. It would seem foolish for Red Hat to abuse the Fedora community like this, because the community is precisely what makes Fedora so valuable to Red Hat, but I would have said the same about the reporters at the newspaper. Point is, with a future change in ownership or leadership or business strategy, all bets are off.
But surely potential future hypothetical scenarios shouldnât stop us from improving Fedora for our users today! Instead of saying âjust trust us,â Iâll instead say âtrust but verify.â Community control is essential. Look over the proposed transparency mechanisms and complain if they seem inadequate. Get involved yourself, or encourage other people to get involved. Ideally the community control should robust enough to at least notice and sound an alarm if Red Hat decides to become evil.
eos-event-recorder-daemon (the component that submits metrics to Fedora) and eos-metrics-instrumentation (the component than submits miscellaneous metrics to eos-event-recorder-daemon) both have systemd services (which will be disabled by default) and can both be uninstalled. Thereâs also an eos-metrics library that allows applications (and eos-metrics-instrumentation) to easily submit metrics to eos-event-recorder-daemon. eos-metrics cannot be uninstalled, but it also doesnât do anything unless eos-event-recorder-daemon is running.
My opinion: that should be entirely up to the maintainers of each spin.
3 Likes
Again, Iâm not saying that the data wouldnât be useful, but this justification is not a strong one, in my view.
I took a look at Distrowatch today. Out of 100 distros listed for the latest âhitsâ, 95 or so are Linux based. And, while Fedora was in the top 10, it had fewer than half the hits of the top two distros, MX Linux and Mint, and 20% fewer than Debian. My point? Fedora, while, sure, itâs a great distro with a legacy of great developers associated with it, is a tree in a forest. If a hardware vendor wants to actively gauge interest in making their products available for Linux platforms, they should look at an already existing platform for that, such as Linux Hardware.
Also, for those folks who do get their hardware chosen by employers, as I was for over 30 years, there are often restrictions for their OS choices. Ours were. And for many of those years it was some enterprise variant of Red Hat. The last of these was RHEL. You folks already have the capability to gain metrics from RHEL.
1 Like
This is getting at part of what Iâve been arguing about. If you donât embed a software platform to gather information in the general Fedora software distro, itâll be more difficult to misuse it should all bets be off down the road. Your story is both terrible and sad, too.
Whatâs the cliche? The road to hell is paved with good intentions?
1 Like
I doubt thatâŚ
Exactly because:
Telemetry in Enterprise grade offerings/products is usually unacceptable.
I would imagine this is even more so true when it comes to Linux, but even Windows Enterprise offers the best (among the rest of their versions, still bad overall) options for disabling much of the telemetry.
P.S:
Distrowatch has been known for the bad quality of their âpopularity dataâ among the Linux community, Iâd suggest you donât pay too much attention to it.
To be fair to them, they donât claim otherwise and they are open about it :
The DistroWatch Page Hit Ranking statistics are a light-hearted way of measuring interest in Linux distributions and other free operating systems among the visitors of this website. They correlate neither to usage nor to quality and should not be used to measure the market share of distributions. They simply show the number of times a distribution page on DistroWatch was accessed each day, nothing more.
The architecture currently doesnât leave a lot of room for other spins to be able to use it. Itâs rather hyper-focused on GNOME (which I think is a huge mistake) and there is not an architecture in which we would have universal opt-in metrics collection with the ability to extend it with more metrics as desired.
Have you considered approaching KDE or Cinnamon or others (upstream) about whether theyâd be interested in leveraging the architecture for metrics? Having a universal framework for this would simplify things considerably for many communities and users alike.
1 Like
The more relevant part of that post was that Fedora is a tree in the forest of Linux distros. I tried to emphasize that fact when I stated âMy pointâŚâ. I donât think we need Distrowatch to be super accurate to allow for that one to make sense.
What part of the architecture do you consider to be GNOME-specific? Itâs really not.
I have not, but eos-metrics certainly could serve as a universal framework for these desktops if they wish to do so.
Recommendation: Limit desktop usage statistics collection to preinstalled apps only.
I am not sure the need for fedora analytics to collect what apps I install on my system. Although only known packages are collected, there are still lots of âknownâ packages that are much less popular.
Iâd be willing to turn it on if the telemetry is limited to preinstalled apps + maybe popular apps. At least provide an option to allow tracking only select apps specified by user.
Edit: Iâve check detailed info about what data is collected and I have some more recommendations.
- updates â repos enabled - will this be made optional or be avoided? Itâs not a big concern but itâd be better if I can tune the analytics to only core fedora components.
- Apps â usage - please provide a way to completely turn off this part, at least for 3rd party apps. Thatâd be better. Better, avoid it altogether.
- GNOME â general usage - better limit it to GNOME apps, especially metrics like no. of windows per app.
In general my recommendation is to focus the telemetry to core fedora apps only. This will provide peace of mind to privacy freaks like me and the collected data will be more useful and applicable to more users at the same time.
With this post Iâm going to better explain my point of view that I quickly jot down in a previous post.
I will mainly speak of increasing users trust and of what the telemetry system should allow from a userâs point of view. I really encourage you to read through this even though it might be a bit long, because I really do believe that a successful telemetry system will be enabled by a lot of people only if perceived as trustworthy, and at the same time any kind of âforcingâ it to users will only inevitably backlash, destroying the reputation of the distro forever. You might do thousands of good things, but you do one thing very wrong and the users wonât ever forget it. I believe anyone has direct experience of this from their lives (who have never did something wrong that some people did not forget) and this is some basic human psychology to at least acknowledge. A lot of famous people and brands lost their trust among people after repeated failures or even a single huge mistake (some people call it trust thermocline), I donât even have to provide concrete examples as there are many across various fields.
If you take this and consider that a lot of users in the Linux land are generally very careful when it comes to ideals in general and tend to judge harshly other infamous products (Microsoft Windows telemetry and lack of control, for example, but also Ubuntu and their opt-out telemetry system with dark patterns, the Ubuntu-Amazon incident and so on), you have to bring this proposal in a landscape where a single mistake can cost the reputation of the distro forever, as users are among the most susceptible of this kind of change.
That said, here I argue that if a telemetry system is implemented in a totally respectful way and it provides full control then it will be perceived as good and it might lead to an increase of the amounts of data collection and backlash will be prevented.
Benefits of this new proposal version, and some details on what can be done
Increased trustworthiness
I really appreciated this new proposal. It sounds a lot more transparent and well-defined.
Authors of this proposal and anyone else here have to deal with the reality: forcing any telemetry or using dark patterns (like in the previous proposal) will not work and will act as backlash (many Fedora users are here because the distro respects them), so the only solution is to simply accept that the only way to get some telemetry is from users that are willing to give data. This might be not fully representative, but at least it might be representative in a certain way of a certain portion of users. Pushing telemetry in any other way will only destroy the distro reputation forever like it happened for Ubuntu.
I believe that full transparency, no dark patterns, fully opt-in implementation and a huge commit to not abuse data or let anyone else abuse it will lead to a larger userbase accepting such data. In the long run this will really help in reputation and in prestige of the distro, setting a milestone for other distros on how to really implement a transparent and respectful telemetry system.
Many Fedora users really do care about privacy, so when put in front of a choice with full transparency and complete control they may be more willing to let their data be collected and processed than in the case, for example, of opt-out or dark-pattern, even though the same data is collected (yes, I am talking about how users will perceive the telemetry, and this is very important). This new proposal version is a lot better than the previous one in this regard, with the chance of it being implemented in a totally respecting manner. The user will not perceive it as being forced through them, but it will be instead perceived as a legitimate choice they did.
Granularity
That said, I think granularity would also help. For instance, I will be very willing to immediately give all my data related to hardware, a bit less willing to give away installed applications list, and not willing to give away applications usage data. This means that facing a non-granular option âenable all or nothingâ I would chose ânothingâ simply because granularity has not been an option. If telemetry is implemented in a granular way, that would surely help people both feeling in control of their data and to provide as much data as they feel comfortable with. Granularity will help maximise the collection as users would instead opt out from everything rather than allowing some bits to be collected, and at the same time it will make the user feel in complete control. Even tech giants who still collect data in a shameful way use granularity as a kind of pattern to make people feel in control. Of course, we can do better than tech giants and actually provide granular telemetry control with actual control from the user. I know this is not easy to implement, but I find it paramount for a successful telemetry system that is perceived as trustworthy.
Policy Update frequency
Another important aspect is how telemetry system will change with respect to amounts and nature of collected data. This has been thoroughly discussed in the previous proposal and again, I believe the best way is to change at most at each release to avoid confusion (or needless or annoying interruptions of work after simple updates: no one wants to be interrupted by common updates, ever). New data collection options should be presented in a screen after the distro upgrade, do not make it opt-out but rather preserve the same opt-in phylosophy, be transparent and authentic, present any new option with an understandable explanation of what it does and why enabling it would help the distribution. Again, trust and transparency and no dark patterns will pay back in the long run.
Being always in control
Those options should be toggleable later, either to be activated or to be deactivated. I think of new Fedora users or users that are trying Fedora: they might not be sure whether or not to trust the telemetry system, so they might disable it first, hear that it is not âevilâ later, and then activate it after witnessing the trust of it; or similarly, users that simply change their minds about giving some data.
Sent data should be somehow seen and inspectable. I believe it makes no sense to show data before sending it each and every time because prompting users will be annoying, so I believe that a simple âclick here to see an example of collected data you will send if you enable thisâ (can be a button, âsee collection exampleâ) when you opt-in or when you toggle a telemetry option can be useful to really help people feel comfortable with the data theyâre going to provide. Again, this is all to let people feeling comfortable and trust the telemetry system.
I also believe, as already discussed here, that aggregate data should be visible somehow, like anyone should be able to access anonymised data. This should of course be also considered from a security point of view to avoid accidental or unwanted disclosure, and Iâm no true expert on the matter so I will let others provide feedback about that 
Cross-DE support is important
Another fundamental bit: I believe that telemetry should be toggleable in the same way in any Spin. This can be done simply not making it depend on GNOME Settings or Whatever-DE-settings, and in general building a tool that works across any DE or WM. It should be done in a separate application, so that if I want it to be enabled in XFCE, LxQt or Cinnamon etc. it should.
This will also prevent the inevitable bias that will occur in the case data collection will be available on GNOME only, and it will also provide the Spins Groups and people working with Spins DEs and WMs a chance to access data related to usage on their platforms. As a side effect, this will also lead to two other important aspects that I will discuss below: the portability of the system to other distros and the fact that this way it will not be perceived as the next âGNOME-only Red-Hat-esque move to take down the Linux ecosystemâ (really, lots of people would believe so. As an anecdote I did not join my local LUG because the vast majority of them thought in a similar manner).
Benefits of making it platform-independent
Portability
Making it non-GNOME-centric will improve portability towards other distributions since the technology will be DE- and distro-independent. I know that platform-independency is not a goal of the proposal and it will make implementation harder, but it will result in a system that it is not bound to the usual Red-Hat products and as such it will be perceived as much more trustworthy by the general public. No one will yell âRed-Hat/GNOME evil they implemented a system which is closed to their platformsâ and be right even in the slighest. Hence, doing so will likely improve how people perceive it across Fedora and other distributions, as those kind of technology that only works in a specific distro or DE are generally perceived as evil and kind of âbullyâ especially when the DE of implementation is the mainstream one.
Portability can also be an opportunity to set a new standard of respectful telemetry that can be enabled across distributions, as already said a kind of being leading edge (âFirstâ) for Fedora.
As a last plus, a platform-independent telemetry system might be useful for server editions too. This means that a simple CLI interface shall be available, to toggle the same options that are available in the GUI. Powerusers and system administrators that are not scared by the command-line can enable it in server edition, atomic editions without GUI. This will also help on the Workstation/Spins side: I genuinely prefer the command-line as I can easily create an install script with the necessary telemetry enabled, and it might also help users on Fedora Minimal system which might not want to have the GUI installed but would rather enable telemetry via the cli.
Anyone, anywhere, should be able to enable telemetry without installing GNOME or using workarounds/hacks.
Dismissing the usual annoying comments on Red-Hat evil, everything is GNOME-centric, and so on
As already pointed out before, making this system non GNOME-centric will be seen as more trustworthy simply because it is not tied to the mainstream. Any user adopting non-mainstream DEs or technology will be more enthusiasts if this telemetry system will be implemented without being bound to a mainstream technology. I know this can sound silly and there will always be someone complaining about anything, but doing it this way will likely help dismissing a lot of complaints about that.
Conclusions
I truly believe that the above points will result in a system that is more transparent and perceived as more friendly even though the amount and quality of collected data stays the very same. If this means adding technical difficulty which results in delaying the deployment into another release this is fine, I totally know this is a best-effort project and contributors are not expected to go great lengths just to develop the perfect telemetry system in time. At the same time, though, I strongly believe that implementing telemetry in a respectful way as above will repay with benefits when it comes to users trust and even amounts of collected data.
Thank you all for your proposal and your efforts in making Fedora a great Linux distribution.
Edit: fixed some typos, better explained some aspects with short clarifications
I think it should be limited to hardcoded known repos, because one of the promises is that we donât collect personal data, and an RPM repo name could be anything (e.g. âMy Companyâs Secret Internal Repoâ).
But limiting metrics collection to only GNOME core apps and popular apps or preinstalled apps is too strict. Applications that want to submit metrics should be able to do so, and less popular applications deserve to be counted in usage statistics. The same rule about not collecting personal data should apply, though: we should only collect the names of applications if they come from known sources (e.g. Fedora, Flathub, RPM Fusion, fedora-workstation-repositories) because collecting the name of your personal/private application would be unacceptable.
My plan is to only provide one on/off switch. Fine-grained controls over what gets collected would be extremely complicated, and pointless because none of this data is going to be associated with you.
Currently the system is all or nothing, so users who require granularity will unfortunately have to disable the whole thing. My hope was that we would collect so little data that granularity would not be required. But maybe Iâm wrong. I donât plan to work on granularity myself; however, it surely wouldnât hurt anything, so if somebody else wants to work on this, I think that would be fine.
That said, we wouldnât want to have a complex user interface for controlling metrics granularity installed by default, so if you want a user interface for this, it would have to be a separate application that users would need to install. Applications that are installed by default need to be very simple, and thereâs surely no way to expose granular telemetry options in a simple way. Thatâs probably fine, though; most users wonât care, and users who do care should be fine with installing an application.
So: not opposed to this, but donât have time to work on it personally. Help welcome.
Iâm thinking something approximately along these lines. We might sometimes want to update the policy for what data gets collected more frequently than every 6 months, but thatâs probably about the right timeframe for most metrics. I donât think we can build a user interface for displaying what new data gets collected directly into the OS, though. It would be pretty complicated, and we donât want disruptive prompts opening up on usersâ desktops. My suggestion is to keep this information on a website instead, where itâs visible to interested users but also doesnât get in the way of everybody else. Maybe we could use RSS/atom or a mailing list to notify users when there are updates to the policy.
Of course you can turn it off at any time.
I also agree we need a tool to inspect what data has been sent. (Although again, this should be a power user tool rather than something that is installed by default.) I actually had been planning to work on this myself, because I agree itâs very important, but Iâm afraid I may have to declare to-do list bankruptcy, so this might turn into another help welcome area.
But at the least, we should be able to come up with some workaround. Maybe we could have an easy-to-deploy container that comes with everything you need to run your own metrics server locally, including a way to visualize the data it contains. Then youâd only need to change the configuration URL for which server to connect to.
We have to balance the value of cross-desktop support with user experience. Like I said above, thereâs nothing preventing other desktops from using the same metrics infrastructure. But the on/off controls built into the OS need to be desktop-specific because anything else would be a jarring user experience. We donât want to have a cross-desktop system-config-metrics app installed by default for the same reasons that older system-config apps were annoying and have been obsoleted by pushing settings into gnome-control-center.
Anyway, having a cross-desktop app to control metrics collection is possible for desktops that donât want their own UIs, but also not the best user experience â GNOME users would be frustrated if itâs not a GNOME-style app, KDE users would be frustrated if itâs not a Plasma-style app â so not something weâd want to ship by default. So the underlying implementation is of course cross-desktop, and any future power user tools can also be cross-desktop, but the user interface that gets installed by default should be desktop-specific.
2 Likes
what is the need for fedora to collect 3rd party usage metrics? My understanding is this metrics is to improve the user experience of fedora by re prioritizing what needs work and what doesnât. Collecting usage time for 3rd party apps is a bit much personally. If you want to collect data on compatibility issues, collect crash counts of all apps. Any app that has a lot of crashes is being used by lot of people and needs more work.
If possible, having a settings page for controlling telemetry in a fine grained way will be nice. The main toggle is can be shown in the initial set up and if user decides to opt in, the granular controls can have sensible defaults. The user can always use the fine grained controls to share exactly what aspects of his usage will get shared. I think fedora will get more data in an opt in system this way as more users(including me) are willing to share partial data.
Edit: The decision to not collect private appsâ names is useful for corporate environment, but as a casual user my concerns are a bit different. I hope you guys understand.
IMHO, If information on what applications are being used is of interest, this should be done at the repo level not on a users system level. Yes I know this would only work for Fedora controlled mirrors, but it would get information from all desktops/installs not just certain ones. And depending on how clever they want to be, they could collate the data as its collected and determine which desktop edition is is based on if that IP is also requesting Gnome/KDE/XFCE/ETC packages in the same session. And at that level, the risk of it collecting sensitive private user data is effectively zero. Any metrics that could be collected would be already mostly anonymized, as long as they scrub the IP from the data before being saved into a dbase.
This also would avoid any custom user/business repos from being potentially captured to, as it would only operate on Fedora Controlled repos where they already have the ability to collect whatever they want since its their infra.
No check the details they actually want usage time, launch count, no. of open windows etc⌠This is a bit concerning tbh
This change proposal has now been submitted to FESCo with ticket #3242 for voting.
To find out more, please visit our Changes Policy documentation.