GNOME.org
 

Re: Extending GtkMountOperation to support TrueCrypt/VeraCrypt

segfault:

Simon McVittie:

On Fri, 02 Feb 2018 at 18:02:24 +0100, Matthias Clasen wrote:

On Thu, Jan 25, 2018 at 2:15 PM, segfault <segfault riseup net> wrote:

   A team mate will also send an
   email regarding this to GNOME UX people in the next days, so you won't
   see any code from us implementing a GUI design that they have not
   accepted. I'm stating this so you can ignore the GUI design implications
   for now.


Hi,

I'm sajolida and the lead UX designer at Tails.

Actually, I haven't contacted the GNOME UX people yet so I'll instead
jump into this thread, putting Jim and intrigeri (from Tails as well) in
copy. Hi Jim, I really like your blog!


[...]

Doesn't sound like the greatest user experience, having to specify
a ton of arcane details like that...


I don't think features like this can be completely decoupled from their
UX. It is sometimes possible to make a good API for a low-level feature
without having the UI fully ready or thought through, but IMO it's usually
still necessary to ask yourself "what would a UI for this look like?" -
otherwise you'll accidentally produce an API that isn't sufficient to
back up the UI you want.

So I would recommend working with UX people to describe the technical
constraints imposed by TrueCrypt/VeraCrypt, then working out what a
reasonable UI to gather that information might look like, and only then
designing the plumbing to get that information down to the implementation
(indeed, having a rough design for the UI might make the right structure
for that plumbing obvious).

If TrueCrypt/VeraCrypt require a lot of technical minutiae to be specified
(rather than learning them from header metadata like e.g. LUKS does)
then it might not be possible to make the resulting UI particularly
friendly, but putting a bit of design work into a "least-bad" UI would
probably still be valuable.


In order to open a VeraCrypt volume, you can specify 5 parameters:

  - Whether the volume is hidden or not (boolean)
  - Whether the volume is a Windows system partition or not (boolean)
  - Password (string)
  - Keyfile, if you configured keyfiles you need to specify them in
    addition to the password (one or several files)
  - PIM, in addition to the password and keyfiles (integer)

https://www.veracrypt.fr/en/Personal%20Iterations%20Multiplier%20(PIM).html

The 2 boolean parameters ("Hidden" and "Windows system partition") could
be tried extensively (more on that later). But the other 3 ("Password",
"Keyfile", "PIM") need to be provided by the user if they were set when
creating a volume.

For example, you could need a password, 2 keyfiles, and a PIM in order
to open your volume if you configured it like that. These parameters are
not optional and I'm not even sure you can change the configuration of
your volume after it's been created.

I agree that they are quite arcane but if you set them and can't specify
them, then you can't open your volume.

We did a quantitative survey on users of both VeraCrypt and Tails to
find out whether these features are commonly used and they are:

  - 65% of Tails plus VeraCrypt users use hidden volumes.
  - 42% of Tails plus VeraCrypt users use keyfiles.
  - We forgot to ask about PIM and Windows system volume.

The full results are on:

https://tails.boum.org/blueprint/veracrypt/#survey

After that, we did a design sprint where we tested our design mockups
with people, some of them not very technical. Our mockups worked well
and people could relate fine to the different options:

https://tails.boum.org/contribute/reports/SponsorW/2017_12/#sprint

The audience for which we are designing this integration of VeraCrypt in
GNOME is people who already know the original VeraCrypt interface and
know that these parameters exist.

On these pages you'll also see the changes that we designed for GNOME
Disks. Our plan was to discuss this directly on devkit-devel.


The work on this part turned out more complicated than we
anticipated. The unlock dialog is not created by the GVfs monitor
directly, but by GtkMountOperation, which in turn calls
org.gtk.MountOperationHandler.AskPassword, which is part of GNOME
Shell, and which then finally creates the ShellMountPasswordDialog
(please correct me if I got anything wrong).

This means that we will have to patch a lot more, and more low-level
GNOME components than we anticipated, and we would like to ask for
advice on what the best way to solve this would be.

The only way I see is to extend GtkMountOperation (and
GMountOperation) by fields for the additional options, and create new
flags in GAskPasswordFlags, which can be passed down from GVfs to
ShellMountPasswordDialog. This could be a single "VeraCrypt-mode"
flag, or a separate flag for each of the required options I listed
above.

Do you see a better way?


If you could describe the required data a bit more, it might be
possible to figure out if we can describe this in a somewhat concise
way - it sounds like you need to add a file chooser button, an entry
and a combobox ?


For the time being, this is the design of our dialog:

https://labs.riseup.net/code/attachments/download/1843/gvfs-monitor-unlock-veracrypt-volume.png

We have the 5 parameters:

  - Hidden volume: Check box
  - Windows system partition: Check box
  - Password: Text field
  - Keyfile: File chooser (can be multiple)
  - PIM: Text field for an integer

To reduce the number of parameters displayed by default to the user we
could also use 2 different strategies:

A. Hide some of these options under a "More options" (or "Advanced
options") foldable section. If we do that, I propose putting:

  - "Hidden volume" and "Password" always visible, because they are used
    by more than half of the people.
  - "Windows system partition", "Keyfile", and "PIM" in the foldable
    section, because they are used by less than half of the people.

B. Silently try to open the volume with and without the "Hidden volume"
   or "Windows system partition" options.

   - If you specify to cryptsetup that you are trying to open a hidden
     volume, it takes 15 seconds to return an error when you enter a
     wrong password.

   - If you don't specify whether you are trying to open a hidden
     volume or not, it takes 30 seconds to return an error when you
     enter a wrong password.

   Yes, VeraCrypt volumes are always pretty slow to open. Here we have
   to make a trade-off between displaying these options and having a
   slower opening.

   For example, by default VeraCrypt hides the "Hidden volume" parameter
   and chooses the trade-off of having a slower opening time.

We are totally aware that the options offered by VeraCrypt are complex
and arcane but we decided to add support to VeraCrypt in Tails anyway
(in addition to LUKS) because it's still a reference tool for file
encryption outside of Linux (as reported by digital security trainers
and our own survey).

We want to integrate that support in GNOME because we think that it's
the way to provide a better UX (despite the complex options), especially
since the VeraCrypt user interface is even more arcane and complex. It
also has licensing issues that prevent it from being included in common
distributions.

segfault's question was actually more about the best way to implement
these options in GNOME. He proposed extending GtkMountOperation.
Our idea is to have a alternative dialog design for opening VeraCrypt
encrypted volumes (with all these options) while leaving untouched the
existing dialog to open LUKS encrypted volumes. So that the extra
complexity is only displayed when it's necessary.

But maybe there are other ways of implementing this that don't require
patching core GNOME components.

By the way, I'm not well versed into the way GNOME is organized and I
wonder what is the recommended way of raising UX questions. Should we
discuss them on the mailing lists of each project? Should we write to
Jim, Jakub, and Alan? Put them in copy like I'm doing now?
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]