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/postings/2017-04-02/0/POSTI...
It's interesting to look at these clipboard APIs together to see what may have led to the Wayland design, which is probably the most recently designed clipboard implementation.
I think the Wayland API is more elegant but also requires a clipboard manager in cases where you wouldn't expect to need tone (to copy less than a kilobyte of data before closing the program, for example).
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 clipboard in different ways.
I have never seen that many bug reports and issues with clipboard behavior as with wayland. If there is a benefit to the design, then it's entirely non obvious to me.
I know you didn't mean anything by this, but given that the entire concept of a clipboard was invented by the Mac/Lisa team (the Xerox Alto didn't have one), it seems wrong to describe it as an "equivalent" to Windows.
The Lisa was the first to name it the "clipboard" but that doesn't really count in my opinion.
Also, modern macOS isn't based on the old mac operating system after switching to Unix, so even for Apple computers the macOS clipboard is an "equivalent" of the old clipboard.
That might be nice, especially if you are just copying a short amount of text before closing the window.
Some time ago I tried to copy something to the X11 clipboard with a Go app, and this is basically impossible as Go can't fork into the background like xclip etc. do, so you need to either depend on a bit of C code or keep the app in the foreground until the selection changes (which isn't really an option for a CLI app).
The essay covers this: it was picked because it means only the pasted data (of the right mimetype) gets copied, so it avoids unnecessary copies. This is especially useful if the source can generate large amounts of data e.g. an image program is able to copy in multiple image formats, in which case said program would have to export everything to the OS on copy.
But yes that also means all the data is lost unless the source program takes extra non-trivial measures to keep the data alive.
This made some sick kind of sense in X11, because all that data might have to transit over the network too if you were using remote X.
Some programs on Windows will present you with this dialog when closing the program:
There is a large amount of information on the Clipboard. Do you want to be able to paste this information into another program later?
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.
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.
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.
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.
Copy/paste are the biggest neglected operations in computing, considering that they are the only universal mechanism for transferring data between applications that is accessible to end users.
Mobile intents do help somehow, but they are not universal or available on desktop or web environments.
Otoh, copy-pasting images or entire files works great, as does drag-and-drop all over the place (dragging things from Firefox's download popup, or from E-Mail attachments).
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, and each new MacOS version makes it creakier. It was broken on Monterey 12.5.1; with Monterey 12.6 it is mysteriously working again, but I know I can't depend on it forever.
I have tried ClipDrop, Clipy, CopyClip, Clips, ClipMenu, Jumpcut, and Qlipper, but nothing has all virtues. The closest I've found is Maccy; while limited to 999 clips, it supports 3 and I can partially replicate 4 with BetterTouchTool's help.[1] I would appreciate suggestions other alternatives, whether free or paid.
[1] Speaking of which, I've never been able to get BetterTouchTool's own clipboard manager to work.
But its not infinite - I think the longest settings is to keep items for 90 days.
The clipboard manager solution seems okay, but copying everything immediately seems like it defeats a lot of the elegance of the design. Perhaps it'd be preferable if the original program held the clipboard until it was about to exit, at which point it would issue a "last call" sort of announcement so that a clipboard manager could optionally "take over" the clipboard. But that wouldn't capture crashes or any app that doesn't send such a signal, so perhaps the aggressive copying is more thorough. But if that's desirable, maybe always copying data to the window manager is the better choice. Presumably Windows is doing this?
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.
The standard web MIME for url(s) is text/uri-list: https://www.rfc-editor.org/rfc/rfc2483#section-5
Still, I would agree with the original statemnt “There seems to be no standard mime type for a URL.” as text/uri-list is for a list of URLs with ␍␊ line separator and #-prefied comments. It would have been nice to have a MIME type for an individual URL with none of that, but it’s a bit late now, for best results anyway.
When you first hear about it, you think "What's the big deal?", but then you quickly find that you use it pretty often.
You can set "dom.event.clipboardevents.enabled" in Firefox to disable all of that, but some websites can break horribly because they just assume it's there and will do $weird_shit if it's not. e.g. Twitter and Facebook messenger for example; it's not that you get an error either, it just behaved in really odd ways. It seems Twitter works now in quick test, and I no longer need to use Facebook Messenger, so let's try setting it again.
There's also "clipboard.plainTextOnly", but it doesn't seem to work, or maybe it does something different from what I expect.
Also with password managers like 1Password using the clipboard as a means to xmit sensitive data it seems to me like the API needs to be updated.
An interesting solution to the problem discussed in the post would be how macOS implements Quick Look in Finder. Apps can serialize a data structure to clipboard and plugins can be responsible for deserialize on paste. This would solve the issue of apps being closed.
Clipboard API should have the concept of sensitive data.
In Windows, pressing Win+V does exactly that.
I wish there was a little more transparency in the clipboard. When I press WinKey+V, Windows 10 only shows me one format but often pastes a different one (obviously) -- would be nice to have the option to allow me to look into the possible formats I can get out.
That would only confuse an average Joe so don't have high hopes.
IMMSMW there was a program what would show which formats are available for the current content, but hell if I remember how it was called and was it a regular program or just an exercise in Win32 API. Maybe it was in Raymond Chen's blog.
But if you are interested you can probably write it yourself.[0]
ADD: there is such a program on codeproject [1] but it requires a registration to download the binary, so I can't vouch for it.
[0] https://learn.microsoft.com/en-us/windows/win32/dataxchg/cli...
[1] https://www.codeproject.com/Articles/886711/Drag-Drop-Images...
Anyway, I will look into links, thanks.
* keep source formatting
* match destination formatting
* text only
ctrl + INS (copy) shift + INS (paste)
IIRC this is a hardware interrupt in much the same way as ctrl+alt+del is. My memory is damn hazy about this (I've used DOS since MS-DOSv3.3) but I think I used that combination back in the DOS days. {instead of using the mouse to select things, shift+CURSOR would do the trick}
This might even be a C=64 trick. I can't remember 100%.
BUT Windows/Linux/BSD _STILL_ honour it's usage. (It's also a handy way to bypass some websites that block right-click & copy/paste.)
I know there are more greybeards on here, so somebody help me nail down from whence CTRL+INS & SHIFT+INS originated.
It doesn't pre-date the C/V/X/Z shortcuts, it's just that those conflicted with things like CTRL-C to interrupt.
I don't think hardware interrupts are involved here. It's not a particularly early DOS convention either, Wordstar-style shortcuts were popular before it.
It's just that that was the de-facto standard before Ctrl+C and Ctrl+V replaced it. Back then, Ctrl+C was the break key, so it wasn't usable.
Even in Windows today, you can still use Ctrl+Insert/Shift+Insert/Shift+Delete in text edit or rich edit controls. Libreoffice even supports it.
Certainly feels like it predates the mouse, considering the innate right-handedness of the key combo.
Android clipboard is broken. I paste out of date content into WhatsApp all the time (while other apps receive the updated 'copy' perfectly fine).
(unless the program crashes, it should go through the "official motions" and one of them should be notifying the server which then can request the clipboard. this should be done early in the shutdown process, of course)
Sidebar: I do at this point use a copy paste history app anyways that saves and plain text-ifies everything.
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 the main uses of copy paste is to transform something to plain text. A clipboard implementation that pasted non-text things would be broken.
This never happens if you only use the unix clipboard. I agree that both methods should point to the same clipboard, but this is an implementation detail. The important thing is the interface: selecting text copies it to the clipboard, middle-clicking pastes it.
Super useful to have two different scratch buffers when moving things around.
Anyway, I use the clipboard mostly to move images I don’t want to save to a file, so I would hate to have them converted to plain text.
I would also be surprised if I copied a text selection from a website into open office and had to manually redo all the bolds and italics.
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 copy an image from Google images and the thumbnail low Res version is copied rather than the full res version.
Copy and paste, and drag and drop, seem to be neglected on the web.
I also think that this is useful. Furthermore you can have separate selections: primary, secondary, and clipboard.
I use xterm, and shift+insert can also be used to paste from the primary selection. Firefox can copy to primary selection automatically and can paste by middle button, but shift+insert pastes from the clipboard instead; I think that it would be better for shift+insert to paste from primary selection and control+V (or command+V would be better; having that a separate key like Mac OS does is better, I think) for paste from clipboard.
Another thing that is helpful, but many modern programs do not do (some older programs do, such as Heirloom-mailx, and vi) that you can enter shell commands to be used by pipes to transfer data between programs (by use of popen function in C). (Some of my own programs have this capability)
I quite like ctrl-c/ctrl-V (or cmd on a mac). Very easy to use while controlling the mouse with the other hand.
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.
ctrl-v and shift-ctrl-v and middle click and shift-middle click and tmux and vim.
The damned system makes no sense! Probably why it feels like home, once you're used to it.
Does the copy-side app have to keep that selection around in memory forever? That seems like a big downside.
> A big upside of this design is that no data is copied around unnecessarily.
That's only true as long as the copy-side app still needs the data, otherwise it needs to save a local copy it doesn't need.
1. If the owning app doesn't need it anymore it does need to keep it around until the clipboard is replaced, but this is likely still cheaper than copying. (For example if you are copying images you just need to reference-count the image, or if you are copying a table in an app with an undo history you are holding that data anyways, you just need to know how to rebuild the old version for the copy).
2. If the owning app is offering to do conversions (for example text/csv or text/html for a table) it only needs to hold one version in memory.
Of course this does add a lot of complexity to do it "well". However the app can always start with a simple implementation (just make a copy/reference count internally) then migrate to a better implementation when it makes sense.
It does seem to me that a hybrid implementation may have been the best. Apps can send data to the compositor (maybe via a sealed memfd) or just tell the compositor to ask for the data when it wants it. Maybe this could even be done per-content-type so that for example the app can send the `text/csv` to the compositor but if someone asks for `text/html` it can read the `text/csv` from the compositor then send back the `text/html`. But that would be an edge case, and still has a problem with closing applications. I guess when the application closes it can either 1. Upload the other content-types proactively before shutting down or the compositor just drops those types off of the clipboard leaving only the types that it holds itself.
Use case is like this:
* A - local computer with Wayland session.
* B - remote computer with terminal neovim running.
I can ssh from A to B and use neovim with clipboard and with X forwarding in ssh that clipboard is synced to local session. But for that I need a terminal that runs in XWayland mode locally when doing ssh and working with remote neovim.
Is there a way to get the same result without X?
We need a secure channel for password managers to pass credentials to applications that a) doesn't use the system clipboard, and b) doesn't simulate the keyboard to type into the password field. All modern OSs fail in this regard, AFAICT.
[1]: Except the ones that function as a browser extension and are used for logging into websites. But using something as critical as a password manager from a browser extension might be an even worse security practice than using the clipboard.
If you have malicious software running on your system, all bets are off. There are many ways it could steal your passwords, since desktop OSes don't sandbox apps like mobile OSes do.
Just one example: you send the password securely to Chrome, but the malicious app just reads the login session cookie from the Chrome user profile files.
Having a secure way of sending a password to an app would indeed be a defense in depth, but fundamentally the system is broken since all apps run with the same permission as the user, thus they can interfere with each other.
I think that's a common and lazy response to many security issues. There are _many_ ways in which a nefarious script or program can run in a "secure" environment and wreak havoc. Think NodeJS or Python scripts, which are typically downloaded from untrusted sources and ran blindly by most people as their own (hopefully) unpriviliged user.
> There are many ways it could steal your passwords, since desktop OSes don't sandbox apps like mobile OSes do.
Well, sure, but isn't securing this one major IMO attack vector an improvement over not doing anything about it? I don't follow this defeatist logic of "well, if you're already running malicious software, you're SoL".
Besides, this clipboard issue is also a problem on mobile OSs, since all apps share a global clipboard. Unless some app-specific workarounds are implemented, as mentioned elsewhere in the thread.
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".
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).
What I want is a native solution provided by the OS that would work for all apps and scenarios.
In Android, it's a case of using a password manager with a built-in keyboard, and having a button available to switch keyboards quickly.
It seems to me that if you can access the system clipboard you have enough access to do all sorts of stuff.
https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
I haven't run into any (that I know of), but it's trivial to write such a program.
> are there clipboard snoopers that access sensitive data they couldn't also access in any other way?
There's no such thing as a 100% secure system, but removing one of the most vulnerable attack vectors is a huge improvement in and of itself.
> It seems to me that if you can access the system clipboard you have enough access to do all sorts of stuff.
Not quite. Currently all applications have unrestricted access to the clipboard. Accessing decrypted credentials in a password manager is only possible by the authorized user, and this can be restricted in a number of ways. Maybe we need a stricter permission system for clipboard access, but I would argue we need to stop using the clipboard for exchanging sensitive data between applications.
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.
