Feature Request: Accessibility setting for globally disabling/enabling the clipboard

Brainstorm
,
1

Feature Request: add a toggle to Accessibility Settings that disables/enables all clipboard functionality globally.

Namely, the toggle would disable/block/continuously overwrite the three possible selections (PRIMARY, SECONDARY and CLIPBOARD) to make any manual cut/copy/paste operations impossible, whether by keyboard shortcuts (CTRL+X/CTRL+C/CTRL+V), by context menu (cut/copy/paste options) or by mouse middle-click.
Considering that every app has their own shortcuts, it’s impossible to globally disable all shortcuts and relevant context menu options within apps, so the best way to achieve this would be to disable/block the selections themselves.

Use Cases: enhanced security data processing, working with cryptocurrency, handling of financial or otherwise confidential data, preventing malicious websites from reading out clipboard contents.

It would allow the system to be used as a kind of dumb terminal for enhanced security/privacy contexts, disabling an avenue for human error (fat-finger errors) and reducing the attack surface for malicious actors.

Also in my case, I have medium-severe OCD, so it would help me greatly in reducing friction in my workflow.

1 Like
2

If you didn’t know, malicious websites cannot read your clipboard without permission :slight_smile: See 클립보드 액세스 차단 해제  |  Articles  |  web.dev

This is more like security theatre, applications can still read the clipboard. On Wayland we could possibly stop all clipboard reading I guess, but I don’t think there’s a real security benefit here.

1 Like
3

I actually didn’t! :astonished:
I assume this is the magic of Wayland then? While I knew that Wayland isolates apps from each other, and only lets them talk to each other securely via portals, I wasn’t aware this applied to Clipboard functionality as well…
Amazingly well thought-out then!

If this gets implemented on Wayland, would it cover Xwayland apps too?

You make a great point about the security benefit, luckily Wayland seems to cover that aspect.

However, there’s still a significant benefit regarding accessibility and security regarding human error: to give an example, when working on anything important or privacy sensitive, I often cannot keep track well of what I interacted with. So I’ll often have moments that are like: “Wait, did I accidentally CTRL+C my password 5 minutes ago? Did I copy it anywhere?”
Or when navigating a website using keyboard controls, while mashing keys quickly, it happens often that I accidentally press one of the CTRL+X/CTRL+C/CTRL-V key combos, and then I have to check whether I copied or pasted anything to the wrong spot. Even when right-clicking a link to open it in a new tab/window, I have misclicked and hit “Paste” instead several times.

There’s an infinite amount of such human error scenarios, and while they are harmless usually, they are a serious problem when working with anything sensitive or private.

The only way to truly prevent this entire error category is to disable the functionality at its root.
With OCD, it truly is hell to have to think about stuff like this regularly, it occupies a significant amount of my capacity just to pay attention that this sort of error doesn’t occur, which I could use a lot better to actually do work.
For me, and anyone else with OCD, as well as anyone in need of enhanced privacy, this functionality would be a very useful “peace-of-mind-button”.

I use Wayland/Xwayland, even as a Wayland/Xwayland-only feature it would be great to have :smile: (especially considering that this kind of feature probably meshes a lot easier with Waylands more modular nature)

I also just realized that it could also make sense to put the feature in the Klipper settings instead of accessibility, either makes sense.

4

If your password manager is smart, it would tell KDE not to record your password in Klipper and also auto-clear. Or perhaps avoid using your clipboard at all :slight_smile:

I don’t see how mistakes like this would warrant an option to completely disable the clipboard though. I could argue that I could accidentally slam my password into a random box on the Internet, so we should be able to disable any keyboard input.

Is it though? If you’re working on a machine where you suspect you have a malicious app running that copies your clipboard contents, maybe don’t run it while working on your company’s financial details. Said app could also read the Excel spreadsheet while you’re working on it as well…

To me it sounds like you just want to disable clipboard history entirely, why not do that instead? :slight_smile:

2 Likes
5

That is essentially exactly what I was thinking of, but just regarding unwanted copy/pasting.

There is an actual usecase for the functionality I described: switching back and forth between an enhanced security context and a regular context.

If you know in advance that your workflow is gonna include a lot of switching back and forth between a secure context and a regular context, it’s much more reasonable to disable the main possible vector of accidental cross-contamination, which is copy/paste functionality, at the beginning, instead of manually clearing the clipboard between every single switch.

Example: working with cryptocurrency or other financial data. You might open one window with your confidential data, and at the same time look up technical instructions in your browser on a forum, while at the same time using a trading platform. In short, any case where you’re working on several things in parallel and switch between them often, while needing to keep them reasonably separated from each other.

The only ways to ensure this otherwise are either to:

  • pay very close attention to not accidentally copy/paste anything, which is distracting and introduces friction, or
  • manually clear the clipboard every single time you switch between two windows/tabs, which would be unreasonably impractical.

In contexts where security is a priority, unneeded clipboard functionality can be a liability instead of helpful, giving the ability to simply temporarily disable the clipboard instead good reason to exist.
It makes the difference between having to worry to prevent mistakes instead of doing meaningful work, and being able to freely use your system to enhance your abilities to their maximum, which also ties into the accessibility aspect I previously mentioned.

Klippers clipboard history doesn’t really matter for this usecase, because even when disabling Klipper, the actual copy/paste functionality within Wayland keeps working just the same, which is the real crux of the problem.

Do I understand correctly that, at least within Wayland, it would be technically possible to implement it?
Would it also work for Xwayland apps?

1 Like
6

Yes, please! Exactly something such as this :100:

1 Like
7

Here’s is the problem’s core, really :grinning:

1 Like
8

What I posted in another thread on the topic.

9

I would LOVE to see you copy-type your wallet addresses by hands. Very secure, such error-proof, much usability, wow

What does that has to do with anything?

Then… don’t Ctrl+C ever again at all? Or check your clipboard content with Meta+V before pasting.

10

I understand the need to protect sensitive data. From this thread, it’s clear that this is the core of the problem. As you write, you suffer from OCD, which is a given context. However, the use case applies to everyone dealing with sensitive data, not only in this context. Therefore, my thoughts are as follows:

  • Separate problem from solution. The problem to be solved is securely working with sensitive data. The proposed solution is to disable the clipboard globally. This solution might seem like a good idea in this given context, but it could have negative consequences for other users and use cases. What if you disable the clipboard for this one use case but need it now for another? What are other solutions and which work best?
  • Don’t mix multiple unrelated problems as this makes it harder to find good solutions. For example, don’t mix the aforementioned security problem with the overall problem of having no track kept (or feeling insecure) about your latest activities or having pasted clipboard content in the wrong place. Rather combine similar problems.
  • Is there serious, reliable research about good interaction practices and accessibility settings for OCD patients? I believe this should be considered before taking any action.
2 Likes
11

You raise a valid point: there are two topics to consider separately, security and accessibility.

On one hand, it would be useful to have the option to turn all clipboards off for an enhanced security context, in order to guarantee no data cross-contamination through human error, as well as serving as an additional mitigation against clipboard-stealing malware.

Qubes OS for example has similar mitigations in place, with each window using a separate clipboard, and copy-pasting between them only being possible by elevating one windows’ clipboard to a higher-order super-clipboard, and then calling it down from that super-clipboard to the second window.
This is almost entirely error-proof, but also sorta too convoluted for a normal context to be enabled all the time.

Then there’s TAILS, which provides a clean slate with each boot, so cross-contamination between boots is no concern.
But it doesn’t mitigate in any way against cross-contamination within a single session, either between applications, webpages or any mix thereof. Also, TAILS is otherwise exclusively geared towards being used in a high security context, making it inconvenient for normal context usage.

For the accessibility component of this issue, it is connected to the security aspect in the sense that better accessibility allows for better functioning within enhanced security contexts and when switching back and forth between normal and enhanced security contexts without having to keep track of cross-contamination.
For example, if you can disable the clipboard, you can use the keyboard in an enhanced security context without worrying whether you accidentally fat-fingered CTRL+C at some point while typing hastily, and then contaminate a normal context down the line.

Of course you could solve that by always being very vigilant about what you input on the keyboard, and then check Klippers history every single time you switch between applications.
But in practice, that is untenable.
It sounds exhausting just reading that, right?
Now imagine what it’s like when your brain runs on manual shift mode all the time.
That is what OCD feels like, and stuff like this feels especially bad.

I also thought long and hard on whether there’s easier ways to tackle this problem, like disabling clipboard functionality per-app. The problem is that individual apps might have settings that override outside settings if the functionality is still there, turning it into a game of whack-a-mole and not providing any certainty.
A similar situation occurs when disabling middle click paste: firefox exposes a separate setting within about:config that needs to be turned off in order to actually disable the functionality within firefox.

If i want both a dynamic workflow that allows me to use applications in different security contexts either alongside each other or in succession and a friction-free workflow that allows for peace of mind, the lowest common denominator, and easiest available solution really is just temporarily disabling the clipboard entirely maybe with a toggle in Klippers settings.

Another point would be whether this global toggle could work for wayland-apps only, or also for xwayland-apps.

Either way, I know it might sound like an odd proposal, but I assure you I’m entirely serious about it, and that it does affect me and others with OCD noticeably in everyday usage of their computers.
This is the most straightforward solution I could think of, and I have never found any proper solution for this issue otherwise.

I love KDE, and it has certainly made computing much more accessible to me than any other DE I’ve ever tried, it almost seems to think the same way I do!
If there’s a solution for this, it would truly mean the world to me!

That being said, I understand that KDE is undergoing a lot of transformations recently, and that this wouldn’t be a high priority issue compared to the other stuff being improved right now.
I just want to note it down properly so you can all understand where I’m coming from with this.