This is almost certainly the app that actually modifies the 50-* files you’re not supposed to edit. (I know in the case of update proxies, it is.) Thus, if you create a 30-* file you’re overriding the GUI and ensuring it will not function. (It will still change the 50- file but the change will have no effect.)
I personally (and with respect to the update proxy) modify the relevant 50- file, making sure the GUI isn’t running; the next time the GUI runs it will show my edit as the current selection. (Note, though, you have to be careful doing this, as with any edit of a policy file.) My edits to 50-* files are, however, automated to reduce the chance of a typo bodging things up.
It also depend on the use-case and if you are alone or not. It can be friendly for non-techies.
My father spend a lot of time playing a old online multiplayer game that tend to break itself time to time. Before he was playing on Windows and I regularly spent a lot of time finding out what got broken this time.
My father as near 0 skills with computers.
Two years ago I reinstalled his computer with QubesOS on it, and specifically configured it for his usecase, the most notable things is 2 desktop icon (it is custom scripts).
One of the icon launch the game. One icon redeploy a fresh vm with the game installed and configured, for the case when the game break itself.
So the instruction are simple “you want launch the game: click here”, “the game got broken again: click here to fix it”, “for anything that is not gaming, click on the software you want here” (for anything not related to gaming it is just one VM).
So now my father is able to “fix” the game by himself when it broke, so I spent way less time debugging it.
Actually, it is the smart way to use the best tool for the job. I went back and removed my extra file, and configured the policy using the config app, like you suggested. Thanks for pointing it out to me!
Since I had previously tried Qubes 3.2 many years ago, I knew it could be daunting. Thankfully 4.2 is much more user friendly.
Even for a security OS, usability is important. In fact, William Stallings lists it under the principal of “least astonishment” for the user.
I am grateful for the help and advice I have received in the forum. The sad part is I got 3 different options for setting the mouse to enabled, and only the last one was both simple and effective.
I consider myself very technical. I have a MSCS and MSEE, and work in IT. I have wrestled some hard problems at work. I don’t mind getting my hands dirty. At the end of the day, however, I have simple needs at home that I want to accomplish simply. I just want a bit more security than Linux alone can give me, which is why I am again trying Qubes.
Looking back at my comment I noticed that my choice of words was rather poor; yes, it’s indeed quite appropriate to use the config app; instead of “dummy way” I should have said “user way” (vs. “admin way”, which puts the developer docs into scope).
I agree that at this stage QubesOS can be quite usable for non-technical people, the biggest issue being various bugs, which, if they are encountered, do often require using the terminal to diagnose and fix.
Thank you for understanding and I did not take offense, but appreciate the rewording.
So far, I haven’t hit bugs as far as I can tell. Most of my issues are combinations of learning curve, out of date (for 4.2) documentation and just stepping into areas that maybe others haven’t ventured in yet.
In addition to my personal interest in Qubes, I am also using it for a term paper for a Network Security class I am in this semester. Part of that paper will cover the usability of Qubes as a daily driver, for folk who desire more security, but are not in a high-risk category that might require all of Qubes facilities. I am trying to come up with a simple setup for what I think would be a garden variety user:
a qube for private work
a qube for accessing “safe” internet sites: bank, amazon, zoom, email, youtube, etc.
a qube for accessing “unsafe” internet sites and content. This would be where they might open a URL or test an application that looked fishy
I didn’t include a work qube, mostly because I think many workplaces are moving to supply equipment to employees so they control the endpoint. One place I worked at was almost compromised via a spearfishing attach on an employee, that ended with them installing software with a remote access trogen (RAT) in it.
I also didn’t include a Windows qube since it was unclear if Qubes Windows Tools were being maintained.
Special cases are not included into statistics by default.
@rjrizzuto
I’m not going to pinpoint/argue about each and every aspect, such as what usability is and how personas come here into the context.
The title and OP got me under impression you’re not so techie and seek for help, but your last paragraph confused me.
You can’t have your cake and eat it.
Anyways, wishing you to use Qubes with ease.
Why not just create 30-user.policy?
The GUI will inform you about override, if that’s the case.
I am sorry if I confused you. Can you explain what part confused you?
I would rate myself as fairly technical. I have a MSCS and MSEE plus multiple decades of programming experience in Assembly, C, C++ Perl and C#. I have programed on embedded systems, Linux/Unix systems, and Windows.
I am currently taking a class in Network Security because security interests me. Last semester I took a class in Cybersecurity. I am trying Qubes out for the second time for the same reason.
Just because I am technical, doesn’t mean I know everything and never need help. I google the internet when I don’t know how to do something on Linux Mint or Windows. I do the same for Qubes, but have been having less success. I am glad that I can ask questions on this forum and so many people are willing to lend a hand.
I’ll try to keep the tilting at windmills down to a minimum
I do hope that the developers read some of the forum to help plan the direction o future development. If not, is there a better place to add concrete suggestions?
The devs definitely do read the forum occasionally and it is the appropriate venue for these kinds of discussions, though if you have a very concrete, specific improvement in mind, you could open an issue on GitHub of type “Enhancement request”.
All you accomplish by insisting on creating 30-user.policy instead of modifying the 50- file is to effectively disable the GUI. Sure the GUI will tell you it has been disabled, but months later, will you remember that you deliberately did so, and how? Because the GUI won’t tell you WHICH file is overriding it.
OK, you (Zeno) might remember this…but someone else taking your advice might not.
I took a look at the readme file in the policy directory. It says it is the directory that contains qrexec files, and to consult Documentation | Qubes OS. From there, it is all just a twisty maze of passages.
I’m sure there are cases where policy files are a better choice/have greater capability, but I’m happy to use the Qubes Global Config tool.
I see there is a nice Qubes Policy Editor tool as well, but I’ll stick with the config tool.
I can’t be sure because I’ve wiped out all my 4.1 stuff, but I suspect that file is unchanged from 4.1…in other words it was written before the 50-* policy files were even invented.
All I have basically done is find a way to automate changes that you could otherwise do in the GUI. (For example enabling/disabling the cacher.) Doing my automation on files numbered 30- would simply render the GUI powerless to do anything, since any changes the GUI makes to the 50- files would be overridden.
Almost everything I do is actually to files numbered 30-.policy (I have a LOT of these in fact) but in these two cases (USB and update proxies) there’s this new 50- series of files and I do not want to either override them or be overridden by them; I’m trying to cooperate with the GUI-based utilities and use the same schema they do.
I don’t recommend simply dumping other unrelated stuff into these files, by any means; only USB and Proxy related stuff. And I recommend extreme care and sticking with the format of the files.
All of that said, there is, I realized, one real reason to use 30-files for these cases, and that’s if you’re trying to test something out. If it doesn’t work, delete your 30- files and you’re back to normal.
BTW there is no reason your 30- file must be named 30-user.policy. I have a few policies in there but in most cases I create a 30-.policy file for related entries; it’s slightly more convenient that way when you’re managing them with salt. I have, in fact, five other files there whose name starts with 30- (And these are all policies that do not even exist on a default install; this is nothing a non-technical user need concern himself with.)
30-user.policy on my system is reserved for backups, opening links in a disposable, and opening files in a disposable (i.e., things the default system can do).
