Web lists-archives.com

Re: Extending GtkMountOperation to support TrueCrypt/VeraCrypt




Hi there!

Sorry I haven't replied until now. I have been working to publish a
book, so the last few months have been very busy.

Replies below:

On Wed, Feb 7, 2018 at 5:52 AM, sajolida <sajolida@xxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxx> 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!

Thanks!

I'm happy to help with usability questions and share opinions/advice. :-)

>>> [...]
>>>> 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

I really like that you did a survey here to understand the users. This
is a very important step. You need to understand what the users want
before you can create a user interface that they will find useful.

> 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

In usability terms, you created a static prototype and did a usability
test with that prototype (aka "paper prototype"). This is a good way
to see how people will use the software before you put much effort
into creating the user interface.

> 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.

Option A works well, and you have data here to suggest that this would
be useful for more than half of your users. If the "More options" is
obvious, this solution should be a good tradeoff. (Pending usability
tests, of course.)

> 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.

Option B would seem like it has hung for many users. Even if you
displayed a "hang on .. trying to decrypt the volume .. this could
take 15 seconds" message, I'm sure many users would try to cancel the
operation before the 15 seconds expired.

Additionally, even for users who understand why it would take so long
to try again, I'm sure anyone who needs to open these volumes will
quickly become irritated that it takes a long time to open a volume.
Even if the Usability were very good, that's bad User eXperience (UX).

> 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.

To me, that seems like the best idea, but Allan and Jakub can comment
more definitively on integrating with the current GNOME design.

> 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?

UX questions are best brought to the Design team: Allan and Jakub. I
assist in GNOME usability testing during certain cycles, but not all
the time.


Jim
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list