Element-web: Current UX design makes it highly probable that users will lose their recovery key (and thus their data).

[tim-seoss]

Description

The current Element UI/UX makes it highly probable that Matrix/Element users will lose/forget their E2E key backup ("recovery") passphrase, resulting in permanent loss of data, and an extremely poor UX.

The root causes of the problem are:

• The human brain is less likely to remember items of information which it has categorised as "unimportant" and/or "low impact".
• The human brain is less likely to remember items of information which are seldom recalled/used.

The Element UI needs to take significant steps to overcome these psychological features, to stop user data loss (and reputational damage to Element/Matrix).

Steps to reproduce

• The user inadvertently loses access to their Matrix client session.
• They attempt to fix this problem, and discover that they don't know their recovery passphrase (typically they don't even know that they have one and/or assume this is just their chosen Matrix password).
• The user discovers that the coincidence of these two events has resulted in permanent (and perhaps personally significant) data loss.

This has happened to multiple users that I have assisted, and has resulted in all such users abandoning (and foreswearing) Matrix, so I think this is a _very_ significant UX bug.

Factors which make this a high probability event

Previous experience with other online services teaches users to expect that they they will always be able to reset a forgotten password e.g. by requesting a "forgotten password" link to be emailed to them.

• Since users expect the loss of a password to be recoverable (if very slightly inconvenient), little importance will be assigned to remembering (and/or taking steps to permanently and securely record) their recovery passphrase.
• Even for users who do understand the distinction between an encryption passphrase, and a resettable password, the passphrase is created early on in the user's experience of Matrix, and at a point in time when the loss of their Matrix key will have zero impact on them.

These two points combine to make the loss of the recovery passphrase commonplace, because the human brain is less likely to remember things which it has categorised as "unimportant" and/or "low risk".

Because this backup/recovery passphrase is not recoverable (by design, for security reasons), the loss of the passphrase, combined with the loss of the user's only Matrix client install (e.g. uninstallation, clearing browser stored data, corrupted storage due to filesystem full, loss or erasure of their device), results in irreversible/catastrophic loss of access to historic messages.

Potential fixes include:

• Check that the passphrase can be recalled before it is needed.
• Helping to aid user memory by implementing a process to strengthen/reinforce the users' memory of the passphrase (reducing probability that it can be recalled when it is needed).
• Discover passphrase loss as early as possible to eliminate (or at least minimise) any resultant damage.

The "Signal" messenger implements the same double-ratchet E2E encryption scheme as Matrix (Olm), and has faced the same problems. The adopted solution is roughly:

• Some time period after first setting the recovery passphrase (e.g. 5 minutes), the user gets a prompt checking that they know the passphrase, and reinforcing that this is a potentially serious issue if they don't.

• If they fail to remember it, they have an opportunity to create a new backup (with a new passphrase) - presumably this is also possible at this stage, since any E2E message keys are still resident in the Matrix client.

• The reminder is repeated (at exponentially increasing intervals until an upper ceiling is reached, e.g. once per month) for active users

• After n successful attempts, the user is given the option to skip/postpone an individual verification check

• The messages should be polite, simply worded, and crafted to emphasise the potential permanent loss of their data, to make the prompt less likely to be ignored (failing this, the user is less likely to blame Element / Matrix if they do suffer subsequent data loss).

• The verification process should include an easily followed recovery process (e.g. creating a fresh backup and/or archiving the old backup in case the user later finds/recalls the lost passphrase).

[jryans]

Thanks for this thorough feedback. I'll circulate this with the Design team for review.

[tim-seoss]

13386 also forms a small subset of this issue I think.

[tim-seoss]

There may also be mileage in only performing the initial set up of the encryption related key backup etc. after the first time that the user exchanges an encrypted message with another user. This would have the advantages of:

• Creating the passphrase as a distinct operation from the initial sign-up etc. (to both reduce cognitive overload, and also make this a distinct "event" in the mind of the user).
• Showing that this is important, i.e. they have something tangible to lose if this passphrase is subsequently lost - "you will no longer be able to view these messages if...".

[jryans]

There may also be mileage in only performing the initial set up of the encryption related key backup etc. _after_ the first time that the user exchanges an encrypted message with another user.

On this point, fully agreed, and we have recently made this change as part of Element 1.7.8 released on 28 Sep.