Basic usability improvements to RPC dialog

[ninavizz]

The problem you're addressing (if any)

In #5840, many concerns around usability and user comprehension were raised with the existing RPC dialog windows. In the discussion points, Marek made clarifications around scope and security concerns, and so this and #5853 have been created to split solution opportunities across 2 separate efforts.

Key concerns raised in #5840

• Filenames and many device details cannot be mentioned in the dialog, as both wd introduce vulnerabilities
• Things more unique to each window than a single string of text that changes on a per-operation basis, would require an API; which is not a lot of work, but is scope-creep on top of addressing some more basic usability concerns with the existing data presented.
  • Many such changes are opportune, however, and should be tracked in Unique dialogs for individual RPC tasks #5853

This Issue is for
Basic, no-API-needed things to the dialog.

Where is the value to a user, and who might that user be?
All users, technical and non-technical, like plain-language as often as possible, as long as important details are not obfuscated or hidden. For the latter, they can be de-prioritized or hidden through progressive disclosure, for view on an as-needed basis.

Proposed Solution

• Replace Operation Execution with Interqube Request as the title-bar's text
• Replace icon with a TBD created icon that uses the QuteQube artwork, Tango icons set styling, and speaks to inter-VM sharing concepts.
  • Alternately, use the "Magic" icon shown in some of the early mockups on Improve RPC dialog windows usability: Window header, text, icon semiotics #5840
• Eliminate line for "Operation," and include that information in the single line of descriptive text in the window.
• Eliminate white background & outline behind Source VM
• If a clear and concise plain-language string can be created for the Policy (such as `copy file to VM') use it—with the verbaitm policy language shown, below, in gray.
  • Spreadsheet to capture plain-language strings for all policies, here in this Spreadsheet.
• If no such plain-language string makes sense or is possible, show Policy string as shown in the admin-vm example, below.

First Mockups

[ninavizz]

Note: In the spreadsheet I created, there are 114 policies I was able to fetch from my own Qubes machine—less custom SecureDrop ones, and backups.

Open questions I have from that spreadsheet:

• Which of those 114 Policies, spawns the dialog this Issue was created to update?
• The text in the existing window, infers that all operations it speaks to are "doing a thing from VM1 to VM2" with a source/target VM. Are there other behavioral categories that do different things? This category, asks a user to select a Target VM. If there are other categories, what are the asks of the user of those—in similarly broad terms?
• Of all the Policies that spawn a dialog, AND spawn a dialog that speaks to inter-qube access where a target VM selection is required: which policies are those, what do those policies do, and ideas for plain-language strings?

The spreadsheet is open to be commented on by anyone, so pls have at it, there—or, make comments, here. Thx!! :)

[rustybird]

Those look a lot cleaner than the current dialogs for sure.

The phrasing "complete your task" though: To me this reads like a trusted dialog implying that this task is something I initiated and that going ahead is in my interest. But strictly speaking, the source VM initiated it (maybe as a result of my actions inside the VM, or maybe unexpectedly), and it might even be an attempt by a malicious source to trick me into going ahead with a detrimental action.

[ninavizz]

@rustybird If the user did nothing to initiate this, it stands to reason this could be judged as malicious. To your ow point above, the user did something specific within the Source VM, to initiate what this dialog is speaking-to, tho... so it seems to make sense to me as a natural next-step in their task flow.

What would you (or others) suggest to remediate? I'm also just not sure how much "a trusted dialog" can be differentiated from "a not-quite trusted dialog," without introducing other new concepts. Which isn't to say those concepts would be a bad thing. If anything, those could be evolutions upon this, as a starting point.

For non-technical users, the current "Operation Execution" with Source/Target text in the window, looks like a malicious intrusion. Especially if I just do something w/in the Nautilus UI, such as "Copy file," and I get this wacky looking/sounding dialog.

[rustybird]

To your ow point above, the user did something specific within the Source VM, to initiate what this dialog is speaking-to, tho...

Sure, but the part of the system mediating the action with this permission dialog can't know that. To the AdminVM, the happy path is indistinguishable from some sort of attack, so one message has to be appropriate in both scenarios. Ok, sounds a little intense for a mundane qubes.Filecopy action, but "complete your task" is in the generic text that would also appear in the context of let's say a local.EmergencySelfDestruct action.

What would you (or others) suggest to remediate?

Maybe just "complete a task"? Hmm.

I'm also just not sure how much "a trusted dialog" can be differentiated from "a not-quite trusted dialog," without introducing other new concepts.

By trusted I meant it's coming from the AdminVM, which is always an agent on my side and would never mislead me. 😍

(In contrast to window content controlled by a regular VM - which could be a viper's nest of three dozen kinds of malware, but can't escape its colorful border marking it as untrusted.)

For non-technical users, the current "Operation Execution" with Source/Target text in the window, looks like a malicious intrusion.

Yeah, it's kind of hilarious in a way.

[ninavizz]

Yeah, it's kind of hilarious in a way.

That's the thing! I agree, it's totally "funny" in the same way an awkward teenager trying to be cool, is... but that's kinda where my excitement is for doing this work. I want it to be friendly and clear, so everyone can trust things, feel confident, and act with more agency with this incredibly powerful OS.

Operation Execution ...feels too robotic. It also matches how the US names its military invasions... so, errmm, yeah.
[Dom0] InterVM Operation ...is clearer, but still robotic.
[Dom0] InterVM Sharing ...is still clearer, and less robotic, but still robotic.
[Dom0] InterQube Access ...leaning towards this?
[Dom0] Broker InterQube Access ...too wordy?
[Dom0] Accept or Decline Access with Decline/Accept instead of Cancel/Ok?

Also raised with me by infosec nerd friends, is the concept that dom0 is the gatekeeper of permissions—and that somehow it's important to "code" the language framing this ask, to speak to concepts of consent. To remind the user to consider this passage of information as legit or not legit, as an aside from being asked to identify a target VM.

Thoughts?

[rustybird]

No other OS even comes close to the power of ordering executions from the command line. Take that, target!

I wonder if "coordinate" would have the right connotations. Someone who coordinates can put elements in relation, and give the go signal or call the whole thing off.

Just throwing it out there:

 [Dom0]  Coordinate an Action?
-------------------------------

        Copy file(s)      <---------- with "qubes.Filecopy" tooltip

        from  🏗 work
          to  __________


        [Stop]  [Go]

[SvenSemmler]

What would you (or others) suggest to remediate? I'm also just not sure how much "a trusted dialog" can be differentiated from "a not-quite trusted dialog," without introducing other new concepts. Which isn't to say those concepts would be a bad thing. If anything, those could be evolutions upon this, as a starting point.

The border color and the [dom0] in the title? Maybe something like the UAC dialogs with "secure desktop" enabled in Windows? ... meaning to blur out the screen and have only the dom0 dialog be displayed.

For non-technical users, the current "Operation Execution" with Source/Target text in the window, looks like a malicious intrusion.

Good?

Especially if I just do something w/in the Nautilus UI, such as "Copy file," and I get this wacky looking/sounding dialog.

This dialog should stop you cold in whatever you are doing! While removing congnitive friction is great, we need to make sure that this dialog is not simply ignored or clicked through especially by non-technical users. The entire point of Qubes OS is compartmentalization. This dialog is a checkpoint / border crossing / security event.

[ninavizz]

This dialog should stop you cold in whatever you are doing!

While removing congnitive friction is great, we need to make sure
that this dialog is not simply ignored or clicked through especially by
non-technical users.

Correct.

However, cognitive friction = uncertain choices, increased anxiety, and an unclear understanding of what is happening. It's security theater, at best, when endeavored with intent.

You can stop a user cold in their tracks, without causing them alarm where alarm is undue. Alarm is not due, here; careful thought and calculated communication, is.

When everything is an emergency, then nothing is an emergency. UI messaging loses its credibility with users, over time, if users don't exercise their full agency of comprehension and intent when making decisions. That's a big problem. It's just not necessary, here.

Also: when non-technical users don't understand something, they often pattern-match that to a compromise. I'm not knowledgeable enough to remediate a compromise, so I'll freak out and hand off my machine to someone who will. A majority of the users I work with, would be forced to do the same. I don't want to waste users time thinking a bunch of everyday things are compromises, that aren't. Likewise, once a user understands that half the things they don't understand do not constitute a compromise, and rather are just "how it was built" they learn to tune it out—and then they miss the real threats.

[ninavizz]

@rustybird I love the word "Action" in there... and am on the fence about "Coordinate." Regardless, thank you for those rad nuggets! I also love the idea of using the qubes.Thinghere operation as a tooltip... but that unfortunately violates accessibility best practices (and tbh, I like keeping it more plainly exposed—visibly tidier as it is, w/o that exposure).

@SvenSemmler I also like the idea of the modal/overlay-blur-out technique you're describing with Windows. I want words to clearly explain what's going on, though—and that the user simply needs to make a measured choice on consent, while also choosing their task's endpoint.

[rustybird]

@SvenSemmler:

Maybe something like the UAC dialogs with "secure desktop" enabled in
Windows? ... meaning to blur out the screen and have only the dom0
dialog be displayed.

On Windows, privilege elevation affects the whole system, so it's a perfect fit for the UI to "stop the world". But on Qubes, an RPC action only affects the source and the target.

@ninavizz:

I also love the idea of using the qubes.Thinghere operation as a tooltip... but that unfortunately violates accessibility best practices

That really is tricky. A tooltip could be made discoverable by adding a dotted underline to the text, and operable for keyboard/tablet users by switching up the main text's and tooltip's contents on press (demo), and maybe Qt allows for some kind of hint for screen readers? But as you say, keeping the command name exposed at all time has its appeal.

When everything is an emergency, then nothing is an emergency.

This, 100%.

I even have the sinking feeling that although consent and authorization are what's at stake for this permission dialog, those sort of terms have become so corrupted by a flood of EULAs and cookie walls that they now mean their opposite in UI: "Consent" is what you're bludgeoned into, and you "authorize" what was already decided you shall meekly go along with.

Hence the idea to getting at it from an angle. But yes, also on the fence about "coordinate". It captures "I choose which VMs to relate to each other" alright, but it's not a slam dunk for "I have the final say". So then the button verbs (e.g. "Stop" / "Go") would have to do most of the work of informing that either way is legitimate, and that there's not an implied default for a generally agreeable person. Hard to say whether that would work.

---

BTW, just noticed that the generic text would probably have to avoid the term "qube", because dom0 can also be a target (such as with qubes.VMAuth) and it's too unconventional to call dom0 a qube, right?

[ninavizz]

BTW, just noticed that the generic text would probably have to avoid the term "qube", because dom0 can also be a target (such as with qubes.VMAuth) and it's too unconventional to call dom0 a qube, right?

@rustybird I have no idea what the history is on the "what is vs what is not a Qube," but to me the value in terminology for an OS is consistency. Qubes is so different from most other OS' in that it's all about compartmentalization, so anything that can suit informing that mental model, I feel is of benefit.

For the mental model to work, I do feel that "Dom-Ohh" has to be considered a qube; as the queen bee is still a bee, just a very different and special bee in a hive. It's all about hierarchies, and terms have to be related enough to where they inform the mental model. Too many terms = a scattered and challenging to remember mental model.

Regardless, I don't think the term "qube" should be used in UI copy. I personally prefer "VM" as it's clearer. It feels appropriate in educational/supportive materials, but not so much in brass-tacks day-to-day stuff. That's just me thinking out loud tho.

[marmarek]

Here is a lengthily discussion about term "qube": #1015
I think a "qube" as a less technical scary word for VM (including dom0) is ok. There are places where we try to differentiate dom0 from any other VM, but I think it creates more confusion than solutions. It does have special powers (managing the whole system), but some other VMs also may have special purpose (and with Admin API, also can be granted some system managing powers).

[ninavizz]

BTW... some community contribs to this spreadsheet, would be very helpful! Comment either here or in the spreadsheet, itself. Don't want to burden Marek and Marta and Friedrich with more than they already have on their plates... <3

[ninavizz]

@marmarek Yeeeah, I came upon that Issue last night. I want to read the whole thing, eventually, but found it overwhelming with the timebox I have available for Qubes stuff this week.

TL;DR, I fully agree with your summation. Even getting today's SimplySecure staff up to speed on Qubes, has been a challenge. It's a legitimately complex system that requires different steps of intensity to introduce... but at some level, needs to just suck it up and be technically honest about itself.

Learning from our users right now with the SecureDrop Workstation project, has been exciting and insightful. It will help a lot once we have the Qubes instance of LimeSurvey (or whatever tool is chosen) up and running, and are able to dive into doing more work with the broader expanse of Qubes users.

[unman]

On Wed, May 27, 2020 at 07:03:40PM -0700, Sven Semmler wrote: On Wed, May 27, 2020 at 05:20:02PM -0700, Nina Eleanor Alter wrote: > For the mental model to work, I do feel that "Dom-Ohh" has to be > considered a qube; as the queen bee is still a bee, just a very > different and special bee in a hive. It's all about hierarchies, and > terms have to be related enough to where they inform the mental model. > Too many terms = a scattered and challenging to remember mental model. +1 > Regardless, I don't think the term "qube" should be used in UI copy. I > personally prefer "VM" as it's clearer. It feels appropriate in > educational/supportive materials, but not so much in brass-tacks > day-to-day stuff. That's just me thinking out loud tho. This is being discussed for years: #1015 The key issue is that qube, domain and VM are interchangeable and mean the same thing.

Domain is not like the others, in that it has established use as "security domain", which may consist of one or more qubes.

[ninavizz]

Domain is not like the others, in that it has established use as
"security domain", which may consist of one or more qubes.

Ok, then the use of the word "Domain" in today's UI suggests differently to me, with how it is presented in today's App Menu.

Unless @unman is being incredibly particular with framing a "Domain" as an app-qube built off a template-qube; which could then technically be 2 qubes? Also, I really don't want to go down this rabbithole on this issue and wd prefer to keep this discussion in #1015 so that this issue about the RPC windows can get efficiently solved.

On that point — thoughts on the below? Icon still in progress (yes, a bit dark and dowdy), but wd use qute qube artwork per Marta's in-flight PR.

[marmarek]

I would remove word "dom0" from the text. It is already in the title, but otherwise it's just a technical detail. And generally, I would not expose "dom0" more than absolutely necessary - this is especially in line of moving user interface of of there (#833).

As for the "domain" in the menu - this is actually a bug (#4723). Simple to fix, but postponed to do together with the rest of the menu reorg (avoid multiple revolutions in the UI to reduce user confusion).

[ninavizz]

@marmarek About to go to bed (do you ever sleep?), and just came to post a version with a less-strange icon... but in response to your above comment, a question: if in fact this dialog is to both straddle consent and destination-selection needs for a sensitive operation, what entity should be positioned in the user's mental model of what's happening, as an origin of the request—if not dom0? Qubes? (which I quite like, actually, after plugging it into my mockup!)

[rustybird]

That imagery of two qubes with an arrow between them + "Interqube" in the window title right above really gets the point across. Now it somehow feels right to call dom0 a qube, and huh there's even precedent for the term "Admin qube" in Joanna's Qubes Air post.

[ninavizz]

I'm now also really into this concept of Qubes speaking to "itself" in the 3rd person, whenever communicating dom0 needs/requests in dialogs or toast messages. It feels both accurate and appropriate, especially with the added transparency into dom0 being the source of the message via the titlebar. "Interqube" felt much less robotic and more appropriate somehow, than "Inter VM."

Question: How could this window work across all 114 policies w/o an API? Spreadsheet is still blank, so I remain uncertain which other policies wd spawn similar (or any) windows.

[andrewdavidwong]

Now it somehow feels right to call dom0 a qube

FWIW, dom0 is also a VM, according to Xen.

"Interqube" felt much less robotic and more appropriate somehow, than "Inter VM."

"Interqube" makes me think of "innertube," but that's probably just me. 😂

Also raised with me by infosec nerd friends, is the concept that dom0 is the gatekeeper of permissions—and that somehow it's important to "code" the language framing this ask, to speak to concepts of consent. To remind the user to consider this passage of information as legit or not legit, as an aside from being asked to identify a target VM.
[...]
I love the word "Action" in there

Perhaps something like "Approve Action"?

[rustybird]

which other policies wd spawn similar (or any) windows

Those I could find were the five where it says ask at the end of their lines in 90-default.policy, with descriptions right above each; and the two from Split GPG. Users can also create their own actions, or modify existing actions' policies to ask.

[ninavizz]

@marmarek Do the two Split-GPG dialogs (cited above) pull from the same template for their dialog, as the dialog discussed here?

[marmarek]

Split gpg (qubes.Gpg action) has two things:

1. The generic RPC dialog (unless you change the policy, which is documented here)
2. Another confirmation "Do you allow VM ... to access your GPG keys for N seconds/minutes/hours"

The first one is pretty annoying, especially when using with Thunderbird or similar mail client, so the recommended thing to do is to modify policy like documented in the link.

The other split gpg service (qubes.GpgImportKey) does use the dialog discussed here.

[SvenSemmler]

This looks great. The only thing I don't like is that is still mixes 'qube' and 'VM'. It kind of really makes sense that 'Qubes OS' has qubes, so maybe just say 'select a destination below'? In the list are qubes (hopefully with their cool cube icons).

And the dialog icon (cube to cube with arrow) is not only nice to look at it actually visually explains whats going on. Great job!

[SvenSemmler]

Question: How could this window work across all 114 policies w/o an API? Spreadsheet is still blank, so I remain uncertain which other policies wd spawn similar (or any) windows.

In ~3 years of using Qubes I've only seen them for file copy, Gpg and USB input proxy requests. I'd love to help but don't know how to find the answers -- I guess that's why the spreadsheet is still empty: it is non-obvious how one would answer/test this out without reading the code.

[ninavizz]

This looks great. The only thing I don't like is that is still mixes 'qube' and 'VM'. It kind of really makes sense that 'Qubes OS' has qubes, so maybe just say 'select a destination below'? In the list are qubes (hopefully with their cool cube icons).

"Destination" is too handwavey, and "VM" is what the destination is; which is echoed by the secondary line of text. To some extent product-specific and general terms do need to be used together (as they are between the window's header and the words VM in the window) to reinforce meaning. Most users derive meaning from use in context, not from looking things up in glossaries. I don't see the mixed-use here, as a likely point of confusion for users.

Also, use of terms consistently across the UI is a much bigger dragon I feel we should avoid trying to slay in this Issue.

I suspect this fix would go in before the QuteQubes are deployed, but without much time before the 4.1 release (when the QuteQubes are expected to go live).

Yep, the purpose of the icon is to inform the user's mental model of what's going on—not just to look cute. ;) Thx for the kind words!

@marmarta Might you have the time to workshop through the spreadsheet with me, sometime this week? I want to make sure a system can be defined that works for everything.

[ninavizz]

Here is the artwork for the icon used in the latest mockup. @marmarta perhaps ping me off GH and lets find a time to go through the spreadsheet to "test" the scenarios against the UI in the mocked-up window... if you have time?

Interqube.zip

[marmarta]

@ninavizz , according to our conversation, I went through the defaults and we should start with custom RPC asks for
qubes.Filecopy (copying files, we already have it)
qubes.OpenInVM (open a file in VM))
qubes.OpenURL (open an URL in a VM (probably dispvm))
qubes.Gpg + qubes.GpgImportKey

we can also cover qubes.StartApp (start an application), but this has no clickable method of causing - if this happens, the user used some shell command :)

those are RPC calls that cover 99,9% "asks" a user may see in a default config, and of those, I'm guessing Filecopy / Gpg /GpgImportKey are crucial. I'll work on a sensible framework for adding icons and descriptions at the end of this week/on weekend :)

[ninavizz]

@marmarta qubes.GetImageRGBA and PDFConvert were also flagged in the spreadsheet. I'm assuming the latter is invoked through a right-click menu item on a PDF file, how is the prior invoked? Do either prompt dialogs that you know of? I can check on the PDF one, but am entirely clueless on the GetImageRGBA one.

[marmarta]

@ninavizz qubes.GetImageRGBA is in practice (due to a bit of magic that happens) never asked to an end user by default; PDFConvert has 'allow' by default in all the sources I can see, so I think we can safely ignore them for now.