Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?
It can be useful of you want to use a non standard way to paste stuff, example a right mouse button in putty.
Who keeps an eye on clipboard access?
11–20 of 147 posts
Re: Who keeps an eye on clipboard access?
#12To what degree does Wayland solve this compared to X?
I believe in Wayland, only foreground applications can access the clipboard. I can’t recall how poorly XWayland fares; I suspect it just bypasses the security boundary. Nonetheless, still useful, especially e.g. for sandboxed apps. I don’t think clients can, without extensions, watch for who’s snooping the clipboard. However… it probably wouldn’t be difficult to integrate this into the compositor. You could even imag…
>I believe in Wayland, only foreground applications can access the clipboard.
To be precise, Wayland does not care who or what accesses the clipboard. Whether or not only foreground applications can access the clipboard is determined by which clients the particular compositor sends wl_data_offer events to.
So the answer to alexvoda's question is: Wayland doesn't solve the problem completely. wl_data_offer events are pushed from the compositor to the client rather than the client asking for a data offer. The compositor cannot know whether the client may want the data offer, so it has to send the event to every client regardless of whether the client ends up needing it or not. For most (if not all) compositors today, "every client" means "clients that are currently focused", so while a background application can't snoop your clipboard, simply focusing such an application would allow it to snoop.
Furthermore, extensions like wlr-data-control are specifically designed for background snooping, since they're intended to be used by clipboard managers. It's again up to the compositor to apply security to this, like only allowing a single specific process to be the data control manager and not arbitrary programs. For wlr-data-control I'm not aware of any compositor that applies such a policy; it would, at the very least, break `wl-paste`.
Re: Who keeps an eye on clipboard access?
#13Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?
IMO: you have to look at how OSes and window systems were designed and evolved to get a great answer here. Those processes resulted in systems where the OS or compositor or window system itself can’t really know when the user is pasting something or not. It could be changed, but it would have lots of implications globally, from rewriting framework code, to changing JS APIs.
Edge cases would be handled worse, like non-standard paste gestures or VM integration.
Re: Who keeps an eye on clipboard access?
#14This is part of the reason I don't set Vim to automatically fill the system clipboard and only do so on demand.
I think a few other geeky apps let you cut and paste internally as a separate thing from the global clipboard, which seems wise as a mitigation.
Re: Who keeps an eye on clipboard access?
#15Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it.
Sure, there are ways that you could design the system, such as making it so the only way to paste is for the user to hit a key combination, or perhaps click on or touch a UI element that is known to be controlled/hosted/owned by the OS. Then the OS can push the clipboard contents to the foreground application, rather than the application trying to pull it. But then that becomes very limiting, UX-wise. (For example, you wouldn't be able to put a "paste" item in a context menu.)
You could also have a permissions model, where the OS prompts for permission every time an app wants to fetch the clipboard contents (presumably with an "I trust this app" option to get it to stop asking). But that might be considered too intrusive, or possibly just ineffective, as people will often just mash at whatever button is closest to get a modal dialog to go away.
At any rate, we have these copy/paste mechanisms from when people didn't really think about local security in the way we do today. Redesigning things would break a lot of existing applications. It might be worth it, or it might not.
Re: Who keeps an eye on clipboard access?
#16Does it really come as a surprise that apps are exploiting the clipboard?
TLDR: Drag and drop sensitive stuff. If necessary, copy only part of sensitive information, enter the rest manually.
The amount of usability obstacles in the name of security is getting ridiculous. For example, when I got a new company mac, I had to enter my keychain access password and grant access to folders countless times - and I still have to do that after one week of using it occasionally.
Similarly annoying are the cookie questions. In the beginning, I found it interesting and tried to reduce the number of cookies as much as possible - now I just click what ever button brings me to the site fastest (or don't click a button at all, if it is still possible to scroll and see about half of the page on mobile).
Don't you also feel some kind of fatigue?
Now please do not cripple the clipboard the same way. By the way: Qubes OS takes an interesting approach here. Similar to suggestions by some of the commenters. [1]
Don't get me wrong: I am extremely sensible to security - but also to usability. I want to use my daily-driver system conveniently and it should "just work" and I want to trust it fully [2]. I do not just install any trash app, simply because there is one available.
On the desktop:
1. Only applications from the official repos get installed. I may install other open source software occasionally. So yes, the trust lies with the distro.
2. Other software (potentially untrusted or good to be isolated) like banking or tax software or zoom get a proot environment or a new user profile.
3. Most software can be run in the browser anyway and it is actually quite a nice sandboxing tech. Web apps can not simply read the clipboard. [3]
4. Clear cookies on browser exit. I have a whitelist for about two or three sites to keep the state for convenience.
5. Browser extension that manages and fills passwords on request(!). No need to copy-paste around. [4]
6. If I need passwords elsewhere, I use drag and drop. I believe this is extremely convenient and very secure. That works 90% of the time, otherwise, I copy only part of the sensitive information and enter the rest manually.
On mobile:
1. Same goes for app installation: open-source only from F-Droid.
2. Other apps get put in a work profile and disabled when not used. [5] No trash like games and social media.
3. Do not copy paste sensitive information, but use IME apps (keyboard apps that actually "type" passwords). Personally, I like KeePassDX and sometimes use KDE Connect. [6]
Accounts:
1. I own several domains and mobile numbers, all companies that want my info get different data.
2. Fill in bogus information if possible.
I may have gone overboard with this :-D But I don't even care about MFA that much at this point... And it is an interesting experiment to see what company leaks data.
[1] https://www.qubes-os.org/doc/how-to-copy-and-paste-text/ [2] Kubuntu fanboy here and Android still on version 8 though because of ROM customization [3] https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/r... [4] https://github.com/adrium/easypass [5] https://f-droid.org/en/packages/net.typeblog.shelter/ [6] https://www.keepassdx.com/ and https://f-droid.org/en/packages/org.kde.kdeconnect_tp/ And I wrote a KeePass plugin to convert the passwords: https://github.com/adrium/KeepassPfpConverter
Re: Who keeps an eye on clipboard access?
#17Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways…
Wow, I had no idea things worked this way. It makes sense but is also terrifying to think about, that I might be copy-pasting some sensitive data and then accidentally tab into some app and it'd just ghost-paste the data into its cache.
Re: Who keeps an eye on clipboard access?
#18Earlier quoted context omitted.
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways…
Wow, I had no idea things worked this way. It makes sense but is also terrifying to think about, that I might be copy-pasting some sensitive data and then accidentally tab into some app and it'd just ghost-paste the data into its cache.
You don’t need to tab into the app (on a desktop os at least). It’s generally possible to read the clipboard from the background. The app mightn’t even need a visible window.
Re: Who keeps an eye on clipboard access?
#19Earlier quoted context omitted.
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways…
Wow, I had no idea things worked this way. It makes sense but is also terrifying to think about, that I might be copy-pasting some sensitive data and then accidentally tab into some app and it'd just ghost-paste the data into its cache.
> accidentally tab into some app
I think in most systems you don't even need to do that. The app should be able to get the clipboard while in the background.
Re: Who keeps an eye on clipboard access?
#20Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways…
Forget a permissions model. How about an informed notification model, where the OS marks the application with a badge notification whenever it requests a paste? And you can see a history of what it requested?
Generally I find it odd that there is so much hand-wringing over basic transparency. As with companies giving away private data to third parties, before talking about consent, how about a paper trail to start with?