MSC4161: Crypto terminology for non-technical users

[andybalaam]

Rendered

Conflict of Interest declaration: I am employed by Element. This MSC was written as part of my work on the Element Cryptography team.

[greentore]

I really don't like calling sessions devices. It may work well for other, mobile first networks, but with matrix it's not all that uncommon to run multiple sessions on the same device.

[uhoreg]

The problem is that "sessions" is used to refer to other things in the spec. So it would be more confusing to call something else "sessions".

[MTRNord]

How about explicitly naming them "Crypto-Sessions" or something in this direction? I agree with the initial mention about devices. This is already these days due to some UIs a bit confusing.

[andybalaam]

My personal take is that most people are familiar with "devices", and non-technical users will probably only have one crypto session per device. Further, where people do have multiple sessions on a device I think is it relatively easy to explain that they look like multiple devices to Matrix even though they exist on the same physical device.

In contrast, when I started using Matrix I had no idea what a "session" was, and as I learned more I became further confused because the word is used for several other concepts, including e.g message keys.

So I plan to propose this as-is.

[TheArcaneBrony]

as much as i hate the "devices" terminology, this is also how it's named over on eg. Discord.

[pmaier1]

as much as i hate the "devices" terminology, this is also how it's named over on eg. Discord.

or Whatsapp or Signal or other platforms. Which is why we suggest it in the first place.

Has user research shown that devices are preferred over sessions? Does Element have some data on their existing transition from devices to sessions?

Not sure whether we have something dedicated to exactly this comparison. @americanrefugee might know more.

[afranke]

Gmail uses “session”. I’m sure others do too. I don’t think it’s such a foreign term for laypeople, or that it can’t be understood by them.

Whatsapp and Signal are more or less tied to phones and don’t expect any other client than “the one app” you have on said phones. In their context, device works. Comparing to them doesn’t work.

[afranke]

The problem is that "sessions" is used to refer to other things in the spec. So it would be more confusing to call something else "sessions".

This MSC is about terms to use for non-technical users as far as I can see. I reckon it is not a problem to use a word for something in a given context, and a different word for the same thing in another context. The spec can call these crypto-sessions as was suggested above, or even devices if further disambiguation is deemed necessary. In a technical context, it can be clear that a “device” is not a piece of equipment, whereas it is really not clear for non-technical users.

Without even thinking about multiple distinct clients on the same device, a single client can become a new session if access to the previous session is lost for some reason. And so now you have two “devices” listed even though you used a single computer and a single client.

[andybalaam]

Element's product people favour "devices", as do Discord, Signal and WhatsApp. We have a counter-example in Google, but I personally find much of Google's UI quite confusing, especially gmail.

As for having two devices listed even though you only used one: the proposed wording seems helpful to me - the mismatch between the wording and reality indicates a problem: they should remove the old device.

Perhaps the product designers from other products could chip in, but at the moment the scale seems to be tipping towards "devices".

[afranke]

as do Discord, Signal and WhatsApp

Again: you are comparing apples to oranges. Signal and WhatsApp have a very different relationship to clients and devices.

[Saiv46]

This should be given more priority. User-friendliness of clients is a must

[turt2live]

This MSC is something I think would be extremely helpful in the spec. It's important to me that users get a relatively consistent experience regardless of the client they choose to use, but still allowing those clients to express their unique features/competitive advantage to users. Clients should also have capacity to participate in different markets outside of chat.

The MSC also appears very nearly ready for FCP, with only a few blocking comments from my side:

• The MSC could do with a bit stronger rationale for why this is important.
• The MSC appears to have a heavy focus on Element clients, which is natural given the authors.
• To help with the "why" of the MSC, "implementation" in the form of user research would help. Ideally from a broad spectrum of users and clients, demonstrating the terms chosen carry well between different markets, audiences, brands, etc.

[turt2live]

it's unclear if this is part of the proposal, or accepting fate. If it's part of the proposal, I suggest moving it down to the normative sections (under "Proposal").

[andybalaam]

I wrote some words in 56b5daf - let me know what you think.

[turt2live]

Has user research shown that devices are preferred over sessions? Does Element have some data on their existing transition from devices to sessions?

(comment from a product/design-orientated person would be appreciated)

[turt2live]

this appears to extend beyond definition and into specification. Is there existing spec which describes the 'error state'? Should we explore the concepts of error and security through another MSC?

[turt2live]

Implementation requirements (in my opinion):

• User research to show these terms as helpful and easily understood.

The research may be done through studies or deployment to a portion of the user base with analytics to show "easier" use of the app.

[turt2live]

The MSC should address why it's important that all clients use the same language, and why the language of the MSC is generic enough to fit the language and feel of all client applications. An app which has a less professional feel may prefer to use different terms for brand identity/recognition, for example. This MSC feels a bit too prescriptive for all audiences.

A common language feels important to me, regardless of audience impact, but the MSC does not really tell me why I should feel that way.

[turt2live]

Overall review: The MSC appears to describe features and requirements of Element, and assumes that all clients in the ecosystem have similar or comparable features/needs. The assumptions read fine when applying this MSC to an Element client, but when comparing to the spec there feels like there's a gap in understanding.

Significant review from other client authors/developers, and their respective product/design teams, I think would be extremely valuable to help ensure this MSC does not solely apply to Element. This kind of review may need to be chased down as it's somewhat uncommon for a product-y MSC to be in the spec process.

[dkasak]

I would call this "Secret storage".

The mechanism in question can store arbitrary data, not all of which are keys. The next paragraph already has to perform significant linguistic gymnastics in order to explain that the user's identity is also stored in the key storage, even though it is called an identity, not a key. (The fact that it is a key is an unimportant technical detail from a user perspective and is very jargony.)

On the other hand, explaining that a key is a certain type of secret should be very natural.

[pmaier1]

I would call this "Secret storage".

We discussed this. The challenge we see is that it could be mixed up. It could either mean

1. a storage for secrets
2. a storage that is secret

That's why we discarded it and propose "Key storage". For a user it is irrelevant if something is a secret or a key or a token or a hash or whatnot, technically speaking. From a users point of view it should be a safe place that holds keys to open up stuff on new devices or in case of an emergency.

[dkasak]

Also, the problem will be further exacerbated if/when new non-key things start getting stored in secret storage.

[Xiretza]

We discussed this. The challenge we see is that it could be mixed up. It could either mean

1. a storage for secrets

2. a storage that is secret

Wouldn't "Secrets storage" fix that problem?

[andybalaam]

"Secrets storage" is feels unnatural to say in English. The justification for "key storage" is that the most important things (from a non-technical user's point of view) that are stored in this storage are message keys.

The fact that other things also get stored there doesn't need to prevent us naming it after the most important thing. For example, if I have a school locker for P.E. kit that I commonly call a "kit locker" I think it would be perfectly natural for me to say "I keep my Sony Walkman and Rubik's cube in my kit locker"...

[Xiretza]

The fact that other things also get stored there doesn't need to prevent us naming it after the most important thing

It doesn't need to, but I think it should, considering that the whole point of this exercise is to make the language used less confusing.

[andybalaam]

I want to split this into 2 separate concepts: I thought we could run storage of message keys together with storage of identity keys etc (recovery) but recently I realised they a really separate, so we probably need something like this:

• Room key storage - store room message keys on the server, protected by a room message key storage key. This room message key storage key can be passed around between devices even if you don't have recovery storage.
• Recovery storage - store identity keys and the room message key storage key on the server, protected by a recovery code. This allows us to recover both our identity and our room message key storage key even if we lose all our devices.

[richvdh]

It's worth noting that the EX designs (https://www.figma.com/design/qTWRfItpO3RdCjnTKPu4mL/Settings?node-id=1653-29941&node-type=frame&t=LeUe8iJVmzG8srM5-0 etc) refer to "key storage" to cover both of these concepts. I think that's ok; we just need to be clear that "key storage" is used for both room keys and recovery, and that they are set up separately.

[richvdh]

Room key storage - store room keys on the server, protected by a room key storage key.

NB they are message keys, not room keys.

[pmaier1]

IMO it would be great if we could abstract the details to the user. It should just be one feature from a user POV. Either you want the server to store some information for you and get benefits from it or you don't. I don't see a reason why the user should need to understand the exact concepts behind it.

[richvdh]

Well, it would be quite a change from the way the apps currently work. Currently EX sets up key backup on registration, but doesn't set up recovery until you actively go through the steps (and EW is even more flexible). That's also why the designs above have separate entries for "Allow key storage" and "set up recovery".

Possibly we could change that, and force the user to set up recovery during the registration/login flow; but it would go against the desire to get people using the app quickly. (Also, this MSC is intended to cover matrix clients in general: even if the Element clients force you to set up recovery at the same time as key backup, other clients may not, and having the terminology available to refer to that situation is important.)

[tulir]

For the record, Beeper settled on "recovery code" after considering other options including "recovery key", but I don't remember the exact reasoning since the switch was made 2 years ago

[tulir]

Asked for the reasoning internally:

Code sounded more friendly than key (in an unscientific review).
e.g. people know what a pin code is. Code is a numerical thing but a 'key' to most people is a physical object