Live data from Hacker News

Verifying your Matrix devices is becoming mandatory

element.io

41–50 of 251 posts

Re: Verifying your Matrix devices is becoming mandatory

#41
post #33
post #31

Earlier quoted context omitted.

@Arathorn would be an objectively better person to discuss this, but the Redditor isn't completely off the mark: metadata is (currently) not nearly as well-guarded on Matrix compared to Signal. However, work is ongoing to improve the situation; more importantly, Matrix is a different threat model (in my opinion), and allows for different trade-offs. When I use Signal, I have to trust Signal's servers and their admin…

Matrix and Signal have very different objectives. Matrix wants to be an encrypted IRC or Slack. Signal wants to be a secure messenger you can entrust your life to. They are both worthy projects; there's not as much overlap as people think.

I trust my life to the server I host in my own closet. People can lecture me all day long about the superiority of Signal's encryption, and I'll just slowly rotate my chair to point my index finger at the Dell OptiPlex behind me.

Re: Verifying your Matrix devices is becoming mandatory

#43
post #39

Despite all the gnashing of teeth in this thread, this seems reasonable. This seems to only prevent you from logging into your account, with only a password, NOT verifying it (by dismissing all the prompts asking you to do so), and then sending (and receiving new!) encrypted messages anyway. I've never used an unverified Matrix account in the 6 years that I've been an active user. Verification used to be a bit finick…

> Despite all the gnashing of teeth in this thread, this seems reasonable

I think it's not the requirement itself that's the crucible of discussion but the issues are rather that the blog post should have explicitly defined what verification is in it's second sentence and that matrix/element still is barely useable even for reasonably technical users.

Re: Verifying your Matrix devices is becoming mandatory

#44
post #39

Despite all the gnashing of teeth in this thread, this seems reasonable. This seems to only prevent you from logging into your account, with only a password, NOT verifying it (by dismissing all the prompts asking you to do so), and then sending (and receiving new!) encrypted messages anyway. I've never used an unverified Matrix account in the 6 years that I've been an active user. Verification used to be a bit finick…

> Despite all the gnashing of teeth in this thread, this seems reasonable I think it's not the requirement itself that's the crucible of discussion but the issues are rather that the blog post should have explicitly defined what verification is in it's second sentence and that matrix/element still is barely useable even for reasonably technical users.

> barely useable even for reasonably technical users

My entire family (including my elderly mother) would be very interested to learn how technical they are!

Re: Verifying your Matrix devices is becoming mandatory

#45
post #20

I tried out an alpha client once & can’t get the stupid pop-up about unverified devices to go away now. Another client didn’t have the verification flow even set up—this will end up being yet another barrier to entry for new clients. With the clients (yes, multiple) crashing often, constantly syncing for ages, & feature sets not on parity + without graceful fallbacks, I do not like the Matrix client space (nor the se…

I used to consider myself a HUUUGE matrix fanboy....while i still respect what the teams have done over time, I have been feeling a little, i don't know, deflated maybe? Maybe its the UX/UI aspect, i don;t know...i have not run a homeserver since like maybe 2019 or so? But nowadays, i have less interest in running a homeserver, and as far using the various clients: meh. Element feels bloated, and others either might be more snappier but might have an odd bug, or don't implement all features that might be expected, etc.

So, last year i tried to play briefly with Prosody server to re-acquaint myself with xmpp...and it wasn't so bad. Not as great as i expected for this day ana age, bbut not terrible. The server setup felt like i needed to study a bunch of different docs...and ultimately was smoother than expected....so i think documentation is either outdated, or was written a little less clear than expected. That being said, the low resource usage was ridiculously pleasant compared to matrix homeserver! The fact that an xmpp server allows for such scalability on such low resources is a great testament! And, that was prosody, which some folks state is not even as performant, scalable as ejabbered....so they say...so wow, that's impressive if that's true. Regardless, xmpp servers that can run on such low resource hardware but enable so many users to chat...is quite awesome!!! The client side of xmpp was a different matter; i wasn't so happy. I blame myself because maybe there might have been plugins that maybe i didn't install correctly on server side, i don't know...but it felt not as easy as i expected. The clients were a little disappointing; again not terrible but not great.

Maybe i'm spoiled? Or, maybe i did too much wrong? But if that's the case, the maybe there's an opportunity for better documentaiton? I don't know....i really like both matrix and xmpp because both live in the realm of free and open source software.....so i really want both or either to succeed. I want to live in a world where we are not beholden to only proprietary options, like whatsapp, crappy sms/text messaging, etc. I want to give props to all the folks who made and maintain all aspects of xmpp...as much as i am whining, i don't want to take away from all the hard work that they have freely given; super props to them!!!

What i really want is a modern, free and open source version of IRC, with plenty of modern features (E2EE, file uploads, presence detection, etc.), decent desktop and mobile clients, easy server installation and management, and said server-side software would ideally not need such beefy hardware to run...Or, is my wish too far fetched?

Re: Verifying your Matrix devices is becoming mandatory

#46
post #41
post #33

Earlier quoted context omitted.

Matrix and Signal have very different objectives. Matrix wants to be an encrypted IRC or Slack. Signal wants to be a secure messenger you can entrust your life to. They are both worthy projects; there's not as much overlap as people think.

I trust my life to the server I host in my own closet. People can lecture me all day long about the superiority of Signal's encryption, and I'll just slowly rotate my chair to point my index finger at the Dell OptiPlex behind me.

That's fine. You'll pardon me if I'm unwilling to trust my own safety to your Dell OptiPlex. Whatever you think about Signal, the fact is that Matrix --- which is what the thread is about --- makes decisions that serve the IRC/Slack use case at the expense of the "absolute most possible safety" use case. That makes sense: some of larger-scale group chat's goals are in tension with "absolute most possible safety".

Re: Verifying your Matrix devices is becoming mandatory

#47
post #15

Earlier quoted context omitted.

Isn't this how TLS itself already works? "trust on first use"?

Not in current practice. That is why you have to get a certificate from a trusted CA. If your CA isn't in the browser's cert database they will reject the connection even on the first time. If browsers allowed TOFU we would still be able to use self-issued certificates, without manually distributing certs to anyone that uses your service. SSH is an example of TOFU.

> we would still be able to use self-issued certificates

You still can... it just displays a warning message on first use, as does ssh.

Re: Verifying your Matrix devices is becoming mandatory

#48
post #14

Earlier quoted context omitted.

Isn't this how TLS itself already works? "trust on first use"?

With PKI you're trusting a certificate chain up to a CA you already trust, by way of your OS or browser vendor. A domain can layer on HSTS to that, which directs clients to additionally refuse to trust a new cert for a domain until the one you currently trust has expired.

That’s not what HSTS does. It asks the client to remember that you want to only use TLS for that domain and refuse to use unencrypted HTTP in the future.

Re: Verifying your Matrix devices is becoming mandatory

#50
post #23

I think Matrix as a protocol has been pretty ineffective, as their top priority seems to be keeping data permanent and duplicated. Both performance and privacy are at the bottom of their priority list. The one good thing I can say about it is that encryption of message contents is enabled by default in conversations and available in groups, but that's about it - nothing else is, or can be, encrypted. In other words,…

I think part of the problem may be that Matrix is just pretty complex, because of its modular and decentralised design. Meanwhile, Signal is much more centralised and monolithic. And while they have added a few features over the years, its core functionality is relatively simple, and they were initially just focussed on getting that right.
Post reply on HN