Ask HN: Why does Zoom Desktop examine all processes and arguments?
Ask HN: Why does Zoom Desktop examine all processes and arguments?
544 points by
neolog 3 days ago |
hide |
past |
favorite |
262 comments 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
...
Why would it do that? Is there any way to prevent it?
Zoom has a popular feature which allows for screen sharing a single application window instead of the entire desktop. I assume this is how its discovering running applications with GUI windows open in a cross-platform manner. Perhaps there is a better API for this? Its not a common use-case that an app would need to know all of the other open windows, but it seems like a perfectly valid use case, and frankly handy for sharing a PPT without fear of an embarrassing email showing up in during a meeting.
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 long shot.
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 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.
Why would you implement such a overly complex and unreliable thing when:
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.
The windows manager can provide you with a list of open windows.But that needs a unified way for this across window managers, does that exist?
I don’t know but xkill works across WM
Let's just say the quiet part outloud: they sell that data.
They probably don't. The list of programs running on a random Linux box probably isn't especially valuable.
That machine can be in a Russian or Iranian nuclear physics or bioweapon lab and run very specific software. E.g. you can be looking for some project code names.
Sure. But that's a
very distinct task vs. the implication that Zoom is somehow making ad revenue off of Linux process names. The latter strikes me as not very likely because there's no money in it; the former is well outside of anything I feel qualified to opine on.
A company in my hometown makes parts for defense aerospace, the oil industry, private military contractors, and hyperscale data centers.
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.
Looks like a defense contractor to me. If you pulled two random things out of my company's roster, you could probably spin an equally suspicious narrative.
Haha. What possible market is there for knowing which other binaries Zoom (desktop) users run? OMG Zoom users also run Chrome, cat, and init! That'll be $10k please.
Nah, the readlink on exe looks like it's simply to query the real name of the executable, so that's pretty benign.
I believe they mean grab the absolute path to the real executable, run ldd against it, and parse that output to see if it links against libX11. That doesn't tell you a program is really using X11, though, as plenty have some sort of no-gui option to launch without a window. You can always cat /proc/{PID}/maps to see if libx11 is actually loaded into the process' address space, and just use readlink on exe to figure out the application name.
That's a really stupid way to figure out if a program has a window, though, compared to just using the X11 API directly.
Do you have evidence of old being executed or similar? The posted strace log section is fairly benign and shows no hints of what you insinuate.
Nope, and I'm not going to run zoom to find out. To be perfectly clear, I'm not at all trying to say I have evidence that this is what zoom is actually doing. I'm trying to say I believe this is what the upper-level post was suggesting zoom is doing.
You wouldn’t actually need to execute `ldd` to get this information: you could parse the ELF entirely in user space. That, in turn, wouldn’t show up in the `strace` logs, since there would be no syscalls. I think that’s extremely unlikely, but it’s certainly possible.
Reading the file would show up as syscalls.
Sure, but you could minimize it to just two: the `open` that we already see here, and an `mmap` that maps the entire thing in. The rest could be in userspace (at least in terms of effects). We only have an excerpt of the syscall trace, so it's possible that happens.
But again: extraordinarily unlikely.
Never attribute to malice what is adequately explained by laziness.
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 can easily believe either. However, while the default assumption of laziness/incompetence works well for good faith discussions, it also provides cover for malicious actors. At some point, even though any given actor is likely to be non-malicious, there is no way to distinguish them from the malicious actors.
Hanlon's razor is a great principle to apply to personal relationships, but it falls apart in these situations.
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.
If you're dealing with bigger threats, you need a more powerful weapon. Sheathe the Hanlon's razor, and unholster the Hanlon's handgun: "Never attribute to stupidity that which can be adequately explained by systemic incentives promoting malice."
https://news.ycombinator.com/item?id=21691282
I’d argue that laziness is worse in security/privacy situations than malicious intent. At least malicious intent only exposes me to Zoom and whoever they answer to. Their laziness, however, which would probably also reflect itself in other security situations, exposes me to them as well as basically the entire world of black hat hackers.
or it’s spyware, maybe not as bad as a keylogger, but it can be mining your active usage behavior
This could be verified by inspecting their analytics requests. If I have time I may take a peek at those later.
I wasn't able to find much of interest from their desktop client, as all of the data is encrypted and I'm not sure how to grab an SSL key from a desktop app for use in Wireshark decryption. If somebody clever wants to help, please let me know.
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.
whoever does the analysis may also become a whistleblower.
Does "whistleblower" apply to people not working directly for the company being reported? I've always understood it to be employee reporting against the employer. I could totally be limiting it from what other people use it though.
I think it's a generic definition for someone closely associated with the company to out them out something that they would like to keep secret because it would embarrass them or lead to legal redress.
I run Zoom from flatpak, which runs it in a container, and sandboxes it to some extent [1]
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/
Are you using Wayland? That might be an artifact of Steam and games running via XWayland.
As far as i know, no, it's all still pure X11. I would like to try Wayland, but i'm using Cinnamon as a desktop, and i'm not sure they work together.
Games always seem impacted in odd ways by remote desktop protocols. One game might run fine, while another is just a black screen, or an uncontrollable mouse.
It makes me wonder how Things like Steam streaming and Paperspace get around the issue.
Based on OP's snippet they're probably doing this on Linux. Assuming the presence of X11 and an EWMH-compatible window manager, they could query X11 directly and ask the root window for its `_NET_CLIENT_LIST` attribute. That, in turn, would list every "semantic" (i.e., non-decorative) window currently open on the current display.
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 selling points of Wayland is, that they have no such API. An Application is supposed to be unable to access windows (and their corresponding keyboard/mouse input).
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.
I initially miss read you post, you formulations can be a bit misleading.
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.
> which can be used with gstreamer to get a live video stream of the deskop, in a way far superior to x11 framegrab
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?
> Presumably Wayland ...
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...
>
I assume this is how its discovering running applications with GUI windows open in a cross-platform manner.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.
Windows has a function EnumWindows() to do just that.
If you say that there's an similar API on Linux for X11, then that's the same methodology across platforms.
I'm not sure there is such a API on wayland,
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.
> 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.
But I can't come up with a "stupidity" which would explain this behaviour...
> handy for sharing a PPT without fear of an embarrassing email showing up in during a meeting.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.
They are grayed out for everyone else, so they can’t actually read the contents.
Caveat being if you move the window around really fast sometimes it’s possible to catch a glimpse.
Maybe that's changed, but a couple months ago we tested it on vanilla Ubuntu in the team at $dayjob and we could see everything. Nothing was grayed out.
Sounds like it works a little differently on Linux.
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.
I don't believe that the WM would enter into it — as long as folks are using X11 the code should be, I think, the same for any WM or DE.
Now, using Wayland it may or may not be possible, depending on which WM/compositor/whatever you are running.
Zoom on Mac and/or windows seems to black out other windows if they appear on top of the target window. I've seen that happen a few times so definitely does happen, just perhaps not on Linux.
I literally quit all messaging apps when presenting to people for any period of time more than ~10s.
You could also disable notifications if your OS has that kind of feature. Mine does, so I took advantage of that after the first incident of being interrupted. It's a nice feature.
Let me introduce you to Microsoft Teams which comes with custom notifications ignoring do-not-disturb settings.
On windows?
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.
> I assume this is how its discovering running applications with GUI windows open in a cross-platform manner.
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.
Does Teams do this in the same way? They offer the same feature
Not sure about Teams, but Google Meet allow you to share a specific browser tab, I don't know how to implement it without reading all the opened tabs.
There is a JavaScript API that abstracts this, so Google Meet/whatever asked can only read the "final" video stream of what you selected and not everything that's going on, which stays in your local browser.
Teams lets you share an application window or your display(s).
Reminds me a bit of how platforms like Citrix will publish single applications. Considering you can give control to another user with Zoom I suppose it's a lot like that, although I know the underlying tech is very different.
I'm pretty sure Jitsi allows for screen-sharing a particular application so I'm curious to know how that works. Might check the source later.
Google meet running in a browser can share any application specific windows. Not sure if it also does the same thing though.
> Why would it do that?
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.
^ This is the correct answer.
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!
God damn it, why do terrible SO suggestions find themselves in every application?
Because there are no "good" suggestions? (or they are harder to find, lack documentation, etc.)
> This hints at a very crude way to determine the desktop environment!
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 mean, in principle the user might be running multiple X servers with different WMs, but that's probably rare enough. I'm also a bit curious what it's actually used for (but not quite curious enough to dig out ghidra, given the other constraints on my time at the moment...)
> I mean, in principle the user might be running multiple X servers with different WMs, but that's probably rare enough
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.
There was a time when I was playing around with programming/changing small WMs, while following Java based university stuff.
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.
I thought this thread was full of sarcasm and then I see the links.
I should have known better.
I am glad this is getting posted because we need reminders of the reality we live in
Yes there are reasons besides conflicts with US law and they not having German Servers which makes it completely GDPR in-compliant and de-facto legal unusable in the EU.
(Not that anyone seem to care.)
Well that's easy enough to defeat if oyu know of it.
Thanks a lot, its now fully trollable.
Ultrasonic sound transmission is what Cisco WebEx also claims to do. So it not something unheard of (although it is not hearable).
Any application allows remote screen recording is basically a trojan horse.
By that definition all major browsers are trojan too because they can capture screens and windows via screen capture api.
Therefore I always manually modify browser binary and rename screen capture api to something else.
I also disable WebRTC.
It's a shame Google's Blink don't offer an option to turn off features.
Its okay to do this as long as webex/zoom explicitly mentions it when you join a meeting.
Zoom has attention tracking, which when enabled silently, shows an admin if the screen is maximized or if the user is focused on other applications. They don't yet tell admins what other apps the user is active in, just whether the user is active.
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.
Oh, yuck, I didn't know this was a thing but it looks like it has since been removed:
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.
That feature got pulled last year and hasn't existed for over a year and a half now.
Perhaps a better question to ask would be "why is any process allowed to do this by default in 2021?"
Because it's a legitimate behaviour. htop needs to do this, it's literally its main feature.
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...
[2] https://firejail.wordpress.com/
> 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.
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.
The issue is that the model on Linux is different. As opposed to walled gardens, the assumption is that applications are cooperative, therefore there is no need for such "authorization systems".
The security model on Linux is based on blacklist, with solutions like firejail.
Also, what's the points of these nags? Most people will just say "OK" anyway because they want to access the features they were promised.
The issue is that this model heralds from the 60s when such problems weren't even considered.
That is a way to see it.
I see it differently, for me the main issue is the fact that people run random software that were not even vetted.
If you dnf/apt install everything from the official repos of your distro, you wont have any misbehaving apps. And that model still holds.
And as I explained, other security models don't work either. People will just whitelist the app, or click "Accept" anyway, because they want the feature now! What's the point of nagging with a modal window "your random app, that you installed from a random website on the internet, which means you really want to use this specific app, is behaving in a shady manner, are you okay with this?"
If you dnf/apt install everything from the official repos of your distro, you wont have any misbehaving apps. And that model still holds.How do you know this?
I hear this a lot, I've built packages myself, only because I needed them in a hurry. I never really went through the source code to make sure it's safe. Maybe others did, but I didn't, people installed the package, maybe they were hacked, who knows?
Just saying...
When a package lands in Debian Sid or in Fedora Rawhide, there is a group/subculture of nerds who like to inspect it and report any misbehaviour. [1] [2]
I usually do this directly on the source project, but some people in this subculture do it in their distro.
Also I'm surprised your packages landed in Debian/Fedora, because there is a review process… I'm not talking about a ppa repo or a copr repo, anybody can run that. I'm talking about packages in the official repositories. Installing software from a random ppa or copr repo is the same as curl | sudo sh, nobody vetted this.
[1] Type of bugs they report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792580
[2] https://www.fsf.org/blogs/community/who-actually-reads-the-c...
If you think of the millions of lines of code these people are just looking at, you'd have to be pretty damn good to pickup everything?
Thanks for sharing
> And as I explained, other security models don't work either. People will just whitelist the app, or click "Accept" anyway, because they want the feature now! What's the point of nagging with a modal window "your random app, that you installed from a random website on the internet, which means you really want to use this specific app, is behaving in a shady manner, are you okay with this?"
At least they get the choice? If they need something so badly they're happy to give it whatever permissions, fine, but at least they're aware and consented.
I don't know why you think nobody ever would decline, I and I assume many people do on mobile devices. Especially now that more recent (Android anyway) versions allow/require a sort of 'progressive' acquiring of permissions, prompt when it's needed and not before.
Apple & Google clearly think some people want to decline some of the time (and enough that it should be an option), or at least that it's a good way to deliver awareness.
Whitelisting htop would be a simple matter.
I think the nags discourage sketchy behavior. It makes some of the lackluster product managers think twice about unreasonable program behavior.
Because you're not supposed to be downloading random binaries from the internet and running them like some toddler on Windows or OSX would.
STOP DOING THAT.
How do you know that a program does this, without running the binary? I'd say that requires expert knowledge not available to most people.
The bar is way lower when the source is available. That they won't share the source code for a free program is also a very big red flag.
This is not the case on Qubes OS, which I use. If you care about security, can't recommend it enough.
> 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.
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_LinuxSince 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).
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.
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.
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.
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.
That's what they're counting on.
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.
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.
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.
> 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?
I'll be annoying and say if people used the FOSS alternatives we wouldn't have to be so paranoid about a tool we all use.
If I had to guess it's for screen sharing.
If so that seems like a great place for someone like Apple or Microsoft to offer an API to bolster security and privacy
OS X already requires that the user open Settings and give the app elevated permissions to be able to share the screen.
One can argue about the granularity, but you can’t argue that Apple hasn’t already done something.
Oh I don't mean to say they haven't done anything, they certainly have. I'm more wondering if there is a system-level privacy feature that they could provide (enforce?) where the system provides a screen share stream handle to only a selected window, similar to the Selected Photos functionality in iOS today.
"Doing something" seems like a really low bar when that "something" is basically useless for the intended use case.
I don’t understand your threat model.
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?
Honestly, I kind of agree with this downvoted post. The MacOS permissions prompts are starting to drive me apeshit. Average user is going to start ignoring them and just click yes to everything anyways. Just like everybody already does on their phones. Reminds me of when Windows Vista came out and they started prompting for permissions like crazy. Everybody hated it. Maybe it was just ahead of its time.
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.
They drove me so insane that I abandoned modern macOS entirely.
What's the solution then? MacOS is exposing how often these programs are requiring privileged access.
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.
Let me turn these prompts off globally. Maybe log the requests somewhere for me to review later if I so choose. I'm just going to hit "Allow" anyway.
Enumerating window handles and titles would be more suited to that. It will need that anyway to share the window. On a multi-user system, it could see processes attached to displays it has no access to.
This. It enables single-app share, instead of just capturing entire displays.
Unless I'm missing something.. all of the required information is available through the X11 protocol. Reading the command lines of the processes is unnecessary and provides data that isn't useful in the window sharing context.
This would not work on Wayland, though.
Wayland is even more strict, you ask it for screen sharing and it gives you the stream. If the compositor doesn't support screen sharing you're out of luck, there's just no way to read the contents of a window.
With X11 if the window manager doesn't have the relevant support you can always ask the server.
Zoom doesn’t support screen sharing on Wayland, except through some propriety Gnome API.
It also doesn’t run at all for me on sway, just crashes at startup.
How would that work? I would expect it to enumerate X clients, not PIDs
How come the OS doesn't provide the list instead of each app enumerating all the proecesses itself?
You're looking at the API.
Also, screen-sharing can't be the reason, because X windows don't have anything to do with processes on the machine.
> Is there any way to prevent it?
Use a flatpak
How else would they backup your command-line passed passwords and private keys for you?
I assume this is a joke comment because I have never heard of passing a private key (the contents of one, not the file name) as a command line argument. It’d be ten times worse than asking what someone’s wifi password was and being told some 40-digit hex string.
People pass private keys on command-lines, particularly with ecc crypto (because the keys are short). It's a really bad idea, but that doesn't mean it isn't sometimes done.
i.e. with 7z (7zip) you have to specify the encode password as a command line argument.
jikes
> Is there any way to prevent it?
Hook the stat, openat, readlink functions within the zoom process, experiment with blocking (returning failure) based on arguments.
> Is there any way to prevent it?
Put it into it's own namespace, and only allow it to connect to your X11 session over TCP.
If you want to prevent programs from accessing other windows, then (in addition to using its own namespace and file access) you would also need to proxy the X server, or run it in a nested X server (which does not have access to the one outside).
Specifically, Xephyr is generally the go-to option, although there are others.
I think only Wayland has real security, X11 lets you do anything
Does that prevent it from reading from `/proc`?
In a PID namespace [1], it will be able to read /proc, but will see nothing interesting other than a strangely empty system. The process is isolated from the rest of the system as far as processes and PIDs are concerned.
[1] https://www.redhat.com/sysadmin/pid-namespace
For a more general solution, 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
AUR has a package for "zoom-firejail" which ships zoom binaries with a ready-made configuration and .desktop for launching it in firejail.
Goes to show how little people trust Zoom.
Just checked the default profile and it looks sufficiently isolated
SELinux being another. Smack too, if people still use that.
(incompetence here) Maybe it's like discord, it does the same to display messages like "$username is playing terraria right now"
Discord leaks which apps you're using to other people?
It “leaks” which apps you’re using if the developer explicitly talks to the discord client. Discord provides an SDK for game developers etc which can talk to discord client and show the game you’re playing and optionally let you invite people to your lobby straight from the discord chat. It doesn’t scan anything or open any processes, it just opens an IPC socket.
I think it does scan your processes. If I go to "User Settings " => "Activity Status" => "Not seeing your game? Add it!" => "Select" then I see many processes that almost certainly have no explicit discord integration. I believe they do this to allow the user to opt into showing their status based on running processes so that any application can be supported.
Yeah, it scans processes but seems to limit sharing what you are running to what it thinks are games unless you explicitly add the application. Still, anyone concerned about privacy should really sandbox these proprietary applications or just use the web version.
It also scans processes. Easy to check: run opensnoop.
So does Steam. It’s... a little creepier when it’s taken beyond “advertise which games you’re playing so your friends can potentially join you”, though.
Steam only does this when you launch an app through steam and only when it is enabled though.
That is quite a difference from broadcasting the name of any binary it recognises.
Are you sure? I think steam only does it for programs launched through it.
Not leaks, proudly announces!
That was the part that bothered me.
Yeah, I highly recommend disabling it.
I'm going to assume this happens when you
aren't trying to share your screen.
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.
It happens right at startup, and is a result of some calls (via the usual fork/exec dance) to `pidof ...` seemingly trying to identify the window manager being used, possibly for telemetry or possibly to change behavior. Decompiling would be more certain (I don't have ghidra on this computer and it's a little more effort than I want to go to) but the pattern is pretty visible in the strace dump.
Maybe it has to alter behavior based on your distro?
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.
Not a bad thought, though ghidra would be more fun.
>
Is there any way to prevent it?Do what I do: Run it on a burner computer connected to your guest network.
Hah! Only a fool would run it outside of a completely sound-isolated windowless underground faraday cage. Otherwise The Men In Black will find out about your blockers in your stand-up meeting!
I'm more worried about our jokes.
Jokes aside, you can probably get close to that by running Zoom in a VM with NAT.
Unfortunately, sound and camera tend to be sketchy in a VM.
Your crap is being exfiltrated.
Stop using non-free software if you're doing anything important on that machine.
Polling for all processes is the technique used by some educators’ quiz/test/exam program.
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.
I can only think the most direct usage for this info is to feed the performance screen/tab that lives in settings showing CPU and memory usage
But some of the info its reading seems a little bit too much
cough 'telemetry' cough
I've used the method of scanning the environment variables of other processes to find the PID of certain applications which advertised themselves using their environment variables. This could be similar?
> Is there any way to prevent it?
I prevent it by running Zoom in a VM on Qubes OS.
Or just run it in a browser...
Can you run it in a browser without an account?
If the meeting is open (join by invite link), yes. It's basically how Zoombombing happens.
The way to prevent it is to not install their poorly engineered spyware and only use the sandboxed web app.
You'd have to be crazy to install Zoom given their history.
So should I move it to docker? Since X11 socket will be shared, I'm assuming screen sharing might work
And for people giving ways to prevent it, can you please provide some context for those of us who aren't OS experts?
"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.
Be careful with this. In some orgs you can get a bit of a bad reputation for being technically incompetent if you can't get zoom to run.
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.
> 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.
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.
Yeah - the problem is now zoom is a skill you basically need - if you can't use a computer / zoom, it can be hard to make the remote work thing work.
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.
You can avoid this reputation by saying “our security analysts block Zoom because they think it might be untrustworthy spyware.”
That's def a better response then I can't figure out how to call into the zoom call!
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.
Yes, this excuse doesn’t work for personal calls and interviews, but most of my vendors seem to understand.
I resorted to using all modern video call software on my iPhone for that reason. I also get better camera quality so there's that. Apple Handshake also makes it relatively easy to share links.
After Pegasus, I'm not sure it's a secure solution.
Apples to oranges. Public companies aren’t going to use exploits to break the sandbox. Zoom on desktop installs all sorts of daemons that I don’t want; on iOS it can’t.
> Public companies aren’t going to use exploits to break the sandbox.
Exploits tend to leak...
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…
Use the work laptop. Its security is then their problem, not yours. Do I care if the Chinese government know that I've got Visual Studio open?
They are picky about making sure everyone uses a camera.
Then I guess your IT department or your management is happy to share your work computer's content with Zoom. I see three paths:
- 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.
If you must use zoom, use it in a browser; uninstall their app.
I must have uninstalled their app on my Macbook ten times now but somehow it keeps coming back. I’ll click a link to join a meeting and the app launches.
This is exactly the kind of dickery I hate zoom for. The same thing with installing a backdoor and then blatantly refusing to remove it when found out. Luckily Apple did the job for them :P
Their attitude is so wrong. I don't understand how people still use it.
But it doesn't work particularly well that way! It's workable, but calls seem to have worse quality and more latency.
By all means, use it if you feel it's necessary, but you're giving up a lot!
Yes! It's a literal tradeoff between security and functionality, the same tradeoff that people make every day.
Figure out which one you want; Zoom is unwilling to give you both, even when you're paying them.
I didn't know that Zoom allowed that. Thank you.
You have to pretend that Zoom doesn't work and then it eventually gives you the "join from browser" link.
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.
> Is there any way to prevent it?
Maybe run it in a chroot?
Does Teams or Discord do anything similar?
Discord does. It makes some sense, since Discord has a feature to broadcast what game you're currently playing (or anything you want), but I found it was scanning /proc even when I turned this off.
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.
Wouldn't it be easier to just run it in a browser?
That's probably the better answer, yeah. I think there's a couple of features that don't work very well in the browser (push to talk?), but the actual answer is that it probably simply didn't occur to me at the time.
I use both these days.
The discord snap blocks this with apparmor by default unless you connect process-control. But it also fills your kernel log with audit denials.
I think I tried one of those alternative app distribute-y things at the time, but I don't remember which, and I came away disappointed. If memory serves, I couldn't establish whether it actually did any sandboxing, or what it did by default (like intentionally opening up this exact hole), and certainly not how to configure it, and gave up shortly in favor of something I'd at least seen before.
It might have been Snap. I don't like Snap.
Zoom is pursuing surveillance profits.
Shoshanna Zuboff has an excellent book on "surveillance capitalism", if you want to read more on the trend.
They may be, but this case is not related unless someone is paying big bucks to know the pid of gnome-session.
Zoom is basically malware with video chat.
Ok, but please don't post unsubstantive comments and/or shallow dismissals to Hacker News. It degrades discussion noticeably, and we're trying for better here.
(Of course, the greater part of this damage is done by upvoters, but they can't upvote nothing.)
https://news.ycombinator.com/newsguidelines.html
Yeah I probably should’ve looked up the citations myself. People quickly swooped in with them at least.
I can't believe I'm saying this, but I'm not sure that last one is zoom's fault. It sounds like Zoom is just calling ShellExecute("open", link), and is getting blamed for the fact that Windows will then connect to random server on public internet and can be convinced to send a hash of the password that can be used to forge a different connection from a different host/client pair with the same credentials.
I mean it is their fault, for a naïve implementation and trusting Windows.
It's the mechanism meant for untrusted links, and it's the prescribed way for instance to open a link in the user's default browser. If Chrome took that link and started sending the user's password hash, that'd clearly be Chrome's fault. Same with, say, an ftp client that listened for ftp paths and would send replayable hashes as the first step. It's clearly SMB's terrible protocol. Yes they removed UNC paths to hack around this... but they shouldn't have to. Nope should they be expected to have known about this particular Windows footgun, IMO.
I'm really, really annoyed that you're being downvoted for providing citations: as f-ing requested!
Thank you. These will make for some interesting reading.
This really should be self-evident
Because they can get away with it and use it to make more money from your "experience".
