Skip to content

Encryption

Cassidy James Blaede edited this page Aug 11, 2021 · 8 revisions

Originally, we had a number of goals with the encryption views:

  1. Strongly push encryption by default. Better securing user data is worth it.
  2. Allow users to opt out of encryption if they have a good reason.
  3. Clearly and honestly explain the implications, whether or not the user might fully understand disk encryption.
  4. Encourage the user to provide a strong password while understanding when and how they will need to use it.

However, users keep hitting negative experiences with encryption:

  1. No localization
  2. No support for Bluetooth keyboards
  3. No support for touch input
  4. No synchronization with the user password
  5. Grub shows on every boot

These were pervasive enough that we've decided to make it opt-in rather than the default. This is in line with what other major desktop OSes do, while still being a better experience to enable it.

To enable encryption while still explaining the implications and providing guidance for passwords, we split encryption into two steps:

Disk Encryption screenshot

Since this is non-destructive at this point (users can go back until they choose their disk and start the installation), we don't need to totally protect them from clicking through to the next screen. We tell the user:

  • Encrypting this disk protects data from being read by others with physical access to this device.
  • Disk encryption may minimally impact read and write speed when performing intense tasks.
  • The encryption password will be required each time you turn on this device or restart.

We carefully considered this ordering; we start with the most important and positive aspect, inform them about the potential performance impact, then detail when a password will be required.

The last point leads nicely into the next step if they choose to encrypt. The right half of the view switches to expose password instructions and entries:

Encryption Password screenshot

Choosing a password acts as a sort of roadblock requiring user interaction, since they need to understand the implications of this password. They can still go back and opt out of encryption. We also present tips from libpwquality, to encourage a strong password, but don't prevent the user from using what appears to be a weak password because we don't know the full context of their choice.