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

101–110 of 277 posts

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

#101

Post by zippergz »

hdjjhhvvhga wrote: post #63
jlgaddis wrote: post #59

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

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.

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

#102

Post by yakubin »

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.

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

#103

Post by TameAntelope »

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.

I literally quit all messaging apps when presenting to people for any period of time more than ~10s.

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

#104

Post by travoc »

slownews45 wrote: post #74
jraph wrote: post #39

Earlier quoted context omitted.

"Zoom does not work on my computer*, can we try X instead?" With X = something the other end does not need to install, like Jitsi Meet for instance *no need to explain that's because you uninstalled it and blocked its domain on your computer.

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…

You can avoid this reputation by saying “our security analysts block Zoom because they think it might be untrustworthy spyware.”

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

#105

Post by aetherspawn »

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.

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.

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

#106

Post by dllthomas »

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

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

#107

Post by P9TXJYG0TENG »

lathiat wrote: post #95
P9TXJYG0TENG wrote: post #91

Earlier quoted context omitted.

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

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.

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

#108

Post by olyjohn »

uoaei wrote: post #27
thephyber wrote: post #24

Earlier quoted context omitted.

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.

"Doing something" seems like a really low bar when that "something" is basically useless for the intended use case.

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.

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

#109

Post by voxic11 »

nrabulinski wrote: post #38
wwweston wrote: post #17

Earlier quoted context omitted.

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.

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

#110

Post by sp1rit »

woodruffw wrote: post #66
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…

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

Post reply on HN