Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why does Zoom Desktop examine all processes and arguments?

news.ycombinator.com

Post reply on HN
Print view View original

171–180 of 277 posts

Re: Ask HN: Why does Zoom Desktop examine all processes and arguments?

#171

Post by dathinab »

sp1rit wrote: post #110
woodruffw wrote: post #66

Earlier quoted context omitted.

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…

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 requestin…

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.

Re: Ask HN: Why does Zoom Desktop examine all processes and arguments?

#172

Post by dathinab »

user5994461 wrote: post #169
kelnos wrote: post #96

Earlier quoted context omitted.

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

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.

Re: Ask HN: Why does Zoom Desktop examine all processes and arguments?

#173

Post by dathinab »

mwcampbell wrote: post #100
kelnos wrote: post #96

Earlier quoted context omitted.

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

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

Re: Ask HN: Why does Zoom Desktop examine all processes and arguments?

#174

Post by dathinab »

yakubin wrote: post #102
reilly3000 wrote: post #50

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 fo…

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

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.

Re: Ask HN: Why does Zoom Desktop examine all processes and arguments?

#175

Post by dathinab »

thxg wrote: post #152
dllthomas wrote: post #106

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

^ 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-…

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

Re: Ask HN: Why does Zoom Desktop examine all processes and arguments?

#176

Post by dathinab »

IG_Semmelweiss wrote: post #163
acatton wrote: post #150

Earlier quoted context omitted.

It also plays your user-name (when configured by the meeting owner) in the background at a non-audible frequency, so that companies can find out who leaked their meetings by analysing the audio from the leak. https://theintercept.com/2021/01/18/leak-zoom-meeting/

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

Re: Ask HN: Why does Zoom Desktop examine all processes and arguments?

#177

Post by mixmastamyk »

acatton wrote: post #148
dmart wrote: post #129

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 wha…

Whitelisting htop would be a simple matter.

Re: Ask HN: Why does Zoom Desktop examine all processes and arguments?

#178

Post by woodruffw »

dathinab wrote: post #162
woodruffw wrote: post #70

Earlier quoted context omitted.

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 mechanism…

Hence “unlikely stretch.”

Re: Ask HN: Why does Zoom Desktop examine all processes and arguments?

#179

Post by NoPicklez »

Wowfunhappy wrote: post #112
olyjohn wrote: post #108

Earlier quoted context omitted.

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 gra…

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.

Re: Ask HN: Why does Zoom Desktop examine all processes and arguments?

#180

Post by woodruffw »

gmueckl wrote: post #147
nonameiguess wrote: post #126

Earlier quoted context omitted.

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 o…

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.

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.
Post reply on HN