Project

General

Profile

Feature #15628

Feature #14468: Add VeraCrypt support to Tails

Feature #15223: Iteration 2: Support unlocking VeraCrypt file containers in GNOME

Consider re-enabling automounting to improve VeraCrypt UX

Added by segfault about 1 year ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
05/30/2018
Due date:
% Done:

100%

Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
Affected tool:

Description

I just noticed that we disable automounting of media in Tails via dconf settings (462acd6). The automount = false setting prevents the GVfs monitor from automatically opening an unlock dialog if an encrypted volume is attached.

I'm confused about this, because I remember that I saw this unlock dialog multiple times in Tails, and I'm sure that was after the date of this commit (2013). In any case, I verified that in recent Tails versions (3.2 to 3.7) this dialog is not opened when an encrypted volume is attached. We should decide whether we want to enable automounting to make use of this feature and our work to add TCRYPT support to it.


Related issues

Related to Tails - Feature #15043: Iteration 4: Create VeraCrypt Mounter application Resolved 08/14/2018
Related to Tails - Bug #15767: Inserting encrypted USB drive does not prompt for decryption Confirmed 08/06/2018
Related to Tails - Feature #15900: Consider mounting external drives automatically (enable automount) Confirmed 09/02/2018
Duplicated by Tails - Feature #5304: Propose mounting external disks Duplicate
Blocks Tails - Feature #15238: Iteration 1: Write tests for unlocking VeraCrypt partitions in GNOME Resolved 01/25/2018

History

#1 Updated by intrigeri about 1 year ago

  • Assignee set to sajolida
  • Type of work changed from Discuss to User interface design

The automount = false setting prevents the GVfs monitor from automatically opening an unlock dialog if an encrypted volume is attached.

Is that dialog open when one clicks on the volume in Nautilus or in the Places menu?
(I'd like to understand whether our custom settings "merely" require one more user action or fully break some use cases.)

We should decide whether we want to enable automounting to make use of this feature

Right. Sadly, neither the commit nor #5314 (which was probably about migrating settings from GConf to dconf) explain why we disabled automounting.
So I did some archaeology with git log -p -S'auto-?mount' --pickaxe-regex config/chroot_local-includes/{etc,usr} and I've found that ff8440887add0bfce991ec80a7b118f143a89bf6 disabled auto-mounting in 2010:

commit ff8440887add0bfce991ec80a7b118f143a89bf6
Author: T(A)ILS developers <amnesia@boum.org>
Date:   Wed Dec 29 00:20:33 2010 +0100

GNOME: disable media automounting / auto open.

This was breaking the assertion on top of T(A)ILS homepage:

no trace is left on local storage devices unless explicitly asked.

I think this reasoning is based on the fact that mounting a filesystem read-write often leaves traces on the backing storage device, e.g. some filesystems keep track of the last mount time. So we have a UX problem at hand: is it better to match our design goals and user expectations as closely as possible (like we do currently) or to violate our design goals and user expectations in order to provide a nicer day-to-day workflow when plugging an external drive? I don't recall seeing info from help desk or user testing sessions about users not managing to mount an external drive so perhaps what we're doing currently is not too bad. sajolida, what do you think?

Another reason to disable auto-mounting is that mounting a filesystem this way will generally run risky code such as kernel FS drivers (that tend to trust the FS is well-formed, see the recent stream of ext4 and XFS security issues in this area) and Nautilus thumbnailers (that rely on media parsing libraries that have a very bad security track record). Now, one can argue that when plugging the drive, the user has already implicitly made the security decision to take their chances and trust the contents of said drive (as being non-malicious) to some degree. As a counter argument, I see quite a few people (who use desktop — not laptop — computers) who keep a number of external USB drives plugged in at all times. In such a situation I don't think we can assume the user has already made a security decision and thus auto-mounting would put them at risk without their consent.

Finally, there's a change management matter at hand here: Tails has not been auto-mounting external media for a long time so I would argue that at least some users have got used to making their security decision explicitly later than when plugging an external drive or starting Tails, by asking GNOME to mount the drive (or not doing so). If we change this behaviour, then these users will have to relearn how/when to make their security decision and until they do that, they will suddenly be exposed to new risks they might think they are (still) not taking. I'm not sure how weak or strong this argument is, food for thought!

and our work to add TCRYPT support to it.

IMO that's an orthogonal question: regardless of Tails customizations, TCRYPT support in GNOME should behave seamlessly to LUKS support. So on systems with automount enabled the GVfs thing needs to support TCRYPT. If we need to discuss this further, let's do it on another ticket so we keep this one focused on the automounting topic :)

#2 Updated by sajolida about 1 year ago

  • Related to Feature #14481: Release Beta for VeraCrypt support in Tails added

#3 Updated by segfault about 1 year ago

intrigeri wrote:

The automount = false setting prevents the GVfs monitor from automatically opening an unlock dialog if an encrypted volume is attached.

Is that dialog open when one clicks on the volume in Nautilus or in the Places menu?
(I'd like to understand whether our custom settings "merely" require one more user action or fully break some use cases.)

Yes, the dialog still opens if the volume is clicked in the places sidebar.

#4 Updated by sajolida about 1 year ago

  • Related to Feature #15043: Iteration 4: Create VeraCrypt Mounter application added

#5 Updated by sajolida about 1 year ago

  • Assignee changed from sajolida to segfault

I tested the differences with and without auto-mount in our three main scenarios:

File container with .hc extension

(It's not working for me but it should: #15051.)

- With auto-mount

  1. User double clicks on the container.
  2. User is prompted for the password by GVfs monitor.
  3. User clicks on "100M Volume" in the left pane of Files.
  4. Files opens the container.

- Without auto-mount

  1. User double clicks on the container.
  2. User clicks on "100M Encrypted" in the left pane of Files.
  3. User is prompted for the password by GVfs monitor.
  4. Files opens the container.

The actions are the same. The order is different but a bit more awkward. I'm not so worried and I can test without auto-mount during the user testing.

File container without .hc extension

- With auto-mount

  1. User opens Disks.
  2. User chooses Attach Disk Image.
  3. User selects container.
  4. User is prompted for password.
  5. A notification for the new place appears on top of the screen.

- Without auto-mount

  1. User open Disks.
  2. User chooses Attach Disk Image.
  3. New loop device appears in the left pane of Disks.
  4. User clicks on the new loop device.
  5. User selects the encrypted partition in the loop device.
  6. User clicks Unlock.
  7. User is prompted for the password by Disks.
  8. User clicks on FAT under the encrypted partition.
  9. User clicks Mount.
  10. User clicks on the "/media/amnesia/XXXX-XXXX" link or open the volume in Files.

The actions are much longer and more complex without auto-mount. It's the only use case that really worries me, especially given the fact that file containers without file extension are probably the most common case (according to our survey).

On the other hand, users on this path will already have to figure out that they need to use Disks and that they need to choose Attach Disk Image which I expect to block most users. The remaining ones are probably advanced enough (or already reading the doc) and might make it just fine through the extra hoops implied by not having auto-mount.

The solution we came up with for that was VeraCrypt Mounter (on top of its other benefits for discoverability). If we had VeraCrypt Mounter, could it also substitute auto-mount and automatically mount loop devices after they are unlocked?

Partition

- With auto-mount

  1. User plugs in the USB stick.
  2. User is prompted for the password by GVfs monitor.
  3. User clicks on "8GB Volume" in the left pane of Files.
  4. Files opens the partition.

- Without auto-mount

  1. User plugs in the USB stick.
  2. User clicks on "8GB Encrypted" in the left pane of Files.
  3. User is prompted for the password by GVfs monitor.
  4. Files open the partition.

The actions are the same. The order is different. It's the use case that worries me less.

Summary: I'm not as worried by the absence of auto-mount than I am about the absence of VeraCrypt Mounter.

#6 Updated by segfault about 1 year ago

  • Assignee changed from segfault to sajolida
  • QA Check set to Info Needed

sajolida wrote:

I tested the differences with and without auto-mount in our three main scenarios:

File container with .hc extension

(It's not working for me but it should: #15051.)

I fixed that now, it should work with the next build.

- With auto-mount

  1. User double clicks on the container.
  2. User is prompted for the password by GVfs monitor.

There is something missing here: A notification "100M Volume" appears at the top. If the user moves the mouse over it, it says "Open with Files", which it does when clicked. I think this notification is pretty helpful, 1. because it's another way to open the volume in Nautilus, and 2. because it tells the user the name ("100M Volume") of the volume, which they otherwise have to guess.

  1. User clicks on "100M Volume" in the left pane of Files.
  2. Files opens the container.

- Without auto-mount

  1. User double clicks on the container.
  2. User clicks on "100M Encrypted" in the left pane of Files.
  3. User is prompted for the password by GVfs monitor.
  4. Files opens the container.

The actions are the same. The order is different but a bit more awkward. I'm not so worried and I can test without auto-mount during the user testing.

File container without .hc extension

- With auto-mount

  1. User opens Disks.
  2. User chooses Attach Disk Image.
  3. User selects container.
  4. User is prompted for password.
  5. A notification for the new place appears on top of the screen.

- Without auto-mount

  1. User open Disks.
  2. User chooses Attach Disk Image.
  3. New loop device appears in the left pane of Disks.
  4. User clicks on the new loop device.
  5. User selects the encrypted partition in the loop device.

That's not necessary with my test containers. How did you create your container? I guess it somehow contains a partition table, which it should not.

  1. User clicks Unlock.
  2. User is prompted for the password by Disks.

Alternatively to the steps below, the user could also open Nautilus and click the "100M Volume" in the sidebar.

  1. User clicks on FAT under the encrypted partition.
  2. User clicks Mount.
  3. User clicks on the "/media/amnesia/XXXX-XXXX" link or open the volume in Files.

The actions are much longer and more complex without auto-mount. It's the only use case that really worries me, especially given the fact that file containers without file extension are probably the most common case (according to our survey).

On the other hand, users on this path will already have to figure out that they need to use Disks and that they need to choose Attach Disk Image which I expect to block most users. The remaining ones are probably advanced enough (or already reading the doc) and might make it just fine through the extra hoops implied by not having auto-mount.

The solution we came up with for that was VeraCrypt Mounter (on top of its other benefits for discoverability). If we had VeraCrypt Mounter, could it also substitute auto-mount and automatically mount loop devices after they are unlocked?

I wouldn't call it "substitute", because the automount feature is integrated into GNOME and VeraCrypt Mounter isn't, but yes, it could also mount the devices it unlocks (and automatically open them in Nautilus if we want that).

Partition

- With auto-mount

  1. User plugs in the USB stick.
  2. User is prompted for the password by GVfs monitor.
  3. User clicks on "8GB Volume" in the left pane of Files.
  4. Files opens the partition.

- Without auto-mount

  1. User plugs in the USB stick.
  2. User clicks on "8GB Encrypted" in the left pane of Files.
  3. User is prompted for the password by GVfs monitor.
  4. Files open the partition.

The actions are the same. The order is different. It's the use case that worries me less.

I agree. I guess users are used to opening the USB stick via Nautilus, in contrast to unlocking a file container they already mounted (attached to a loop device, actually).

Summary: I'm not as worried by the absence of auto-mount than I am about the absence of VeraCrypt Mounter.

I agree that VeraCrypt Mounter would help our users a lot. And since other GNOME users probably use the default automount setting (enabled), they don't have as many UX issues. So I would say, let's try to still implement VeraCrypt Mounter. Do you think it still makes sense to release the current state as the beta? It could give us some data to decide whether we should prioritize VeraCrypt Mounter (although there is not that much I can do with less priority, I still have to upstream the GNOME components ASAP).

#7 Updated by sajolida about 1 year ago

:

File container with .hc extension

- With auto-mount

  1. User double clicks on the container.
  2. User is prompted for the password by GVfs monitor.

There is something missing here: A notification "100M Volume" appears at the top. If the user moves the mouse over it, it says "Open with Files", which it does when clicked. I think this notification is pretty helpful, 1. because it's another way to open the volume in Nautilus, and 2. because it tells the user the name ("100M Volume") of the volume, which they otherwise have to guess.

Indeed! I missed that and it's another useful hint that's missing
without auto-mounting.

- With auto-mount

  1. User opens Disks.
  2. User chooses Attach Disk Image.
  3. User selects container.
  4. User is prompted for password.
  5. A notification for the new place appears on top of the screen.

- Without auto-mount

  1. User open Disks.
  2. User chooses Attach Disk Image.
  3. New loop device appears in the left pane of Disks.
  4. User clicks on the new loop device.
  5. User selects the encrypted partition in the loop device.

That's not necessary with my test containers. How did you create your container? I guess it somehow contains a partition table, which it should not.

I create it using VeraCrypt on Windows, trying to follow the shortest
path and the default options.

From the command line I can mount directly /dev/mapper/tcrypt-1793 as
VFAT so I understand that my container has no extra partition table.

  1. User clicks Unlock.
  2. User is prompted for the password by Disks.

Alternatively to the steps below, the user could also open Nautilus and click the "100M Volume" in the sidebar.

Indeed. I missed that because, as I was already in Disks it was more
obvious to me to stick with the same tool. But users who know Disks less
than me might behave differently.

  1. User clicks on FAT under the encrypted partition.
  2. User clicks Mount.
  3. User clicks on the "/media/amnesia/XXXX-XXXX" link or open the volume in Files.

The actions are much longer and more complex without auto-mount. It's the only use case that really worries me, especially given the fact that file containers without file extension are probably the most common case (according to our survey).

On the other hand, users on this path will already have to figure out that they need to use Disks and that they need to choose Attach Disk Image which I expect to block most users. The remaining ones are probably advanced enough (or already reading the doc) and might make it just fine through the extra hoops implied by not having auto-mount.

Something else I didn't consider is that it's also possible to open a
container without file extension with right-click → Open With Another →
Disk Image Mounter. Then the flow is similar than for a container with
extension.

My wild guess is that it will be a little bit easier for people to
discover but still quite hard. As you saw in the user testing, some
people try out the right-click and some other just don't consider it.

The solution we came up with for that was VeraCrypt Mounter (on top of its other benefits for discoverability). If we had VeraCrypt Mounter, could it also substitute auto-mount and automatically mount loop devices after they are unlocked?

I wouldn't call it "substitute", because the automount feature is integrated into GNOME and VeraCrypt Mounter isn't, but yes, it could also mount the devices it unlocks (and automatically open them in Nautilus if we want that).

Yeap.

Partition

- With auto-mount

  1. User plugs in the USB stick.
  2. User is prompted for the password by GVfs monitor.
  3. User clicks on "8GB Volume" in the left pane of Files.
  4. Files opens the partition.

- Without auto-mount

  1. User plugs in the USB stick.
  2. User clicks on "8GB Encrypted" in the left pane of Files.
  3. User is prompted for the password by GVfs monitor.
  4. Files open the partition.

The actions are the same. The order is different. It's the use case that worries me less.

I agree. I guess users are used to opening the USB stick via Nautilus, in contrast to unlocking a file container they already mounted (attached to a loop device, actually).

Summary: I'm not as worried by the absence of auto-mount than I am about the absence of VeraCrypt Mounter.

I agree that VeraCrypt Mounter would help our users a lot. And since other GNOME users probably use the default automount setting (enabled), they don't have as many UX issues.

Yeap, I was going to say that as well :)

Also, as a general note, I want to focus our work on Tails users and
their UX even if we're of course upstreaming our work to GNOME. Because:

- Tails users are our priority, GNOME users are happy beneficiaries.
- We can do stuff for Tails users that we can't do for all GNOME users
(like VeraCrypt Mounter).
- I'm more worried about discoverability for Tails users than for GNOME
users because Tails users might be very new to GNOME while regular
GNOME users should know it better already.

So I would say, let's try to still implement VeraCrypt Mounter. Do you think it still makes sense to release the current state as the beta? It could give us some data to decide whether we should prioritize VeraCrypt Mounter (although there is not that much I can do with less priority, I still have to upstream the GNOME components ASAP).

I'll answer that on #15043.

#8 Updated by intrigeri about 1 year ago

File container without .hc extension
[...]
The actions are much longer and more complex without auto-mount. It's the only use case that really worries me, especially given the fact that file containers without file extension are probably the most common case (according to our survey).

ACK.

On the other hand, users on this path will already have to figure out that they need to use Disks and that they need to choose Attach Disk Image which I expect to block most users. The remaining ones are probably advanced enough (or already reading the doc) and might make it just fine through the extra hoops implied by not having auto-mount.

After reading this, it seems to me that in order to succeed in this scenario ("File container without .hc extension"), the vast majority of users will need to read some documentation anyway, at least to figure out that they need to use Disks. So maybe the corresponding doc should boil down to "add a .hc extension" and then the user effectively lands into the "File container with .hc extension" scenario, which is rather well covered already, regardless of VeraCrypt Mounter and auto-mount settings, no?

#9 Updated by intrigeri about 1 year ago

  • Subject changed from Don't disable automounting to Consider re-enabling automounting
  • Status changed from Confirmed to In Progress
  • Parent task set to #15223

#10 Updated by intrigeri about 1 year ago

  • Blocks Feature #15238: Iteration 1: Write tests for unlocking VeraCrypt partitions in GNOME added

#11 Updated by segfault about 1 year ago

intrigeri wrote:

On the other hand, users on this path will already have to figure out that they need to use Disks and that they need to choose Attach Disk Image which I expect to block most users. The remaining ones are probably advanced enough (or already reading the doc) and might make it just fine through the extra hoops implied by not having auto-mount.

After reading this, it seems to me that in order to succeed in this scenario ("File container without .hc extension"), the vast majority of users will need to read some documentation anyway, at least to figure out that they need to use Disks. So maybe the corresponding doc should boil down to "add a .hc extension" and then the user effectively lands into the "File container with .hc extension" scenario, which is rather well covered already, regardless of VeraCrypt Mounter and auto-mount settings, no?

If we have VeraCrypt Mounter, according to our first user tests, users will probably be able to unlock file containers without reading any doc.

#12 Updated by intrigeri about 1 year ago

If we have VeraCrypt Mounter, according to our first user tests, users will probably be able to unlock file containers without reading any doc.

It's good to know that VeraCrypt Mounter would improve things this much, so we are better placed to compare the with and without situations.

#13 Updated by intrigeri about 1 year ago

  • Related to deleted (Feature #14481: Release Beta for VeraCrypt support in Tails)

#14 Updated by intrigeri about 1 year ago

  • Blocks Feature #14481: Release Beta for VeraCrypt support in Tails added

#15 Updated by intrigeri about 1 year ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (sajolida)
  • % Done changed from 0 to 100
  • QA Check deleted (Info Needed)

So, without auto-mounting the situation seems acceptable in any case:

  • if we manage to implement VeraCrypt Mounter it'll even be great
  • even if we can't implement VeraCrypt Mounter, my proposal above makes things not that bad: users need to read and follow one single instruction from our documentation (add a .hs extension) and they'll succeed in our worst scenario

#16 Updated by sajolida 12 months ago

  • Status changed from Resolved to In Progress
  • Type of work changed from User interface design to Discuss

During the user testing of the VeraCrypt beta, 4/5 participants would have benefited from automounting. I disabled automounting in my test ISO to match the current behavior of Tails.

  • P3 had a hard time opening the USB stick to access the file container in mission 1. She said that usually the USB stick appears automatically on Ubuntu.
  • P5 didn't notice the new label in the sidebar and wondered why "nothing happened" after he unlocked the container. He opened the container a second time before noticing the new label (he had 2 by then). He might have noticed better the notification in the top bar if automount was enabled.
  • P1, P2, P3 had a hard time navigating Disks and understanding that they had to mount the "Filesystem" that appeared after they unlocked the volume. Some of them used the label in the sidebar of Files instead of finishing the mission with Disks. All these users were already following the doc, but as usual people don't read on the web, they scan for the most relevant bits. Having to navigate between the doc and the UI also makes it harder to follow and more prone to scanning for relevant bits only.

So the consequences of the absence of automounting are a bit more severe than what I thought at first.

Summarizing the pros of disabling automount (#15628#note-1):

  • It makes a difference for people:
    • Who keep USB sticks always plugged in their desktop computers and are used to Tails not having automount.
    • I'm ignoring people who might plug in a USB stick in Tails without being interested in mounting it later on. Could this be a valid user case, like for forensics or such?
  • The benefits are:
    • Avoid leaking mount times when people have something plugged in that they don't want to mount.
    • Avoid running risky kernel FS driver, in case the filesystem is malformed or cannot be trusted.
    • I'm not mentioning the Files thumbnailer because, even with automount, this code is only run if people explicitly open the USB stick in Files.

So to me it seems like the benefits of having automount disabled benefits a very tiny portion of our user base and is only useful against crazy threat models. On the other hand, having automount would have slight benefits for a vast portion of our user base, especially users who are discovering Tails or using it very occasionally, without being harmful to them.

intrigeri marked this ticket as Resolved while commenting in favor of keeping automounting disabled while segfault has code in his branch that enables automounting (c707d4f128). See it seems like we need a bit more discussion... at least to make the code match whatever decision we will take.

#17 Updated by intrigeri 12 months ago

  • Target version changed from Tails_3.8 to Tails_3.9

#18 Updated by intrigeri 12 months ago

  • Assignee set to sajolida
  • QA Check set to Info Needed

sajolida wrote:

So to me it seems like the benefits of having automount disabled benefits a very tiny portion of our user base and is only useful against crazy threat models.

Agreed (modulo s/crazy/extreme/; people don't always get to choose their adversaries and they are not "crazy" merely because their adversaries are very powerful).

intrigeri marked this ticket as Resolved while commenting in favor of keeping automounting disabled while segfault has code in his branch that enables automounting (c707d4f128). See it seems like we need a bit more discussion...

FYI I marked this ticket as resolved as the conclusion of a discussion with segfault, during a VeraCrypt team meeting. (We wanted to discuss this with you but you did not show up, so we tried our best to take into account the input you had provided on this ticket.)

at least to make the code match whatever decision we will take.

Sure! That commit was reverted in segfault's branch on which the beta will be based.

Now, wrt. this:

During the user testing of the VeraCrypt beta, 4/5 participants would have benefited from automounting

This is good to know. Thanks for the additional data points.

We've decided to implement VeraCrypt Mounter because it would solve a great set of problems. We made this decision in a context when we took it for granted that auto-mounting would be disabled. Since then, segfault has implemented a first version of VeraCrypt Mounter. My understanding is that enabling auto-mounting would fix another set of problems, that overlaps in big part with the set of problems fixed by VeraCrypt Mounter.

So my questions for you are:

  • Once we have VeraCrypt Mounter, what part of the problems you've described above would remain and be fixed by enabling auto-mounting? I know you'll have to do some guesswork (to be 100% sure we would need to do some more user testing) but you did that already when you gave us a list of problems that would have been fixed by VeraCrypt Mounter, so I hope that's fine.
  • If we decide here to enable auto-mounting, how big are the advantages of shipping VeraCrypt Mounter? (Even if the code is ready, once we ship it, we have to maintain it, so there's a cost attached to it.)

As a side note, which will be relevant whenever we think about cost/benefit: enabling auto-mounting breaks big parts of our test suite. I did not check how hard it would be to fix all that.

#19 Updated by sajolida 12 months ago

Agreed (modulo s/crazy/extreme/; people don't always get to choose their adversaries and they are not "crazy" merely because their adversaries are very powerful).

Indeed, sorry for the bad formulation! I didn't thought about using
"extreme"...

Sure! That commit was reverted in segfault's branch on which the beta will be based.

I missed that, cool!

  • Once we have VeraCrypt Mounter, what part of the problems you've described above would remain and be fixed by enabling auto-mounting?
  • For P3 her problem was before even getting into VeraCrypt: she
    expected the USB stick to show up automatically like in Ubuntu or at
    least to appear in the Places menu. VeraCrypt Mounter wouldn't change
    anything. This problem is not related to VeraCrypt and existed since we
    2010 :) We could gather more data about how big of a problem this if we
    do other user testing involving plugging in a USB stick.
  • For P5, VeraCrypt Mounter would solve his problem if it can automate
    mounting the volume after unlocking it. If it can't automate this, then
    it might make the problem worse as P5 might have to discover that he has
    to open Files and do something from there.
  • The same will apply to partitions: if VeraCrypt Mounter can automate
    mounting a partition after unlocking, we're good. Otherwise it might
    create a problem as people would have to switch to Files to mount
    their volume.
  • For P1, P2, and P3, the problem came while mounting the unlocked
    volume from Disks. This only applies to volumes with keyfiles and
    VeraCrypt Mounter doesn't change anything here.

Still, the problem of P5 is the one that happens in the most popular
VeraCrypt scenario (unlocking a file container without keyfiles). So
solving this is the most important.

So my question to you is: will VeraCrypt Mounter be able to automate the
mounting of volumes after they are unlocked? If yes, then we can live
without auto-mounting. If not, then we have more arguments in favor or
enabling auto-mounting.

  • If we decide here to enable auto-mounting, how big are the advantages of shipping VeraCrypt Mounter?

The critical benefit of VeraCrypt Mounter is about discoverability of
how to use VeraCrypt in Tails. All participants (except P1 who read the
doc before trying anything) would have used VeraCrypt Mounter from the
menu if it had been there and might have avoided falling back on the doc.

Even if the code is ready, once we ship it, we have to maintain it, so
there's a cost attached to it.

When discussing implementing VeraCrypt Mounter in the last weeks we
forgot that during the UX sprint we had the idea of adding a
documentation launcher to VeraCrypt from the Applications menu if we
couldn't have VeraCrypt Mounter. That's always a possibility for the
distant future if the maintenance of VeraCrypt Mounter is too costly.
Tough that would be sad now that we have some code.

#20 Updated by intrigeri 12 months ago

  • Assignee changed from sajolida to segfault
  • Once we have VeraCrypt Mounter, what part of the problems you've described above would remain and be fixed by enabling auto-mounting?

[…]

Thanks for making this clear!

So my question to you is: will VeraCrypt Mounter be able to automate the mounting of volumes after they are unlocked? If yes, then we can live without auto-mounting. If not, then we have more arguments in favor or enabling auto-mounting.

I suspect it should be rather simple but segfault will of course know much better than me ⇒ reassigning to him.

  • If we decide here to enable auto-mounting, how big are the advantages of shipping VeraCrypt Mounter?

The critical benefit of VeraCrypt Mounter is about discoverability of how to use VeraCrypt in Tails. All participants (except P1 who read the doc before trying anything) would have used VeraCrypt Mounter from the menu if it had been there and might have avoided falling back on the doc.

Funny, after reading this, I immediately thought "let's add launcher called VeraCrypt that opens the doc and we're done with it". And then I read what follows :)

Even if the code is ready, once we ship it, we have to maintain it, so there's a cost attached to it.

When discussing implementing VeraCrypt Mounter in the last weeks we forgot that during the UX sprint we had the idea of adding a documentation launcher to VeraCrypt from the Applications menu if we couldn't have VeraCrypt Mounter. That's always a possibility for the distant future if the maintenance of VeraCrypt Mounter is too costly.

OK. This is good to keep in mind and helps me relax :)

Tough that would be sad now that we have some code.

It's correct we have some code and better than that, it is based on modern technologies and seems to be of excellent quality (just had a quick look). And I agree it would be sad to drop VeraCrypt Mounter, especially after we've asked segfault to write it.

To be clear, I have no obvious big concern regarding the long-term maintainability of VeraCrypt Mounter (it's a quite small piece of code), but that's mostly a statement of cluelessness: I have no idea about the future of the APIs and technologies it relies upon. I've just become extremely careful about the sunken costs fallacy and it's historically my role here to be the devil's advocate who asks the painful questions about long-term maintenance… and who, in practice, ends up maintaining quite a bit of our code, regardless of who wrote it in the first place :) Also, past experience shows that once we've added anything, it takes lots of discussion, planning and work to remove it (partly for good UX reasons, partly because of a culture that IMO we should change a little bit).

#21 Updated by segfault 12 months ago

intrigeri wrote:

  • Once we have VeraCrypt Mounter, what part of the problems you've described above would remain and be fixed by enabling auto-mounting?

[…]

Thanks for making this clear!

So my question to you is: will VeraCrypt Mounter be able to automate the mounting of volumes after they are unlocked? If yes, then we can live without auto-mounting. If not, then we have more arguments in favor or enabling auto-mounting.

Yes, mounting, i.e. making the volume accessible in the file system, is done automatically. And to open the volume in Nautilus, VeraCrypt Mounter provides an "Open" button for unlocked volumes.

It's correct we have some code and better than that, it is based on modern technologies and seems to be of excellent quality (just had a quick look).

Thanks! :)

#22 Updated by segfault 12 months ago

  • Assignee changed from segfault to intrigeri
  • QA Check deleted (Info Needed)

#23 Updated by intrigeri 11 months ago

  • Subject changed from Consider re-enabling automounting to Consider re-enabling automounting to improve VeraCrypt UX
  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)

segfault wrote:

So my question to you is: will VeraCrypt Mounter be able to automate the mounting of volumes after they are unlocked? If yes, then we can live without auto-mounting. If not, then we have more arguments in favor or enabling auto-mounting.

Yes, mounting, i.e. making the volume accessible in the file system, is done automatically. And to open the volume in Nautilus, VeraCrypt Mounter provides an "Open" button for unlocked volumes.

So the 3 of us decided that we can rely on VeraCrypt Mounter and live without auto-mounting, at least as far as the VeraCrypt integration project is concerned. sajolida may create a new ticket about auto-mounting in the general case.

#24 Updated by segfault 11 months ago

  • Blocks deleted (Feature #14481: Release Beta for VeraCrypt support in Tails)

#25 Updated by u 10 months ago

  • Related to Bug #15767: Inserting encrypted USB drive does not prompt for decryption added

#26 Updated by intrigeri 10 months ago

  • Duplicated by Feature #5304: Propose mounting external disks added

#27 Updated by sajolida 10 months ago

  • Related to Feature #15900: Consider mounting external drives automatically (enable automount) added

#28 Updated by sajolida 4 months ago

So to me it seems like the benefits of having automount disabled benefits a very tiny portion of our user base and is only useful against crazy threat models.

Agreed (modulo s/crazy/extreme/; people don't always get to choose their adversaries and they are not "crazy" merely because their adversaries are very powerful).

I kept thinking about this and someone referred again to this phrasing recently.

According to English dictionaries, "crazy" has different meanings:

https://www.thefreedictionary.com/crazy

I was using "crazy" as in "Departing from proportion or moderation" and "Extremely; very" but not as in "Mentally deranged". I made the bad choice of using a polysemic word but I never said that people under extreme threat models were mentally deranged.

#29 Updated by intrigeri 4 months ago

I was using "crazy" as in "Departing from proportion or moderation" and "Extremely; very" but not as in "Mentally deranged". I made the bad choice of using a polysemic word but I never said that people under extreme threat models were mentally deranged.

Point taken!

Also available in: Atom PDF