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

61–70 of 160 posts

Re: How the clipboard works

#61

Post by swah »

TMWNN wrote: post #16

Might as well ask here. On MacOS I have eight years of clips saved in a SQLite database created by Ondesoft's ClipBuddy. It is, by far, the best MacOS clipboard manager: 1. Unlimited clip storage, with no limit whether by time or space. 2. Search clips. 3. Paste without formatting from the keyboard. 4. Scroll up and down the history before pasting, again with the keyboard. Ondesoft hasn't updated ClipBuddy in years,…

Alfred and Raycast also do that - I use the combo cmd+opt+v to search the clipboard history and then paste.

But its not infinite - I think the longest settings is to keep items for 90 days.

Re: How the clipboard works

#62

Post by Tistron »

enriquto wrote: post #57
Beltalowda wrote: post #49

Earlier quoted context omitted.

> It mostly ends up with me overwriting the clipboard unintentionally with data I don’t care about. I mostly find it really useful for "quick copies", like the quote from your post here. I don't really care if it gets overwritten because it's only relevant for a few seconds. For anything else you can still use ^C/^V on Linux.

> you can still use ^C/^V on Linux How do people stand these particular keybindings? They get so much in the way inside a terminal! They are possibly the worst choice of keys for something as important as copy/paste (if the keyboard is needed at all, but I digress). ^C = forcefully stop the current program ^V = escape to enter the next character verbatim I use these two all the time, and I find it very confusing that…

Yes, the Mac is the only system doing this right

Re: How the clipboard works

#63

Post by Tistron »

aasasd wrote: post #37
londons_explore wrote: post #24

Earlier quoted context omitted.

I find the clipboard increasingly broken for this usecase... Imagine I want to copy an image from a webpage into an email... And then the paste fails because the email client tries to download the image but doesn't have the correct cookies and fails... Or I want to copy a file from Google drive onto a USB. But when you copy from the Google drive webUI it just copies the name of the file, not the file itself... Or I c…

> I want to copy an image from a webpage into an email... And then the paste fails because the email client tries to download the image. Personally I haven't had this problem: just like the article says, the browser ‘copies’ image data with a correct mime-type, and the other app pastes the image if it knows about that mime-type. This is on MacOS, with Firefox. (Though, again personally, I now usually scale the image…

I often find myself taking screenshots of pictures for that reason. It's not webp, but also not 4k.

Re: How the clipboard works

#64

Post by NavinF »

enriquto wrote: post #23
bowsamic wrote: post #19

Earlier quoted context omitted.

Most people want to copy and paste files and images

I understand this concern. But it seems that it would be better to have an orthogonal implementation of this. The clipboard remains text-only. If you select an image or a file, it copies its absolute path (or url) into the clipboard. Then it is the responsibility of the destination program to interpret what to do with this text. If you paste the filename of an image into a plain text editor, you'll get the filename v…

That breaks common use cases such as copy-pasting private images that can only be downloaded using your login cookies.

> If you paste the filename of an image into a plain text editor, you'll get the filename verbatim. If you paste it into an image editor, it opens and pastes the image in there

That's how the clipboard already works on Windows as long as the source application provides both formats.

Re: How the clipboard works

#65

Post by Someone »

imiric wrote: post #27
enriquto wrote: post #18

No word about unix-style clipboard? Select to copy, middle-click to paste. If I had to highlight an immediate usability advantage of linux with respect to windows and macos, it would be clearly this thing. It feels "at home" when you can do this. Also, I have a viscerally strong disagreement with the following sentence: > The majority of the implementations out there are broken and only handle text. For me, one of th…

I don't think having two different clipboard implementations is a usability advantage. Only on Linux do you find yourself in the situation where one application copied to the Unix clipboard, and another tries to paste from the "secondary" (X11?) one. Standardizing on one implementation is the only sane path forward.

MacOs sort-of has that, too. Control-K and control-Y cut and paste to a separate clipboard (at least in TextEdit.app, with its emacs-like key bindings)

Re: How the clipboard works

#66

Post by boole1854 »

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

I just tested this on the latest desktop version of Excel on Windows 10, and I did not get the 'large amounts of data' warning with only a single cell copied in the clipboard (the cell contained the word 'foo'). Increasing the number of cells copied to a large number did cause the warning to appear. I did not investigate further to see exactly how many cells need to be copied to cause the warning to appear.

Re: How the clipboard works

#67

Post by nicoburns »

enriquto wrote: post #57
Beltalowda wrote: post #49

Earlier quoted context omitted.

> It mostly ends up with me overwriting the clipboard unintentionally with data I don’t care about. I mostly find it really useful for "quick copies", like the quote from your post here. I don't really care if it gets overwritten because it's only relevant for a few seconds. For anything else you can still use ^C/^V on Linux.

> you can still use ^C/^V on Linux How do people stand these particular keybindings? They get so much in the way inside a terminal! They are possibly the worst choice of keys for something as important as copy/paste (if the keyboard is needed at all, but I digress). ^C = forcefully stop the current program ^V = escape to enter the next character verbatim I use these two all the time, and I find it very confusing that…

I use a mac, so it's actually cmd-c and cmd-v for me. And ctrl-c and ctrl-v work in terminals as they normally do. Best of both in my opinion!

Re: How the clipboard works

#68

Post by alkonaut »

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 and persist data so that apps don't have to take care of it themselves?

One huge benefit of the no-actual-clipboard design that I can immediately see is the fact that probably 99% of all cut/copy/paste operations are within the same application, and this design allows a shortcut where the data can be cloned as the application sees fit. For example, an immutable data structure can just be added as another reference. If I have two copies of an image resource in my document, I can just use the same image in both locations. With a serializing copy the cost of serialization for the copy must be paid up front because we can't know whether the same application will be the receiver.

Re: How the clipboard works

#69

Post by jdsnape »

Beltalowda wrote: post #47
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…

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.

Re: How the clipboard works

#70

Post by alkonaut »

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 (just like OSes often indicate mic recording). A screen sharing or screenshot app would require the permission and I'd allow it.

Apps that place sensitive content on a clipboard (such as password managers) could use an isolated form of clipboard where only apps that are granted permissions can read. E.g. I copy from my pw manager and when I paste, the OS asks me if I want to allow "Firefox" to read the secure clipboard content from "KeePass".

Post reply on HN