End-to-end encryption UI/UX

[giomfo]

This is a high level bug to track all the design & UI implementation dependencies for E2E crypto, to compliment the list of individual issues we've had historically. It's also written to reflect the guide I gave at the Ribot offices this morning. Top priority first:

• Show whether room is either:

  • unencrypted (same as current UI - perhaps an grey opened padlock shown in the RoomHeader?)
  • encrypted and trusted: i.e. all devices present are verified - perhaps a green closed padlock shown in the RoomHeader?
  • encrypted and untrusted: i.e. some devices present are not verified - perhaps a yellow /!\ shown in the RoomHeader
  • End-to-end encryption: show whether encrypted room and room members are trusted or not element-web#1783 & End-end encryption: room state / room level privacy indication element-web#1781

  Untrusted messages / users / rooms are not necessarily the end of the world, so should not be a huge red flashing warning, but an advisory warning (hence the /!\ suggestion) that users could choose to ignore if they don't care about verifying who they're talking to.

• Show whether received messages in an encrypted room are, per message:

  • trusted messages could have a green padlock or something in the left margin on hoverover.
  • untrusted messages could have a yellow /!\ or something in the left margin all the time.
  • unencrypted messages could have an unlocked padlock or something shown all the time in left margin.
  • blocked messages (i.e. sender blocked you from receiving them) could have a red /x\ or something in the left margin.
  • End-to-end encryption: room messages (receiving) element-web#1785

• Toggle encryption for a room on (and off, in future)

  • Could be a toggle in RoomSettings, or perhaps the padlock icon in the RoomHeader proposed below.
  • End-to-end encryption: toggle encryption per room element-web#1782

• Show whether users in an encrypted room's membership list are:

  • trusted: i.e. all the devices for that user have been verified (green padlock on the avatar?)
  • untrusted: i.e. some of the devices for this user are unverified or blocked (yellow /!\ on the avatar?)
  • blocked: i.e. all of the devices for this user have been blocked (red /x\ on the avatar)
  • End-to-end encryption: show whether encrypted room and room members are trusted or not element-web#1783

• Show and manage list of devices for a given user. For each device for a user in the MemberInfo contents of RightPanel we need to show:

  • The device's name (e.g. "https://vector.im on Chrome OSX")
  • How trusted the device is:
    • verified: i.e. we have explicitly verified this device belongs to the human we think it should: green padlock?
  • unverified: i.e. we have not verified this device yet: yellow /!? padlock with a question mark? yellow /??
  • blocked: i.e. we have explicitly blocked this device from receiving our messages as we do not trust it: red /x\ ?
  • A UI control for explicitly marking the device as verified, unverified, blocked, or unblocked.
  • End-to-end encryption: room member devices element-web#1784

• UI for sending messages in an encrypted room

  • If someone adds an unverified device to a room, or changes the encryption settings of the room, we should block the UI with a modal dialog when the user hits 'send' on a message to warn the user and force them to review the settings/devices before hitting send again.
  • The warning modal only triggers the first time we send a message after unverified devices are added to a room (including first use), to avoid being too nagging.
  • End-to-end encryption: room messages (sending) element-web#1786

• UI for verifying someone else's device. When the user asks to verify someone's device (e.g. using the UI control mentioned on the previous line), we need to show some UI that guides the user through proving that the device is owned by that user.

  • As a first cut, this could just be a modal dialog that displays the hexadecimal fingerprint of the device (e.g. 4EB9 F820 5F2A 19E2) and prompts the user to compare this fingerprint with the other user "out-of-band" (e.g. over a phone call) to verify they match.
  • As a later cut (requires more backend work), we could show a modal dialog that prompts the user to enter a passphrase in order to verify the remote device. The passphrase (e.g. "horse pink plaster razor" would be told to the verifying user "out of band".
  • End-to-end encryption: device verification (for the verifier) element-web#1788

• Show UI for verifying your own device with someone else.

  • If someone asks you to verify your device (e.g. you get a phone call from them saying 'Hey, can you confirm that your device is really you?'), the user should go to MemberInfo for the user who is calling them, and hit a "Verify myself" button.
  • As a first cut, this would just show them a modal dialogbox with their hexadecimal fingerprint that they can then confirm with the other user.
  • As a second cut (requires the same backend work), we could show a passphrase (e.g. "horse pink plaster razor") that they can read out to the other user.
  • End-to-end encryption: device verification (for device being verified) element-web#1789

• Show and manage list of our own devices. For each of our devices, in UserSettings, we need to show:

  • The device unique ID (just to help the user disambiguate devices with the same name)
  • The device's name
  • Where/When that device was last seen (to help track whether your devices have been stolen, which ones are active, and to order the list)
  • The ability to delete a device.
  • End-to-end encryption: device name management element-web#1787

---

deprioritised:

• Differentiate between rooms with "burn after reading" crypto and "replay history" crypto
  • We currently implement two different crypto algorithms for rooms: "Olm" and "Megolm". Olm lets messages only be downloaded and decrypted once per device; Megolm lets messages be re-downloaded multiple times and generally behave like normal Matrix.
  • When configuring encryption, some option to select the "burn after reading" semantics for a room (and somehow represent that in the crypto settings on the UI) would be useful.
  • This is lowest priority.