It’s been some years so I may be misremembering, but IIRC on macOS an app has to be active/frontmost to be able to read the clipboard. Or else have been given access to the Accessibility API, which gives it superpowers to inspect and drive other apps.
HTML5’s clipboard API definitely has security features to prevent web apps from trolling for clipboard data.
The X clipboard is a hairy beast. First, note that there is not a single clipboard. X traditionally has two clipboards, PRIMARY and SECONDARY, the first of which is accessed by selecting something and pressing the middle mouse key to duplicate the selected text while it’s selected. It’s quite a nice feature, but widely unknown; I have come to like it quite a bit. I never came about a use for SECONDARY. The CTRL+C/CTRL+V keyboard is a not formally included in X11, but de-facto third clipboard, named fittingly CLIPBOARD in X atom terms. For notifications on clipboard access, you will need to monitor all three of them. PRIMARY and SECONDARY are managed by X.org itself. For CLIPBOARD it is typical to employ a helper programme called a “clipboard manager”, but it is by no means necessary. If however you don’t, closing the source application will make the clipboard content vanish, because there is no clipboard owner anymore in X’s terms.
I had my fair share with X’ clipboard when I wrote tinyclipboard, a minimal C library for interacting with the X and Win32 clipboard abstracting over the platform differences, many years ago (I don’t work on this anymore, use at your own risk). The source code might serve as inspiration for you, but I will give you the most useful resources I used when writing this below (the first one is particularyly insightful):
I could have sworn I read at some point that clipboard access was being limited to only keyboard apps, but I’m unable to find a citation now so I guess I’m misremembering?
It’s handled somewhat similarly to X11, but you’d need to modify the compositor to get such information for most of them (I’d say all, but it could be that some do have some interfaces for snooping). And of course, since you’d be working from the compositor, you should be able to get more information about the source and the sink. Some details about the protocol and it’s implementations can be found here
Jokes aside: I’d really like to have multi-dpi setups and X11 is apparently even worse, code wise. But historically you won’t replace faults in wayland until wayland++ in 18 years.
Jokes aside: I’d really like to have multi-dpi setups
works for me on x11….. I understand a lot of applications are buggy though, but nothing I use. That’s what bugs me so much about this, things get called “fundamental flaws” but it works sometimes, so pretty sure what we actually have are just bugs. It happens.
and X11 is apparently even worse, code wise
I’m not convinced this is true, but even if it is…. it happens. I look at my own code from a few years ago and hate it, but I know the code I write today will be either hated or abandoned in a few years too.
But historically you won’t replace faults in wayland until wayland++ in 18 years.
TLDR: previous project lead calls it abandonware (and today they found out most drivers don’t build anymore)
I’m not so sure about multi-dpi. It just never worked for me on X11. And scaling itself also was pretty buggy. Otherwise I’d run a 4k + fullhd setup on linux instead of windows.
Edit: Also I think the overhaul of who can grab your input is already worth a lot.
Your TLDR; seem to imply that you read the Phoronix “GPT3 meets adtech”s “take” on it, and not Ajax post itself.
“Though the code happens to implement an unfortunate specification, the code itself is quite well structured, easy to hack on, and not far off from being easily embeddable.”
It boils down to the modeset-ddx falling behind. That’s the part that, simplified, implemented half of GPU drivers in userspace. The relevant layers (KMS/GBM) has since evolved, which changes not synched to the modeset driver. That can be fixed with a KMS/EGL only- ddx, which is in the effort of 4-5kloc.
He goes on to literally opening up for teaching anyone who wants to step up the ropes on workflow and architecture. The problem is, was, and remains, economic incentives. The last few months, it seems, that there are at least one or two candidates for that position pending.
Also I think the overhaul of who can grab your input is already worth a lot.
If you are willing to accept breakage of singular clients >and take the reactions from people who relied on the edge cases<, it is fixable, and trivially so. XACE specification provided all the necessary hooks, it is literally an if condition or two away away.
Except Wayland doesn’t define any authentication mechanism, so identity is out the window (ha) and the intended APIs and OO model abstract way too much for it to be fixed in a way where the damage isn’t already done.
One might rightfully ask what the point is of privilege without authenticity or identity in the xkcd fashion of “make me a sandwich?” “what? make it yourself.” “sudo make me a sandwich.” “ok”.
This is why I am looking to replace my use of Bitwarden with something else. It’s so inconsistent with how you save a password to it and with inserting passwords into fields that you have to copy the password to the clipboard, at which point it’s as good as if you hadn’t used a password manager at all from an access standpoint.
The X server itself could definitively tell which application - at least if it is local - is accessing the clipboard, but I don’t know if that can be pulled through a client at all. But yeah you don’t want to keep nasty applications that misuse those apis.
Based on the information I was able to find the window property _NET_WM_PID is set by the window creator itself (voluntarily) and on my tests most windows accessing the clipboard didn’t do it. I couldn’t find any other way of getting that piece of data.
Right, the client api is limited to the voluntary property, so no promise it is set (and if it is, they could just lie, this is malware we’re talking about), but the server itself could ask the kernel who is on the other end of the local unix socket with the SCM_CREDENTIALS function. Then you could sandbox non-local sockets so they can’t share clipboard if you wanted to lock it down.
The pieces to do it are all in the X server, just it isn’t exposed for user access so you’d have to modify the core and/or do an extension plugin to get at the info.
sudo apt-get install wl-clipboard
old="";
while true; do
sleep 1;
clipped=$( wl-paste );
if test "$old" != "$clipped"; then
echo $clipped;
old=$clipped;
fi;
done
shows the whole system clipboard contents (i.e. if I copy something something in chrome it gets displayed on terminal).
Indeed, the more I think about the ways clipboard is used the more I think the user needs more control/visibility over it, even though most the times these use cases are very useful.
It’s been some years so I may be misremembering, but IIRC on macOS an app has to be active/frontmost to be able to read the clipboard. Or else have been given access to the Accessibility API, which gives it superpowers to inspect and drive other apps.
HTML5’s clipboard API definitely has security features to prevent web apps from trolling for clipboard data.
Electron: 1
X11: ∞
/s
The X clipboard is a hairy beast. First, note that there is not a single clipboard. X traditionally has two clipboards, PRIMARY and SECONDARY, the first of which is accessed by selecting something and pressing the middle mouse key to duplicate the selected text while it’s selected. It’s quite a nice feature, but widely unknown; I have come to like it quite a bit. I never came about a use for SECONDARY. The CTRL+C/CTRL+V keyboard is a not formally included in X11, but de-facto third clipboard, named fittingly CLIPBOARD in X atom terms. For notifications on clipboard access, you will need to monitor all three of them. PRIMARY and SECONDARY are managed by X.org itself. For CLIPBOARD it is typical to employ a helper programme called a “clipboard manager”, but it is by no means necessary. If however you don’t, closing the source application will make the clipboard content vanish, because there is no clipboard owner anymore in X’s terms.
I had my fair share with X’ clipboard when I wrote tinyclipboard, a minimal C library for interacting with the X and Win32 clipboard abstracting over the platform differences, many years ago (I don’t work on this anymore, use at your own risk). The source code might serve as inspiration for you, but I will give you the most useful resources I used when writing this below (the first one is particularyly insightful):
Take a look at tinyclipboard’s source code if you are interested in how things work on Win32 or how I implemented the above for X11.
Android 12 also notifies the user: https://developer.android.com/about/versions/12/behavior-changes-all#clipboard-access-notifications
I could have sworn I read at some point that clipboard access was being limited to only keyboard apps, but I’m unable to find a citation now so I guess I’m misremembering?
Also of note here: Qubes OS’ clipboard system.
I wasn’t aware more recent versions of Android did the same. That is great.
Interesting, I will check it out.
Would be interesting to read a followup how this is handled on wayland and whether you can get more information about the source there.
It’s handled somewhat similarly to X11, but you’d need to modify the compositor to get such information for most of them (I’d say all, but it could be that some do have some interfaces for snooping). And of course, since you’d be working from the compositor, you should be able to get more information about the source and the sink. Some details about the protocol and it’s implementations can be found here
The more I hear about wayland, the more I ask myself if it’s really any good ;)
It’s not.
Jokes aside: I’d really like to have multi-dpi setups and X11 is apparently even worse, code wise. But historically you won’t replace faults in wayland until wayland++ in 18 years.
works for me on x11….. I understand a lot of applications are buggy though, but nothing I use. That’s what bugs me so much about this, things get called “fundamental flaws” but it works sometimes, so pretty sure what we actually have are just bugs. It happens.
I’m not convinced this is true, but even if it is…. it happens. I look at my own code from a few years ago and hate it, but I know the code I write today will be either hated or abandoned in a few years too.
I’m so excited for PulseGraphics!
https://www.phoronix.com/scan.php?page=news_item&px=Ajax-On-The-X-Server
TLDR: previous project lead calls it abandonware (and today they found out most drivers don’t build anymore)
I’m not so sure about multi-dpi. It just never worked for me on X11. And scaling itself also was pretty buggy. Otherwise I’d run a 4k + fullhd setup on linux instead of windows.
Edit: Also I think the overhaul of who can grab your input is already worth a lot.
Your TLDR; seem to imply that you read the Phoronix “GPT3 meets adtech”s “take” on it, and not Ajax post itself.
“Though the code happens to implement an unfortunate specification, the code itself is quite well structured, easy to hack on, and not far off from being easily embeddable.”
It boils down to the modeset-ddx falling behind. That’s the part that, simplified, implemented half of GPU drivers in userspace. The relevant layers (KMS/GBM) has since evolved, which changes not synched to the modeset driver. That can be fixed with a KMS/EGL only- ddx, which is in the effort of 4-5kloc.
He goes on to literally opening up for teaching anyone who wants to step up the ropes on workflow and architecture. The problem is, was, and remains, economic incentives. The last few months, it seems, that there are at least one or two candidates for that position pending.
If you are willing to accept breakage of singular clients >and take the reactions from people who relied on the edge cases<, it is fixable, and trivially so. XACE specification provided all the necessary hooks, it is literally an if condition or two away away.
Except Wayland doesn’t define any authentication mechanism, so identity is out the window (ha) and the intended APIs and OO model abstract way too much for it to be fixed in a way where the damage isn’t already done.
Here is the related section from the “spec”, a recent issue from the reference compositior reaffirming the fact, and a very recent issue from a popular compositor library showing that it generalises to “privileged protocols”, and a mailing list thread on the same matter. A more fun can of worms to open if one is so inclined is ‘Denial of Service’ and grep:ing commit logs for variants of Use-After-Free.
One might rightfully ask what the point is of privilege without authenticity or identity in the xkcd fashion of “make me a sandwich?” “what? make it yourself.” “sudo make me a sandwich.” “ok”.
Indeed. Perhaps once I have a machine running wayland, I will try to figure out how it works.
This is why I am looking to replace my use of Bitwarden with something else. It’s so inconsistent with how you save a password to it and with inserting passwords into fields that you have to copy the password to the clipboard, at which point it’s as good as if you hadn’t used a password manager at all from an access standpoint.
The X server itself could definitively tell which application - at least if it is local - is accessing the clipboard, but I don’t know if that can be pulled through a client at all. But yeah you don’t want to keep nasty applications that misuse those apis.
Based on the information I was able to find the window property
_NET_WM_PIDis set by the window creator itself (voluntarily) and on my tests most windows accessing the clipboard didn’t do it. I couldn’t find any other way of getting that piece of data.Right, the client api is limited to the voluntary property, so no promise it is set (and if it is, they could just lie, this is malware we’re talking about), but the server itself could ask the kernel who is on the other end of the local unix socket with the SCM_CREDENTIALS function. Then you could sandbox non-local sockets so they can’t share clipboard if you wanted to lock it down.
The pieces to do it are all in the X server, just it isn’t exposed for user access so you’d have to modify the core and/or do an extension plugin to get at the info.
Interestingly enough I supposed chromeos somewhat restricted programmatic clipboard access (i.e. https://chromeos.dev/en/linux/linux-on-chromeos-faq#can-i-readwrite-the-clipboard-automatically-from-inside-the-vm ) but a quick test proved my assumptions very wrong. Opened terminal:
shows the whole system clipboard contents (i.e. if I copy something something in chrome it gets displayed on terminal).
I had KDE Connect’s clipboard sync plugin on, this is very scary
Indeed, the more I think about the ways clipboard is used the more I think the user needs more control/visibility over it, even though most the times these use cases are very useful.