Ubuntu Telemetry: What Ubuntu Collects and How to Disable It

Ubuntu telemetry is one of several ways an Ubuntu system communicates with Canonical. This comprehensive guide explains what Ubuntu Report and Ubuntu Insights collect, how the consent model changed between Ubuntu 24.04 and 26.04, and what happens when telemetry is disabled.

This guide also covers other Canonical-connected services, including APT, Snap, crash reporting, Ubuntu Pro, Livepatch, Landscape, MOTD news, connectivity checks, and firmware updates.

Finally, it shows how to monitor Ubuntu's network activity, which settings you can control, and the steps to harden Ubuntu Linux.

The goal is not to determine whether Ubuntu is “private” or “not private”, but to document what each component does, why it communicates with Canonical, and what control you have over it.

1. Is Ubuntu Privacy-Friendly?

Yes, Ubuntu can be reasonably privacy-friendly for most users. But turning off Ubuntu's telemetry does not mean your computer will stop communicating with Canonical.

Ubuntu has several different components that can communicate with Canonical or other online services. System telemetry is only one of them.

Software updates, Snap, crash reporting, and optional Canonical services can have their own network activity. These connections serve different purposes, so it would be misleading to call every connection to a Canonical server “telemetry.”

For example, Ubuntu may contact Canonical when checking for software or security updates. A system using Snap can communicate with the Snap Store, while crash-reporting components can communicate with Canonical when configured to report problems. These activities are separate from Ubuntu's system-information reporting.

The good news is that many of these activities can be controlled by the user. You can choose not to share your Ubuntu's system information, control crash reporting, remove Snap if you do not need it, and avoid optional Canonical services.

Please note that “privacy-friendly” does not mean “completely private” or “completely offline.” Ubuntu will still receive software and security updates and work with online services. If you use those features, some network communication is expected.

So instead of asking:

"Does Ubuntu send anything to Canonical?"

One should ask:

"What information can Ubuntu send, why is it sent, and which parts can I control?"

That is what we will investigate in the rest of this guide. We will look at Ubuntu 24.04 and 26.04 versions, examine what their telemetry systems collect, investigate Snap and other Canonical services, and show you how to check Ubuntu's network activity yourself.

By the end, you should be able to decide whether Ubuntu's privacy model is acceptable for your needs and what you can change if it is not.

2. What Does Ubuntu Telemetry Actually Collect?

Ubuntu's system-information reporting has changed over time. Ubuntu Report was the older reporting tool, while Ubuntu Insights is its newer replacement.

Ubuntu 26.04 provides graphical controls for Insights under Settings → Privacy & Security → Telemetry, including a way to preview the report before sharing it.

2.1 Ubuntu Report

In the older Ubuntu versions, Ubuntu Report was used to collect information that describes the computer, its software environment, and how Ubuntu was installed.

The information could include:

• Ubuntu version
• Computer manufacturer and product
• BIOS vendor and version
• CPU and GPU information
• Amount of RAM
• Disk and partition sizes
• Screen resolution and refresh rate
• Desktop session information
• Language and time zone
• Installation choices, such as installation media and partitioning method
• Whether certain options, such as automatic login or Livepatch, were enabled during installation

Ubuntu Report was designed to show the collected information before it was submitted. Its command-line tool also provided a show mode that displayed the report without sending it.

If the user declined, the published implementation sent an opt-out message rather than the normal system-information report.

2.2 Ubuntu Insights

Ubuntu Insights is the newer replacement for Ubuntu Report. It was introduced with Ubuntu 25.10 and continues in Ubuntu 26.04.

Canonical describes Ubuntu Insights as an opt-in system for sharing non-personally identifying system metrics. Previous consent given to Ubuntu Report is not automatically carried over to Insights.

Insights can collect several categories of information.

Hardware information can include:

• Computer manufacturer, product name and version
• CPU name, vendor, architecture, cores, sockets and threads
• GPU device, vendor and driver
• Total physical memory
• Disk and partition information
• Display resolution, physical size and refresh rate

Software information can include:

• Operating system and Ubuntu version
• BIOS vendor and version
• Language or locale
• Time zone

Ubuntu and desktop information can include:

• Ubuntu Pro attachment status
• Desktop environment
• Session name and type

Installation and upgrade information can also include:

• Installation type and media
• Partitioning method
• Installation language
• Whether the minimal installation was selected
• Whether restricted add-ons were selected
• Installation stages
• The Ubuntu version being upgraded from
• Original installation media
• Upgrade method and stages

For Ubuntu running under WSL, Insights can also collect WSL-specific information such as the WSL version, subsystem version, kernel version, and certain configuration states.

The Insights project is open source and is specifically designed to let users inspect what is being collected. The reports are cached locally and that consent is checked both when information is collected and when it is uploaded.

2.3 Why Does Canonical Collect This Information?

Canonical says it uses this system information primarily for engineering and improving Ubuntu. The stated purpose is to understand typical hardware configurations and selected Ubuntu features so development and testing can focus on real-world systems.

Canonical also says the information may be processed globally and that aggregated Ubuntu system information may be made publicly available.

There is an important privacy distinction here.

The information described in the telemetry report is primarily about the computer and its software environment. It can reveal what hardware you have, which Ubuntu version you are running, your display configuration, installation choices, and aspects of your desktop environment.

That is very different from collecting your browser history, the contents of your personal files, or a record of everything you do on your computer. Nothing in the system-information list described by Canonical indicates that those types of user-content data are part of Ubuntu's system telemetry.

Canonical describes the information as non-personally identifiable and states that, if you choose not to share it, Canonical will not receive the system information covered by that notice.

So, Ubuntu's telemetry is more accurately described as system and usage metrics than as a record of your personal activity.

But this still leaves an important question: What happens after you turn telemetry off?

And even if Ubuntu stops sending the system information described above, can other parts of Ubuntu still communicate with Canonical?

That's what we are going to discuss in the next section.

3. What Happens When You Disable Telemetry?

If you tell Ubuntu not to share system information, what actually happens?

The short answer is: The system-information report is not sent to Canonical when you decline to share it.

Canonical's current notice on System Information Collection explicitly states that if you choose not to share system information, Canonical will not receive any item of system information covered by that notice. Ubuntu 26.04 also uses an opt-in model for Ubuntu Insights.

3.1 Opting Out Does Not Necessarily Mean Zero Network Traffic

There is an important technical detail here.

The reporting software can communicate the user's decision separately from the actual system-information report.

The older Ubuntu Report source code defines an opt-out payload:

{"OptOut": true}

The current Ubuntu Insights project also provides an example showing the same kind of opt-out payload when consent is false.

That distinction matters.

The opt-out message represents the user's decision not to share the system information. It is different from the normal telemetry report containing hardware, software, installation, and other system information.

In other words:

• Telemetry report: the system information that can be shared when you consent.
• Opt-out message: a record of your decision not to share that information.

Seeing an opt-out message does not mean that the full telemetry report was also sent.

3.2 Why a Canonical Connection Does Not Automatically Mean Telemetry Was Uploaded

Suppose you monitor an Ubuntu installation and notice a connection to a Canonical server after changing the telemetry setting.

It would be easy to conclude: “Ubuntu is still sending my telemetry”. But a network connection alone cannot establish that.

A connection tells you that communication took place. It does not, by itself, tell you what information was transmitted.

To investigate that properly, you need to know:

• Which process made the connection
• Which service or component it was using
• Which Canonical endpoint it contacted
• When the connection occurred
• What type of request was made
• Where possible, what information was included in the request

The published Ubuntu Report source code is a good example of why this distinction matters: its code separates the normal system-information report from the opt-out payload. Ubuntu Insights similarly documents an opt-out state separately from its example system-information report.

So simply finding traffic to a Canonical domain is not proof that Ubuntu uploaded telemetry.

3.3 Telemetry Is Not the Same as Every Canonical Connection

Turning off Ubuntu's system telemetry does not disable Ubuntu's other network functions.

Your computer should still communicate with Canonical for software and security updates, Snap functionality, crash reporting, or other services. Those activities have different purposes and should not automatically be classified as telemetry.

3.4 So, What Does Turning Telemetry Off Actually Achieve?

As per the Canonical's current notice, if you choose not to share it, Canonical says it will not receive that system information.

What disabling telemetry does not mean is that Ubuntu becomes completely silent on the network.

That is an important distinction because the next sections will examine those other connections separately. We will look at APT, Snap, crash reporting, and optional Canonical services and determine why they communicate, what information may be involved, and whether you can control them.

Later, we will also show you how to monitor Ubuntu's network activity yourself.

Key Takeaway: Turning off Ubuntu telemetry stops the sharing of the system information covered by the telemetry system. It does not mean Ubuntu will make no network connections to Canonical.

4. Ubuntu 24.04 vs. 26.04: What Changed?

Ubuntu's system-information reporting changed during the transition from Ubuntu 24.04 to 26.04.

Ubuntu 24.04 uses the older Ubuntu Report system. Ubuntu Insights was introduced during the Ubuntu 25.10 development cycle as its replacement and is included in Ubuntu 26.04.

4.1 Ubuntu 24.04: Ubuntu Report

Ubuntu Report was designed to collect information describing the computer, its software environment, installation, and desktop session. It shows users what is going to be reported and asks for acknowledgement before uploading it.

It also provides separate modes for displaying the report, automatically reporting it, and reporting that the user has opted out of data collection.

4.2 Ubuntu 26.04: Ubuntu Insights

Ubuntu Insights is the newer replacement for Ubuntu Report.

The main change is the consent model. Ubuntu Insights is an opt-in system for sharing non-personally identifying system metrics with Canonical. Consent previously given to Ubuntu Report is not automatically carried over to Ubuntu Insights.

Ubuntu 26.04 also provides graphical controls for Insights under Settings → Privacy & Security → Telemetry.

From this panel, users can manage Insights consent and preview the reports. The new Telemetry panel also replaces the previous Diagnostics panel.

4.3 What Happens During a Release Upgrade?

Ubuntu 26.04 integrates Ubuntu Insights into the release-upgrade process. When Insights is available and configured, the release upgrader can use it at the end of an upgrade, based on the existing consent state.

Ubuntu 26.04 can also prompt for Insights consent after a release upgrade when consent has not already been set or when another consent prompt is required.

However, Canonical explicitly notes that this does not prevent Ubuntu Report-based collection that may be triggered by a release upgrade. Therefore, saying simply that “Ubuntu 26.04 no longer uses Ubuntu Report” would be too broad.

For normal system-information consent on Ubuntu 26.04, Insights is the newer mechanism. But Ubuntu Report can still matter when you are investigating the release-upgrade process.

4.4 At a Glance

As I already stated, changing the telemetry system does not eliminate the other ways Ubuntu can communicate with Canonical.

APT, Snap, crash reporting, and optional Canonical services have their own purposes and network activity.

That is where we need to look next.

5. What Can Still Connect to Canonical?

Turning off Ubuntu's system telemetry does not make Ubuntu stop communicating over the internet.

That is not necessarily a privacy problem.

Ubuntu needs network access for software updates, Snap packages, and other services. Some of these connections also send technical information needed to provide the service.

5.1 APT and Ubuntu Updates

APT is Ubuntu's default package-management system. It connects to configured package repositories to download package lists, security updates, and software.

Ubuntu enables automatic security updates by default through unattended-upgrades. By default, it runs once per day and applies security updates from the configured Ubuntu archive sources.

Please note that APT does not necessarily connect directly to Canonical.

APT uses the repositories configured on your system. Those can include Ubuntu archive servers, mirrors, third-party repositories, or PPAs.

When APT contacts a repository, that activity is not Ubuntu system telemetry. Its purpose is to obtain package metadata or software updates.

The connection still involves ordinary network information, such as the client's IP address. That is a normal consequence of communicating with an internet service.

So if you see APT connecting to an Ubuntu archive or mirror, that does not mean Ubuntu has ignored your telemetry settings.

Important Note:

Do not disable security updates simply to reduce Ubuntu network activity. Ubuntu team recommends automatic security updates because the security risk of not applying them is generally greater than the risk associated with automatic installation.

5.2 Snap

Snap is a separate package and update system from APT.

If Snap is installed and you use snaps, snapd needs network access to search for snaps, retrieve package information, download packages, and check for updates. Snap documentation says installed snaps automatically check for updates four times a day by default.

Snap Store requests can contain technical information such as the Ubuntu series and CPU architecture. Depending on the request and configuration, device authorization and Store-related identifiers can also be involved.

Technical information being sent to the Snap Store does not automatically make it telemetry. Some of it is functional information that allows the Store to determine what package or version is appropriate for the system and to handle Store operations.

Snap should therefore be treated as a separate network and data path, not as an extension of Ubuntu Insights.

We will examine Snap's Store communication, update system, and application permissions in more detail in the next sections.

5.3 Crash Reporting

Ubuntu also has a separate crash-reporting system. This is different from Ubuntu Insights and the older Ubuntu Report system.

Apport collects diagnostic information when supported applications or processes crash. On Ubuntu Desktop, users can control how error reports are handled, including choosing whether reports are sent automatically, manually, or not at all. The default stable-release behavior is not to automatically upload crash reports without user interaction.

Crash reports deserve separate attention because they can contain considerably more detailed information than ordinary hardware telemetry. Apport stores crash reports locally and can collect information about the crashed process for debugging.

On Ubuntu Desktop, whoopsie is installed by default and is involved in uploading crash reports to Ubuntu's Error Tracker when the relevant reporting path is used.

The default behaviour differs by platform. On Ubuntu Desktop, the user is given the choice to send crash reports manually. On Ubuntu Server, Apport is disabled by default, and no crash-reporting path is active unless explicitly configured.

This is why checking the crash-reporting setting directly is more reliable than assuming a single default applies to every Ubuntu installation.

So turning off Ubuntu Insights does not automatically mean that crash reporting is disabled.

They are different systems with different purposes and controls.

Privacy takeaway: If you want to minimise information sent after software crashes, check the crash/error-reporting setting separately from the Ubuntu Insights setting.

5.4 Ubuntu Pro and Livepatch

Ubuntu Pro is an optional Canonical subscription. It is not required for ordinary Ubuntu use.

When a machine is attached to Ubuntu Pro, Canonical can receive service-related information from the Pro client. This allows Canonical to manage the machine's subscription and provide the services enabled for that system. Ubuntu Pro is primarily a security and management offering for Ubuntu systems.

Livepatch is another optional Canonical service. It allows supported kernel security fixes to be applied without requiring an immediate reboot.

A Livepatch client periodically contacts Canonical to check for new patches. Canonical documents an hourly default check interval and says these requests can contain information including:

• system architecture
• CPU model
• kernel version
• boot time and uptime
• a unique machine identifier based on /etc/machine-id
• currently applied Livepatch version
• current Livepatch state
• time of the previous server request
• Livepatch client version

This is another useful example of why “Canonical connection” does not automatically mean “Ubuntu telemetry.”

If Livepatch is enabled, this communication is part of providing the service.

If you do not use Livepatch or Ubuntu Pro, these particular connections are not part of the traffic generated by those services.

Privacy takeaway: Treat optional Canonical services separately from Ubuntu's system-information reporting. Enable them when you need their features rather than assuming they are required for Ubuntu itself.

5.5 Landscape

Landscape is Canonical's system-management platform. It is designed to manage Ubuntu systems from a central location. Administrators can use it for tasks such as software management, updates, monitoring, remote commands, and compliance.

Landscape uses a client-server model. The Landscape Client runs on the managed Ubuntu machine and communicates with a Landscape Server.

A normal Ubuntu installation should not be assumed to be enrolled in Landscape.

The management client must be installed and configured with a Landscape account and server. After registration and approval, it begins reporting data to the Landscape server.

Therefore, if you have never installed or configured Landscape, it is not normally a hidden management service running on your personal Ubuntu desktop.

5.6 Other Functional Services

Ubuntu also contains smaller components that can communicate with Canonical for specific functions.

One example is MOTD news.

5.6.1 MOTD News

The motd-news package periodically contacts Canonical servers to retrieve news and informational messages for the command line. Canonical's MOTD legal notice says that the request can include information such as:

• Ubuntu version
• operating-system name
• kernel version
• CPU architecture and model
• system uptime and idle time
• cloud environment
• curl version

Canonical also states that the IP address and other network information are transmitted to facilitate the internet connection.

This is separate from Ubuntu Insights and Ubuntu Report.

However, MOTD news is worth mentioning because, unlike a simple package download, Canonical explicitly describes this service as collecting system information to tailor the news returned to the machine.

If you do not want the MOTD service, you can disable it through /etc/default/motd-news as described in the link below.

• Disable Ads In Terminal Welcome Message In Ubuntu Server

There can also be other service-specific connections depending on what you install or enable.

For example:

• Snap has its own Store communication.
• Ubuntu Pro adds communication related to subscribed services.
• Livepatch contacts Canonical to check for kernel patches.
• Landscape communicates with a management server when configured.
• MOTD news contacts Canonical to retrieve command-line news.
• APT communicates with whatever package repositories are configured.

The exact network activity therefore depends heavily on the software and services present on your particular installation.

5.6.2 Firmware Updates

Another example is firmware updates.

Modern Ubuntu systems include fwupd, which provides firmware updates for supported hardware through the Linux Vendor Firmware Service (LVFS). The LVFS is a central service where hardware vendors upload firmware, and fwupd on the local system downloads and applies those updates.

During normal operation, fwupd periodically downloads firmware metadata from the LVFS. This is functional traffic. The system is checking whether any of its hardware has an available update.

After an attempted firmware update, fwupd can optionally report the result back to the LVFS. This reporting is opt-in, not automatic.

The report contains information that identifies the machine, the old and new firmware versions, and in the event of an error, enough debug information to be useful.

The LVFS documents several privacy protections around this reporting:

• The user's IP address is not shared with the hardware vendor and is not saved in the database.
• The machine identifier is a salted hash of /etc/machine-id, not the raw ID itself.
• The LVFS does not store reports for firmware it did not sign itself. The locally built firmware archives are ignored and not logged.
• Reporting can be disabled entirely by editing the relevant configuration files under /etc/fwupd/remotes.d/.

This is another useful example of a service that communicates with a remote server as part of its normal function. The metadata download is functional traffic. The post-update report is opt-in telemetry, and the user controls it.

5.7 Connectivity Checking

Ubuntu also includes a network connectivity check that is separate from the telemetry system, APT, and Snap.

This feature is provided by NetworkManager. Its purpose is to periodically test whether the system can actually reach the internet, or whether it is behind a captive portal — the kind of login page you see on hotel, airport, or café Wi-Fi networks.

The check works by contacting a specific URI. On Ubuntu, the default configuration points to connectivity-check.ubuntu.com.

The default interval is 300 seconds, meaning the check runs roughly every five minutes when a network connection exists.

What information is involved?

Canonical's package description states that no user data is transmitted in the connectivity checks. However, contacting the Ubuntu connectivity check server does reveal that the system is running Ubuntu (or an Ubuntu-based distribution) with NetworkManager.

That is a useful example of the distinction this guide keeps returning to: the check is functional metadata associated with a network feature, not system-information telemetry.

Can you control it?

Yes. Because the check is a NetworkManager setting, it can be configured or disabled.

The relevant options are:

• connectivity.interval - the number of seconds between checks. Setting this to 0 disables the check entirely.
• connectivity.uri - the URI that NetworkManager requests.
• connectivity.response - the expected HTTP body that indicates the connection is online.

On systems using the network-manager snap, these can be set with commands such as:

snap set network-manager connectivity.uri=http://connectivity-check.ubuntu.com/
snap set network-manager connectivity.interval=180

The same behaviour can also be configured through the NetworkManager configuration file on traditional package-based installations.

Privacy takeaway:

Connectivity checking is a functional feature, not telemetry. It reveals that you are running Ubuntu with NetworkManager, but Canonical states that no user data is transmitted. If you do not need captive-portal detection, the check can be disabled through the connectivity.interval setting.

5.8 What This Means on a Normal Ubuntu Installation

A fresh Ubuntu system with system-information telemetry disabled can still generate network traffic.

For example, it may contact package repositories when checking for updates. If Snap is installed, snapd may contact the Snap Store. Other connections can appear if you use crash reporting, Ubuntu Pro, Livepatch, or other services.

None of this means the telemetry opt-out has failed.

Think of Ubuntu's network activity as several separate paths:

A network monitor can tell you that a connection happened. It cannot, by itself, tell you that the connection contained Ubuntu telemetry.

To investigate properly, you need to identify:

1. Which process made the connection
2. Which Ubuntu service that process belongs to
3. Which server or endpoint it contacted
4. When and why the connection occurred
5. What information that service is designed to send

That is the difference between observing network traffic and understanding it.

6. Does Snap Collect Data Separately?

Yes. Snap has its own Store infrastructure and network activity, separate from Ubuntu Insights.

That does not mean Snap is collecting the same system telemetry discussed earlier.

Snap is a separate software distribution system. Its background service, snapd, communicates with the Snap Store to search for packages, retrieve package information, download snaps, and check for updates.

There is also a separate layer of personal information when you use Snap Store account or purchasing features.

It is therefore useful to separate four things:

1. snapd and its Store communication
2. technical information included in Store requests
3. automatic Snap updates
4. account and purchase information, where applicable

6.1 Snapd

snapd is the background service that manages installed snaps.

It handles installing, removing, configuring, and updating snaps. Its Store component also communicates with Snap Store infrastructure when Store access is required.

The current open-source snapd code identifies the default Store API as api.snapcraft.io and includes endpoints for searching, retrieving snap information, refreshing snaps, and other Store operations.

This means a computer with Snap installed can have network activity from snapd even when Ubuntu's system-information telemetry is disabled.

6.2 The Snap Store

The Snap Store is the central service through which most public snaps are distributed.

When snapd searches for a snap, retrieves information about one, downloads it, or checks for an update, it can communicate with Snap Store infrastructure.

The Store is therefore a separate network and data path from Ubuntu Insights.

This distinction matters because a connection to api.snapcraft.io does not by itself indicate that Ubuntu has ignored a telemetry opt-out.

It may simply mean that snapd is performing a normal Store operation.

6.3 Store Requests and Device Information

The current snapd source gives us a useful look at what Store requests can contain.

For Store API requests, snapd sets technical information including:

• Ubuntu series
• CPU architecture
• whether the system is running in classic mode
• Snap Store identity where applicable
• device authorization where applicable
• Snap client user-agent information where applicable

When cloud information is available through the device context, snapd can also construct a Store location value containing the cloud name, region, and availability zone.

The important qualification is “where applicable.”

These fields are not proof that every request contains all of this information. Different Store operations use different request paths and authentication requirements.

The most accurate conclusion is:

Snap Store communication can include technical device, session, authentication, and environment information depending on the operation and configuration.

That is more precise than saying that Snap continuously uploads a complete hardware profile.

6.4 Is This Snap Telemetry?

As stated earlier, Ubuntu Insights is specifically designed to collect system metrics for Canonical's engineering and product-improvement purposes, with user consent controlling whether those metrics are shared.

Snap Store communication has a different primary purpose: providing and managing Snap packages and related Store services.

For example, the Store needs to know a system's architecture so that it can handle software appropriate for that architecture.

Therefore, it would be misleading to call all Snap Store traffic “telemetry.”

A better model is:

This is exactly why turning off Ubuntu telemetry does not disable Snap Store communication. They are separate systems.

6.5 Automatic Updates

One of the most visible sources of Snap network traffic is automatic updating.

Snaps update automatically by default, and the snapd daemon checks for updates four times a day. Each update check is called a refresh.

You can see the current refresh schedule on your system with:

snap refresh --time

Sample Output:

timer: 00:00~24:00/4
last: today at 14:09 IST
next: today at 23:32 IST

The refresh schedule is configurable. Snap also provides controls for holding updates, choosing refresh windows, and handling metered connections. The documented minimum refresh frequency is once every 20 minutes when configuring a custom schedule.

This means a computer with Snap installed can make regular connections to Snap Store infrastructure even when you are not actively opening the App Center or installing software.

That network activity is expected behavior.

It is part of Snap's update mechanism, not evidence that Ubuntu's system telemetry is still enabled.

Automatic updating also has a security benefit. The newer Snap revisions can include bug fixes and security fixes without requiring users to manually check each application.

6.6 Account and Purchase Information

Snap has another privacy layer when you use account-based or purchasing features.

Canonical's Snap Store privacy notice says that when you use the Snap Store, Canonical may ask for personal information such as your name, address, telephone number, email address, and credit-card details.

Canonical says this information can be used to manage a Snap Store account, provide Snaps, and fulfil purchases. Payment information can be passed to Canonical's third-party payment processor for transactions.

This does not mean every Ubuntu user who installs a free Snap provides all of this information.

A user who installs a public Snap without using account or purchasing features is in a different situation from someone who creates an account or buys software.

So these personal-data flows should not be confused with the technical information exchanged by snapd during ordinary Store operations.

6.7 What About the Snap Application?

Please note that the Snap Store and snapd are not the same thing as the application you install.

After you install a Snap, the application can make its own network connections.

For example, a browser can connect to websites, a cloud-storage application can connect to its provider, and a messaging application can communicate with its own servers.

Those connections come from the application, not from the Snap Store.

Snap's security architecture is designed to run applications in a sandbox by default, with access to system resources mediated through interfaces.

That issue is important enough to deserve its own section, so we will examine it separately rather than treating application traffic as Snap Store traffic.

6.8 The Practical Privacy Picture

If you disable Ubuntu system telemetry but leave Snap installed, you can still expect network connections to Snap infrastructure.

A simplified picture looks like this:

Ubuntu Insights
      │
      └── System-information reporting
          (controlled by telemetry consent)

snapd
      │
      └── Snap Store
          ├── Search
          ├── Package information
          ├── Downloads
          ├── Update checks
          └── Technical device/session information
              where applicable

Snap Store account
      │
      └── Account or purchase information
          where applicable

Snap application
      │
      └── Its own network connections
          depending on the application

So the answer to “Does Snap collect data separately?” is: Yes, but Snap's Store communication is not the same thing as Ubuntu system telemetry.

snapd communicates with the Snap Store and can provide technical device, session, authentication, and environment information required for particular Store operations.

Snap also generates regular network traffic because it checks for updates automatically. If you use Snap Store account or purchasing features, Canonical can process personal information associated with those activities.

7. What Can a Snap Application Access?

In the previous section, we looked at what snapd and the Snap Store can communicate.

Now let us find the answer to another privacy question: What can the Snap application itself access on your computer?

This is where Snap's confinement and interfaces matter.

A Snap application is not automatically given unrestricted access to the host system. Most published Snaps use strict confinement, which limits access to system resources. Additional access is controlled through Snap's interface system.

However, not every Snap has the same level of isolation.

7.1 Strict Confinement

Strict confinement is the most common Snap security model.

A strictly confined Snap runs with a restricted security profile. It cannot access files, network resources, processes, or other system resources beyond its minimal default access unless the required access is provided through an interface.

Snap uses Linux security mechanisms including AppArmor, seccomp, and namespaces to enforce this isolation.

This can restrict access to things such as:

• files and directories
• network connectivity
• hardware devices
• cameras and microphones
• system services
• other applications and system resources

The exact permissions depend on the Snap and the interfaces it uses.

This is a meaningful security boundary.

But it does not mean that a strictly confined application has zero access to your system.

For example, an application that needs internet access can request the appropriate network interface.

So, Strict confinement means restricted access, but not zero access.

7.2 Classic Confinement

Some Snaps use classic confinement instead.

Classic confinement allows access to system resources much like traditional packages do. It therefore provides substantially less application isolation than strict confinement.

Classic confinement is generally used when software needs access to parts of the host system that cannot be provided through the normal interface system.

There are additional safeguards around classic Snaps:

• the Snap must use classic confinement
• publishing a classic Snap requires manual approval
• installing a classic Snap requires the explicit --classic option

For example:

sudo snap install <snap-name> --classic

The privacy and security lesson is this: A classic Snap should be treated much more like traditional software installed directly on the host.

You can inspect a Snap's confinement with:

snap info --verbose <snap-name>

The output includes its confinement information.

7.3 What About Devmode?

There is also a devmode mode.

Devmode is intended primarily for Snap developers and testing. A devmode Snap retains the strict security model as its basis but allows access that would normally be denied, while recording those accesses so developers can identify missing interfaces.

Devmode requires the --devmode option and is not a normal stable-channel distribution mode. Devmode Snaps do not automatically refresh while running in development mode.

For ordinary users, the two confinement levels that matter most are therefore:

1. strict → restricted access controlled through interfaces
2. classic → broad host access, similar to traditional packages

7.4 Interfaces

Interfaces are the mechanism that allows a strictly confined Snap to access resources outside its basic sandbox.

Think of them as controlled connections between the application and specific parts of the host system.

Depending on the interface, access can include:

• network connectivity
• audio
• cameras
• Bluetooth
• removable storage
• the user's home directory
• desktop services
• other system resources

The exact interfaces available and their connection rules vary by resource.

Please note that Interfaces are not always manually approved by the user.

Some interfaces can automatically connect on traditional Linux distributions, while others require an explicit connection. For example, the current home interface can be auto-connected for eligible Snaps on traditional distributions, while personal-files is not auto-connected.

You can inspect the actual interface connections for an installed Snap with:

snap connections <snap-name>

The following example shows the interface connections for Firefox snap:

ostechnix@ubuntu2604desktop:~$ snap connections firefox
Interface                 Plug                              Slot                            Notes
alsa                      firefox:alsa                      -                               -
audio-playback            firefox:audio-playback            :audio-playback                 -
audio-record              firefox:audio-record              :audio-record                   -
avahi-observe             firefox:avahi-observe             :avahi-observe                  -
browser-support           firefox:browser-sandbox           :browser-support                -
camera                    firefox:camera                    :camera                         -
content[gnome-46-2404]    firefox:gnome-46-2404             gnome-46-2404:gnome-46-2404     -
content[gpu-2404]         firefox:gpu-2404                  mesa-2404:gpu-2404              -
content[gtk-3-themes]     firefox:gtk-3-themes              gtk-common-themes:gtk-3-themes  -
content[icon-themes]      firefox:icon-themes               gtk-common-themes:icon-themes   -
content[sound-themes]     firefox:sound-themes              gtk-common-themes:sound-themes  -
cups-control              firefox:cups-control              :cups-control                   -
dbus                      -                                 firefox:dbus-daemon             -
desktop                   firefox:desktop                   :desktop                        -
desktop-legacy            firefox:desktop-legacy            :desktop-legacy                 -
gsettings                 firefox:gsettings                 :gsettings                      -
hardware-observe          firefox:hardware-observe          :hardware-observe               -
home                      firefox:home                      :home                           -
joystick                  firefox:joystick                  :joystick                       -
kerberos-tickets          firefox:kerberos-tickets          -                               -
login-session-observe     firefox:login-session-observe     :login-session-observe          -
mount-control             firefox:host-hunspell             :mount-control                  -
mount-observe             firefox:mount-observe             :mount-observe                  -
mpris                     -                                 firefox:mpris                   -
network                   firefox:network                   :network                        -
network-bind              firefox:network-bind              :network-bind                   -
network-observe           firefox:network-observe           -                               -
opengl                    firefox:opengl                    :opengl                         -
password-manager-service  firefox:password-manager-service  -                               -
pcscd                     firefox:pcscd                     -                               -
personal-files            firefox:dot-mozilla-firefox       :personal-files                 -
removable-media           firefox:removable-media           :removable-media                -
screen-inhibit-control    firefox:screen-inhibit-control    :screen-inhibit-control         -
system-files              firefox:etc-firefox               :system-files                   -
system-files              firefox:host-usr-share-hunspell   :system-files                   -
system-packages-doc       firefox:system-packages-doc       :system-packages-doc            -
timezone-control          firefox:timezone-control          :timezone-control               -
u2f-devices               firefox:u2f-devices               :u2f-devices                    -
unity7                    firefox:unity7                    :unity7                         -
upower-observe            firefox:upower-observe            :upower-observe                 -
wayland                   firefox:wayland                   :wayland                        -
x11                       firefox:x11                       :x11                            -

This is useful because it lets you move beyond the simple question:

"Is this Snap sandboxed?"

A better question is:

"Which parts of my system has this Snap actually been given access to?"

7.5 Personal Files and Permissions

File access deserves particular attention because your home directory can contain highly sensitive information.

A strictly confined Snap does not automatically receive unrestricted access to your normal home directory.

The standard home interface allows access to non-hidden files owned by the user in $HOME. Without that access, a strictly confined Snap generally cannot browse those ordinary home files.

Depending on the Snap and its interface declaration, home may be connected automatically or may need to be connected manually.

There is also a separate personal-files interface. This provides access to specifically declared files or directories in the user's real home directory, including hidden paths such as application configuration directories.

The personal-files interface is classified as a super-privileged interface, does not auto-connect, and requires an approved interface declaration for distribution through the Snap Store.

The distinction is important:

• home - access to non-hidden files in the user's real home directory
• personal-files - specifically declared access to selected files or directories, including hidden paths
• Snap-specific storage - the application's own private data area

A Snap also has its own per-Snap user-data directory. For non-classic Snaps, HOME is rewritten by snapd to point to the Snap's own SNAP_USER_DATA location, normally under: ~/snap/<snap-name>/<revision>.

This is different from the user's normal home directory. Snaps can access their own Snap-specific data without being granted the home interface.

That distinction is important when judging what a Snap can actually see.

7.6 Network Access Is Also an Interface

A strictly confined Snap can still have network access.

Network access is controlled through Snap's interface system. An application that needs internet connectivity can use the appropriate network interface.

This means an application can be strongly restricted from reading arbitrary files while still being able to communicate with internet servers.

That is normal for applications such as:

• web browsers
• messaging clients
• cloud-storage tools
• email applications
• online services

Please be mindful that Sandboxing controls what an application can access locally. It does not guarantee that the application is private when communicating over the network.

If an application has legitimate access to a file, camera, microphone, or other resource, the Snap sandbox does not by itself determine what the application's developer does with that information.

The sandbox limits the application's access to the system. It does not turn the application into a privacy-preserving application automatically.

7.7 Why Snap Application Privacy Is a Separate Issue

This is why Snap privacy should be considered at two different levels.

Level 1: Snap infrastructure

This includes:

• snapd
• Snap Store communication
• Store requests
• update checks
• device/session information
• account and purchasing features

That was the subject of the previous section.

Level 2: The Snap application

This includes:

• which files it can access
• which hardware it can use
• which system services it can access
• whether it can access your camera or microphone
• whether it can access your home directory
• whether it has network access
• what information the application itself sends to its developer or service provider

These are separate privacy questions.

For example, imagine you install a strictly confined photo application.

The sandbox may prevent it from freely reading your entire filesystem. But if you give it access to photographs, it can process those photographs.

If it also has network access, it can communicate with its own servers.

The Snap sandbox does not guarantee that the application itself is privacy-friendly.

It primarily provides a security boundary around what the application can access on the local system.

7.8 A Practical Check for Any Snap

Before installing or keeping a Snap that handles sensitive information, check three things.

1. Check the confinement level

snap info --verbose <snap-name>

Look for the confinement information, such as strict or classic. The output can also show whether devmode is enabled.

Example:

$ snap info --verbose firefox
name:    firefox
summary: Mozilla Firefox web browser
health:
  status:  unknown
  message: health has not been set
publisher: Mozilla✓
links:
  source-code:
    - https://github.com/canonical/firefox-snap
license: unset
description: |
  Firefox is a powerful, extensible web browser with support for modern web application
  technologies.
commands:
  - firefox
  - firefox.geckodriver
notes:               
  private:           false
  grade:             stable
  confinement:       strict
  devmode:           false
  jailmode:          false
  trymode:           false
  enabled:           true
  broken:            false
  ignore-validation: false
base:         core24
snap-id:      3wdHCAVyZEmYsCMFDE9qt92UV8rC8Wdk
tracking:     latest/stable/ubuntu-26.04
refresh-date: 2026-04-23
installed:    149.0.2-1 (8107) 287MB -

Check Confinement level of Snap Apps.png

2. Check the interfaces

snap connections <snap-name>

Pay particular attention to interfaces involving:

• home
• personal-files
• camera
• audio or recording
• removable storage
• Bluetooth
• network
• other sensitive system resources

The exact interfaces vary by application.

3. Check what the application does online

Even a well-confined application may legitimately need network access.

If privacy matters, look at the application's privacy policy and identify which online services it uses.

A sandbox can restrict local access, but it cannot guarantee that an application will not send information that the application itself can legitimately access.

7.9 Confinement is not Privacy

Snap's confinement model provides a meaningful security boundary, especially when an application uses strict confinement.

But strict confinement is not the same as complete privacy.

A strictly confined Snap can still have network access and can access sensitive resources when the necessary interfaces are connected.

A classic Snap is substantially more permissive and should be treated more like traditional software installed directly on the host.

So when evaluating a Snap, do not ask only:

"Is it a Snap?"

Ask:

"What confinement does it use, which interfaces are connected, what local resources can it access, and what does the application do with the information it can access?"

That is a much more useful privacy assessment than simply deciding that all Snaps are either "safe" or "unsafe."

8. Other Ubuntu Features That Can Generate Network Traffic

By now, you should be clear about one thing: A network connection does not automatically mean telemetry.

Ubuntu contains many features that may communicate with the internet for ordinary reasons. Some are Canonical services. Others come from GNOME, Debian, hardware vendors, third-party applications, or the wider internet.

This matters when investigating Ubuntu privacy because a network monitor can show that a process connected to a server. It cannot, by itself, tell you why the connection happened or what information was sent.

Two examples in Ubuntu 26.04 make this distinction especially clear.

8.1 Ubuntu 26.04 Search Providers

Ubuntu 26.04 includes GNOME Shell search providers for Snap applications and web search.

The Snap search provider allows the desktop's global search to find available Snap applications.

The web search provider allows a search from the GNOME Shell overview to be passed to the user's default browser.

Ubuntu provides controls for disabling these search providers in the Search settings.

These features are useful examples because network activity can be triggered directly by an action you take in the desktop.

That is different from background system-information reporting.

In simple terms:

• Snap search helps you find available Snap applications.
• Web search starts a web search through your browser.
• Their network activity is related to those search functions, not automatically evidence that Ubuntu's system telemetry is enabled.

The important question is not simply:

"Did Ubuntu make a network connection?"

It is:

"Which feature made the connection, and what information did that feature need to send?"

8.2 popularity-contest

Another package worth knowing about is popularity-contest, commonly called popcon.

This one is different from Ubuntu Insights.

popularity-contest is a Debian project that collects package-usage statistics. Its current documentation says that the package sends a weekly report containing the list of installed packages and the access times of relevant files. The collected results are then anonymized by the Debian server before the published survey is generated.

This is genuinely usage reporting, so privacy-conscious users may reasonably want to know whether it is installed.

But it is important not to describe this as part of Ubuntu's normal system-information telemetry.

In Ubuntu, popularity-contest is packaged separately in the universe repository. It is not the same software as Ubuntu Report or Ubuntu Insights.

So this statement would be too broad:

"Ubuntu sends package-usage telemetry by default."

A more accurate statement is:

"An Ubuntu system can run separate reporting software such as popularity-contest if that package is installed and configured."

You can check whether it is installed with:

dpkg -l popularity-contest

or:

apt policy popularity-contest

If the package is not installed, it is not generating popularity-contest reports.

8.3 What About Similar Packages?

There is no single list of "Ubuntu telemetry packages" that covers every Ubuntu installation.

Ubuntu is a Linux distribution built from software from many projects. Your system can contain packages that communicate with remote services for very different reasons.

For example:

• a package manager downloads package metadata
• a Snap client checks for application updates
• a firmware tool contacts a firmware service
• a time-synchronization service contacts time servers
• a browser communicates with websites
• a crash-reporting component may submit diagnostic information
• a usage-reporting package may submit statistics

It is also worth knowing that GNOME itself has a telemetry system, separate from anything Canonical operates.

gnome-info-collect was released by GNOME developers in 2022 to collect anonymous information about how the desktop is used.

It shows the collected data to the user before transmission, asks for confirmation, and only sends after approval.

The information includes the operating system, hardware vendor, whether Flatpak and Flathub are enabled, installed applications, whether file sharing, remote desktop, or remote login are active, the number of user accounts, the default browser, and enabled extensions.

GNOME states that no locale information or other sensitive data is transmitted.

This system is opt-in and is not enabled by default. Because Ubuntu uses GNOME as its desktop environment, the tooling exists on Ubuntu systems even though it is not part of Canonical's telemetry.

A connection related to GNOME telemetry is not the same as a connection related to Ubuntu Insights. They are separate systems with separate consent controls and separate purposes.

If you have never run gnome-info-collect, it is not generating reports. The tool does not install itself, and it does not run automatically.

One related detail: the GNOME Shell extension update checker contacts a GNOME server on every boot to check for extension updates. This is a functional update check, not telemetry, but it is an example of a non-Canonical connection that can appear in network monitoring even when Ubuntu telemetry is fully disabled.

None of these activities should be placed in the same category. The fact that a package can make a network connection does not make it telemetry.

8.4 Features, Metadata, and Telemetry Are Not the Same Thing

A useful way to think about Ubuntu's network activity is to divide it into three broad categories.

Functional network traffic

The system communicates with a service because a feature needs it to work.

Examples include:

• downloading software updates
• refreshing Snaps
• searching for Snaps
• performing a web search
• synchronizing time
• downloading firmware

Functional metadata

A service may need information about the computer, software, or request in order to provide that function.

Examples can include:

• Ubuntu release
• CPU architecture
• application version
• device or session identifiers
• repository or Store information

Such information can be sent as part of providing a service without making the connection Ubuntu's system telemetry.

Telemetry or usage reporting

The software intentionally reports information about the computer, software, or usage for purposes such as measurement, diagnostics, analytics, or product improvement.

Ubuntu Insights belongs in this category.

popularity-contest is also a reporting system, but it is a separate project with a different purpose and data set.

8.5 Why the Distinction Matters

Suppose you install Ubuntu, turn off system-information reporting, and then monitor its network activity.

You may still see connections.

That does not mean the telemetry setting failed.

You might instead be seeing:

• an APT update check
• a Snap refresh
• a Snap Store request
• a search-provider request
• a crash-reporting component
• an optional Canonical service
• a firmware update
• time synchronization
• another installed application

This is why the claim "Ubuntu contacted a server, so Ubuntu telemetry must be enabled" is not a reliable conclusion.

The same principle works in reverse. Not seeing a connection during a short monitoring session does not prove that a service never communicates. Some services run periodically, only when triggered, or only when a particular feature is used.

8.6 How to Interpret Network Monitoring Results

When you investigate Ubuntu's traffic, ask these questions:

1. Which process made the connection?
2. Which server or domain did it contact?
3. When did the connection happen?
4. What was happening on the computer at that moment?
5. What data was actually transmitted?
6. Is the connection part of a feature you enabled or used?
7. Is there a privacy or configuration setting that controls it?

For example, seeing snapd contact the Snap Store tells you something very different from seeing Ubuntu Insights upload a system-information report.

Likewise, seeing a browser make a connection after you initiate a web search from GNOME Shell is not evidence that Ubuntu is silently collecting system telemetry.

8.7 The Bigger Picture

Ubuntu privacy is therefore not a simple question of "online" versus "offline."

A normal Ubuntu installation can communicate with many different services while performing completely legitimate tasks.

The useful question is:

What component made the connection, why did it make it, and what information did it send?

That distinction will become especially important in the next section.

Instead of relying on assumptions, we can actually watch Ubuntu's network activity and identify which processes are communicating, where they connect, and when those connections occur.

That gives us a much more reliable way to test Ubuntu's privacy behavior.

9. How to Check Ubuntu's Network Activity Yourself

If you want to know what Ubuntu is actually communicating with, you do not have to rely entirely on privacy claims or forum discussions.

You can observe the network activity yourself.

Linux provides several tools for this, ranging from simple command-line utilities to full packet-analysis applications.

The important thing is to understand what each tool can actually tell you and what it cannot.

9.1 Start With ss

ss displays information about network sockets and their current state. It can show TCP and UDP connections, listening sockets, addresses, ports, and associated processes where available.

For example:

ss -tupn

This asks ss to show:

• TCP sockets
• UDP sockets
• process information where available
• numeric addresses and ports

You can also look specifically for established TCP connections:

ss -tpn state established

This is useful when you want a quick snapshot of what is connected right now.

You might see a process such as snapd, a browser, or another system service connected to a remote address.

But there is an important limitation: ss shows sockets, not the contents of the communication.

It also gives you a snapshot. A service that connects for only a few seconds may no longer be visible when you run the command.

9.2 Use lsof to Identify the Process

lsof means list open files. On Linux, network sockets can appear as open files, allowing lsof to show which processes have network connections.

A useful command is:

sudo lsof -i -n -P

The options mean:

• -i - show network-related files
• -n - do not resolve IP addresses into hostnames
• -P - show numeric port numbers

The output can include:

• process name
• process ID
• user
• protocol
• local address and port
• remote address and port

Sample Output:

COMMAND    PID            USER FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd-r  665 systemd-resolve 16u  IPv4   6591      0t0  UDP 127.0.0.53:53 
systemd-r  665 systemd-resolve 17u  IPv4   6592      0t0  TCP 127.0.0.53:53 (LISTEN)
systemd-r  665 systemd-resolve 18u  IPv4   6593      0t0  UDP 127.0.0.54:53 
systemd-r  665 systemd-resolve 19u  IPv4   6594      0t0  TCP 127.0.0.54:53 (LISTEN)
avahi-dae 1134           avahi 12u  IPv4  15265      0t0  UDP *:5353 
avahi-dae 1134           avahi 13u  IPv6  15266      0t0  UDP *:5353 
chronyd   1449         _chrony  4u  IPv4  15312      0t0  UDP 127.0.0.1:323 
chronyd   1449         _chrony  5u  IPv6  15313      0t0  UDP [::1]:323 
cupsd     1594            root  6u  IPv6  16665      0t0  TCP [::1]:631 (LISTEN)
cupsd     1594            root  7u  IPv4  16666      0t0  TCP 127.0.0.1:631 (LISTEN)
python3   3889       ostechnix  8u  IPv4  27117      0t0  UDP 239.255.255.250:3702 
python3   3889       ostechnix  9u  IPv4  27118      0t0  UDP *:51413 
python3   3889       ostechnix 10u  IPv4  27119      0t0  UDP 192.168.1.26:3702 
python3   3889       ostechnix 11u  IPv6  27212      0t0  UDP [ff02::c]:3702 
python3   3889       ostechnix 12u  IPv6  27213      0t0  UDP *:57004 
python3   3889       ostechnix 13u  IPv6  27214      0t0  UDP [fe80::be24:11ff:fe64:429d]:3702 

You can then filter for a particular process:

sudo lsof -i -n -P | grep snapd

This can help answer one of the most useful questions in a privacy investigation:

"Which program is actually making this connection?"

Depending on permissions and how the system is configured, information about processes owned by other users may require elevated privileges.

9.3 Capture Traffic With tcpdump

If ss and lsof tell you which processes have network sockets, tcpdump lets you capture the packets travelling across a network interface.

For example:

sudo tcpdump -i any

You can save a capture for later analysis:

sudo tcpdump -i any -w ubuntu-network.pcap

tcpdump supports capture filters, so you can narrow the traffic you are interested in.

For example, DNS traffic:

sudo tcpdump -i any port 53

Or HTTPS traffic:

sudo tcpdump -i any port 443

Be careful with broad captures. They can produce large amounts of data quickly.

There is also an important limitation: tcpdump captures packets; it does not inherently identify the user-space process responsible for every packet.

That is why it works particularly well alongside ss, lsof, or an application-aware firewall such as OpenSnitch or LittleSnitch.

9.4 Analyze Packets With Wireshark

If you prefer a graphical interface, Wireshark is a powerful option.

Wireshark can capture traffic from a network interface or open previously captured packet files. It allows you to inspect individual packets, protocols, connection flows, and packet fields.

A controlled investigation might look like this:

1. Start a capture.
2. Perform one specific action on Ubuntu.
3. Stop the capture.
4. Examine the connections created by that action.
5. Inspect DNS requests, destination addresses, protocols, and packet contents where available.

This is much easier to interpret than leaving Wireshark running for an hour and trying to understand thousands of unrelated packets.

For example, you could:

1. disable Ubuntu system-information sharing;
2. start a Wireshark capture;
3. leave the computer idle for a defined period;
4. trigger one specific feature;
5. stop the capture;
6. compare the traffic before and after the action.

This can help establish whether a particular action caused a particular connection.

9.5 OpenSnitch: See Connections by Application

If you want to find "which application is trying to connect to the internet?", you can use OpenSnitch.

OpenSnitch is an interactive application firewall for GNU/Linux. It monitors outbound connections and provides information about the processes making them. It can also prompt you to allow or deny connections and create rules for future connections.

This gives you a different perspective from Wireshark.

Instead of starting with:

"Which packets are leaving my computer?"

you can start with:

"Which application is trying to communicate?"

For example, you might see a connection associated with:

snapd

or:

some-application

You can then investigate the destination and determine why that application is expected to communicate.

OpenSnitch can also create persistent rules. Its documentation recommends observing normal traffic before creating restrictive rules based on what you have identified.

Please Do not blindly block everything.

Some Linux processes make network connections that are necessary for normal operation, including DNS resolution, time synchronization, and other system functions. Blocking them can cause apparently unrelated features to stop working.

9.6 Which Tool Should You Use?

Each tool answers a slightly different question.

You do not need all five.

For most users, a sensible progression is:

ss → lsof → Wireshark/tcpdump → OpenSnitch

Start with the simplest tool that can answer your question.

If you only want to know whether anything is connected right now, start with ss. If you want to identify the process, use lsof. Suppose if you need to examine the actual network exchange, capture packets. And, if you want application-level visibility and the ability to control outbound connections, consider using OpenSnitch.

9.7 A Controlled Ubuntu Privacy Test

Suppose you want to know whether a particular Ubuntu service communicates with the internet after you disable system-information reporting.

Do not start by assuming what the answer will be.

Instead, run a controlled experiment.

Step 1: Record the configuration

Write down the relevant privacy settings and the Ubuntu version you are testing.

Step 2: Start monitoring

Use ss, lsof, Wireshark, tcpdump, or OpenSnitch depending on the question you are trying to answer.

Step 3: Observe an idle system

Leave the computer alone for a defined period.

This establishes what background activity occurs without deliberately triggering a feature.

Step 4: Perform one action

Trigger only one thing.

For example:

• open the Snap Store
• search for a Snap
• check for software updates
• launch a particular application
• use the GNOME web-search feature

Step 5: Record the result

Note:

• process
• destination
• time
• protocol
• whether the connection was expected

Step 6: Repeat the test

One connection is not always enough evidence.

Repeat the same action and see whether the same behaviour occurs.

Step 7: Compare the observation with documentation

This is one of the most important steps.

If Ubuntu's documentation or the relevant project's source code describes a connection for a particular purpose, and your observation matches that behaviour, you have much stronger evidence than simply seeing a Canonical-owned address.

9.8 What These Tools Can Show You

Used appropriately, these tools can provide strong evidence that:

• a process opened a network connection
• a connection was made to a particular address
• a connection happened at a particular time
• a particular protocol or port was used
• packets were transmitted
• some unencrypted information was present
• a particular process was associated with a socket, when the tool provides that information

9.9 What They Cannot Prove by Themselves

Network-monitoring tools generally cannot prove:

• the exact purpose of a connection merely from its destination
• the complete contents of encrypted traffic
• that every connection to a Canonical service is telemetry
• that a connection contains no telemetry simply because its payload is encrypted
• that a service will never communicate later because nothing happened during a short test
• what a remote server does with information after receiving it

This is why network monitoring should be combined with documentation and, where available, source-code inspection.

For example:

snapd → Canonical server

does not automatically mean:

snapd → Canonical telemetry server

The connection could be related to searching, downloading, refreshing, authentication, or another Snap Store operation.

Likewise:

browser → web server

does not tell you whether the connection came from Ubuntu itself, a website you opened, a browser extension, or a search feature.

You need to identify the process, understand what triggered the connection, and examine the available evidence.

9.10 The Key Lesson

The goal of network monitoring is not to find a scary-looking IP address.

The goal is to build a chain of evidence:

Which process → contacted which destination → at what time → after which action → using which protocol → sending what information, if observable?

That is a much more reliable way to investigate Ubuntu privacy than simply counting network connections.

10. A Real Ubuntu Privacy Test

So far, we have looked at what Ubuntu and Canonical say their services do. Now we can test the system ourselves.

The goal is not to prove that Ubuntu is “spying” or that it sends nothing. The goal is much simpler:

Can we observe a difference between system-information reporting being enabled and disabled, while separating that traffic from normal Ubuntu network activity?

10.1 Test on a Clean Ubuntu Installation

For the most reliable results, use a fresh Ubuntu installation or a virtual machine.

Record the exact Ubuntu version first:

cat /etc/os-release

This matters because Ubuntu 24.04 and Ubuntu 26.04 use different system-information reporting mechanisms.

• Ubuntu 24.04: primarily uses Ubuntu Report.
• Ubuntu 26.04: uses Ubuntu Insights, which replaced Ubuntu Report for the main system-information reporting flow and is opt-in.

Also record whether Snap, Ubuntu Pro, Livepatch, or other optional services are enabled. Otherwise, their network activity can make the results harder to interpret.

Step 1: See What Ubuntu Plans to Report

On Ubuntu 24.04, Ubuntu Report provides a command that displays the report without sending it:

ubuntu-report show

As stated already, this command collects and displays the metrics without sending them. The report can contain hardware, software, installation, partition, and desktop-session information.

On Ubuntu 26.04, Ubuntu Insights provides report-preview functionality, and the graphical controls are available under Settings → Privacy & Security → Telemetry.

The current Insights project is specifically designed to show users what is being sent and let them control consent.

This is an important first check because you can inspect the intended contents before looking at network traffic.

Step 2: Check the Consent Setting

For Ubuntu 26.04, make sure you know whether Ubuntu Insights consent is enabled or disabled.

The 26.04 documentation describes Insights collection as opt-in, and previous consent given to Ubuntu Report is not automatically carried over to Insights.

For Ubuntu 24.04, check the Ubuntu Report setting separately. Do not assume that a 26.04 Insights setting applies to the older Ubuntu Report mechanism.

Step 3: Start Monitoring Network Connections

Now start a network monitor before performing the action you want to test.

For a simple view of active sockets:

sudo ss -tupn

You can also monitor established connections:

sudo ss -tpn state established

For packet-level observation, you can use:

sudo tcpdump -i any

Or save a capture for later inspection:

sudo tcpdump -i any -w ubuntu-privacy-test.pcap

For a graphical investigation, Wireshark can open the capture and show packets, protocols, destinations, timing, and conversations.

Step 4: Keep the Test Controlled

Do not open a browser, install software, refresh Snap packages, run updates, and change privacy settings at the same time.

Instead:

1. Start the network monitor.
2. Let the machine sit idle for a defined period.
3. Record the connections you see.
4. Perform one specific action.
5. Record any new connections.
6. Stop the capture.
7. Repeat the same test with the relevant reporting setting changed.

For example, you could compare:

The purpose is to isolate variables.

Step 5: Test the Reporting Mechanism, Not Just the Network

A connection to a Canonical server is not enough to establish that telemetry was sent.

Instead, look for a chain of evidence:

process → destination → time → action → protocol → data

For example, if a reporting process makes a connection immediately after a reporting action, that is much stronger evidence than simply seeing a Canonical IP address in a packet capture.

On Ubuntu 24.04, the Ubuntu Report source documents both the report contents and the separate opt-out reporting mode.

On Ubuntu 26.04, the Ubuntu Insights project likewise documents an explicit opt-out state and provides report-preview and consent controls.

Step 6: Compare the Results

The most useful result is not:

“Ubuntu connected to Canonical.”

You already know that several Ubuntu components can legitimately do this.

The useful result is something like:

“With system-information reporting enabled, the reporting component produced a system-information report and attempted its reporting workflow. With that consent disabled, the system-information report was not sent.”

That conclusion is consistent with Canonical's current system-information notice, which states that if a user chooses not to share the covered system information, Canonical will not receive that system information.

At the same time, you may still observe connections caused by Snap, APT, crash reporting, MOTD news, time synchronization, browsers, or other software.

That does not contradict the telemetry setting.

10.2 What the Test Can Prove

A carefully controlled test can show:

• which processes create network connections;
• which destinations they contact;
• when those connections occur;
• whether a connection appears after a particular action;
• whether changing a privacy setting changes the observed behaviour;
• what information a reporting component says it intends to send.

10.3 What the Test Cannot Prove by Itself

A packet capture cannot necessarily reveal the contents of encrypted traffic.

It also cannot prove, by itself, that:

• every Canonical connection is telemetry;
• a connection contains no telemetry simply because its payload is encrypted;
• an IP address belongs exclusively to one Canonical service;
• no future connection will occur;
• a remote server does nothing with information after receiving it.

CDNs, shared infrastructure, changing IP addresses, DNS, proxies, and other services can also make network attribution more complicated.

This is why documentation, source code, local configuration, process information, and network observations should be considered together.

10.4 The Most Important Result

The privacy test should lead to a more precise conclusion:

Disabling Ubuntu's system-information reporting changes that reporting behaviour, but it does not turn Ubuntu into an offline operating system.

Ubuntu can still communicate with online services for updates, Snap, crash reporting, optional Canonical services, and other functions.

That is not a failure of the privacy setting. It is simply the difference between telemetry and ordinary network functionality.

The next step is to put these findings together into a practical privacy-hardening setup: what you can safely disable, what you should leave enabled, and which changes provide the most privacy benefit without weakening Ubuntu's security.

11. How to Harden Ubuntu for Better Privacy

You do not need to turn Ubuntu into a heavily modified system to improve its privacy.

For most users, good privacy hardening is about data minimisation: disable reporting you do not want, review services and application permissions, and keep the system secure.

A practical approach is:

• Turn off Ubuntu system-information reporting if you do not want to share it.
• Keep crash reporting under your control.
• Keep Snap if you use it; remove it only if you deliberately want a Snap-free system.
• Disable optional Canonical services you do not need.
• Review search providers and application permissions.
• Monitor network activity when you want deeper visibility.

The goal is not to make Ubuntu completely silent. It is to make its network activity and data sharing more deliberate and easier to control.

11.1 Turn Off System-Information Reporting

On Ubuntu 26.04, Ubuntu Insights is opt-in. Its consent controls and report preview are available in Settings → Privacy & Security → Telemetry. Ubuntu says Insights is designed to give users control over the non-personally identifying system metrics they choose to share with Canonical.

If you do not want to share these system metrics, leave Insights disabled.

Ubuntu 24.04 uses the older Ubuntu Report mechanism, so instructions written specifically for Ubuntu 26.04 should not automatically be applied to 24.04.

This is one of the clearest privacy controls because it directly affects Ubuntu's system-information reporting.

11.2 Keep Crash Reporting Under Your Control

Crash reporting is separate from Ubuntu Insights.

The automatic crash-interception component of Apport is disabled by default in Ubuntu stable releases.

On Ubuntu Desktop, error-reporting behaviour can be managed from Settings. In Ubuntu 26.04, the former Diagnostics panel has been replaced by the Telemetry panel. The available choices include manual reporting, automatic reporting, and disabling error reporting.

Error Reporting in Ubuntu Settings Panel.png

For most privacy-conscious users, Manual is a reasonable middle ground. Ubuntu can ask before submitting an error report instead of automatically sending it.

There is a good reason to review this setting. Apport can collect crash information such as core dumps, stack traces, and log files, which may contain sensitive information.

You do not necessarily need to disable crash reporting completely. If you are comfortable reviewing reports before submission, manual reporting gives you more control while still allowing you to help diagnose problems.

11.3 Do Not Remove Snap Just Because It Uses the Network

Snap is not simply a telemetry component. It is Ubuntu's application packaging and update system.

If you use Snap applications and are comfortable with the Snap Store and its update model, there is no need to remove Snap merely for privacy reasons.

If you prefer traditional Debian packages or another software-management approach, however, you can choose not to use Snap.

You should keep this in mind: Removing Snap reduces Snap-related network activity, but it does not disable Ubuntu telemetry or make Ubuntu private by itself.

If you decide to remove Snap, check which installed applications depend on it first. Removing snapd can affect applications that were installed as snaps.

• How To Completely Remove Snap from Ubuntu

11.4 Disable Optional Canonical Services You Do Not Need

Some Canonical services are optional.

Ubuntu Pro, for example, provides additional services such as Expanded Security Maintenance and Livepatch.

The following data are collected from active Ubuntu Pro machines:

• Distribution and release codename
• Kernel version
• Machine architecture
• CPU family, model, and model name
• Whether the machine is a desktop
• Virtualization type
• Services enabled
• When the machine was attached
• Version of ubuntu-pro-client

This collection only applies to machines that are actually attached to a Pro subscription. Canonical states this data is collected to ensure machines attached to a Pro contract are compliant with the terms of that contract.

If you have attached the machine to Ubuntu Pro, review which services are actually enabled.

You can check their status with:

pro status

If your system is attached to Ubuntu Pro, you will see this output:

ostechnix@ubuntu2604desktop:~$ pro status
SERVICE          AVAILABLE  DESCRIPTION
anbox-cloud      yes        Scalable Android in the cloud
esm-apps         yes        Expanded Security Maintenance for Applications
esm-infra        yes        Expanded Security Maintenance for Infrastructure
landscape        yes        Management and administration tool for Ubuntu
livepatch        yes        Canonical Livepatch service

For a list of all Ubuntu Pro services, run 'pro status --all'

This machine is not attached to an Ubuntu Pro subscription.
See https://ubuntu.com/pro

Note: The ubuntu-advantage-tools package, which provides the pro command, is installed by default on all Ubuntu systems, whether or not the machine is ever attached to an Ubuntu Pro subscription. This means the client is present even on systems that have never enrolled in Pro.

If your machine is already attached to Ubuntu Pro and you do not need a particular Pro service, it can be disabled with:

sudo pro disable <service-name>

If you no longer want the machine attached to the Pro subscription, pro detach disables the Pro services and removes the subscription stored on the machine. These commands do not automatically uninstall packages that a service previously installed.

When Pro services like ESM are enabled, downloading packages from them also sends the Ubuntu codename, package name, package version, and package architecture to esm.ubuntu.com. Because the request is authenticated with a token tied to the Pro subscription, this data is inherently tied to that subscription.

The principle is simple: do not keep optional services enabled if you do not use them.

This does not mean that Pro or Livepatch is inherently bad for privacy. They provide useful security and maintenance features. They simply create additional service-specific communication that you may not need.

11.5 Review Search Providers in Ubuntu 26.04

Ubuntu 26.04 adds GNOME Shell search providers for Snap applications and web search.

The Snap provider can find available Snap applications from the desktop's global search.

The web-search provider lets you initiate a web search from GNOME Shell using your default browser.

These providers can be disabled from the Search section of Settings panel.

If you do not use these features, disabling them is a simple way to reduce unnecessary online functionality.

This is not the same as disabling telemetry. These are feature-specific search functions.

11.6 Review Snap Application Permissions

If you use Snap applications, privacy is not only about snapd and the Snap Store.

The application itself may have access to files, hardware, or other system resources through Snap interfaces.

Strictly confined snaps use security mechanisms including AppArmor, seccomp, device controls, namespaces, and traditional file permissions. Additional access is managed through interfaces.

Ubuntu 26.04 also improves integration with XDG Desktop Portals. Portal permissions for Snap applications can be controlled from GNOME Settings, including access involving resources such as files, cameras, notifications, and USB devices.

For a closer look at a particular Snap, useful commands include:

snap info --verbose <snap-name>

and:

snap connections <snap-name>

Pay particular attention to sensitive permissions such as personal files, cameras, microphones, removable storage, and other hardware.

This can provide a more meaningful privacy improvement than simply removing Snap itself.

11.7 Keep Security Updates Enabled

This is where privacy hardening should stop.

Do not disable security updates simply because they create network traffic.

Ubuntu needs to communicate with software repositories to obtain security fixes. That is functional update traffic, not system-information telemetry.

An unpatched vulnerability can expose your files, accounts, browser data, and other information to an attacker. That can be a much greater privacy risk than normal update traffic.

So keep Ubuntu's security-update mechanism enabled unless you have a specific administrative reason to manage updates manually.

A more private system is not automatically a safer system.

The goal is to improve both.

11.8 Monitor Connections If You Want More Visibility

If you want to go beyond Ubuntu's privacy settings, monitor the system rather than blindly blocking connections.

Useful tools include:

sudo ss -tupn

sudo lsof -i -n -P

and, for packet capture:

sudo tcpdump -i any -w ubuntu-network.pcap

Wireshark can provide detailed packet analysis, while OpenSnitch can provide application-level visibility and outbound connection control.

The important rule is: Investigate before blocking.

A connection from snapd, APT, a browser, DNS, time synchronisation, or another system component may have a legitimate purpose. Blocking it without understanding the dependency can break updates or other system functions.

11.9 A Practical Ubuntu Privacy Baseline

For most privacy-conscious Ubuntu users, this is a sensible starting point:

11.10 Privacy Without Breaking Ubuntu

Privacy hardening is not about making Ubuntu completely silent.

It is about reducing unnecessary data collection and unnecessary services while keeping the system secure and functional.

You do not need to disable every network connection. You need to understand which component is communicating, why it is communicating, what information it needs, and whether you actually need that feature.

That is a much more useful privacy strategy than simply blocking every connection to a Canonical-owned server.

In the next section, we will discuss which Ubuntu components you should never disable just for privacy.

12. What You Should NOT Disable When Hardening Ubuntu

Privacy hardening has a limit.

Some Ubuntu components communicate with the internet because they perform essential maintenance and security functions. Disabling them may reduce network activity, but it can also leave the system exposed to known vulnerabilities.

The most important rule is simple:

Do not disable security infrastructure just to make Ubuntu quieter.

12.1 APT

APT is Ubuntu's default package-management system. It retrieves package metadata and downloads software from the repositories configured on your system. Those repositories can include official Ubuntu sources, mirrors, PPAs, and other third-party repositories.

APT traffic is not the same thing as Ubuntu telemetry.

When APT checks for updates, network communication is necessary to determine which packages are available and download them. That is functional package-management traffic.

So disabling APT simply to reduce Ubuntu-related network activity is not a sensible privacy improvement.

12.2 Security Repositories

Ubuntu's package archive separates software into different pockets. The security pocket contains security-related updates, while the updates pocket contains non-security updates. Ubuntu's current documentation recommends keeping the security pocket enabled.

Do not remove the official security sources because they communicate with Ubuntu infrastructure or mirrors.

If you want to reduce unnecessary software-source activity, review third-party repositories that you no longer need instead.

An old PPA or unfamiliar repository can introduce security and maintenance risks. Removing an unnecessary third-party source is a much better approach than disabling Ubuntu's security repositories.

12.3 Security Updates

Security updates should remain enabled.

Ubuntu's current security documentation says unattended-upgrades is included by default on Ubuntu Desktop and Server and automatically applies security updates. The current default policy installs security updates after a delay of about 24 hours, while normal updates are delayed for about 7 days.

Ubuntu continues to publish security fixes for supported releases. For example, current Ubuntu Security Notices include fixes for Ubuntu 26.04 LTS for vulnerabilities in packages such as curl, Vim, and ImageMagick.

This matters for privacy as well as security.

An unpatched vulnerability can allow an attacker to access files, credentials, browser data, or other information on your computer. That can create a far greater privacy risk than the normal network communication required to download a security patch.

In other words: Reducing update traffic is not worth increasing your exposure to known vulnerabilities.

12.4 unattended-upgrades

Ubuntu uses unattended-upgrades to install security updates automatically.

As I explained in Section 5.1, it is installed by default, automatic security updates are enabled by default, and it normally runs once per day. It performs the equivalent of refreshing package lists and then applying the upgrades allowed by its configuration.

Its main configuration files include:

/etc/apt/apt.conf.d/20auto-upgrades
/etc/apt/apt.conf.d/50unattended-upgrades

The exact policy can be configured. For example, the default configuration allows security updates and can include Ubuntu Pro's ESM security repositories when Pro is enabled. It does not automatically apply updates from arbitrary third-party repositories simply because those repositories have been added to APT.

For a normal desktop, there is little reason to disable unattended-upgrades purely for privacy.

There are legitimate exceptions. A specialised system might need tightly controlled maintenance windows, or a particular package might require manual intervention. In those cases, Ubuntu recommends considering more targeted configuration, such as postponing or blocking a specific package, rather than disabling the entire automatic-update mechanism.

12.5 Balancing Security and Efficiency

If you want to minimise unnecessary package-management activity without sacrificing security:

• Keep the official Ubuntu security sources enabled.
• Keep security updates enabled.
• Keep unattended-upgrades enabled on normal systems.
• Review and remove third-party repositories you no longer need.
• Avoid adding unnecessary PPAs.
• If you need tighter control over when updates are installed, configure a deliberate maintenance policy rather than disabling security updates completely.
• Use network-monitoring tools if you want to understand where APT is connecting.

This gives you a better balance between privacy, security, and system reliability.

12.6 Sensible Hardening

Do not confuse "communicates over the internet" with "privacy-invasive."

APT needs network access to maintain your software. Security repositories need to remain available so vulnerabilities can be fixed. unattended-upgrades exists to automate that protection. These functions are fundamentally different from Ubuntu's optional system-information reporting.

So the goal is not to make Ubuntu generate zero network traffic. The goal is to disable unnecessary data collection without disabling the mechanisms that keep the operating system secure.

That is the line between sensible privacy hardening and counterproductive privacy hardening.

13. Frequently Asked Questions (FAQ)

14. Final Verdict

Ubuntu does collect some system information through its telemetry and reporting mechanisms, but not every connection Ubuntu makes to Canonical is telemetry. APT, Snap, crash reporting, Ubuntu Pro, Livepatch, firmware updates, and other services have their own purposes and communication patterns.

Disabling system-information reporting therefore reduces one category of data collection, but it does not make Ubuntu completely network-silent or completely private.

Likewise, a connection to a Canonical-owned address is not, by itself, evidence of telemetry. Understanding what a connection represents requires looking at the process responsible, the destination, the timing, and the purpose of the connection.

The final conclusion is simple: Ubuntu's communication mechanisms should be evaluated separately rather than treated as one form of telemetry.

Whether Ubuntu's defaults are acceptable depends on your privacy requirements and threat model. Users who want to minimize optional reporting have configuration options, while those seeking stronger isolation or minimal third-party communication may need additional measures or different software.

Telemetry is telemetry. Updates are updates. Snap traffic is Snap traffic. A network connection to Canonical is not automatically telemetry.