Live data from Hacker News

Verifying your Matrix devices is becoming mandatory

element.io

101–110 of 251 posts

Re: Verifying your Matrix devices is becoming mandatory

#101
post #61

Earlier quoted context omitted.

Let's not forget the shock image spam issue. Public Matrix channels are plagued with horrendous shock images (including CSAM). The development team seems to not care, they have a proposal for "policy servers" which is still incomplete and not supported by all server implementations.

It’s terrible. I had to leave most channels on the matrix.org namespace because they won’t properly moderate their own server from CSAM. I dropped to 7 day media retention to lower legal liability on my own server, since there’s no way to know when one of my users will be in a channel hit with abuse. At this point the majority use case I have for matrix is to bridge to IRC with heisenbridge and be able to use signal…

Have they done anything to mitigate this? Like client side filters or message scanning for new direct messages?

Re: Verifying your Matrix devices is becoming mandatory

#102
post #70
post #52

Earlier quoted context omitted.

> Pretty quick and easy in most cases The experiences reported here seem to say otherwise... As others, anyhow, I haven't tried again recently > (Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.) I last tried Element about six months ago, bu…

I think current Element versions accept either a recovery key or recovery passphrase in the same input field, so there's no getting it wrong. Since you seem focused on UI, it's worth noting that Element X (their beta mobile app) has a greatly simplified interface; their team clearly has been working to make it easier. Also, other clients exist. For whatever it's worth, I've been using Matrix for about five years, inc…

> I can see slow and steady improvement.

That is true, but what weakens my confidence is that the Element/Matrix team often doesn't present it that way. So much communication from them is about how it's amazing and great and the best messaging app in the world. If they presented it more like a typical slow-growth open source app I think they'd garner more goodwill. By setting high expectations they increase the likelihood of disappointment.

Re: Verifying your Matrix devices is becoming mandatory

#103
There seems to be a lot of confusion regarding what verification is all about. I'm going to list out what it means, based on my reading of their documentation[1] and on what worked for me. It includes some essential preparations that you MUST TAKE if you have access to your account. This is to ensure that all your devices are verified, that they all have access to all encrypted messages and that you don't ever get fully locked out.

DISCLAIMER: I have no direct experience with Matrix or Element code base. I have no affiliation with them either. So this isn't official and a few errors can be expected. Please let me know if you notice any. I will keep this corrected for as long as I can. Otherwise I'll add the errata as child comments.

1. Matrix has TWO levels of authorized access.

2. The first level is where you enter your regular username and password, that's unique to your homeserver (like matrix.org). It looks like OIDC/OAuth2 to me. On being authenticated at this level, your client (Element, Fluffy, Cinny, etc) is able to access the messages meant for you. At this stage, you're able to read any unencrypted messages. Most community chatrooms are unencrypted by choice.

3. The encryption used for your encrypted messages is end-to-end. Their encryption keys are named 'room keys' in Element (there are several of them). They are not directly available to your homeserver (otherwise, it wouldn't be end-to-end). Similarly, there seems to be an 'Identity key' (presumably a cryptographic private key that makes you the owner of the account and is needed for some account operations). This key is also not directly available to the homeserver.

4. The client app just logged in and the server doesn't know your room keys or ID keys. They're known only to your other clients. So now you need to transfer them from those clients to the new client without divulging them to any servers in between. Once that's done, your new client will be able to decrypt all your encrypted messages and join those discussions.

This process of transferring your room keys and the ID key to your new client is the second authorization step known as 'Verification'. (I presume it's called verification because your new client can now prove its authenticity using your ID key.)

5. Verification can be done in three different ways. The first two are manual methods and are rarely used. We will discuss these two later. The other is using a 'verification request'. This is straightforward. Your new client requests the already verified clients attached to your account for your room and ID keys. Any verified client can respond. However, it needs to first verify that your new client is really yours, and not someone who used your leaked password or hacked your account. To do this, the clients currently offer you two methods - one using a QR code and the other using a sequence of icons.

If you select QR code, your verified client will show you a QR code that you need to scan with your new unverified client. Since it proves that both clients are in the possession of the same person, the verified client then proceeds to transfer the keys to the new client, finishing the verification. Now if you chose the Icon sequence instead, then the verified client creates a random sequence of icons that it sends to the new clients. Then both the clients display it to the user. If the user accepts on both device that the icon sequences are identical, it's the required proof that both clients are with same person. The rest of it is the same as before.

6. So far, so good. If you were able to complete till step 5, the new client is verified and now you can carry on with your business. Now we address the situation of what happens if you are not able to do any of these. Just assume that all your clients got logged out together for some reason (yes, it has happened before). Now none of your clients or the server has any of the room keys and the ID key needed to prove your ownership (crypto authn) or access your encrypted messages, even after you log back in. The only solution is to load the room keys and ID key from a backup. This is why it is IMPORTANT TO BACKUP your room and ID keys.

7. There are two ways to backup the room keys and the ID key. These two methods are also the two manual methods of verification that I mentioned above. The first method is to back up the keys on the homeserver itself. It's convenient because all your clients can access them at any time and keep the room keys updated as they change or new ones are added. This feature is called 'Key Storage' in Settings/Encryption tab of Element. It's enabled by default. ALWAYS keep it enabled.

You may be wondering how it can be end-to-end encryption if the private keys are stored on the homeserver itself. If you're, then you're correct. They are stored in encrypted form on the server key storage. The decryption keys for that is available only to the clients. So while the server holds the keys, it cannot access any of them.

8. Here is your first opportunity to do something about accidental losses. The decryption key for the key storage can be downloaded and preserved in a secure manner. Perhaps write it down on a paper or put it in the password manager. This key is called the 'Recovery key'. You can download or change it from Element's Settings/Encryption tab. ALWAYS BACKUP YOUR RECOVERY KEY.

You can use the recovery key instead of the QR code or the icon sequence to verify your new clients. There are two differences from the previous method. The first is that you can enter the recovery key directly into the new unverified client. The verified clients are not needed here. The second is that this is possible even if all your clients gets logged out. Again, this is why it's very important to BACKUP YOUR RECOVERY KEY!!

9. Besides setting up server key storage, you can take one additional step. This is the second manual method of verification. You can download and backup all the room keys and your ID key on your local system. This option is available as the 'Export keys' button on the Settings/Encryption tab. When you do so, you'll be asked for a password. This password is used to encrypt the file with all those keys, so that they don't sit unencrypted on your disk. This file can be backed up as such, but you can encrypt it again if you prefer.

You can use these keys also to verify your account. You'll need the above password to decrypt the keys file. However, this method still has one big CAVEAT. I suspect that the keys file need to be updated regularly, since there will be new keys when you join rooms. So if you use this method to validate, it's likely that your client won't be able to decrypt the rooms/messages for which it doesn't have the copy of their key. But this is still worth doing, because it contains your ID key which can be used to verify all your devices again as a last ditch measure (if your homeserver happens to quit or something).

10. Now let's just say that you're a careless ### who didn't do any of the above. You still have the option to nuke it! That is to Reset your cryptographic identity from Settings/Encryption. I presume that this just discards all your previous keys and creates a new private ID key. Since all the clients can now access this key, your account is verified again. But you will not be able to access any of your previous encrypted conversations. And the homeserver helps you along by discarding all your previous conversations, room subscriptions and settings. So now you're left with a cleanly empty account. But hey! You have your verified account back!

So, in summary:

1. Always verify all your clients

2. Setup server key storage (it is enabled by default, don't disable it) and backup the recovery key

3. Backup the room keys and ID keys on your local system. Use it for recovery/verification only in the worst case

4. Don't forget the password you used to encrypt the above file (just sayin)

NOTE: I intentionally left out some crypto details from the above (like session keys) to avoid making it any more complex. If you're unhappy with those omissions, please just leave a comment.

[1] https://element.io/en/help#encryption

Re: Verifying your Matrix devices is becoming mandatory

#104
post #72

"Now the end-to-end encryption will leak into the UX even more and you better like it" I'll say it again: E2EE will never become mainstream unless someone somehow manages to implement it such that it's completely transparent to the user while keeping all the features that people have come to expect from IM apps, like server-stored conversation history or support for multiple devices. By "completely transparent" I mea…

I mean we’re there for Signal. The parts that suck still are regarding access/retention of old messages which is an area Matrix is ironically slightly better about. But Signal we don’t need to think about verification, at worst it says this asshole has a new identity and then I have to tell them I’ve reset my iPhone for the 4th time this week… Normal users do find retention important even if privacy/security minded u…

Can you use Signal across multiple devices?

Re: Verifying your Matrix devices is becoming mandatory

#105
post #91
post #61

Earlier quoted context omitted.

Let's not forget the shock image spam issue. Public Matrix channels are plagued with horrendous shock images (including CSAM). The development team seems to not care, they have a proposal for "policy servers" which is still incomplete and not supported by all server implementations.

Let's not forget a team making a great free product. Yeah we can complain about filthy materials but imagine you working hard to build something as nice as Matrix/Element only for these low-lifes to do these horrible things to it. How annoying it must be to have to spend time battling such things.

If you make anything public, you will have to deal with it. You should be mentally prepared for that from the start.

Re: Verifying your Matrix devices is becoming mandatory

#106
post #72

"Now the end-to-end encryption will leak into the UX even more and you better like it" I'll say it again: E2EE will never become mainstream unless someone somehow manages to implement it such that it's completely transparent to the user while keeping all the features that people have come to expect from IM apps, like server-stored conversation history or support for multiple devices. By "completely transparent" I mea…

I more or less agree. And I also agree with the other commenter who says this may mean e2ee will never become mainstream. I think a lot of e2ee enthusiasts don't realize that the overwhelmingly most important feature for a messaging system is "when I log in, I can see all my messages". If there is a chance of that not happening, you're going to lose a lot of users.

I think there's the potential for a slight middle ground, but it would involve giving up a lot of the e2ee bells and whistles that privacy enthusiasts enthuse about (like perfect forward secrecy). You could image for instance a system where you have a single e2ee password and your data is encrypted on the server with that password. When you log in, you supply two passwords: your login password and your e2ee password. Then you have access to everything.

This tends to irritate people on both sides, since you can still lose your messages if you forget your e2ee password, and your privacy guarantees are also weaker, since the e2ee password can be a single point of failure that allows someone to read your messages. But people already rely on this level of security in other contexts. For instance, some cloud backup solutions encrypt your backup with a single passphrase. People are okay with having one password to unlock their entire hard drive's worth of data but not with one password to unlock their chat history?

I think it's worth exploring the space of e2ee solutions to find something that finds the balance between the levels of privacy and convenience that most users want. The thing is that existing apps that tout e2ee often do so to appeal to hardcore privacy advocates or people like dissidents in authoritarian states who are at risk of death if their messages are discovered. This level of security simply isn't a concern for the average person, and so they're not willing to take on the inconveniences that go along with it.

Re: Verifying your Matrix devices is becoming mandatory

#107
post #70
post #52

Earlier quoted context omitted.

> Pretty quick and easy in most cases The experiences reported here seem to say otherwise... As others, anyhow, I haven't tried again recently > (Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.) I last tried Element about six months ago, bu…

I think current Element versions accept either a recovery key or recovery passphrase in the same input field, so there's no getting it wrong. Since you seem focused on UI, it's worth noting that Element X (their beta mobile app) has a greatly simplified interface; their team clearly has been working to make it easier. Also, other clients exist. For whatever it's worth, I've been using Matrix for about five years, inc…

I tried the current Element and Element X.

In short, the passphrase works with both and the recovery key with neither, specifically:

Element classic has two separate fields; if I input the recovery key (in the correct field), I get told "Backup could not be decrypted with this PASSPHRASE: please verify that you entered the correct recovery passphrase."

That's how it was the last time I used it, and if I'm not mistaken it's been for years.

Element X has a single field, that supposedly takes both passphrases and recovery keys, but if I enter the recovery key I'm directed to a "Verify with another verified device" screen, even if I had logged out from all other sessions.

Funnily, by the way, it seems that with Element X you can't do anything if you don't manage to get verified, there just doesn't seem to be a way to skip it.

Furthermore, after signing out from Element X I'm unable to even just logging back in, I get an error ("Sorry, an error occurred") after I enter the credentials; even after clearing all the app's storage. Very, very weird.

The new login-via-browser is pretty problematical, by the way, I could only make it work with Chrome.

Re: Verifying your Matrix devices is becoming mandatory

#108

Earlier quoted context omitted.

I mean we’re there for Signal. The parts that suck still are regarding access/retention of old messages which is an area Matrix is ironically slightly better about. But Signal we don’t need to think about verification, at worst it says this asshole has a new identity and then I have to tell them I’ve reset my iPhone for the 4th time this week… Normal users do find retention important even if privacy/security minded u…

Can you use Signal across multiple devices?

Officially it supports linking other devices like their desktop app as a secondary. I currently use this to link into signal-mautrix on my matrix homeserver. This way I can access signal from multiple phones and multiple computers using a matrix client instead.

Re: Verifying your Matrix devices is becoming mandatory

#109
post #45
post #20

I tried out an alpha client once & can’t get the stupid pop-up about unverified devices to go away now. Another client didn’t have the verification flow even set up—this will end up being yet another barrier to entry for new clients. With the clients (yes, multiple) crashing often, constantly syncing for ages, & feature sets not on parity + without graceful fallbacks, I do not like the Matrix client space (nor the se…

I used to consider myself a HUUUGE matrix fanboy....while i still respect what the teams have done over time, I have been feeling a little, i don't know, deflated maybe? Maybe its the UX/UI aspect, i don;t know...i have not run a homeserver since like maybe 2019 or so? But nowadays, i have less interest in running a homeserver, and as far using the various clients: meh. Element feels bloated, and others either might…

> can run on such low resource hardware

This is what frees a barrier to decentralization & actually owning one’s data. A few of my friends are now running their own single-user or small XMPP servers since it doesn’t use much in terms of resources or storage in comparison.

> The server setup felt like i needed to study a bunch of different doc

I believe this is what the Snikket project is trying to be. That said, XMPP servers are used for a lot more than just chat which is why most of them don’t have good defaults for merely chatting with friends since that isn’t the only or a generic enough use case (XMPP is behind Zoom, Jitsi, Fortnite, etc.).

> The clients were a little disappointing; again not terrible but not great

True. But I appreciate that there are many options & most features gracefully fallback even on TUI clients (like ‘reactions’ just being a message reply with a single emoji). If Element adds a feature (like polls), the other clients, the new feature just doesn’t show up. For a web client, the NLNet funding is really giving a boost to Movim as a reasonable alternative to Discord that is self-hostable & federated so users—taking back the meaning of “join my server” to literally mean someone’s server & without needing to create another account just to join that server.

As for the wish… this is what XMPP MUCs are—IRC with niceties like moderation, optional encryption, & file uploads. You said yourself the resources for servers is small & for your stated use case, most existing clients can handle being IRC+features while also not being centralized unlike IRC.

Re: Verifying your Matrix devices is becoming mandatory

#110

Earlier quoted context omitted.

Can you use Signal across multiple devices?

Officially it supports linking other devices like their desktop app as a secondary. I currently use this to link into signal-mautrix on my matrix homeserver. This way I can access signal from multiple phones and multiple computers using a matrix client instead.

But you still need one "primary" device and it has to be a phone, right? That's different from Matrix where you can have arbitrary devices that are all on an equal footing.
Post reply on HN