Can we use "io.element.e2ee" to configure tchap-web to use secure backup ?

[estellecomment]

https://github.com/vector-im/element-web/blob/develop/docs/e2ee.md#requiring-secure-backup "Si je comprends bien, c'est des options que le serveur peut retourner dans le well-known, qui fait que element-web va demander aux users d'utiliser le secure backup. (je sais pas encore l'UX de ce truc, je vais regarder) On peut aussi indiquer qu'on utilse key et pas passphrase."

This could remove some custom code by reusing config options given by element-web. What's the UX for this ? Is it acceptable ?

Note : If the backend can't return it, we could patch to fake-return it, and trigger the UX.

[estellecomment]

TLDR : secure_backup_required directly displays the dialog for setting up secure storage, instead of showing the toast (the smaller less intrusive dialog in the upper left corner)

When you have "secure_backup_required": true in the well-known, if the user already has secure storage nothing happens. If the user does not have secure storage yet :

• if user already exists, what happens ? At the next login (or the next page reload if already logged in), the Dialogs for creating the secure storage appear.

• when creating a user, at first connection what happens ? When user creates their first encrypted message, the dialogs for setting up the secure storage appear. (without secure_backup_required, it's just the small dialog in upper left corner which asks if you want to start the setup, so less constraining)

Once the dialog for secure storage setup has appeared :

• In Tchap, "Annuler" will get you out of it, and secure storage is not set up. You have escaped secure storage!
• In Element, there is no way to get out of it, even reloading the page. You can't even log out any more. It's secure storage or nothing.

[estellecomment]

I think that Tchap has made "escape from secure storage flow" possible because we want to avoid have secure storage but user ignored the key and didn't store it (it's not a solution to locked messages if you don't have your key)

I'm not sure that using bigger dialogs will help. People will close them without reading them, or not store the key. So I think this feature is not useful.

[estellecomment]

Second question : without changing the current UX, can we use this feature to simplify our patch code ?

[estellecomment]

No, it changes which dialogs are triggered, but not the content of the dialogs.

[odelcroi]

thanks for the investigation, can this issue be closed then?

[estellecomment]

I have a doubt : when is the toast displayed ? I thought it was at each page reload but it's not. Find out.

[estellecomment]

"Enable secure storage" toast displays

• when the initial sync finished (when you reload page for example)
• when you do anything important with encryption (start your first encrypted room, verify your device, setup xsss or secure storage, that kind of thing).

However sometimes another dialog shows up instead, asking to "Verify this session". (In more detail : VERIFY_THIS_SESSION in SetupEncryptionToast. if (!(await crypto.getCrossSigningKeyId()) && (await crypto.userHasCrossSigningKeys())) // Cross-signing on account but this device doesn't trust the master key (verify this session)) I think this happens because I refused Secure Storage previously, in different ways.

This can happen when you have a single session, so that you can't verify with other devices, and it sends you to setup secure storage. That's probably a bug for element : it should be "Setup Secure Storage" toast, not "Verify this session" toast.

@odelcroi would it make sense to send people to setup secure storage in all cases, and never make them verify through other devices ? (I think we're going in that direction on mobile ?)