Improve Clipboard Experience #5778
Comments
ninavizz
added
P: default
|
...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: |
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. |
|
@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.
|
|
@marmarek We actually have those notifications enabled on our 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! |
|
^ Crap, that got really long... sorry! :/ |
|
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. |
|
Adding to #5807 |
ninavizz
changed the title
|
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):
I see something like this on Qubes working in this way:
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 |
|
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! |
|
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. |
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 reminderI would instead advocate for user education about the clipboard. For example, when the user This suggestion would give this feature discoverability (which AFAIK is not currently discoverable). |
Not only may they surprise users, they also increase attack surface. Specifically, they may open the door to timing attacks. |
|
Timing attacks Human error protection 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 A sad history 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
|
|
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. |
Well, we could assume that he missed even he is running Qubes:
I think that the current clipboard system maximizes this kind of errors specially for new users.
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? |
|
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. |
|
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. |
|
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). |
Agreed. Not to mention that for me at least, I have several qubes with incomparable trust levels. |
|
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.
|
|
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. |
|
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. |
|
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):
In this way you only use the different pasting combination when: 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. |
|
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 ( I'm rather skeptical of remarks to the effect that learning the
There seems to be a misconception here. The inter-VM clipboard doesn't affect what happens within a single qube. |
Not if the user reads their dom0 notifications. It tells you that the clipboard has been wiped after pasting.
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. |
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 😃 The problem is that it is probably more difficult to do safely.
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. |
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, 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. |
|
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:
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. |
|
FWIW, the toolbar buttons I was envisioning would be in dom0. Clicking the buttons would function the same as if the user had pressed |
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.
The heuristic could be very powerful on Qubes:
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: 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
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 If the user wants to paste "Current month winnings: XXX", press |
It would help for people reluctant to keyboard combinations... but nothing more comfortable than using the standard buttons and context menus. |
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. |
|
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. |
|
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.
|
|
@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. |
|
In both cases you must use a dom0 trigger to move the data from the VM to the target VM. Assuming default Qubes config:
B |
|
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. |
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. |
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. :) |
|
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.
|
I guess you're not understanding what I mean. Of course
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. |
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. |
andrewdavidwong
added
the
R: not applicable
|
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? |
I am not either of the people you mentioned, but I am almost certain that it is the latter. |
The latter. |
The problem you're addressing
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:
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?
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.
The text was updated successfully, but these errors were encountered: