[ATsch]

I think you misunderstand why the keys were deleted. The keys get deleted on the client when you log out. This is sensible, because if you log out on a device, you probably don't want to keep the keys around in your browser storage. When the users session is destructed on the server, existing clients get a 403 error and told that their session is logged out. When that happens, they go through the normal logout routine which involves deleting the keys on disk.

Deleting the keys isn't something the matrix.org folks explicitly had to do because of the compromise; it's simply how the riot.im client reacts when you terminate it's session.

[notyourday]

If user sessions are that important, then there's no way Matrix should be killing them and instead that behavior has to become a design and operations constraint.

Imagine if this was facebook. Or whatsapp. Or signal and this was the result. They would be crucified ( justifiably ). But for some reason we are giving Matrix a pass.

[cyphar]

There is currently a bug open in Riot to allow users to save their keys if there was a forced logout by the server (right now, if you try to log out and don't have key backups set up Riot will warn you and ask you to set up key backups).

But, your comparison with other messaging apps aren't really a fair comparison (other than "they are messaging apps"). The reason why they don't have these issues is because they don't provide features that Matrix does -- and those features make it harder for Matrix to implement something as simply others they might. For example, Signal stores all your messages locally and doesn't provide a way for new devices to get your history -- Matrix doesn't store messages locally long-term and all your devices have access to your history. In addition, there is no "log out" with Signal unless you unlink your device.

The reason why Matrix doesn't have e2e by default yet is because they want to ensure issues like this don't happen to every user.

[notyourday]

Maybe I'm not clear -- destroying any user's data without user's explicit authorization is unacceptable for any non-joke of a system.

If users' keys are linked to the session key then the system has to be designed in a way that the centralized session key store is protected like a pot of gold. That's a design constraint and dictates operational constraints.

> Matrix doesn't store messages locally long-term and all your devices have access to your history. In addition, there is no "log out" with Signal unless you unlink your device.

If one designs this kind of a system, one accepts the security constraints this system has. That's a basic competence or in this case a lack of it.

[cyphar]

If Riot kept around your session keys even if you were logged out I guarantee that a similar complaint would be made about it being insecure since it leaks keys.

I would also like to point out that e2e is still not enabled by default because of issues like this. If you enable it you should know to enable key backups.

Riot has supported automatic key backups for the past few months, and if you'd used that you wouldn't have had a problem (yes it should've existed earlier but there are a lot of things for the underfunded Matrix team to deal with). And the reason it's not default is because making such a system opt-out would also make people start screaming about how Matrix is insecure because "it stores your keys on the server".

I think in many respects, the people working on Matrix are going to get criticised like this no matter what they do. I note you haven't actually suggested a specific proposal for how to fix this -- you're just going on about design cinstraints and how Matrix is therefore a joke system. To me that seems to be more snark than useful advice.

[notyourday]

> Riot has supported automatic key backups for the past few months, and if you'd used that you wouldn't have had a problem (yes it should've existed earlier but there are a lot of things for the underfunded Matrix team to deal with). And the reason it's not default is because making such a system opt-out would also make people start screaming about how Matrix is insecure because "it stores your keys on the server".

Encrypt the bloody backup keys with a key derived from a passphrase selected by a user.

> I think in many respects, the people working on Matrix are going to get criticised like this no matter what they do. I note you haven't actually suggested a specific proposal for how to fix this -- you're just going on about design cinstraints and how Matrix is therefore a joke system. To me that seems to be more snark than useful advice.

The snark would be to say "Use Matrix. Who cares about the system not being built to deal with the design constraints"

No one should defend Matrix after this. It was not a mess up. It was an Equifax level fuckup that was totally preventable.

[cyphar]

> Encrypt the bloody backup keys with a key derived from a passphrase selected by a user.

Actually the system they have is better than that. You generate a random Curve25519 private key and the public part is stored. This allows your client to upload backups of session keys without needing to constantly ask the user for their recovery password.

You can then set a password which will be used to encrypt the private key and upload it to the homeserver (but you can just save the private key yourself).

So, not only do they have a system like you proposed, it's better than your proposal.

> It was an Equifax level fuckup that was totally preventable.

I agree with you that their opsec was awful on several levels, but you're not arguing about that -- you're arguing that their protocol doesnt fit their design constraints (by which you mean that they clear keys on forced logout without prompting to enable backups if you don't have them enabled yet -- as I mentioned there is an open bug about that but that's basically a UI bug).

All of that said, it's ridiculous that they don't have all their internal services on an internal network which you need a VPN to access.

[acct1771]

Yes - on their operational security.

Not the implementation of the encryption code.

Which we'll continue to use from people like www.modular.im, and whoever else springs up. As well as self-hosted servers.

Don't trust them? Host it yourself, and it's easier every day.

That's what drew me to the platform, and what will keep those serious about security, and decentralization/federation.