Qubes Clipboard™ is painful

I was under an impression that the clipboard can only handle text?

Even text can be tricky, especially if it contains unicode characters. You are unlikely to convince anyone that dom0 should display the content being copied.

After I’d seen them couple of times I’d not be able to remember them, but I’d for sure be able to tell if I’m pasting the correct one.

That’s a fair point for frequently used passwords.

2 Likes

It’s a good thing I’m not trying to convince anyone then ;). But if I were, I don’t think that many people would oppose having and option to have the contents of clipboard displayed in dom0, since they can just choose not to turn it on if they are worried about their displays being monitored (pun intended).

However what I think you meant is it’d be hard for me to convince people to have the clipboard contents processed in dom0 which sure is a bit of a different story. Even though I’m slightly tempted to argue about factual security risks involved I don’t really have to, fortunately, since we are talking about Qubes. If we have data that we don’t trust but have to process in some way we can do what we do all day long anyway - make a new vm for it. You could (from what I can tell fairly easily) set up a new system vm that’s sole reason for existing is interpreting clipboard content. Use a specially prepared monolithic kernel and it could be fast enough to reboot itself after interpreting content without you noticing. You lose few dozen megabytes of ram at most.

1 Like

(removed " - here’s how to get a relief" from the title as it hinted at reducing the security)

just a vote for the super-c super-v bindings, versus ctl+shift…

its not just the number of keys, its the muscle memory / co-ordination involved. Super is right next to ctl, so the hand/fingers basically need not move for intra-App copy or paste.

Also, returning ctl+shift+c/v to terminal’s rightful solitary claim to the throne in bash is worth even more, for me.

1 Like

I think there was some enhancement request on qubes-issues requesting that. Shouldn’t be too hard to implement.

Btw Ctrl-V should be possible by putting /etc/qubes-rpc/policy/qubes.ClipboardPaste to “allow” for those like the OP who don’t want clipboard security.

2 Likes

It’s always questionable to interpret what someone else has said when
their meaning seems plain.
You make it sound as if the option would be “display by default”, and I
would oppose this. If the display were opt in, I wouldn’t use it. But
some people would.

You do know that the keybindings are configurable in /etc/qubes/guid.conf ?

The discussion went from “It definitely should not be processed by dom0.” to “You are unlikely to convince anyone that dom0 should display the content being copied.” in the span of two posts. There is a huge difference between processed and displayed with actual security implications. I described them in the very next post. What’s so questionable about that?

I tried to use the word “option” as many times as possible without making it sound funny to the reader, but just to be perfectly clear, yes I do think it should (could?) be an option. If it was on by default I’d be the first to complain.

One thing I realized I dislike a lot is how Qubes notifies you about clipboard operations - it uses the same message area that it uses for everything else. Which makes sense when you think about it at first. But in reality, (at least in my experience with running a lot of vms at once, some of which might not even start and just throw out an error), it’s actually pretty hard to notice you missed an action. Especially if you are tying to paste few different thing to few different destinations in a hurry. One somewhat easy (I think…) fix would be to have the mouse cursor react to clipboard actions in some way. Changing colors and/or animations are probably off the table for a lot of people and for good reasons too. But how about small icons popping up next to your cursor? You could have one icon when something gets copied to the clipboard and another one for the paste/wipe. It’s only two icons so they could be monochromatic and just two simple but distinct shapes.

However what I think you meant is it’d be hard for me to convince people to have the clipboard contents processed in dom0 which sure is a bit of a different story.

Displaying is processing whether you want it or not. For instance, if you are copying something that has Markdown markers, you have to make sure it won’t get interpreted by chance. And that’s not even getting into something like unicode and other things.

If we have data that we don’t trust but have to process in some way we can do what we do all day long anyway - make a new vm for it.

Making this efficient could be a little bit of a challenge. But this could be a good community contribution if you interested in exploring this further.

2 Likes

I didn’t expect my words to be that deeply analyzed. This clearly counts as processing :wink:

I agree that this far from perfect. Personally, I think I would love to have a Filecopy style window that would tell me where I’m copying data from and ask to which qube I want to paste it. This is probably not difficult to implement, but I never got around this. At least this would make it more difficult to paste things into a wrong qube.

1 Like

You can get involved here:

3 Likes

Honestly I was just about to straight up say no, since I feel like I’m way to new to Qubes to start making changes. But then I looked at the source code and honestly I’m going over and over this in my head and can’t really imagine any serious obstacles? I’m probably missing something very obvious.

That said I’ll probably still pass on this for couple of reasons: for one I’m a lazy leech and if I were to do some actual work there are subsystems that need much more love than the clipboard (cough cough firewall? cough); and what’s there already is working.

But honestly my main problem is I don’t think I’d be comfortable using any software that accepts PRs from me :wink:

It took my brain an embarrassing amount of time to process this joke :expressionless:

Thank you very much for this!

2 Likes

I created shortcuts in Keyboard → Shortcuts:
/bin/bash -c "sleep 0.2 && xdotool key ctrl+c && sleep 0.2 && xdotool key ctrl+shift+c" for copy and write to interVM-clipboard
/bin/bash -c "sleep 0.2 && xdotool key ctrl+shift+v && sleep 0.2 && xdtool key ctrl+v" for read, wipe and paste
And it’s working sometimes! Not smoothly (to the point of “unusable”, 50% times it’s just does not work and idk why) and some apps are ignoring these methods, but still.
Probably I could achieve same goal more smoothly with xte\xkb\ahk\xbindkeys\etc but I’m afraid of installing anything in dom0.

I’m sure there is a more proper way to do this, but two comments:

  1. One reason this might not work is that your modifier key (Win?) for this is still depressed while the script is being executed. Just for testing if you increase the first sleep to 1 second and make sure that you don’t press any keys when this is executed, does the situation improve?

  2. There is the danger that the focus changes between the two executions of xdotool (by the way, you mistyped it in the second script). I believe there is a way to get the window ID first, and then send both keystrokes to the same window.

2 Likes

by the way, you mistyped it in the second scrip

thx edited (typo cause there’s no way to copypaste from dom0)

One reason this might not work is that your modifier key (Win?) for this is still depressed while the script is being executed.

Actually I tried it with Ctrl+Alt+,. and Ctrl+C\V (but concern on key being pressed is still reasonable).

Just for testing if you increase the first sleep to 1 second and make sure that you don’t press any keys when this is executed, does the situation improve?

0.2: Paste working, copy doesn’t
1: Paste working, copy doesn’t
1 but trying to depress on copy real fast: TOTALLY WORKS. Thanks.
I changed delays from 1s everywhere to 0.2 + 0.2 on paste, still works. Copy does not work on 1 + 0.2 or 0.2 + 1, 1 + 1 only. Tried Win\Meta\Super+C\V, also F7\8+C\V, same result on delays (copying does not happen, but writing to interVM-clipboard maybe does, there’s notify about it).
Maybe only first emulated shortcut is messed by trigger key(s), if second working properly? Aaaaand yes that’s the fix. /bin/bash -c "sleep 0.1 && xdotool key ctrl && sleep 0.1 && xdotool key ctrl+c && sleep 0.1 && xdotool key ctrl+shift+c" perfectly works.
But with Ctrl+C as a trigger this does not work at all, also this keystrokes sequence can stop stuff if you’d try to copy text from terminal. Maybe there’s some console way of copying in VM’s clipboard? Still win though.

I believe there is a way to get the window ID first, and then send both keystrokes to the same window.

It wouldn’t work if focus changes after emulated end copy and before physical start of paste. So only protection from change focus after (start of?) physical keystroke and before emulated keystrokes (which is time-possible because of two waits).

In my opinion Qubes Clipboard should hold its security aspect like now even if it changes in future. I don’t like the idea of sharing my VM clipboard to directly Global clipboard without any manual method ( like now ctrl+shift+c). But showing the content of clipboard by any tooltip can be helpful (But I think that might increase attack surface because of parsing?)
In ANY case I don’t want to mess with Security of my system, I can afford losing some usability.

2 Likes

How about a notification that shows the clipboard transaction by source vm to destination vm. This only shows vm names not the actual text copied.

This could look like file copy between VMs and thus would help to look moreconsistent.

FY(& others)I: If you click the Qubes Clipboard widget, you should see “Copy dom0 clipboard”…

4 Likes

@IHavNoRamAndMustQube if there is a way, it’s in the docs :wink:

3 Likes