Continuing the discussion from Webinar: Meet the Discourse Customer Projects Team:
I just want to share that this problem unfortunately did not cease and, on the contrary, it is getting worse every day. I agree that trade agreements should exist, and my intention here is not to discuss them because I am not the right person to do so, but rather to humbly request support for secure platforms in the main development of Discourse.
The integration of Zoom in Livestream and other plugins is truly essential for maintaining periodic meetings among users, and today it is limited and exclusive to a platform that many do not use due to countless events that make it unsafe and not a viable option.
I noticed today that an update to the Linux Zoom client has made it start proactively reading everything written to the X11 clipboard.
If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!
This is Linux Zoom 7.1.5. Previously I had 6.6 installed, which didn’t do this.
It appears to only care about the CLIPBOARD selection – the one with Windows-ish UX, which you typically copy to explicitly with a keystroke such as ^C, and paste from with ^V (or similar). It doesn’t look at PRIMARY, the selection used for trad X11 “just select in this window then middle-click in the other” copy-paste.
It looks as if it’s detecting changes of clipboard via the XFIXES extension, and whenever the clipboard is claimed by a new owner, it immediately sends that client a paste request.
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. But today, after an apt update, it doesn’t work: my one-shot paste tool terminates as soon as it starts, because (I found out after some debugging) Zoom always requests a paste immediately.
(Regular readers might recall that around this time last year I caught Slack doing something similar, but only when focus entered the Slack window, and also, they had a configuration option to turn it off. A one-shot paste tool seems to be a good way to notice weird things going on in the X server!)
The way the X11 selection mechanism works is that every time an application wants to paste, it contacts the current selection owner and asks it to send the data.
This allows some amusing stunts, like writing a selection client that always pastes the current time, rather than the time the clipboard was (logically speaking) written. But it also means that the selection-owning application knows when someone is pasting from it, and can do things in response.
A one-shot paste tool is a thing that starts up, claims ownership of the clipboard, waits until it’s received and fulfilled one paste request, and then immediately terminates.
It so happens that I use one I wrote myself. But others exist. One that’s already available in Debian and Ubuntu is ‘xclip’. If you do this …
sudo apt install xclip # if you don’t have it installed already
echo -n foo | xclip -selection primary -loop 1 -verbose… Then middle-clicking in some other window should cause two things to happen. First, it pastes ‘foo’. But also, the xclip tool terminates, and your shell prompt comes back in the first terminal.
If you use ‘-selection clipboard’ instead of ‘-selection primary’ then it will write the other clipboard, the one that typically pastes using ^V or similar. Except that if you’re running Zoom 7.1.5 on the same X server, it won’t wait for you to paste something on purpose – it will terminate immediately, because it already received a paste request from Zoom!