Is Apport Enough in 2025?

Project Discussion
1

I’ve been thinking about what ex-Windows users struggle with when they move to Linux, and how we can smooth those rough edges to help desktop adoption. One question that keeps popping up is whether Apport is still adequate in 2025.

Apport can catch crashes and help users report them—or even send reports automatically—but that’s a narrow slice of what modern operating systems track. Proprietary systems gather far more detailed telemetry: not just crashes, but non-fatal errors, failed app launches, slowdowns, and overall system performance. By comparison, Ubuntu’s diagnostics are minimal.

It might be time for Ubuntu to rethink what Apport should be. Maybe it needs to expand beyond crash detection to pick up non-crashing application errors, measure performance indicators like login-to-desktop time, track app launch failures, and gather data on how long apps take to start. All of this could be done in a privacy-respecting way.

Expanding Apport—or building a companion tool—could help Ubuntu grow into a more mature desktop platform and give developers better insight into the real-world experience of their users.

Even Firefox which is open source today gathers far more telemetry on an opt-in basis than Ubuntu as an entire operating system does.

2 Likes
2

As someone in the IT Security sector myself, I think one of the problems is ‘telemetry can leak private data’. Even if there were telemetry integrations like this, it would be immediately frowned upon by the public userbase as ‘invasive spyware’. (Go see 20.04 era and the Amazon integration hellstorm).

Additionally, the scope of such telemetry is overly wide. Consider: much of the repository is Universe packages that have issues and don’t have dedicated responders. Thus tracking those issues actively in something like Sentry telemetry systems would be pointless.

Additionally, we have to be extraordinarily careful about private data being gathered and leaked. Which again goes to privacy and security.

But with my Technical hat on as someone who’s been working with and using Ubuntu since 2009:

It would be wonderful to have more in-depth active tracking of crashes, etc. but the scope has to be exceedingly narrow and then have extremely fine grained privacy controls on the metrics data to prevent data leakage. Which means you are not changing the status quo by simply replacing one tool for another - even with scope of operations expansion.

Apport also doesn’t send reports unless you tell it to. Any other tool needs a similar system. And that is currently not really an available option in most systems for ‘selective sending’. And writing a new system would take time. And you still have the data privacy concerns including GDPR compliance.

5 Likes
3

As someone in the IT Security sector myself, I think one of the problems is ‘telemetry can leak private data’. Even if there were telemetry integrations like this, it would be immediately frowned upon by the public userbase as ‘invasive spyware’. (Go see 20.04 era and the Amazon integration hellstorm).

Undoubtedly, this is why Mozilla uses an opt-in approach, as seen in Firefox. The problem with Amazon integration lies in its opt-out design, which seriously compromised user privacy by exposing data for Canonical’s commercial benefit. I don’t expect the same backlash if the data collection were focused on improving the desktop experience or identifying bugs that manual release testing often misses—a process that, frankly, is insufficient on its own.

Concerns around PII and sensitive data leaks are not new; Mozilla has addressed them, and Canonical could do the same by limiting access to data until any inadvertent sensitive information is filtered. Such leaks are unlikely. If you’re concerned, I’d ask: do you have the same concerns about Apport? Why trust Apport as it is, but not for collecting additional metrics—like app load times, time to desktop load after login, or application hangs? Apport is already a form of telemetry; it just focuses on crashes. And even then, it doesn’t capture every crash.

Additionally, the scope of such telemetry is overly wide. Consider: much of the repository is Universe packages that have issues and don’t have dedicated responders. Thus tracking those issues actively in something like Sentry telemetry systems would be pointless.
Additionally, we have to be extraordinarily careful about private data being gathered and leaked. Which again goes to privacy and security.

I agree that collecting additional opt-in telemetry from every package and application is unlikely to be worthwhile. However, starting with core software components and the default GNOME applications would be a reasonable first step for Ubuntu Desktop. I also fail to see why one would be wary of expanding Apport’s functionality while having no qualms about its current iteration. The same hypothetical privacy risks present in Apport today would still exist if new data were collected.

It would be wonderful to have more in-depth active tracking of crashes, etc. but the scope has to be exceedingly narrow and then have extremely fine grained privacy controls on the metrics data to prevent data leakage. Which means you are not changing the status quo by simply replacing one tool for another.
Apport also doesnt send reports unless you tell it to. Any other tool needs a similar system. And that is currently not really an available option in most systems for ‘selective sending’. And writing a new system would take time. And you stll have the data privacy concerns including GDPR compliance.

I’m not suggesting replacing apport; instead, I propose expanding it to monitor default app performance and collect error data beyond crashes for all default apps.

4

That is beyond Apport’s scope. It’s more a crash collector and bug info collector, not a replacement for actual monitoring of core components. Which in turn when they crash trigger Apport collection.

I’m not sure expanding Apport monitoring is the proper solution here either, performance monitoring for core apps is even MORE likely to expose info and would have to be opt-in (like sending apport reports is!), and has even more regulatory chaos like GDPR to worry about and such. That’s why I think Apport is ‘fine’ for actual crash/error handling.

Additionally, consider also that the Desktop Team wouldn’t necessarily be the proper team. What if GNOME crashed only because of an incompatibility with a C library that is covered by Foundations and wasn’t caught during development? Then it needs Foundations to look at it. And what if they look at it and determine its a kernel-level issue? NOW you have the Kernel team added to the scope.

Another case: what if the error is because someone upgraded and its that user’s configuration at fault? Because upgrading doesn’t migrate config formats over always. Then you are introducing useless noise to the system.

Another case from my radar space: You installed something - an external plugin or such that works with software 1.2.3 but now the upgrade is 1.3.5 and now your addon is causing 1.3.5 to crash. That means there’s noise now from users misconfiguring their systems with incompatibilities that load into the tracker. And may send people hunting them but not able to solve nor reproduce it. (And this is a HUGE chunk of things lately with ChatGPT and AI giving users needing help bad advice, or them following random Internet tutorials)

And another common case I see nowadays: people with older hardware trying to use newer kernels but never updating their BIOS for compatibility. Or cases where older hardware just can’t get BIOS updates and generate crash reports. THAT would be another section of noise where we’d get reports but “we can’t do anything because you don’t have any BIOS updates necessary for this”. And then that just adds to the noise that Apport already would see.

I get it - better monitoring of errors, etc. would work. But given this is ‘worldwide scale’ and you are asking for things BEYOND the scope of crash reporting, you’re really asking for live metrics reporting to things like a Sentry instance, and the performance is going to heavily depend on endpoint hardware configs (old systems vs. cutting edge) and other issues where expanding Apport to cover doesn’t make sense because that’s not what Apport was made to do. Barring legality and jurisdictional issues (case in point Iran or Iraq may have issues with this due to sanctions or other issues, or even things like US/UK can’t collect data there due to sanctions, etc.).

(Also, you don’t gain anything by changing Apport to add these metrics, nor by simply switching tracking systems to Sentry or such, because you introduce the same logistical headaches that Apport does, but even more of them.)

5

The telemetry required for performance monitoring would make the data potentially at least personally identifiable, i.e., a detailed hardware profile. Surely this would not be acceptable both from a security and privacy perspective.

2 Likes
6

Taking just one example here, and putting aside security/privacy concerns, for a moment.

I can certainly see the benefit of more instrumentation in the desktop session: application launch time, time-to-desktop, memory hogs, and the like.

Since this is an optional activity, it could (at least initially) be something only enthusiasts install, with zero automated upstream submission. However, if it detects something, perhaps it could offer to craft a bug report for the user, and then run ubuntu-bug to gather the necessary data to submit it to Launchpad.

Enthusiasts who are already testing Ubuntu and using it on non-production environments could well be happy to review the data and send it. Using the existing bug reporting tool means it would follow the established processes and be gated on human action, not automation so that it wouldn’t flood an internal development team. Launchpad already has the smarts to search for existing issues, reducing the chance of duplicates.

The tricky part of this might just be detecting issues and knowing when something is an issue, rather than operating as the user intended.

What’s the ultimate goal, though? Bug reports saying “It takes too long to get to the desktop,” resulting in developers saying “We know, upstream bug,” and “We know, you have a single-core CPU from the past” don’t seem to me to be a ton of use, and might just rub everyone the wrong way.

I guess the big-picture question is: what problem are you trying to solve here, @redwoodsec?

3 Likes
7

As @popey said, putting aside security and privacy concerns for a moment…

Reality check seems to tell me this might end up like a dog chasing its own tail, rather than actually serving any useful purpose in the end.

8

Apport should first work with snaps

1 Like
9

I suppose pushing Ubuntu as a project to achieve software greatness beyond its current capabilities.

The Steam Deck, which is Linux-based, has telemetry built-in.

Firefox provides a range of telemetry options.

In essence, manual testing with end users alone is inadequate from a quality assurance standpoint to develop exceptional software. Implementing telemetry would result in releases with fewer post-release issues. It would promptly identify software defects, enabling more effective releases.

I believe privacy concerns are valid, but they can also be easily addressed by adhering to industry-accepted standards for data handling with a privacy focus.

10

Yes, generally, I would say that Apport should also be able to identify every crash, and right now, even that task is genuinely poorly performed.

This is why I am pushing for a stronger investment in QA of Ubuntu.

11

@redwoodsec So you’d like the dog chasing its own tail then. And security and privacy would be severely compromised. Even with so-called industry standard measures, the extensive telemetry you advocate would make the user easily identifiable. It’s in the nature of the beast, one could say.

13

Which is why I stated what I said about privacy @redwoodsec

What you want is a fully audited system complete with performance metrics, hardware profiles, etc. as well as crashes to be collected and audited by ‘developers’. However, let’s expand this a little. What you call “Core Components” is only for standard Ubuntu Desktop. Lubuntu, and Kubuntu rely on LXQt and KDE packages which aren’t under ‘core’ Desktop Team purview. Xubuntu uses XFCE, same situation.

Additionally, it would be trivially easy then to fingerprint every system using Ubuntu, and then you REALLY have to begin worrying about privacy laws and regulation.

Apport doesn’t catch everything, correct. But if it did, then you’re facing quite a privacy and protection legal headache that is beyond Apport or Ubuntu’s scope to handle. Consider GDPR - if you requested data removal under GDPR then we would lose the very reports you wanted collected as well. Which opens the legal can of worms that I am sure Canonical would rather not mess with.

(And Firefox hasn’t solved those issues either with regards to privacy around that data either and regulations therein)

2 Likes
14

I think using telemetry to improve Snap on Ubuntu makes a lot of sense. Snap has struggled with performance issues for a long time, and aside from its limited app availability, performance is arguably its biggest weakness. How are those problems supposed to be solved without detailed performance data from real users across a wide range of hardware and configurations? Do you think gaming on Linux would be where it is today if Valve had gutted telemetry in Steam for Linux and SteamOS, leaving itself blind to performance data? Telemetry from Valve has driven fixes in Linux libraries and software that likely never would have happened otherwise.

My goal is to address performance issues that are concealed from distro projects and app developers, thereby limiting the potential of Linux as a desktop operating system.

15

As someone who worked on the team, I hard disagree.

Performance was a massive issue, but that’s largely been solved, mostly.

The problem isn’t that the team (at the time) didn’t have telemetry. It was the lack of recognition that there was a problem, the lack of desire to fix the (known) problem, and the lack of engineering effort allocated to fix it.

They knew there was a problem. I know, because I worked there. We banged this drum over and over.

So, no, performance isn’t the most significant weakness. There are at least two or three more that are way more of a problem:

  • Outdated, abandoned, and insecure apps in the store
  • Confinement makes some applications difficult to package well
  • Lack of buy-in from the rest of the Linux ecosystem

It’s not data they lack, it’s resources and motivation, IMHO.

I don’t think this Valve/Steam comparison is as compelling as you think it is.

  • Steam is a proprietary storefront selling DRM-encumbered, proprietary games to people who (generally) don’t care about software freedom and licensing.
  • Ubuntu is a (largely) open source desktop environment with a small number of optional non-free components.

The audiences for these two platforms overlap, but the philosophical expectations of users for each do not align.

Show, don’t tell.

Joining a community and telling them to do something rarely works in the open source world. Please don’t take that approach, it won’t amount to much. But if you prototype something, or publish a well-researched document, perhaps people will listen.

Could you show us what it would look like? Design something. Publish it, show people evidence, not conjecture and poor analogies. That’s how the open source community works.

2 Likes
16

This can be closed I learned much of what I’m asking for is already being worked on with Ubuntu Insights in future releases