Tails

#1 Updated by eloquence 2019-05-13 22:26:36

FYI, SecureDrop directly relied on this persistence feature as part of our setup instructions, to minimize the passphrase juggling required:

https://docs.securedrop.org/en/release-0.12.2/set_up_transfer_device.html

For now we’ll update our docs to work around this (tracker here: https://github.com/freedomofpress/securedrop/issues/4434), but it was definitely a nice convenience feature for SecureDrop admins.

#2 Updated by jonathonz 2019-05-14 01:05:59

Not just for SecureDrop admins. Everytime a journalist moves the transfer USB key, which is encouraged to have a long diceware password, this passphrase would need to be retyped twice (on the journalist and secureview stations) if the feature didn’t exist.

eloquence wrote:
> FYI, SecureDrop directly relied on this persistence feature as part of our setup instructions, to minimize the passphrase juggling required:
>
> https://docs.securedrop.org/en/release-0.12.2/set_up_transfer_device.html
>
> For now we’ll update our docs to work around this (tracker here: https://github.com/freedomofpress/securedrop/issues/4434), but it was definitely a nice convenience feature for SecureDrop admins.

#8 Updated by sajolida 2019-06-02 17:24:46

> At first glance, I strongly disagree: we ship dozens of programs that offer the user to “Save” stuff and unless the user explicitly chooses a destination file that’s on the persistent volume, “saved” stuff will be forgotten next time you reboot. So I would assume that the expectation this surrounding environment creates is that “remember”, as a synonym of “save”, implicitly means “until I reboot”. But perhaps I’m missing something behind your reasoning? I’m curious! :))) Anyway, this is probably moot because:

I understand. I think that this reveals another deeper problem which
relates to a core mental model issue around Persistence.

We say “leave no trace on the computer you are using unless you ask it
explicitly” when it actually means “leave no trace on the computer you
are using unless you ask it explicitly to Tails”.

And implies that people are able to make a clear distinction between:

• What is Tails (eg. Persistence settings, default KeePassX database
  location, Additional Software notifications, and maybe other things).
• What is not Tails (“Remember password” in GNOME Shell and maybe other
  places as you said).

The distinction is pretty easy for us to understand as veteran Linux and
GNOME users: we understand that Tails is an additional layer on top of
GNOME. But I bet that someone who knows little about computers and never
used anything else than Windows wouldn’t make this difference. So far
I’ve done very little usability tests with such people so I don’t have
good data on this.

But yes, I agree with you and we shouldn’t do what I proposed :)

> libsecret is the standard way for desktop apps to store secrets. Many programs use it and more may start using it at any point in the future. So I don’t think that a list of “significant use cases” there is for it in vanilla Tails currently is a good enough criterion wrt. making the data of libsecret’s GNOME storage backend persistent by default.

Ok, so basically we have a storage for secrets without knowing really
what it will store and this might evolve without us noticing.

I’m afraid that such a vague Persistence feature will be unhelpful for
users. They won’t be able to know, without evolved and time consuming
trial and error:

• What useful things will be stored in it (eg. the passwords for
  encrypted disks is stored but the password of the KeePassX database
  is not).

• What possibly dangerous things might be stored in it as well, without
  them asking it explicitly.

So for me it’s an argument in favor or not having such an unexplainable
and potentially dangerous Persistence feature.

I mean, if we can’t even know ourselves what kind of data GNOME Keyring
is storing, how can we expect our users to make a good “all-or-nothing”
decision for it?

#11 Updated by intrigeri 2019-06-07 10:50:18

sajolida wrote:
> intrigeri wrote:
>> At first glance, I strongly disagree: we ship dozens of programs that offer the user to “Save” stuff and unless the user explicitly chooses a destination file that’s on the persistent volume, “saved” stuff will be forgotten next time you reboot. So I would assume that the expectation this surrounding environment creates is that “remember”, as a synonym of “save”, implicitly means “until I reboot”. But perhaps I’m missing something behind your reasoning? I’m curious! :))) Anyway, this is probably moot because:

> I understand. I think that this reveals another deeper problem which relates to a core mental model issue around Persistence.

> We say “leave no trace on the computer you are using unless you ask it explicitly” when it actually means “leave no trace on the computer you are using unless you ask it explicitly to Tails”.

Exactly!

FWIW, I think for our persistent stuff we try to make the consequences of choices clearer (i.e. “$thing will still be here every time you start Tails”) than an ambiguous “save”, but that does not solve the fundamental problem we’ve spotted here.

> So for me it’s an argument in favor or not having such an unexplainable and potentially dangerous Persistence feature.

ACK.

#12 Updated by intrigeri 2019-06-07 10:52:45

> intrigeri: To go back to @jonathonz’s initial problem which was to save typing long passwords to unlock external storage, what security difference would it make for such users to store these passwords in plaintext in their Persistence or in a KeePassX database with a much simpler simple password? I mean, what kind of security GNOME Keyring offers on top of the LUKS encryption of the Persistence (and the screen locker when the session is running)? Shoulder-surfing protection?

At first glance, none compared to KeePassX, unless GNOME Keyring implements some kind of access control (e.g. an app can only access secrets it has stored there itself), which I don’t know. If it’s it worth me spending time researching this?

#15 Updated by huertanix 2019-11-06 18:30:49

Is there any way the “Remember Password” checkbox could be removed or not shown in the dialog altogether if it serves no function? This quirk is something we’ve had to explain to trainees and we’ll inevitably have a situation where someone either doesn’t remember this or gets onboarded without our training and will assume the feature will work when it doesn’t.

#16 Updated by intrigeri 2019-11-09 09:28:13

> Is there any way the “Remember Password” checkbox could be removed or not shown in the dialog altogether if it serves no function?

I took a very quick look and it seems that we can very simply do this (in GNOME Shell’s js/ui/shellMountOperation.js).
At the moment, the maintenance cost would be extremely low because we already patch GNOME Shell.
But once we upgrade to a version of GNOME Shell that has all our VeraCrypt support patches (Tails 5.0), hiding this checkbox will cost us a few hours a year in maintenance.

@sajolida, shall we create a ticket for this and put it in the Feature #14544 basket? Or is the UX benefit too small to be worth the maintenance cost?

#17 Updated by sajolida 2019-11-14 17:27:33

I would say that the UX benefit is too small to justify the maintenance cost. It would be different if we had more patches to GNOME Shell.