Comment by tialaramex
6 years ago
I think the timing makes Moxie's point very well without him saying a thing.
All these years later Matrix only has... The ambition to some day try to offer the core privacy features Signal already delivered back then. Some of the most basic stuff is, you believe, almost kinda sorta done.
This is, to be clear, much better than just sitting back insisting you were right but not lifting a finger. But for an actual user who needed privacy and security any time between then and now - and for future users who need it between now and whenever you get this stuff working in the real world, it was Signal that delivered. Moxie was right so far.
Talking about privacy of a system that requires you to sign up with a phone number, that in my country (and in most other European countries as far as I know, and without talking about non democratic regimes) is required to be associated with your ID (it's illegal to buy a SIM without registration) is nonsense.
And you know another thing? Email works great to me, and it's decentralized. I have my email server, with my domain, so I don't depend on anyone to provide me a service. I have full control of my data that is on my server. I can even send encrypted emails with GnuPG without any problem, and it's as secure as Signal, if not better. I can use whatever client I want, a fancy application, a web interface, or as I do a small CLI program since I don't use graphical user interfaces.
Sure, having a chat protocol that is decentralized like email would be great! I wish that Matrix will evolve in something usable in the following years, we need that. I need a chat application where I can have a client that I can use in my terminal, and Signal doesn't do that (Telegram does, for example, since the API is more open, and it's what I use second to email).
> I can even send encrypted emails with GnuPG without any problem, and it's as secure as Signal, if not better.
Alas this requires a fairly contorted definition of "secure" to be true. The cryptography in GnuPG has plenty of problems even if you insist on manually doing everything from your own CLI tools which maybe don't suffer the problems from EFail.
Mostly it's just kinda old, AEAD hadn't been conceived when Phil wrote PGP you know. That's a big foundational idea for modern crypto and instead PGP had to kind of fudge a separate MAC into the design and hope that's good enough.
When you send your GnuPG encrypted mail, how do you decide which cryptographic primitives to use? With Signal the whole _point_ of Moxie's decision is that Signal gets to insist on all clients having whatever the best option is, so that's always used. But in GnuPG you've got to guess, what might the other participant's client be able to handle? If you guess wrong then your email is unreadable, or, worse, bad guys might be able to read it more easily.
> in most other European countries as far as I know
In England at least SIMs are available in the pound shop. You buy a SIM with cash (a single bright coin) and it comes with a phone number. British people do not carry any ID as a habit, and I make a point of never having ID unless I've been specifically asked to bring it for a good reason (e.g. to leave the country or when I got a job that required security clearance).
>...if you insist on manually doing everything from your own CLI tools which maybe don't suffer the problems from EFail.
The only surprising thing that EFail revealed is that there are email clients out there that will silently allow html emails to communicate with the outside world. Encryption isn't the only thing that leaks from such clients.
>...PGP had to kind of fudge a separate MAC into the design and hope that's good enough.
Well isn't it? What attack is possible here? What attack was ever possible?
>When you send your GnuPG encrypted mail, how do you decide which cryptographic primitives to use?
You use the best ones supported by the receiver as listed in their public key. No one actually has to decide this and no guessing is required. This is something that the OpenPGP standard gets right for a crypto standard. Such things by necessity have to evolve over time. Sure this was hard to figure out, but it's done now. This particular wheel does not have to be reinvented or avoided.
2 replies →
> And you know another thing? Email works great to me, and it's decentralized. I have my email server, with my domain, so I don't depend on anyone to provide me a service. I have full control of my data that is on my server. I can even send encrypted emails with GnuPG without any problem
OK, and how many non-technical people do you email that have GPG keys? If they don't have GPG, how do you have end to end encrypted communications with them?
This is where Signal won and GPG lost, with the Signal protocol integration into WhatsApp, one billion people instantly got secure comms without even having to know what a key is.
> it's as secure as Signal, if not better.
Signal uses a new key for every single message you send, so it could be argued that actually Signal is better than GPG.
>I need a chat application where I can have a client that I can use in my terminal, and Signal doesn't do that
Have you looked at signald or Signal-CLI?
https://gitlab.com/thefinn93/signald https://github.com/AsamK/signal-cli
weechat-matrix is really nice
1 reply →
> Some of the most basic stuff is, you believe, almost kinda sorta done.
The core Matrix stuff has been usable for years, and in many ways you've had better metadata and censorship protection available than Signal - given you have the option of running your own server which could be entirely off the grid, and used only for your own conversations.
However, if your point is that Matrix focuses on freedom as well as privacy (rather than privacy at the expense of freedom), then we're agreed :D
No, a hypothetical option to never communicate with anybody on the network isn't "better protection" in any meaningful sense than a system designed from the outset to actually protect you when you communicate with other people.
When you say we're trying to improve I want to believe you. When you stubbornly declare "we're better" in "many ways" while actually being much worse, what could I conclude? Only that your goal is to deceive people because you're not really interested in improving. Blergh.
Back in February 2015 you did not understand the gravity of the mistake in leaving end-to-end encryption as a TODO item for Matrix and defended this decision as "Pragmatic" repeatedly. Matrix itself is a bit older, mid-2014 I think, but 2015 was the first time I ran into the arguments for Matrix. It's important to underscore those dates. I've moaned (including to his face) about Tim's choice not to do encryption out of the box in his toy hypermedia system, but that was almost 25 years earlier and whilst annoying a lot more understandable. 2014 on the other hand is after BCP #188 ("Pervasive Monitoring Is An Attack") and all that implies so there are no excuses. Matrix was a defective design on day zero. 2020 begins with a promise that it'll be fixed soon, kinda, sorta and then a retreat to old arguments about how it's all worth it for "freedom".
When I say "kinda sorta done" I am not referring to being able to send unprotected plaintext over the Internet in 2020. What's "kinda sorta done" is the basic task of sending messages between participants without anybody else knowing what was said, or preferably who by and who to. It sounds like Matrix's _ambition_ is still that in 2020 this will be the case for certain groups of participants, at least some of the time. Not everybody, and not all the time, and not yet unless you go out of your way which we know users will not do.
? I'm confused. My understanding is that Matrix/Synapse has E2EE; it's just that the UX around it right now is still garbage (and that's what they're working on).
Building monoliths (like Signal) is easy and that's a core take-away point of Matthew's response in the blog post. Building Matrix is not and has not ever been a small task, but the effort gives us the freedom to run our own services and still be able to talk with our friends. Matrix is the "long game".
And it's a worthwhile pursuit. Moxie's points simply don't make sense, and are infuriating / disrespectful to those who are working on solving decentralization's issues.
_Of course_ it will be difficult. But the same argument could be made for building a completely unencrypted messenger app. You won't have to worry about managing keys, obfuscating metadata, or anything like that.
At the end of the day, it's about realizing the importance of both privacy _and_ decentralization that our current infrastructure threatens.
He's been anti-complexity for awhile. the matrix ecosystem is far more complex than signal.
4 replies →
>All these years later Matrix only has... The ambition to some day try to offer the core privacy features Signal already delivered back then.
E2E on Matrix works, plus key verification is easier than on Signal. Managing metadata is hard, but my Matrix homeserver doesn't have my phone number (unlike Signal) and does not require Google Cloud Messaging. I can even run it on a PinePhone or Pocket CHIP!
>But for an actual user who needed privacy and security any time between then and now - and for future users who need it between now and whenever you get this stuff working in the real world, it was Signal that delivered. Moxie was right so far.
Tell that to the people getting imprisoned due to Signal's metadata leaks: https://news.ycombinator.com/item?id=21747424
> Tell that to the people getting imprisoned due to Signal's metadata leaks
Isn't this rather Twitter's metadata leaks in your source?
...that wasn't Signal leaking data, though, and unlike Twitter, which until last week allowed anyone to mass-check phone numbers, Signal doesn't publicly broadcast your number.
I don't use Signal, and won't as long as they force a phone number, but at least be accurate.
> Tell that to the people getting imprisoned due to Signal's metadata leaks:
Please explain how Signal leaks metadata given:
- everything behind the client and the server goes over TLS
- all Signal messages are end to end encrypted with the Signal protocol
- the Signal server doesn't even know who is messaging whom in the majority of cases: https://signal.org/blog/sealed-sender/
E2E in Matrix "works" with which Matrix clients? The whole point of a decentralized federated messaging protocol is to allow people to build their own clients. Do Matrix clients uniformly and interoperably support E2E today?
Nearly; we’re aiming to force on E2E by default at end of Jan (but it’s getting tight). There are at least 6 complete independent implementations, and once cross-signing lands it’s good to go. For clients/bots/bridges without E2E we have pantalaimon (a clientside daemon which you proxy all the traffic through in order to encrypt it).
2 replies →
bruh did you honestly just say home server.... might as well just say use "tor and pgp".
Well, XMPP had working e2e encryption a decade before Signal. That's not really a reason to consider something done. Axolotl and OMEMO improved on OTR, and it seems OTRv4 will improve on it further.
Wait a minute. When you say "Axolotl improved OTR", what you're really saying is that Signal improved on OTR, because that's where Axolotl comes from. The same is true of OMEMO.
It seems like they are both right based on their values? Signal put privacy and security first, and Matrix put federation first.
They are both idealistic in their own way.
Security: sure, but privacy: no. An application focused on privacy should never require a phone number. In many countries phone numbers can easily be tied to individuals.