[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