First Published: June 9, 2025
At its core, security is about keeping unwanted things out of your system, the same way you lock your doors to prevent strangers from walking into your house. Without security, anyone could tamper with or damage your data.
Privacy, on the other hand, is about making sure no one is quietly watching you through the window or listening at the door. You might not notice it, but the mere fact that an unknown party can observe your actions is a violation.
In reality, security and privacy go hand in hand: if someone can watch you, they may soon find ways to control or harm you. Yet this connection is frequently ignored. Many people trust their operating systems blindly, simply because they have not seen anything go wrong.
This false sense of safety leads to complacency. Until something happens, a breach, stolen data, or invasive surveillance, and suddenly security and privacy become urgent concerns. That's when people start searching for antivirus tools or privacy services, often after the damage is already done.
But it shouldn't be reactive. The best time to consider privacy and security is before the problem arises, by understanding what your OS does, what it collects, and what it protects you from (or fails to).
These principles are innate to Islam:
Allah says:
يَاأَيُّهَا الَّذِينَ آمَنُوا لَا تَدْخُلُوا بُيُوتًا غَيْرَ بُيُوتِكُمْ حَتَّى تَسْتَأْنِسُوا وَتُسَلِّمُوا عَلَى أَهْلِهَا ذَلِكُمْ خَيْرٌ لَكُمْ لَعَلَّكُمْ تَذَكَّرُونَ
"O you who have believed, do not enter houses other than your own houses until you ascertain welcome and greet their inhabitants. That is best for you; perhaps you will be reminded." (An-Noor 24:27)
Shaykh 'Abdurrahman ibn as-Sa`di (may Allah have mercy on him) explained:
Here Allah instructs His believing slaves not to enter houses other than their own without asking permission, because that leads to a number of bad consequences, including that to which the Messenger (peace and blessings of Allah be upon him) referred when he said: "Asking permission has only been prescribed so that one will not see that which is not appropriate for him to see." Because not following this ruling properly may lead to one's gaze falling upon private things inside other people's houses. A person’s house, by covering what is private inside its walls, is like a garment that covers what is private of his body.
Entering other people's houses without permission may create suspicion about the one who enters them, and he may be accused of evil deeds such as stealing and so on, because entering houses surreptitiously is suggestive of evil intent. Allah forbids the believers to enter houses other than their own until they seek permission; the word used in the original Arabic suggests that seeking permission creates a sense of assurance, whereas entering without permission may cause alarm.
"and greet their inhabitants" – the manner in which this is to be done is mentioned in the Hadith: "As-salaamu 'alaykum (peace be upon you); may I come in?"
"That" namely seeking permission to enter "is best for you; perhaps you will be reminded", because it will serve many interests, and because it is part of the noble characteristics that are required of the Muslim. If he is given permission, then he may enter.
(Tafseer as-Sa'di, 565)
Narrated by Muslim (2158), from Abu Hurayrah, from the Prophet (peace and blessings of Allah be upon him), who said: "Whoever looks into the house of a people without their permission, it is permissible for them to put out his eye."
Imam an-Nawawi (may Allah have mercy on him) explained:
His (peace and blessings of Allah be upon him) saying: "Whoever looks into the house of a people without their permission, it is permissible for them to put out his eye," the scholars have said this applies in the case where someone looks into a man's house and he (the owner) strikes him with a small stone and thereby puts out his eye. Is it permissible to strike him before warning him? There are two views among our scholars. The more correct view is that it is permissible, according to the apparent meaning of this hadith. And Allah knows best.
It is also narrated in as-Saheehayn from Abu Hurayrah that the Prophet (peace and blessings of Allah be upon him) said: "Beware of suspicion, for suspicion is the falsest of speech. Do not eavesdrop; do not spy on one another; do not envy one another; do not forsake one another; do not hate one another. Be, O slaves of Allah, brothers." Al-Bukhaari (5144); Muslim (2563).
Imam an-Nawawi (may Allah have mercy on him) explained:
Some of the scholars said that tahassus ['eavesdropping'] means listening to other people's conversations, and tajassus ['spying'] means seeking out their faults. Or it was suggested that tajassus means looking for secrets. The word is mostly used in the sense of evil. The jaasoos (spy) is the one who seeks out secrets for evil purposes and the naamoos is the one who seeks out secrets for good purposes. And it was said that tajassus means looking for information for someone else, and tahassus means looking for information for oneself. This was the view of Tha'lab. And it was said that they mean one and the same, which is seeking out information about people's circumstances.
This alone should dismantle the common "nothing to hide" argument. Such reasoning ignores the very principles that Islam upholds regarding personal privacy, dignity, and the right to be free from intrusion, whether in one's home or in one's private affairs.
All of this should complement the PDF below, as well as the follow-up points related to security and privacy discussed in this article.
Before or after you read the PDF, it is important to recognize that in discussions on security and privacy, threat modeling is a key concept. Threat modeling is the process of identifying what you are trying to protect, who you are trying to protect it from, and what capabilities those adversaries might have. In other words, it helps you define your own risk profile. Not everyone faces the same level of threat, a casual home user, a journalist, a political dissident, and a system administrator all require different approaches to security and privacy.
Threat modeling generally involves considering several levels of threat, such as:
Understanding your personal or organizational threat model is crucial because it informs which tools, operating systems, and practices are appropriate. Unfortunately, many discussions, including some promoted by Privacy Guides, present solutions in a one-size-fits-all manner without clearly situating them within specific threat models. This can lead users to either overestimate their needs and adopt unnecessarily complex setups, or worse, underestimate their risks and rely on incomplete protections.
Keeping this in mind while reading both this article and the linked PDF will help you better evaluate which strategies serve your privacy and security goals, rather than simply following generic recommendations.
It is also important to remember that this article is written from a FOSS-first perspective, with both security and privacy in mind. By now, it should be clear that relying on proprietary software inherently undermines both. Moving away from proprietary tools does involve certain compromises: it may mean sacrificing some features, convenience, or familiarity. Some proprietary programs still outperform FOSS alternatives in specific areas, but the long-term benefits of embracing FOSS far outweigh these initial compromises.
Using FOSS can save you significant money by avoiding costly licenses and also protects you from the temptation to use cracked software, which is often bundled with malware. From a security standpoint, that is an unacceptable risk. Moving toward FOSS is not just a "philosophical" choice, it is a pragmatic safeguard rooted in minimizing your attack surface and maximizing user control.
This is why I encourage you to evaluate your own threat model. By understanding what you need to protect, and from whom, you can make more informed decisions about which privacy and security tools best suit your particular situation.
In this article, I am advocating, wherever feasible, for a full or near-full adoption of FOSS on personal devices. While this may not be immediately practical for everyone, it is an ideal worth pursuing over time. As you continue to explore, conduct your own research alongside this article, there is no universal formula for privacy; it must be shaped by your needs and circumstances.
Finally, be aware that distro-hopping is a real phenomenon, many users experiment with different Linux distributions as they refine their setup. While I may not recommend Fedora here, you may well find that Fedora, or another GNU/Linux OS, suits your particular use case and threat model. The key is to approach this process with realistic expectations and clear priorities.
Now, there are various privacy guides online that discuss which operating systems are recommended and the reasoning behind those choices. However, there are some peculiar arguments made against certain GNU/Linux distributions, particularly Debian. I believe these arguments are misunderstood or misconstrued, even though some of the reasoning may initially appear valid. Therefore, I would like to dispel these misconceptions:
Simply listing the points above shows how trivial these arguments are, none of them provide a substantial reason to dismiss or not recommend Debian. In fact, even before we examine these points, the very fact that respected projects like Tails, Kali Linux, and Whonix are built on Debian should make it clear just how solid and trusted Debian is as a foundation.
The idea that Debian's frozen release cycle inherently leads to slower security updates mischaracterizes how Debian handles security. Debian takes security very seriously and ensures that all security issues brought to its attention are corrected within a reasonable timeframe. The process is deliberate and well-audited: rather than blindly chasing the latest upstream versions, Debian applies targeted security updates to its stable releases in order to maintain system stability and reliability.
Some critics assume that "newer version" automatically means "more secure," which is an oversimplification. Debian's security team monitors vulnerabilities closely, coordinates with upstream developers and other vendors, and frequently publishes advisories on the same day a vulnerability is made public. In practice, major CVEs are addressed promptly, and Debian’s reproducible builds provide an additional layer of transparency, allowing users to verify that distributed packages match their published source.
Moreover, real-world examples show that simply having the latest version does not guarantee better security. For instance, Fedora, a rolling-ish release praised by some privacy guides, left users exposed to a critical OpenH264 vulnerability for months due to external supply chain delays. (Source) Debian's model of controlled and transparent updates, with security fixes reviewed and applied to stable releases, provides a more dependable approach in such cases.
Debian's conservative release cycle is a strength, not a weakness, it prioritizes security, stability, and transparency over superficial markers like version numbers, offering users a robust and verifiable foundation.
The claim that backporting diverges from upstream intentions misrepresents both the purpose and the process of backporting in Debian. Backporting is not about randomly changing upstream software, it is a controlled process designed to maintain stability while providing critical fixes or newer functionality in a predictable way. In fact, Debian's Backports policy explicitly ensures that packages used in backports come from Debian testing or unstable branches that are intended for the next stable release, meaning they are aligned with upstream development paths, not arbitrary forks.
Furthermore, the notion that backporting somehow distorts the "intentions" of upstream maintainers misunderstands the responsibilities of a distribution like Debian. Upstream developers typically focus on adding new features and moving forward quickly, but distributions like Debian serve users who value stability, security, and compatibility. The Debian Security FAQ clearly explains this: changes are made conservatively, with minimal disruption, because users depend on consistent behavior. Where necessary, upstream maintainers are contacted, and security patches are coordinated. This does not diverge from upstream intentions; it complements them by ensuring that upstream improvements can reach users in a stable, well-tested environment.
In addition, Debian provides the backports suite as an optional mechanism, allowing users who need newer features to selectively enable them without compromising the integrity of their overall system. Users retain control, and this is clearly documented, with warnings about potential risks and best practices for using backports sensibly. This level of transparency and user empowerment is far preferable to forcing everyone onto the latest upstream versions by default, as is the case in many rolling-release models.
Backporting in Debian is a deliberate process designed to balance user needs, system stability, and upstream development. It is not a reckless divergence from upstream intentions, it is a pragmatic and well-documented approach to software maintenance that respects both upstream work and the expectations of Debian's diverse user base. Moreover, running Debian Stable without any backports is perfectly valid and well-supported; Stable itself is designed to provide a secure, consistent, and reliable environment for those who prioritize long-term stability over newer features. The choice to use backports is entirely optional, not a requirement or a sign of deficiency in Debian's standard release model.
The claim that Debian requires manual updates is largely inaccurate. First, Debian provides a built-in mechanism, unattended-upgrades, that allows users to automatically receive security (and other) updates. This is an officially documented and supported method, not an external hack, and can be easily enabled on any Debian system. In fact, Debian’s own security information explicitly recommends it as a way to keep systems current automatically.
In desktop environments like GNOME, Automatic Updates are built-in and enabled by default, providing a user-friendly and automated way to apply updates without manual intervention. This experience is comparable to what is offered by other mainstream operating systems, helping to dispel the notion that Debian users are forced to rely solely on manual package management.
Of course, Debian also respects user choice and system control, which is why automated updates are not forcibly imposed across all configurations. This design respects both casual users who prefer automation and advanced users who want fine-grained control over what gets updated and when. In this way, Debian offers flexibility rather than a limitation, and certainly does not deserve criticism for lacking functionality that it clearly provides and documents.
The claim that Debian lacks automatic firmware updates is outdated and oversimplified. With the release of Debian 12 and the introduction of the non-free-firmware component, Debian now includes comprehensive support for installing and managing firmware through its standard package system. The installer and live images automatically detect and install required firmware during installation. This alone reduces much of the manual burden users may have faced in older releases.
Moreover, Debian supports using fwupd, a widely adopted cross-platform tool for managing UEFI and device firmware updates. This tool integrates with GNOME Software and provides automatic firmware update capabilities comparable to those offered on Fedora or even Windows. It is already used by many hardware vendors who publish updates through the LVFS (Linux Vendor Firmware Service), and Debian users can easily install fwupd and benefit from this ecosystem.
It is also important to note that the availability of automatic firmware updates ultimately depends on the hardware manufacturers themselves. If a device vendor does not publish updates to LVFS, no Linux distribution, whether Debian, Fedora, or otherwise, can offer automated updates for that device. In such cases, manual installation is required regardless of the distribution. This is a limitation of upstream vendor support, not a shortcoming specific to Debian.
Debian now provides robust, flexible, and automated mechanisms for handling firmware updates, fully aligned with modern expectations for system maintenance. The notion that Debian users are left to manage firmware manually is no longer reflective of reality, and where manual steps remain necessary, this is an industry-wide limitation beyond the control of any individual Linux distribution.
Relevant:
Important reminder: Your security and privacy are only as strong as your own actions. As the saying goes, the weakest link is the user. You may have an excellent, secure, and private setup, but a single misconfiguration or careless mistake can compromise everything.
While GNU/Linux offers many advantages for privacy and security, those same advantages come with responsibility. The system will do exactly what you tell it to do. If you install or remove software without understanding the consequences, especially when dependencies are involved, you can inadvertently affect critical functionality or even destabilize your entire system.
Take time to understand the changes you make, and always prioritize caution over convenience when managing a security and privacy-focused setup.
Now, I will only address the major Linux distributions commonly used and promoted. The rest of the anonymity- or security-oriented projects are not the main focus of this discussion. For example, Privacy Guides recommends distributions such as Fedora, openSUSE Tumbleweed, Arch Linux, Fedora Atomic Desktops, and NixOS. While these are all capable and well-respected systems in their own right, they share a common shortcoming in the context of supply chain trust, particularly in Privacy Guides' strong endorsement of Flatpak as a primary application delivery mechanism.
Flatpak is presented as a security enhancement due to its sandboxing capabilities. However, Privacy Guides' recommendations downplay, or outright ignore, the critical supply chain risks that come with Flatpak's current ecosystem. Many Flatpak packages on Flathub are not built entirely from source within a trusted infrastructure, and they frequently rely on upstream binaries that may not be properly vetted. Additionally, security updates for core libraries within Flatpak apps are dependent on upstream developers, not the base distribution's security team, leading to delays and inconsistent patching, as demonstrated by multiple examples.
In contrast, traditional package management through vetted distribution repositories (such as Debian's) benefits from coordinated security oversight and reproducible builds, providing a much stronger guarantee of integrity and timely updates. By heavily promoting Flatpak across rolling release and immutable distributions without properly addressing these tradeoffs, Privacy Guides inadvertently encourages a model where users must place more trust in a fragmented and less accountable supply chain.
Relevant:
Another notable inconsistency lies in the reasoning behind Privacy Guides' preference for distributions like Fedora and Tumbleweed over Debian, supposedly based on security or modernity. Yet even Fedora itself openly acknowledges the leadership role of Debian and the reproducible-builds.org initiative in defining and advancing the concept of reproducible builds, a critical component of a verifiable and trustworthy software supply chain.
It is worth clarifying what this means. A supply chain attack is when malicious code is inserted somewhere in the software build or distribution process, not in the source code that users see, but in the compiled binaries that are ultimately shipped. Such attacks can be devastating because they subvert the very trust users place in verified software sources. The recent XZ-utils backdoor incident showed how subtle and dangerous these attacks can be, even when coming through seemingly trusted channels.
Reproducible builds are one of the strongest defenses against this threat. They allow anyone to independently rebuild the binaries from source and verify that the resulting artifacts match what the distribution publishes. If they do not match, it signals a potential compromise. Fedora's own reproducible builds documentation explicitly references Debian's pioneering work and the original reproducible-builds.org definition of this process. This is an essential quality in any distribution aiming to support privacy and security-conscious users.
Despite this, Privacy Guides ignores Debian's concrete and well-established progress in this area, while promoting rolling or fast-moving distributions that are still working toward this goal, in some cases with significant limitations still in place. It is important to recognize that reproducible builds are a fundamental, distribution-wide guarantee, they cannot be substituted by user-facing sandboxing tools like Flatpak or by simply having newer package versions.
Debian's mature work in reproducibility, combined with its transparent and auditable build infrastructure, directly addresses one of the most serious modern threats to software integrity. By failing to factor this into their criteria, and by ignoring Debian's leadership in this space even while their recommended distributions acknowledge it, Privacy Guides presents an incomplete picture of which Linux distributions are suitable for privacy-focused users.
The recent XZ-utils supply chain attack offers a concrete example of why these issues matter in practice. The malicious backdoor was introduced into upstream XZ version 5.6.0, which was quickly picked up by rolling-release distributions such as openSUSE Tumbleweed, and distributed in install media and container images in Arch Linux. While the Arch Linux team later clarified that the injected malicious code was not actively exploitable in their default binaries, the compromised versions were still shipped to users in official artifacts. This reflects a structural risk of rolling models: they rapidly ingest new upstream code, in many cases before a broader review cycle can detect subtle supply chain attacks. Meanwhile, Debian stable's conservative release process kept its users entirely unaffected, as the vulnerable version had not been adopted. This is a clear example where prioritizing the "latest versions" over careful vetting and reproducibility exposed users to risk, and it underlines the short-sightedness of Privacy Guides' preference for rolling distributions without considering these risks.
Relevant:
Arch Linux regularly appears online, accompanied by the meme-like phrase "I use Arch btw", as the ultimate "power user" distribution. In reality, however, it is a poor fit for those who prioritize serious security and privacy. Arch is a hobbyist-oriented, bleeding-edge rolling release system, with minimal default security hardening, limited auditability, and no focus on privacy by default.
One of the most glaring issues is the heavy reliance on the AUR (Arch User Repository), where packages are contributed by individual users with little to no formal review. Installing software from the AUR is frequently done blindly, without proper auditing of PKGBUILDs or source code, introducing serious supply chain risks, similar to those discussed earlier. This model relies on trust in random contributors, an unacceptable risk profile for any privacy-critical system.
Arch also lacks official, well-maintained support for many respected privacy tools. For example, users wanting to install Tor Browser, Signal, Mullvad VPN, or Mullvad Browser must rely on AUR packages, which undermines both trust and consistency. In contrast, distributions like Debian offer vetted packages for several of these tools, and for those that are not officially packaged (e.g., Tor Browser), verified, reproducible upstream builds are provided.
Finally, while Arch offers extreme flexibility, this comes at a cost: complex manual configuration. Even advanced users can easily overlook critical hardening steps or misconfigure their systems in subtle ways. For those seeking a reliable, secure, privacy-respecting environment, having to rebuild trust and security from scratch is not a reasonable starting point.
Another factor overlooked in Privacy Guides' promotion of Atomic systems is that these models reduce the user's ability to manage system security proactively. The base OS is intentionally read-only, which limits transparency, local auditing, and the capacity to apply targeted patches or emergency mitigations without performing full image rebuilds or rebases. If a system compromise occurs at the base level, users are dependent on upstream fixes and release cycles, they cannot take responsive action themselves. In practice, this model has led to complex workarounds when critical drivers, kernel modules, or security configurations needed adjustments that Atomic workflows do not readily support.
A related point is how projects in this space frame their goals. In one popular discussion about Secureblue, a hardening layer built on Fedora Atomic Desktops, a user described it as "not meant to improve your privacy, only your security," a characterization that likely reflected the project's initial messaging or public perception. The current official site now states: "Secureblue is designed for users whose first priority is using desktop Linux, with security as a second priority." While this clarifies the intended audience, it still highlights a larger issue: treating privacy and security as separate concerns is misguided. The two are fundamentally intertwined, weakening one undermines the other. The notion that a system can be "secure" while leaving privacy as an afterthought reflects the kind of compartmentalized thinking that Privacy Guides should be challenging, not endorsing. In this way, the immutability promoted by Atomic models, while useful for consistency, can hinder the system's ability to adapt to evolving security and privacy threats.
User experiences echo these concerns. Across discussions in the Fedora community, Linux forums, and even security-focused spaces like GrapheneOS, users repeatedly point out that Atomic systems trade transparency and flexibility for a narrow form of immutability. While consistent system images and rollbacks can be valuable in certain environments, such as appliances or kiosks, they come at the cost of reduced user agency, fragile update processes, and limited ability to respond quickly to emerging threats. Worse, the promise of a "secure" base system can foster a false sense of confidence, while the actual attack surface, such as applications, user data, and containers, remains exposed. In this light, Privacy Guides' promotion of Atomic systems without adequately addressing these constraints is not only incomplete, but potentially misleading for users seeking genuine security and privacy resilience.
Privacy Guides recommends options such as SimpleX Chat, while PrivacyTools has promoted Session, but both of these instant messaging apps suffer from the same fundamental issues. Despite claiming to be decentralized, this decentralization is effectively illusory: in practice, both projects maintain their own servers, meaning users are still dependent on a centralized infrastructure controlled by the project maintainers. Their claims of decentralization do not withstand scrutiny and ultimately fall apart under closer examination.
Even the developer of SimpleX acknowledges this reality. He states, "as only preset servers are operated by us [and] are centralized at the moment" (source). Elsewhere, he further admits that "self-hosted servers make traffic analysis easier" (source). In other words, the supposed decentralization is not only incomplete, but also introduces additional risks that undermine its intended privacy guarantees.
A second critical weakness is the lack of reproducible builds in both cases. Without verifiable builds, users cannot confirm that the binaries they install correspond to the public source code, a notable omission for applications that claim to prioritize privacy and security. In this respect, these projects replicate many of the problems inherent in Software-as-a-Service (SaaS) models, which Richard Stallman has long criticized: users must trust someone else's server and binaries, without meaningful verification or independence.
This is a completely different situation from that of Signal. While Signal itself is centralized, it offers reproducible builds, an essential safeguard, and remains a vastly superior alternative to platforms like WhatsApp, especially when usability is taken into account. I am aware of the criticisms that have been raised against Signal, but in practical terms, it remains the most balanced and trustworthy option currently available for secure messaging among non-technical users.
As for the other recommendations once promoted by PrivacyTools (such as Tox, Speek, and Threema), they are similarly problematic. The core principles I have outlined here should provide sufficient grounds for making an informed judgment about any such tools.
Privacy and security are not goals you simply "achieve" and forget, they are ongoing processes of learning, adaptation, and vigilance. As threats evolve and tools change, so too must your understanding and your practices.
No system is invulnerable, and no setup is foolproof. Tools like GNU/Linux offer great flexibility, but with that comes responsibility, missteps and poor choices can easily undermine your efforts. It’s important to stay informed, apply changes thoughtfully, and remain open to new research or proven improvements. Good security and privacy practices are never static; they evolve with time, and so should your approach.
In the end, it's about maintaining control over your data and your devices, and taking responsibility for the choices you make. If this article has helped you think more clearly about that, then it has served its purpose. By the will of Allah, the rest is in your hands.
The tips provided here can also be applied to other GNOME or Wayland environments; however, be sure to adjust them as needed to suit your specific GNU/Linux distribution.
If your display looks too large or too small with the default scaling options, you can enable fractional scaling to fine-tune it (for example, 125% or 150%).
Run the following command in a terminal:
gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"After that, go to Settings → Displays, and you will see more scaling options available.
If you are using Debian, you may want to consider installing some useful free software applications. These can be installed easily via the terminal:
sudo apt update && sudo apt install vlc onionshare gdebi keepassxc apparmor-profilesYou also can improve the security of your system updates by making sure your /etc/apt/sources.list uses HTTPS (instead of HTTP) for Debian package sources. As of recent Debian versions, APT supports HTTPS by default.
To do this, edit your sources list:
sudo nano /etc/apt/sources.listThen update the URLs to start with https:// instead of http://. For example:
deb https://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb https://security.debian.org/debian-security bookworm-security main contrib non-free
deb https://deb.debian.org/debian bookworm-updates main contrib non-freeOptionally, you may see lines starting with deb-src, which enable downloading source packages. These are not required for most users, so you can disable them by commenting them out — simply add a # at the start of each deb-src line:
# deb-src https://deb.debian.org/debian bookworm main contrib non-free
# deb-src https://security.debian.org/debian-security bookworm-security main contrib non-free
# deb-src https://deb.debian.org/debian bookworm-updates main contrib non-freeAfter saving your changes and exiting the text editor, run:
sudo apt updateThis will reload your package lists using secure HTTPS connections and reflect any changes.
GDebi is a lightweight graphical installer for .deb package files. It makes it easy to install software downloaded from the web by handling any required dependencies automatically.
If you have already installed GDebi, you can use it to install programs such as VeraCrypt:
.deb file from the official website:
.deb file in your file manager and select Open with GDebi Package Installer.Using GDebi is a convenient and reliable way to install third-party .deb packages on Debian-based systems.
In the Software Repositories window, you’ll see options like:
Now that the correct sources are enabled:
If you are running a GNU/Linux distribution with GNOME using Wayland, you can configure Tor Browser to use native Wayland support. This can improve graphical performance and security isolation.
To do this, you need to edit the launcher script used by Tor Browser.
When installed through torbrowser-launcher, Tor Browser is located in your home directory:
~/.local/share/torbrowser/tbb/x86_64/tor-browser/Browser/execdesktopTo enable Wayland support:
nano ~/.local/share/torbrowser/tbb/x86_64/tor-browser/Browser/execdesktop#!/usr/bin/env bash), add the following lines:
# Enable Wayland for Tor Browser
export MOZ_ENABLE_WAYLAND=1#!/usr/bin/env bash
# Enable Wayland for Tor Browser
export MOZ_ENABLE_WAYLAND=1
# (rest of the script continues here)nano: press Ctrl+O, Enter to save, then Ctrl+X to exit.You can now launch Tor Browser as usual. It will use native Wayland support in your GNOME session.
To check whether Tor Browser is running with native Wayland support, open the browser and navigate to about:support. In the displayed information, look for references to Wayland.
If you see "wayland" mentioned in the Window Protocol, native Wayland is in use. If it says xwayland, the browser is running through the X11 compatibility layer, meaning native Wayland is not active.
This guide assumes that you have previously added the official Mullvad Browser repository to your system and installed Mullvad Browser using your package manager.
To enable native Wayland support, you need to edit the Mullvad Browser launcher script.
sudo nano /usr/lib/mullvad-browser/mullvadbrowser#!/bin/sh
export MOZ_ENABLE_WAYLAND=1nano: press Ctrl+O, Enter to save, then Ctrl+X to exit.After editing the script, it is recommended to log out and back in — or restart your session — before launching the browser again to ensure the Wayland setting takes effect.
The gnome-shell-extension-appindicator is a GNOME Shell extension that allows traditional system tray icons (AppIndicators) to appear in the GNOME top bar. This is useful for applications like Mullvad VPN, VeraCrypt, and some legacy apps that rely on tray icons for interaction.
Open a terminal and run the following command:
sudo apt update && sudo apt install gnome-shell-extension-appindicatorAfter installation, enable the extension using the Extensions application available in your system menu. Simply toggle Ubuntu AppIndicators to ON. You may need to reboot for it to appear.