What can the official Discord app access on Linux?

I recently started using Ubuntu (I know it’s not recommended but I have good reason to) and I must be able to use Discord. I heard it’s a good idea to install apps as Flatpaks or Snaps so that they are sandboxed but I’m having major issues with both the Discord Snap and Flatpak. I don’t notice bugs using it in browser but it does not support screen sharing specific windows with audio and it’s incompatible with encrypted voice calls, so not an option for me. I know there are third-party clients but I’m not excited by the idea of spending even more time with trial and error as well as violating Discord terms of service.

Just so I can make an informed decision, what would the non-sandboxed official deb Discord client have access to on my system? Is there any easy way for a Linux noob like myself to confine what it can do?

The discord client (and any app you run) has the same privileges as you. The easiest way to lower those is using sandboxing.

This article (old, see @anonymous457 ‘s reply) Discord — Spyware Watchdog explains the Discord’s client behahivor in more detail.

3 Likes

My understanding is that the .deb install (and any 1st party install from a package manager) is the most invasive install from a privacy perspective. By default, package managers basically assume that since you installed the software, you are OK w/ anything it is doing behind the scenes w/ user files.

Things that it could (potentially) access include:

  • Read your SSH keys (could be great for fingerprinting you)
  • Monitor what files you’re working on
  • Read your bash history
  • Access browser cookies/sessions
  • See what other apps you’re running

First Party Package Manager installs are (IMO) best for packages that you trust, and everything else should be containerized via Flatpak/Firejail/Snap/Docker etc.

Personally I use webcord since it has a focus on privacy/security and is popular. From their GitHub readme, here is their approach on privacy:

WebCord does a lot to improve the privacy of the users. It blocks known tracing and fingerprinting methods, but it does not end on it. It also manages the permissions to sensitive APIs like camera or microphone, sets its own user agent to the one present in Chromium browsers and spoof web API modifications in order to prevent distinguishing it from the real Chrome/Chromium browsers.

And here is their info on security:

WebCord cares a lot about your security. Being fully written in TypeScript, it brings the power of static types to help detecting common bugs without the need of testing the app at runtime. All of this is hardened by ESLint, which forbids some TypeScript practices like the use of any type and enforces some cosmetic aspects of the code to keep it more consistent.

Unlike the official Discord client, WebCord’s policy about Electron also makes it to use the latest major release currently supported and available at the package time. This makes WebCord use more up-to-date Electron releases with more recent Chromium engine.

Built on top Electron and Chromium, WebCord’s security is also highly dependent from Chrome’s vulnerability rewards program, which is probably one of the most known programs like this when comparing to different popular browser engines choices. Electron is also well-prepared for loading remote content, using their process model to the advantage and different Chromium sandboxing techniques to split Node.js from browser scripts. WebCord also tries its best to follow practices from the Electron#Security.

(A 3rd party app may not be ideal for certain threat models FYI)

I actually use a .deb install of webcord, but I also use firejail’s discord profile (and the --private /path/to/folder flag) to reduce some theoretical-but-possible security/privacy concerns of a 3rd party app. Firejail is a big rabbit hole though as a heads up.

My suggestion is to pivot away from the official .deb app and either troubleshoot the official app’s flatpak (or try webcord’s flatpak) and cross-reference flatseal to limit its theoretical scope as a safety precaution.

1 Like

Is it possible to install it in an unprivileged user profile? I tried testing it out by creating a new admin user and demoting my current user to a standard account, but when logging into the admin I noticed that a deb program I previously installed still transferred over.

Without a sandbox, it can do anything that it wants to.
And because its a proprietary application with some ties to the CCP, it would totally undermine any privacy gains you made by switching to Linux in the first place.
I would recommend to either use the Flatpack or even better the Web app, cause Web apps can harvest even less data then Flatpacks.

If these doesn’t work, you could consider an third party open source client.
As your mentioned it could mean some try and error, but if you can make the switch to Linux, you can also switch from proprietary Discord to an open source client :+1:

1 Like

Try using a Linux friendly client like Vesktop.

I’ll be honest, the state of electron apps right now aren’t great but what I usually do is use a Linux client like Vesktop but have the official Discord app installed just in case it doesn’t work.

9 times out of 10, you will have a superior Discord experience with less of the potential privacy implications of giving the official app access to your screen or something like that.

2 Likes

I just want to jump in to quickly say that that source is not up-to-date.

Specifically, that article’s most recent update (visible at the very bottom of the page) is August 17th of 2021.[1] Furthermore, their Neocities profile indicates that the website as a whole was last updated three years ago.[2] To further cement that the website is no longer active, their git repo was archived on September 17th of 2024.[3]

We should not cite sources from projects that are no longer actively developed, especially considering the fact that the technological landscape is always changing.

The article is certainly informational, but it at best shows Discord’s client behavior from 2021, not currently.


  1. Discord — Spyware Watchdog ↩︎

  2. Neocities - Home - Spyware Watchdog ↩︎

  3. shadow/SpywareWatchdog - Codeberg.org ↩︎

2 Likes

That’s the principle of sandboxing, but while you could run discord as a standalone unprivileged app, this wouldn’t change anything other running it from the deb install as the executable inherits from the user’s provileges anyway (except the install scripts ran as root by dpkg, which could be another attack vector)

I think Flatpack is the established and reliable way that is also at least a bit user friendly way to sandbox Linux applications

1 Like

The discord flatpak breaks the sandbox used by electron and relies on zypak to “replace it”

Thanks for the suggestion, I tried it but for me WebCord was even more dysfunctional than the Discord Flatpak. I reported a bug to Discord but they didn’t get back to me. I might try Vesktop at some point but I don’t want to get my hopes up. I’ll try to come back with a solution if I find one.

1 Like

That has been the main problem since I posted

I checked the flathub site and I thnink you are right, cause it hase the following warning
Uses non-portal services

Can request data from non-portal services and gain additional permissions

Do someone know to what actual permissions this refers and if its possible to remove them through Flatseal or command line?

1 Like

It is because the discord flatpak does not use portals to ask for permissions to access e.g webcam and instead grants itself the permissions listed in the manifest.

You can remove them with flatseal.

1 Like

But this wouldn’t be an additional permission because its already stated in the manifest:

User device access
Can access hardware devices such as webcams or gaming controllers

But the none portal permission states that it can gain additional permissions:

Can request data from non-portal services and gain additional permissions

Do you know under which headline this is listed?
With headline I mean: Share, Socket… System Bus, Session Bus, Portals

It probably refers to device=all since that is a pretty invasive permission.

Instead of using the portals to explicitly get access e.g.,to the webcam, it has device=all, which means it doesn’t have to use the portals and can access them directly. This way it can gain additional permissions without using the portals.

For example:
Cinny (Matrix Client) has the Can request data from non-portal services and gain additional permissions flag but it doesn’t has device=all

I would consider this additional, although its not optimal.
Because then every app that has unessary permission that could be tight by using portal should have this flag.
A great example is filesystem=host which is extremely invasive but can simply be avoided by using portals or at least working with custom paths.

But it seam that this flag means somethign different then just having to much permissions.