Improve Clipboard Experience

[ninavizz]

The problem you're addressing

• OpSec fails when using Clipboard happen too often, from users of all skill and experience levels.
• Existing clipboard experience is a bit clunky, in general.

In more detail For users new to Qubes and to seasoned users with imperfect motor skills (so, anyone with too much coffee or too little sleep, or just being human) it is easy to mess-up the 10-key combination of keystrokes required to successfully cut-and-paste from one VM to another VM, through the global clipboard. A failed cut-and-paste can result in any number of operational failures with petty to severe security consequences for the user.

Bigger-picture, this is a difficult interaction design problem to solve for that will take many months to develop the right solution for, before a single line of code is even touched.

Immediately, however, it has been suggested that simply granting immediate visibility to users into the contents of the global clipboard from the System Tray, could provide value as a step towards remediation.

At a minimum, it will passively surface to users when their keystroke commands are successful vs not, and what, exactly, is the status of the Global Keyboard. Without requiring the user to always first click on the icon in the Tray menu, to look at its contents.

Describe the solution you'd like UX Caveats:

• The layout of the tray icons will need to be cleaned-up, in order for this to work.
  • When everything is "bunched up" and too busy, as today's tray is, passive indicators are unlikely to succeed in what is visually overwhelming in all the colors, pixels, and some confusing semiotics.
  • Kill the white background rectangle, and added padding to the left and right of each icon, are the two strongest things that need doing.
• A majority of the Tray icons that exit today, will need to be replaced by cleaner monotone and high contrast icons, for a visual indicator to passively catch the attention of the user.
  • Of course, a more visually obnoxious solution could be pursued—but that would introduce a ux regression.
  • Included in the below mockups, are in-progress versions of icons to include.
  • Alternately, the high-contrast icons could simply be set to be the OEM default.
  • Updated icon design stuff, tracked here.

Stretch Goal: Surface more info directly in Tray, via a hide/show option in the Menu

Where is the value to a user, and who might that user be?

• Any users with flesh-and-bone fingers controlled by a human brain.
• Anyone who cuts-and-pastes sensitive content between qubes, such as passphrases, confidential information among high-risk individuals, etc.
• Users new to Qubes and adapting to Qubes paradigms
• Existing users simply being human
• Users who use many different computing environments, including Qubes, who cannot remember allthethings all the time, and are more prone to make mistakes.

Describe alternatives you've considered Lots of options; all of which need more time and user research, to sufficiently not suck.

Additional context Discussed in email thread already with Marta, as concern that was raised with other Qubes users I'm working with.

[ninavizz]

...also on the fence about using a literal clipboard, or the more colloquial semiotic of scissors, as an updated icon for Clipboard. Many non-techy users do not know what "clipboard" means, and thus a pair of scissors may be more intuitive for them. While Qubes' existing users are, yes, mostly developers, user growth among less techy but still threatened folks cd be nice. For them: do we want to push a clipboard semiotic, or no?

For any users: is one just nicer than the other?

Suggestions welcome!

...with "populated by stuff from a yellow qube" indicator:

...when clipboard is empty:

[marmarek]

At a minimum, it will passively surface to users when their keystroke commands are successful vs not, and what, exactly, is the status of the Global Keyboard.

Regardless of the whole idea in this issue, we already have notifications about global copy/paste, exactly for this reason. It looks like this:

Note the notifications are handled by clipboard widget, so if you have it disabled, you won't have them either.

[SvenSemmler]

@ninavizz first of all I love your idea of getting rid of the white background and having monotone tray icons, just for esthetic reasons. Regarding the clipboard vs. scissors metaphor ... if the goal is to make it easier on the average user we should probably go with whatever is the prevalent metaphor in modern UX.

I think that is (still?) the clipboard, while the scissors are related to the "cut" action - if anything it might actually confuse average users to mix those up?

Currently it seems to default to whatever the environment uses as icon set. In my case the style is "Breeze Dark" and the clipboard function shows up as two sheets of paper on top of each other (right next to the time). Looks pretty neat to me.

[ninavizz]

@marmarek We actually have those notifications enabled on our personal and work VMs, that I've been using at home to fuss around with learning and observing the nuances of Clipboard as y'all have it configured out-of-the-box.

A generally challenging thing for me with Qubes, is that almost everything produces the same black toast notifications. After a while, I kind of tune them out; and the only bits I have the cognitive bandwidth to pay attention to, is usually just the first few words. That was part of what was discussed in the FPF Qubes user meeting we had this past Thursday.

The other challenging thing with the toast notifications, is that there's a LOT to read in that text... and, they go away at some point. Unless the user configures them differently... but, still, there's a lot to read. Too much, per UX best practices standards.

The functionality I'm proposing, would keep the colored dot on the Tray Icon, as long as the clipboard has that data in it. So, if you're going to paste into a sensitive region—or into a URL bar, or a Google bar (highly not-sensitive destination, but a major fail of the clipboard contents is sensitive), you can just glance-up to make sure you're pasting into your destination what you think you're pasting. Moreso, if the data volume and vm-name are also surfaced, in an extended tray widget.

It's also just easier to make cognitive sense of a passive notification that's almost entirely symbolic, and unique, vs done as written language and in the same style as many others.

How to surface the GPG stuff in the tray somehow, and not as a written/bubble notification, is also something that's been discussed on and off through the months. I love the notifications, don't get me wrong—I just feel it could be really helpful to use visual ques as often as possible, to avoid cognitive overload on the user.

@SvenSemmler The most common metaphor I've seen is the two-sheets-of-paper one, that much of the time is rendered poorly as two rectangular blobs. Google Docs does it terribly, despite most of the rest of their icons being crisp and easily decipherable... whereas Google Sheets just introduced a proper clipboard icon in a focus-state widget. Likewise, a lot of UX is simply really bad—and I want to be mindful to introduce an improvement, not a regression. :D

I'm fine doing whichever tests best with users, and am personally leaning towards the clipboard... but again, that's just personal.

Your Breeze Dark theme does have the nicest rendering I've yet seen of the two pieces of paper, tho—my only concern is that it could be confused for a printing widget? Hence, user testing. :)

Thank u for including the screencap, I'll definitely re-create and include it in future user testing!

[ninavizz]

^ Crap, that got really long... sorry! :/

[eloquence]

I'm personally a big fan of this state change indicator idea for opsec reasons:

It's true the existing notifications are helpful; however, I've seen enough reports of Qubes-specific clipboard accidents including from our own internal Qubes users to believe they're not sufficient. In my observation, most of the mistakes tend to happen when a user hasn't successfully copied contents via the global clipboard, and is instead accessing the VM-specific clipboard, which may still hold certain sensitive contents.

The idea with this indicator is that it gives users a predictable place to focus on in the UI, regardless of whether an ephemeral notification is still present, to ensure that they have completed the required steps to perform a cross-VM paste, instead of a local-VM paste. I don't think it will magically solve all problems, but it may help.

Does that make sense? If so, I think we should try to figure out if there's a smaller scoped version of this issue that may be more achievable in the near term than all the changes described in the issue, while still adding user value.

[ninavizz]

Adding to #5807

[donob4n]

Hello,

I personally don't have any problem with current copy&paste behavior but I read some post on discourse [1] and realized that some people could find it really painful. That said, I was just playing with weechat plugins and one of them gave some idea for this (maybe it was already discussed):

anti_password.py 1.1.0 2021-02-26 | Prevent a password from being accidentally sent to a buffer.

I see something like this on Qubes working in this way:

• For almost any copy/paste action, Qubes works like typical desktops. You copy on a window, paste on another and "IT WORKS". (In reality you already have more security than other desktops since it only shares the clipboard content when you paste it and only to 1 different VM)

• When the clipboard heuristic "thinks" that you are probably pasting a password, it prompts for an user confirmation in the less possible disruptive way. "The content of clipboard is probably a password, are you sure to paste it to VM-NAME?"

With a checkbox like, don't ask again for this VM, the most used "copy paste flows" could be easily done without confirmation. Also some VM's could be configured for always ask for confirmation.

I suppose that most advanced users will prefer the current way but this could be something optional, like "Simple copy paste method" which could be enabled on the installation process.

1 - https://qubes-os.discourse.group/t/qubes-clipboard-is-painful/2830

[ninavizz]

That is a terrific idea, thank you @donob4n! My only possible doubt, is that it would recognize diceware passphrases as "passwords," as those are much of what security trainers these days advise. Unfortunately, that script does not check against any diceware libraries—and does appear to be built to examine more traditional password structures trainers advise against. That said, it could potentially be enhanced to do as much. There are also many other types of sensitive information a better clipboard experience could help with.

Thx for surfacing this rad tool, @donob4n!

[donob4n]

I'm glad you like it. I think that the heuristic could use (additionally to regular expressions) the context of the copy event. e.g. If the user copies something on a keepass or electrum window, the content will be flagged directly as sensitive.

With few rules I suppose that we could cover most cases.

[deeplow]

• When the clipboard heuristic "thinks" that you are probably pasting a password, it prompts for an user confirmation in the less possible disruptive way. "The content of clipboard is probably a password, are you sure to paste it to VM-NAME?"

Putting aside the potential challenges of identifying what is a password and what is not. Your suggestion assumes only passwords are sensitive. Something I'd disagree with. For example someone copying text from a sensitive document.

Additionally heuristics may surprise users.

---

Suggestion: secure clipboard mechanic reminder

I would instead advocate for user education about the clipboard. For example, when the user ctrl+c and then go to another VM and try ctrl+v they get confused because nothing gets pasted. This would be an excellent time to educate/remind users about the "safe clipboard" mechanic.

This suggestion would give this feature discoverability (which AFAIK is not currently discoverable).

[DemiMarie]

• When the clipboard heuristic "thinks" that you are probably pasting a password, it prompts for an user confirmation in the less possible disruptive way. "The content of clipboard is probably a password, are you sure to paste it to VM-NAME?"

Putting aside the potential challenges of identifying what is a password and what is not. Your suggestion assumes only passwords are sensitive. Something I'd disagree with. For example someone copying text from a sensitive document.

Additionally heuristics may surprise users.

Not only may they surprise users, they also increase attack surface. Specifically, they may open the door to timing attacks.

[donob4n]

Timing attacks If the copy process is started by dom0, I don't see how to a timing attack could be done and even allowing a VM to request it (e.g. just right clicking and selecting copy), I doubt you could get profit from it (and the user will notice soon that some VM is overriding the clipboard due the notifications spam).

Human error protection I think that the current implementation is not really too much more secure against human errors which seems the most valuable reason for keeping it this way (probably there is some technically part too). But really having a four-hotkey combination for doing a process instead a two-hotkey don't gives too much extra protection for human errors. With practice and time you start to do the 4-key-combo without thinking, specially if you are a kind of user accustomed to console apps and keyshorcuts, so the probability of doing a wrong paste is not very different than having standard shortcut.

In contrast the heuristic setup (with an extreme simple algorithm) could be really helpful to avoid wrong pastes.

In any case I think that this kind of wrong pastes are not so common. I personally remember many times the feeling of pasting an old copy because I missed to ctr+c-ctrl+shift+c/ctrl+shift+v-ctr+v and had to redo the process. But I would say that I don't remember any case where I thought, "oh this Qubes Magic long key combination saved my life".

A sad history In some sense the current method also induces human errors but since this errors are always sourced from the same VM we assume that they are not serious. Is this realistic?

Imagine some new Qubes user at work, he has a VM for private IM with other employees and his boss. He has some problem with his boss and talks about it with some partner, then copy paste some text from there to other good partner. Minutes later his boss ask him for some work results which our user saves in other VM, he opens that VM copies the results and.... wOPS, he accidentally pastes part of his confidential conversation with his partners talking about his problems with the boss...

This kind of copy/paste error is strongly promoted by the current long key-shourtcut. But since all them have the same VM as source/dest they are considered not harmful.

TL;DR

• Qubes clipboard isolation provides same protection regardless a short or long key shortcut to a process monitoring clipboard content.
• Current key shortcut could provide some protection to human errors but... does it really do it? (it also induces errors!)
• An heuristic based warning will really prevent possible errors in a more robust way, obv not all possible errors but the common cases yes (copy from a password manager, bitcoin adress/privkey/, pgp key, etc..).

[brendanhoar]

In your scenario: the user is multi-tasking, is interrupted, and fails to paste the sensitive data into the correct VM first before mis-pasting to the wrong VM, yes? Only asking for clarification as my understanding is that upon paste-into-VM the meta-clipboard is cleared.

As a mitigation for this I would like to see the name of the VM that sourced the meta-clipboard data displayed on the dom0 menu bar when VM data exists on the meta-clipboard.

[donob4n]

In your scenario: the user is multi-tasking, is interrupted, and fails to paste the sensitive data into the correct VM first before mis-pasting to the wrong VM, yes? Only asking for clarification as my understanding is that upon paste-into-VM the meta-clipboard is cleared.

Well, we could assume that he missed even he is running Qubes:

• Using 'work-chat' he copies, ctrl+c "Daniel, our boss, is a moron!", and pastes ctrl+v to other window. As usual, it works.
• Via 'work-chat' too, the boss asks him for an account balance that our user saves on an offline 'work-vault'.
• He opens a doc on 'work-vault', Selects "Total month winnings: 999,999€", copies with ctrl+c, returns to his boss chat window and pastes: "Daniel, our boss, is a moron!".
• He loses his job.

I think that the current clipboard system maximizes this kind of errors specially for new users.

As a mitigation for this I would like to see the name of the VM that sourced the meta-clipboard data displayed on the dom0 menu bar when VM data exists on the meta-clipboard.

It could be nice for advanced/experienced users but for the kind of user I imagine here I think that it won't help very much.

[DemiMarie]

In your scenario: the user is multi-tasking, is interrupted, and fails to paste the sensitive data into the correct VM first before mis-pasting to the wrong VM, yes? Only asking for clarification as my understanding is that upon paste-into-VM the meta-clipboard is cleared.

Well, we could assume that he missed even he is running Qubes:

• Using 'work-chat' he copies, ctrl+c "Daniel, our boss, is a moron!", and pastes ctrl+v to other window. As usual, it works.
• Via 'work-chat' too, the boss ask him a account balance that our user saves on an offline 'work-vault'.
• He opens a doc on 'work-vault', Selects "Total month winnings: 999,999€", copies with ctrl+c, returns to his boss chat window and pastes: "Daniel, our boss, is a moron!".
• He loses his job.

I think that the current clipboard system maximizes this kind of errors specially for new users.

As a mitigation for this I would like to see the name of the VM that sourced the meta-clipboard data displayed on the dom0 menu bar when VM data exists on the meta-clipboard.

It could be nice for advanced/experienced users but for the kind of user I imagine here I think that it won't help very much.

Good point! Would displaying the actual clipboard contents help? We probably don’t always want to do that, though (in case they contain a password or similar). Maybe we should have a separate clipboard for secrets?

[donob4n]

In my opinion the "ideal" solution should unify the method for copy/pasting 'inter-vm' and 'cross-vm' (even with the mouse). Having two different ways for doing almost the same thing is inevitably error prone.

Having this unified method I will try to protect the 'cross-vm' case. e.g. a cross-copying between 'work-vault' and 'work-online' should be done without disruptive warnings, but other like between 'work-vault' and 'disp7343' should say "ey, are you sure?"

With few checkboxes like: "don't ask again for pasting to 'work-online' from 'work-vault' the user could setup his custom copy/paste flows fast and easy.

[ninavizz]

So... unfortunately there is a reality with what users "habitualize" vs what users can re-learn and continue to use in an ongoing fashion.

There is currently a trend in infosec, that we can train users to do anything—and regrettably, that's just not the case. Especially when we do things differently in other areas of our life for whatever reason. I personally dislike the idea of coming-up with a different "Secure Clipboard" experience to use in addition to Qubes' regular clipboard, because the whole point of Qubes is "security" and Yet Another Clipboard is too prone to cause more confusion and frustration than to do good. The same rationale exists, for not wanting to create more Qube colors. 7 is too many imho, as it is.

Also, to be perfectly honest: my own biggest infosec fails, have never happened when I thought I was doing something terribly sensitive. As such, I would never have elected to use a "Secure Clipboard" for those things. Context is everything, and those operations became big infosec fails because of the intended-recipient/actual-recipient whoopsie-doozie. Not because I was sending nuclear codes.

Qubes' Clipboard needs to be done as a proper design project, with tons of ideas and several rounds of testing. I felt the "password detector" script is/was a "good idea," but alone won't solve the problem—and tbh, is likely to trigger too many false alarms when truly secure passphrases are used (instead of

The thinking with the initial idea—of a status light when the clipboard is "full" vs "empty" is that the "safety" part of the experience would be dead-simple and add minimal cognitive load on top of what already exists. Likewise, to show the size of the contents in the clipboard. While I'm totally open to other ideas, how the functionality is surfaced to users has to be that simple/minimal and cannot require fundamental behavior changes, nor become so overwhelming that users become fatigued by it.

[ninavizz]

Idea: build-in something enabling a user to turn ON in a VM's settings, that it's clipboard going to the global clipboard will always enable a unique flag on the global clipboard when it has contents from that VM in it.

Example: I turn that flag on in my Vault VM, and the status-indicator proposed in this first comment, has been enabled. Typically, it just shows a yellow dot to indicate the global clipboard is populated, but because my Vault VM has ULTRASECURE clipboard-flagging enabled, anytime I copy something from it and into the Global Clipboard, its status-light shows as red.

The above could perhaps be "standardized" to always show the color of the VM from which something was taken, I do not believe that would be as effective—because then users would just adapt to the Clipboard always changing colors and will tune it out, intended or not. If users select just one or two VMs to throw that flag, and it's only one color, then the rarity with which it is thrown will command the user pay more attention to it. Likewise, a binary is easier to remember, than the "7 versions of this" equivalent (eg, all the dang qube colors).

[DemiMarie]

The same rationale exists, for not wanting to create more Qube colors. 7 is too many imho, as it is.

Agreed. Not to mention that for me at least, I have several qubes with incomparable trust levels.

[unman]

On Tue, Mar 02, 2021 at 07:53:17PM -0800, Demi Marie Obenour wrote:

The same rationale exists, for not wanting to create more Qube colors. 7 is too many imho, as it is.

Agreed. Not to mention that for me at least, I have several qubes with incomparable trust levels.

I don't know what this comment means: "several qubes with incomparable trust levels".

As to whether 7 is too many colours, there have been many requests in the past for more colours or distinguishing methods. There seems to be an assumption here that colour is related to trust level - it may be, but it need not be. I know people who use colour to group to gather distinct aspects of their digital lives - just like Joanna outlined in that early post: work, play, home etc - and these will include different security levels with the same colour. One of the great things about Qubes is the freedom it gives to users to organise as they will - I think it would be sad to see that freedom limited. Particularly if it is done on the basis of a limited understanding of usage.

[ninavizz]

One thing that is very difficult with the traditional FOSS/decentralized developer community engagement model w/ users, is the request/build cycle; problems aren't so much understood, as teams are inundated with "solution requests" that come from each user's own contemplation of a subpar experience.

I have heard the logic, "Don't complain if you cannot present a solution." The difficulty with that, is that there needs to be room for inquiry and discovery around what the actual problem is, vs honing in on a perceived problem; and what feasible solution is likely to alleviate that. We don't even know what the problems are, motivating the solution request to add more colors.

Observed problems are also often very different from how problems are articulated by an individual experiencing the problem. Eg: my truck is not hard to drive. My partner is just uncomfortable driving it when he's so high off the ground. The problem is one of emotional discomfort, and not one of a skill deficiency. Yet he is convinced the problem is a lack of skill, because he didn't learn how to drive until mid-age and has only ever driven one automobile... which is logic that makes sense to him.

We don't know why people want more colors. It is possible to read through the zillions of GH comments and forum comments, but a centralized, structured research/ideation/inquiry effort is needed to learn about what motivates people to pipe up and suggest that more of a thing would fulfill a need of theirs.

I would really like to see or to get some design and research funded to solve for the Clipboard issues; but because of how nuanced the problem space is, and how unique Qubes users are, I feel it merits more of a research/ideation/inquiry driven process. It's not an easy problem to solve for, which is also why it's a kinda fun problem to solve for.

[donob4n]

Since I wrote in this thread I am being more aware of my habits with the clipboard and I have noticed that I use the cross-vm key shortcut (the long) for inter-vm copy/pasting a considerably high percentage of the time.

I wonder how many users experience the same.

[unman]

On Wed, Mar 03, 2021 at 07:07:34PM -0800, Nina Eleanor Alter wrote:

One thing that is very difficult with the traditional FOSS/decentralized developer community engagement model w/ users, is the request/build cycle; problems aren't so much understood, as teams are inundated with "solution requests" that come from each user's own contemplation of a subpar experience.

I have heard the logic, "Don't complain if you cannot present a solution." The difficulty with that, is that there needs to be room for inquiry and discovery around what the actual problem is, vs honing in on a perceived problem; and what feasible solution is likely to alleviate that. We don't even know what the problems are, motivating the solution request to add more colors.

Observed problems are also often very different from how problems are articulated by an individual experiencing the problem. Eg: my truck is not hard to drive. My partner is just uncomfortable driving it when he's so high off the ground. The problem is one of emotional discomfort, and not one of a skill deficiency. Yet he is convinced the problem is a lack of skill, because he didn't learn how to drive until mid-age and has only ever driven one automobile... which is logic that makes sense to him.

We don't know why people want more colors. It is possible to read through the zillions of GH comments and forum comments, but a centralized, structured research/ideation/inquiry effort is needed to learn about what motivates people to pipe up and suggest that more of a thing would fulfill a need of theirs.

I would really like to see or to get some design and research funded to solve for the Clipboard issues; but because of how nuanced the problem space is, and how unique Qubes users are, I feel it merits more of a research/ideation/inquiry driven process. It's not an easy problem to solve for, which is also why it's a kinda fun problem to solve for.

I completely agree with this, Nina, although the colours issue is obviously outwith the scope of this thread. (my bad). If I may comment here, in my experience people want more colours because they use them to represent security domains not security levels. Some people who do this also want some other extension - hatching/ shading/lines etc to enable them to set security levels within a domain. I haven't done this and think it would be unworkable.

I too would like to see a decent enquiry in to working practices and Qubes use -I've argued for that for years. Absent that, we have to rely on input from UX folk - I've also argued for that. And that's you.

[unman]

On Thu, Mar 04, 2021 at 01:22:10AM -0800, donob4n wrote:

Since I wrote in this thread I am being more aware of my habits with the clipboard and I have noticed that I use the cross-vm key shortcut (the long) for inter-vm copy/pasting a considerably high percentage of the time.

I wonder how many users experience the same.

I'm sorry - can you explain what "the cross-vm key shortcut" is ? Is it the standard Ctrl+C/Ctrl+Shift+C etc combination?

Do you mean you are cutting and pasting between qubes a lot? Since you ask, this is not my experience.

[donob4n]

I'm sorry - can you explain what "the cross-vm key shortcut" is ? Is it the standard Ctrl+C/Ctrl+Shift+C etc combination? Do you mean you are cutting and pasting between qubes a lot? Since you ask, this is not my experience.

Yes I meant the standard combination. Usually I work with offline or Internet restricted qubes so I do most random web surfing, URL opening, searches for programming APIs, etc... in disposablesVMs, this implies a lot of copy/pasting between different qubes. But I also have some IM tools on same qube where I work and I tend to use the long combination copy/paste instead the short because I am like "overtrained" for using it.

From the perspective of most desktop computer users, in Windows and Mac there is just a clipboard, in most Linux exists also the middle-click clipboard... but in Qubes you have a clipboard for each opened qube, another for dom0 and then the shared... I think that it could be pretty hard to understand for users without virtualization experience.

Currently I am starting to think that a unique clipboard "concept" would be better for most users and it could even improve the clipboard security:

• Imagine that when you copy something from a qube it is moved automatically to the shared clipboard and wiped from the VM clipboard. If some minutes later you open a malware which tries to read the qube clipboard it will be empty near 99% of time. All the clipboards of all your qubes will be empty most of the time.

And we end with a very simple clipboard experience. The shared clipboard for all qubes (with some policies or maybe a special paste shortcut for cross-vm, but same copy method for both inter/cross) and the dom0 which generally users don't have to be aware of, that's all :smile:

Example:

• User copies "Hello World" from "work" (he uses just ctrl+c)
• He pastes it in another "work" app, (he uses just ctrl+v)
• He now tries to paste it in "work-im", (first tries with ctrl+v)
• A warning appears: "Trying to paste a message from "work" VM!! please use ctrl+shift+v !"
• He does ctrl+shift+v and "Hello World" appears in "work-im" window.

[ninavizz]

I'm starting to mull the possibility that there be a few different "types" of Clipboards; not to burden all users with, but to provide users the option of using one or the other with hiiiiiighly sensitive qubes, while relegating others to lower but easier to deal with clipboard protocols. eg: something like what @donob4n describes above. Forcing users to always have to remember how to do the global clipboard dance all the time, feels dreadful.

Instead of having a "safe clipboard" and a "regular clipboard" as two protocols that users can choose in a moment to engage with, the 'kinds' of clipboards are designated via policies; and there is a persistent indicator to remind users which clipboard is active for the active qube they're in.

That all sounds terribly complicated and also somewhat contradicts an earlier thought I'd had; but reading @donob4n's comment above, I'm increasingly in favor of both a) simplifying the keyboard-choreography that trips-up (what I speculate is) many new users, and b) embracing policies, more, to mitigate some of these issues. Once there is a solid Policy Manager GUI, that should also be much easier for all users to do, while surfacing the capability to non-technical users.

Like: the whole point of qubes is to enable users to have safe spaces on their devices; and if I'm in my dank-memes qube, it will frustrate me to pieces that I can't just have fun and let loose with muscle-memory/brainless stuff driven by habit more than thinking. Qubes needs to be protective, but also allow users to feel safe to just let-go in not-sensitive domains. Keeping one's guard-up all the time is just exhausting.

[donob4n]

Just for comment other benefit of the "unique clipboard":

In this way, it will be more familiar for new users, since most of them are used to copy once but paste all times they want! Currently, if you copy something from 'dispXXX', then you paste to 'work' and finally you want to paste it too to 'work-share', you will have to copy again it from 'dispXXX' (or 'work-share'). For a non experienced Qubes user this looks like a broken copy/paste.

Since the shared clipboard is saved in dom0, we can assume that it is safe (or we are totally defeated), so wiping it after pasting is not protecting from being stolen, it is protecting the user from pasting it wrongly to another window. But we are already protecting that possible error forcing a different key combination! (Anyway, we could also wipe the shared clipboard after some time of inactivity, it would be almost as safe as instant wiping but allows users to have a usual copy/pasting experience)

My last idea is having three VM levels for clipboard trusting (defined with qvm-pref and simple to set with GUI):

• Normal or default: all vm's in that clipboard mode can copy/paste between them with simple keyboard combination (like other Linux, Windows, etc..)
• Trusted or sensitive: All content copied from them is flagged as sensitive and require special keyboard combination for being pasted.
• Untrusted (default for dispvms, annon vm's): It always require the special combination for pasting on them.

In this way you only use the different pasting combination when: a) You are pasting something very valuable (it comes from your vault keepassx) b) You are pasting something to a very untrusted place (tor browser in some dark place?)

The rest of the time you are just copy/pasting without worrying too much about it, like most people do everyday in their desktops systems.

Finally for clarify, when you are on cases a) or b) the standard combination "ctrl+v" does nothing, just notifies that the clipboard is blocked and informs the user to use the "ctrl+shift+v" if effectively he wants to realize the paste.

[andrewdavidwong]

The standard UX approach for handling this type of case is to provide a toolbar with buttons for performing the relevant actions. For example, in a standard word processor, there are buttons for the standard clipboard cut/copy/paste actions. Hovering over each of these buttons shows a tooltip for the corresponding keyboard shortcut (ctrl+x/ctrl-c/ctrl-v). One option would be to handle the Qubes inter-VM clipboard in a similar manner.

I'm rather skeptical of remarks to the effect that learning the ctrl+shift+c and ctrl+shift+v shortcuts is too difficult. Difficulty is relative. These shortcuts fit into the existing standard model and require one additional key each. In general, anyone who is unable to use these additional shortcuts is probably also unable to use the standard ctrl+c and ctrl+v shortcuts. They would likley use the aforementioned buttons instead of keyboard shortcuts.

---

Like: the whole point of qubes is to enable users to have safe spaces on their devices; and if I'm in my dank-memes qube, it will frustrate me to pieces that I can't just have fun and let loose with muscle-memory/brainless stuff driven by habit more than thinking. Qubes needs to be protective, but also allow users to feel safe to just let-go in not-sensitive domains. Keeping one's guard-up all the time is just exhausting.

There seems to be a misconception here. The inter-VM clipboard doesn't affect what happens within a single qube.

[andrewdavidwong]

In this way, it will be more familiar for new users, since most of them are used to copy once but paste all times they want! Currently, if you copy something from 'dispXXX', then you paste to 'work' and finally you want to paste it too to 'work-share', you will have to copy again it from 'dispXXX' (or 'work-share'). For a non experienced Qubes user this looks like a broken copy/paste.

Not if the user reads their dom0 notifications. It tells you that the clipboard has been wiped after pasting.

Since the shared clipboard is saved in dom0, we can assume that it is safe (or we are totally defeated), so wiping it after pasting is not protecting from being stolen, it is protecting the user from pasting it wrongly to another window. But we are already protecting that possible error forcing a different key combination! (Anyway, we could also wipe the shared clipboard after some time of inactivity, it would be almost as safe as instant wiping but allows users to have a usual copy/pasting experience)

This speaks in favor of allowing users to configure this behavior. If the user thinks that the separate keyboard shortcut is sufficient protection, they can choose to turn off auto-wiping, for example.

[donob4n]

I'm rather skeptical of remarks to the effect that learning the ctrl+shift+c and ctrl+shift+v shortcuts is too difficult. Difficulty is relative. These shortcuts fit into the existing standard model and require one additional key each. In general, anyone who is unable to use these additional shortcuts is probably also unable to use the standard ctrl+c and ctrl+v shortcuts. They would likley use the aforementioned buttons instead of keyboard shortcuts.

Well, it is not just learning an additional key in a shortcut. It also implies some grade of abstraction, "First, copy with ctrl+c to the internal clipboard, then use ctrl+shift+c to copy it to the global clibpoard....etc...". For new users to virtual machines world it could be very confusing (the fact that each VM has its own clipboard could be hard to visualize). And really it is not just a different shortcut with an additional key, it is the same old combination plus two additional combinations.

And also, in a "next level" of simple clipboard for everybody, I will consider doing the same using the mouse (right click + copy, right click + paste). The case of "sensitive paste" could be solved with a dom0 dialog "Sure you want this?". The security of Qubes OS with the simplicity of Windows XP :smiley: The problem is that it is probably more difficult to do safely.

This speaks in favor of allowing users to configure this behavior. If the user thinks that the separate keyboard shortcut is sufficient protection, they can choose to turn off auto-wiping, for example.

In my opinion if some alternative is finally approved it will be some kind of opt-in. Many users will prefer to untouch the current clipboard.

[andrewdavidwong]

I'm rather skeptical of remarks to the effect that learning the ctrl+shift+c and ctrl+shift+v shortcuts is too difficult. Difficulty is relative. These shortcuts fit into the existing standard model and require one additional key each. In general, anyone who is unable to use these additional shortcuts is probably also unable to use the standard ctrl+c and ctrl+v shortcuts. They would likley use the aforementioned buttons instead of keyboard shortcuts.

Well, it is not just learning an additional key in a shortcut. It also implies some grade of abstraction, "First, copy with ctrl+c to the internal clipboard, then use ctrl+shift+c to copy it to the global clibpoard....etc...". For new users to virtual machines world it could be very confusing (the fact that each VM has its own clipboard could be hard to visualize).

This is why we have notifications to tell you what's happening at each step of the way. Maybe we just need to improve that feedback.

And really it is not just a different shortcut with an additional key, it is the same old combination plus two additional combinations.

Yes, but each individual action is no more difficult than the standard copy/paste shortcuts. Users who can't handle the new keyboard shortcuts probably can't handle the old ones either.

[donob4n]

Yes, but each individual action is no more difficult than the standard copy/paste shortcuts. Users who can't handle the new keyboard shortcuts probably can't handle the old ones either.

Well I don't think really that it is too difficult. But I wouldn't focus the problem on that.

The question should be if there are alternatives to do it easier and more comfortable without losing security (if yes, why don't do it?). Since I'm convinced that the current behavior is more focused on avoiding human errors than protecting from technical holes (is there any risk for dom0 when copying to global clipboard?), I think that security could be even improved. More easy, more comfortable and less error prone.

[marmarek]

Side note: we have explored using standard "copy" and "paste" operations (whether that is ctrl+c/v, or some toolbar click, or right click menu) for inter-vm clipboard transfer. Technically, it is possible. But it comes with a huge security disadvantage - you no longer know if that operation was triggered by the user, or by a (malicious) applications on its own. This means a malicious application can:

• monitor the clipboard and steal it at will
• inject malicious clipboard content

In fact, there are several malwares in the wild (for classic OSes) that do exactly that:

• steal passwords from clipboard
• monitor clipboard and when seeing for example bank bank account number (it supposes you'll transfer money to), replaces it with another number

Web browsers try to apply some heuristic to this problem (like - allow a clipboard access from JS only when a function is called in a response to click event), but I don't consider such approach even close to our security requirements. There is no practical way to ensure that "some user action" was really clipboard access consent, and not for example a confirmation "yes, I do want to see cute kitten!".

Some mixed scenario is technically possible (like, allow direct clipboard access to some VMs, require confirmation to others or require full double-key-combo copy/paste for yet another cases), but the experience is really confusing. Plus, for technical reasons, it still leaks an information that something was copied between some VMs, even if the actual content is not accessible.

[andrewdavidwong]

FWIW, the toolbar buttons I was envisioning would be in dom0. Clicking the buttons would function the same as if the user had pressed ctrl+shift+c or ctrl+shift+v. This could be useful for people with disabilities that prevent them from pressing such keyboard combinations, for example. It may also be more discoverable for new users (easier to see a button on the screen than to learn that a keyboard shortcut exists).

[donob4n]

Side note: we have explored using standard "copy" and "paste" operations (whether that is ctrl+c/v, or some toolbar click, or right click menu) for inter-vm clipboard transfer. Technically, it is possible. But it comes with a huge security disadvantage - you no longer know if that operation was triggered by the user, or by a (malicious) applications on its own. This means a malicious application can: In fact, there are several malwares in the wild (for classic OSes) that do exactly that:

* steal passwords from clipboard

* monitor clipboard and when seeing for example bank bank account number (it supposes you'll transfer money to), replaces it with another number

Currently the protection against this kind of attacks is trying to avoid that the user puts delicate information in the wrong place. This should remain working in the same sense. Although it could be a little simpler to do, it will be done also less frequently so when need the user will be more conscientious that he is doing something critical.

Currently, reusing @ninavizz example, I'm using the same flow for copy/pasting a meme URL from my 'irc-vm' to other qube as copy/pasting a card number from 'vault' to 'banking'. It is hard to notice that you are copy/pasting something important when you use it most of the time for irrelevant things.

Web browsers try to apply some heuristic to this problem (like - allow a clipboard access from JS only when a function is called in a response to click event), but I don't consider such approach even close to our security requirements. There is no practical way to ensure that "some user action" was really clipboard access consent, and not for example a confirmation "yes, I do want to see cute kitten!".

The heuristic could be very powerful on Qubes:

• Is the user session logged in or locked?
• There was some user activity in the last 'X' seconds?
• Has the domain which requests the clipboard access some window with current focus?

If all is ok then the current policy should be checked, if the access is allowed it will show a discreet notification. It won't bother the user on legitimate access but he could notice something strange is happening if he is not using the clipboard. If the malicious app is monitoring the clipboard at some fixed frequency it will be discovered thanks to this notifications. (If some app requests clipboard access and the heuristic fails the user should be notified with a very different way: "DANGER!!").

In case the paste requires explicit authorization, the user can just use the special combo directly, if he is totally aware of what he is doing he can just: "ctr+c" copy from 'vault', "ctrl+shift+v" paste to 'banking', if the user is not so aware of the risk of the operation he will try "ctr+v" (since he uses it the major part of the time) but when nothing is pasted, he will look at the notification "Restricted clipboard access, please use "ctrl+shift+v" if you want to paste", he will notice that is doing something pretty risky, he probably will recheck that effectively the current window is the desired one and finally press the "ctrl+shift+v" combo.

The confirmation dialog will be useful for right click pasting because the user has one hand on the mouse and the other is not necessary in the keyboard. A small dialog near the current cursor position is much more pleasant to click that the need of "ctrl+shift+v".

Some mixed scenario is technically possible (like, allow direct clipboard access to some VMs, require confirmation to others or require full double-key-combo copy/paste for yet another cases), but the experience is really confusing. Plus, for technical reasons, it still leaks an information that something was copied between some VMs, even if the actual content is not accessible.

Well I don't see it too much confusing than currently it is. The objective is that user sees the clipboard as unique, the Qubes Clipboard! (not the vm-xxx clipboards, the shared clipboard, the dom0 clipboard...). The most of the time he can paste with ctrl+vand only when he performs a critical task it requires "ctrl+shift+v".

If the user wants to paste "Current month winnings: XXX", press ctr+v and "nothing" happens (he will realize sooner or later that there is a notification about what's happening), is less confusing than if he pastes "My boss is......". Nothing more confusing than thinking that you are going to paste something and pasting something totally different!

[donob4n]

FWIW, the toolbar buttons I was envisioning would be in dom0. Clicking the buttons would function the same as if the user had pressed ctrl+shift+c or ctrl+shift+v. This could be useful for people with disabilities that prevent them from pressing such keyboard combinations, for example. It may also be more discoverable for new users (easier to see a button on the screen than the learn that a keyboard shortcut exists).

It would help for people reluctant to keyboard combinations... but nothing more comfortable than using the standard buttons and context menus.

[marmarek]

The heuristic could be very powerful on Qubes:

I think you haven't understood my explanation why such heuristics do not work. It isn't because inability to detect if user have interacted with the VM requesting clipboard (this can be tricky at times, but it isn't the main concern). It is because you can't distinguish what that interaction was - whether that was a legitimate clipboard access action initiated by the user, or some totally unrelated action.

[donob4n]

Honestly I try to see what I could be misunderstanding. I assume that a clipboard legitimate action is always triggered consciously by the user but maybe you are also considering other cases.

In the first case, I know that the heuristic wouldn't be perfect, but it wouldn't be the main clipboard security. It would be like some kind of IDS based on clipboard behavior (more than currently we have) which notices unexpected attempts to manipulate the clipboard (and a really high % of this kind of attempts would be captured by it). But the security remains on the restrictions for copy/pasting in a similar form to what is now. Additionally, since all copy/pasting would be routed via dom0 (maybe someone could consider using a special VM for this task, GUI-VM?), the access to the clipboard could be logged and any strange pattern should be easily detected.

In my previous messages I was only worried about protecting the "paste" part of the process since it could leak information. But now I see that the "copy" could be also protected for unexpected/undesired overriding. If you copy some bitcoin address from a "Secure" domain, as previously it is moved to the Qubes Clipboard and flagged as sensible (it will demand explicit authorization to be pasted), but suppose that before you paste it somewhere, another qube wants to copy something (maybe some malware trying to replace your bitcoin address?), so I would add a condition for copy: if the current content is flagged as "sensible" and it has not been pasted yet, it needs explicit authorization to be overridden. This way the kind of attacks based on replacing clipboard content will be heavy mitigated too. Maybe untrusted VM's should require always the confirmation for copy action.

Other nice tool could be, in the case of "confirmation dialog" when using the mouse, adding a "Show me clipboard content" button so the user has the possibility to check exactly what he is pasting before doing it. For pro users this could be done with the keyboard, e.g. the first "ctrl+v" (assume that our case needs authorization, otherwise the content would be instant pasted) does nothing but shows the notification about clipboard protection, now pressing "ctrl+v" again could show the clipboard content as a notification message, and obviously doing "ctrl+shift+v" would paste the content.

In the end, all this are just minor details about the core idea: to have a unique clipboard, like most desktops, compatible with the most copy/paste buttons possible and of course reasonable secure.

[unman]

I have no doubt that the clipboard experience could be changed, BUT: in my experience working with naive Qubes users, they do find the experience "odd", but not difficult. Some people may find it difficult - but those people are likely to find any clipboard changes difficult. If you provide more options for cut/paste between qubes, then you add a layer of complexity in choosing the right method, and add to the possibility of taking the wrong path.

Clearing the clipboard after paste seems to me the right thing to do - the last thing I want is for data to be hanging about waiting to be mistakenly pasted in the wrong qube by some easy to use key combination.

Here I speak entirely for myself : it should be possible to pass data between qubes; it should not be trivial. When I hear that people cut/paste between qubes a lot, (and I have come across some), then in almost every case there is a better way of doing this: by changing the workflow, or by changing the way in which qubes are used, or by improving their understanding of what Qubes aims to do. Here's an example - I worked with one person who found the current method hard to use: she was a researcher who was copying URLs from a disposableVM to a work qube. I pointed out that she could bookmark the pages as she went, export the bookmarks, and then copy the bookmark file to a storage qube before closing the disposableVM. Since she already knew about exporting bookmarks, and copying files between qubes, this was an easy change to make.

Again, this is one of those cases where a proper review of user experience should be done, and the results balanced against security requirements.

[donob4n]

@unman your example has made me aware of one thing, currently you can move a file or an entire folder between qubes using just the mouse, but you can't copy/paste a simple text line.

The clipboard is overprotected but not against malware, it is only protected against the user using it wrong. You copy a btc address from 'vault', paste it to 'funds-crowdfunding' but this vm is compromised, your clipboard is modified and you don't notice anything if don't manual check. With unified clipboard you should notice that 'funds-crowdfunding' is trying to manipulate the clipboard.

[brendanhoar]

In both cases you must use a dom0 trigger to move the data from the VM to the target VM.

Assuming default Qubes config:

1. The dialog box for copying files between VMs exists in dom0 not in the source VM, and the source VM will a) never know the name of your target VM and b) cannot push data there unassisted by the user in dom0 who requested that it be transferred.

2. Similarly a source VM should never be allowed to push data to dom0 meta-clipboard without the explicit intervention by the user. Many users expect clipboard data to be limited in scope to a VM unless they purposely pull it out of a VM via a secure keystroke that is not sent to the VM but instead invokes a secure message to the Qubes component in the VM requesting the clipboard data. Again that is always triggered from dom0 for security reasons.

B

[andrewdavidwong]

I suggest taking the general brainstorming discussion to the qubes-users mailing list or the forum and reserving this issue for more actionable information and decisions. qubes-issues is not intended to be a discussion forum, and using it as such tends to make it less useful as a tool for the developers.

[ninavizz]

The standard UX approach for handling this type of case is to provide a toolbar with buttons for performing the relevant actions.

Nope. The standard ux approach for copy/paste, is control-c and control-v; that it simply works; and that opsec fails rarely/never happen, because most folks just don't care or know to pay attention with a majority of cut/paste transactions. Therein, lies the challenge with Qubes: the entire mental-model of this OS breaks all existing conventions, and something better needs to be done.

How radically different the mental-model of Qubes is, must be elevated as the recurring #1 challenge to overcome with most users.

Also, fwiw, the "just one more key" thought on the Command-Shift-C/Command-Shift-V hypothesis, I strongly challenge. It's a huge fumbling point for all the Qubes users I know, including myself. Especially when it's so similar to existing commands, it gets easily confused; and the fact that I have to do 4 key-presses to achieve what usually takes two, is already overwhelming.

I'm not in the Forums, as I just don't have the cognitive/emotional bandwidth. A LOT of discussion has happened here, already, and I'd suggest tabling/recording thoughts until a proper project can be put together? Otherwise, everything will be too "lost" for when a project is put together, unless other designer(s) are super involved in the forums. Sorry... I just really can't deal with forums or email lists, as a cognitive limitation of my own. Which makes me a shitty FOSS contributor, I realize.

[ninavizz]

This is why we have notifications to tell you what's happening at each step of the way. Maybe we just need to improve that feedback.

YES. The existing notifications are far too wordy, and the line-spacing and use of mixed italics and regular text, compromises their legibility a lot. I understand why all of the aforementioned were likely endeavored; all the best of intentions. But it still is far to much of a cognitive burden for users to always pay attention to. The OS needs to be able to be smarter about delivering which ques, when, and how, in a fashion that works acceptably with the human brain's capacity to process and remember things. Which is a dance.

"Notification Fatigue" is also a real/major usability hurdle with Qubes... hence my desire to ideate and find more visual solutions. None of this is easy, unfortunately, but imho is all quite worth it. :)

[unman]

On Fri, Mar 05, 2021 at 09:10:34AM -0800, donob4n wrote:

@unman your example has made me aware of one thing, currently you can move a file or an entire folder between qubes using just the mouse, but you can't copy/paste a simple text line.

The clipboard is overprotected but not against malware, it is only protected against the user using it wrong. You copy a btc address from 'vault', copy it to 'funds-crowdfunding' but this vm is compromised, your clipboard is modified and you don't notice anything if don't manual check. With unified clipboard you should notice that 'work-X' is trying to manipulate the clipboard.

I don't understand this example - if the destination is compromised, then why would there be a need to modify the clipboard? They just capture the data as is and exfiltrate it - you are hosed, and the Qubes clipboard is the least of your problems.

[andrewdavidwong]

The standard UX approach for handling this type of case is to provide a toolbar with buttons for performing the relevant actions.

Nope. The standard ux approach for copy/paste, is control-c and control-v; that it simply works;

I guess you're not understanding what I mean. Of course ctrl+c and ctrl+v are standard for copy and paste. No one would ever dispute that. "This type of case" refers to the discoverability of software-specific functions with keyboard shortcuts. In almost every GUI application I use that has non-OS keyboard shortcuts, there are buttons that do the same thing, and hovering over those buttons displays a tooltip that shows the corresponding keyboard shortcut. A typical word processor is a common, simple example of this. There's typically a long bar or two near the top with a bunch of buttons on it, and most of those have their own keyboard shortcuts that do the same things, including standard copy and paste.

I'm not in the Forums, as I just don't have the cognitive/emotional bandwidth. A LOT of discussion has happened here, already, and I'd suggest tabling/recording thoughts until a proper project can be put together? Otherwise, everything will be too "lost" for when a project is put together, unless other designer(s) are super involved in the forums. Sorry... I just really can't deal with forums or email lists, as a cognitive limitation of my own. Which makes me a shitty FOSS contributor, I realize.

The reason for my suggestion is based on my experience with this pattern. Soon enough, someone will say, "This issue is way too long and messy. It's hard to figure out what's going on. Let's close it and open a new one." Then this issue will have served no purpose except to be a glorified discussion venue (perhaps with the added bonus that it lends the discussion an air of importance, since it's on the issue tracker). But we already have discussion venues precisely to avoid that and to keep things organized. The issue tracker is meant to be a practical tool to assist the developers in their day-to-day work, and I'm afraid that cluttering it up with other stuff makes it less useful for that purpose.

Perhaps a good compromise is to lock this to contributors only. That way we can keep the discussion focused. Let's try it for now.

[marmarek]

The issue tracker is meant to be a practical tool to assist the developers in their day-to-day work, and I'm afraid that cluttering it up with other stuff makes it less useful for that purpose.

TBH, this issue is already far beyond the point of usefulness as an actionable issue.

[andrewdavidwong]

The issue tracker is meant to be a practical tool to assist the developers in their day-to-day work, and I'm afraid that cluttering it up with other stuff makes it less useful for that purpose.

TBH, this issue is already far beyond the point of usefulness as an actionable issue.

Ok, let's just close it, then. When we've determined some specific, actionable task regarding the clipboard, a well-scoped issue can be opened for that task.

[ninavizz]

Question @andrewdavidwong @marmarek: Does the "invalid" tag on this mean that there is no desire to improve the Clipboard, or only that this issue lost focus and spun into the ether of in-actionable discussion?