Tails

#1 Updated by intrigeri 2018-06-02 10:32:03

• 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 Feature #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 commit: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 2018-06-03 11:08:44

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

#4 Updated by sajolida 2018-06-04 19:25:44

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

#5 Updated by sajolida 2018-06-04 19:47:21

• 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: Feature #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 2018-06-04 23:16:11

• 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: Feature #15051.)

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

> - With auto-mount
>
> # User double clicks on the container.
> # 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.

> # User clicks on “100M Volume” in the left pane of Files.
> # Files opens the container.

> - Without auto-mount
>
> # User double clicks on the container.
> # User clicks on “100M Encrypted” in the left pane of Files.
> # User is prompted for the password by GVfs monitor.
> # 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
>
> # User opens Disks.
> # User chooses Attach Disk Image.
> # User selects container.
> # User is prompted for password.
> # A notification for the new place appears on top of the screen.
>
> - Without auto-mount
>
> # User open Disks.
> # User chooses Attach Disk Image.
> # New loop device appears in the left pane of Disks.
> # User clicks on the new loop device.
> # 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.

> # User clicks Unlock.
> # 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.

> # User clicks on FAT under the encrypted partition.
> # User clicks Mount.
> # 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
>
> # User plugs in the USB stick.
> # User is prompted for the password by GVfs monitor.
> # User clicks on “8GB Volume” in the left pane of Files.
> # Files opens the partition.
>
> - Without auto-mount
>
> # User plugs in the USB stick.
> # User clicks on “8GB Encrypted” in the left pane of Files.
> # User is prompted for the password by GVfs monitor.
> # 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).

#9 Updated by intrigeri 2018-06-10 16:34:40

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

#10 Updated by intrigeri 2018-06-10 16:34:55

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

#13 Updated by intrigeri 2018-06-11 13:16:28

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

#14 Updated by intrigeri 2018-06-11 13:16:38

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

#15 Updated by intrigeri 2018-06-11 13:43:57

• 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 2018-06-19 17:01:14

• 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 (Feature #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 2018-06-26 16:27:59

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

#18 Updated by intrigeri 2018-07-03 11:30:47

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

#20 Updated by intrigeri 2018-07-06 19:22:24

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

#22 Updated by segfault 2018-07-06 21:02:23

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

#23 Updated by intrigeri 2018-07-09 09:25:14

• 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 2018-07-09 20:15:44

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

#25 Updated by Anonymous 2018-08-16 10:21:17

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

#26 Updated by intrigeri 2018-08-19 11:48:34

• has duplicate Feature #5304: Propose mounting external disks added

#27 Updated by sajolida 2018-09-02 14:15:54

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