Persistent Storage feature: language and keyboard layout in Welcome Screen

• Context
• Decision
• Options
  • Always encrypt
  • Always ask the user to choose
  • Don't encrypt by default
  • Never encrypt
  • Implementation

Context

I worked on design ideas to allow saving the language and keyboard layout from the Welcome Screen as part of my work on the Persistent Storage in #15572 (closed).

@segfault already made it possible to save these settings encrypted in the Persistent Storage in #17136 (closed). It's a great first step but our original idea was to allow saving these settings unencrypted in the Tails system partition in order to have them applied straight away and before unlocking the Persistent Storage.

That's particularly important for the keyboard layout: users will have configured their Persistent Storage with their preferred layout and their passphrase might be different when typed with the default English layout. Special characters, which people have been heavily recommended (or forced) to use for years, are particularly affected here.

We will also have to solve a similar problem to allow saving accessibility technologies from the Welcome Screen in #18156.

Actually, this issue turned out to be the most hairy part of the design work that I did for #15572 (closed). @segfault and I couldn't agree easily on what was the best solution, so I'm describing here the various options that I could design and I am asking for comments to help us make a final call.

I'm focusing on first time use because it's the most important and complicated at the same time.

Decision

We'll implement the "Never encrypt" option.

Options

I see 4 options:

Always encrypt

Always store the language, keyboard layout (and accessibility options) in the Persistent Storage.

This is roughly what we have now. I haven't designed the UI needed to make this option available in the Welcome Screen.

Pros:

• No private information is ever saved to the USB stick, which matches the promise of Tails and the Persistent Storage.

Cons:

• People might not know how to type their passphrase with an English keyboard.

  I thought that we could use a second key slot of the LUKS header to store a version of the passphrase as if it was typed with the default English layout. It sounds hackish and might be a can of worm but it could workaround some pain for our users if we decided to always encrypt.

• People without a Persistent Storage cannot store their language and keyboard settings or have them automatically configured without unlocking it.

• Saving these settings is conditioned by having a Persistent Storage. It makes first use either more complex to understand (by mentioning a Persistent Storage that doesn't exist yet) or different than when a Persistent Storage is available.

Always ask the user to choose

...whether they want to store their language and keyboard layout (and accessibility options) encrypted in the Persistent Storage or unencrypted in the Tails system partition.

Here is the design that I tested for that:

1. A Save button below the language and keyboard layout options in the Welcome Screen:

2. A dialog that asks whether to save encrypted or unencrypted and explain the pros and cons of each option:

The explanation is needed for people to understand that they might not be able to type their passphrase with an English keyboard.

3. A drop down list that both displays the current state of encryption and allows changing it.

Displaying the state of encryption is important feedback on which option was chosen in the dialog. We could still display the "encrypted" state before unlocking the Persistent Storage by storing 1 bit of information about this in the Tails system partition.

4. An option in the Persistent Storage settings to change the encryption:

5. A dialog to warn about they keyboard layout when turning on encryption:

Pros:

• People get to weigh the pros and cons of each option.

• During my tests, P2 missed the switch on first use and found that a button was more visible. I then moved the label closer to the switch in the following option.

Cons:

• P1 chose "encrypted" because "of course I want to encrypt!" without realizing that he wouldn't be able to type his passphrase. Then I added the tips.

  Some people won't read them and won't be able to type their passphrase the next time, get confused, and probably regret their initial choice, and have to rollback.

• P2 was a bit overwhelmed by the choice that sounded more complicated and scary than it should be and chose "unencrypted" because he didn't feel that it was sensitive information.

• More complex interface to code and interact with.

Don't encrypt by default

...and offer a feature of the Persistent Storage to encrypt.

Here is the design that I tested for that:

1. A Save switch below the language and keyboard layout options in the Welcome Screen:

2. A dialog that explains the unencrypted default and the encryption option:

3. The same option in the Persistent Storage settings to change the encryption.

4. The same dialog to warn about the keyboard layout when turning on encryption:

Pros:

• Simpler and less overwhelming for first time users.

• P5 found that having a switch was less ambiguous than having a button because a button could imply taking you somewhere else in the interface, like the Continue button in the title.

  Buttons in the titlebar is very GNOME-ish and otherwise unusual and I expect more people to click a Save button instead of Continue.

• P6 preferred the simplicity of this option when comparing with the previous one.

Cons:

• Encryption is relayed as a second class option that people might or might not remember to turn on afterwards.

Never encrypt

I think that this was the original intent when we created this issue 7 years ago.

The design could be limited to:

1. The same Save switch.

2. A modified version of the previous dialog:

Implementation

• Reorder the sections: Persistent Storage first, then Language & Region