[pid 3844872] stat("/proc/1", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid 3844872] openat(AT_FDCWD, "/proc/1/stat", O_RDONLY) = 4
[pid 3844872] openat(AT_FDCWD, "/proc/1/cmdline", O_RDONLY) = 4
[pid 3844872] readlink("/proc/1/exe", 0x20c0520, 1024) = -1 EACCES (Permission denied)
[pid 3844872] stat("/proc/2", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid 3844872] openat(AT_FDCWD, "/proc/2/stat", O_RDONLY) = 4
[pid 3844872] openat(AT_FDCWD, "/proc/2/cmdline", O_RDONLY) = 4
[pid 3844872] stat("/proc/3", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid 3844872] openat(AT_FDCWD, "/proc/3/stat", O_RDONLY) = 4
[pid 3844872] openat(AT_FDCWD, "/proc/3/cmdline", O_RDONLY) = 4
...
Personally I’d guess it is either some other library Zoom uses or some kind of debug info capturing system. But I don’t know work at Zoom so who knows.
This probably explains why, when i try to screenshare a single application window, not every application shows up! I can share my browser, file manager, and various other things, but not windows for games started by Steam.
[1] I followed these instructions https://www.mayrhofer.eu.org/post/zoom-flatpak-sandboxing/
It makes me wonder how Things like Steam streaming and Paperspace get around the issue.
But that doesn't work for non-X11 or if the WM is non-EWMH compliant. Presumably Wayland has a similar API, and non-EWMH is probably a minuscule group that considers this a desirable feature.
One of the downsides this has is the described issue of "screensharing beeing impossible on wayland". This is solved by the XDG Desktop Portal, which provides a unified dbus interface across the different compositor implementations for requesting a pipewire file descriptor (which can be used with gstreamer to get a live video stream of the deskop, in a way far superior to x11 framegrab). However the implementation differs for each compositor, GNOME for example asks you if you what to share the whole screen or just a specific application but wlroots (swaywm, wayfire, etc.) AFAIK automatically accepts and shares the whole screen. I don't know what KDE Plasma does.
Yes there is a wayland extension for screen sharing and also support for sharing just one application.
It provides screen sharing on KDE, Gnome and most wlroots based WMs.
Through wlroots doesn't yet (or maybe does by now) support sharing a specific window I think, but this mean it doesn't support sharing a specific window and knowing which process belongs to a window doesn't really help you there either...
That's definitely not a cross-platform way of doing it (and I doubt there is one, even).
On Linux you'd use libX11 and just enumerate all windows (using XQueryTree()). Walking the contents of /proc is not only unnecessary, but is more difficult to do, as looking at executable names won't tell you if a program has a GUI, or if it has any open windows. It won't give you window titles, or how many windows are open, or how to grab their contents.
Pretty sure Zoom is snooping on us and is gathering telemetry.
If you say that there's an similar API on Linux for X11, then that's the same methodology across platforms.
Don't forget Hanlon's razor, as someone else in the thread pointed out.
When you share a single window in Zoom, notifications are still visible to others in the meeting when they overlap with the window you're sharing. That's the case for e.g. Slack notifications.
Caveat being if you move the window around really fast sometimes it’s possible to catch a glimpse.
Hm, I don't think that is the case for Gnome/GTK as pipe wire should grab the image before it's composed as far as I know.
But I can't check as I'm running sway which (I think, haven't checked for a while) doesn't yet support single window screen sharing.
The screen sharing functionality is handled by a mix of protocols of the windows manger and service providers announced over dbus.
Even if you want to map GUI windows to processes you would do so by getting a list of windows from the window manager and getting the pid property of the windows, but if you have a list of windows you don't need to scan processes anymore...
There might (I'm not sure) be valid use-cases for this behaviour but I'm pretty confident screen sharing of specific windows isn't part of 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.
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.
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.
It's not like BlueJeans which has a web version pretty much aligned with the desktop client.
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.)
I should have known better.
I am glad this is getting posted because we need reminders of the reality we live in
One can argue about the granularity, but you can’t argue that Apple hasn’t already done something.
Also, screen-sharing can't be the reason, because X windows don't have anything to do with processes on the machine.
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.
Zoom is very invasive / flexible - so it's actually somewhat hard to have it NOT work. People will suggest you try connecting on your phone or dialing in if you really can't figure it out (note that it has a fallback to browser option if you get stuck trying to start meeting as well).
I know of at least one job interview where they claimed they couldn't get zoom to run / couldn't connect - and that was basically decisive.
Although I nearly universally would be happy to skip those meetings, so…
By all means, use it if you feel it's necessary, but you're giving up a lot!
[0] https://techcrunch.com/2020/06/11/zoom-admits-to-shutting-do...
You can use hidepid=2 to prevent users from seeing other user's processes list.[1]
But I don't want my OS to ask me "do you want to allow htop to access the list of your processes" — à la Windows Vista — every time I want to run htop to see my user processes.
The issue here is closed source software with no way to inspect what they do.
If one really want to run closed source programs which were not vetted by their distro's maintainers, they should use firejail.[2]
[1] https://www.cyberciti.biz/faq/linux-hide-processes-from-othe...
Why would it be every time? Say yes once to htop, no to Zoom. Sort of like Android/iOS permissions.
Or just require root. No way I'd give it to Zoom, htop maybe.
STOP DOING THAT.
Put it into it's own namespace, and only allow it to connect to your X11 session over TCP.
(Of course, the greater part of this damage is done by upvoters, but they can't upvote nothing.)
Zoom banned from New York City schools due to privacy and security flaws https://www.fastcompany.com/90486586/zoom-banned-from-new-yo...
Google Told Its Workers That They Can’t Use Zoom On Their Laptops Anymore https://www.buzzfeednews.com/article/pranavdixit/google-bans...
Elon Musk's SpaceX bans Zoom over privacy concerns https://www.reuters.com/article/us-spacex-zoom-video-commn/e...
Zoom lied to users about end-to-end encryption for years, FTC says https://arstechnica.com/tech-policy/2020/11/zoom-lied-to-use...
Zoom security issues: Here's everything that's gone wrong (so far) https://www.tomsguide.com/news/zoom-security-privacy-woes
Maybe we shouldn’t use Zoom after all https://techcrunch.com/2020/03/31/zoom-at-your-own-risk/
Attackers can use Zoom to steal users’ Windows credentials with no warning https://arstechnica.com/information-technology/2020/04/unpat...
Do what I do: Run it on a burner computer connected to your guest network.
That article claims that Zoom does have a feature allowing hosts to see whether people have the zoom window focused while someone is presenting, but it doesn't allow the host to actually see running processes. Note that I can't, nor do I claim to, vouch for the accuracy of the explanation in the link. Just something I found.
It used to but it was removed.
https://support.zoom.us/hc/en-us/articles/115000538083-Atten...
We can answer part of that with just a little more reading. What's pid 3844872?
For me, the series of queries against /proc happen from a process that, just a bit earlier, called exec. So it's not really zoom reading "all processes and arguments" but ... `pidof gnome-session`, so I guess zoom is looking for the pid of gnome-session.
To what nefarious purpose zoom intends to put this knowledge of gnome-session's pid, I can't say - I am not running gnome-session so my trail goes cold; but at least for me, for that particular run, zoom itself doesn't actually see the contents of all of those files.
I installed the Zoom client just to have a look for myself. The syscalls in question emanate from freshly forked processes that immediately execvp() the command `pidof` (on my system it finds it under /usr/bin, so it's the system command, not anything fishy shipped by Zoom). Actually, the command-line argument to the command is, in succession:
gnome-session
gnome-panel
gnome-shell
gnome-session-binary
ksmserver
cinnamon
cinnamon-session
mate-panel
mate-session
xfce-mcs-manage
xfce4-panel
xfce4-session
I suppose Zoom goes through the whole list on my system because it finds none of them. The fact that it stops on parent's system suggests that Zoom stops when it finds one. This hints at a very crude way to determine the desktop environment!
https://stackoverflow.com/questions/3376679/qt-how-to-detect...
That is a good discovery.
It's probably one of the better ways to detect the running desktop environment as the user might have multiple environments installed and just uses one of them currently, as such looking for installed things doesn't work reliable.
And looking for env variables can be unreliable.
And scanning the dbug might not be that use-full either.
But I'm not sure what they use that for. (Notification daemon selection? But that wouldn't be that reliable either, theaming? I dubt it.)
But I guess even if it's just for telemetry it would be a reasonable thing to do.
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.
Goes to show how little people trust Zoom.
I didn't like that, and I spent a lot of time and effort working out various ways to keep it out of /proc (or anywhere else while I was at it- mostly with AppArmor) and ultimately ended up running it in a container with systemd-nspawn. This is still a little bit fiddly, but seems to work reliably and without any issues.
Another angle for Zoom to do that, is that it is a massive Chinese spyware application, which can target users by meta data or IP, like it did by messing with the calls of activists. A bit like how anti-virus companies are sometimes charged with exfiltrating secret documents.
https://support.zoom.us/hc/en-us/articles/115000538083-Atten...
> As of April 2, 2020, we have removed the attendee attention tracker feature as part of our commitment to the security and privacy of our customers. For more background on this change and how we are pivoting during these unprecedented times, please see a note from our CEO, Eric S. Yuan.
I once worked on a file synchronization application that would scan processes when files were locked. I don't remember if we put the process name in the UI, but we logged detailed information about the other process in case someone contacted support. (Sometimes users ran weird applications that kept files locked.) I believe we had to scan through all processes and inspect their open file handles.
I would assume some things like: Maybe there are applications that are known to cause problems for Zoom? Maybe some applications lock the camera or microphone? Maybe some applications hog the CPU and cause encoder problems?
If you really want to know more, consider decompiling zoom and/or looking at strings compiled into the binary.
IMO, if you can't/won't reverse engineer, maybe see if you can contact Zoom support and see what they say? Obviously the support people won't know, but if you can ask the right way they might pass your question on to the developers.
For the file sync client, we got all kinds of oddball questions passed along from support to developers; and we'd make an honest effort to answer reasonable ones.
I prevent it by running Zoom in a VM on Qubes OS.
This is enough for me to remove the app and just use it in the browser.
Hook the stat, openat, readlink functions within the zoom process, experiment with blocking (returning failure) based on arguments.
Shoshanna Zuboff has an excellent book on "surveillance capitalism", if you want to read more on the trend.
Use a flatpak
Zoom is probably footholding their place as to be able to inform its educator whether their students’ behavior are acceptable or are cheating.
Most probably.
But some of the info its reading seems a little bit too much
cough 'telemetry' cough
You'd have to be crazy to install Zoom given their history.
Maybe run it in a chroot?
Stop using non-free software if you're doing anything important on that machine.
You can probably prevent it with capabilities, or selinux, or with a container. Unless you just enjoy the fashion statement of tinfoil hats, it's not worth it.
But if you really must, use the web version only.
If you can avoid it, jitsi is a great alternative. Much smoother video than teams and much lighter