Facilitate intuitive user access to qrexec RPC policies in the GUI #4721
Comments
andrewdavidwong
added
T: enhancement
andrewdavidwong
added
the
P: default
|
A while ago just for fun I made a mock-up of this. Sharing it here just in case...
(ping me if you want the original draw.io file) |
andrewdavidwong
added
P: major
andrewdavidwong
changed the title
|
Commenting so I'm on this thread. Related discussion: https://qubes-os.discourse.group/t/policy-manager-gui-why-how-what/4079/6 |
|
Design brief for this project y'all! A "Design Brief" is a document that designers often create at the beginning of a project, to ensure we're on the same page wrt expectations and needs-priorities, as the rest of a team. It covers a general overview of the problem, users prioritized, design principles to employ in a solution, and pain-point priorities to address: https://docs.google.com/document/d/15ixJECkh_llFdVp014PMBsWMRLKUdaQ86LdAFpIzGis/edit?usp=sharing P.S.: @deeplow after a call with @marmarta this afternoon, I think I kinda understand your mockup from up above, now! :) Wd especially love thoughts from @mfc @unman @SvenSemmler and @DemiMarie; comments in doc should be open to anyone, and I'm also happy to receive feedback here, too. If the doc is too conceptual/broad leaving folks uncertain how to respond, that's also ok. Just want to ensure I'm on the right track. :) |
|
Thank you for the brief, @ninavizz. Some general feedback: Let real-world user needs determine the scope. Your primary target is the non-technical user base. We've had several reports from such non-technical users that they've been getting along just fine using Qubes as a daily driver never having heard of RPC policies before this effort. This indicates that the default policies are already sufficient for many users, possibly the vast majority. Let's not assume non-technical users need to mess with RPC policies more than they actually do, as this could easily lead to a project that's too large in scope. Overscoping can, in turn, result in a misallocation of time and resources. Worst, it increases the risk that a high-quality, complete, and working implementation fails to make it into a stable release in a timely manner. Currently, I'm seeing a lot of a priori speculation about what users need regarding RPC policies, and it's leaning toward maximalism. I suggest starting with a minimum viable product, getting it into the hands of users, and letting the resultant evidence determine how we iterate from there. I strongly suspect that a minimal implementation will be sufficient, since the need of even moderately technical users to manipulate policies is generally not great, while more advanced users are capable of using the policies in their current implementation. (On the other hand, some overeager users seek to manipulate policies more than necessary, in attempt to squeeze extra perceived security out of the system. An easier interface risks encouraging users with such predilections to fiddle with things even more, potentially to their own detriment.) In short, I agree with the scope suggested by @DemiMarie's remarks above:
|
|
On Tue, May 25, 2021 at 07:19:55AM -0700, Andrew David Wong wrote:
Thank you for the brief, @ninavizz. Some general feedback:
**Let real-world user needs determine the scope.** Your primary target is the non-technical user base. We've had several reports from such non-technical users that they've been getting along just fine using Qubes as a daily driver never having heard of RPC policies before this effort. This indicates that the default policies are already sufficient for many users, possibly the vast majority. Let's not assume non-technical users need to mess with RPC policies more than they actually do, as this could easily lead to a project that's too large in scope. Overscoping can, in turn, result in a misallocation of time and resources. Worst, it increases the risk that a high-quality, complete, and *working* implementation fails to make it into a stable release in a timely manner. Currently, I'm seeing a lot of a priori speculation about what users need regarding RPC policies, and it's leaning toward maximalism. I suggest starting with a minimum viable product, getting it into the hands of users, and letting the resultant evidence determine how we iterate from there.
I strongly suspect that a minimal implementation will be sufficient, since the need of even moderately technical users to manipulate policies is generally not great. (On the other hand, some overeager users seek to manipulate policies more than necessary, in attempt to squeeze extra perceived security out of the system. An easier interface risks encouraging users with such predilections to fiddle with things even more, potentially to their own detriment.) In short, I agree with the scope suggested by @DemiMarie's remarks above:
> This does not need to be very sophisticated, and does not need to expose every feature. Mostly, I am looking for a tool that avoids common reasons to edit policy files by hand, which could be offputting for some users, and is error-prone even for experienced users. For example, the tool could enforce that the policy files are always syntactically valid, and offer warnings about policies that are potentially insecure. Additionally, the tool could provide shortcuts for common tasks, such as remote GPG.
Can we have the brief somewhere other than google?
Not having seen it ,I am limited in what I can say, **but** I agree
with Andrew completely. Well, almost completely. If you put a tool in to
users hands, and they learn how to use it (after some struggle), they
are likely to see it as an essential part of their Qubes experience. If
they had never had the tool they would probably not feel the lack of it.
I think *exactly* this happened with the Qube Manager.
Non-technical users will very rarely need to interact with RPC policies,
and making a specific tool available to make it easy for them to do so
is likely to cause more difficulties than it fixes.
One solution might be to limit the policies that are exposed by this
tool, or to have an "expert" mode with strong health warnings. The tool
could also be used to point out or block policies that are potentially
insecure.
As a concrete example, do *not* allow a Clipboard Paste:
Vault @AnyVM allow
|
In case it helps, here's the PDF download as of now: Design Brief — QubesOS Policy Manager.pdf |
|
For what it is worth, I would like to contribute my 2 cents:
I do not think a policy editor as it is being currently discussed makes
any sense at all for non-technical users. The discussion (that I have
seen) centered around the capabilities of the existing policy framework
and how it could be mapped to a GUI.
I think that is the wrong approach and as @demi, @adw and @unman pointed
out the full power off that framework is rarely needed and if so should
be accompanied by a through understanding of what needs to be achieved.
What then?
I think it makes much more sense to collect very common use cases:
* select 'vault' qube and specify which other qubes are allowed to
connect to it (split-gpg)
* select default 'file open' disposable qube for each qube and whether
it should be started right a way or if the user wants the dom0 selection
dialog
* same for 'launch URL'
* select 'usb' qube and whether it should always allow keyboard/mouse to
connect to dom0 (default=ask)
* block the clipboard for a specific qube
I've have seen too many 'generic' GUI's build on top of 'human readable'
config files to just stand by and let this happen without at least
trying to change your mind.
If a user has a very special use case that needs editing of the policy
files but lacks the knowledge, chances are they won't get it right with
a GUI either or they are simply reproducing what someone told them to
do. In which case there is no difference between a GUI and the files.
The common user who "just" wants to have a USB qube or define what
happens if she clicks a URL ... won't be happy with a "policy editor"
either.
@nina I know you are a Mac user, so this example might be esoteric to
you: I think you a trying to build something like the Windows 'group
policy editor' or the 'registry editor' when what is really needed is a
simple and straight forward preference pane with the most common
scenario (completely hiding the existence of the underlying policy
framework).
|
|
Hi all! Dang, blown away by the amount and depth of feedback here... thank you all! Yet to really go through and more thoughtfully read it all. First off: to clarify... a "Policy Manager GUI" was approved as a funded project for a grant last year. At least, the wireframes/design/research part, were. So, there's that dragon, to slay the "Why this?" inquiry. Building upon @andrewdavidwong's feedback: I actually think this tool would be incredibly handy for non-technical users. IF done correctly, per @unman and @SvenSemmler's thoughts. Some qrexec thingys, such as things relating to fetching the latest apps list from a Template, or the latest app icons, I feel are best managed in the context of related functionality (so, Applications manager pane in each qube's Settings window). Based upon what I have learned from Qubes users in the SecureDrop Workstation pilot, the idea of having control of specific activities permissions between qubes, is both exciting and appealing. As I re-read through Joanna's (or maybe Andrew wrote that?) article explaining the "whys" of qrexec, the TL;DR on that, is basically that without qrexec, Qubes is just a colourful implementation of Xen; that the true power of qubes, is in qrexec stuff. Which, as I've observed a handful of new Qubes users becoming more and more familiar with Qubes over a year, I can anticipate they'd be excited about. That said—as I was going through a list of available policy services installed OEM with Qubes, about half of them struck me as "When on Earth would I ever need that?!" Many also struck me as one-time things I may want to do from a terminal to get information from, or are Services to power existing GUI features (such as the apps stuff cited above) and should be controlled from a contextually-relevant part of the UI. For the services that directly affect inter-qube i/o permissions, a Policy Manager GUI does feel appropriate. However, doing some user research to ask folks more about this, I have yet to and want to do. In order to do that, however, I need to understand some more info about each of the Services available to Qubes when it is installed... as well as more about how to create new Services. Both of those topics, feel like good opportunities to make use of a conversation and wiki in Discord, so I'll start both over there. In the meantime, for the core inter-qube i/o permissions stuff (GPG, clipboard, files management), I created an initial interaction model that I'd love feedback on for just that stuff. What may or may not be appropriate to go inside of it (so far as services are concerned) is TBD. I 100% agree, that adding form controls to abstracted computer-y lingo "so users can access advanced functionality" is pointless. I'm currently experiencing tension with that, in my prototyping tool. It has a whole panel available for non-developers to use for conditions and expressions and variables in Javascript—but to know how to use it, requires knowledge of Javascript, and the level of abstraction required to put together executable commands that make sense. So, it overlooks why I'm using that tool in the first place. Because my brain seizes when trying to abstract things in Javascript terms, yet I fully understand basic If This Then That logic. So, it missed the mark.
EDIT: Project focus has changed to not expose users to Policies architecture, which I fully support and agree with.
|
|
@unman Sorry for the Google-block! TY @andrewdavidwong for making a Proprietary Demagogue Format version. I will mull on how to better make those available for team consumption, that is less State spyware compatible for individual contributors. Possibly as "Issues" in my own GH, so folks can comment on a MD file. |
|
I think we should also include some static analysis, at least to avoid obviously dangerous situations. For instance, |
ninavizz
changed the title
ninavizz
changed the title
|
Ok! A couple actions I just took...
Discovery BoardGoal: To document Every. Single. Doggone.
Next-up, I'll edit the Design Brief to reflect the above feedback. I still feel we need to facilitate better user access to the full gamut of qrexec things, and tbh do like the idea of this project pivoting in that direction without prescribing a specific GUI artifact at the outset. |
|
Ok y'all... Marek had this to say, back in November, in response to @hackerncoder :
So, the backend has already been built, it appears, in a PR by @pwmarcz. Pawel, mind filling me in on what the minimum-bar might be for a GUI to be built to make your PR functional? Interaction model proposed a few comments ago (also, sorry my keyboard and my brain suck at not knowing how to create a Polish "L" with the little squigggle through it) for a "Policy Manager;" with 'management' implying viewing and editing and creating. @andrewdavidwong in the context of that discussion, you liked the idea of a GUI to edit Policies. Sincerely curious to learn what changed that thinking, from the design brief I wrote? |
|
On Tue, May 25, 2021 at 02:05:09PM -0700, Nina Eleanor Alter wrote:
@unman Sorry for the Google-block! TY @andrewdavidwong for making a Proprietary Demagogue Format version. I will mull on how to better make those available for team consumption, that is less State spyware compatible for individual contributors. Possibly as "Issues" in my own GH, so folks can comment on a MD file.
--
I'm sure this was meant as a joke, but from the beginning the PDF format was
open, and since 2008, it has been under control of ISO, so the format is
not and has *never* been proprietary.
|
|
@deeplow That link is like magic, TY!! Yep, also presumed that interaction pattern for details with settings that have params/args. @unman I sometimes receive flack for using PDFs, and appreciate your reminder of that! I also used to work for Adobe, and they try much too hard to monetize PDFs with proprietary tools. Internalized guilt feels, perhaps. |
|
This is just my personal opinion, but it still seems like you're trying to do too much. I have never had to create a new policy. I have only edited existing policies, and even much of that was unnecessary. I suspect most users are in the same boat. Users who do need more are advanced enough to learn how to do it (and probably already are). I won't tell you not to try. This grand proposal is more than we asked for and certainly more than we need, but, for all I know, it could usher in a new golden age in which users of all skill levels are able to manipulate qrexec services and policies with ease. I don't want to be the one who stood in the way of progress. I'll just point out that it seems like a big speculative gamble and somewhat overambitious, but if you're sure that this is one of those "if you build it, they will come" situations, who am I to say otherwise? 🙂
Ah, now that's a different matter. In that context, a user was setting up Split GPG, but he accidentally entered an extra character in his
The idea is a simple and familiar one: A policy editor tool could validate the syntax when a user edits a policy. If there's a syntax error, the tool would point out the error (and probably do other things, like refuse to save the new invalid policy until it's fixed). This is a pretty standard type of functionality for editor/validator tools for any kind of language that can have syntax errors. In fact, my thinking on this point has not changed at all. I still believe this would be one of the primary benefits of having a policy editor tool. Your brief, however, doesn't mention this at all and instead discusses a lot of other things about which I'm skeptical, as explained above. |
|
@andrewdavidwong I think there's only, like, 7 policies that would be editable by a new "Permissions Manager" per this project as approached per the current design brief (all ID'd in the far-right column of the Miro board); and a few tossed into the per-qube Settings manager. How do you feel that would be too much? Most of the policies I added towards the bottom of the spreadsheet, are new to me—and I'd planned to review with @marmarta to confirm their status as either in or out of scope for a "Permissions Manager" effort. My assumption, is that ~80% of all the policies on the Miro board are what I call "Backstage Actions;" things that support information or functionality already present in today's UX. Not as settings, but just helping Qubes do stuff. FWIW, It's a common activity for designers to perform functional audits at the outset of a project, so that all decisions are made with intent. Things are too often left behind or "oops'd" when that intent is not made out the gate.
This, I strongly disagree with. Journalists and human rights defenders are the most at-risk users, I suspect... and few, are at all technical. It is a significant burden to ask them to become technical, to keep themselves safe. Which is why I'm so committed to making Qubes more user friendly. A majority of today's users, are developers. Those folks don't "need" security, so much as they are aware of State surveillance and corporate privacy games and desire it. Their lives are not at stake. I'm personally more in this for the journalists and activists whose lives depend upon not being hacked; and I also see Qubes as being more adoptable to more folks, the less it's developed as a niche product for developers and researchers. @marmarek @andrewdavidwong On Andrew's point...
I leave this question up to you two, to determine the direction I take on this. It would be my own preference, to see non-technical users targeted as the primary audience, per the design brief. However Andrew's proposal seeks to build a GUI to support advanced users capable of translating their use needs into technical arguments—so that syntax errors can be avoided. I could do both as two separate deliverables; or one or the other. The GPG policy, on an aside, I'd planned to include in the user-friendly "Permissions Manager" UI; avoiding the mental gymastics of thinking in arguments for all users, altogether. Many, many users in our surveys, have expressed an interest in seeing these isolation and security concepts brought to a simple and intuitive UI, in part to spare themselves the mental gymnastics of thinking in syntax and arguments, and in part to just make it quick and easy for them to do things. No docs, no fuss. |
That was not at all obvious to me from looking at the brief and the Miro board. Seems much better and likely the appropriate scope!
Sigh. You've completely misunderstood me. I'm actually saying almost the exact opposite of what you think I'm actually saying. I'm saying that the security that non-technical users (the people you care about) actually need can be achieved with only a small amount of policy editing. For example, journalists might need Split GPG, but they probably don't need to be messing with
When I say, "It would be beneficial to have a tool to address problem type X," it should be understood that I would also welcome something even better that prevents instances of X from even arising in the first place. A tool in which users don't even edit policy files directly, thereby making syntax errors a thing of the past, could be a great way to prevent syntax errors from being a problem (could be, depending on a lot of things, and still won't help if direct editing is needed). But I'm not going to file a feature request for a bulldozer when a hammer will do (and when the dev already knows that a bulldozer would be better and can make her own decision about what to implement given the request). You seem to assume that I care more about technical users than non-technical users, which is simply false. I would have hoped that spending years advocating for the interests of non-technical users would count for something, but I guess not. |
I was starting to think that was happening. That's all on me, WHEW! :)
Nooo, not at all! I'm the new kid here. I'm just trying to follow what you're writing. I totally know and trust you want to protect non-techy users! But then I'd heard you advocating for a WYSIWG functions tool, so was confused. And then all the Updater stuff. So many conversations. All async.
|
|
> Users who_do_ need more are advanced enough to learn how to do it
> (and probably already are).
This, I strongly disagree with. Journalists and human rights
defenders are the most at-risk users, I suspect... and few, are at
all technical. It is a significant burden to ask them to become
technical, to keep themselves safe.
This is hard to watch. @nina we all get where you are coming from and
want the same thing.
The at-risk user needs a simple but powerful GUI to make decisions about
how their qubes interact ... to stay safe. Giving them the ability to
edit all the rules and achieve all the possible (and technically valid)
combinations will cognitively overwhelm them and is a bit like giving a
knife to a toddler.
Instead, we need to model the "what". In another thread I saw you
explain this very well. Instead of starting with the "features" and
defining the GUI from that, let's start with use cases and user stories
and model from there how the GUI should work. The goal should be to
allow them to make the important decisions easily and understand what
they are doing, rather than exposing all possible options to them.
Makes sense?
|
I actually tried this in the Forums, and only got technical answers. Outside of GitHub and Forums, doing this more broadly with user interviews would be time consuming and expensive—and I'd still need to understand & to learn about the qrexec system, to form human-value centric questions or activities to ask in interviews. And yet, GitHub and Forums both exist for people to get technical answers to technical problems. UX has historically almost never been attempted, in a distributed fashion. Before COVID, it was done between rarely and never. So, I'm doing my best to adapt my toolkit, to work with mostly asynchronous, all-distributed collaboration. Many of you have also never worked with a UX practitioner before, or have only worked on occasion with one. So, it's hard all around. Everyone here is a joy to work with, and I value a great deal. The last thing I want, is for anybody to feel any different, when working with me or together on these problems.
Yes, I realize this. That is why I did the qrexec audit. Look, Design Briefs are a communication tool. Not a gospel. It takes iteration to get them right; which is why they're done, in the first place. Then once everyone agrees on goals, assumptions, users targeted, priorities, and constraints, the design comes along more naturally. All of the feedback in this thread, has helped me get the design brief for this project, to what I feel is a much more accurate summation of goals and inputs. That's been a really good thing. |
|
DesignBrief_03.pdf, following the wealth of feedback. EDIT: Old version initially uploaded, correct one now behind link. Again: it is not a gospel. It is a communication tool to ensure everyone's on the same page, before I dive into wireframes. As it has surfaced misunderstandings or miscommunications, its doing what I'd intended. I should have likely stated that at the outset, and regret not having been more clear about that. <3 Wireframes, I'll likely begin next week. Lots else to do for other projects, this week. |
|
Collecting feedback of how people use qrexec policies over here: https://qubes-os.discourse.group/t/how-do-you-use-qubes-policies/4252 |
|
Based on feedback above, a rough proposal for proceeding forward. Need to focus on other stuff for the rest of the week, and am hoping to see more stuff trickle-in to the Discourse thread, above, so will return to this next week. As per my usual methods—if its magenta, it's an annotation. Helpful Feedback
EDIT: Updated with accidental/redundant supportive text removed. |
|
My feedback: because some sort policy always exists (at worst it's the default blanket deny, but for things like Clipboard defaults are broader), I'd rather toggle between CUSTOM and DEFAULT. |
|
"On/Off" is a simpler mental/cognitive model to grok for a UI switch, but I agree that it should be made totally clear that this is a customization module, not a creation module. Possibly then, w/o the switches, too. TY for the clarification! |
|
Yeah, I don't think it's a good idea to show everything for which a policy file exists (in any list, even "default"), because there are a lot of policies that exist by default that most users never need to worry about. They'd just be a confusing distraction. Probably better to just have a single whitelist of the ones you care about, or something. Also, the "default vs. custom" policy distinction (in terms of whether the policy file exists by default on installation) is extremely arbitrary and doesn't track what users care about. |
|
The on/off switch model seems ok, but a lot will depend on how it looks after switching to "on," e.g., how the user specifies the source VM, dest VM, and action(s). I'm not sure what the bit about "will always show 1:1" means, but if it means that it will look exactly like the policy text file, then I'm not sure what this tool solves besides saving the user from having to find the location of the policy file. |
|
@andrewdavidwong The "1:1" bit means offering switches and checkboxes and stuff, for "Allow," "Deny," and "Ask;" and the same, for whatever args/etc are available for each policy—while also using more intuitive/human language than words like "operation" or "service," etc. Possibly using complete sentences and stuff, potentially, too. I'm still squinting and confused-dog-head-tilting at many of the example policy files Marta sent me, to make sense of the literal policy formats. :) Anywho, I'm looking forward to having the bandwidth to dig into a couple of the above policies, to determine what those UIs look like, too! These are the problems I get really excited to solve for, as a designer. Stay tuned... |
|
I'm not really convinced for "on/off" model, if that's going to enable/disable non-default settings. For example, |
|
@marmarek I hadn't realized that Qubes comes with policies for everything, by default. @marmarta clarifying that in her comment above, negates the on/off model to me. So, yeah, we're in total agreement. Communicating a "Custom/Default" binary, parallel to what she suggested, feels much more appropriate—and inline with your suggestion, too. Switches don't communicate "Custom/Default," but other things can. @andrewdavidwong Users totally do care to know, if they've modified something or if it's "as the system designated it." They also care about what the system designates, in the first place. Bottom line, this is a permissions manager—and folks need to have visibility into 1. What the permissions are currently set to, and 2. Who designated those permissions—(themselves, an IT manager, or the OEM default). There are totally models for all of that, and I'll look to those for my next iteration. (aside: it's Friday, so I'm totally going to abuse use of the word "totally") |
Yes, of course, but that is neither what I said nor what I meant. I'm talking about whether the FILES exist by default. Please read my comment again carefully. |
Updated: New artifact for feedback!Latest wireframes, on Invision. https://invis.io/GN11L0IGBMQE#/457149162_Notes Note: Tor is unlikely to be friendly to Invision, as are some browser-based privacy tools. If folks need static JPGs, let me know and I can create a set. There's 23 pages, total, in this click-around quasi-prototype. Much as I'd like to be able to make this work more accessible, the goal with this format it to enable quick ideation. So, higher res JPGs is sadly the only option I have, for broadening its reach. Also, note: Moving away from the mental model of "I need to do a thing in my machine's policies" is very intentional, in these. Discoverability of functionality, matters, as does reduced cognitive friction in access to rich capabilities. EDIT: Most of the wires have gotten Marek's signoff on "correctness" and the general direction. The USB stuff is most of what is up in the air, right now. If folks have a lot of thoughts, please come to the design review—yet to be scheduled! Synchronous discussion is significantly more helpful and efficient to suss through on subjective points, than asynchronous written feedback. |
|
Have also created a thread in the forum, for feedback: https://forum.qubes-os.org/t/feedback-sought-system-global-settings-policies-ui-stuff/5888 |
|
Updated Invision to include:
|
|
This was completed by qubes-policy-editor-gui plus the new GUI policy manager. |
Qubes OS version:
Qubes release 4.0 (R4.0)Affected component(s):
qrexec
Steps to reproduce the behavior:
Look for a GUI tool for managing qrexec policies
Expected behavior:
Such a tool exists
Actual behavior:
No such tool
General notes:
This does not need to be very sophisticated, and does not need to expose every feature. Mostly, I am looking for a tool that avoids common reasons to edit policy files by hand, which could be offputting for some users, and is error-prone even for experienced users. For example, the tool could enforce that the policy files are always syntactically valid, and offer warnings about policies that are potentially insecure. Additionally, the tool could provide shortcuts for common tasks, such as remote GPG.
Qubes already contains a graphical editor for firewall rules, presumably for similar reasons, so there is precedent.
Related issues:
The text was updated successfully, but these errors were encountered: