The topic of copying and pasting across qubes via the Qubes Clipboard comes up every now and then. Knowing what is in the Qubes clipboard at any given time seems to be a recurrent concern.
Examples:
I know that rendering the content of the Qubes Clipboard is risky because that data cones from less trusted qubes. The size of the contents is ready displayed (e.g. “87 bytes were copied from…”).
Considering that the qubes names (e.g. work, vault, disp1234) belong to dom0, and that the time at which the Qubes Clipboard was updated/cleared. Could displaying that information in a permanent widget help people confirm that the Qubes Clipboard contains what they expect / that they didn’t miss a step in the copy sequence?
I’m thinking of something in the lines of: “(Qubes Clipboard) contains 87 bytes copied from vault 4 seconds ago.”
The way I see it, its really simple; If i copy something in an actual physical machines clipboard, it stays there and i can paste it lots of times. Like the one im using right now. CTRL-C one time, CTLR-V as much as i like
Its the same for a Qube. If i copy to a Qubes clipboard, it stays there for as many pastes as needed within that same Qube.
If i copy the Qubes clipboard data to the inter Qube clipboard (CTRL-SHIFT-C), then it disappears from the inter Qube clipboard when i paste (CTRL-SHIFT-V) that inter Qube clipboard to a different Qube.
But … much like a real machine, it stays in the original Qubes clipboard.
It does seem to confuse a lot of folks though, I agree. Perhaps this is simply a documentation/terminology understanding? Maybe its that plus a clipboard risk/threat model understanding?
Ultimately, individual machines keep their clipboard. thats the way of the world. The risk in Qubes to the greater good, is sharing a clipboard and inter-qube clipboard takes care of that risk by blanking after ctrl-shift-V.
Oh, the information I was thinking of (size and origin, not the time of copy, but that’s not necessarily a big deal) is shown exactly where I’d expect it (the Qubes Clipboard widget). I had never noticed! Happy to see that actually! (It obviously makes sense to me to show the metadata where possible. )
I’m with you. Once I understand the principle of how the inter-qube clipboard works, it’s simple. It’s just a bunch of regular clipboards with a single one-time clipboard shared among them. It works exactly how you’d expect it to work based on that description. I’m not seeing where the confusion comes from. I think we may need a @ninavizz usability study or something in order to understand why exactly people get confused about this and what to do about it.
One thing off the bat @adw: you clearly have a clear mental model of cut-and-paste functioning within a capability called “Clipboard.” Most users do not have that clarity when the enter the Qubes-iverse. You may have been one of those, but—just an off the bat observation.
From a simple heuristics POV, everything to do with Qubes as a multi-environment system is an unfamiliar mental-model for folks; so things just do need to more visibly get spelled-out to folks, and surface more visibly to folks. There’s also a principle in cognitive science, “Working Memory,” similar to how RAM works on a computer. TL;DR, our working memory can only keep track of so many things… and many of the rough patches of UX in Qubes, exhaust the capacity of our working memories… such that we often lose track of things like clipboard, that don’t feel urgent or immediate in the face of other tasks. Clipboard, I very much place in this bucket. For longtime users with the cognitive equivalent to muscle-memory, who know to keep track of such things, it’s far less of a big deal. But for new users, it is incredibly confusing, and something I’ve not seen people prioritize until they paste the wrong thing into the wrong app or VM.
“Interqube Activities” is also not an umbrella concept we speak to in the UI, or in learning materials, that I’ve been mulling over for some time in the back of my head around how to do, better. Like: a “Clipboard” widget, why would anyone need such a thing? Well, because that’s an inter-qube behavior—yet there are a lot of interqube functions that are handled inconsistently.
So, yes, it is a hypothesis of mine that if we more clearly grouped all interqube activities into the same tray widget, and kept users focused upon it as a key focus area—that could help develop the cognitive equivalent to muscle memory, more quickly.
I’d love the funding to fall from the sky to enable a robust design sprint and user study on this. I’d previously created an issue in GitHub, to also surface Clipboard activity more visibly—including a capture of metadata, and/or just showing a full/purged status indicator at the global and/or per-qube level. This is definitely a chewy design problem.
I agree - I think the use of “Qubes Clipboard” can be confusing and
misleading. It raises expectations of what it will do.
I usually emphasize that it’s a tool for moving data between clipboards.
Sometimes I find users who don’t understand how the clipboard works at
all - if they want to paste in different places, they will copy again
for each paste. Showing them that the clipboard has “memory” is a huge
productivity boost. Very occasionally they will start to worry about
data being retained in the clipboard.
Then, once they understand how to move data between qubes clipboards,
they worry even more about that data being retained.
My point is that this is not a Qubes specific issue - it’s impact is
obvious in Qubes because we separate out qubes, but the problem is
generic. That’s why there are clipboard managers.
Instead of, or while, working to develop a Qubes specific solution,
why not add a clipboard manager as part of a standard install? We could
deliver this now, and it would allow users who want to clear the
clipboard, (and in the Forum we’ve discussed this), a ready means to do so.
Yes, yes, yes, yes! Many of the stumbling blocks I’ve come upon in Qubes, are simply around this multi-environment system requiring a slightly more detailed understanding around the pieces of single-environment systems, than most people have—simply because “they just work” in single-environment contexts, whether or not we really understand them.
Qubes’ clipboard’s non-handling of images, has been a very confusing pain-point for me as a user. While, yes, it does say stuff about “text only” in different places—those surfacing of its limitations feel like “minimum viable disclaimers” that fall short of providing users a richer understanding of The Thing, before then being clear about how This Instance of The Thing works.
I’d also love to learn more about what these “Clipboard Manager” tools are you speak to above, @unman. I’ll totally do some googling on the topic, but if there are reputable or common ones you know about, I’d love some direction from you where to explore.
Maybe I’m just getting old, but images being copiable on the clipboard still feels like a fancy new innovation to me. When did that start being a thing, anyway? I still feel like standard operating procedure for a clipboard is text-only.
I can’t answer for Linux / X systems as I am still relatively now to it
compared with my time on the other systems.
Pretty sure a Mac could C&P images from the start.
I also remember being able to C&P so-called Rich Text (RTF) with images
and formatting on Windows 3.0 some 25+ years ago. Then the whole Object
Linking & Embedding (OLE) thing started, where one could C&P all kinds
of data formats as long as you had something installed that supported
OLE and knew how to handle it.
That being said: it makes total sense to me that Qubes only allows plain
text C&P. Anything that needs to parsed (formatting, images, …) must
be considered ‘untrusted’ and go through a conversion to make it safe
using the tools Qubes OS provides.
C&P is an action to casually invoked to allow it to move unsafe data.
Obviously one can still cause harm by pasting into a website or a terminal.
Qubes could implement image copy/paste in exactly this way, namely by doing the image conversion and inter-qube copy behind the scenes. It would just the slowest copy/paste operation known to humankind.
I’ve never not known copy/paste to handle both rich text formats, and images. That said… Oh Qubes, I love you, Oh Qubes! Let’s not overload The Reasonably Safe OS That Could. Mebbe just communicate a little more clearly and/or smartly about it.
But can Qubes implement the image copy/paste in the same way as the text copy/paste already works? AFAIK the text is not processed anywhere, it’s just given to the other qube as a string of bits.
I might be wrong (and please correct me if I am), but I believe that not making some unsafe operations too convenient may be intentional.
That being said, I believe there is an argument to be considered about providing similar options in the GUI and the command line. Thinking aloud: if qvm-copy allows to copy any kind of file from one qube to another, maybe it would make sense that the GUI copy-paste mechanism could be used for the same purpose?
This does nothing to help people wrap their heads around how copy-pasting between qubes differs from copy-pasting inside a given qube; I think that’s a distinct topic.
All this has drifted quite a bit from the original intention for the topic, that being said, I think the conversation is interesting and I personally don’t mind. (@deeplow if you have thoughts on renaming / splitting the topic, please do what seems best to you!)
It’s obvious from context that I meant “much less safe than converting it to a trusted version.” Or at least it would be, if you didn’t selectively cut off the rest of my message.
Yes, it was perfectly clear from your message. I just wanted to note that upgraded clipboard could be useful without necessarily breaking the current Qubes security model.
Considering that the qubes names (e.g. 
Happy to see that actually! (It obviously makes sense to me to show the metadata where possible. 
)
