5 ms·

> Is there any way to prevent it? Mounting /proc with "hidepid=2" should prevent it from seeing processes owned by other users, although it would still be able

> Is there any way to prevent it? Mounting /proc with "hidepid=2" should prevent it from seeing processes owned by other users, although it would still be able to see your processes. Alternatively, it shouldn't be too hard to create an AppArmor profile that blocks access to /proc. Other options might include things like SELinux, seccomp-bpf, namespaces, cgroups, etc., depending on what's available on your host. Or you could just, you know, obliterate it from your system altogether. That's almost certainly the best option.

hdjjhhvvhga 5y ago
I don't understand why anyone who is forced to use it doesn't use it in a browser (I have a separate Firefox container for that, same for Teams).
- vbernat 5y ago
  For me: more CPU usage (and more battery usage), not able to see other participants when sharing screen. But I am running Zoom in a Flatpak to avoid the kind of issues reported here. BTW, the same happens with Discord and it's not possible to disable it.
  - rocqua 5y ago
    Discord does it to detect which game you are running, so it can display "user is playing X" to your friends.
- avel 5y ago
  The browser edition of zoom lacks a lot of features and also lacks in performance. It's not like BlueJeans which has a web version pretty much aligned with the desktop client.
  - maxk42 5y ago
    That's what they're counting on.
  - christophilus 5y ago
    Unless you’re using Zoom all day, the browser version is just fine. Folks can see and hear me; I can see and hear them; I can share my screen. It’s good enough. Also, we’re trialing big blue button (self hosted) as an alternative, and it’s honestly pretty decent from what I can tell.
- GekkePrutser 5y ago
  Does teams work for your in a FF container? For me it always ends up in a redirect loop :( but my work uses MCAS for external computers so that may have to do with it. It's a proxy service from MS that adds some supposed security to their services and makes them even slower.
  - nsomaru 5y ago
    With containers, subdomains and redirects I’ve found switching off network and forcing each subdomain to open in a particular container 1-by-1 to work well.
  - hdjjhhvvhga 5y ago
    Teams seems to work normally in a container for me but I realized even though I have it open all day... I just use chat, not video/audio calls. I tried to call someone yesterday and it turned out Microsoft says they don't support FF and I have to use Edge or Chrome (or the app, preferably, of course). This is not a problem with the container itself, though. Interestingly enough, when I asked my colleague call me, they didn't receive any feedback message - it was as if I was not responding to their call. Another lame thing on the part of MS as it could introduce (potentially never verbalized) problems into communication.
- zippergz 5y ago
  The people here who are saying "Teams and Meet are just as good" are the people who use Zoom in a browser. The audio and video quality, and resilience to poor connections, is much better in the desktop app.
  - eertami 5y ago
    >The audio and video quality, ... is much better in the desktop app But is the quality actually better, or is it post-processing tricks to make it seem better on commodity hardware/audio setups? If it is actually better, surely this should be measurable and there should exist evidence to support such a claim.
    - scubbo 5y ago
      > is the quality actually better, or is it post-processing tricks to make it seem better Serious question - if the experience is the same, why does this distinction matter?
      - hdjjhhvvhga 5y ago
        Usually postprocessing requires significant computing power. This is something that might matter for people maximizing battery usage. But another person in the same thread says in the case of Zoom it's the opposite - the web app seems more CPU-intensive.
        scubbo 5y ago
        That's a helpful perspective that I hadn't considered, thank you!
      - eertami 5y ago
        Because if I have good hardware the post-processing isn't going to make it sound any better, I'm better off with the source.
    - neurostimulant 5y ago
minitech 5y ago
> Mounting /proc with "hidepid=2" should prevent it from seeing processes owned by other users Note that this isn’t a supported configuration for systemd and will totally break it. (Which is too bad, because it’s a sensible default.)
_Algernon_ 5y ago
Wouldn't using it through the browser prevent this?
nonameiguess 5y ago
You can edit /usr/share/applications/Zoom.desktop to run inside of bubblewrap, similar to how the Arch Wiki suggests doing this for Skype: https://wiki.archlinux.org/title/Bubblewrap#Skype_for_Linux https://wiki.archlinux.org/title/Bubblewrap#Skype_for_Linux Since this puts it in its own PID and mount namespace, it won't see any processes except itself and its children. You can even try not mounting /proc in the container this makes at all and see what happens. This is effectively what flatpak does, but doing it yourself doesn't require installing flatpak.
- ghostpepper 5y ago
  This is very cool. I was going to suggest running it inside a container/namespaces but I didn't know about bubble wrap.
- neurostimulant 5y ago
  Does screen sharing still works with this method?

hdjjhhvvhga 5y ago

I don't understand why anyone who is forced to use it doesn't use it in a browser (I have a separate Firefox container for that, same for Teams).

vbernat 5y ago
For me: more CPU usage (and more battery usage), not able to see other participants when sharing screen. But I am running Zoom in a Flatpak to avoid the kind of issues reported here. BTW, the same happens with Discord and it's not possible to disable it.
- rocqua 5y ago
  Discord does it to detect which game you are running, so it can display "user is playing X" to your friends.
avel 5y ago
The browser edition of zoom lacks a lot of features and also lacks in performance. It's not like BlueJeans which has a web version pretty much aligned with the desktop client.
- maxk42 5y ago
  That's what they're counting on.
- christophilus 5y ago
  Unless you’re using Zoom all day, the browser version is just fine. Folks can see and hear me; I can see and hear them; I can share my screen. It’s good enough. Also, we’re trialing big blue button (self hosted) as an alternative, and it’s honestly pretty decent from what I can tell.
GekkePrutser 5y ago
Does teams work for your in a FF container? For me it always ends up in a redirect loop :( but my work uses MCAS for external computers so that may have to do with it. It's a proxy service from MS that adds some supposed security to their services and makes them even slower.
- nsomaru 5y ago
  With containers, subdomains and redirects I’ve found switching off network and forcing each subdomain to open in a particular container 1-by-1 to work well.
- hdjjhhvvhga 5y ago
  Teams seems to work normally in a container for me but I realized even though I have it open all day... I just use chat, not video/audio calls. I tried to call someone yesterday and it turned out Microsoft says they don't support FF and I have to use Edge or Chrome (or the app, preferably, of course). This is not a problem with the container itself, though. Interestingly enough, when I asked my colleague call me, they didn't receive any feedback message - it was as if I was not responding to their call. Another lame thing on the part of MS as it could introduce (potentially never verbalized) problems into communication.
zippergz 5y ago
The people here who are saying "Teams and Meet are just as good" are the people who use Zoom in a browser. The audio and video quality, and resilience to poor connections, is much better in the desktop app.
- eertami 5y ago
  >The audio and video quality, ... is much better in the desktop app But is the quality actually better, or is it post-processing tricks to make it seem better on commodity hardware/audio setups? If it is actually better, surely this should be measurable and there should exist evidence to support such a claim.
  - scubbo 5y ago
    > is the quality actually better, or is it post-processing tricks to make it seem better Serious question - if the experience is the same, why does this distinction matter?
    - hdjjhhvvhga 5y ago
      Usually postprocessing requires significant computing power. This is something that might matter for people maximizing battery usage. But another person in the same thread says in the case of Zoom it's the opposite - the web app seems more CPU-intensive.
      - scubbo 5y ago
        That's a helpful perspective that I hadn't considered, thank you!
    - eertami 5y ago
      Because if I have good hardware the post-processing isn't going to make it sound any better, I'm better off with the source.
  - neurostimulant 5y ago

minitech 5y ago

> Mounting /proc with "hidepid=2" should prevent it from seeing processes owned by other users Note that this isn’t a supported configuration for systemd and will totally break it. (Which is too bad, because it’s a sensible default.)

_Algernon_ 5y ago

Wouldn't using it through the browser prevent this?

nonameiguess 5y ago

You can edit /usr/share/applications/Zoom.desktop to run inside of bubblewrap, similar to how the Arch Wiki suggests doing this for Skype: https://wiki.archlinux.org/title/Bubblewrap#Skype_for_Linux https://wiki.archlinux.org/title/Bubblewrap#Skype_for_Linux Since this puts it in its own PID and mount namespace, it won't see any processes except itself and its children. You can even try not mounting /proc in the container this makes at all and see what happens. This is effectively what flatpak does, but doing it yourself doesn't require installing flatpak.

ghostpepper 5y ago
This is very cool. I was going to suggest running it inside a container/namespaces but I didn't know about bubble wrap.
neurostimulant 5y ago
Does screen sharing still works with this method?