[sodality2]

Their quote related to the incident and deleting keys (GPG release signing keys on prod machines, no locked down servers, etc leading to the hack):

>You might have lost access to your encrypted messages.

>As we had to log out all users from matrix.org, if you do not have backups of your encryption keys you will not be able to read your encrypted conversation history. However, if you use server-side encryption key backup (the default in Riot these days) or take manual key backups, you’ll be okay.

>This was a difficult choice to make. We weighed the risk of some users losing access to encrypted messages against that of all users' accounts being vulnerable to hijack via the compromised access tokens. We hope you can see why we made the decision to prioritise account integrity over access to encrypted messages, but we're sorry for the inconvenience this may have caused. [1]

I think this shows they simply revoked keys to avoid the hacker accessing messages. Had messages been breached, that would have been significantly worse for an E2EE federated messaging platform.

[1]: https://matrix.org/blog/2019/04/11/we-have-discovered-and-ad...

[notyourday]

They revoked keys of users without giving users a choice, ability to save, backup user messages etc.

It is a company with operations, engineering and business ran by amateurs that do not understand the foundation of any user facing business - when you have a choice between not destroying user data and devising a method to handle a situation even if it costs you and losing user data, you do the first.

Every single person that gives them his or her data to host is a toddler having a tantrum.

[sodality2]

>As we had to log out all users from matrix.org, if you do not have backups of your encryption keys you will not be able to read your encrypted conversation history. However, if you use server-side encryption key backup (the default in Riot these days) or take manual key backups, you’ll be okay.

I'm not defending them, in fact I prefer XMPP+OMEMO (or I would if I had someone people to talk to). But it seems like the default is key backup which means a significant number of users do have access to their old messages once they restore their key.

>Every single person that gives them his or her data to host is a toddler having a tantrum.

I mean, if you're criticizing a central server in a decentralized platform, agreed, I don't like the heavy influence a single "default" server will have, which is why I self host for myself and any friends/family who want to use it.

Keep in mind that this was a bad hack and IMO they made the right decision to revoke keys (alternative is possible leak of every message, ever sent on their platform) but I don't like that it came to that. Do you think they should not have revoked keys, and if so why? If you're criticizing about the hack in general, though, 100% agreed.

[notyourday]

> Keep in mind that this was a bad hack and IMO they made the right decision to revoke keys (alternative is possible leak of every message, ever sent on their platform) but I don't like that it came to that. Do you think they should not have revoked keys, and if so why?

That is not a decision for them to make, rather that is a decision for their users to make. Their inability to understand that the mantra of a company that happen to carry user data is "Shall not lose user's data" means the are not tall enough to take the ride.

> If you're criticizing about the hack in general, though, 100% agreed.

That's a separate topic. Their operational security was atrocious, which even by itself should be a reason why one should highly discount their hosted promises but to me inability to understand that under no circumstances they can choose to destroy user's data trumps it.

[sodality2]

>That is not a decision for them to make, rather that is a decision for their users to make.

At which point the data could be taken and leaked. That would end the company, protocol, and platform forever.

>Their inability to understand that the mantra of a company that happen to carry user data is "Shall not lose user's data" means the are not tall enough to take the ride.

I think having lost data is better than having it stolen and lost...

>That's a separate topic. Their operational security was atrocious, which even by itself should be a reason why one should highly discount their hosted promises but to me inability to understand that under no circumstances they can choose to destroy user's data trumps it.

I concur. Again, not arguing against that there were significant failures, missteps, and mistakes that led to this. But saying "the users should have the choice" simply would have opened up the risk of a more serious attack at the whim of whoever was doing the attack...

[notyourday]

> At which point the data could be taken and leaked. That would end the company, protocol, and platform forever.

First of all, Could and is are two different things. Second of all, if the protocol and company are so badly designed that "could" is equal to "leaked" then it should be the end of the the protocol and the company.

> I think having lost data is better than having it stolen and lost...

Not "stolen" vs. "lost" but "possibly stolen" vs. "definitely lost". It is up to a user to establish if they think that "possibly stolen" is worse than "definitely lost"

> But saying "the users should have the choice" simply would have opened up the risk of a more serious attack at the whim of whoever was doing the attack...

Absolutely not. That's the trade off that one makes when deciding to handle user data. Encryption and backup strategies come into play there. The company in question had not bothered to think about it.

[sodality2]

>Not "stolen" vs. "lost" but "possibly stolen" vs. "definitely lost". It is up to a user to establish if they think that "possibly stolen" is worse than "definitely lost"

Not when you are in a critical situation and you don't know if the attacker is exfiltrating data right now.

>Not "stolen" vs. "lost" but "possibly stolen" vs. "definitely lost". It is up to a user to establish if they think that "possibly stolen" is worse than "definitely lost"

No, it's "possibly stolen" vs. "lost if you don't have your password and can't log in", because: "No keys were revoked (nor does Element have the power to do so). What happened was that existing user login sessions were destroyed and users had to log in again." https://news.ycombinator.com/item?id=26316147

[feanaro]

No keys were revoked (nor does Element have the power to do so). What happened was that existing user login sessions were destroyed and users had to log in again.

If you had either backed up your keys locally or had an encrypted copy of your keys stored on the server-side as a backup, no access was lost.

[notyourday]

If the keys were associated with a session, then it quite literally demonstrates how clueless the company and its engineers are:

1. Send a message to the users with the existing sessions telling them to create backups.

2. Have users confirm that the backups were created

3. Log users that created backups out.

There's no excuse at losing user's data. Ever.

[Arathorn]

I ran the response for the Apr 2019 incident that you're digging up, and fwiw:

* The breach impacted the free best-effort matrix.org server & infrastructure, not Element Matrix Services (the subject of this HN thread).

* We didn't "revoke user keys", we logged users out on matrix.org whose password hashes & login access tokens had been exposed.

* At the time we were in beta, and there was only one mechanism to logout users: a 'hard logout' used to evict client sessions which would cause them to clean up their local data; the common case where as a user you want to kick off old sessions and don't want to leave your keys littered around. Before exiting beta in June 2019, we implemented 'soft logout' as a mechanism to expire access_tokens without clients cleaning up data: https://github.com/matrix-org/synapse/issues/4280. Given the urgency to protect user data immediately after the breach, we couldn't release new clients to expedite soft logout, so had to go with hard logout.

* However, any user who backs up their E2EE keys, either online (the default configuration), or offline was unaffected. To repeat: the default configuration was to nag the user into backing up their keys, encrypted, on the server, for precisely this sort of situation. And to the best of my knowledge I don't recall anyone who reported having lost data to us.