How the clipboard works
whynothugo.nl
whynothugo.nl
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.
They have still not gotten it right. I still sometimes experience the clipboard losing things on modern Ubuntu.
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.
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.
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.
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.
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:
https://lisalist2.com/lisalist1/1796.html
> 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).
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).
Of course Go can fork processes.
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).
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.
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.
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.
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.
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.)
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.
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.
God its so annoying to tab back to the sheet to hit Ctrl-C again.
- 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.
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.
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.
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.
- If the text to sanitize is a single line: Win+R, paste, select all, cut, Esc (to close "Run" window)
- If it's multiple lines: Win+R, notepad, Enter, paste, select all, cut, Alt+F4 (to close notepad)
On Linux, I usually switch to Emacs, switch to a scratch buffer, then do the paste-and-cut-again dance in it.
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.
When you first hear about it, you think "What's the big deal?", but then you quickly find that you use it pretty often.
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.
* keep source formatting
* match destination formatting
* text only
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.
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.
Certainly feels like it predates the mouse, considering the innate right-handedness of the key combo.
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.
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.
> 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.
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.
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" ?
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.
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.
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.
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.
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.
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.
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.
^V is probably rare enough that it's not a big deal, but ^C is indeed an unfortunate conflict.
I don't find it too hard to remember to use Ctrl+Shift+C/V in terminals (when I don't just use the primary selection).
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)
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.
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.
Or, how is drag-and-drop insecure by default, and what alternative do you propose?
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.
It seems to me that if you can access the system clipboard you have enough access to do all sorts of stuff.
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.
I think a permission system for the clipboard would be pretty awkward UX, and not really worth the effort for the (hypothetical) problem it's solving.
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.
https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
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".
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.
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.
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.
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%
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.
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.