81–90 of 277 posts
> Is there any way to prevent it? Firejail[0] allows cobbling together various linux sandboxing features, including namespaces which should result in an isolated proc filesystem which doesn't see the other processes. But I don't know if the default profile for zoom does that, you have to test it or write your own. [0] https://github.com/netblue30/firejail
> Is there any way to prevent it? Firejail[0] allows cobbling together various linux sandboxing features, including namespaces which should result in an isolated proc filesystem which doesn't see the other processes. But I don't know if the default profile for zoom does that, you have to test it or write your own. [0] https://github.com/netblue30/firejail
Earlier quoted context omitted.
There’s nothing in /proc/PID/cmdline etc that would definitely confirm an app has a GUI. The two concepts are at very different layers of the stack — to the OS the GUI is just another app on top of the kernel. Mayyyyyybe Zoom could be doing some crude pattern matching on process name or environment variables of a given process (though it’d only be able to read data of processes running as the same user) but it’s a lo…
This is an unlikely stretch, but it looks like they're also attempting to read `/proc/PID/exe` -- they could be doing something (extremely) cursed like attempting to parse the program linkages and filtering by programs that link to `libX11`. But that's me straining to explain this in the context of the GP's hypothesis.
I can easily believe somebody just wrote a chunk of naive code that grabbed all the running processes, and it worked, and they moved on.
Earlier quoted context omitted.
"Zoom does not work on my computer*, can we try X instead?" With X = something the other end does not need to install, like Jitsi Meet for instance *no need to explain that's because you uninstalled it and blocked its domain on your computer.
A bit difficult when your org has decided to use Zoom for large meetings. Although I nearly universally would be happy to skip those meetings, so…
Earlier quoted context omitted.
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).
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.
Shoshanna Zuboff has an excellent book on "surveillance capitalism", if you want to read more on the trend.
> 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…
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.)
Earlier quoted context omitted.
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).
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.
Also, we’re trialing big blue button (self hosted) as an alternative, and it’s honestly pretty decent from what I can tell.
> 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…