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.
Out of interest why do you still use the app and not just use it in the browser? I feel much more secure having it in the browser sandbox and everything I care about works in the browser.
> A few years back, there was something about gaining root on MacOS via Zoom due to shady execution on their end.
> There's no legitimate use for it accessing privileged or private paths.
Well, that was the whole premise that made Zoom popular in the first place! It was a true one click install which made onboarding frictionless for non-technical users
Security wise, it's insane but user experience wise, it was unbeatable and is what solidified their position. It's ironic nowadays that all of those tricks have been stripped away, making it just as painful as any other platform to install on a fresh machine.
> 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.
Just run these things in your browser. Despite the dark design patterns that try to trick you into installing their desktop client, the web-based versions are fine.
if you use Wayland's security context to prohibit privileged protocols such as arbitrary clipboard access then an application will either not be able to grab clipboard content until you focus on it or the attempt will be noticeable as it spawns a short lived window in an attempt to grab focus.
I would rather have a nice popup on first attempt "this application is monitoring your clipboard, allow?", ideally with that process completely suspended while that prompt is up.
This should be behind a toggle driven by intent, rather than something allowed by default. Default stance on trust should be "don't". Open source has nothing to do with it, when a typo while installing with a package manager means you might accidentally install something else (a common attack vector).
Linux generally presumes that you run trusted software, not some proprietary program that is approximately malware. If you want a "sandbox" run that program as a separate unprivileged user or use bubblewrap.
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?
It's not chromium. But what's happening here is that even if you don't click paste, zoom is actively listening to clipboard events and consuming pastes.
Tbh, if they aren't harvesting clipbakrds data which is a weird thing to do and is unlikely, this doesn't really mean much. Anyways any X client can read.
I suspect it's something like: a bug report that said that I copied the link but when I opened zoom and pasted it it didn't it work. I.e, they probably closed the source application and thus the selection owner is gone, and the selection is gone too. This fixes that. I would test that maybe. See if paste after source app close works. Then again, if you use a ownership changing clipboard manager this shudnt be a problem.
The "clipboard" as it is implemented in many (most?) operating systems today, only exists because it's a legacy idea that hasn't died. If it were freshly invented today, it would never get past even the most lenient privacy review.
Think about the pitch for the feature: "So, we're going to make this in the OS, where the user can highlight anything in any application, invoke a command, and then that thing (which could be a sensitive password, private personal information, or the codes to a nuclear weapon) will instantly become available for all applications on the system to read and do anything with. Uhh... NO THANKS!
Ideally, if an application wants to read from the clipboard, it should explicitly ask the user for permission, or the user should have to specify the exact app he's copy/pasting to. This reduces the clipboard's ease of use, but at least makes it NOT a truck sized privacy hole.
No. You're assuming that you don't have control of your own computer.
Think about the pitch for removing the feature, "So, we're going to make this in the OS, where visually disabled users cannot highlight anything in any application, can't move text between applications, cannot get the window title, cannot get the window tree, cannot have applications automate or know where other applications are, and basically they won't be able to use their computers. But everyting will be super private. Even the human using the computer won't be able to read it." This is what modern linux desktop computer is on waylands thanks to this toxic privacy meme. It literally just doesn't work for me.
Privacy needs the kind you're talking about simply don't exist on desktop computers where the human actually controls everything (as opposed to smartphone model where the user controls very little and applications are hostile and opaque). If you want to break accessibility and functioning of smartphones, fine, go for it. But leave desktop computers alone.
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.
Out of interest why do you still use the app and not just use it in the browser? I feel much more secure having it in the browser sandbox and everything I care about works in the browser.
Yes Apple even blocked their app because they refused to fix it. Eventually they did and unfortunately they were allowed again.
It wasn't really root as much as an open backdoor on a TCP port as far as I recall.
> A few years back, there was something about gaining root on MacOS via Zoom due to shady execution on their end.
> There's no legitimate use for it accessing privileged or private paths.
Well, that was the whole premise that made Zoom popular in the first place! It was a true one click install which made onboarding frictionless for non-technical users
Security wise, it's insane but user experience wise, it was unbeatable and is what solidified their position. It's ironic nowadays that all of those tricks have been stripped away, making it just as painful as any other platform to install on a fresh machine.
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.
Turns out, Wayland has wl-copy:
https://man.archlinux.org/man/wl-copy.1
(i was also interested :)
Just run these things in your browser. Despite the dark design patterns that try to trick you into installing their desktop client, the web-based versions are fine.
with Wayland it's generally not any safer.
if you use Wayland's security context to prohibit privileged protocols such as arbitrary clipboard access then an application will either not be able to grab clipboard content until you focus on it or the attempt will be noticeable as it spawns a short lived window in an attempt to grab focus.
https://jitsi.org/
Jitsi is an excellent free and open source alternative.
Why I always shutdown the zoom process as soon as meetings end.
I miss ordinary conference calling being the norm. I like having a desktop IP phone.
Feeling good about using Zoom, when necessary, in a tab in ChromeOS. Zoom is "Not allowed to see your clipboard" in Chrome preferences.
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.
I would rather have a nice popup on first attempt "this application is monitoring your clipboard, allow?", ideally with that process completely suspended while that prompt is up.
This should be behind a toggle driven by intent, rather than something allowed by default. Default stance on trust should be "don't". Open source has nothing to do with it, when a typo while installing with a package manager means you might accidentally install something else (a common attack vector).
Reason 1492835 to use Qubes OS.
Also reason 35892384242892 to not use proprietary software, especially proprietary software with network access.
Qubes OS saved me, once again. On it, Zoom only has the access to an empty VM and no access to the clipboard.
What's it like using Qubes? How much friction? I wish I could use some Nix-flavored variant of the sandboxing.
Just not using that piece of trash that is zoom would work very well too in this case
That's bad news. Don't use Zoom.
That's wildly impractical advice for many.
Just use Firefox, or Chromium if you must.
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.
Linux generally presumes that you run trusted software, not some proprietary program that is approximately malware. If you want a "sandbox" run that program as a separate unprivileged user or use bubblewrap.
Android allows apps to read from the clipboard at will, though it does show a toast. GrapheneOS, I believe, asks for permission first.
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?
It's not chromium. But what's happening here is that even if you don't click paste, zoom is actively listening to clipboard events and consuming pastes.
Tbh, if they aren't harvesting clipbakrds data which is a weird thing to do and is unlikely, this doesn't really mean much. Anyways any X client can read.
I suspect it's something like: a bug report that said that I copied the link but when I opened zoom and pasted it it didn't it work. I.e, they probably closed the source application and thus the selection owner is gone, and the selection is gone too. This fixes that. I would test that maybe. See if paste after source app close works. Then again, if you use a ownership changing clipboard manager this shudnt be a problem.
The "clipboard" as it is implemented in many (most?) operating systems today, only exists because it's a legacy idea that hasn't died. If it were freshly invented today, it would never get past even the most lenient privacy review.
Think about the pitch for the feature: "So, we're going to make this in the OS, where the user can highlight anything in any application, invoke a command, and then that thing (which could be a sensitive password, private personal information, or the codes to a nuclear weapon) will instantly become available for all applications on the system to read and do anything with. Uhh... NO THANKS!
Ideally, if an application wants to read from the clipboard, it should explicitly ask the user for permission, or the user should have to specify the exact app he's copy/pasting to. This reduces the clipboard's ease of use, but at least makes it NOT a truck sized privacy hole.
No. You're assuming that you don't have control of your own computer.
Think about the pitch for removing the feature, "So, we're going to make this in the OS, where visually disabled users cannot highlight anything in any application, can't move text between applications, cannot get the window title, cannot get the window tree, cannot have applications automate or know where other applications are, and basically they won't be able to use their computers. But everyting will be super private. Even the human using the computer won't be able to read it." This is what modern linux desktop computer is on waylands thanks to this toxic privacy meme. It literally just doesn't work for me.
Privacy needs the kind you're talking about simply don't exist on desktop computers where the human actually controls everything (as opposed to smartphone model where the user controls very little and applications are hostile and opaque). If you want to break accessibility and functioning of smartphones, fine, go for it. But leave desktop computers alone.