Defining our target audience for community guides, accessibility for new users

General Discussion
1

Hi

I would like to initiate a constructive community discussion following some unexpected feedback regarding recent documentation updates aimed at new users.

The goal of this conversation is to collectively clarify: What audience do we aim to serve, and what is the minimum skill level we deem necessary for a successful adoption of Qubes OS?

My perspective is guided by the following points:

Reducing cognitive overload: I would like us to provide tools and guidance to people who have general computer knowledge (coming from Windows, macOS, Android, or user-friendly Linux distributions) and to assist them in their journey with Qubes OS without a heavy cognitive load of “how do I get this done on Linux.” They already have a lot to understand.

All potential users are not tech professionals, nor they are tech enthusiast. Some just want to secure their computer and data. We should help users to focus their energy on what truly matters: understanding and using the security principles of Qubes OS.

Using Windows, macOS, Android, Ubuntu, or even Tails allows users to maintain daily productivity without having to learn terminal tricks for routine tasks. Why shouldn’t this be an equally valid goal in Qubes OS?

I know Qubes OS is not easy and it’s a patchwork of various things tied together that try to be consistent and usable. But we can certainly do something to help beginners to get started.

Providing support to users with less pre-existing knowledge and skills should not negatively affect the experience or functionality for our power users.

I look forward to hear other’s thoughts on this topic. Thank you for your engagement everyone :slight_smile:

15 Likes
2

This isn’t as easy as it sounds. The concept is simple, but nailing down details isn’t. The first question I think deals with Qubes itself. Do we intend to coddle new users or force them to learn Linux basics?

Coddling new users (I say this not in a negative way) is the obvious choice if we want to be new-user-friendly, but that requires intentional OS design, such as making a text editor universal, as in available on all templates (minus minimal) and making it default to present. Then, editing a file can be as simple as “open Application X in Y template.” But we can’t do that with just documentation.

If we decide to go documentation-only, users will have to learn Linux. This is more complicated and invites more questions. Should we point to a one-page doc that explains all the basics, such as editing files and installing packages in he most concise way possible, as a primer to future how-tos, or should we give users many small docs on how to do each individual thing?

If we choose the former, it has the benefit of allowing users to see everything all at once and get a better grip of what Qubes is, which is objectively better as it gives users a mental picture of Qubes and encourages familiarity with the system. If we choose the latter, it is objectively better in that users are not bombarded with too much information all at once all together.

Personally, I’d advocate for the latter, in which case scope becomes the issue. What is the smalles quanta of Qubes knowledge? I think it is best to illustrate Qubes-specific things in computer-generic ways, so that the Qubes knowledge is gained less consciously. “How do I edit a file?” is really answering one Qubes question, one Linux question, and one computer question. The Qubes question is “How do I find and use software already included on my system?”, the Linux question is “What does this piece of software do?”, and the computer question is “How do I edit a file?”

It would be nice to be able to symlink things together so we could answer how to find software in Qubes in its own article, and have the contents of that article show in the aforementinoed guide, and have both be updated together.

These are just the most basic considerations.

7 Likes
3

I don’t think that the definition of the target is the problem. I agree with you but I don’t think we are capable of providing the efforts to maintain quality and updated guides.

I would love it if Qubes OS provided the same kind of documentation as Tails OS. But Tails OS has a very narrow audience: activists (and, IMO, not every activist but only the ones with values in line with the project), journalists & sources and domestic violence survivors, mostly. Tails OS provides specific tools and procedures to follow to “[protect] against surveillance and censorship”. So unless the scope of the project is redefined, I think we currently don’t have the resources to provide the same level of beginner-friendly documentation, that’s why I think it’s better to focus on documenting only Qubes OS tools.

3 Likes
4

The required amount of skill is hard set by current security field and cannot be changed by qubes os documentation. If starting skill of a user is insufficient, determination is tested. Documentation can make this ride smoother, but extensive documentation leads to disrepair (and we have plenty of it in our current docs).

People often need to learn a lot to get into QubesOS. Trading volume in exchange for growing user skill set (especially if a skill can be applied in multiple contexts) might be useful. Not like I know how to do that :slight_smile:

2 Likes
5

My opinion is not so popular, but still holding it:

Qubes OS is not for everyone.

As most of the people not even understand it’s goal, and don’t have any clue what problems it might solving for them.

Another ‘opinionated’ analogy:

"An expert can avoid problems the beginners not even aware of"

And that’s the situation with Qubes OS.
The ‘Experts’ who actually understand the IT security landscape, and clearly see the ‘dangers’ might welcome the features that Qubes would be able to give them. Still most of those who - just call themself IT Security experts - are not willing to exchange the ‘comfort’ of their Windows/Mac PC :slight_smile:

My slogan of Qubes OS is like:

Qubes OS gives you the possibility to be the weakest link, even if you are an IT se security expert.

And no other OS can provide such…

But ofc it’s not means that Qubes OS is only for experts, everyone can learn… but the learning curve is very steep for beginners.

The pre-requirements of using Qubes OS - if you ask me:

  • To understand the fundamental problems it’s might save you from,
  • Understand the concept of virtualisation,
  • Basic understanding of the hardware related things like BIOS/UEFI,IOMMU, and PCI Passtrough
  • Real experience with Linux as a desktop - but at least the willingness to try out completely new things :wink:
  • Understand the concept of open-source - but at least accepting that the developers might not care about your specific problems.
  • Willingness to read the documentation.
  • Having a spare hardware to try it on.

I’m saying those based on my experience, and I’m using Qubes OS from it’s very first release, and I have held many (public) sessions about Qubes OS during this time. Based on that I really feel that if someone show the audience how it is looks in practice, and how it is supposed to be used, that’s gives them a huge initial boost compared to just reading the docs and trying out themselves.

Another disturbing fact that I’m working in the IT Security field for 20+ years, means meeting customers and SMEs from this field on a daily basis. Still, very rarely meet people who even heard about Qubes OS, let alone who tried, or actually using it as their main OS - like myself.

8 Likes
6

To achieve something special, you sure have a lot to learn. But to use Qubes OS to do basic things, like any other OS? I’m not sure. Don’t you think that someone could use Qubes OS with the default qubes provided during installation, and by following basic compartmentalization principles, they will still get some benefits from that?

3 Likes
7

The task at hand is not trivial at all. Qubes users have very heterogeneous levels of knowledge, so one might need to create documentation, how-tos, and best practices tailored to two or three different skill levels. And even then, there’s still a huge risk of completely missing the target audience / talking past the user.

Now I’ll throw out what might be a somewhat heretical thought, based on my own experience with Qubes. I installed Qubes 4.2 on my desktop first, then upgraded to 4.3, and I’ve been using this installation quite intensively ever since.

My Unix/Linux experience goes back about 35 years — it comes from my student days in a physics research group. A lot has changed since then, but some things haven’t (e.g., bash still works the same way).

Despite this (admittedly outdated) background, I would never have been able to successfully install and run Qubes without interactive help from AI. I frequently copied error messages 1:1 into the AI for analysis, asked for the exact commands to fix them, and gradually built up my basic understanding of Qubes through “conversations” with the AI while implementing my use cases.

I believe that in today’s world, it makes very little sense to create extremely detailed text-based documentation — at least not for new users.

Why don’t we simply start an AI based project that interactively guides users and helps them with the installation and day-to-day operation of Qubes? I’d be willing to invest a few hours per week into such a project.

3 Likes
8

Nope, user still needs to learn what IOMMU is to get started (or sift through HCL and markets and find a match). You need to be good at shopping and/or a nerd to install qubes.

And after that, in many cases, they are required to read troubleshooting documentation to set no-strict-reset on, say, a device that prevents them from starting sys-net and opening documentation in a browser. Whoops…

There is a way around this, of course, it should be possible to set no-strict-reset automatically if required to avoid this kind of problem. But it means nobody ends up here, which IMO is even worse.

QubesOS user either has enough knowledge to overcome stuff like this, or enough determination to get there anyway. High cognitive load when learning is a boon.

4 Likes
9

TL;DR: If you take security seriously, don’t do it. There are no shortcuts to difficult things. ‘Knowing how to do something’ is not the same as ‘knowing how and when to use it’. Some people sustain serious injuries from carrying ‘defensive weapons’.

A bit more detail:

To implement secure systems four things need to come together:

  1. The policy, which sets out what you’re supposed to achieve. (Usually discussed in terms of security, availability, processing integrity, confidentiality, privacy, etc.)
  2. The mechanisms, such as ciphers, access controls, ‘compartmentalisation’, hardware tamper resistance, anti-theft and so on, that you use to implement the policy. (This seems to be the topic under discussion here.)
  3. The assurance: the degree to which one can rely on each mechanism and how well they work together.
  4. The incentives: the motivation for those guarding and maintaining the system(s) to do their job properly, as well as the motivation for attackers to try to defeat the policy.

All of these interact. How can anyone fulfill the second part (mechanisms) without a deep understanding of the others?

2 Likes
10

I don’t know what IOMMU is :flushed:

3 Likes
11

Why do you think you need to?

1 Like
12

The non-technical user just needs a list of actions to perform - open this program, paste this command. I feel some of the current How-To guides capture this pretty well (Example: ProtonVPN setup)

Technical users can benefit from a brief descriptor for each step, but theyll ultimately couple your guides with their own knowledge & independent study

Include a referral over to this forum at the bottom as a catch-all for users who encounter an unexpected issue, youve got a doc that serves the whole community

3 Likes
13

And I agree.

As I say, when talking to someone with computer knowledge, I cannot recommend Qubes enough.

But when talking with someone with NO computer knowledge, I cannot recommend Qubes.

2 Likes
14

This is a very good idea! defining the audience is key when writing documentation or user-facing interfaces.

An industry standard is to define a couple of “personas” with short descriptions, for example:

  • technical user, interested in having a secure OS for standard everyday tasks
  • security researcher, studies cutting-edge OS security practices
  • independent journalist: needs a secure OS protect source anonymity

Once these are done, select which user persona(s) the docs are written for and structure them in the most accessible way.

6 Likes
15

To someone with NO computer knowledge, using Windows will be just as difficult as using Qubes OS. That person will be 100% dependent on someone else being able to help them use the system.

7 Likes
16

Nice idea. We already have Alice, Bob, Carol and … John. Bob isn’t a technical guy but, to be fair, a colleague of Bob helped him setup his Qubes system. So all this topic is about this guy.

4 Likes
17

I fully agree, but why not helping others to learn that?

1 Like
18

It’s the guitarist of Black Sabbath!

SCNR

2 Likes
19

In what way would learning not be supported? The documentation exists. There is also a forum with quite a few dedicated helpers (some of whom are also the ones who write the documentation or continuously improve it).

2 Likes
20

Nothing wrong with following HCL way

Alternatively you might know IOMMU under vendor-specific name: VT-d or AMD-Vi

Because QubesOS docs should be about QubesOS, and only providing instructions may be harmful. If documentation team has enough hands on board to maintain large, extensive documentation then sure, why not. But otherwise it would be better to let people study necessary topics elsewhere. Not like this kind of information is hard to obtain.

3 Likes