Hash: SHA256

*A Critique of Qubes*

Before discussing Qubes, I want to give you a bit of background about
me. I do not want to tell my life-story, I doubt anyone is interested.
However, I want you to know "where I am coming from" and what I want
from Qubes. I am keeping in mind that what I want is just that and
Qubes may not be intended to satisfy, or interest in satisfying my
wants and needs -- that is, I may simply be part of the wrong

* Retired roughly 2 decades
* 73 years old
* Degree in Computer Science
* Started out programming mainframes in Assembly Language (machine
* Later, large-scale software development (various roles) -- R & D,
  telecoms and mission-critical apps (those involved in health-care are
* Proprietary H/W and OSes, then various Unixes.

I am not paranoid over privacy and security, but I recognize there are
many individuals who, rightfully, fear for their privacy and anonymity
- -- their livelihood and even their lives may depend on it.


* Reliability -- do not fail on me or, if something goes wrong, fail
* Reasonable security -- more than is provided by the more standard
  Linux distributions (I am a fan of Linux Mint).
* Reasonable privacy (I hope that is not an oxymoron); though perhaps
  it is too late in the game for me (though I have never been a fan of
  social media, or anything Google)
* No need to spend large amounts of time tinkering with my basic
  personal computer setup.
* Ease of use and administration, including software installation.
* GUI for virtually everything unless there is a really, really, really
  good reason to use a CLI. Do not get me wrong, I am comfortable with
  CLI's, but I do not want to spend my time researching various Linux
  administration tools. Consider me lazy if you wish.
* No need to build my own tools to use Qubes (I do some website and
  server- side development to keep the neurons firing -- I can do all
  the programming I want in that environment).

Basically, my personal computer(s) is a tool. If I write some software
on it, that software will be for some other purpose and not to
complement the OS.

- ---------------------------------------------------------------------


I started using Qubes for my main computer about two months ago. I had
previously experimented with release 3.2 and 4.0 on my HP laptop and
ran into various problems -- discussed by many users ad nausium in
qubes-users. I got a nice little desktop computer for Christmas (from
my wife :-) -- an Intel NUC7i7 (32 GB RAM, 512 GB SSD).

So I started from the beginning. Installing Qubes 4.0.1 was relatively
straightforward, although it did require researching the use of a USB
mouse and keyboard.

Basic configuration was no worse than any Linux distribution I have
played with. Software installation was not as straightforward. I was
forced into using the CLI (I do have two proprietary programs: VueScan
and Bcompare). Installing other software can be problematic. I
installed Chromium. The install appeared successful. I was able to add
Chromium to an appVM. When I started the appVM and launched Chromium
from the menu... nothing! No window, no error message. I tried a number
of times (the reason for just re-trying will be mentioned below).


* When launching a program from the Qubes menu, particularly if the
  target   appVM has to be started, the program often fails to be
  launched. This happens very frequently with the Text Editor.

  This is annoying as one waits a bit in case one is simply being
  impatient, or at least I do, so as not to launch two copies of the
  program by accident.

* When a USB device is attached to an appVM, there is an appropriate
  notification. When it is detached, there is a notification that the
  device is being detached, but no notification to indicate that it has
  been successfully detached  so how long should one wait before
  unplugging it?

* Ignoring whonix (I do not use it... yet), there are two template VMs
  in the vanilla Qubes 4.0.1 installation: Fedora and Debian. However,
  they have not been treated equally, with Debian being the loser. The
  Qubes documentation indicates that Fedora was favoured for security

  Since I had been using Linux distributions based, directly or
  indirectly, on Debian, when I first set up Qubes, I created my appVMs
  based on Debian. That  was painful as I then had to install a lot of
  basic software.

  When I re-read the documentation, I realized the security reasons,
  so I switched all my appVMs (except one!) back to Fedora. It was not
  painful, but I would have rather have spent the time doing something

  The kicker came when Firefox stopped playing Flash content in my
  untrusted appVM, complaining that I needed an up to date version of
  Flash. I installed the most recent version, but that did not solve
  the problem. The problem is/ was something to do with Fedora (or the
  version of Firefox for Fedora or ??).

  Since Firefox and Flash were working fine on my Linux Mint laptop
  (which I use "to play with"), I re-based my untrusted appVM on Debian
  and, lo and behold, Firefox and Flash worked just fine. This, by the
  way, was when I attempted to use Chromium.

  The appVM that had remained Debian-based (the "except one" mentioned
  above) is my "entertainment" appVM that I use for streaming radio via
  Firefox and playing audio files (VLC player).

  At least for some people, it seems Debian is a necessity, but it is
  not given the attention it deserves. At a minimum, a GUI software
  installer should be included in the Qubes distribution which would
  make it much easier for people to install other software they feel
  inclined to use.

* Screenshot only appears to work from Qubes Tools. I can "add"
  "Screenshot" to appVMVs based on Fedora (but not on Debian). But it
  does not work -- The dialog comes up but, having chosen to select an
area, I cannot do so.
  Subsequent attempts to use Screenshot do not even present a dialog.

  Although I have not seen this documented anywhere (which does not
  mean it is not), it seems logical -- dom0 owns the screen (monitor),
  so it makes sense that it handles screenshots. However, that means
  screenshots are saved in dom0 and have to be moved (or, I suppose,
  copied) to the desired appVM. It seems a bit awkward. If one is in a
  program in an appVM and decides a screenshot would be nice, it is
  probably focussed on that window or a portion of it. Since the OS
  displaying the window "knows" what it is displaying, it seems logical
  that some kind of screenshot could be made by that OS, but restricted
  to its window.

  If not, why is it possible to "add" Screenshot to an appVM?

* About a week ago, I started having a problem: I could not
  copy-and-paste between appVMs. Prior to that, I had been having
  problems with Firefox freezing in different appVMs. Rebooting the
  affected appVM solved (or should I say "worked around") the latter
  issue; however, it had no effect on the former problem.

  [Aside] Ever since my mainframe and Unix days, I have been used to
          systems that would run for weeks or months between reboots.
          That experience did not carry over to personal computers
          until relatively recently (in terms of years) when improvents
          in hardware and my switch to Linux got me back into the habit
          of rebooting only when necessary.

  Using Linux and now Qubes, I not only do not shutdown the computer
  (i.e. power-off), but I do not logout -- I simply "Lock the Screen"
  and power-off my monitor.

  So, wondering about the copy-and-paste problem (and also the Firefox
  issue), I decided to re-boot. I individually shut down each VM after
  quitting its running programs -- dom0 and the sys- VMs excepted,
  before clicking Shutdown (rightmost menu with my user name on it).

  That looked like it solved the problems, but...

  KeePassX 2 complained that I had the wrong password or the database
  was corrupted. It was not a typo in the password (I tried several
  times and restarted the vault VM to be sure nothing was wrong).

  I was able to restore the vault VM from a backup, but was missing a
  few entries. That was alright since my real password vault is on my
  smart phone (FWIW, I use mSecure and keep it automatically backed up
  to DropBox).

My Bottom Line:

I can live with most of the issues described above. What I cannot live
with (and worry about) are stability and reliability issues.

[Aside] I do not intend doing a daily full back-up. I do not wish to be
        hypocritical, so full-disclosure: When I was managing the
        internal hardware and software support teams at a Bell-Northern
        Research lab., I insisted on daily backups. When managing the
        "System Programming" group for a mainframe (same as the modern
        "System Administration") the scheme involved daily, weekly,
        monthly and  annual backups of data files and backups whenever
        the operating system was updated, withappropriate off-site

[Disclosure] I run a FreeNAS file server on a computer on my LAN
        Whenever I create (or update) a file that involves my family
        (that is, something legal, financial, or similar), I *always*
        copy it immediately to the fileserver. In that sense, the only
        "stuff" I will lose in a catastrophic failure of my personal
        computer and my Qubes backups, is personal stuff not involving
        my family.

        My wife has access to the file server. My wife knows the master
        password to my mSecure password vault (and I to hers). One of
        our children has those master passwords in a sealed envelope).
        In fact, my wife has the keyphrase for my encrypted Quebes disk
        (Luks?) and my login password -- that does not mean she could
        manage to navigate Qubes, but I intend to show her.

[Question] So, what do other Qubes users do to protect their families
        in case they die/get killed, get imprisoned, go missing?

I need some reasonable assurance that data corruption on disk has a
very low probability. I need some reasonable assurance that the
operating system (the combination of Xen and dom0) is stable.

I will probably survive regardless. However, I assume (hope) there are
others like me. Qubes addresses a relatively small proportion of the
population. However, it does not hurt if it can include people like me
 if nothing else, some of us would undoubtedly donate money and help
support Qubes. The user base may be very small, but there is no reason
to force it to be tiny.


You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to