The system clipboard is part of every modern operating system. It lets us copy and paste text, images, files, and data between different applications. Like everything else these days, it’s increasingly getting tied up with other people’s servers (“the cloud.”) So, what does that mean for your clipboard privacy?
The clipboard was invented in 1973, and it was never designed to be secure. It’s a shared area of computer memory used to quickly duplicate information from one app — one data silo — to another. Traditionally, every running process on our computers has had full access to everything that lands on the clipboard. Yet, we copy and move about personal information, passwords, company secrets, and a whole lot more using the same old clipboard without blinking an eye.
New features like cross-device synchronization and clipboard history can be very useful. However, they also make the interactions more complicated and the behavior more unpredictable. It can even expose our passwords and personal data to new avenues of attack from malicious software running on your other devices.
The clipboard has traditionally been unconditionally available to all applications. Android version 10 introduced new restrictions to keep background apps from accessing the clipboard.
The newer Universal Windows Apps (“store apps” or “UWP apps”) introduced in Windows 8 limits access to the clipboard to foreground apps only. Traditional Windows apps — still the most common kind of application — have full access to the clipboard at all times. Likewise, all apps on MacOS have full access to the clipboard. Background apps on iOS have never had access to the clipboard. iOS version 14 even began to display warnings whenever foreground apps access it.
Limiting access to foreground apps is a good security measure that can help prevent third-party apps from spying on the clipboard. However, this assumes that the user knows to clear their clipboard before switching back to the unrelated app. No operating system offers a convenient way to quickly clear the clipboard, though. The user has to copy something else to overwrite the clipboard.
Windows 10.1809 complicated things further by introducing the Windows Clipboard History (a.k.a Cloud Clipboard). The Windows clipboard can now store up to 25 items for up to twelve hours, and optionally synchronize them across your devices. Microsoft hasn’t implemented end-to-end encryption, so, the software giant can read everything on your synced clipboard. Users agree to let Microsoft in on all the secrets, probably without realizing that it’s happening. All UWP foreground apps and all traditional Windows apps can also access your full clipboard history and not only its most recent contents.
Why does the Windows 10 clipboard history clear after twelve hours, though? You may have had important work on the clipboard and trusted Windows 10 to maintain your history from when you stopped working yesterday afternoon to when you picked it up again this morning. Especially when you left the laptop powered on overnight (assuming it doesn’t reboot by itself). The time limit makes sense in theory, but then the user needs to be made aware of it. Things like this can’t just happen on their own without frustrating and confounding users.
Applications can specifically request that some items don’t appear in clipboard history or are excluded from synchronized to remote devices. This decision is left entirely up to the application developers, however. Users have no say, indication, or knowledge of what’s or isn’t going to be synchronized or made available in the clipboard history. It’s best to assume that everything will be stored in the clipboard history and synchronized unless you’ve verified that it isn’t.
Developers need to take great care when testing how the clipboard behaves in different apps, though. How you copy something — e.g. using keyboard shortcuts, context menu, or dedicated Copy button in the app — may yield different results. Each method requires additional effort from the developer to properly exclude it from history or syncing. In my tests, apps often fail to handle copies made using keyboard shortcuts and or the context menu.
Apple hasn’t yet added a clipboard history to either iOS or MacOS. However, the Apple Universal Clipboard synchronizes the current clipboard item between iOS and MacOS, end-to-end encrypted, using Bluetooth, and without involving Apple’s servers. Synchronized clipboard contents expire from the remote clipboard after two minutes.
You may be using the Apple Universal Clipboard daily, and sometimes it doesn’t work. Did you exceed the local or synced data size limit? or maybe the time limit? For most people, the experience will simply be that it “sometimes doesn’t work” and they won’t know why. These limitations are never taught to the user, and they have no reason to go look it up online.
Apple’s operating systems also have options for developers to indicate that the clipboard should be excluded from the sync service. The results may vary depending on how you copy it as application developers are sometimes lazy or account for all the possible ways you might interact with the clipboard. Again, the end-user probably won’t know or understand why their clipboard is or isn’t synchronized using the Universal Clipboard.
You can find plenty of popular third-party clipboard history managers available for MacOS. (Strangely, this concept has never really caught on among Windows users.) There’s a convention among app developers on MacOS for communicating that the clipboard contains sensitive or ephemeral data. For example, password managers use this to inform clipboard managers to exclude copied passwords. This is a voluntary scheme that some apps honor, and it’s not enforced by security policies in the operating system.
This convention isn’t endorsed or supported by Apple but has seen surprisingly high up-take among third-party developers over the years. I tested 22 different clipboard history utilities and password manager, and they all supported the convention. Even the Chromium web browser engine respects the convention to some degree. On the other hand, Apple’s official “don’t sync this” API has almost no developer up-take whatsoever (as indicated by code searches on GitHub).
Things are, as they often are, messier still on Linux. The Linux desktop has spent the last decade transitioning from the legacy X11 windowing system to Wayland. The transition is still ongoing. In short: X11 has no clipboard security, and any application can do anything with it. Wayland limits both reads and writes to the clipboard to foreground applications. Many Wayland implementations empty the clipboard contents when you exit an application, which can be very confounding to users.
But the situation isn’t that black and white. Linux users love their clipboard managers, and different Wayland implementations have added clipboard manager extension APIs. These APIs offer a convenient way to grab the contents of the clipboard. So, how do you know which applications are sneakily accessing the clipboard through these APIs? … well, you don’t. We’re back to where we started.
The Plasma Desktop (“KDE”) is the most popular Linux desktop environment to feature a built-in clipboard history manager (Klipper) and device clipboard synchronization utility (KDE Connect). KDE Connect uses end-to-end encryption between devices running Linux or Android on the local network without involving anyone else’s servers. (KDE Connect doesn’t currently work under Wayland.) Application developers can indicate that something should be excluded from the clipboard history, but there’s no way to opt out of clipboard synchronization when it has been configured.
If you want to remain in control, you can use a security-hardened Linux distribution called Qubes OS. When properly configured, it runs each application in a and isolated virtualized environment. In this environment, applications can’t snoop on each other’s clipboards. To share data across applications, the user must first copy from the source application to an app-specific clipboard. Then, they must copy that to a shared clipboard, paste the shared clipboard into the destination apps’ clipboard, and then finally paste it into the destination app. This workflow is as inconvenient and cumbersome as it sounds. Though, it’s one of the very few options on the market that allows for secure cross-application clipboard handling.
Clipboard synchronization with Android (e.g. KDE Connect or through Microsoft apps that integrate with Cloud Clipboard) devices became a one-way deal after Android 10 locked down background app’s access to the clipboard contents. They can still put content on the clipboard, but not seamlessly copy content from your clipboard and synchronize it to your other devices. This still leaves a vulnerability where passwords can unintentionally leak to third-party apps.
The app you used last and left open on your Android phone will still be in the foreground and have clipboard access. Some apps, especially long-lived “idle games”, can even prevent the display from turning off. They do it to show your more ads — I mean to let you enjoy the time-killing gameplay without having to unlock the phone every five minutes. When you copy something on your computer, it may get synced to your phone where the foreground app has full clipboard access. Depending on your device’s memory- and battery-saving settings, an app may even be considered a foreground app even when the device is locked.
You may feel relatively safe and sound copying your password from your password manager on your computer. Then your clipboard synchronization tool stabs you in the back, unintentionally, and shares it with a third-party app you forgot was still running. The same method can cause problems on Windows and bypass UWP app restrictions. Apple’s Universal Clipboard is only vulnerable to the same attack vector when both devices are unlocked.
Recent versions of iOS and Android has addressed the password manager problem with new APIs for auto-filling data into login forms. These methods bypass the clipboard entirely and handle the data transfer from a password manager to an app more securely. It doesn’t work for all websites and apps, though. So, users must still rely on the clipboard for some websites and apps. The newer APIs don’t solve any problems related to protecting other sensitive or personal information that may linger on your clipboard. There’s nothing comparable for the desktop operating systems.
The modern clipboard is frustratingly opaque and riddled with unexplained limitations and unexpected behavior. How does the clipboard work in this situation? with these two apps? with this device? while that device is charging and is on the same network as the current one? I feel like my head is about to explode just thinking about it. Big tech has rushed to compete on ways to “improve” the clipboard but still hasn’t fixed fundamental weaknesses in the system. It also hasn’t bothered with teaching its customers how the updated clipboard works now compared to yesteryear.
You can’t assume it’s safe, and even highly technical users no longer have any idea what’s going on with their clipboards. It has all just gotten out of hand. There’s no audit-log trail of which applications have accessed the clipboard. You just can’t know if something is monitoring it. Even a highly knowledgeable and technical user no longer has any hope of keeping up with what has access to the clipboard.
You can minimize risks by limiting the number of background apps and services that run on your system. Quit some unused apps before you open your password manager. Does your computer really need so many background services to augment various device drivers? My Windows laptop somehow runs four background services just for the audio driver. It plays audio just fine without any of them running! The fewer programs that run, the smaller the risk of one of them doing something bad behind your back.
Bonus content: Developers, developers, developers
Throughout this article, I’ve mentioned that application developers can hint to clipboard managers that content placed on the clipboard is sensitive and shouldn’t be kept in history or synchronized across devices. This section is a quick reference to how they achieve that. It also explains in a bit more detail how the clipboard works.
The clipboard data source — the application that placed something on the clipboard — is responsible for labeling the data with metadata. In broad general terms, you can put any data type on the clipboard; whether it’s text, an image, a comma-separated list, or something else. You can even put multiple things on the clipboard at once — such as copying both an image, table, and paragraph from a webpage or document. This is achieved the same way it is in email messages: using the multipart MIME (M/MIME) protocol.
Each “part” of the multipart data (even then it’s only one part) is labeled with a content-type indicating what the content is. You’ll most typically encounter text/plain.
The exception from the rule is Apple platforms which use toolkit-specific APIs that aren’t expressed in M/MIME. The below table shows the platform-specific APIs or M/MIME content-types (plus any magic values) that should be present along with a clipboard entry to either exclude it from cross-device synchronization or clipboard history managers. The effect of the various APIs are pretty self-explanatory from their names. You can find more information about each in the sources section at the bottom of the article.
| Platform | API or | |
|---|---|---|
| Content-Type | Magic Value | |
| iOS | UIPasteboard.OptionsKey.localOnly |
|
| Linux KDE* | x-kde-passwordManagerHint |
secret |
| MacOS | NSPasteboard.ContentsOptions.currentHostOnly |
|
org.nspasteboard.ConcealedType† |
||
org.nspasteboard.TransientType† |
||
| Windows 10 | ExcludeClipboardContentFromMonitorProcessing |
|
CanIncludeInClipboardHistory |
0 |
|
CanUploadToCloudClipboard |
0 |
|
- Empty values mean you can use any or no value.
- Supported by Klipper, but not Connect.
- A third-party convention not endorsed by Apple. Also used on iOS.
Remember my warning from earlier in the article about the different methods the user can utilize to copy something! Be sure to test every possible method to copy something from your app and make sure your app sets the expected metadata in all situations.
These APIs only help with well-intended local apps that might otherwise do bad things. They may also help prevent accidental clipboard sharing with unintended recipients running on remote devices.
Make sure to educate your users when you implement any special clipboard handling. It may frustrate them when the clipboard history or synchronized clipboard doesn’t work as they expect. Then again, it may be considered a security vulnerability if these tools do work with your app (depending on the sensitivity of what’s copied). Your only option is to communicate how your app integrates with these tools with the user.