-----BEGIN PGP SIGNED MESSAGE-----
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
demographic.
* Retired roughly 2 decades
* 73 years old
* Degree in Computer Science
* Started out programming mainframes in Assembly Language (machine
code)
* Later, large-scale software development (various roles) -- R & D,
telecoms and mission-critical apps (those involved in health-care are
regulated)
* 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.
Wants:
* Reliability -- do not fail on me or, if something goes wrong, fail
gracefully.
* 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.
- ---------------------------------------------------------------------
Critique:
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).
Issues...
* 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
reasons.
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
else.
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
storage.
[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.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEe8Wcf7Po7bts2Rl4jWN9/rQYsRwFAlyMX+QACgkQjWN9/rQY
sRzdQQf/WltsYXQ+TQJgLmaJDSe8KtK2lJJyDzQ8uBVffwRsGX+8iD9r7HiJgAm6
v80S6AYPeVz00XpGB2QM3jHYNhFyIMcxVXDAh7NH6rwtnxLeGZef6ABtUCYRZX36
RNja8qSHt2cGp/JhSlrPtPMGjIUng1cuWbP4PT0qPAiwSYra8kMAYPWK6SHvXZ6E
g3FZ/pEGCBRDKdvAxCcT8vNNobDEssPvjvrYmWL92wij2seEvqwa78HrPVw1F1Gn
jbr6kAor+rd597eflHcR+XlEXBA46iMuHIuAU9R+phBCACaSH9tz1qAZ/8WJlGyY
vud5KdimUm4wgQ7HSbODqn0hmA/0bw==
=NPJ4
-----END PGP SIGNATURE-----
--
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
https://groups.google.com/d/msgid/qubes-users/4474d553-f69b-eb91-128b-5ebe74c9f2d1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
