Live data from Hacker News

Who keeps an eye on clipboard access?

blog.ovalerio.net

21–30 of 147 posts

Re: Who keeps an eye on clipboard access?

#21
post #15

Earlier 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

Apps do not even have to be foreground to fetch clipboard contents, afair. On windows, a clipboard is shared with the entire session (i.e. everything that you or the system runs for you after you log on).

Re: Who keeps an eye on clipboard access?

#22
post #15
post #7

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?

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…

The way it works for webapps is that you are only allowed to read or write the clipboard in the event handler for certain events, but it isn’t really watertight and that sort of mechanism isn’t so feasible outside the web where you don’t have so much control on how programs handle events.

Re: Who keeps an eye on clipboard access?

#25
post #15

Earlier 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.

As other pointed out, you don't even need to tab into some app. The security model on desktop OSs is that by default, every app has access to everything owned by the current user, even memory of other apps or hijacking commands by adding scripts in ~/.local/bin.

It is slowly being worked on (on Linux, this is done via control groups (containerization), AppArmor, SELinux, ...) but takes time to carefully tune so legitimate existing apps don't crash because they expect access to something. IIRC, macOS and Windows are also working on this.

There is also Qubes OS, taking a more radical approach of isolating everything by default, like Android or iOS. But it can be painful to use, as apps are not designed to support it.

Re: Who keeps an eye on clipboard access?

#26
post #24
post #7

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?

Clipboard should be a private and secure enclave (encrypted) in the first place. Only the OS should store and retrieve data from it.

It’s pretty safe in web browsers. Any app can write to it but the only way to read is if the user hits the paste shortcut.

Re: Who keeps an eye on clipboard access?

#27
post #4
post #2

To 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…

XWayland as a whole is itself a Wayland client. So as long as any X11 window has focus then any other X11 window can steal the clipboard. But once a Wayland window is focused, X11 windows don't have access anymore.

Re: Who keeps an eye on clipboard access?

#29
post #15
post #7

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?

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…

> you wouldn't be able to put a "paste" item in a context menu

I don't know about that. One approach would be for the menu invocation to accept a capability object representing the active context's interpretations of "copy", "paste", "save" etc. (A "user agent" if you will!) The menu would then invoke methods on that object. That way, interactions triggered by the mouse would propagate the appropriate capability. Other uses of the menu would have to synthesise an object of the correct type, which they could do, but they wouldn't be able to forge access to the user's clipboard.

In general, capability style thinking benefits from removing ambient authority such as a global clipboard, replacing it with an object explicitly representing the necessary authority in each context.

Re: Who keeps an eye on clipboard access?

#30
That my web browser process can read my windows clipboard is fine, what’s important is that it prevents the web pages it has loaded from doing the same.

I can’t trust all web pages but trusting all my desktop programs is a much easier pill to swallow.

Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access, or notifying the user when apps read the clipboard without being in focus or sent any input first.

Post reply on HN