Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the clipboard works

whynothugo.nl

Post reply on HN
Print view View original

71–80 of 160 posts

Re: How the clipboard works

#71

Post by the_mitsuhiko »

ygra wrote: post #54
Khoth wrote: post #13

Earlier quoted context omitted.

On Windows, when you Copy the program supplying the data decides whether to send the data to the clipboard manager straight away, or whether to defer. If it defers, then yes it does a "last call" on closing. If it crashes you lose the clipboard. Some programs will ask you when you quit them if you want to keep the clipboard contents, if you'd copied a large amount of data.

Annoyingy, in Excel's case that question "Do you really want to quit? You have copied large amounts of data to the clipboard." even occurs when you have a single cell's worth in the clipboard. But that's also a confirmation question that no one really understands unless they understand how the clipboard works (or can work).

> in Excel's case that question "Do you really want to quit? You have copied large amounts of data to the clipboard." even occurs when you have a single cell's worth in the clipboard

That's not correct. You need to have quite a few cells in the clipboard for this to happen.

> But that's also a confirmation question that no one really understands

The dialog tells you exactly what it is asking for. It gives you three options: keep the app open, store the data in the clipboard, discard the data from the clipboard. I am not sure how a user could not understand what to do in that situation.

Re: How the clipboard works

#72

Post by xtiansimon »

alkonaut wrote: post #68

What's the reason for this unusual no-actual-clipboard design? The user's mental model of a clipboard is that things are copied to the clipboard, so breaking that mental model has to have a reason? Obviously this is more elegant for several reasons (performance, security/privacy) etc. But still: the fact that it doesn't survive a shutdown sounds problematic. Can a clipboard manager fill that gap completely, i.e. copy…

“… the fact that probably 99% of all cut/copy/paste operations are within the same application…”

Depends. If you’re working, say, in an application writing or a drawing/graphic app then you’re likely doing a lot of copy and paste. In which case the total number of CnP operations is very high.

However, this measure is misleading to the utility of CnP between applications. Not having to save to a compatible format and then importing from the other app is a great productivity improvement.

Just saying.

Re: How the clipboard works

#73

Post by db48x »

alkonaut wrote: post #68

What's the reason for this unusual no-actual-clipboard design? The user's mental model of a clipboard is that things are copied to the clipboard, so breaking that mental model has to have a reason? Obviously this is more elegant for several reasons (performance, security/privacy) etc. But still: the fact that it doesn't survive a shutdown sounds problematic. Can a clipboard manager fill that gap completely, i.e. copy…

This design dates back to X Windows (and probably before). It does indeed allow for various optimizations of that sort.

A clipboard manager is simply a program that initiates a paste into it’s own window as soon as any other window announces that it has the selection. It then advertises itself as having the selection, so that the the user can ultimately paste the data wherever it should go. The clipboard manager can persist the clipboard state, maintain a history of recently copied items, etc.

Re: How the clipboard works

#74

Post by wongarsu »

alkonaut wrote: post #68

What's the reason for this unusual no-actual-clipboard design? The user's mental model of a clipboard is that things are copied to the clipboard, so breaking that mental model has to have a reason? Obviously this is more elegant for several reasons (performance, security/privacy) etc. But still: the fact that it doesn't survive a shutdown sounds problematic. Can a clipboard manager fill that gap completely, i.e. copy…

I assume it's meant as a simplification?

For comparison, when you copy something in Windows, for each offered format the software can decide to either immediately give the data to the OS for safe-keeping, or to just announce the availability of data in that format, and generate it on request. The intention obviously being that for example Excel might immediately put the text representation in the OS buffer, but only create the HTML version if anyone requests it. This was invented in a time when those CPU cycles mattered after all.

The wayland setup reads like someone looked at a Windows-like design, thought having two ways clipboard data could be handled was confusing, and decided to simplify it by axing the straightforward path that 99% of clipboard data takes.

Re: How the clipboard works

#75

Post by Beltalowda »

jdsnape wrote: post #69
Beltalowda wrote: post #47

Earlier quoted context omitted.

Are there "clipboard snoopers" out there? Or more specifically, are there clipboard snoopers that access sensitive data they couldn't also access in any other way? It seems to me that if you can access the system clipboard you have enough access to do all sorts of stuff.

Yes - for example https://github.com/slyd0g/SharpClipboard This is designed to work with CobaltStrike, which is a tool used by security testers (i.e. redteams), but also by real life adversaries as well.

So has anyone every used that as an attack vector? Some proof-of-concept code is not hard to write.

Re: How the clipboard works

#76

Post by ygra »

the_mitsuhiko wrote: post #71
ygra wrote: post #54

Earlier quoted context omitted.

Annoyingy, in Excel's case that question "Do you really want to quit? You have copied large amounts of data to the clipboard." even occurs when you have a single cell's worth in the clipboard. But that's also a confirmation question that no one really understands unless they understand how the clipboard works (or can work).

> in Excel's case that question "Do you really want to quit? You have copied large amounts of data to the clipboard." even occurs when you have a single cell's worth in the clipboard That's not correct. You need to have quite a few cells in the clipboard for this to happen. > But that's also a confirmation question that no one really understands The dialog tells you exactly what it is asking for. It gives you three o…

Oh, indeed. I misremembered then. Seems to be that way in my ancient version already as well.

Re: How the clipboard works

#77

Post by ziml77 »

alkonaut wrote: post #70
imiric wrote: post #33

It's remarkable to me how we still don't have a security-minded clipboard implementation, seemingly on any OS. It's standard security practice now to use a password manager, but they all[1] exchange critically sensitive data with applications via the clipboard, which is accessible by any application that asks for it. The best we can do is automatically clear the clipboard after a certain time, but this still leaves a…

Applications also have access to global desktop screen recording, which has similar security issues. Basically: the desktop including all user input, frame buffers etc. was created as a free-for-all with security as an afterthought. It's as if all processes run in the same memory space. I should be able to control which apps can read the screen outside of its own top level window, and be notified when it happens (jus…

macOS actually has these kinds of permissions. The clipboard is still a free-for-all though. I guess that's harder to lock down because it's more than just a simple option of fully allowing or denying access to the clipboard. You would want to be able to paste to any application even if that application can't read the clipboard whenever it wants, but you'd be adding an extra confirmation on every paste if a user doesn't initiate the paste in a way that the OS knows is secure.

Re: How the clipboard works

#78

Post by alkonaut »

wongarsu wrote: post #74
alkonaut wrote: post #68

What's the reason for this unusual no-actual-clipboard design? The user's mental model of a clipboard is that things are copied to the clipboard, so breaking that mental model has to have a reason? Obviously this is more elegant for several reasons (performance, security/privacy) etc. But still: the fact that it doesn't survive a shutdown sounds problematic. Can a clipboard manager fill that gap completely, i.e. copy…

I assume it's meant as a simplification? For comparison, when you copy something in Windows, for each offered format the software can decide to either immediately give the data to the OS for safe-keeping, or to just announce the availability of data in that format, and generate it on request. The intention obviously being that for example Excel might immediately put the text representation in the OS buffer, but only…

I’m a windows desktop dev since the last millennium and tbh never knew that there was an announce api. It seems really difficult to use as a tiered solution where you only return the more complex data when asked. After all, you must then still snapshot that data from the moment the copy occurred to be able to provide a snapshot from the time of the copy later?

Re: How the clipboard works

#79

Post by xerxesaa »

imiric wrote: post #33

It's remarkable to me how we still don't have a security-minded clipboard implementation, seemingly on any OS. It's standard security practice now to use a password manager, but they all[1] exchange critically sensitive data with applications via the clipboard, which is accessible by any application that asks for it. The best we can do is automatically clear the clipboard after a certain time, but this still leaves a…

KeypassXC takes a slightly different approach. It uses named pipes to send the password from the application to the browser extension.

Though the browser is where I find myself using it 95% of the time, they also have an "auto type" feature that will go to the last window and type in your password for you (again, without passing through the clipboard).

Re: How the clipboard works

#80

Post by aumerle »

the_mitsuhiko wrote: post #22
jeroenhd wrote: post #17

For those wondering about how Windows does this, there is, as you'd expect, a Raymond Chen article about it: https://devblogs.microsoft.com/oldnewthing/20210526-00/?p=10... (and some more, like https://devblogs.microsoft.com/oldnewthing/20220608-00/?p=10... ) Elsewhere in these comments there is also a link to an explainer for the macOS equivalent. Here's also an explainer for X11: https://www.uninformativ.de/blog/po…

> It's interesting to look at these clipboard APIs together to see what may have led to the Wayland design If that lead to Wayland then I think people took away the wrong lessons. Wayland's current protocol / API for clipboards is incredibly annoying. It's hard to deal with for applications, it's even harder to deal with for clipboard managers which were not really considered in that design and usually break the clip…

That's generally true of most things in Wayland. It's poorly designed and then badly implemented, by multiple different compositors in different ways, leading to endless bug reports and broken software.
Post reply on HN