If there is any feature that “universally” describes the usage of computers, it is the copy/paste pattern. We are used to it, practically all the common graphical user interfaces have support for it, and it magically works.
We copy some information from one application and paste into another, and another…
How does these applications have access to this information? The clipboard must be something that is shared across all of them, right? Right.
While very useful, this raises a lot of security questions. As far as I can tell, all apps could be grabbing what is available on the clipboard.
It isn’t uncommon for people to copy sensitive information from one app to another and even if the information is not sensitive, the user generally has a clear target app for the information (the others don’t have anything to do with it).
These questions started bugging me a long time ago, and the sentiment even got worse when Apple released an iOS feature that notifies users when an app reads the contents of the clipboard. That was brilliant, why didn’t anyone thought of that before?
The result? Tons of apps caught snooping into the clipboard contents without the user asking for it. The following articles can give you a glimpse of what followed:
- LinkedIn says it will stop repeatedly copying iOS clipboard
- TikTok and 32 other iOS apps still snoop your sensitive clipboard data
- iPhone User Sues LinkedIn For Reading Clipboard Data After iOS 14 Alert Revelations
That’s not good, and saying you won’t do it again is not enough. On iOS, apps were caught and users notified, but what about Android? What about other desktop operating systems?
Accessing the clipboard to check what’s there, then steal passwords, or replace cryptocurrency addresses or just to get a glimpse of what the user is doing is a common pattern of malware.
I wonder why hasn’t a similar feature been implemented in most operating systems we use nowadays (it doesn’t need to be identical, but at least let us verify how the clipboard is being used). Perhaps there exists tools can help us with this, however I wasn’t able to find any for Linux.
A couple of weeks ago, I started to look at how this works (on Linux, which is what I’m currently using). What I found is that most libraries just provide a simple interface to put things on the clipboard and to get the current clipboard content. Nothing else.
After further digging, I finally found some useful and interesting articles on how this feature works on X11 (under the hood of those high level APIs). For example:
- https://www.jwz.org/doc/x-cut-and-paste.html
- https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html
- https://wiki.archlinux.org/title/Clipboard
Then, with this bit of knowledge about how the clipboard works in X11, I decided to do a quick experiment in order to check if I can recreate the clipboard access notifications seen in iOS.
During the small periods I had available in the last few weekends, I tried to build a quick proof of concept, nothing fancy, just a few pieces of code from existing examples stitched together.
Here’s the current result:
It seems possible to detect all attempts of accessing the clipboard, but after struggling a bit, it seems that due to the nature of X11 it is not possible to know which running process owns the window that is accessing the clipboard. A shame.
The information that X11 has about the requesting client must be provided by the client itself, which makes it very hard to know for sure which process it is (most of the time it is not provided at all).
Nevertheless, I think this could still be a very useful capability for existing clipboard managers (such as Klipper), given the core of this app works just like one.
Even without knowing the process trying to access the clipboard contents, I can see a few useful features that are possible to implement, such as:
- Create some stats about the clipboard access patterns.
- Ask the user for permission, before providing the clipboard contents.
Anyhow, you can check the proof of concept here and give it a try (improvements are welcome). Let me know what you think and what I’ve missed.
16 replies on “Who keeps an eye on clipboard access?”
This behaviour has bothered me for quite a while and I am now in the habit of clearing the clipboard immediately after using it. The only solution I can think of a is a clipboard timer: After a set time the clipboard automatically clears itself. As this doesn’t exist I can only assume there is a technical reason why it doesn’t.
At least one password manager (LastPass, maybe?) does this. It can be configured to clear your clipboard after pasting the password you had it copy to it.
KeePassXC does it and is open source if you want to see how!
The password manager 1Password also has this feature. Depending on the platform and version of the client, you can enable this feature and even set the timer yourself
I use KeePassXC which also has a “clear clipboard” feature with a timer but it only clears clipboard data put there by KeePassXC. Clipboard contents from other copy/paste operations are left. I was suggesting a feature that clears all contents after use or after a certain period.
Android 12 shows access to the clipboard, too. At least my Pixel 5 does.
That is great. I don’t have an Android 12 device yet, so I was unaware of the new feature. Now we need something like that for our desktop OS.
The clear clipboard functionality provided by applications such as lastpass, does not actually clear the clipboard. Clipboard has a history (at least on windows) and each new item copied is just put on top of the history stack. Clearing the clipboard is just pushing an empty object to the top of the stack.
It’s a hard problem. Before we thought about security the OSes just made an API of effectively “getContentsOfClipboard”. The browser on the other hand doesn’t work that way. Instead you subscribe to an event “onPaste” (not the real name). In which the browser calls you when the user does the paste action (Ctrl/Cmd-V), Picking Paste from menu, etc.
Unfortunately bringing that to the OS requires more API design because often it’s the app that reads the keys and decides what to do. What’s the API design? You might think all you need is OS level Cmd/Ctrl+V and Menu Edit->Paste but plenty of apps draw their own menus or put up a toolbar button “Paste”. Plenty of text editors use a different key combo for pasting. What would the API design be that allows an app to present a UI and initiate a paste action based on using that UI that wouldn’t also allow them just to submit that action to get the “onPaste” callback. Maybe if you want to switch keys for paste you have to register that key with the OS? Not sure how you’d handle clicking toolbar buttons to paste given plenty of apps create their UI from scratch, they’re not using OS level widgets. Most games for example. Also I believe Figma, Blender as just two examples off the top of my head. Maybe you could register an area that when clicked will trigger the paste callback with some limit on the size of the area. Of course if you can draw a UX it can say something other than “paste”
On Windows at least, the developer may choose to do its own rendering of a widget, but still leave the OS handle keyboard events and their translation to higher level events.
https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard-messages
> Perhaps there exists tools can help us with this, however I wasn’t able to find any for Linux.
Qubes does. https://www.qubes-os.org/doc/how-to-copy-and-paste-text/
Very nice, Qubes did a great job in this regard. Perhaps we could “steal” some ideas to apply in other operating systems.
I never thought to watch for other programs accessing the cut/paste buffers – this demo is great, kudos! I’ve long wanted an app showing all the buffers (xclipboard just shows one) in a window (and a way to flip the two main ones) now I have to add wanting it to track track access 🙂
Copy+paste is slightly complicated in X: As JWZ describes, X has a set of buffers, with apps not quite agreeing on how to use them. Users often use X on multiple hosts using the *same* home underneath, complicating saving state in the filesystem. There has even been an X supporting multiple users/mice/keyboards on one display – imagine the copy/paste implications.
X assumes the user is responsible for the apps and so doesn’t try to police clipboard (etc) access, but that doesn’t account for hostile sites visited by web browsers, who have to shoulder that discretionary obligation themselves (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Interact_with_the_clipboard). Personally I think adding JavaScript access to the selection mechanism was unwise, at best, and more likely criminally stupid, and a feature I’ve never seen a use for, but hey, that’s just me.
Lastly, the reason you can’t easily get a process ID, or anything really trustworthy from the X apps digging into the clipboard, et alia, is that those apps may be (in my experience, often are) running on entirely different computers, where we wouldn’t be able to trust that their alledged PIDs were correct anyway.
Who keeps an eye on clipboard access?
Spread the love
Send to HN
If there is any feature that “universally” describes the usage of computers, it is the copy/paste pattern. We are used to it, practically all the common graphical user interfaces have support for it, and it magically works.
We copy some information from one application and paste into another, and another…
How does these applications have access to this information? The clipboard must be something that is shared across all of them, right? Right.
While very useful, this raises a lot of security questions. As far as I can tell, all apps could be grabbing what is available on the clipboard.
It isn’t uncommon for people to copy sensitive information from one app to another and even if the information is not sensitive, the user generally has a clear target app for the information (the others don’t have anything to do with it).
These questions started bugging me a long time ago, and the sentiment even got worse when Apple released an iOS feature that notifies users when an app reads the contents of the clipboard. That was brilliant, why didn’t anyone thought of that before?
The result? Tons of apps caught snooping into the clipboard contents without the user asking for it. The following articles can give you a glimpse of what followed:
LinkedIn says it will stop repeatedly copying iOS clipboard
TikTok and 32 other iOS apps still snoop your sensitive clipboard data
iPhone User Sues LinkedIn For Reading Clipboard Data After iOS 14 Alert Revelations
That’s not good, and saying you won’t do it again is not enough. On iOS, apps were caught and users notified, but what about Android? What about other desktop operating systems?
Accessing the clipboard to check what’s there, then steal passwords, or replace cryptocurrency addresses or just to get a glimpse of what the user is doing is a common pattern of malware.
I wonder why hasn’t a similar feature been implemented in most operating systems we use nowadays (it doesn’t need to be identical, but at least let us verify how the clipboard is being used). Perhaps there exists tools can help us with this, however I wasn’t able to find any for Linux.
A couple of weeks ago, I started to look at how this works (on Linux, which is what I’m currently using). What I found is that most libraries just provide a simple interface to put things on the clipboard and to get the current clipboard content. Nothing else.
After further digging, I finally found some useful and interesting articles on how this feature works on X11 (under the hood of those high level APIs). For example:
https://www.jwz.org/doc/x-cut-and-paste.html
https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html
https://wiki.archlinux.org/title/Clipboard
Then, with this bit of knowledge about how the clipboard works in X11, I decided to do a quick experiment in order to check if I can recreate the clipboard access notifications seen in iOS.
During the small periods I had available in the last few weekends, I tried to build a quick proof of concept, nothing fancy, just a few pieces of code from existing examples stitched together.
Here’s the current result:
Demonstration of clipboard-watcher detecting when other apps access the contentsIt seems possible to detect all attempts of accessing the clipboard, but after struggling a bit, it seems that due to the nature of X11 it is not possible to know which running process owns the window that is accessing the clipboard. A shame.
The information that X11 has about the requesting client must be provided by the client itself, which makes it very hard to know for sure which process it is (most of the time it is not provided at all).
Nevertheless, I think this could still be a very useful capability for existing clipboard managers (such as Klipper), given the core of this app works just like one.
Even without knowing the process trying to access the clipboard contents, I can see a few useful features that are possible to implement, such as:
Create some stats about the clipboard access patterns.
Ask the user for permission, before providing the clipboard contents.
Anyhow, you can check the proof of concept here and give it a try (improvements are welcome). Let me know what you think and what I’ve missed.
Read More
.fb-background-color {
background: #ffffff !important;
}
.fb_iframe_widget_fluid_desktop iframe {
width: 100% !important;
}
Facebook Notice for EU!
You need to login to view and post FB Comments!
Facebook iconFacebookTwitter iconTwitterLINE iconLine
Related