Simon Tatham@simontatham@hachyderm.io
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!
Sep 02, 2026, 09:06 AM·· Mastodonochrome
909 boosts·11 quotes· 690 favorites
Simon Tatham@simontatham
Some details:
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!)
Simon Tatham@simontatham
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!
Simon Tatham@simontatham
I'm not sure. The hard part is identifying a particular application.
In the X11 protocol each client connected to the server (typically a single instance of an application) is granted a subspace of the space of identifiers for windows and similar server-side objects, and the paste protocol involves the sender knowing one window id of the receiver. So it's easy to know which client (identified by a window-id range) is requesting the paste.
But reliably identifying the application corresponding to that client is another matter. There are two separate problems. First, it's not trivial to start from a range of window ids and find the main window within that range – the one which has usefully identifying information like its title and WM_COMMAND property.. In this thread's example, I found that the window requesting the paste wasn't the main Zoom window, it was some auxiliary thing with a generic name. I didn't find out it was part of Zoom until I ran 'xkill' on it and watched to see which application suddenly vanished. (Then I double-checked in a couple of other ways.)
Second, I don't think there's anything unforgeable in an app's collection of windows and X server properties. This kind of a defence might work if you're trying to defend against badly behaved applications: things that aren't being actively malicious, or trying to hide their identity in a serious manner, they're just sloppily written and making unnecessary requests. But if you have any suspicion of true malice, then you have to assume your opponent can lie about its identity in order to cover who's really doing the bad thing.
Simon Tatham@simontatham
Yes, that will be why. If the source application isn't still available to serve the paste data, then the receiving app won't get anything useful.
There is a fallback system of static cut buffers, which are written at cut/copy time and survive the source app if it quits, but a lot of apps don't bother to use that fallback system at all, and even if they do, the cut buffers are much less flexible: no support for any data type other than plain strings in the default character encoding (which, X11 being the age it is, isn't even UTF-8).
I showed an example of one-shot pasting using a standard tool in the post you replied to. To paste several things in sequence, just run that 3 times (or whatever) in a script. I don't have a polished reusable version of that wrapper script, though.
Simon Tatham@simontatham
A nice theory, but several of the machines I use will not run Wayland, because it just crashes at startup.
Also the UX still seems only half finished to me – e.g. two separate APIs for server-side decorations, with some clients doing one and some the other, and
I've not yet seen a compositor that supports both.
Wayland seems to me to be in that space of tools that say
- "We can only be bothered to support the 85% common case"
- "Everyone has to use our stuff, no exceptions, we will judge you for using the old thing instead."
You can't have both! Pick one!
Simon Tatham@simontatham
'maybe the Wayland stack is too old' – it will be whatever comes as standard on Ubuntu 24.04. I feel as if, for software mature enough that people are asking why you're still using the old thing, that ought to be new enough to work!
Client vs server side decorations: on X11, I run a highly customisable window manager (Sawfish) which lets me configure my window frame – both what buttons exist on it, and what they do. In particular, my GUI habits make heavy use of a 'send window to back without minimising' action, and also I've configured various types of clicks on the window frame to move/resize windows without also bringing them to the front, or to reset them to standard sizes I like for that application, or to ping the window instantly to a piece of free space on the screen rather than making me drag it gradually.
X11 applications which say "forget the window-manager frame, I'll make my own" are saying "Simon, I don't care about all those UI actions you configured on the WM frame, the only actions you get are the ones I implemented on my frame". I lose all the shortcuts I set up on purpose, and have to do everything the long way.
If/when I move to Wayland, I will want a window manager that still lets me get this level of configurability. Otherwise I'll be back to the bad old days where GUI actions are all slow and manual instead of fast and automated. And this will mean I want server-side window frames, because that's where a lot of my configurability will want to live.
My current best prospect looks like 'River', a compositor which provides a sub-protocol for window management, so that you can write a custom WM without having to write a full compositor. However, I tested it earlier this year with applications that used both of the different protocols for suppressing the client window frame when the server is providing one, and it only worked with one of the two. I'm hoping that I can fix that in River and send a patch, and then write a River-based WM that behaves the way I want it to. But this is a coding project, not a "just apt install something else" job!
Simon Tatham@simontatham
I don't have a citation – this is original research! I found out when a program I was running received an unexpected SelectionRequest and I investigated.
Simon Tatham@simontatham
I see, thanks. So a side effect would be that command-line pasting tools, like 'xclip -o', also couldn't work?
That's quite a big tradeoff for some users – me in particular. I use that kind of workflow a lot. As and when I move towards Wayland, I'll have to work out what to do about losing that.
Simon Tatham@simontatham
I can't say how? I've never got round to learning Wayland. What restrictions can it place on clipboard use that prevent this kind of unwanted behaviour while still allowing intentional copy-paste?
Simon Tatham@simontatham
that sounds like a very plausible thing to try, but I can't find that setting!
In the Zoom client's Settings dialog box, the "My account" entry in the left sidebar only offers me some links to the web version of my account settings, an option to make a voice recording for smart voice recognition, and a list of all the clients logged in to my account.
Other plausible sidebar entries, like "Meetings & webinars" or "Share screen", don't have any option of that kind either.
Searching for 'clipboard' in the whole settings box, via the search tool at the top of the left sidebar, only finds "Automatically copy invite link to clipboard" in the Meetings tab.
Simon Tatham@simontatham
ah, yes, now I see that in the web version of Settings it's there, a long way down a very large page.
But no luck, I'm afraid. I turned that off; pressed Save; quit and restarted the local Zoom client, since you said the web settings might only be loaded at startup; and alas, the unwanted clipboard slurping is still happening.
