Why federated protocols don't work (2016)
signal.org
signal.org
https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom
Despite the supposed innovation benefits of centralised control, Signal still requires phone numbers, and its main "innovation" has been adding a pump-and-dump crypto-coin, which users are forced to have the code for in their clients whether they want it or not, because he refuses to allow non-official clients to connect to Signal's servers.
In fact he even objects to people installing the official client from F-Droid.[0] So it seems that in his mind, progress is "whatever direction I decide", and what we call freedom is what he would call "dangerous fracturing of my ecosystem".
[0] https://old.reddit.com/r/fdroid/comments/q1jnbb/why_isnt_sig...
Instead many feel Signal has moved in a wrong direction with crypto currency.
Reliance on Google as a third party is just another example of the blind-spot that Marlinkspike has about the dangers of centralisation. This is seen in his resistance to making Signal work on devices that don't use the proprietary Google Play services[0], and the slowly boiling frog of developers no longer having control of their own keys when publishing in the Google Play store.[1]
[0] https://github.com/signalapp/Signal-Android/issues/5450
[1] https://www.theregister.com/2021/07/01/android_app_bundle/
I still think the issue from 2016 is worth reading, as the issue was closed on the basis of being a duplicate, but as a commenter on the issue points out:
> Because all the refernced duplicate discussion threads trying to solve this are locked (why?), I'm raising my voice for this here.
This is indicative of a project which not only resisted supporting users without Google Play services, but also resisted people questioning their decision. Two days after that plea, without any further explanation:
> @signalapp locked and limited conversation to collaborators
Of course an issue tracker isn't a discussion forum, but a good project team would have taken an extra couple of seconds to point issue reporters and commenters to an FAQ answer (assuming they had an answer that would withstand scrutiny).
Anyway, my point is that despite the supposed merits of centralisation, people had to beg (and be met with silence) before the project deigned to grant this reasonable request. This is not the sort of permissionless innovation that free software is supposed to enable.
Similarly, although Signal may have relented and made an .apk file available (perhaps due to pressure from more innovative and user-respecting platforms like Matrix), their stubbornness is still apparently preventing F-Droid from distributing it. Here's a better link to support that claim:
I don't know what your experience with FOSS development is. I still have fairly little and only with low-profile projects, and yet I've already been accused of many things and spent (wasted?) quite some time in pointless arguments. This issue is exacerbated in high-profile projects such as Signal, and it's impossible to deal with them as you're suggesting.
https://github.com/signalapp/Signal-Android/issues currently has close to 10000 issues (most of them closed). Signal does not have that many people to deal with what is mostly noise. There are explanations about their stances regarding F-Droid etc. if you're willing to look for them. In any case these questions belong to the community forum. Most of the duplicates are opened in bad faith, and there are diminishing returns in answering all of them. I recommend you "watch all activity" on one of the Signal client repository and check your GitHub notifications to understand the problem.
> Anyway, my point is that despite the supposed merits of centralisation, people had to beg (and be met with silence) before the project deigned to grant this reasonable request. This is not the sort of permissionless innovation that free software is supposed to enable.
You're talking about their development model (which is rather closed, a very high bar has to be reached for them to accept community contributions) rather than the fact that they're using a centralized rather than federated network. The article is about the latter, not the former. These issues are orthogonal.
Source(s): Dude trust me.
> These issues are orthogonal.
They are distinct issues, but not orthogonal. It wouldn't matter how Signal decided to run their "rather closed" open source software project if they allowed other people's forks to connect to their centralised network. By not allowing that, they have "weaponised" the "rather closed" development model against their own users, and, as a result, invalidated these bold claims made about why centralised networks are better.
The benefit of Free Software is that it allows everyone (rather than a self-selected few) to add and remove features as they choose, and let users choose which fork they support. That creates a selective pressure towards genuine (user-centric) innovation, rather than changes that are declared to be innovation by fiat (excuse the pun). It also prevents the sort of stagnation (and potentially security problems) we saw when Internet Explorer had a 90% browser market share.
There are very clear links between centralisation of design/control and a culture of closed source software development (with a non-transparent "we know better" attitude).
This is pretty obvious, so much so that I'm immediately suspicious of people who believe it's some nefarious plot. You don't have to agree with it, and many people don't, but if you say you don't trust their intentions (with respect to this one issue), you're saying more about yourself than about Signal.
I disagree, in the sense that they could still produce their own client which had those new features (and use feature-detection to remain compatible with forks that support them), but you seem to be making a more subtle argument about market forces and group dynamics, which I want to understand better.
What sort of tradeoffs do you think competing clients would make? I can't think of any way that weakening the privacy could improve the UX enough to make people want to abandon the official client (although I could see people abandoning the official client for a fork which doesn't include the crypto-coin, and all of its attack surface).
The only example I can think of (trying to steelman your position as much as possible) is that other clients would remove the requirement for providing a phone number, and this would make it harder to do key verification somehow (and thus it would happen less often). I can't quite make that argument work, and I still think that not providing Signal with a phone number is a choice that users should be allowed to make based on their own assessment of the risks.
Ultimately, though, Signal closing their network cannot make users safer, since their network isn't the only way to communicate. Users who don't like the UX (or unwanted features) of their client are free to install WhatsApp instead, or just use SMS, so I really don't accept the argument that restricting free software development leads to better privacy over all.
I also found it strange they ignored one of the largest arguments that Moxie made. Federation becomes centralization. We've seen this happen time and time again. It makes sense by pareto distributions. Just the same way one city has way more people than most others (e.g. NYC has half the population of NY state). This is a natural phenomena. We saw it on the web, email, internet providers, telephones, cryptocurrencies, everything (we'll see it with web3 too). It's because if there isn't an explicit hierarchy there's an implicit one. Eventually that implicit one becomes explicit. Moxie's argument here isn't "federation sucks" it is "why fight the centralization effort? It is better to take control of it than let it run wild."
Would you also say this about democracy? Why not to become a dictator yourself and ride this wave?
So centralization is not an insult to democracy at all. Decentralization aligns if you want to make a political analogy, much closer with democracy's predecessor, feudal society in which sovereign fiefdoms compete with each other. (It's not surprising that this is also a popular form of organization among libertarian decentralization advocates).
AFAIK Switzerland would be a good counter-example to your words.
You're right in some ways. It always tends to be the official project instance. For example, the dominant Mastodon instance is mastodon.social. Eugen, the owner of that instance, did something though: he restricted registrations to the instance and encouraged people to sign up at other instances. Sadly Matrix did nothing of the sort, and it continues to allow sign-ups even though (IMO) it's quite clear that they can't handle the moderation workload.
Ok, even if that wasn't funny, it illustrates that the biggest centers of federated systems interact perfectly with smaller centers. You don't have to be part of New York to be part of the federation. And if the NYC hub walls itself off and demands tolls to interact? So be it. Let the market bear what it will.
They didn't, at all, and I find it strange you're claiming that.
After
> It’s also fair that in a multi-server federated model, users naturally tend to sign up on the most prominent server(s) (e.g. the matrix.org homeserver in the case of Matrix). In practice, the matrix.org homeserver currently makes up about 35% of the visible Matrix network by active users.
they explain how they are working to counter the effect:
> In practice, we’re looking into solving metadata protection in Matrix by experimenting with hybrid P2P / Client Server models - letting users store their metadata purely clientside if they so desire, and potentially obfuscating who’s talking to who via mixnets of blinded store & forward servers (more about this coming up at FOSDEM). Combined with nomadic accounts, this would let us eventually turn off the matrix.org server entirely and eliminate the pseudo-centralisation effect - the default ‘server’ would be the one running on your client.
This wasn't a vague "someday" claim, either; here's the most recent talk about the work they're doing: https://fosdem.org/2022/schedule/event/matrix_p2p_pinecone/
* yes it's harder to build
* harder to evolve, which is why we invested in a spec process to get it right, and you can see we push out features at a comparable pace
* does tend toward centralization, so we're working on p2p/nomadic identity
* the freedom to switch apps involves paying the costs of your history and your network, so that's a very weak freedom
And then the point about freedom is really only being balanced against the security/privacy risks of fragmented implementation.
His point would really be that you're not getting a "free" "free / open source messaging application" in a meaningful sense.
(oh, while I'll cede to you the UX has historically been crap, it's really not at "PGP key exchange parties" levels these days; my server has some non-tech friends and it's fine)
Moxie was explaining why he was doing what he was doing. I doubt it was ever intended as some sort of manifesto.
He opens by talking about how everything keeps changing, the denigrates the stuff "stuck in the 1990s" then complains that you cant change a federated protocol. Not sure what he's in favor of.
As evidence I would submit that it's 2022 and we are still using IPv4. A centrally managed Internet could have upgraded to IPv6 in one day. Send out update. Everything updates. Done.
There is a genuine and IMHO very significant problem here. If this problem can be solved it will require a different approach from the ones already tried. Pretending the problem doesn't exist doesn't help.
I've been harassing other employees to move away from our old Prometheus instance to our new one and it's been a real uphill battle. The only work is (1) copy over the alerts they want to keep to the new storage location. By copy, I mean literally copy. (2) Change the datasource pointer in grafana to the new prometheus location
Could you not copy their alerts and use DNS aliases and/or load-balancing to migrate them?
That said, I've had teams forget they had alerts at all or outright deny they owned alerts on their service.
Yeah? What does that have to do with anything? The internet became the internet expressly because it wasn't centrally controlled. If it were centrally controlled from the beginning it would never have outgrown IPv4. See also IPX.
The argument says that the last step of copying the Centralized Services is a fool's errand, and it makes more sense to build better Centralized Services through (Step 2 + SGX) specialized hardware.
Time and again Moxie has decided to build the better Centralized Services by leveraging Intel's SGX enclaves (the specialized hardware). Both Signal and MobileCoin rely entirely on these SGX enclaves.
Since I don't trust the enclaves, my hope is for Step 3.
edit that said, I do use signal everyday and I think mobilecoin is neat.
"Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all."
...which is is a far cry from "why federated protocols don't work". A more accurate headline summary might be "why we believe federated protocols are not competitive for this use case", which has a different ring to it.
In other words, it didn’t accomplish what any pro-Federation activist actually wants to accomplish.
The fact is that you generally don't, because you want to access your mail from any device and you want a server-side search. All of this is made impossible by a proper e2ee.
Also, proper e2ee requires identity verification of your contacts, where you check their key fingerprints using an uncompromised channel. If you skip this part, all e2ee you use is just a security theater.
[1] https://delta.chat/en/help#which-standards-are-used-for-end-...
Not with the same security guarantees, the same usability, nor the absence of footguns that apps such as Signal provide.
> Also, proper e2ee requires identity verification of your contacts, where you check their key fingerprints using an uncompromised channel. If you skip this part, all e2ee you use is just a security theater.
Even if you don't check fingerprints, you're fully protected against passive attackers, as well as attackers who started being active only after the key exchange. For casual users, Signal is a good protection against dragnet surveillance. For advanced users, Signal with key fingerprint checks is a good protection against more powerful attackers that control the network.
It is not a protection, just a security theater. If you don't trust your service provider not to spy on you, you must not trust it completely. Thus, Signal tells you that you are talking to Joe, but it can easily make it so that you talk to MitM who talks to Joe, for everyone, dragnet style. (those who do indeed verify fingerprints are excluded from this program)
Nobody but the slim nerdy minority wants to burden themselves with proper e2ee, yet everyone insists on having some snake oil too.
Don't want to be spied by your service provider - run you own server. That's what federation is for.
If they introduced blanket MitM, it would only take one person to verify fingerprints for it to become public. You mention that people who verify fingerprints would be excluded, but I've no idea how you'd achieve that. My understanding is that proper fingerprint confirmation has to, by definition, be conducted out of band.
With any FLOSS everyone is trusting that another geek somewhere is paying attention to a particular piece of software and will raise the alarm if there is something wrong. And I do mean everyone. I don't think its conceivable that even the most paranoid, technically proficient user could verify the integrity of their entire technology stack.
You see, this is all a question of trust. The only threat against which the e2ee is useful is non-trusted server admin. But then signal fans paradoxically don't trust Signal to have their unencrypted communications and simultaneously trust them to have means to get access to their messages.
So in practice a personal/corporate email / xmpp server without any e2ee gives you a better level of security than using third party service like Signal with e2ww, because in that case the attacker will have to somehow gain admin access to your server to learn anything about your communications, while in Signal's case, even if they don't compromise your encryption, they still have means to know who you are talking with, when, your IP addresses, etc.
(and don't even let me started on that crap where Signal supposedly has no ability to know who is sending you a message - it all can be logged on server side, and we're not trusting the service operator, right?)
Tldr: insisting on e2ee while fully trusting third party infrastructure is double-think at its best. If you want to be safe, use self-hosted servers. Which brings you to federation. :-D
The fingerprint is computed at key exchange, you can't change it after the fact without warnings about it. If you assume the clients are compromised, E2EE or federation or other network properties won't help, so this discussion is meaningless.
Nobody claimed E2EE was the be-all and end-all of security; only that it's an improvement over having to trust a 3rd party. This is because everything else being equal, the less components you trust, the better security-wise. So given a network operator, if you can choose between trusting them or not, you'll be better off not trusting them. That's why E2EE is better than no E2EE.
Finally "use your own server" seems like the perfect solution if you're only talking to yourself. To take the email example, just because you trust gmx.de doesn't mean you want to trust mail.ru, but it seems that you're either suggesting that the trust propagates between servers in the same federated network (obviously not the case), or that you can just demand your recipients use the server you chose, ending up with a centralized silo within the federated network, which is itself a contradiction.
Compromised apps can very much silence such warnings.
> If you assume the clients are compromised, E2EE or federation or other network properties won't help, so this discussion is meaningless.
Federation absolutely helps. If you get your service and your (preferably open-source) software from different sources, the chances that you'll be attacked via software backdoors is significantly reduced, especially when there are many competing apps. If you run the server yourself, the chance to be compromised becomes infinitely small.
Again, this is not a useful take since this equally applies to any other app, federated or not.
> If you get your service and your (preferably open-source) software from different sources, the chances that you'll be attacked via software backdoors is significantly reduced
No, you just need one of the trusted component to be compromised to lose your security guarantees. You're suggesting to increase your attack surface instead of reducing it.
Wrong. If your client software and service come from different vendors, it is by far harder to attack your privacy via compromised apps - especially if there are multiple vendors of client software and reputable open source repositories like f-droid who build apps from sources.
> No, you just need one of the trusted component to be compromised to lose your security guarantees
While this looks to be true, in real world practice it is completely not so. It is far harder sneaking a backdoor into a F-droid app, with far bigger reputation risks, than doing it in Signal app - especially if the attacker knows which account should be affected. And in a federated environment the attacker might not even know your account name.
> It is far harder sneaking a backdoor into a F-droid app, with far bigger reputation risks, than doing it in Signal app
We'll have to agree to disagree.
Signal is a perfectly good protection against passive attackers. MITMing a non negligible portion of Signal users would be too visible to be worth doing. This doesn't solve target surveillance (but key fingerprint checks help there), but this does ensure that most of the data exchanged via Signal services does not feed NSA databases.
> If you don't trust your service provider not to spy on you, you must not trust it completely.
Ideally you wouldn't trust anything nor anyone, that's the Mossad thread model and it's not useful to judge incremental improvements.
> Don't want to be spied by your service provider - run you own server. That's what federation is for.
A server running where? Most "servers" are rented from a big cloud provider, and there's no physical control over it. Having to trust these is definitely worse in terms of security. This is also forgetting the users Signal is targeting, who are not technical users, but precisely people who don't know what a server is.
You are not trusting Signal to have your unencrypted chats. Why do you trust their client apps? You aren't building them yourselves, right? MitMing ALL users and just showing them matching fingerprints so they feel safe is pretty plausible, since all users communicate using one central server. Of course, this MitMing is best perpetrated by Signal themselves.
> A server running where? Most "servers" are rented from a big cloud provider, and there's no physical control over it.
If you are a criminal, somewhere in TOR. If you are a legal organization, in your server room. If you are neither, nobody freaking cares about your chats and you might as well keep them unencrypted, enjoying better portability and overall improved user experience, as proven by Telegram.
Because it's open-source, has been reviewed extensively, and people (with various degrees of expertise) keep looking at it.
> You aren't building them yourselves, right?
It builds reproducibly on Android, so this doesn't matter.
> If you are neither, nobody freaking cares about your chats
That's not what the Snowden leaks showed, nor what scandals about e.g. some $BIG_CORP employees stalking their acquaintances via their privileged accesses demonstrated. E2EE on Signal means I don't have to trust that some employees won't abuse their rights to access my data. Do you even know how many people could access your Telegram chats if they wanted to? Just look up "stalker facebook employee", this is not some theoretical scenario.
You're basically saying you and others have "nothing to hide". This argument has been repeated and debunked ad nauseam, if the whole literature against this stance hasn't convinced you yet I don't have more to convince you now.
Sooo your security is based on blind trust in some people out there who definitely do keep looking at Signal's apps, somehow verify that every shipped version of their app contain the same code as their open source repository? That's a lot of trusting.
(Wouldn't it be simpler to just trust Signal not to watch what you are texting to your significant other, and keep everything without encryption, saving yourself a lot of trouble?)
> E2EE on Signal means I don't have to trust that some employees won't abuse their rights to access my data.
So your threat model are Signal's employees who might be stalking you? You know, you could run a $2/month xmpp server that would serve you just fine, and you wouldn't have to worry about any threat of this kind. This not-working-federated-protocol is surprisingly effective in sending and receiving messages.
This doesn't hold in practice, you simply cannot trust any single entity about this, since it's bound to be abused eventually.
> You know, you could run a $2/month xmpp server that would serve you just fine, and you wouldn't have to worry about any threat of this kind.
So instead of managing my client, I need to manage both my client and a server, and trust this server on top of the client? That's obviously worse, I'm starting to think you're trolling.
For the record, Signal's servers run on US cloud providers, including AWS and Google Cloud. Signal do not have physical control over their machines either, which I believe invalidates this point about self-hosting.
On the other hand, I don't need to trust Signal's servers, by design, thanks to E2EE.
Does this use mind-reading or time travel? Which is it?
Suppose I walk across to my friend Steve's house tomorrow and I verify our Safety Numbers match. Do the Secret Police hop into their time machine and go back and cross Steve and myself [and all our contacts?] off their MITM list?
Or did they use precognition to know I was going to do it and so they were able to never intercept the affected messages in the past?
> Don't want to be spied by your service provider - run you own server. That's what federation is for.
Notice that when you do this, the Secret Police's job is suddenly trivial. Gee, I wonder who we should arrest for this conspiracy that was organised on Andrew_nenakhov's server? Let's try starting with Andrew_nenakhov. Bingo.
Job #1 if you actually don't want this sort of global surveillance effort to be successful is Don't Stand Out. If your traffic is special, if your users are different, if your service is unlike all the others - you are a target. So blend in, that means you use TLS because everybody else does, and you use Google's Play message service because everybody else does, and you use the same server for all the mundane shit that is used for the plot to kill the Secret Police chief.
Read my lips.
You do not trust the service provider. To be consistent, you do not trust the software provided by this provider. From here, the possibilities are endless. They can just show you some fingerprint numbers so you feel safe, while in practice they might be completely unrelated to the real keys. Or whatever. The keys you verify with your friend Steve might be generated on the very moment you look at them, unrelated to your prior keys that you used 'trusting' the Signal's CA.
> Job #1 if you actually don't want this sort of global surveillance effort to be successful is Don't Stand Out.
That's why just use a plain old email server in TOR network, not tied to your identity. Email blends in juuust fine, certainly much better than centralized silo Signal where your accounts are tied to your identites.
These are completely different threat models. You're saying that since you can't have bulletproof security, you might as well have none. This is simply not the case.
At least with encrypted email you are less likely to kid yourself. If you do figure it out then the existence of identities you treat as objects ("public keys") makes it intuitively obvious that you have to get the right one.
I am old enough to be pretty cynical about this stuff. People keep on coming up with purely technical solutions to the encrypted messaging problem. They all eventually fall down on the human side. This isn't working. We have to do something else.
[1] https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...
This is a post on the Signal blog. They are obsessed with E2E encryption, and will never be talked down from it.
Also, I presented several problems with email, not just poor support for encryption.
> Email can be e2e encrypted easily if you want it.
E2E encryption should have forward secrecy. The way that’s usually implemented requires “handshake” messages to be exchanged before the payload is sent anywhere, which cannot be easily retrofitted onto PGP (adding it would be less “encrypted email” and more “an entirely different communication protocol, tunneled over SMTP”). The Axolotl ratchet that Signal uses requires the key for a communication channel to change over time, which is also pretty far away from what PGP and S/MIME currently do.
> The fact is that you generally don't, because you want to access your mail from any device and you want a server-side search
Signal and WhatsApp both exist and people use them, so they obviously aren’t deal-breakers.
> Also, proper e2ee requires identity verification of your contacts, where you check their key fingerprints using an uncompromised channel
It requires you to verify the identity of one, initial contact to bootstrap your social network. From then on, the “uncompromised channel” can be the previous E2E encrypted channel you already created.
I'm not responding to a person who writes the Signal blog. I'm arguing with a silly statement 'but but email doesn't have e2ee'.
Spam problem is big, and can be solved in other federated protocol like XMPP by requirement to authenticate sender before sending a message.
> E2E encryption should have forward secrecy.
That is an arbitrary requirement imposed by you just now. For many people it absolutely SHOULD NOT have forward secrecy, and a message signed by a public trusted key would be much better.
Regarding that 'axolotl ratched', my developers have implemented it on at least 2 platforms, that protocol can absolutely be ported to email. But nobody will do it because in practice nobody really needs it, just some obsessed nerds.
> Signal and WhatsApp both exist and people use them, so they obviously aren’t deal-breakers.
... And Telegram CRUSHES them with BY FAR superior user experience precisely because they DON'T have e2ee for regular chats.
> It requires you to verify the identity of one, initial contact to bootstrap your social network.
No, this is a security theater again. If you need e2ee you should not trust someone else to do a verification work for you. Not your contacts, not a Signal's CA, nobody. Imagine you are a gangster in a sinister organization. All it would take to compromise your communications is just one mole coerced to work with the police.
And if you aren't willing to do this work because it is too burdensome, you should honestly face the fact that nobody is interested in your communications, and that your insistence on e2ee does not, in fact, increase your privacy, but just makes you feel more safe.
Curios, why? What scenarios does PFS protect you from exactly?
So first you implement an e2ee protocol with PFS, then make a hole in your security to make using it a little less inconvenient. Good job!
Matrix doesn't encode all data on the server with your current password.
Messages are encrypted through keys according to MEGOLM.
If the user chooses keys can be encrypted using a security key either generated randomly or derived from a password.
I think Signal's derision towards federated protocols should be taken with a grain of salt, but email is genuinely kind of bad on multiple axes. It's difficult to encrypt well, the network is difficult to federate with as an independent user because of anti-spam measures, there's a lot of stuff that providers have kind of stapled on top of it to get around the problem of embedding remote images/resources, message verification, etc... there's just so much duck-taping over problems with the protocol.
> If you skip this part, all e2ee you use is just a security theater.
No, not at all. It's better if you take that step, but skipping it doesn't necessarily mean there are no benefits elsewhere. Proper E2EE does require verification, however, proper E2EE implementations only require additional verification for new devices, movement, etc... verifying something once, even verifying poorly once, is still a lot more secure than verifying it multiple times in a row.
We can get into big debates about the technical side of E2EE, but the short version of that debate is that if E2EE didn't matter, attackers wouldn't be making as much of a big deal about it. This is a good general metric to use when thinking about privacy measures, whether that's sandboxing improvements in iOS, or DNS over HTTPS, or ESNI, or E2EE. If the primary attackers are freaking out about it, there's probably a reason for that. And all of them are freaking out over E2EE so unless you think this is some kind of giant coordinated conspiracy, probably the reason they're freaking out about it is because E2EE does make it harder to monitor people.
If there were a standard for strictly formatted "introductions", which were the only type of message you could send someone unless you were in their address book (and had confirmed public keys out of band?), then spam probably wouldn't be profitable enough to exist.
The drawbacks for p2p and centralized systems seem to be mostly inherent to the technical requirements necessary for things to function.
The downsides of federation are more practical (who/how deploys and maintains the servers). Good reminder that organizational structures like technical "communes" need more emphasis!
Yes, federation makes all of this stuff harder. Of course it does. There are problems you have to solve in federated systems that you don't have to solve in centralized systems. And it used to be easy to point at platforms like Matrix/Element and say that they were still struggling to get encrypted chat turned on by default, and that was proof that federation didn't work.
But in the years since this article was written things have started to change. And now the interesting stuff going on with Matrix isn't E2EE chat, it's P2P encrypted chat, it's using Matrix as a drop-in securely encrypted data-transfer for web apps. It's all of the innovation on how metadata gets encrypted that Moxie claimed was going to come out of centralized platforms, and never did. Meanwhile, Signal is still trying really hard to decide whether or not usernames should exist.
It seems clear to me that federation isn't the entire picture, because the federated apps I'm paying attention to are seeing more active development and iteration on user-facing privacy features than Signal is.
Separately, I think Moxie's argument that switching costs between networks aren't an issue has not aged well. And I also think Signal itself demonstrates this point; there's a reason why Signal falls back to relying on one of the most insecure messaging protocols in existence, and there's a reason why Signal makes privacy concessions like tying itself to phone numbers and announcing to you when other contacts join Signal. It does that because actually switching costs are very high, and even Signal can't get people off of SMS unless it maintains compatibility with that network. Even Signal as a centralized platform hasn't been able to get people to switch off of literally the worst messaging service we have today on almost every technical level.
So my main criticism of Moxie's take is that I see federated systems that are overcoming some of the problems he talks about, and I don't see Signal innovating in that space to the same degree (not that they're doing nothing, just that they're not doing nearly as much). And my secondary criticism is that I think he's dismissive of some of the downsides that come from centralization, including downsides that have hurt Signal's adoption rate among ordinary users.
The main reason I like Signal so much is that it is highly audited by security professionals that I trust, that it's been around for a while and proven that it is secure, because it is a small app with less attack surface, because it's seamless on top of SMS, and because I think Moxie is a good, trustworthy coder with solid moral principles about privacy (part of why I'm disappointed to see him leave the company).
And all of that is still true today, but since this article was written I haven't seen the level of supposed innovation that I was told was going to happen. It's the federated platforms doing the exciting stuff, and meanwhile Signal is good because it doesn't change much and it still just kind of reliably works the same way it always used to. It's ironically almost the opposite of the situation Moxie claimed was going to exist.
I'm pretty sure it didn't have all the badges and other tat I don't use but which I'm sure somebody say 30 years younger would care about and I believe is on the popular chat apps
It had secret groups back then, but they had to be kept small, whereas today much larger (unlimited?) group sizes are available thanks to changes in the protocol to facilitate that.
It had secure phone calls, but I don't know if it had video calling and certainly not group video calling as it does today.
As I understand it (I don't buy Apple devices) they also delivered the seamless encrypted upgrade behaviour where you buy a new iPhone and transfer everything securely.
I'm sure there's a bunch more.
by only looking at the message...
but: you authenticate yourself at the Signal service and you use your authentication to drop of a set of messages
How do they not know who sent them (if they want to know)?
And how do you get it?
> Signal doesn't learn who sent it nor do they care, the recipient's client figures out who sent it after decrypting it.
which doesn't mean they couldn't
First message without sealed sender from A to B: Signal knows the recipient. This messages includes a token that A wants to receive B’s messages with sealed sender, that is, a payload signed with A’s private key
B accepts message and also sends back proof that it wants to received further messages from A with sealed sender (again something signed by B). This message can be sent via sealed sender as well because B now has A’s token
Signal Server only allows sealed sender if token is valid (i.e. is signed by the recipient)
In the first message Signal knows the sender. Signal always knows the recipient (otherwise it couldn’t deliver). From then on Signal doesn’t know the senders because of Sealed Sender.
Also: “a token that A wants” should have been “a token indicating that A wants”
It's just that the list you're bringing up is dwarfed by the list of improvements that have happened in protocols like Matrix and chat apps like Element over that same time period. I don't think anyone would claim that Signal right now is evolving faster than the rest of the messaging market -- or maybe I'm wrong and people want to try and make that claim?
Make a protocol. Make a server for it. As the central authority updates the protocol, they update the official server software. If someone installs it, it auto updates by default. If someone runs an alternative server software, or doesn’t update, then they will be broken by everyone else’s updates, and that’s just too bad for them. Keep up, or get left behind.
If you all are forced to use the same server software, it's not federation, it's just a distributed app.
What if somebody decides to clone the software, and manages to keep up?
Who pays for the center, and keeps it running, if you have no access to users?
I want any government to help the community set rules, and provide transparency. As opposed to encouraging or implementing mono/oligopolies.
One way of using an acceptance test could be to centrally name and shame/fame the various implementations. (Like caniuse.com for web tech.)
It's good when the clock strikes 13 in the very title of an article; saves time :-/
Edit: I originally claimed there was no previous HN discussion, but it was on a different URL.
also in talk form some years later: https://news.ycombinator.com/item?id=21904041
Everyone loves to rag on signal here it seems. They would rather something be correct in ideals than help the largest amount of people. It’s a strange and holier than thou stance to take in my opinion.
So I don't think "it's impossible to make a non-shitty federated client" is really a valid argument. That's not to dispute real problems with wide-open federation or XMPP, because they absolutely exist, just that "the clients are hard to use" seems more an artifact of the resources of the people making them than anything to do with technical merit.
Perhaps not, but it's definitely a strawman.
I imagine federated chat means more opportunities for your users to avoid seeing ads too... Just use someone else's server!
I want federation to work. But this is a fair critique of the tradeoff and competition between centralized and federated services - and the dynamics of network switching instead of host switching.
The protocols “work” just fine. It’s making money that seems to require centralization, even by his own examples. And if the making-money part doesn’t happen, the commercialized/centralized service goes away. But guess what keeps running. The open federated protocols.
I made this point in another thread. The point of openness and federation is not to prevent failure, but rather to facilitate continuity when central/commercial interests … lose interest.
Besides. Try building Signal /without/ using IPv4, or HTTP, or email, or git. And then maybe /thank/ federated protocols for making this little blog post even possible.
Extremely underrated point.
The problem is more a prisoner's dilemma w/r/t monetization than some intrinsic problem with federation.
Signal is a non-profit entity.[1] E.g. Billionaire Brian Acton "donated" (aka 50-year loan at 0%) about $105 million to keep Signal running. If Signal has a monetizing agenda, they're going about it in a convoluted way.
[1] https://twitter.com/chrisjbakke/status/1348319406028296192
EDIT to reply: >, and from what i've read, Signal does monetize.
In precise terms, how exactly does Signal monetize? Every source I found says they're still running on donations: https://www.google.com/search?q=signal+technology+monetize+m...
It's worth calling this out specifically so I can evaluate gp (jmbwell) accusations of Marlinspike's motives to write the essay for commercial gain rather than outline the technical pros/cons of federation.
This means Signal has an obligation to come up with $105 million somehow. So, at the least, they can monetize $105 million worth, and still be a non-profit. More likely, they need to monetize $2 million/year for that loan, plus however many $million/year to pay salaries, etc. just to break even and be "non-profit." When you pay a single developer $200K/year + $20K/year health insurance + $5K/year food, it's pretty easy to be a non-profit even when you are trying to be high-profit.
You're entitled to your opinion, but I don't think you'll convince many people with this.
> "I no longer believe that it is possible to build a competitive federated messenger at all"
Personally I think the new titles stays pretty close to the thesis statement, but it might be a bit exaggerated as clearly Marlinspike doesn't mean "technically impossible" but rather something more like "socially unworkable".
It's not up to the submitter of an article on Hacker News to decide that an article's title "conveys naught", and then make up their own purportedly better title. Threads are sensitive to initial conditions, and submitters don't have a privilege to set those conditions. This is black-letter HN guidelines stuff; the title here is an abuse.
> The protocols “work” just fine. It’s making money that seems to require centralization, even by his own examples.
Why would you say that? I skimmed it, and he wrote very little about money at all, and a lot about the stagnation that federated protocols experience, e.g.:
> I thought about it. We got to the first production version of IP, and have been trying for the past 20 years to switch to a second production version of IP with limited success. We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s. To answer his question, that’s how far the internet got. It got to the late 90s.
> That has taken us pretty far, but it’s undeniable that once you federate your protocol, it becomes very difficult to make changes. And right now, at the application level, things that stand still don’t fare very well in a world where the ecosystem is moving.
It's true: the federated protocol that is email doesn't actually have encryption, even though people have been talking about it for decades. The need to be interoperable with lowest common denominator means that even Phil Zimmerman finds it too troublesome to receive anything that's not unencrypted. A platform like WhatsApp added it in like a year or two.
Federation seems like it more for an end state where things are stable and well-understood enough that it's tolerable that the implementations stagnate.
EDIT: Not sure why I am downvoted, editing is against the site guidelines: https://news.ycombinator.com/newsguidelines.html
This particular title also feels extremely clickbaity.