Hacker News new | past | comments | ask | show | jobs | submit login

It still looks like users that enable the previously mentioned option and/or verify sessions accordingly are fine. I'm just trying to clarify a simple guideline for users looking to continue using Matrix securely with confidence.



It doesn't look remotely like that, given the description the previous comment provides.


"if you follow these instructions without fail, Matrix can provide you with confidentiality and authentication." I was hoping the researchers could clarify these simple mitigation instructions to protect users, assuming they already know how to use Element.


Do you think saying things like "if you follow these instructions without fail" makes Matrix security look better?


Yes. I have used Matrix professionally for years and it's pretty simple for me to understand and follow what is unnecessarily editorialized here to keep my conversations safe. I don't understand why this language is not being simplified to keep Matrix users safe, as that should be the highest goal of this entire situation.


The typical standard for a system that purports to offer cryptographically secure communication to end-users is that it does it by default rather than 'only does it if the user does these specific things otherwise it doesn't'. This isn't some controversial thing or topic of particularly serious debate.


I agree wholeheartedly and this is why I use Matrix. The fact that a vulnerabilitiy of this magnitude can largely be defeated with precautions, albeit non ideal, are a real testament to the power of e2e. Hopefully we will see the fixes these non-default settings recommendations very soon.


You keep saying that this vulnerability can be defeated by carefully examining warnings. That's simply not true. The vulnerability is that the server, which you're not supposed to trust, can allow unauthorized people to decrypt your messages. The fact that you get a warning when unauthorized people are decrypting your messages is not a "defeat" of the vulnerability!

The bug is that you're owned, not that you didn't get an alert saying that you're owned.


Did you skim over the part where there's a toggle to strictly prevent sending messages to unauthorized devices?


No, I did not. There are like 7 different horrible vulnerabilities in this paper, and you're talking about a different one (the one where the server can add new devices to people's accounts!) than I am (the one where the server can add random people to your channel, whether they're verified or not).




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: