Not the first time Zoom abuses privilege.

A few years back, there was something about gaining root on MacOS via Zoom due to shady execution on their end.

They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f...

I always ask (1) why does an app require installation and (2) why would it require root?

There are valid answers for both, but realistically, all a videoconferencing app should need (apart from audio and video and maybe screen sharing) is to store a config file.

There's no legitimate use for it accessing privileged or private paths.

Unrelated to Zoom, but

> I noticed it because I make heavy use of a "one-shot paste" tool which fulfills a single paste request and then terminates. Handy for filling in lots of fields of a web form – queue up pastes of several different things, then go to each form field in turn and just hit paste, bam bam bam.

This sounds very useful. Is the tool available anywhere? xclip -loops doesn't seem to do the trick, or maybe it just doesn't work that way on Wayland.

Par for the course when running a proprietary application. If doing that on Linux, can you imagine what it and others do under Windows ?

As people running Linux should know, you cannot trust proprietary applications.

Qubes OS saved me, once again. On it, Zoom only has the access to an empty VM and no access to the clipboard.

I miss ordinary conference calling being the norm. I like having a desktop IP phone.

I'm not surprised by news like this anymore. When will Linux distributions properly sandbox our applications?

Our phones have had a better permission system for years.

Reason 1492835 to use Qubes OS.

Also reason 35892384242892 to not use proprietary software, especially proprietary software with network access.

That's bad news. Don't use Zoom.

There is no such thing as an "X11 clipboard" that something can be written to. As the poster goes on to allude, X11 has a concept of a "selection" (a primary and a secondary one).

It goes roughly like this: when you select a text in a window, the X client tells the X server "I have the selection now", when you paste in another window, the client behind the other window asks "who has the selection?" and requests the selection contents from the other client, the data is then forwarded through the server. The client that claimed ownership has to properly handle some associated requests/events for the whole thing to work.

The key point is, there is no central "clipboard" style repository like on Windows, the client that does the "copy" is responsible for the data, the client that wants to "paste" has to talk to it. If I try to copy/paste and quit the source program before the paste, the data is gone. That's why modern desktop environments usually come with a dedicated daemon that immediately reacts to selection ownership changes, grabs the data for itself and then claims the selection ownership to emulate the Windows style behavior.

If we play devils advocate, it's possible the Zoom client tries to do just that, not trusting whatever desktop environment. I don't use this software, so I'm going out on a limb here, but I'd guess that the "Zoom Desktop Client" is just another browser in disguise? It might be actually Chromium or whatever underneath that does this?