Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

While I'm very excited about the prospects for Matrix in 2019, the reality of client choice for end-to-end encrypted Matrix chat is currently disappointing compared to the potential it has.

Someone on reddit gathered some data [1] about E2EE support a few months ago, and Debian maintain a wiki page [2] about their progress packaging Matrix-implementing applications.

[1] https://www.reddit.com/r/privacy/comments/9avyen/sad_state_o...

[2] https://wiki.debian.org/Matrix



I bear no ill-will towards the Matrix project, but this fact pattern (I knew about it in the abstract but hadn't seen it laid out like this) makes me actually angry about the people who have recommended Matrix as a replacement for the Signal Protocol messengers like Signal, WhatsApp, and Wire. Telling people to switch to Matrix from those is simply malpractice.


tptacek: the reddit article there is a bit flawed (as uhoreg tries to gently point out in the response). the reality is that we provide decent E2EE stacks on web, iOS and Android which get used in the flagship client (Riot) that most people use. These are pretty solid and getting better, as per the SAS verif and cross-signing work. Other clients like Seaglass which build on the same SDKs obviously get the same experience. I would argue that these provide a decent decentralised alternative to Signal, WA or Wire, especially if you run your own server (given we don’t do log minimisation on matrix.org).

Now, there’s a long tail of other random clients which don’t do E2EE, which is inevitable given doing a good secure job of an independent E2EE implementation is obviously tough. But is that actually a problem, given the most usable mainstream clients do have it?

It’s a bit like declaring that the Web is in a disastrous sad state because of the number of HTTP clients out there which don’t have a CSS engine in them...


> Now, there’s a long tail of other random clients which don’t do E2EE, which is inevitable given doing a good secure job of an independent E2EE implementation is obviously tough. But is that actually a problem, given the most usable mainstream clients do have it?

Well, given that decentralisation is the primary differentiator from Signal (as far as I can see), everybody having to use the same client to get it is a bummer. I would even go as far as to say that it's a clear example of the problems Moxie sees with making Signal decentralised.


But they don't have to use the same client? The web, iOS/macOS & Android SDKs are completely independent, and have different clients written on them. Riot may be the main one, but Seaglass (on the macOS SDK) has full E2E support, and there are loads of projects building on the matrix-js-sdk which inherit its E2E support. Meanwhile the nheko project has an independent from-scratch implementation of the E2E stack, Fractal is adding it too (thanks to funding from Purism), and even Pidgin has it (albeit read-only currently). (N.B. that the reddit post gets almost all of this wrong :|)

So yes: Moxie has a point that the more implementations you have, the more bugs and security holes you may have, and the slower the project can evolve. But for us, freedom to control your own data and conversations and provide an open network & platform to build on is more important.


> Meanwhile the nheko project has an independent from-scratch implementation of the E2E stack

True, but here is the repo:

https://github.com/mujx/nheko

"Note regarding End-to-End encryption - Currently the implementation is at best a proof of concept and it should only be used for testing purposes."

and:

"No longer maintained - Desktop client for the Matrix protocol"


Sure, not exactly the same client, but at least you should make sure that none of the participants use one of the long tail of non-mainstream clients. Being able to do so would be one of the main selling points of decentralisation for me.


Those other "random clients" (as you call them) exist because your desktop client is bad. And I am being nice by just calling it "bad", it is the least performant client I have ever come across, even counting other electron-based software.


yup, the electron app sucks :) we are very very glad folks are writing native clients, and can't wait to kill it off. meanwhile we're working on its perf anyway, and if you look at the client redesign in the OP (riot.im/develop) you'll see it's actually getting better.


How does an encrypted client interoperate with a non encrypted client?


encryption is configured per conversation. if you try to participate in an encrypted conversation on a client which doesn't support encryption, you simply won't see the messages.


Signal is a proprietary service. As it is security-oriented, for me it looks like a clear honeypot, so I would never use it. Matrix is much better approach. While I don't like that they use flashy languages for their leading implementations instead of platform-native C/C#/Objective C/Java, it doesn't matter in the long run, what matter is standards and implementations will come.


This kind of analysis will reliably lead you to services that will get your data compromised. Cryptocat was a non-proprietary, open-source messenger with "end-to-end" encryption, and Snowden and Greenwald used it to communicate. And it was grievously broken.


Trust > features & polish.


> makes me actually angry about the people who have recommended Matrix as a replacement for the Signal Protocol messengers like Signal, WhatsApp, and Wire.

On the other hand a number of us are puzzled by a leading cryptographer and security expert actively recommending WhatsApp after all the tricks Facebook has been trying to play since they bought it, e.g default opt in to new amd wildly different terms.

Signal? Sure. Feels reasonable. Bjt as long as you keep recommending WhatsApp while lashing out against everyone else I really don't see why I should trust you.

There's more to security than bullet proof e2e delivery of tbe content, you see.




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

Search: