That said, there are some other pretty big differences between Matrix & Signal; the biggest one is probably that Matrix is an open standard and open network, encouraging 3rd party clients, servers, bridges, bots etc - optimising both for freedom/liberty as well as encryption. Signal optimises for privacy at all costs and doesn't allow 3rd party clients or services. See https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom for more.
Matrix doesn't have any special way of avoiding that tradeoff. It just takes the other end of the trade: Matrix servers are exposed to valuable metadata, so that people can use whatever identifier they want.
And, of course, the flip side of Matrix's "freedom and liberty" federalized design is that it is May 7, 2020, and the project is just now announcing E2E by default for private conversations. This is exactly why, years ago, Moxie Marlinspike wrote his post arguing about the downsides of federalization. It sure looks like his predictions were borne out!
I think both of these projects are valid and important, and that they have different goals and audiences, and we do people a disservice when we pretend like they're in any kind of serious competition. Matrix is what you'd replace an IRC server with. Signal is what you'd tell an immigration lawyer to use for messaging.
I'm skeptical that much of this particular delay has to do with federation, as opposed to things like differing priorities and general project velocity.
Why? Because Matrix is not yet as successful or as diverse as XMPP, the example Moxie gave in his blog post. My impression is that Matrix has one main server implementation (Synapse) that everyone uses, and one main client implementation (Riot) that E2E encryption was added to. And the company developing Synapse and Riot is also developing the spec, so it's completely coordinated. Alternate clients and servers exist, but they're very much "alternate"; I don't think anyone was waiting for them to implement anything before making this announcement.
I could be wrong. I'm not involved in Matrix development, or even a Matrix user. But that's my impression from some quick Googling.
If I'm right, the only real cost of decentralization at this point was having to (a) design the protocol itself to support federation and (b) document the protocol as part of the Matrix spec. That's not nothing, but it's small potatoes compared to the kind of massive ecosystem fragmentation Moxie was talking about.
Yes, Matrix’s development would go way faster (6-10x is my estimate) if it wasn’t decentralised. Huge amounts of effort goes into designing a system where you have multiple servers (or peers in p2p) which can’t be trusted, and where the behaviour needs to be formally specified in a neutral public spec that can be independently implemented. You have to layer the spec into abstractions which ensure the lower layers are stable and relatively frozen such that folks can build on them confidently, but the higher layers can evolve and experiment as rapidly as possible.
However, we think this is an acceptable cost in exchange for building an open network / protocol / ecosystem like Matrix. Freedom is important.
As comex points out, we’ve tried to mitigate slowness by developing the core of Matrix (protocol and reference server and reference clients) by the same logical team rather than by vying factions - which has certainly helped, but only as an incremental factor.
The fact it took us 3 years to exit beta for E2EE and turn it on by default reflects more that we chose a large scope (interactive verif, cross-signing, encrypted key backups, etc all break new ground, afaik), had to make it decentralised, and also reflects prioritisation (encryption is not our only focus).
So yes, it takes longer to build Matrix than a centralised e2ee messenger. Or longer to build bitcoin than paypal. Or the Web than AOL. But we think it’s worth it.
https://news.ycombinator.com/item?id=21765008
But there have been other times where "soon!" have been given over the past three years:
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
I like Matrix and think Signal makes some serious mistakes for no apparent reason, but yeah, the repeated "Matrix is just as good and more free we swear!" is...maybe not the right thing to say, yet.
Is there any technical reason why Matrix servers would have to store contact lists?
Both Signal and Matrix would have store message metadata to deliver it.
I searched for what the significant difference is, but could not come up with a good document to read.
Could you link to a reputable resource for this? I've always imagined that phone number background checks were mostly scams with a bit of public information sprinkled on top.
I'd be very surprised to learn that I could purchase a burner phone, give you the phone number, and have you be able to tell me my address and criminal history.
OK, so even if you pay cash, there's video surveillance in the store, and surveillance (license tag, video, etc) on the route. And that's linked to the number. Then there's the number that you call from to activate the burner phone account, which may have some identity information. Plus geolocation data for that, and for the burner phone.
I guess that I'm a few years out of touch.
There's no ID requirement in the US, I think.
In each case I got dozens of the same flavour of site, which I've seen many times before, it has a paginated list of every possible phone number that could exist, and an advertisement. These sites are pretty cheap to build and presumably over their lifetime they bring in enough advertising revenue to justify renewal costs, hosting and so on.
But they don't offer (and couldn't deliver) personal information about any of us, since that isn't publicly available.
In practice,it's worse than having to use your SSN. You don't need SSN to sign up with all the major apps and sites (including free email),but you do need a phone#.
This sounds like an interesting trade off, but I'm not totally following how using phone numbers and contacts avoids the metadata on server issue.
Unsure how this relates to contact lists though (other than that secret sender is apparently only available for messages from people in your contact list?)
Matrix on the other hand isn't a message-passing system like Signal (or IRC or XMPP or SMTP) - instead it's a way of securely storing your conversations (more like NNTP or IMAP). This means that when you log into a new Matrix client you can get at your conversation history, and it means that even if you lose all your clients you don't lose your history.
The compromise is that Matrix ends up storing the metadata of who spoke to when in the conversation history which is stored on the server.
However, we're working on mitigating this with P2P Matrix (where you run the server clientside, unless you explicitly want to pin that conversation to a serverside server), as per https://fosdem.org/2020/schedule/event/dip_p2p_matrix/ - and it even works :)
Then there's all the "private" data about you that is commercially available. That's what credit agencies and similar companies do--buy your data from any company willing to sell it. Such databases are so deep and comprehensive that these companies have become extensions of intelligence organizations for all the business they do with government. In fact, just a year or two ago there was the "scandal" where it turned out cellphone companies were selling location data, which some savvy police departments started using to avoid dealing with warrants.
Well, that's precisely why I don't use Signal. In that I don't use smartphones. I could probably run Signal in an Android VM. But I have no way to get a phone number that's both adequately anonymous and adequately secure. Or at least, I don't yet know how to do that. Burner phones are too readily located, and hosted SIMs are too insecure.
Android x86 VMs now have functional virtual WiFi interfaces. But I'm not aware of a virtual cellular network implementation, which could theoretically (I imagine) allow virtual SIMs. That would be very cool. Or maybe it's doable with VoIP?
* The Signal client regularly re-sends your complete local contact phone numbers to the Intel SGX contact-intersection code on Signal servers. So, potential flaws in that process would mean Signal servers continually receive, & could possibly log, far more metadata than competing systems that upload all your contacts' phone numbers.
* Signal leaks that your phone number has enrolled with the Signal service to anyone who chooses to query it.
It's great that Signal has devised a system that, ostensibly, obviates the need for them to keep persistent lists of everyone's correspondents. But as that same system requires the constant, repeated uploading of phone-number-identifiers, and complete trust in Intel SGX™, it misses the primary thing most want from an end-to-end, open-source solution: no reliance on remote personnel or systems.
Signal's created a fancy 'Maginot Line' that ultimately reduces to the same core flaw as much-simpler architectures: if a small number of hard-to-monitor key people or servers are compromised, even temporarily, the metadata is also compromised.
You tout that "Signal's servers store no contact lists at all". But can you prove that? Signal's servers are still sent all the same data that would be required to do that.
Meanwhile, other secure messengers manage to:
* avoid ever knowing a users' phone number, or revealing a users' phone number to their correspondents
* avoid broadcasting the fact of a user's participation to anyone who cares to query
It's important to remember these caveats & tradeoffs when alleging Signal stores no contact lists at all.
I want readers to know that your headline claim, "Signal's servers store no contact lists at all", should be coupled with the important caveat that believing that claim still requires trust in Signal and Intel personnel/servers.
And even if someone, like yourself, assumes such trust in Signal & Intel, the metadata protection Signal does offer still requires other metadata tradeoffs. That's not 'equivalent' to other options, it's different in notable ways. For some users, like say an anonymous whistleblower without a 'burner' phone number, Signal's metadata handling is arguably worse than other extant options.
You find Signal a preferable, perhaps even dominant choice; I think they're a mixed-bag once aware of all the tradeoffs.
The interface is just complicated for average people and the translations were half done and this will scare people off if I recommend for cross company chat.
The server side may be great but it needs some work to have simple and elegant client on desktop and mobile clients.
Currently I use Mattermost and it seems to be doing ok but this has no built-in support for audio and video.
All I can say is that we’ve hired three permanent kick-ass full time UI/UX designers for the team, put them charge of the product direction for Riot, and told all the devs that their job is to do nothing but implement their design iterations as efficiently and accurately as possible. Let’s see how it goes.
Can Matrix servers be run as Tor onion services?
regardless, the e2e encryption debate seems largely settled by the key players at this point. I think any legislation that makes its way through is likely to see brinkmanship again. Theres no reason these services cant use darknets. At the risk of sounding like a cryptobro, theres also no reason they have to use a server at all with blockchain.
Matrix is federated and individual servers can be run by volunteers/individuals for whom EARN IT would not apply.
It would apply to them if they were or served US citizens, which would mean that nobody in the US could get encryption, which is exactly what might happen with Signal.
Sure, but only if they could be identified. So obviously any such volunteers would make sure that they remained anonymous. Otherwise, they would suffer the consequences.
Can we stop saying blockchain for everything? You don't always need to, nor want to, audit your entire history.
So if every country passes something like EARN IT, Signal shuts down, how is that resilient?
That's not a forgone conclusion. Maybe it is for Signal, but not for chat overall. There's this thing called Tor. If you're careful, you can remain anonymous. And there's the new onion routing network Loki, which backs the Session chat app.
If things got bad enough, there are more robust options. I can imagine a botnet that spread much like WannaCry, and which offered deniable messaging via covert channels. Data transmissions would be hard to detect, and running the network components would be deniable.
Signal: - cannot run own server - writing clients discouraged; centralised control preferred
Matrix: + can run own server + writing clients encouraged
Ideally, what persons A and B might want is a protocol that allows for peer-to-peer connections without passing traffic through the third party. The server might be merely a point of rendezvous to enable one person to discover the network address of the other. For example, person A contacts person B's rendezvous server for person B's address, port, etc. Then person A makes direct connection to person B. Once that peer-to-peer connection is established there is no more need for the server. No traffic passes through it. It could even be shut down.
Also: they are fairly old by now, and most complaints that have merit have been addressed.
This blog post goes into more detail https://matrix.org/blog/2019/06/30/tightening-up-privacy-in-...
What metadata are you talking about?
"Who you send a message to" is actually a relationship between two pieces of information, a sender and a recipient but Signal doesn't collect this in most cases.
Who the message they received is _to_ in the sense of which Signal account it's for, they need to know in order to store it and pass it on. But who you were they don't need in most cases because of their Sealed Sender feature.
When you converse with Alice your phone fetches profile data that it is able to unlock because Alice's phone agrees you're a friend and provided the key to do so. Alice's profile includes tokens that her friends can use to send her messages. Subsequently your phone presents a token authorising you to send messages to her, and so Signal does not ask it to identify itself when sending this message.
As a result Signal intentionally does not learn who sent these routine messages between friends and acquaintances even though the message recipient can determine who sent them.
And, by extension, the exact real world identity and location of this person.
Signal promises not to store metadata, but definitively have access to it.
Not at all? Most likely what's happened here is that you don't understand what "by extension" does in a sentence.
Hopefully the difference about having access to data and storing data is still clear?
Apart from that, group membership is also E2EE, which is a signifiant piece of metadata.
How is this achieved? How can this be attacked? Are users at risk of deanonymization?
We're mitigating this with P2P Matrix (https://fosdem.org/2020/schedule/event/dip_p2p_matrix/ etc), where there are no longer servers where metadata pools.
Signal: ?Brian Acton?
Signal: + protects metadata + protects the content (e2e encryption) - is not anonymous - is not resilient against regulations
Matrix: - does not protect metadata + protects the content (e2e encryption) + is anonymous + is maybe, potentially resilient against regulations (federated, not centralized architecture)