Why Security-Conscious Gamers Play Minecraft on Linux

When someone says "I play Minecraft on Linux," the usual response is a raised eyebrow. Many people think of Linux as a developer tool, a server OS, or a hobbyist experiment. But for those who think carefully about what happens on their machines when they launch a game, Linux is not a quirk. It is a deliberate choice. And Minecraft, of all games, sits at the center of a fascinating set of privacy, security, and architecture concerns that make the platform question much more significant than it first appears.

This article is not a tutorial on installing Minecraft. There are plenty of those. This is a careful look at what is actually happening under the hood — on both operating systems — when you load a world, move through it, and log off. Understanding the difference requires examining kernel security primitives, telemetry architecture, JVM internals, and the philosophy of how operating systems handle trust. These are things worth understanding regardless of whether you ever play a single block game, because they reveal something important about how modern software relates to the machines it runs on.

The Telemetry Problem: What Minecraft Is Actually Sending

Let us start with Minecraft itself, because many players do not know what the game is doing in the background.

Minecraft: Java Edition historically included a feature called the Snooper, which collected and transmitted usage data to Mojang. It was removed in snapshot 18w21a as a direct response to the European Union's General Data Protection Regulation (GDPR), because Mojang's legal team apparently concluded that the Snooper's data collection practices were not compliant with the regulation's requirements around consent and identifiability. That removal was widely praised by privacy advocates. It lasted about three years.

In snapshot 21w38a — released during the development cycle for Minecraft 1.18 — Mojang re-introduced telemetry under the framing of improving player experience. The critical difference from the original Snooper: this time, there is no off switch. As of version 1.19.3, players can toggle between "Minimal" and "All" data collection settings, but the Minimal setting is still mandatory — there is no "Off" option through the official client.

The community has submitted formal feedback requesting a proper off toggle. The argument made by a community member on Mojang's official feedback portal captures the problem well: players who want to safeguard their data should not need to resort to workarounds, and the absence of a true opt-out may place Microsoft and Mojang at ongoing risk of violating GDPR if its provisions are updated or reinterpreted. As of this writing, no full opt-out has been provided.

The developer response to this gap has been a Fabric and Forge mod called "No Telemetry," which has been downloaded over five million times via CurseForge. That number tells you something about how many players feel about being opted in by default. On Linux, this mod works exactly as it does on Windows — the Java runtime is the same, the mod loader is the same, and the JVM network calls that the mod intercepts are the same. The platform does not magically solve the telemetry problem within Minecraft itself.

What the platform does is affect everything else happening on the machine at the same time.

The OS Telemetry Layer: Windows Is Doing More Than You Think

When you run Minecraft on Windows, you are not running a single process in a quiet room. You are running a game in an operating system that has its own comprehensive telemetry infrastructure running concurrently. Understanding the interaction between these two layers is essential to the platform security conversation.

Windows includes a background service called DiagTrack, whose official display name is "Connected User Experiences and Telemetry." It is a built-in Windows service that collects and transmits anonymized data about user experience and device health to Microsoft, including things such as device specs, installed programs, basic error information, and Windows update details.

The service runs as LocalSystem — one of the highest privilege levels available in the Windows service model — in its own svchost.exe process. It manages event-driven diagnostic collection including crash reports and app usage events, coordinates the local staging and upload of telemetry artifacts, and supports connected user experiences features that rely on anonymous signals to tailor OS and feature improvements.

There is also a companion scheduled task called CompatTelRunner (Microsoft Compatibility Appraiser), which performs more detailed compatibility and telemetry scans. Consumer versions of Windows 10 and 11 do not allow DiagTrack to be disabled through the standard Settings UI — it requires group policy configuration or direct service modification via the registry or command line. Even if a privacy-conscious user disables DiagTrack, other telemetry channels continue to operate.

What this means in practice is that when a Windows user plays Minecraft, there are two separate telemetry pipelines active: one from the game itself sending session data with the player's Xbox user ID, and one from the operating system sending device telemetry, app usage data, and compatibility information to Microsoft. Both are sending data to the same company. Microsoft owns Mojang. This is not a conspiracy theory — it is a straightforward description of the corporate structure and its technical implications.

On Linux, there is no equivalent to DiagTrack. There is no background service collecting app usage data and transmitting it to the kernel maintainers or distribution publishers by default. Major distributions such as Ubuntu do include opt-in error reporting systems (Apport, Whoopsie), but these are opt-in, clearly disclosed during installation, and do not track app usage patterns or cross-app behavioral data. The absence of a persistent, background, always-on telemetry service at the OS level is a default security posture, not a setting you have to work to achieve.

Linux Kernel Security Primitives: The Architecture of Isolation

To understand why Linux is a structurally better environment for running a network-connected Java application from a security standpoint, you need to understand what the Linux kernel provides that Windows does not expose in the same way.

The Linux kernel implements several mechanisms for process isolation and security that are either absent from Windows or exist in a less composable, less configurable form. Three of these deserve careful attention: namespaces, seccomp-BPF, and Linux Security Modules.

Namespaces are the foundational isolation primitive of the Linux kernel. There are currently eight distinct namespace types: UTS (hostname and domain name), IPC (inter-process communication), PID (process IDs), mount (filesystem view), network (network interfaces and routing tables), user (user and group ID mappings), cgroup (control group memberships), and time (clock offsets introduced in kernel 5.3). Namespaces wrap global system resources so that processes appear to have their own isolated instance. When you run a container, it gets its own PID namespace so it cannot see host processes, its own mount namespace giving it its own filesystem view, and its own network namespace with its own interfaces.

This composability is key. It means you can give Minecraft — or any application — a restricted view of the system without affecting anything else. A process running in a network namespace can only see and interact with the network interfaces explicitly allocated to it. A process running in a PID namespace cannot enumerate the other processes on the system. These are not settings configured at the application layer. They are enforced by the kernel itself.

Seccomp-BPF (Secure Computing Mode with Berkeley Packet Filter) is arguably the most powerful application security primitive in the Linux kernel. Seccomp allows a process to make a one-way transition into a "secure" state where it cannot make any system calls except exit(), sigreturn(), read() and write() to already-open file descriptors. Should it attempt any other system calls, the kernel will either log the event or terminate the process with SIGKILL or SIGSYS.

The BPF extension makes this more flexible by allowing developers to attach a BPF program that acts as a system call filter, permitting or denying specific syscalls based on syscall number and argument values. The result is that the attack surface available to any code running inside the process — including injected shellcode — is dramatically reduced. By filtering and limiting the system calls accessible to a process, seccomp aids in minimizing the potential impact of vulnerabilities and decreases the attack surface.

The practical implication: if a malicious Minecraft mod or a compromised dependency attempts to execute a shell command, create a new process, or establish a raw socket connection, a properly configured seccomp filter will block it at the kernel level before any userspace code can respond. The kernel does not need to ask the application whether this is allowed — it simply does not pass the call through.

Linux Security Modules (LSMs) such as AppArmor (default in Ubuntu and Debian) and SELinux (default in Fedora and RHEL) provide mandatory access controls at a higher level than seccomp. Where seccomp filters based on which syscalls a process can make, LSMs define what resources — files, sockets, capabilities — a process can access, based on a policy that is defined and loaded by an administrator rather than by the application itself. AppArmor in particular uses a path-based policy model that is relatively approachable for end users.

None of this machinery requires root privileges to benefit from in the context of running applications. Firejail, an open-source sandboxing utility, is a SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces, seccomp-bpf, and Linux capabilities. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, and mount table.

A Linux user can launch Minecraft through Firejail in under a minute:

$ firejail --net=eth0 --dns=1.1.1.1 --private-tmp java -jar minecraft-launcher.jar

This gives Minecraft its own network stack view, redirects its DNS queries to a controlled resolver, and isolates its /tmp directory — all without requiring system administrator privileges or modifying a single system configuration file. If Minecraft attempts to read files outside its home directory, that access will fail silently or be denied at the kernel level before the application ever receives a file descriptor.

The JVM Security Landscape: A Critical Architecture Shift

Minecraft: Java Edition runs on the Java Virtual Machine, and understanding what has changed in the JVM security model recently is important for any technically serious discussion of Minecraft security on any platform.

Java historically provided a mechanism called the SecurityManager — a runtime permission enforcement layer built into the JVM that allowed code to define and enforce security policies, restricting what operations (file access, network connections, process creation) were permitted for code loaded from specific sources. Minecraft and its plugin ecosystem made varying use of this mechanism over the years, and some server implementations relied on it heavily to sandbox potentially malicious plugins.

Why does this matter for Minecraft security? It means that the JVM-level sandboxing layer that some server administrators and security-conscious players previously relied upon to contain the behavior of Minecraft mods and plugins no longer exists in any functional sense. Any security guarantees must now come from somewhere else.

There is a companion development worth noting. JEP 472, also shipped in JDK 24, begins restricting the Java Native Interface (JNI) — the mechanism by which Java code calls native compiled code. JNI has long been an avenue for bypassing JVM-level protections entirely, since native code operates outside the managed runtime's safety checks. JDK 24 introduces warnings for JNI usage by default; future releases are expected to make those warnings into hard exceptions, fully restricting JNI unless explicitly enabled at startup. For Minecraft modders, this matters: a mod that uses JNI to call native libraries can execute code that no JVM-level protection — past or present — would have constrained. That attack path already existed; now the JDK is signaling its intent to close it, but hasn't yet.

The "somewhere else" on Linux is the kernel. Seccomp, namespaces, AppArmor, and Firejail can enforce boundaries on Minecraft's JVM process at the OS level, independent of whether the JVM itself has any internal security mechanism. The kernel does not know or care that the process running beneath it is a Java application — it enforces its policies against the process boundary regardless.

On Windows, with the SecurityManager gone and without equivalent kernel-level sandboxing tools available for arbitrary user-space applications, a Minecraft mod that attempts to exfiltrate data, read files outside the game directory, or establish outbound connections to unauthorized endpoints has a significantly wider opportunity to do so before being detected or stopped. If untrusted code can reach ClassLoader.defineClass, escaping the Java sandbox is trivial. The attack surface for malicious mods is non-trivial and has been demonstrated in real incidents — including one in 2023 that affected both Windows and Linux users simultaneously, and which we examine next.

Fractureiser: When the Threat Model Became Real

Theory is useful. But the reason this conversation matters in practice — not just academically — is that the threat model described above was not hypothetical. In June 2023, a multi-stage information-stealing malware campaign named Fractureiser compromised multiple accounts on CurseForge and the Bukkit plugin repository. The attackers injected malicious code into widely-used Minecraft mods and plugins, including those bundled in popular modpacks with millions of downloads. The campaign is estimated to have infected over 6,000 machines before the command-and-control servers were taken down.

The Fractureiser malware was architecturally sophisticated. It operated in four stages: Stage 0 was embedded in infected JAR files and downloaded a next-stage payload. Stages 1 through 3 progressively escalated capability, ultimately delivering a payload that could steal browser cookies and saved credentials, replace cryptocurrency wallet addresses in the clipboard, and exfiltrate credentials for Minecraft, Discord, and Microsoft accounts. Critically, Stage 3 included a self-propagation mechanism: it scanned the filesystem for other JAR files and injected Stage 0 into them, meaning that mods which were never downloaded from a compromised source could become infected simply by existing on the same machine as an infected mod.

This is exactly the scenario the Linux sandboxing discussion is preparing for. The Prism Launcher project confirmed that the Fractureiser Stage 3 payload would fail to function correctly inside the default Flatpak sandbox because the malware hardcodes the user's ~/.config/ directory — a path that, inside a Flatpak sandbox without explicit filesystem permissions, is either absent or redirected to a per-application sandbox directory that gets wiped. A Firejail profile with whitelist ~/.minecraft and read-only ~/ would similarly prevent the payload from establishing persistence.

The Fractureiser incident answers a question that sometimes gets raised in these discussions: "Isn't this all theoretical?" The answer is no. And notably, the incident also demonstrated something about supply chain risk that Linux's open-source toolchain actually addresses more meaningfully than Windows: when the community discovered that CurseForge's CDN used the outdated MD5 algorithm to verify downloads — making cache poisoning attacks possible — that finding was public, documented, and acted upon. The full post-incident analysis is available in a GitHub repository maintained by the investigation community, open for anyone to read and verify. That kind of transparent post-mortem is structurally more available in the open-source ecosystem than it would be for a closed telemetry or distribution pipeline.

The incident also raised a pointed question about mod security architecture that this article would be incomplete without asking: if you are running a Minecraft server, not just a client, what does your security posture look like? A server running dozens of third-party plugins is a substantially larger attack surface than a single-player client with a few mods. On Linux, each of the tools discussed in this article applies directly to server deployments — in fact, many Linux server administrators already run Minecraft servers as dedicated, low-privilege system users under systemd, with service-level sandboxing applied via the SystemCallFilter, NoNewPrivileges, and PrivateTmp directives in the unit file. This approach is worth examining in the hardening section.

Network Traffic and the Principle of Least Privilege

Every time Minecraft launches, it establishes outbound connections. It authenticates with Microsoft's session servers. It may check for updates. It sends telemetry. On a public server, it communicates with the game server over TCP on port 25565 by default. Each of these connections represents an attack surface — not just for passive data collection, but for active exploitation.

On Linux, a security-conscious user can apply network-level controls at multiple layers independently. The firewall (nftables or iptables) can restrict which processes are permitted to make outbound connections and to what IP ranges. With network namespaces, the game can be placed in an isolated network environment where only specific routes are permitted. The DNS resolver can be controlled at a per-process level using Firejail's --dns flag, preventing the game from using a resolver that might be compromised or logging queries.

More fundamentally, the Linux permission model allows a player to run Minecraft as a dedicated, unprivileged user account with no other processes running under that account and no sensitive files in its home directory. If the game or a mod is compromised, the blast radius is limited to what that account can access. This follows the principle of least privilege — a foundational concept in information security — in a way that is straightforward to implement and verify on Linux.

On Windows, running applications under separate user accounts for security purposes is possible but awkward in practice. The Windows user model does not have the same depth of per-process filesystem ACLs that Linux achieves through its combination of DAC (discretionary access control) and mandatory access control via LSMs. The user experience friction of maintaining separate security-context accounts for gaming is high enough that almost no consumer Windows users do it.

What "Open Source" Means for Trust in This Context

One dimension of the Linux security advantage that does not get discussed enough in gaming contexts is verifiability. The Linux kernel, Firejail, AppArmor, and the core system utilities used to implement these security controls are all open source. The security properties they claim to provide can be — and regularly are — independently audited, formally analyzed, and verified through code review.

When a Linux security primitive claims that a process cannot see files outside its restricted mount namespace, that claim is grounded in publicly readable kernel code and has been reviewed by security researchers who have a financial and reputational incentive to find mistakes. When a flaw is found — and they are found — the fix is made publicly, often within days for critical issues, and can be applied immediately.

The telemetry behavior of Windows, the DiagTrack service, and the data Microsoft collects from gaming sessions is not independently verifiable by consumers. Microsoft publishes documentation about what it collects, but that documentation cannot be independently verified against the actual behavior of the closed-source binaries. For security professionals who work in threat modeling and adversarial thinking, this distinction between "trust me" and "verify it yourself" is not a minor philosophical preference — it is a fundamental requirement for any serious security posture.

This matters specifically for Minecraft because the game is popular with children. Parents who are security-aware and privacy-concerned should understand that running Minecraft on Windows means operating within a telemetry stack where the full behavior cannot be independently confirmed, and where the same company that owns the OS also owns the game. On Linux, both the OS telemetry layer and the application sandboxing layer can be inspected, modified, and verified by anyone with sufficient technical knowledge.

Practical Hardening: What You Can Actually Do on Linux

Understanding the theory is only useful if it connects to action. Here is a concrete picture of what a security-conscious Linux setup for Minecraft looks like in practice.

The starting point is choosing an official installation method that adds an additional sandbox layer. Mojang provides an official .deb package for Debian-based distributions, but the Flatpak distribution via Flathub is worth considering for security purposes. Flatpak uses bubblewrap under the hood — a minimal SUID sandbox based on Linux user namespaces — and applies a permission model defined at the package level. This means Minecraft as a Flatpak is already running inside a constrained namespace environment before any additional tools are applied.

For users who want more granular control, Firejail with a custom profile provides a higher degree of restriction:

# /etc/firejail/minecraft.profile
include default.profile
private-tmp
net eth0
dns 1.1.1.1
dns 9.9.9.9
whitelist ~/Games/Minecraft
whitelist ~/.minecraft
read-only ~/

This configuration gives Minecraft access to its own game files, an isolated temporary directory, a specific DNS resolver, and nothing else. Any attempt to read files in other home directories, access system configuration files, or write to system locations will be blocked at the kernel level through the mount namespace and filesystem overlay Firejail constructs.

For the in-game telemetry, the No Telemetry mod (available on Modrinth and CurseForge, compatible with Fabric and available in over a dozen Minecraft versions) disables the mandatory WorldLoaded and WorldUnloaded telemetry events entirely. Combined with OS-level sandboxing, this creates a meaningful layered defense: the kernel prevents unauthorized file and network access, the sandbox isolates the process from the rest of the system, and the mod prevents the game from executing its own built-in data transmission calls. Each layer is independent, and each operates at a different level of the stack.

Network-level controls complete the picture. An nftables rule restricting Minecraft's outbound connections to known Mojang IP ranges, combined with DNS filtering to block Mojang's telemetry endpoints (currently routed through analytics.tj-mc.minecraftservices.com), provides defense-in-depth against data transmission even if a mod or launcher component attempts to bypass the in-application controls. A minimal nftables ruleset for this purpose:

# Restrict the minecraft user's outbound traffic to Mojang auth + game servers
# Replace UID 1001 with the actual UID of your minecraft user account
table inet minecraft_policy {
  chain output {
    type filter hook output priority 0; policy accept;
    # Allow established connections back
    ct state established,related accept
    # Allow DNS lookups
    meta l4proto { tcp, udp } th dport 53 accept
    # Block known Mojang telemetry endpoint by owner UID
    meta skuid 1001 ip daddr { 20.54.232.0/24 } drop
    # Allow Mojang auth + session servers, game port 25565
    meta skuid 1001 ip daddr { 54.230.0.0/15 } accept
    meta skuid 1001 tcp dport 25565 accept
    # Drop everything else from the minecraft user
    meta skuid 1001 drop
  }
}

This approach uses nftables' meta skuid matching to apply rules based on the Linux user ID of the process originating the traffic. Because Minecraft runs as a dedicated low-privilege user account on a properly configured Linux system, all of its outbound traffic can be identified and filtered at the kernel's netfilter layer — before it leaves the machine, independent of any application-layer controls.

Systemd Sandboxing for Minecraft Servers

For players running Minecraft servers — which carry a substantially larger attack surface than single-player clients, since they process external player connections and may run dozens of untrusted plugins — the Linux toolchain offers another layer that deserves explicit attention: systemd service sandboxing. When Minecraft runs as a systemd service under a dedicated user, the unit file itself becomes a security policy document.

[Unit]
Description=Minecraft Server
After=network.target

[Service]
User=minecraft
WorkingDirectory=/srv/minecraft
ExecStart=/usr/bin/java -Xms2G -Xmx4G -jar server.jar nogui

# Prevent privilege escalation
NoNewPrivileges=true
# Isolated /tmp and /var/tmp
PrivateTmp=true
# Read-only system directories
ProtectSystem=strict
# No access to /home, /root, /run/user
ProtectHome=true
# Writable paths explicitly whitelisted
ReadWritePaths=/srv/minecraft
# No device access except safe pseudo-devices
PrivateDevices=true
# Restrict system call classes (adjust for JVM needs)
SystemCallFilter=@system-service @network-io @process
SystemCallErrorNumber=EPERM
# Restrict capabilities to minimum required
CapabilityBoundingSet=
AmbientCapabilities=

[Install]
WantedBy=multi-user.target

Each directive in this unit file maps to a concrete kernel enforcement mechanism. NoNewPrivileges=true calls prctl(PR_SET_NO_NEW_PRIVS), preventing the JVM from gaining elevated capabilities through setuid binaries — precisely the technique Fractureiser's Stage 3 relied upon via its hook.dll payload. ProtectSystem=strict remounts the filesystem with read-only overlays for /usr, /boot, and /etc. PrivateTmp=true gives the service its own mount namespace for /tmp, isolating it from the host's shared temp directory — the exact vector Fractureiser used for staging its payload files. SystemCallFilter applies a seccomp whitelist at the service level, restricting the JVM to a named set of syscall groups appropriate for a network-connected Java application. If a malicious plugin attempts to call a syscall outside those groups — ptrace, execve, raw socket creation — it will receive EPERM and fail before any userspace code can respond.

This systemd-level sandboxing is distinct from, and complementary to, Firejail and AppArmor. They operate at different points in the stack: AppArmor enforces path-based mandatory access controls, Firejail constructs namespace isolation for interactive processes, and systemd sandboxing provides declarative process security for service-managed daemons. A properly hardened Linux Minecraft server runs under all three simultaneously, each enforcing independently. An attacker who finds a way around one layer still faces the others.

The Broader Lesson: Platform as Security Posture

The Minecraft-on-Linux question is interesting not just for what it reveals about a specific game, but for what it reveals about how security-conscious people should think about platform selection in general.

Most consumer security advice focuses on what software to run — use this antivirus, use that VPN, enable this feature. Far less attention is paid to the foundational properties of the platform those tools run on, and whether the platform itself is structured in a way that supports security goals.

There is a deeper structural question here that rarely gets named directly: who benefits from your platform being hard to audit? Microsoft's telemetry infrastructure, Mojang's re-introduced XUID-linked data collection, and the opacity of closed-source binaries are not random design decisions — they reflect the interests of organizations for whom behavioral data has commercial or product value. That is not a conspiracy. It is just incentives. Linux, by contrast, has no single commercial entity with a financial interest in tracking what applications you run or how you use them at the kernel level. The absence of a DiagTrack equivalent is not an oversight. It reflects a different set of stakeholder interests embedded in the platform's design.

Linux, as a platform, is structured around composable kernel primitives that give users genuine control over how applications interact with the system. The security controls available — seccomp, namespaces, LSMs, cgroups — are not add-ons or vendor products. They are intrinsic to how the kernel works, exposed through stable interfaces, and available to any user who understands how to use them. The open-source nature of both the tools and the underlying kernel means that their security properties are verifiable rather than merely claimed.

Windows, by contrast, is structured around a closed telemetry architecture, a permission model that grants OS-level services extraordinary access with limited auditability, and a gaming ecosystem that increasingly integrates with Microsoft Account identity in ways that make behavior tracking easier rather than harder. The JVM SecurityManager's removal makes this more acute: the application-layer security fence that some mod authors and server operators relied upon is gone, and the platform you are running the JVM on now determines how much replacement security enforcement is available.

What Fractureiser revealed is also worth sitting with: the attack was not a theoretical zero-day. It was a supply chain compromise — compromised accounts, malicious JAR files distributed through trusted channels, self-replicating payloads. These are the actual threat vectors that affect real Minecraft players. Linux sandboxing, at the Flatpak or Firejail level, meaningfully constrained the damage in a way that a default Windows installation could not. That is a data point from a real incident, not a vendor claim.

Playing Minecraft on Linux does not make you invulnerable. A compromised mod can still do damage within the constraints of the game user account. Bad operational security elsewhere on the system can undo careful application hardening. And the social engineering attack surface — convincing players to install malicious mods through unofficial channels — is entirely platform-agnostic.

But it does mean you are operating within a system where the tools to enforce least privilege are native, composable, verifiable, and free. Where no background service is transmitting your app usage patterns to a vendor by default. Where the JVM you are running the game on has lost its internal security layer and the kernel has to pick up the slack — and on Linux, the kernel can.

For security professionals, educators, and technically curious players, that distinction is worth understanding in full. And for parents deciding where their children play: both the game and the OS send data to the same company. Only one platform lets you verify exactly what gets out.

Sources and Verification

All claims in this article are verifiable through primary sources. The Minecraft telemetry history is documented on the Minecraft Wiki and the Minecraft Feedback portal. The No Telemetry mod source code and documentation is available on GitHub and via CurseForge and Modrinth. The JVM SecurityManager deprecation and permanent disablement timeline is documented in JEP 411, JEP 486, and Oracle's JDK 24 Security documentation. The JNI restriction trajectory is described in JEP 472. The Fractureiser malware incident is documented in the community-maintained fractureiser GitHub repository, in the Prism Launcher incident advisory, and in technical analyses published by Bitdefender and BleepingComputer. Seccomp-BPF technical details are in the Linux kernel documentation. Linux namespace details are documented in man 7 namespaces and kernel.org. Firejail documentation and security profiles are available at firejail.wordpress.com and via man7.org. Flatpak sandbox architecture and CVE-2024-42472 are documented in the Flatpak security advisory. Windows DiagTrack behavior is documented on Microsoft Learn. Systemd sandboxing directives are documented in man 5 systemd.exec and on the systemd project website.