That response is basically "nothing he said is strictly speaking wrong, but we value freedom above everything else." Well, they're allowed to take that position, but I prioritize being able to use a free / open source messaging application with as many people as possible over being able to choose exactly which federated client I can use to talk to the two people I know who go to PGP key exchange parties. Sometimes I want to make a video call with two other people on my phone without using software written by Google, Apple or Facebook. Signal does that. I don't even know how feasible that is with Matrix.
That isn't an accurate summary, because he's refuting a number of the points. fake "we" to summarize, I'm not affiliated:
* 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)
The "freedom" vibe was weird. I'm all for freedom and maximizing negative rights, but there's some compromises we have to make. I don't think this argument is ever going to work, just like it hasn't worked in politics. At the end of the day people do realize there are some compromises that make sense. It's about finding that ground where we maximize negative rights while still having those conveniences.
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."
> I also found it strange they ignored one of the largest arguments that Moxie made.
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.
> I also found it strange they ignored one of the largest arguments that Moxie made. Federation becomes centralization.
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.
Your city analogy exposes the defects of this argument. As noted, federation does not prevent centralization. And there is no reason to fight against centralization. It's ok for NYC to contain 1/2 the population of the state. What your argument seems to gloss over is that in _only_ contains 1/2. Nobody is forced to live there. They can go upstate, or to any other part of the state. People who want to can live in NYC and still be part of the entire state, enjoying all the benefits. People can live in the state capital, or Buffalo, or the best part of New York: Stamford.
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.
I think you're giving my comment an unfair characterization. I'd appreciate it if we discussed in good faith with one another. If you read carefully I talk about trying to maximize negative rights and a balance. The political equivalent is saying that I like democracy but a pure democracy is chaos. This does not mean I'm remotely in favor of autocracy. There's a spectrum here and it isn't a dichotomy.
Of course you can say it about democracy. The basis for democracy as we know it is the modern nation state, a fundamentally centralized institution. Democracy without a high degree of centralization tends to decay. Even the dictator in its original sense as an institution acts on behalf of the people, appointed during times of exception. (many presidents in presidential republics today actually have comparable emergency powers).
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).
I would say it's Marlinspike's position that has aged badly.
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".
Your "freedom" has in fact nothing to do with the project Signal is working on, and the fact that you want to sysadmin your phone, something only a tiny fraction of the world's population has or ever will have any interest in doing, has nothing to do with whether Signal is meeting its objectives. By all means, use Matrix.
I don't want to sysadmin my phone, I just want to remove Google from my threat model. That means I'd like everyone to be able to buy phones which come pre-installed with F-Droid as an alternative app store, so people get the benefit of reproducible builds of free software apps (ideally with binary transparency, and verifiers in multiple jurisdictions).
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]
This is an issue from 2016, it's 2022 now and Signal works perfectly fine without Google Play Services. The .apk is there if you don't want to use Google Play Store: https://signal.org/android/apk/ and it prompts for updates when they're available.
Thank you for adding that context, which I should have included in my comment.
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:
> 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).
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.
> There are explanations about their stances regarding F-Droid etc. if you're willing to look for them.
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).
It would matter a great deal if Signal allowed other people's forks to connect to their network, because they would lose the ability to deploy new privacy features. The whole point of Signal is that it consistently makes tradeoffs in favor of privacy and against UX. An "open" Signal network would immediately be dominated by clients making the opposite tradeoff, because users value good UX far more than they value privacy.
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.
> they would lose the ability to deploy new privacy features
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.
If Signals direction was so much better they should have come a lot further since they have an easier task (and are better funded) than their main competitors (XMPP and Matrix).
Instead many feel Signal has moved in a wrong direction with crypto currency.
You're just saying that Signal's priorities don't align with those of some people, but the point of the article is that, given certain priorities, they'll be more easily fulfilled if your system is centralized, nothing else. Whether these priorities are the "right" ones is orthogonal to the debate about decentralized vs federated architures.
This doesn't seem all the controversial or even interesting to me. It is perfectly true that a standalone project is easier than one where you have to communicate and negotiate a specification with other people. The idea here was to showcase an approach to cryptography. The Signal project has done a good job of that. It is up to us to decide if we want to modify any of the existing systems based on those ideas.
Moxie was explaining why he was doing what he was doing. I doubt it was ever intended as some sort of manifesto.
Hey, once again: you can't editorialize titles like this on HN. The title of this post --- and it's an extremely well-known post at this point --- is "Reflections: The Ecosystem Is Moving".
>> but it’s undeniable that once you federate your protocol, it becomes very difficult to make changes.
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.
Moxie also talks about this dynamic in his critique of NFTs. The logic kinda goes like this: (Step One) People create Federated Services to establish fault tolerant internet infrastructure which more-or-less works. (Step Two) People then build agile Centralized Services which give users exactly what they want. (Step 3) People then attempt to build new, robust Federated Services in an attempt to copy the good features of the Centralized Services.
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.
He is arguing that decentralized systems are incapable of keeping up with the times due to inability to herd the cats.
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 like your optimism but even in centrally managed systems people won't upgrade.
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
Counterpoint, basically everyone who runs them runs up-to-date Chrome and iOS. This is more an argument that some centralized systems are poorly (or perhaps weakly?) managed.
Could you not copy their alerts and use DNS aliases and/or load-balancing to migrate them?
We're trying to slowly reduce the amount of technical debt we've built up. It's not a naive copy and paste for us, since it's possible they've done silly things, but for teams they will understand what the alerts are for.
That said, I've had teams forget they had alerts at all or outright deny they owned alerts on their service.
I don't understand your point. In some alternate reality, there could be some IPv4 internet that was centrally managed and contained like 3 routers and 20 total nodes?
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 subject line doesn't seem to match with the the post it links to - perhaps it's been updated since being shared here? The blog post right now is titled 'the ecosystem is moving', and in the first paragraph states:
"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.
You can use it for communication, and it remains popular by first-mover advantage, so I suppose it “works” technically. But almost everyone is on a few, huge servers that can dictate the standards to everyone else, it’s not E2E encrypted and the few attempts to add E2E encryption are unusable, the anti-spam systems are so strict and flakey that it’s a crapshoot if any email actually arrives in someone’s inbox, and routing emails is based on domain names, which are a terrible way to manage data portability.
In other words, it didn’t accomplish what any pro-Federation activist actually wants to accomplish.
Oh again this obsession with e2ee!! Email can be e2e encrypted easily if you want it.
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.
> Email can be e2e encrypted easily if you want it.
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.
> For casual users, Signal is a good protection against dragnet surveillance.
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.
No, not really. There are actually ways to go around that. One person who does verify a fingerprint will get a real fingerprint. Or maybe they'll just show you same numbers as to your buddy, because they control both server and client software and users have very very limited resources to control what code is shipped to them via appstores.
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
> One person who does verify a fingerprint will get a real fingerprint. Or maybe they'll just show you same numbers as to your buddy, because they control both server and client software and users have very very limited resources to control what code is shipped to them via appstores.
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.
> The fingerprint is computed at key exchange, you can't change it after the fact without warnings about it.
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.
> Compromised apps can very much silence such warnings.
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.
> this equally applies to any other app, federated or not.
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.
Whether the protocol is federated or not (which is the topic of the article) doesn't say anything about the clients and how they're distributed. Even with respect to Signal, which is open-source, can be rebuilt from source and has several clients, including 3rd-party ones.
> It is far harder sneaking a backdoor into a F-droid app, with far bigger reputation risks, than doing it in Signal app
> (those who do indeed verify fingerprints are excluded from this program)
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.
> Does this use mind-reading or time travel? Which is it?
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.
> You do not trust the service provider. To be consistent, you do not trust the software provided by this provider.
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.
You made a claim ("those who do indeed verify fingerprints are excluded from this program") and "read my lips" doesn't substantiate it. Your claim was in fact just nonsense.
I was just listing the possibilities, which your paranoia about being spied upon somehow doesn't account for. You have no means to really verify if your communications are being compromised, so you just trust Signal. But at the same time you don't trust Signal and use e2ee. That's schizophrenia.
> It is not a protection, just a security theater.
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.
> MITMing a non negligible portion of Signal users would be too visible to be worth doing.
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.
> Because it's open-source, has been reviewed extensively, and people (with various degrees of expertise) keep looking at it.
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.
> Wouldn't it be simpler to just trust Signal not to watch what you are texting to your significant other
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.
> 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.
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.
Well that means that, Signal (and other instant encrypted messengers) bundle the risk up into one huge footgun. Very few people know how to verify their identities with the "safety numbers" and then keep them verified. As a result, you end up trusting the provider not to MITM your messages. This is particularly trivial to do in, say, some sort of non-federated system where one entity controls the entire infrastructure. That is not necessarily a bad thing but it would be good if the user was made to understand exactly who they are trusting. Signal deemphasizes this sort of information these days and has made the warnings about changed safety numbers easier to ignore. This is a depressingly common progression.
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 think you're saying that Signal is not perfect, and I agree, but there's just nothing better at the moment. Email encryption is a bad reference because it has negligible usage (in comparison with modern messengers) and has proved over the years that it cannot cater to the needs of Signal's current users. But even then, I don't think we can claim that getting the email encryption setup right is any easier than ensuring one hasn't been MITMed during the initial key exchange on Signal.
In terms of usability, Signal is not that great. In a usability study involving Signal[1], 21 out of 28 computer science students failed to establish and maintain a secure end to end encrypted connection.
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.
This is a never-ending debate, but you really shouldn't be doing E2EE for emails, and you really shouldn't be using it as a backbone for encrypted chat. There are just too many foot-guns. Other people more qualified than me can have that debate if they want, but that's the consensus I see from security people that I respect, and I think there reasoning is sound.
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.
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.
Any scenario where the keys are now in unfriendly hands, without PFS they now get to read any previous data encrypted with those keys, for example because they've snooped the encrypted data and been keeping it for just such an opportunity.
just a day or two ago some Matrix fan here proudly told me how great e2ee is implemented in matrix that they encode all data on a server with your current password.
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!
> just a day or two ago some Matrix fan here proudly told me how great e2ee is implemented in matrix that they encode all data on a server with your current password.
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'm not talking end to end encryption, but server-to-server encryption. STARTTLS is still vulnerable to downgrade attacks, as 9% of outgoing mail from Gmail servers still ends up being sent unencrypted. https://transparencyreport.google.com/safer-email/overview?h...
I think email only proved the need for strong moderation in the case where the expectation is that you can send any message to anyone with only knowing their address.
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!
I think my main criticism of this article is that Signal today isn't proving that this is true.
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.
When I first installed Signal it didn't have Sealed Sender, which means that an adversary in Signal's privileged position knows who is sending me messages (today only I know who is sending me messages)
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.
Oh of course! I didn't meant to imply that nothing at all has happened, Signal has seen development.
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?
> When I first installed Signal it didn't have Sealed Sender, which means that an adversary in Signal's privileged position knows who is sending me messages (today only I know who is sending me messages)
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)?
You don't need to identify yourself to Signal in order to send messages with Sealed Sender. You just present a delivery token, which proves you are authorised to send messages to this recipient, and your encrypted message addressed to the recipient. Signal doesn't learn who sent it nor do they care, the recipient's client figures out who sent it after decrypting it.
> You just present a delivery token, which proves you are authorised to send messages to this recipient, and your encrypted message addressed to the recipient.
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.
I don’t know Signal internals but it could work like this:
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)
E: Just realised I have made a mistake when typing, sorry.
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”
What if you allowed federation, but you centralize updates?
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.
I like that Matrix has a separate system/acceptance test that any implementation can run against to check compatibility: https://github.com/matrix-org/sytest
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 clear you took the time to comment, but didn’t take the time to click the link and commented purely on the HN title which is different than the articles title and point.
This needs 2016 in the title. Signal can spin stories about why federated protocols don’t work, but the simple explanation behind this is Signal doesn’t want to do certain things. Signal’s unwillingness to avoid doing certain things shouldn’t construed as “hard to do” or “not worth doing” or “too much hassle”. Take every position that Signal takes with a pinch of salt. It is, after all, a centralized platform that benefits from centralization.
You managed to not address any point in the article, instead insinuating poor motives by the author.
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.
yep. for better or worse (it is security-wise), a federated platform has taken over way more of my chatting than Signal ever reached, and Signals insistence on "we know what client people want" plays a large part in that.
I have yet to see a federated chat app my tech illiterate family can download and use. Sure I have set some up to test out but the UX is terrible on all of them. Matrix was the most polished but still horrible compared to signal.
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.
I mean, there was a while there where XMPP-based and federated chat clients (particularly google chat, along with early facebook messenger) were becoming dominant, and were widely used by "normal people" without even knowing it was a thing.
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.
I wonder if some of what went wrong with XMPP was the big platforms (Facebook, Gmail) adopting it, then dropping it. Coupled with the rise of smartphones and the cloud. Previously you ran your chat app on a desktop PC and it stored your chat history/etc.
I imagine federated chat means more opportunities for your users to avoid seeing ads too... Just use someone else's server!
Were things like Google Chat and Facebook chat actually federated, or did they just allow for XMPP clients to authenticate and have some marginal functionality of the platform? If I was a member on some XMPP server, could I send a message to either platform without having a Google or Facebook account?
Please make actual arguments, and not just Bulverism. After all, building a centralized system and an organization that can run it is the behavior you would expect from someone who sincerely thought it was a better way to make a messenger.
He writes “don’t work” but he seems to mean “aren’t easy to monetize.”
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.
> 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.
> He writes “don’t work” but he seems to mean “aren’t easy to monetize.”
> 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.
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.
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.
A donation and a loan are not the same thing. Even for a 0% loan.
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.
Moxie jumped the shark when he started arguing for reliance on Google Play for better end-user security. He's just got a completely different threat model that focuses on getting users the first 90% by forgoing the last 10%. I personally am less concerned about drive by attackers (oh no, I might have to change my credit card number one additional time), and more concerned about APTs (advanced persistent threats) like Google.
The reason you're even making this argument is that the person who submitted this story altered the starting conditions of the thread by substituting an editorialized title for the author's own, and in that sense you're arguing not with Moxie Marlinspike, but with the submitter.
The original title was a bland thing conveying naught but the thin idea that the world changes. A better objection is that the submitted title does not accurately reflect what is clearly Marlinspikes thesis statement:
> "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".
The corruption imposed by the false title is clear from the comment I responded to, which is premised on the idea that Moxie Marlinspike opposes all federated protocols (including, as the comment asserts, HTTP), when in fact his concern is with the project of deploying very specifically a secure messenger.
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 centralized part will eventually fail, the federated will live on.
You could have argued that RSS got centralized with Google Reader, but Google Reader died and RSS feeds are still alive.
https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom