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.
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.
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...
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.
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.
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.
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.
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.
This probably explains why, when i try to screenshare a single application window, not every application shows up! I can share my browser, file manager, and various other things, but not windows for games started by Steam.
[1] I followed these instructions https://www.mayrhofer.eu.org/post/zoom-flatpak-sandboxing/
It makes me wonder how Things like Steam streaming and Paperspace get around the issue.
But that doesn't work for non-X11 or if the WM is non-EWMH compliant. Presumably Wayland has a similar API, and non-EWMH is probably a minuscule group that considers this a desirable feature.
One of the downsides this has is the described issue of "screensharing beeing impossible on wayland". This is solved by the XDG Desktop Portal, which provides a unified dbus interface across the different compositor implementations for requesting a pipewire file descriptor (which can be used with gstreamer to get a live video stream of the deskop, in a way far superior to x11 framegrab). However the implementation differs for each compositor, GNOME for example asks you if you what to share the whole screen or just a specific application but wlroots (swaywm, wayfire, etc.) AFAIK automatically accepts and shares the whole screen. I don't know what KDE Plasma does.
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...
That's definitely not a cross-platform way of doing it (and I doubt there is one, even).
On Linux you'd use libX11 and just enumerate all windows (using XQueryTree()). Walking the contents of /proc is not only unnecessary, but is more difficult to do, as looking at executable names won't tell you if a program has a GUI, or if it has any open windows. It won't give you window titles, or how many windows are open, or how to grab their contents.
Pretty sure Zoom is snooping on us and is gathering telemetry.
If you say that there's an similar API on Linux for X11, then that's the same methodology across platforms.
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.
Don't forget Hanlon's razor, as someone else in the thread pointed out.
When you share a single window in Zoom, notifications are still visible to others in the meeting when they overlap with the window you're sharing. That's the case for e.g. Slack notifications.
Caveat being if you move the window around really fast sometimes it’s possible to catch a glimpse.
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.