Ask HN: Why does Zoom Desktop examine all processes and arguments?
Looking at syscalls, I see Zoom desktop reads all processes and arguments.
[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
...
276 comments
[ 3.7 ms ] story [ 280 ms ] threadThis is enough for me to remove the app and just use it in the browser.
dtruss
Sadly it's a little more involved (a chroot which removes all codesigning bits) than a simple option, but I'm glad to have found a way to do it all.
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...
Thank you. These will make for some interesting reading.
(Of course, the greater part of this damage is done by upvoters, but they can't upvote nothing.)
https://news.ycombinator.com/newsguidelines.html
With X11 if the window manager doesn't have the relevant support you can always ask the server.
One can argue about the granularity, but you can’t argue that Apple hasn’t already done something.
I already granted this permission to Teams on my Mac. It's not malicious now, but when an update comes out in the future, it could be, and I've already allowed it. So this whole thing feels kinda dumb. Nobody wants to manage all this shit, and nobody understands it.
The solution is partly for applications to limit their use of elevated privileges which we can't always rely on. Therefore MacOS is exposing and providing users with visibility and choice.
The user chose to install an application, then had to use admin permissions to choose to give that application more access after installation.
How much additional nanny protection should a user get?
Also, screen-sharing can't be the reason, because X windows don't have anything to do with processes on the machine.
That is quite a difference from broadcasting the name of any binary it recognises.
https://github.com/simmsb/discord-emacs.el
Put it into it's own namespace, and only allow it to connect to your X11 session over TCP.
[1] https://www.redhat.com/sysadmin/pid-namespace
Use a flatpak
Maybe run it in a chroot?
Hook the stat, openat, readlink functions within the zoom process, experiment with blocking (returning failure) based on arguments.
They recover the app from your backups if available when launching. Try appCleaner or something like that, and you might need to delete it from any TimeMachine backups too, lol
Their attitude is so wrong. I don't understand how people still use it.
When you click on a Zoom meeting, it will prompt you to launch xdg-open -- cancel it. Then hit launch again -- cancel the xdg-open again -- and then the "Join from browser" link should pop up after a few times.
Sometimes it tries to capture you, I had to click on trucks and trains for 15 minutes before it let me in, and then had to apologize for being 15 minutes late to the meeting.
By all means, use it if you feel it's necessary, but you're giving up a lot!
Figure out which one you want; Zoom is unwilling to give you both, even when you're paying them.
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.
Although I nearly universally would be happy to skip those meetings, so…
- Resort to use Zoom in a browser, maybe from a separate profile
- If this does not work for you, use Zoom from a virtual machine (it should be possible by exporting the camera likely connected by USB to the VM)
- If you'd like to avoid a VM because it's heavy / annoying, I'm not sure there's an easy solution without learning how to use namespaces and unshare.
Additionally, and optionally:
- Gently campaign against Zoom or for a better solution internally.
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.
That said, a fair number of folks don't credibly have "security analysts". Unless you are interviewing / working for some sort of high security / security analyst type job the world may move on pretty quickly without you.
Exploits tend to leak...
I used to interview candidates via Zoom. There were quite a few who couldn't figure it out. I gave 2nd chances interviews, mostly for optics for upper management. (And because sometimes hardware breaks at the last minute.) The candidates always failed the retry interview.
At least for software development, troubleshooting a camera and mic is a pretty similar skill to what our job is on a day-to-day basis. It's also very disrespectful to make someone wait at the beginning of a meeting while you troubleshoot, especially when I'm waving my phone and sending IMs that ask the candidate to just use their phone.
But, if a candidate fell back to their phone, I appreciated that they respected my time.
It's also not that difficult to click in and to the test audio / test video features. I still do that (sometimes just to check a virtual background etc).
So yeah, if you are going to always be saying it's too hard or you can't get into zoom (ie, for "security" reasons) that may be a dealbreaker.
[0] https://techcrunch.com/2020/06/11/zoom-admits-to-shutting-do...
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.
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.
I did take at their privacy policy and didn't see anything that explicitly states they are collecting info about running applications. "and other" leaves room for interpretation... Regardless, my main concern after viewing this isn't that they are snooping my running processes and sending that back to home base. Its that they are openly keylogging and tracking everything under the sun, and can view every aspect of the meeting's content (audio, video, text, etc) and share it with 3rd parties like law enforcement and others.
Source: https://zoom.us/privacy#_qhklx843v2zq
> Device Information: Information about the computers, phones, and other devices people use when interacting with Zoom Products, which may include information about the speakers, microphone, camera, OS version, hard disk ID, PC name, MAC address, IP address (which may be used to infer general location at a city or country level), device attributes (like operating system version and battery level), WiFi information, and other device information (like Bluetooth signals).
> Meeting, Webinar, and Messaging Content and Context: Content generated in meetings, webinars, or messages that are hosted on Zoom Products, which may include audio, video, in-meeting messages, chat messaging content, transcriptions, written feedback, responses to polls and Q&A, and files, as well as related context, such as invitation details, meeting or chat name, or meeting agenda. Content may contain your voice and image, depending on the account owner’s settings, what you choose to share, your settings, and what you do on Zoom Products.
> Product and Website Usage: Information about how people and their devices interact with Zoom Products, such as: when participants join and leave a meeting; whether participants sent messages and who they message with; performance data; mouse movements, clicks, keystrokes or actions (such as mute/unmute or video on/off), and other user inputs that help Zoom to understand feature usage, improve product design, and suggest features; which third-party apps users add to a meeting or other Product and what information and actions the app is authorized to access and perform; features used (such as screen sharing, emojis, or filters); and other usage information and metrics. This also includes information about when and how people visit and interact with Zoom’s websites, including what pages they accessed, their interaction with the website features, and whether or not they signed up for a Zoom Product.
You can explain away any deliberate malice or negligence using it, even when there are clear incentives to enage is such behavior, unless there's absolute evidence of malice. By then it's too late because you've already been swindled, and the principle ignores the lengths organizations will go to cover that evidence up.
https://news.ycombinator.com/item?id=21691282
That's a really stupid way to figure out if a program has a window, though, compared to just using the X11 API directly.
But again: extraordinarily unlikely.
1. The windows manager can provide you with a list of open windows.
2. Screensharing including only sharing specific windows is a feature provided by the windows manager over standardized protocols.
3. Even knowing the processes which do have a GUI doesn't allow you to share that GUI, at least not without going through roughly the same mechanisms as mentioned in 2nd.
Here is a company that does censorship-resistant P2P networking...and also....Nuclear Material Detection?
Obviously very closely related things?
https://www.clostra.com/newnode-mesh-network https://www.clostra.com/nuclear-detection-snm
Are they spying on your Azure servers? Unlikely, they make hose reels and related round metal things.
Sometimes little (or big) companies like that get involved in weird lines of business because they buy other companies for the contracts.
But that needs a unified way for this across window managers, does that exist?
[0] https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.h...
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.
E.g. "Wayland is, that they have no such API.", it has screen sharing APIs but they are different and require you do go through other programs like XDG Desktop Portal and Pipewire to allow the user to control such access. Similar this also means Wayland supports screen sharing just in different ways.
Anyway the important parts are:
- the implementation might differ, but the API doesn't (or at least not by a relevant degree)
- wayland requires you to go through specific APIs for screen sharing, scanning processes has little to do with screen sharing on either wayland or X.
I don't think I'd agree that having to go through dbus and pipewire just to get the contents of the screen or a window is far superior to requesting that data from the display server. It certainly adds a lot of complexity with subpar documentation spread across multiple projects. Does this provide you a compressed stream or can you get the raw pixels that are displayed?
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...
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.
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.
Don't forget Hanlon's razor, as someone else in the thread pointed out.
If you say that there's an similar API on Linux for X11, then that's the same methodology across platforms.
BUT there are standardized protocols/APIs for screen sharing including screen sharing of just a window. And you won't get far without using them so also no reason to scan processes.
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.
To be honest, I'm actually surprised and impressed that they support screen share in the Linux version because of how many different flavors of i.e. WM there are in the wild.
Now, using Wayland it may or may not be possible, depending on which WM/compositor/whatever you are running.
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.
I prevent it by running Zoom in a VM on Qubes OS.
Do what I do: Run it on a burner computer connected to your guest network.
Unfortunately, sound and camera tend to be sketchy in a VM.
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.
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.
Also, we’re trialing big blue button (self hosted) as an alternative, and it’s honestly pretty decent from what I can tell.
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.
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.
Serious question - if the experience is the same, why does this distinction matter?
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.)
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.
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
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.
It might have been Snap. I don't like Snap.
I use both these days.
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
Shoshanna Zuboff has an excellent book on "surveillance capitalism", if you want to read more on the trend.
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.
I actually do that all the time. My main "work environment" is TTY0 with i3wm, but when I make nice videos/screencasts, or use Zoom for presentations I often switch to a clean and neat KDE Plasma session on TTY1.
During that time I often had a "IntelliJ" only instance of X running in some TTY1, some other WM or just a raw TTY on TTY2 and a maybe crashing WM I was playing around with on TTY0 ;-)
Fun times.
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...