Re: Extending GtkMountOperation to support TrueCrypt/VeraCrypt

[Jim Hall]

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

Re: Extending GtkMountOperation to support TrueCrypt/VeraCrypt

[sajolida]

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

Re: Extending GtkMountOperation to support TrueCrypt/VeraCrypt

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

smcv
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Extending GtkMountOperation to support TrueCrypt/VeraCrypt

[Matthias Clasen]

On Thu, Jan 25, 2018 at 2:15 PM, segfault  wrote:

> (I resend this email because the first one awaits moderator approval
> since a few days, because I was not subscribed to the list when I sent it)
>
> Hi,
>
> we at Tails (tails.boum.org) are currently working on adding support for
> TrueCrypt and VeraCrypt volumes in udisks and GNOME Disks (see also the
> corresponding thread on devkit-devel [1]). 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.
>
> Beside other things, we also want to support unlocking via the GVfs
> udisks volume monitor, which automatically prompts the user to unlock
> encrypted volumes once they are plugged in. In order to fully support
> TC/VC volumes, the unlock dialog shown to the user must allow specifying
> several other options than only the password, namely: keyfiles required
> to unlock the file, a PIM value [2], and whether the volume is a hidden
> volume, a system volume, or neither.
>

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


> 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 ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list