Hacker News Reader

Comment by jlgaddis | Hacker News Reader

> 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.

View on HN

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

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.

This is very cool. I was going to suggest running it inside a container/namespaces but I didn't know about bubble wrap.

Does screen sharing still works with this method?

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).

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.

Discord does it to detect which game you are running, so it can display "user is playing X" to your friends.

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.

That's what they're counting on.

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.

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.

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.

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.

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.

>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.

> 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?

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.

That's a helpful perspective that I hadn't considered, thank you!

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.

You can test it by throttling your network speed down from your router and compare the desktop and web version performance. The desktop version will sacrifice video quality (to the point of stuttering on very low bandwidth) in order to maintain audio quality, which massively increase usability on poor network condition.

All the times I've used Zoom on browser the recent year didn't have any problem.

> 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.)

Wouldn't using it through the browser prevent this?

Reply on news.ycombinator.com