Clearer Network/Internet UI Communication

General Discussion
1

Hello! This is a discussion to solicit ideas and feedback on what feels like a usability problem in Qubes. The primary “problem,” being too much forced-abstraction for newer users, in getting a basic handle on how their internet traffic is routed—and, on networking permissions.

The problem for me, began when I was having a discussion with a security trainer who recently traveled abroad with their Qubes laptop. In order to randomize their MAC address as others on shared networks might see it, and in order to create a “name” for themselves other than “Qubes OS Device,” they had to jump through a number of technical hoops. Both such things, feel to me like they should be easily surface-able and editable by users, in a UI somewhere.

Second, when I began to dig around in my own Qubes laptop’s networking, what the individual Qube Settings panel showed me for my sys-net and sys-firewall qubes, felt confusing and counter to what I understood of both. It took me a lot of time and mental gymnastics to understand how what both said, maps to reality. I am filing a separate bug on GitHub, to at least improve the language in both places.

HOWEVER… for a longer-term “solution” for less-technical high-risk users (so, yes, journalists and human rights defenders), I’d like to have some sort of a global “Network” settings pane in the TBD Qubes Global Settings pane.

The framework for the below pane, was created in response to the need to surface RPC policies in the UI (presented in this Forum thread). The framework on this screen, is the running solution for that; an overhaul of today’s Global Settings screen, with a left-nav for users to manage inter-qube permissions across a number of policy things.

Thoughts on the below? Does this make zero sense, do folks have concrete ideas for iteration, or other ideas, generally? Pink text = my annotations… on the below, just notes right now, spitballing what I envision for different areas.

EDIT: Tweaked the below image, so may be different than what shows-up in folks’ email.

Network
Network1775×1216 203 KB

4 Likes
2

Hi @ninavizz, you definitely want to read this thread and checkout @unman’s prototype.

2 Likes
3

Ohai @unman that is EPIC!! TY for sharing, Sven, This is soooo rad. YES, this needs to be included, somehow!

4

I like it! I have some ideas on how to display internet access without a graph. The idea is to group them by network paths

[internet] <-> [sys-net] -> [sys-firewall]
  - personal
  - fedora-33-dvm

[internet] <->[sys-net] <-> [sys-firewall] <-> [work-vpn] <-> [work-firewall]
  - work-mail
  - work-documents

Offline:
   - vault
   - work-vault

Not sure if it’s a good idea but just wanted to put it out there.

Just adding a note here that VPN configurations are something very hard to do in Qubes and that is proved by the amount of threads we have on VPN configuration (see here)

3 Likes
5

Networking stuff: abundant YES, thank you for the great idea deeplow!

VPN = Well, rats. I’d like to surface it on the frontend to be a piece of cake, and don’t feel that part of it should be too, too hard. As per usual: when millions of dollars or volunteers fall from the sky and into Qubesland, all of this should be possible! TY for the rad insights, as always, friend. :slight_smile:

1 Like
6

Just for context, there is actually a GUI-way of setting up a VPN. Not sure if it’s perfect, but does the jobs wihout ever using a terminal. It’s just not well publicized.

7

We used to have a network tree available from Qube Manager.
4.1 has qvm-ls -O NAME -t

2 Likes
8

Thank for this useful command.

The man page:

--tree, -t
       List  domains  as a network tree. Domains are sorted as they are
       connected to their netvms. Names are indented  relative  to  the
       number of connected netvms.
2 Likes
9

Yeah, unfortunately that’s not very discoverable. Also, requiring users to reference documentation to set stuff up, excludes scenarios where a user is facing a new threat, and needs to do something to protect themselves in a hurry (and potentially without an internet connection). Two different concerns there, being 1) Literal access to instruction, and 2) The luxury of time and cognitive ability to follow multi-step/detail-involved instructions when in a heightened alert/emotional state of mind.

I greatly appreciate that being a mostly-volunteer project, Qubes has to pick and choose its projects/battles wisely—and that “it’s in the GUI, but not intuitively usable” is not a strong argument to nominate a thing for being done ATM. I’d still like to be able to consider and evaluate alternatives for implementation as resources or volunteers find themselves available, though.

10

Not crazy @ninavizz (well I’m crazy so I would say that wouldn’t I).
I would also like to see this.

These were my thoughts some time ago:
What I think would be very helpful is if we could have a network manager in ‘dom0’.
Which shows us simply, visually, the networking of all qubes.
So if xxxis sysf-firewall show us this.
And clicking that would show us xxx : sys-firewall : sys-net

etc

Separate thread (sorry @deeplow )
Especially relevant, as I would also like for their to be improvement with the ‘x action dispVM’ - because sometimes I want a networked disposable VM and sometimes I don’t (with the same appvm base - it’s incredibly irritating to have to move the file to then open it, or launch a disp vm - it negates the benefit of the right click).

11

I think you have missed the point.
Since that tool, and output, is already included, it can be leveraged
(trivially), right now, to provide an overview of networking, if that is
wanted.

Whether a new user who hasn’t looked at the documentation, and has
little time, will be able to make anything of it, is a different matter.
We have different perspectives on this.

12

I didn’t miss Deeplow’s point. I think you missed mine.

I think that we’re all in agreement, that the most important priority is things “just being in the UI” or even feasible. Yes, it is great that things are at that point.

I don’t think it’s so awful that I’d like to make it better or more intuitive, so users don’t have to depend on documentation; or could protect themselves on the fly, without a significant time commitment. Which is the reality of many at-risk folks facing everyday threats.

I also don’t think I disagree with a lot of how you’d probably order priorities for Qubes, from your own perspective. I don’t see this being an especially high priority; but it did come from a user interview, so I wanted to document and explore an opportunity for it in a quick sketch.

1 Like
13

Ah, it read as if you were commenting on the qvm-ls -O NAME -t tree,
which is also not easily discoverable.
But you were referring to the VPN documentation.

Discourse insists on top-posting comments, so it’s often hard for me to follow a
thread.

Apologies.

2 Likes
14

No worries at all! I’d like to make them both easily discoverable, but also for your datavizzy-version of the networking diagram to eventually get surfaced in the UI. Both are incredibly useful.

1 Like
15

This might sound mad, but:
Couldn’t Qubes have an improved UI-package release scheme, along the lines of:
barebones/volatile/bleeding-edge
beta
alpha
stable
?

Primitive Insight Inside (not Intel)

As I understand it, some UI packages are not cross-platform and easily transferable between linux distros. My point here is, as with Qubes alpha and user-contributed packages - could we have user-contributed graphic packages with versioning? I agree with @ninavizz - the most important priority is things just being in the UI, make it stable later; (hence Q4.1).

16

For better and for worse, Qubes is a tiiny, tiiny project team. We are doing our absolute best, and our lead, Marek, lives/breathes Qubes OS. Your suggestion is not at all “mad,” it just presumes that more resources go into release management than is currently the case.

Until 4.0, the entire project was in many ways “bleeding-edge.” I’m also the first UX researcher to work on the project, with here/there UX design contributions having been made, previously. This thread speaks to a concern unique to a multi-environment system.

There has been zero work that I have been able to find, done by UX practitioners in the past, around how to present multi-environment experiences intuitively to users. So, there are many problems like this, for which there is no known paradigm—and we’re starting from scratch. Which is both exciting for us (as makers), but admittedly a bit tough on our users.

All we can ask for is patience, and to work with us as we seek engagement from our community of users on user research studies to iterate on frontend improvements. Because neither I nor the UI developer are full-time on Qubes OS, these will also take some time.

Bigger picture, millions of dollars falling from the sky would help all of this—but our project not being keen to the bondage (or profit desires, or ethics obliterations) of accepting VC funds, this has also not happened (as of yet).

Please just know that we’re doing our best, and that our project lead is very mindful to deliver the best possible experience—and that he (and the rest of us) sees the thousands of users and many, many project sustainers (donors) with high hopes, and that all of us are doing all that we can, with the resources we have.

Developing an OS; and an OS that has to be compatible with multiple distros, hardwares, and fully-built laptops, and is best-of-breed privacy, is NOT a trivial undertaking. It is much more resource intensive, than most projects, on an aside.

TY for your patience as we refine and improve… but, the above is just to manage expectations. :pray:t2:

2 Likes
17

(and, also—that outside of project leadership and paid resources, there are SO MANY amazing volunteers busting their humps, all desiring the same—a more stable, predictable, and easy to use, Qubes OS. None of what we have today, would be possible without their contributions. We see/hear your difficulties, and pls know are working on improving, within our means!)

2 Likes
18

imho, i see that, both are good things,
either the UX design, is slowly or vastly improved,

because, even if the UX design, is slowly improved,
but, from the user perspective, it does make sense,
because, the team has always focused, and prioritized on the security improvement,
which also strengthen its reputation, as a reasonably secure OS.

anyway, thanks @qubes-team