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).
> 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 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.
X11/ICCCM clipboard semantics (which is arguably the same design, but with the server being part of the data transfer) was also source of many bugs and the applications/toolkits did not get it right until 00's and linux-centric desktop environments. IIRC disagreement about how to integrate Emacs' concept of kill rings with X11 selections was one of the major reasons for Emacs/XEmacs split.
X11's model for 'cut buffers', 'primary', and 'clipboard' is a historically bad design.
Like very easily in the top 10 worst designs in computer science history.
The fact that it managed to work at all is a testament to the millions of man-hours people were willing to pour into polishing a turd to make Linux Desktop a reality.
If we had the ability to go back in a time machine and do it again it is now painfully obvious that X11 should of been completely abandoned by the mid-1980s. This would of saved a huge amount of heartache.
Cut buffers are different thing than selections and cut buffers are deprecated and probably not used by anything written in last 25-30 years.
On the other hand cut buffers are so simple that there isn't any of the complexity as with selections. But still I think that the ICCCM/Wayland model of selections is the only sane way how to implement clipboard, because it does not involve creating some kind of shared state of potentially unbounded size and consuming potentially unbounded CPU time doing that even if it will not be used.
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.
What's so frustrating is that this is my Linux desktop experience since I have been using it. Clipboards not surviving shutdown where at one point not working, then a bunch of people got together to fix it up and now it's broken again. My Wayland experience is a massive flashback to 2004.
Yes, I know. I remember several years ago being super excited about Wayland. But every time I have tried it, it just falls over in so many different ways. I have given up.
About copy/paste in particular, I have solved it for myself because I work almost exclusively in the terminal and the browser, both of which stay running all the time and therefore acts as a clipboard manager for any copy/paste that happens in it. I am just waiting for my terminal of choice to get support for copy/pasting arbitrary mime types, which its maintainer has said he is going to implement.
> Elsewhere in these comments there is also a link to an explainer for the macOS equivalent.
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.
I don't think it was the Apple Lisa that had the first clipboard. Xerox definitely had a clipboard and other experimental environments had them as well.
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.
> I don't think it was the Apple Lisa that had the first clipboard. Xerox definitely had a clipboard and other experimental environments had them as well.
Larry Tessler coined the terms "copy" and "paste" (basically just mark and yank) on early Xerox text editors. But AFAIK the Lisa group invented the Clipboard as a general storage mechanism for a variety of data types: and they certainly they coined the term. Here's a message from Bruce Horn, who is about as authoritative as it can get:
> 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.
Meh. The current MacOS clipboard is an amalgam of the NeXTSTEP pasteboard and the Carbon clipboard (derived from 9).
This design has the really annoying situation that applications closing down can't leave stuff in the clipboard. This results in a quite a frustrating behavior for users and also makes command line tools tricky. wl-clipboard lets you pipe text into the command to copy. The way it works is that it daemonizes in the background to fulfill the copy request. It either cancels on the first paste (command) or until some other application copies something into the clipboard. It's not completely awful design, but I'm surprised that the protocol does not offer at least the option to move content into the clipboard and exit.
It's disappointing to see Wayland copied X11's annoying clipboard semantics. I've been using X11 for so long I'm used to it now, kind of, but it still regularly bugs me or leads me to accidentally "lose" some things.
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).
> That is kinda insane thing to say. That is like trying to claim that you can't do threads in C++ because you can fork.
If you have more than one thread the only thing you are allowed to call after fork() are async safe functions and only the calling thread will make it into the forked process. Go uses a multi threaded runtime so the state of the runtime will be in an absolute mess in the child process. There generally is no sensible way in which an application can fork after a second thread has been created and how bad this gets, depends very much on the situation. But yes, the same problem applies in any programming language after multiple threads were created.
As I understand it, the problem is that the Go scheduler uses threading to schedule the goroutines, and fork(2) says: "the child process is created with a single thread—the one that called fork()", so your fork then lose access to the scheduler.
Or something along those lines; it's been a while and this kind of stuff isn't really my expertise. I'm sure it's not literally impossible, but I wasn't able to get it to work in a reasonable amount of time so I just shrugged and exec'd xclip instead. The C++ runtime is tiny in comparison, and doesn't do anything like the Go scheduler. I think in general it's just not really considered much of a priority. Modern service managers don't really rely on processes to "daemonize" any more, which was always a bit hacky, and in my 8 years of Go this is the only time I ever wanted to do anything like this.
Go also had trouble with setuid() for the same reason (it would only get set for the current thread on Linux), although IIRC that's long since been fixed (this was around Go 1.5 or so).
Usually programs fork() before they do anything that requires threads. To have the program in the "foreground", just fork and wait for a kind of signal from the forked process and exit only when that arrives.
I don't get it (Windows user). If I copy some text in the browser and then close the browser the clipboard is gone under linux? How is that good design, wouldn't it be preferable if the OS is holding the clipboard data as a middle man?
> I don't get it (Windows user). If I copy some text in the browser and then close the browser the clipboard is gone under linux? How is that good design, wouldn't it be preferable if the OS is holding the clipboard data as a middle man?
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.
It's horrible design. It's basically an omission of one of the most critical parts of how the Windows/macOS clipboard APIs actually function where data can optionally be frozen. For whatever reason the wayland folks thought they can get away without that functionality and from what I can tell (as user and developer) you can't.
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.
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.
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?
You snapshot the data in your application's native data format, then you can convert it later to the best match for the consumer.
Taking the Excel example form above: You got to store the cell layout and values. If it's pasted into a different excel sheet you pass that structure over. If it is pasted in a richt text editor it is converted to some richt text table format. If it is pasted to a plain text editor it is made tab separated or something and if pasted into an image editor it is renders into a bmp (well, Excel doesn't do that, but imagine ...) Doing all those conversions beforehand, just due to pressing Ctrl-C, is expensive as most of the time none is needed.
- If the copied data is pasted in the same Excel instance, then the system clipboard isn’t used at all and native Excel objects are pasted.
- If data is pasted in an OLE-enabled application (e.g. Word or PowerPoint), then an OLE-specific method is used.
- If the data is pasted into another Excel instance or into another application, then the system clipboard is used, but without the possibility to transfer native Excel objects, only csv, RTF, html, text, image, or an ancient spreadsheet-like format called SYLK.
True, but doing it "right" (especially considering 1990ies hardware) isn't easy. And Windows has the option, to just pass it to the system, if you don't have complex needs (only copying plain text etc.)
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.
You'd expect the Wayland design to improve on that to allow clipboard managers to work 100% reliably and efficiently by only being able to take over the clipboard just before the previous owner closes - just like how Windows does it. Better yet would be to integrate that behavior into the server.
You don’t want to integrate it into the server, because that limits choice. There are a lot of features that you could put into a clipboard manager that not everyone would want, and you don’t want to force everyone to just have the least common denominator of those features.
For example, one commenter pointed out that he uses one that keeps a permanent database of everything he has ever copied. Maybe you want to sync your clipboard between computers, while I just want mine to keep the last 10 clipboards and throw away the rest. (Actually I use Emacs which has it’s own internal kill-ring, so I don’t use a clipboard manager.)
I'd want the server to provide the baseline functionality to keep up the illusion that Ctrl+C copies into the clipboard, even accross application restarts. That doesn't preclude additional clipboard managers that do more (e.g. history) on top of that.
“… 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.
> The majority of the implementations out there are broken and only handle text.
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.
In Windows-land I'm more annoyed that lots of applications default to pasting rich-text, when in 95% of cases I only want the text and not the formatting.
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.
The "closing the app after copying and before pasting" case is very interesting. Shows how even things that sound simple turn out to have very tricky edge cases as soon as you start optimizing and really thinking about how to implement them.
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?
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.
> 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.
Doesn't Microsoft Office still have a button in the bottom-right of the Cut, Copy, Paste section of the Ribbon (subtitled "clipboard") that opens a big Clipboard side panel?
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.
My life was significantly improved when I discovered control shift paste, which pastes just text without format. But un-desired formatting of text remain the bane of my life.
Off-topic, but a somewhat similar experience for me was learning about Alt+select. Allows you to select parts of a hyperlink without actually activating the link. (At least in Firefox.)
When you first hear about it, you think "What's the big deal?", but then you quickly find that you use it pretty often.
So essential - how often would I want the formatting in the obviously completely different context? I used to paste things into the URL bar to remove formatting. I've discovered a colleague does the same.
You might want to be careful about pasting anything remotely sensitive into the URL bar as most browser automatically send your query to the search engine for auto-complete functionality.
I never changed my habits from Windows; I use the Run box, or type leafpad / mousepad. It's interesting that we've independently invented the same technique.
GitHub started mangling text some months ago and it bugs the hell out of me. It's also completely unnecessary as GitHub already links things like @user, #123, and deadbeef (for commit hashes). I just want to copy the exact literal text I see; why does that need to be hard?
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.
This contradicts how I as a user think of the clipboard. The clipboard is the most important feature of end user computing that is ignored by OS designers. I should be able to open a window and see all things in my clipboard.
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.
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.
> 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.
None of which quite do what they say, in my experience. For actual text-only pasting, I often end up pasting into a fresh notepad, then copying that and pasting into Word. Otherwise, newlines at least sometimes get altered. Similarly "match destination formatting" often gets confused by formatting changes within the pasted text. I often end up pasting even formatted text via notepad and then recreating the formatting by hand.
I'm surprised there was no mention of copy/paste that existed BEFORE ctrl+c/ctrl+v
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.
You use the mouse left handed, then? I'm left handed myself and briefly tried that back as a youngster in computer lab but never really adjusted to it well enough to continue doing so.
I definitely saw some of that keybinding in old DOS programs, but when I started using a microcomputer, the WordStar shortcuts (Control-K based scheme for copy/paste) were the most common.
This design could have an interesting security twist to it. The copy side could maybe infer who the paste side is and change the output, similar to the problems of piping curl into bash.
Why can't the server inherit the clipboard from the program being shut down?
(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)
Given how much memory we have available these days, would we build it the same way? Having copy paste usually work outta the box everywhere might be more valuable than memory savings.
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.
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.
> 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"
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.
Well, of course; why would you want to keep the initial clipboard forever? This is exactly the same behavior as for ^C/^V. I don't understand the purpose of your question.
Imagine you install a 'clapper' in your bedroom to control the lights. You say "works great for me, let's install this everywhere". Someone responsible for an auditorium then says "so clapping turns the lights on and off?"
That said, I frequently use text selection as a highlighter. I will highlight lines as I'm reading text to help me keep track of which line I'm on. I also need to select text to apply formatting such as bold or add link.
I have literally never run into applications mixing up the clipboard and selection on Linux - its always CTRL+C->CLIPBOARD->CTRL+V and select->PRIMARY->middleclick.
Super useful to have two different scratch buffers when moving things around.
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)
For a while a lot of distros started suppressing the Unix clipboard. Not sure if that's still a thing, but drove me crazy because it's just muscle memory for me now.
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 verbatim. If you paste it into an image editor, it opens and pastes the image in there. But from the point of view of the clipboard it's always just text (maybe with some textual markers).
But I already downloaded the image, I don't want to download it again. What if I want to copy a subsection of an image from an image editor, there is no textual representation as it is not a file on disk.
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.
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 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 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 and convert to webp before sending in a chat—I don't do much email. This way I'm avoiding 4K 4MB pics. I'm probably gonna make me a browser extension to do this automatically.)
You're right however that drag-n-drop doesn't work so smoothly yet.
If they don't understand the difference between copy pasting HTML with an image inside the tag soup (select with mouse a bunch of text and image and right click copy) and an image (hover image and right click "copy image") then there's not much anybody can do.
Do you want clippy in the browser "looks like you are trying to copy an image" ?
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)
> 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.
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 they have a different meaning in other contexts.
The Linux clipboard feels like home to me too, but let's not kid ourselves. Between primary, secondary, and clipboard, it's part of the learning cliff (cos it's steeper than a curve) that is linux. It's totally inscrutable!
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.
If the copy-side app is supposed to serve the selection whenever requested, then what happens if the user interaction causes the selection to change or be removed? e.g., editing text or navigating to another page
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.
I think you are right but it is still an optimization in the common case.
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.
Is there any good solution for remote clipboard sync with Wayland session?
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.
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 wide window for any application to grab the contents. And if you're using a clipboard manager, the standard on Linux DEs, then you have to remember to clear it from there afterwards as well, and suddenly your clipboard manager is a very attractive honey pot.
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.
> which is accessible by any application that asks for it
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.
> If you have malicious software running on your system, all bets are off.
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.
> isn't securing this one major IMO attack vector an improvement over not doing anything about it
Unfortunately securing this attack vector is costly - in the sense of annoying the user with prompts and access grants.
This is why even on mobile as you noticed, only browsers require user confirmation before allowing webpages access to the clipboard.
You could maybe do something in between, like not allowing clipboard access to processes which don't have a foreground window visible to the user.
But in practice, this attack vector is not exploited. If you are targeted, it's much more likely that a specific attack against the password manager is used, since it will extract ALL passwords, and not need to wait for one to show up in the clipboard:
> KeeFarce allows for the extraction of KeePass 2.x password database information from memory. The cleartext information, including usernames, passwords, notes and url's are dumped into a CSV file in %AppData%
> Unfortunately securing this attack vector is costly - in the sense of annoying the user with prompts and access grants.
You're making assumptions about what the implementation would be. There are many ways the UX could be unobtrusive. Besides, I'm not even proposing that the solution should be to restrict access to the clipboard. I'm just saying that there should be a secure channel between apps provided by the OS that can be used for these purposes. Designing and implementing that would be costly, sure, but I'm not an OS designer, and merely speaking what I would like to see as a user.
> But in practice, this attack vector is not exploited.
Of course it is[1]. It's not even an exploit, but an abuse of a glaringly insecure OS feature.
> If you are targeted, it's much more likely that a specific attack against the password manager is used
Again, why are you minimizing this clearly easy to abuse OS feature by comparing it to much more sophisticated exploits? Yes, there are other attack vectors. This thread is specifically about how the clipboard is trivially abused.
> Again, why are you minimizing this clearly easy to abuse OS feature by comparing it to much more sophisticated exploits
You need to think like an attacker. If you gained a foothold on a machine, maybe for a limited time, do you wait until the user happens to login to their banking site by copy pasting the password, or do you comb the machine for everything valuable - files, cookies, password manager databases, ...
If you are sniffing the clipboard you are actively malicious, but then you limit yourself to low gains?
Note that most of the trojans listed in your link are fully featured, sniffing the clipboard is one of the many attacks in their menu.
You are right that it is an attack vector, but it's not a particularly bad one. Microsoft did implement various restrictions which annoy the user, and did implement some protections against common attacks - ransomware file protection, but did nothing regarding the clipboard. Which means that in their cost/benefit analysis it did not stick out as a priority.
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".
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.
I think the solution can be quite simple: allow the user to configure secure channels between apps, sidestepping the main clipboard altogether. So that if e.g. a password manager is configured as source, and the browser as destination, have an option in the password manager to send a password directly to the browser. There would be no intermediary storage like the traditional clipboard, and no typing with a virtual keyboard, just apps communicating directly via a secure mechanism provided by the OS, and configured by the user.
This is already possible by using named pipes on Linux[1], but it has to be built specifically for each app, and anything can go wrong with the implementation. It seems like it would be relatively simple to have this functionality built into the OS.
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).
I think those are workarounds with questionable UX. Whereas something as security sensitive as credential access should have a native OS-provided workflow that's secure by default.
Drag-and-drop seems to have an excellent UX. The semantics are incredibly clear: Take this data from this app and put them into this container in that app. Any insecurities would be an accident of implementation rather than part of the core design like with copy-paste.
Or, how is drag-and-drop insecure by default, and what alternative do you propose?
I'm not saying that drag-and-drop is insecure, but that it's not an ideal UX. I, for one, don't enjoy using it on any OS, and I guess I'm not alone.
The alternative I propose is a native solution from the OS to pass data securely between applications. Not workarounds like drag-and-drop or built-in app keyboards that force me to change my workflow.
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.
There are known cases of malware clipboard snoopers which replaced bitcoin addresses with attacker controlled ones, so if you copy/pasted an address to send bitcoin to, you would end up sending it to the attacker.
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.
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).