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.
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.
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.
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...
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.
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
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.
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.
* 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.