Improve UX regarding RPC policy evaluation

[andrewdavidwong]

Qubes OS version:

R3.2

Affected component(s):

Qubes Manager, inter-VM clipboard

---

Steps to reproduce the behavior:

1. Copy some text into the clipboard in dom0.
2. Right-click the Qubes Manager icon in the system tray.
3. Click "Copy Dom0 clipboard".
4. Receive a notification that some text has been copied into the inter-VM clipboard.
5. Press Ctrl + Shift + V into an AppVM.
6. Nothing happens.

Expected behavior:

Pressing Ctrl + Shift + V into an AppVM in step 5 should paste the text from the inter-VM clipboard into that VM's clipboard.

Actual behavior:

Pressing Ctrl + Shift + V into an AppVM in step 5 appears to do nothing. (It works when I copy the text from another AppVM, but not from dom0.)

---

Related issues:

3571

[andrewdavidwong]

Oh, it was because I had commented out the dom0 line in my qubes.ClipboardPaste RPC policy file. Once I changed it to "allow," pasting worked as expected. I recommend:

1. Providing a notification that the action was denied (if it was denied).
2. Setting a default policy in case nothing about copying from dom0 is specified in qubes.ClipboardPaste (if such a default does not already exist). If the default is to deny, then just the first point should be enough.

[marmarek]

Setting a default policy in case nothing about copying from dom0 is specified in qubes.ClipboardPaste (if such a default does not already exist). If the default is to deny, then just the first point should be enough.

Default policy file already have it: https://github.com/QubesOS/qubes-gui-daemon/blob/master/gui-daemon/qubes.ClipboardPaste.policy

Note the comment about "ask"/"allow" there. For dom0 as a source it doesn't matter in practice, but for other domains it does.

Providing a notification that the action was denied (if it was denied).

You mean specifically for clipboard paste, or for any qrexec service in general? If the latter, IMO there should be also an option for silent deny - for example I don't want a notification about denied qubes.InputKeyboard every time I plug in my yubikey...

[andrewdavidwong]

Default policy file already have it: https://github.com/QubesOS/qubes-gui-daemon/blob/master/gui-daemon/qubes.ClipboardPaste.policy

Note the comment about "ask"/"allow" there. For dom0 as a source it doesn't matter in practice, but for other domains it does.

The original behavior I reported happens with a policy file that looks like this:

#dom0   $anyvm  deny
[...]
$anyvm  $anyvm  ask

The dom0 line is commented out. In this case, shouldn't the last line apply to dom0? In other words, shouldn't Ctrl + Shift + V in the target VM work after using the "Copy to Dom0 clipboard" button?

Providing a notification that the action was denied (if it was denied).

You mean specifically for clipboard paste, or for any qrexec service in general?

Whichever one you think would be more appropriate to communicate to the user the reason that Ctrl + Shift + V is denied when the user presses it. If the user is actually pressing Ctrl + Shift + V, we can generally assume that one of the following cases holds:

1. The user intends to paste from the inter-VM clipboard into the target domain.
2. The user meant to paste from the inter-VM clipboard into a different domain and accidentally targeted the wrong one.
3. The user accidentally pressed Ctrl + Shift + V instead of a different key combination.

Suppose the action is denied due to the RPC policy.

• If case 1 is denied, the user probably forgot that the policy is set to deny this action. We should remind her.
• In case 2, the user may not realize she's trying to paste into the wrong domain. Telling her that the action is denied might tip her off that she's trying to paste into the wrong domain.
• In case 3, the user may not realize she pressed the wrong key combination. Providing the "denied paste" feedback would tell her what she pressed (Ctrl + Shift + V), which will help her to realize (if she doesn't already) that she didn't press what she meant to press.

If the latter, IMO there should be also an option for silent deny - for example I don't want a notification about denied qubes.InputKeyboard every time I plug in my yubikey...

In the case of Ctrl + Shift + V, at least, I think a notification that occurs each time (but only each time) that Ctrl + Shift + V is pressed and denied would be perfect with respect to frequency (and not being too annoying). We already have one for each time that Ctrl + Shift + V is pressed and succeeds. We certainly shouldn't have verbose success and silent failure.

[marmarek]

The dom0 line is commented out. In this case, shouldn't the last line apply to dom0? In other words, shouldn't Ctrl + Shift + V in the target VM work after using the "Copy to Dom0 clipboard" button?

No, dom0 is special in here - $anyvm doesn't apply to it. See https://www.qubes-os.org/doc/qrexec3/#qubes-rpc-administration This is why default policy for this service have this additional line.

We already have one for each time that Ctrl + Shift + V is pressed and succeeds. We certainly shouldn't have verbose success and silent failure.

Makes sense.

[andrewdavidwong]

No, dom0 is special in here - $anyvm doesn't apply to it. See https://www.qubes-os.org/doc/qrexec3/#qubes-rpc-administration This is why default policy for this service have this additional line.

Ah, so what happens when the only dom0 line is commented out? Is it the same as dom0 $anyvm deny?

[jpouellet]

@andrewdavidwong If this issue is now actually about implementing notifications on qubes-rpc policy denial, could you please update the issue title and OP to match? Or, if you prefer, lets open a new issue to track that and close this one.

This is not a bug in qubes manager, this is a feature request about user feedback from policy evaluation, and requires various additional plumbing (e.g. probably a new event type to notify GuiVM that denial has happened, since evaluation happens in dom0 which may not be GuiVM) and potentially some additional configuration mechanism to squelch frequent and unwanted denial notices (for example marmarek's yubikey example).

[jpouellet]

A friendly squelch mechanism might look something like: /etc/qubes-rpc/policy/qubes.InputKeyboard:

sys-usb   dom0    deny,silent
$anyvm    dom0    deny

I am generally afraid to add any complexity to policy evaluation though.

[t4777sd]

Has this been removed in Qubes 4.0? I can neither copy inside of Dom0 and the Qubes button does not show the options in the picture as shown here: https://www.qubes-os.org/doc/copy-from-dom0/

[jpouellet]

@t4777sd Correct, there is currently no GUI way to do it in R4.

[jpouellet]

@andrewdavidwong I believe this is fixed by https://github.com/QubesOS/qubes-desktop-linux-manager/commit/18741200a3e37f9182caeff5aba51880b213cf01. /cc @marmarta

https://www.qubes-os.org/doc/copy-from-dom0/#copypaste-from-dom0 should probably be updated to reflect the new UI -- perhaps close this issue and open a separate one for it?

[andrewdavidwong]

@andrewdavidwong I believe this is fixed by QubesOS/qubes-desktop-linux-manager@1874120. /cc @marmarta

While I'm personally satisfied with the "Qubes Clipboard" widget, we still have verbose success and silent failure, so the fundamental problem remains.

https://www.qubes-os.org/doc/copy-from-dom0/#copypaste-from-dom0 should probably be updated to reflect the new UI -- perhaps close this issue and open a separate one for it?

Agreed: #5119. Please feel free to submit a PR for this, if you're so inclined.

[pwmarcz]

UX review time!

(Top is a Fedora-based VM, bottom is dom0).

• Any ideas how to better format this?
• Should the notification auto-disappear after a few seconds, or stay there?
• Should we display the argument (qubes.Service+arg)? Maybe only in the details?

(@marmarek)

[marmarek]

I think it should disappear automatically (both of them). As for the argument, not sure about that. In many cases it isn't something very useful in the notification (for example, U2F key handle, or device id in qubes.USB), but there are cases where it is (application name for qubes.StartApp service, or command in qubes.VMExec service).

@ninavizz what do you think about this and other points from the above comment?

[marmarta]

I don't like the lightbulb icon for allow - it seems to be disconnected from the meaning of the notification. And a minor issue: what will happen when, say, GUI VM makes 60 policy requests in a short moment? Is it possible to have a option for "don't show notifications for this service any more"? I think it could be useful.

[marmarek]

Possibly crazy question: should the notification include icon of a source qube?

[unman]

On Fri, Feb 28, 2020 at 05:42:30AM -0800, Marta Marczykowska-G??recka wrote:

I don't like the lightbulb icon for allow - it seems to be disconnected from the meaning of the notification. And a minor issue: what will happen when, say, GUI VM makes 60 policy requests in a short moment? Is it possible to have a option for "don't show notifications for this service any more"? I think it could be useful.

I'd prefer to see a "squelch notifications for the next 10 min" than an absolute "any more"

[pwmarcz]

Possibly crazy question: should the notification include icon of a source qube?

Using the icons from /usr/share/qubes/icons:

I don't like it :) And it removes the distinction between allow and deny.

For now I would rather go with warning-sign for deny, and no icon for allow.

[marmarta]

I like the idea of using no icon for allow and warning icon for deny :)

[ninavizz]

Icons should always speak to what is expected of the user. If we're expecting you to learn something, a lightbulb or "i" thing is appropriate. If something went wrong and we need you to act on something, a circle-bang. If you need to take caution when proceeding, a caution-bang.

Probably a red "x" icon, for "Denied" would be appropriate—and a green check-mark, for "Allowed." Good news! :) Bad News :( is what's being communicated to the user. What we expect of users with this messaging, is to simply grok an outcome and to then decide what they want to do next.

I'm also seeing an orange outline around the Fedora toast messages, and per how coloration is currently done, that's telling me it's an Orange VM... but there's 2 VMs that I'm being communicated-to, about, so which one is it? I'd keep coloration out of this, as it's unlikely to be intuitive to non-technical users which VM the coloring applies to. Cognitive overload matters, and coloration loses relevance when the entirety of Qubes comes to resemble a giant gay pride party, more than a semiotically clear set of bounded realms.

The text itself for the messaging, is also very important. It should give enough information for all users to know how to proceed, without technical users feeling left in the dark and without non-technical users feeling confused or overwhelmed. I'd love to see drafts of what text might look like.

If communicating the VM name is important, then I'd format the text to include that. Likewise, if the permission is qubes.Filecopy then 2 tables should be created for plain language substitutions for syntax (one for the headline, and one for body-text—the latter, speaking to actions and consequences/benefits, with tensing factored in). That's a much bigger-issue with Qubes, right now—that cognitively burdens users with always translating syntax to plain-language. Which technical users can do, and simply alienates non-technical users.

Something like the below. "Allowed" and "Denied" should always begin the header sentence, because that's the most important info to communicate to the users—the desired action was allowed or not. Then, plain-language version of the action. Finally, more details—again, in plain language:

Allowed: File Copy The file was copied from [work] to [anonweb]

or

Allowed: GPG Key Access The GPG key from [work] was accessed by [anonweb]

If 2 plain language tables is too much work, then include the synax in the "body" line of text, and do plain-language in the salutation. It's less abrasive, that way.

Allowed: File Copy qubes.FileCopy was allowed from [work] to [anonweb]

or

Allowed: GPG Key Access qubes.GPG was allowed from [work] to [anonweb]

Actually, friendlier language would be:

File copied qubes.FileCopy was allowed from [work] to [anonweb]

or

Keyring access granted qubes.GPG was allowed from [work] to [anonweb]

Speak to actual/human outcomes above, and technical tasks executed, below.

[ninavizz]

^ When the Policy Manager GUI is introduced, knowledge-of or insight-into syntax will hopefully no longer be required. At that point, either new messages will need to be added to speak to confirmation of GUI requested actions, or all messages will need to be plain-language-ized.

[ninavizz]

@marmarta Why a "warning" icon for "deny"? There's nothing for the user to be "warned" about. The system is communicating a status in the past-tense, to users. Not warning them of future-tense dangerous/foreboding things. :)

Thing Failed! Thing Succeeded!

[ninavizz]

@marmarek I suspect it would not be intuitive to users, which qube a Qube icon is referencing—the source or the destination? That feels like a 50/50 tossup. If Qube icons were to be used at all, I'd include both—with an arrow between to clearly indicate "source" from "destination"

If you'd wanna get really fancy, make the arrow have a red "x" or a green check laying atop it, to communicate the whole idea, visually.

[marmarek]

Thanks @ninavizz !

I'm also seeing an orange outline around the Fedora toast messages, and per how coloration is currently done, that's telling me it's an Orange VM... but there's 2 VMs that I'm being communicated-to, about, so which one is it? I'd keep coloration out of this, as it's unlikely to be intuitive to non-technical users which VM the coloring applies to. Cognitive overload matters, and coloration loses relevance when the entirety of Qubes comes to resemble a giant gay pride party, more than a semiotically clear set of bounded realms.

Yes, those orange (or other) frames won't be there. Even in the GUI VM case (@pwmarcz in that case notification daemon is running in the same place as window manager, so its notifications won't get those extra frames - similar as in GUI in dom0 case).

Likewise, if the permission is qubes.Filecopy then 2 tables should be created for plain language substitutions for syntax (one for the headline, and one for body-text—the latter, speaking to actions and consequences/benefits, with tensing factored in).

I think it's still important to communicate connection between human-readable action (File copy) and actual service name (qubes.Filecopy), as the latter one is what you need if you want to do something about that notification (add a rule that will allow the call that was just denied, for example). User-friendly names would be a good thing, but not sure how to do that in a flexible enough way. That's because qrexec services can be added by extra packages (for example SecureDrop Workstation has few on its own, but also standard qubes services are spread across many packages, some optional) and it would be good to not alienate them. I'm sure @pwmarcz will have some idea :)

If we'd be going with per-service user-friendly names, we can also per-service define if the service argument should be included or not. For example Allowed: Start application "firefox". Anyway, this may be a little more complex than just adjusting notification text and may warrant deferring to a later time. @pwmarcz what do you think?

[ninavizz]

@marmarek Did you see the bottom-most suggestion—that included the syntax in the body and kept the friendly stuff to the salutation? That one's kinda growing on me, tbh.

That said, I also feel this should have some more time invested in doing it properly.

For example: Files, I'd want to see a file-image with a green check on, as the icon... whereas for the GPG one, there's currently a GPG notification when keyring access happens across qubes... and I like seeing the icon of the keyring for the small duration of that toast message. GPG feels like a rare instance when the standard check/x icon paradigm is ok to deviate from... but I'd also like to validate that with testing.

[ninavizz]

Also... I threw this together to see what a more visual version could look like, and... err, no. It feels uncharacteristically goofy/cartoony for what I expect from Qubes.

[pwmarcz]

+1, I think it's pretty important that the service name is still shown - it's unique and pretty meaningful to how Qubes OS works. I am reminded of Ubuntu GUI updater which at one point stopped displaying package names at all and it made it very hard to tell what you're actually installing. And in Qubes, the security aspect makes knowing the identifier even more important.

User-friendly names would be a good thing, but not sure how to do that in a flexible enough way. That's because qrexec services can be added by extra packages (for example SecureDrop Workstation has few on its own, but also standard qubes services are spread across many packages, some optional) and it would be good to not alienate them.

At first reflex, this belongs in dom0 together with policy. It feels like a similar piece of configuration. And when you think of it, the service names are global, and user-friendly names should be too: you want to use them before knowing the target VM.

That's a problem if you install a new service in a VM and dom0 doesn't know about it. If we want to get fancy, maybe there could be a mechanism for installing new service configuration in dom0, similar to "confirm policy creation" Qubes used to have? When you install a new package in domX, you get a GUI prompt about installing configuration for that service, including user-friendly name and initial policy.

If we'd be going with per-service user-friendly names, we can also per-service define if the service argument should be included or not. For example Allowed: Start application "firefox".

Sure. "Start application %s"?

Anyway, this may be a little more complex than just adjusting notification text and may warrant deferring to a later time. @pwmarcz what do you think?

I agree. In the basic version (set of static config files in dom0) adding user-friendly names doesn't sound so difficult, but should at least be a separate change (one that would touch not only the notifications, but confirmation prompt as well).

I agree, though, that we're adding another potentially unfriendly bit of UI. The denied calls were failing silently before, so we don't know how often the user will see the message - if appear frequently (due to misconfiguration), it will be more important to improve.

[ninavizz]

I'm also thinking that all of this is best left for consideration in a holistic "Policy Management" UX effort, that'd include GUI for a Policy Manager?

I've scoped the UX effort for a policy management GUI, and this would be great to fold into that. Seemingly pedantic stuff like how to make plain-language/human text for each unique policy call, is actually very time intensive but important. Friendly can't obfuscate visibility into what's actually happening.

I appreciate all the detailed feedback, y'all! It's so important for me to learn, to get things right.

[marmarek]

@ninavizz important piece of information you might miss in this thread: by default "allow" notifications are disabled, unless specifically enabled for some service. Same for services with "ask" policy action - because you already got a notification, in a form of confirmation prompt. Do you suggest to change this?

That's a problem if you install a new service in a VM and dom0 doesn't know about it. If we want to get fancy, maybe there could be a mechanism for installing new service configuration in dom0, similar to "confirm policy creation" Qubes used to have? When you install a new package in domX, you get a GUI prompt about installing configuration for that service, including user-friendly name and initial policy.

(currently) you always need to add something in dom0 - a policy file, otherwise all calls will be denied. One of the possibilities is to do this through policy control api - its current state is rather outdated, for example it operates on the old policy format. But I think friendly names belong rather in the frontend (policy-agent), because:

• we may want less restrictive filtering of what is allowed in such user-friendly names (html formatting? utf-8 characters?) - and I'd prefer to not need to process such things in dom0 if don't need to (in GUI VM case, it would be in GUI VM only)
• having this in the frontend would allow you to have those names translated and switch translation using standard mechanisms (policy-agent is run as part of the user session, so standard local switching will work here too) - also, different GUI VMs could have different languages set and it should just work this way

[pwmarcz]

But I think friendly names belong rather in the frontend (policy-agent)

I agree, that makes sense. My point was about them being centralized, and I said dom0 because I'm not used to the arrangement with GuiVM yet.

[ninavizz]

@marmarek If the only user (ever) of a Qubes device is the same person who administrates that laptop, maybe not—but I'm thinking of use-cases in the enterprise. Which I appreciate to not be common, today, but if there is a desire to move in that direction that should be considered.

I just discussed an RPC issue wrt the SD Workstation, where in provisioning we disable copy/paste between specific VMs... but how is the journalist user supposed to know that?

Stuff that may not be relevant for today's users of Qubes, but might be relevant for tomorrows.

I don't know enough about the "Ask" policy to have an opinion on that, right now. Generally, I haven't done much investigation into learning about policies... but it feels like a meaty topic I should get my teeth into.