E2E device/key management dashboard to replace UnknownDeviceDialog

[richvdh]

We are considering making a single crypto management dashboard, which would include:

• A list of the devices for each user in the current room, showing their verification/blocked status and whether they are 'known', with knobs to twiddle those flags.
  • We especially need to loudly highlight blocked devices - whether they are explicitly blocked or blocked because we autoblock untrusted devices. This is critical for helping users debug self-imposed UISIs.
• A separate section highlighting the 'unknown' devices? or just a way to filter the huge list of devices? And a way to mark them all as 'known' in a single click.
• A list of received keyshare requests (which would mean tracking them rather better than we do today.)
• A button for turning on crypto for the room if it's not already enabled (so that people can hit the padlock icon next to the composer and promptly encrypt the room.....)

You would open the dashboard by clicking on the padlock. [Not sure that this is very discoverable: we should probably put it elsewhere too?] [Absolutely. Room Settings? And linked from the dialog you get when you click on a per-msg padlock? --M]

We would then remove the Unknown Device Dialog, instead just showing the "couldn't send because unknown devices" error, and include a "click here to open dashboard" link. Ideally we would also show a "there are new devices in this room!" warning somewhere in the Room so that you can manage the list proactively.

Surely this can be the same StatusBar warning - the behaviour is just like losing connectivity. The second the untrusted devices appear, the warning appears in the StatusBar telling you messages will be queued until you verify them. If it's a single new unknown device, it'd be cute if the StatusBar warning just linked you straight to the verify dialog for that device though rather than forcing you unnecessarily through the dash -> this is now #5534

We might also replace the 'you got a keyshare request' dialog with a banner at the top of the app (where the 'new version of riot' banner goes) with 'You got a keyshare request! Click here to manage!' or 'A device has requested access to decrypt conversation history in the #foo:matrix.org room. Click here to manage!' -> this is now #5533

https://github.com/vector-im/riot-web/issues/4157 and https://github.com/vector-im/riot-web/issues/3857 have now been replaced by this one.

[lampholder]

Have we drawn any wireframes for how this would look? I would be happy to help with that - perhaps next Wednesday we can sketch some stuff on a whiteboard? Or do we need to move more quickly?

I've P2'ed this because I don't have much perspective on the E2E roadmap - please P1 if this is the next thing we're looking at :)

[ara4n]

P1'd 'cos it's the next thing we're looking at, and it's our biggest blocker on this stuff being usable in anger :)

[richvdh]

FTR it's just behind #2325 on my roadmap

[AmandineLP]

I won't be around for the sketching session, so here are some inputs. I also briefed Matthew:

Dashboard UI

• I’m relatively open although please can we try to have something not too crowded and have subsections rather than a list of thousands lines
• The main problem will be to manage the enormous amount of noise brought by the browser sessions. I don’t think we have a way to avoid every new session being a new device right? So we have to extract the useful info out of it:
• i.e. potentially have something like:
  • Group by users => x devices; y new devices; [show new devices] [show all devices]
  • Then group by device type: smartphone, tablet, browser, desktop.. the idea being that if a new “real” device (a smartphone or a tablet) it really jumps out. Then potentially order the browsers by type? I like the piwik UI with small logos for that:

Makes it easy to see any anomaly (ie wrong OS, wrong browser…)

• Then +1 on Rich suggestion on how to display and allow to tune the different status; and +1 on the verify all button
• Question: will this replace the list of devices in the member info panel? Or at least can we take the opportunity to fix it there too (eg just have a button which for example opens the same dashboard ui but for the selected user only.

New devices warning/verification management:

• Today’s behavior is too intrusive and too complicated for whatsapp users. But we have to maintain a level of warning for tinfoil hat people.
• My suggestion is to make the block on unverified devices optional: users see it the first time the case arises in a room but have the option to opt-out (it’s a per room config, might be already too much for WA users tbh). This would look like:
  • the first time people posts in a room and there is new devices, a message pops up saying:

There are new devices in this room. It might be your contacts opening up a new browser window or someone stealing their account. You can disable this warning in this room, decide to send your message anyway (without verifying the devices) or verify all the new devices.

[ ] Don’t show this msg again for this room (you can see all devices by clicking on padlock, your sending won’t be blocked on new devices but you will be warned)

[send anyway] [verify the new devices (which opens the dashboard UI showing non verified devices only)]

• if the user checks the box, when they come in the room next time they will see a warning in the StatusBar anyway when new devices are added (‘heads up, new devices. You can verify them here but your msg won’t be blocked’). The warning disappears after the 1st msg they send, which is considered as an acknowledgement of the new devices (i.e. same as clicking on ‘send anyway’)

Keyshare requests

• Give the option to accept them all by default, or in a given room only

Other notes:

• Need an overlay text when hovering over the padlocks/warning triangles of a message to say what they mean

[uhoreg]

I ran into an interesting situation today that I hope will be addressed by the new redesign somehow. I opened up a new device that hadn't been active for a while, while another device was active. Device A requested keys from device B, and device B requested keys from device A, which resulted in both devices asking me to verify the keys of the other device, but then with the "Verify device" dialog open on both devices, I can't open the user settings on either device to find out what my key actually is. (Of course, this could be solved by using a verification mechanism that doesn't require the users to actually view the keys.)

[richvdh]

no longer p1, unfortunately

[ara4n]

IT'S BACK AT P1 BABY!!!

[t3chguy]

The dialog this wishes to replace is long dead