Absolutely agree. This reminded me that with absolute beginners I went even more backward teaching them MS Office. Bringing them some old desktop case, dismantled it in front of them teaching them what each component in it to which part of their organization refers, then how Windows refers to the real organization, then how folders and files refers with the real compartments and their content, then how Windows Explorer helps with that, then promising them when they learn Windows Explorer and its commands they will learn at least 30% of any other software, finally to get to the Office.
And I was spending about 30% of the courses just to get to the point to open Microsoft Word which turned out to be great investment which led us to have 10-20% time of the course to show their self-creativeness.
None of them, as far as I know, ever flooded their desktop anymore, but kept it clean.
Underlying effect we didn’t discuss was a layer of responsibility (meaning security) they got as a base for future advancing to their needs and wishes.
If I am reading your “offtopic” paragraph correctly, you showed them the nuts and bolts first, then taught them the front end.
That’s actually the exact opposite of GWeck’s approach, he shows them the front end first, then drills down to other things. If I wanted to emulate his approach with Word and Windows, I’d probably show them file manager and introduce them to the hierarchy of folders, Then show them how to get there both via explorer and the save-as and open dialogs in Windows. Then I’d do an introductory document in Word…then maybe jump back to explorer and move the file around to different places, copy it, rename it, open it up again so they can see nothing changed except where it’s being filed and under what name and then (maybe) delete it. At that point they can now navigate the abstract “filespace” well enough to manage their documents, they can create one and do rudimentary things to it. Then they know enough to really start learning Word.
Your point about teaching them about the file system before getting into word is a good one; it never occurred to me that lacking that is probably why so many desktops get cluttered. But I’m not sure if I’d go so far as to open up a box for that first lesson! [Second lesson: Why you want a D: drive even though Micro$haft tries very hard to hide the concept from you. Third lesson, those phony folders that are really combos of actual folders; which is why I don’t use them because I don’t know WTF the system is actually doing with my documents.]
[In Windows and even sometimes Linux I pick up some clutter over the yea rs simply from having a document that doesn’t “fit” in any pre-existing place and I am in a rush and defer figuring out exactly what to create for it to go into. But that means maybe four columns of icons in ten years and a lot of those are put there by software I install. I at least won’t have that issue in QubesOS as my qubes don’t have desktops, most disappear in a cloud of smoke when I shut them down anyway, and one shouldn’t work on documents in dom0.]
I would like to see that discussion here. Customising existing templates
is relatively simple to do - determining what should go in to them,more
difficult.
@Sven it probably wont surprise you to know that I follow the same
approach as you.
This isn’t the default install, and requires some configuration and
effort on the part of the user.
I have salted this in the past, so I’ll dig out those formula and post
them for review. The one area I am sure I am lacking is in browser - I
do not use bookmarks or history, and have not reviewed split-browsers - is
that approach workable and intuitive? If not, how should this be best
dealt with?
One area that I think can be hardened out of the box is qrexec policy -
e.g, setting deny policy for the vault rather than ask. Does any one
else have views on this?
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
It’s you who shaped my thinking more than any other community member. The pupil following the ideas of the teacher shouldn’t surprise anyone.
I haven’t looked into split-browsers either and are afraid I have little to add and are bound to repeat myself. I can and have made arguments for and against all kinds of browsers, but in summary I would boil it down to:
disposable for everything that doesn’t need state/login
compartmentalize as much as possible / useable
disable / limit scripting as much as possible
I use Brave mainly for performance reasons, but it has the added advantage that limiting scripts, tracking and fingerprinting are core features and do not require additional plugins. They’ve also made it very easy to set the defaults and adjust them on a per site basis so it doesn’t feel like a chore or gets annoying.
There are no scripts or salt to set this up. After generating my templates I simply create my online-dvm, launch it and make my most restrictive default settings in the profile without ever visiting any website. This becomes my template for disposables and I also clone from it for the more specialized qubes that will hold state. When I visit such a site for the first time I then use the shield icon to allow scripts for that specific site and maybe non-third party cookies.
I imagine one could automate the creation of the the qubes and placing the restrictive default settings / profile.
I have thoughts, but are unsure how useful they are:
There was a time when I used Kicksecure templates converted from debian-minimal. I wasn’t really able to tell what it was doing to harden beyond the descriptions on its website. What I did notice was a marked increase in memory usage and things being a bit slower. My understanding is that the later might have been an effect of AppArmor?
The problem (I think) I see is that any kind of hardening will require configuration (like a whitelist, checksum database, etc.) and therefore require a level of understanding and maintenance that might exceed both the willingness and capability of most users.
The later was at least where I failed: it appeared to me that to have any meaningful gains in hardening I would have to invest a lot of time learning and maintaining and reached the point where I wasn’t at all sure it would be worth the trouble (in the context of Qubes OS only obviously).
Maybe this at least get’s the ball rolling in terms of a discussion / proposals. I’d be happy to change my mind when confronted with new information.
Most of my templates are KS-based with both HM and LKRG enabled (and a bunch of extra hardening features listed in the various KS docs). Besides a slightly longer startup time I haven’t ran into major issues.
Yesterday I tried installing the malloc and kernel guard, they don’t need any extra time investment, you just install them and they do their thing.
It’s difficult to gauge how effective they are and if you get any meaningful gains, I couldn’t find any information on which in the wild exploits had been mitigated by either of them.
I also noticed an increase in memory used, my browser qube with brave increased from 850 MB to 1.2 GB under similar loads. The kernal guard also has a negative impact on CPU usage, around 2.5-5% in everyday use, but it should be a lot worse in high IO loads, like compiling source code.
I have switched my browser qubes to kicksecure, I have enough memory that trading some resources for extra potential security is worth it for me.
Yes it is a burden, it’s the price I pay for peace of mind. Also I’ve created a little workaround for DispVM startup time but beware (!!!) if used in a wrong way it will negate the advantages of edit/view in a DispVM.
The idea is to move the time penalty to the end of the session (shutdown, restart) instead of the beginning (e.g. have a DispVM pre-loaded). However if you then go an edit multiple files in the same session or forget to shutdown/restart you’ve shot yourself in the foot and the entire advantage of using DispVM’s is out the window. SO PROCEED WITH CAUTION and be sure you understand what you are doing!
I don’t, but one could to keep data compartmentalized. It’s a trade off between compartmentalization and ease of backup.
Since I follow the ‘never edit/view in storage qube’ rule strictly, I allow myself the exception of having it all be in the vault qube.
Nothing special at all here. Just make sure it doesn’t have a NetVM set and optionally base it on a minimal template to prevent yourself from accidentally viewing/editing anything in it. You’d probably want to install some packages in that template like a file manager, but that’s another topic. Make sure to consult the documentation should you choose to go down this route.
If you’d open an infected file (e.g. an office document with a macro exploit) it could potentially spread to other files stored in the same qube. I am assuming that files might be malicious no matter where they came from. As long as I only edit/view them in an offline disposable nothing really bad could happen – right? The malicious code executes in the dispVM, has only access to the file it came from and “dies” once the disposable closes.
)
Also I’ve created a little 