Mandatory session verification

[libreom]

Why you broke users workflow? I don't want total verify session. Add a no/close button. You broke existing login with update and new login after clearing data. Fix it. It's broken

[bmarty]

I asked the product team to give some feedback about it.

[eikehein]

I'd like to second this. I don't want to verify the session on the device I carry, because I don't trust it. But now I can't use Element X for non-encrypted messaging anymore. This has forced me to install a different client.

[claell]

Currently, seems to be wanted (see #2594), but I also think that making this mandatory is a bit of a bad design decision for several reasons.

[pmaier1]

Thanks for your feedback! I can understand the complaints and I'm grateful that you're voicing them. Let me try to give a bit of rationale and background why we think that this is the right thing to do.

First of all, we want Element X's value proposition to be a secure messenger application. That is why we are fully focused on end-to-end-encrypted communication and are willing to accept trade-offs that adversely impact non-encrypted communication. EX further has the clear goal to be a Matrix client that is actually usable by everybody. That comprises simplicity and security by default. We therefore follow the principle of 'convention over configuration' and take users by the hand such that they don't have to understand the technical primitives in order to properly and securely use the app. In this sense we try to avoid loopholes (e.g., ability to skip device verification).

Second, it is a good thing to have your devices verified. It is even required to make use of features like message history in encrypted rooms. That is another reason to guide users to do it. Specifically, device verification gives you a couple of things:

• Access to your message history in encrypted rooms (access to your crypto keys, including the key to key backup which you need to decrypt your message history)
• Another layer of security for access to your sensitive data. If someone steals your login credentials, they also need to verify the device to get access to your message history and your crypto identity. This can also prevent attackers (together with other functionality) from impersonating you.

Third, this is in line with future concepts and paradigms on trust in Element apps. We are working to introduce new functionality around trust and related decorations in EX and EW. Especially we're automating trust between users (identity pinning / TOFU) to not require manual verification and still be able to notice when other users' 'identities' change. As part of this concept we're also isolating unverified devices such that you cannot communicate on these devices until they're verified (other devices won't send encryption keys to unverified devices and won't accept encryption keys sent by them). The reason behind all this is that we eventually consider unverified devices as insecure and not trustworthy. Mandatory device verification obviously is a prerequisite for this.

I understand that this goes at the expense of simple, unencrypted messaging use cases in our apps but I hope that the reasoning above does resonate. I can further understand that the introduction of mandatory session verification might have been a bit bumpy in some scenarios due to asking for verification directly after the update and blocking the app thereby. At some point it was necessary to conduct the change, though, and we decided to do it rather sooner than later. It's a one-off hurdle that you'll not encounter again if you don't sign-out your device.

The good news is that usability improvements like QR code login are just around the corner. When you sign in a new device using that feature, you don't need to worry about verification as it's just happening in the background, automatically done for you. Furthermore, if you can't verify a device for whatever reason, the key reset option will soon be available in EX as well.

[kongo09]

@nadonomy I think what can help here is to take another look at the design and especially the copy of the page to take the user more by the hand.

[claell]

@kongo09, looks like your comment is in the wrong issue.

[claell]

@pmaier1 I understand the rationale. The only problem I see with it is the use case that @eikehein describes: Not trusting a device to be secure.

Then, all the benefits of verification that you mention are no longer that valid, and instead can turn into the opposite.

Personally, I don't have that use case, but I can see that just "blindly" verifying every device can lead to a lot of more attack vectors, especially, if some devices are not secure for other reasons. But maybe that is a worthy trade-off to take.

[spaetz]

@pmaier1 I understand the rationale. The only problem I see with it is the use case that @eikehein describes: Not trusting a device to be secure.

Sorry, but if you are not trusting a device to be secure you should never enter your matrix login credentials in it, nor the recovery key, which is needed to read/write e2e encrypted messages.

[BrenBarn]

First of all, we want Element X's value proposition to be a secure messenger application. That is why we are fully focused on end-to-end-encrypted communication and are willing to accept trade-offs that adversely impact non-encrypted communication. EX further has the clear goal to be a Matrix client that is actually usable by everybody. That comprises simplicity and security by default. We therefore follow the principle of 'convention over configuration' and take users by the hand such that they don't have to understand the technical primitives in order to properly and securely use the app. In this sense we try to avoid loopholes (e.g., ability to skip device verification).

I would like to know a bit more about the process and priorities here though. Is there an issue where the goals and priorities on this are laid out.

You have listed two goals:

1. focus on e2ee and accept tradeoffs that adversely impact non-encrypted communication
2. be a Matrix client that is usable by everybody

Is there discussion on an issue or anywhere else where you explain how to reconcile those goals? Because I think the current landscape of messaging apps shows that those goals are at least to some extent at odds. They're not in direct opposition, but it's going to be a very narrow path forward to meet both those goals.

The reason is that "everybody" does not care about encryption. That's why they use Discord and various other apps that don't provide encryption, or whose encryption is unverifiable or otherwise suspect. For the great majority of users in most of their use cases, it is more important that the intended recipient is able to see the message than that other people are not able to see it. Thus the "tradeoffs" that you mention are highly asymmetrical for the average user: they will not see much benefit to the improved encryped messaging, but will be highly sensitive to any loss of functionality relative to alternative messaging apps (that don't prioritize encryption so highly).

As I see it, the way to succeed with an app whose value proposition is to be a secure messager is as follows:

1. Get secure messaging fully working
2. Release the app

What I consistently see from the Element team (both with old Element and EX) is the reverse:

1. Release a series of partial implementations with bugs, inconsistencies, confusing UI, etc.
2. Try to tell people you have a secure messaging app.

That will not convince people that you have a secure messaging app. My view is that security as a feature should not even be publicly mentioned as a selling point until the entire app has been in a stable, smooth state with security and everything else working for a considerable length of time (i.e., measured in months at least).

Part of security is trusting the app and the company that makes the app, and people won't trust an app that constantly shifts around and breaks their expectations, let alone an app that locks them out of their messages.

Second, it is a good thing to have your devices verified. It is even required to make use of features like message history in encrypted rooms. That is another reason to guide users to do it.

I'm basically in agreement with this, but there are many subsidiary questions without which the value of this position on its own is unclear. For instance:

1. How is the device verified?
2. What happens if it is not verified?
3. How reliable/smooth is the verification process?

If the verification process is not easy and as smooth as butter, forcing users to verify is worse than not doing so. So, again, the point is that it's good to require verification after you have everything else fully in place.

• Another layer of security for access to your sensitive data. If someone steals your login credentials, they also need to verify the device to get access to your message history and your crypto identity. This can also prevent attackers (together with other functionality) from impersonating you.

Again, if the goal is for "everybody" to use the app, the value proposition of this is questionable. Most users are not worried about "attackers". The added pain of not being able to log in when you want to and see all of your messages greatly outweighs the perceived gain of some hypothetical attacker seeing your happy-birthday message to grandma.

Third, this is in line with future concepts and paradigms on trust in Element apps. We are working to introduce new functionality around trust and related decorations in EX and EW. Especially we're automating trust between users (identity pinning / TOFU) to not require manual verification and still be able to notice when other users' 'identities' change. As part of this concept we're also isolating unverified devices such that you cannot communicate on these devices until they're verified (other devices won't send encryption keys to unverified devices and won't accept encryption keys sent by them). The reason behind all this is that we eventually consider unverified devices as insecure and not trustworthy. Mandatory device verification obviously is a prerequisite for this.

This again sounds like putting the cart before the horse. It is great to "work to introduce" new functionality to make encryption better. After that new functionality is fully working is the time to roll it out in a publicly released app.

I understand that this goes at the expense of simple, unencrypted messaging use cases in our apps but I hope that the reasoning above does resonate. I can further understand that the introduction of mandatory session verification might have been a bit bumpy in some scenarios due to asking for verification directly after the update and blocking the app thereby. At some point it was necessary to conduct the change, though, and we decided to do it rather sooner than later. It's a one-off hurdle that you'll not encounter again if you don't sign-out your device.

Again, I question the idea of "sooner rather than later". The time to do this is after the entire encryption UX is fully working.

The good news is that usability improvements like QR code login are just around the corner. When you sign in a new device using that feature, you don't need to worry about verification as it's just happening in the background, automatically done for you.

How do you do that when you don't have any of your other devices ready at hand (and they may, for instance, be turned off)?

[rltas]

a) I'd like to have a choice other than not using Element X. Hide it behind a big fat warning if you want, but don't patronize me.
b) many, if not most rooms on on matrix.org are unencrypted for a reason.

[juantxorena]

I just want to add that this change has made this app completely useless for me. I rarely use matrix, only when some app requires it, so I usually don't have it installed. Today I needed to use it, so I downloaded this from the f-droid repo. I tried to login, and I got this this verification thing, either with a code that I don't have, or with another device that I don't have neither. So the result is that I cannot use this app. I fixed it by uninstalling and installing a different matrix client.

You can justify however you want this change, bottom line is, I cannot login, and I doubt I'm the only one, so element is effectively useless.

[ara4n]

@juantxorena the app should have prompted you to reset your encryption (using Element Web, as it's not implemented on Element X Android yet) if you've lost your recovery code and don't have another login. Did it not?

[juantxorena]

@ara4n I only used element for android. I didn't know that it existed for the web. I never have had a recovery code as far as I know. I only commented here to inform the developers that this change has made this app completely useless for me, and probably for a number of potential users like me, that need a matrix client for reporting a bug or something in some other app, but aren't necessarily interested in matrix as a protocol.

This app seems to be the recommended Matrix client in android. I'm talking about my experience as a very casual user of matrix, and I think that you are talking as and advanced user full into the matrix ecosystem, hence the problem. This bug, unless it's fixed, will drive away casual users of the app.

As I said before, I already found another Matrix client that I can use as a casual user.