With XMPP and federated messaging servers they would have at least working infrastructure within their country.
But ...
What exactly happened that XMPP lost on mobile phones? What did they do wrong? XMPP was there before smartphones came, had working clients, and had (for that time) pretty decent encryption.
While I understand that big players like WhatsApp want to bind all users to their own infrastructure, I don't understand why even the niche instant messangers go through the burden of creating their own infrastructure (or relying on Google's) instead of just concentrating on the client side to provide better XMPP clients.
Is XMPP so bad that nobody wants to do that? If so, why?
XMPP used to have power consumption issues on mobile because of the constant TCP connection from the client to the server. There were also problems with network disconnections/changes on mobile for the same reason. XMPP uses TLS certificates for client to client and server to server connections and such things used to be a pain before Let's Encrypt for those hoping to run their own servers. The end to end encryption used to be OTR which tended to be a bit clunky to use in practice.
That was then. Those issues have been more or less fixed these days. XMPP is actually starting to look interesting again. For an example of a modern XMPP client (and discussion about the issues mentioned above) see here:
They only want money for providing the build. The source code and build scripts are free/libre.
From the website:
How do I install Conversations?
Conversations is entirely open source and licensed under GPLv3. So if you are
a software developer, you can check out the sources from GitHub and use gradle
to build your APK file.
The more convenient way — which not only gives you automatic updates but also
supports the further development of Conversations — is to buy the App in the
Google Play Store.
Buying the App from the Play Store will also give you access to our beta test.
XMPP _was_ bad on mobiles. The biggest issues were
a) it was overly chatty (i.e. constantly sending/receiving information, draining your battery)
and arguably worse
b) it wasn't designed for changing addresses (wifi->data and back) or constant loss of connectivity.
So if you used XMPP some years ago you'd kill your mobile, fast, and would constantly lose messages.
Other features of modern IM solutions (say, an archive of your messages?) weren't present or usable either.
Today? Most of these issues are resolved. Prosody is a great server to get started (again) and comes with solutions for most (all? MAM aka 'Message Archive' is still somewhat scary imo) problems I mentioned above. Conversation is a very nice and modern XMPP client.
TL/DR: XMPP was 'bad' for mobile deployment for a long time and probably lost too much traction because of that. XMPP isn't bad in that respect anymore.
From what I've read, yes, XMPP is bad. But that's not the problem. Keeping a persistent connection to your server, while not keeping the phone processor and/or radio active, and while not being dropped by the phone company's NAT after a very short timeout, is not a simple problem. The native persistent connection (Google's, for Android, and Apple's for an iPhone) is the only one which is guaranteed to work good enough.
Federation has the problem of being harder to prevent abuse. And for systems that use the phone number as the user's identifier, like WhatsApp or Signal, it's even harder: which server is associated to an user? What to do if the user registers to more than one server? How to prevent a server from saying it has registered a user, when the user didn't do it?
And when you control the whole infrastructure, it's easier to provide a good user experience. With federation, you are depending on the quality of other's implementations.
> Federation has the problem of being harder to prevent abuse.
Precisely XMPP have already solutions for this problem
> And when you control the whole infrastructure, it's easier to provide a good user experience. With federation, you are depending on the quality of other's implementations.
So basically if you are an expert. Find/install a XMPP client, then register/buy/install an XMPP server. Oh you probably want some SRV DNS entries as well. Then ensure your client and server support and have enabled XEP-0198, XEP-0313, XEP-0352, XEP-0280, XEP-0363, XEP-0374, XEP-0357 then in theory you can have a reasonable user experience.
However in reality opening a TCP connection to a server will silently drop and all the discussed behavior depends on the cellular provider sending an RST packet back when that happens.... which often doesn't.
So because google negotiates with carriers to not time out GCM connections those don't time out. Unfortunately other connections do, thus the power efficiency of other push based approaches on android.
Federation has the problem of being harder to prevent abuse.
But this is also an issue with centralized systems (see Facebook, Twitter right now).
And for systems that use the phone number as the user's identifier, like WhatsApp or Signal, it's even harder: which server is associated to an user? What to do if the user registers to more than one server? How to prevent a server from saying it has registered a user, when the user didn't do it?
This is "hard", but solved. Bitcoin and similar systems do this (prove identity) very well already.
And when you control the whole infrastructure, it's easier to provide a good user experience. With federation, you are depending on the quality of other's implementations.
Google doesn't control email, gmail is still a pretty good experience. Controlling the infrastructure should lead to better quality and experience, but practically often doesn't. Does anyone love iTunes?
> With XMPP and federated messaging servers they would have at least working infrastructure within their country.
Why do you think this is true? I can't see how federation is an answer to censorship. They would simply censor access to all the XMPP providers, just as they're censoring access to all the non-federated messengers.
Is your idea that people would spin up new providers so quickly that the censors wouldn't be able to keep up? Every time people switched, they'd have to rediscover their entire social network all over again, and there's an asymmetry between how difficult it is to get everyone over to different hosts while rediscovering where everyone is vs how easy it is for the censors to add a single line to their block list.
It'd be way easier just to have a centralized host and have people switch VPN providers as they get blocked, since then they don't have to rediscover each-other, but that isn't a great user experience either.
Just like with metadata hiding, really effective censorship circumvention is going to require new protocols and new techniques, so we're going to be more likely to see those emerge in centralized rather than federated systems (that are by their nature difficult to update). I think we'll be able to respond in Signal very quickly.
> They would simply censor access to all the XMPP providers
First we already know this situation with email, and we see that as a federate protocol email is not censorable. At least not as easy to censor as Signal is.
Secondly it's not possible because their is not a finish list of providers. By the way 1) everybody should-could be its own provider 2) everybody must use its own domain name DNS to make addresses like greeting@name.
> Secondly it's not possible because their is not a finish list of providers. By the way 1) everybody should-could be its own provider 2) everybody must use its own domain name DNS to make addresses like greeting@name.
Just to be clear, this is never going to happen. We do not live in a world where computers are for "computer people" anymore. I've been running my own mail server since 1995, and I would not wish it on anyone.
Running my own mail server has not helped me with:
1) Metadata protection. Every email that I send or receive either has Google or Yahoo on the other end of it. Running my own mail server does not help me "own" my data at all.
2) Data protection. Federated protocols can almost never change (look at the history of IRC, XMPP, SMTP, HTTP). Email is stuck in time, which is why emails are still not encrypted. WhatsApp, on the other hand, had the freedom to deploy e2e encryption to over a billion people very quickly.
3) Censorship circumvention. Email is very easy to identify and filter using DPI. In a world where people are only doing host-based filtering, blocking 100 or 1000 hosts is no more difficult than blocking one. Whether or not there is "a finished list," if people can discover these services, so can the censors. It is much easier for the censors to add a single line to a block list than it is for people to switch to an entirely different provider with an entirely different namespace and try to rediscover all their friends.
If your idea is that every time a host gets blocked, everyone could move to a new one and somehow rediscover their entire social network, it would be way easier just to use a centralized service and access it with different VPNs as they are successively blocked instead. That would prevent you from having to rebuild your entire social network each time, but is still a terrible UX.
And even if everyone won't selfhost one's email or XMPP service, by owning one's domain name (DNS or GNS) he-she can switch from an hosting service to an other. And by owning one's own domain name, he-she wont loose contact with his-her social network. GNS is a good decentralize solution by separating name-identifier-locator https://gnunet.org/gns
> If your idea is that every time a host gets blocked, everyone could move to a new one and somehow rediscover their entire social network, it would be way easier just to use a centralized service and access it with different VPNs as they are successively blocked instead.
This look like a joke. How many VPNs providers is there ? Won't be blocked ? The only thing you've done is post-pone the problem and save your centralize enclosing business.
With Signal and WhatsApp and other centralizes and enclosing social network precisely you have to rebuild your entire social network when the service go bankrupt / go wrong way or don't evolved / is compromize by intelligence agencies and law / is blocked.
Switching from Signal to WhatsAPP is very expansive because you need to rebuilt your social because you don't own your Internet name (DSN or GNS) nor a conversation address with the semantic greeting@name.
1) actuality this is not true and even if it was it could evolve. A google-centric world is not the end of history.
2) XMPP is an evolution of email and it solve many metadata and data protection problems. Conversations is a good modern solution https://conversations.im With Snowden revelations and the GAFAM domination many people do hard work to solve those problems, for example the IETF. It looks like you don't want to solve those problems because you want Signal to become a S for GAFAMS.
3) "blocking 100 or 1000 hosts is no more difficult than blocking one." Yes it is more difficult because censors have to discover all these hosts. They don't already now them. Big centralize and enclose social networks as Signal, Facebook or Gmail addresses with semantic user@host are gifts to censors and Intelligence agencies. We've saw it with Prism.
Finally is there perfect technical solutions for political problems ? No, no one is perfect, no one can solved political problems. But some of them are better than other, some make more difficult to censor and spy everybody. Big centralize solutions are the worst and are not "Internet" solutions but they are 20th century "Minitel" Telco bad solutions.
> Switching from Signal to WhatsAPP is very expansive because you need to rebuilt your social [graph]
It's not and you don't, because your entire social graph is on your phone, in your address book. That's precisely the point. As the identifiers and contact lists are owned by the users and not by the messaging service providers, switching between messaging services (taking your social graph with you) is about as easy as it gets. See https://whispersystems.org/blog/contact-discovery/
They could also sensor all email providers, or try to block all SMS providers, but historically we've seen that this is much more difficult than you make it out to be. It's not a silver bullet of course, but it's evident that federated architectures are harder to kill (see eg. Egypt attempting to censor emails and SMS's a while back, or Syria before that [and probably after too])
Can you provide specific historical examples where censorship of federated protocols was difficult or impossible for technical reasons?
I can't see how there is anything technically difficult about it. To the extent that services aren't censored, it's usually either because they're not encrypted (so no reason to block them) or because they're too popular to get away with blocking.
As I said, it's not impossible, nor is it difficult for technical reasons, it's just more difficult because there's more stuff to block, and you'll never find every little server setup by a few activists to access the network. With proper encryption (or even basic TLS to the server) it also becomes difficult to do deep packet inspection (which is hard to do in the first place). The example I gave before also still stands: Look at the last time Egypt tried this. They attempted to block email and SMS temporarily and various activist groups just setup their own servers to get around it. Not every random user can do this of course, but it's important that at least some activists can.
"Various activist groups" setup their own SMS service?
If all you want is for a few hundred people to be able to communicate, you don't need a federated protocol, you just need a VPN. It is much easier to use a centralized service and access it with a VPN than to use a rotating set of hosts across successively blocked federated services. At least when the VPN gets blocked you don't have to rediscover your entire social network when you start using a new one.
True, neither architecture will ultimately solve the problem of an attacker having absolute control over the lower layer. No way around it.
Federation does has the nice property that it gives you some choice over who controls the infrastructure you use, but in this case it would mean moving to a different country.
Yes, it really is that bad. It's based on XML, which in theory would be possible to do right, but all the actually existing XML libraries insist on validating everything at the drop of a hat (probably fetching schemas over the internet) and a horifically overengineered model of namespaces where you can't do anything until you've precisely defined all your namespaces.
The vanilla XMPP standard doesn't permit a server to deliver the same message to more than one client for the same user. This is utterly wrongheaded and falls apart as soon as you start logging in from multiple devices (e.g. phone + computer, or even just two different computers). This was obviously terrible and has been obviously terrible for decades, but it seems impossible to change it. There is an extension to work around the problem, but extensions take forever to get approved and twice forever to get actually adopted in real clients.
The groupchat UX was always awful, partly because groupchats were never properly federated (they have to live on a single server) and there was no way to do groupchat history for people who didn't keep all their devices turned on all the time (other than, you guessed it, an extension that got stuck in limbo for a decade or so) but mostly just because all the clients sucked. It really isn't hard to do groupchats right: all you have to do is alert when the user is mentioned but not alert on ordinary messages to the group. But somehow everyone managed to screw it up.
XMPP was objectively terrible (or at least, all the XMPP clients were objectively terrible). Worse than AIM. But there were people who were (understandably) blind to its faults because it was open-source, and this anti-synergized with the traditional-unix luddite tradition that rejects anything other than plain text in messages, and the good old standards-first approach that brought us XHTML2.0 and CSS2.1 and a decade with no HTML standard (i.e. trying to standardize everything before any implementation, which never works - what works is allowing clients to add extensions and then standardizing what's been shown to work and become popular, a la WhatWG).
The real issue is that if you try to build an XMPP client that defines something "non-standard" you'll get torn to pieces by the OSS fans. Many of the niche instant messengers are probably running XMPP under the hood, but they don't want to expose it or support federation lest they get accused of trying to "embrace, extend, extinguish".
1) XML really isn't that bad. Honestly. It can be (and is) parsed fast, without any schemas at all. The only thing you need to define about your namespace is the URI you're using. XMPP is not SOAP.
2) Wrong. RFC 6122 explicitly permits this. XMPP was designed for multiple devices, actually, but expectations changed over the past decade. Carbons (XEP-0280) does what people want now, and is widely deployed, in real clients and servers. Getting extensions to the "Experimental" state is easy, BTW - it's trickier moving them on from there because it's trickier to change them once they're widely deployed.
3) Bizarrely, you're mostly describing the client behaviour I have on every client I use. As for federation, that's what XMPP does. It doesn't do distribution, because doing that and getting autonomy for your security domain is hard (if not impossible).
4) Saying something is "objectively terrible" when it's clearly your opinion, and then rubbishing everyone who might hold a contrary one, is pathetic. The validity of your position is not helped by the XSF working on live documents for most of the time (the "Experimental" phase). Where it differs from the WhatWG is that specs move out of that phase once they're proven, and the documents become harder to change once they're Draft or Final, reflecting how hard changing all the implementations would be. The XMPP world sees people add extensions, try them out, and then move them to standards all the time. We see that from HipChat, Conversations, and plenty of others - it's a great way to work. Other folks like to get something to Experimental first, and that way get early feedback from the community. We think the way we work is a pretty good balance between stability and dynamism.
5) Absolutely not. That "X" stands for "Extensible" (I know, it was fashionable back in the '90's), and the XML namespaces you despise (and appear not to understand) mean that you can cheerfully slap whatever data you like in and alongside the standardized stuff. Trust me, the (many) IM services based on XMPP - and if it were as bad as you claim, that'd seem a poor choice - aren't refusing to federate because the OSS fans might not like it. Quite the opposite, actually.
My mistake - it is a permitted option. Still, the standard (or at least RFC 3921) encourages servers not to - delivering to all clients is mentioned as the last MAY option, and only permitted at all if they all have the same priority (which given that clients like to do things like lower priority when you haven't been typing for a while, is very hard to achieve).
> XMPP was designed for multiple devices, actually
Be that as it may, it was a lot less usable in practice than any of the alternatives when used from multiple devices.
> Carbons (XEP-0280) does what people want now
Yeah, that's the extension I was talking about. Dated 2010 but I could swear I remember it being discussed in 2008 or earlier? Looks like it may, perhaps, have finally been standardized in 2015? Of course it's still an extension so you can't rely on any given implementation supporting it, though if you're saying it's widely deployed then that's a huge improvement over what I saw a couple of years ago.
> As for federation, that's what XMPP does. It doesn't do distribution, because doing that and getting autonomy for your security domain is hard (if not impossible).
Be that as it may, it leads to very poor UX. I can have one-to-one conversations with any of my contacts as though it were a peer-to-peer messenger, but as soon as I want to have a three-way conversation we have to pick a server and a room name and .... Heaven help you if you want to add a third participant to a conversation after you've started.
RFC 3921 was superceded by RFC 6121 in 2011. You might want to update your facts before you criticize the protocol.
The message routing rules leave many things to the server implementation, adding a bit of fuzzyness, but all of this has been addressed in Carbons, and really, in the last years there was significant progress in how mobile XMPP works and feels.
as soon as I want to have a three-way conversation we have to pick a server and a room name and...
The modern mobile XMPP apps like Conversations already have a seamless 1:1 to group-chat upgrade mechanism, and people are working on writing down according specifications.
> I don't care whether XMPP is good or not, but please realize your arguments are entirely subjective
Yes and no. I mean you can argue it's a matter of taste but I don't think anyone genuinely likes (for example) having to right click and go through two levels of menu, type a name, press a button, wait for results, and double-click on the correct one, just to rejoin the groupchat they were already in, every time they lose and regain connection. The line between legitimate differences in preferences and genuinely bad design is always fuzzy, but I do think there's such a thing as objectively bad UX, and every XMPP client I ever saw had it.
> Prosody and ejabberd exist. They don't take much hacking to make them very usable - certainly quicker than writing a protocol from scratch.
I can't speak to the servers. Just to the clients.
I've never seen that happen and I used to be a fan even while it was 'Jabber' (and I still have a 'Programming Jabber' book on my shelf here, in the same section as 'Mono: A developer's notebook': For things I deeply cared about, but which lost a lot of influence over me in recent times)
That was my experience using Kopete (which was the best client I found for 1:1 chats, but the groupchat experience really sucked). In theory there was a bookmark/history feature where you could just right click and go through two levels of menu to get back to the groupchat you were just in, but it never seemed to work.
I think this comes from people attempting to roll their own low-level XMPP clients top of generic XML libraries, which is a recipe for having a bad time.
Also, people who connect Pidgin to their Gmail and think that is the pinnacle of XMPP experience, but in fact both are severely outdated.
Why do you think egypt only protects their network at the border? Just because they block signal servers at the border, doesn't mean they don't implement blocks at other places on their network.
XMPP seems a morass of optional pieces, so clients and servers implement random subsets and it makes life difficult for random users to use securely. Moxie makes a good point about and federated standard without control of client and server is going to evolve very slowly an fracture into incompatible pieces.
There's more than one way to build a federated network. XMPP follows the IETF model, with standards and code only loosely coordinated, and evolves through optional extensions. Matrix is trying something different: a versioned, more monolithic specification, with reference implementations and SDKs.
Signal's approach has its share of problems, too. It took OWS two years from the start of iOS development to deliver voice and text support. (They may not have been working on it the whole time, but that just underscores the problem.) The iOS app doesn't support rotation. Desktop support was a long time coming, and the multi-device experience still kind of sucks.
It's great that WhatsApp could push end-to-end encryption to a billion users at once. But none of my friends who care about end-to-end encryption trust Facebook, and Signal isn't winning over the others.
"Just think about how the web and Internet evolved"
What percent of DNS lookups use DNSSEC?
What percent of email is e2e encrypted?
What percent of NTP lookups are signed, encrypted, or trust worthy?
What percent of HTTPS traffic would not die by a trivial downgrade attack?
What XMPP client allows you to click on it in the apple/google play store, auto discover any contacts using it, and start chatting (with e2e) in 30 seconds?
Are things getting better? Certainly, it's rather slow progress though. I don't see how signal could have gotten as far as has, as quickly as it has, without controlling both server and client, and skipping federated.
Sure, by leading by example hopefully the bar is raised. All the signal compromises (controlling client and server, non federating, using GCM, requiring a sim, etc) seem to be well justified to get pretty good security to a large number of diverse people quickly.
Sure federated would be great, as would be independence from the whisper systems servers which can be easily blocked (like in egypt).
So sure hopefully someone comes up with something that manages the strengths of signals with federation and censor resistance. Not sure that will look much like XMPP though.
I think part of it is that XMPP dates back to the late 90s, when we thought XML was a good thing (not realising that it is, in fact, a kind of information technology antimatter, which annihilates anything it touches, leaving nothing but bugs and hurt feelings behind).
The protocol in action feels crufty, and the massive number of optional extensions means that you're never quite certain if your client, your server, your correspondent's server and your correspondent's client will all play ball.
Then you toss in the fact that all the big players have decided that walled gardens are just awesome, and the fact that no-one today would touch anything using XML with a 1,024-foot pole — and thus there's just no ecosystem for it anymore.
(as an aside, I believe that in a century our children will consider the digression to XML & JavaScript to be as inexplicable as we do China's decision to scuttle its fleet of exploration)
Federated services don't allow companies to lock you into wallen gardens.
The big tech companies don't know how to make money without walled gardens (Thiel's book more or less makes this gospel without actually saying it)...hence, XMPP lost.
You can go look at XMPP or any other protocol and yeah it has issues, but no more than any other protocol, and none that couldn't be fixed.
But it's not obvious to find a working business model worth billions out of that, so companies that have to make billions don't want that. And of course government only cares about billion dollar companies (they don't have more reliable signaling), so...the fate of the protocols. There's usually a lot of bike-shedding after the fact, but they ignore the real reasons behind failure of adoption.
There's already been multiple waves of centralization, decentralization, and so on:
In the late 90s you had ICQ, MSN, AIM, etc, by the mid 2000s those had been reversed engineered to be open, new protocols were made (XMPP) and even adopted by the new giants, then Facebook, Google, etc closed back down.
> Federated services don't allow companies to lock you into wallen gardens.
This does not explain why small (niche) players go that route, too. It seems you overlooked the second part of the question: While I understand that big players like WhatsApp want to bind all users to their own infrastructure, I don't understand why even the niche instant messangers go through the burden of creating their own infrastructure (or relying on Google's) instead of just concentrating on the client side to provide better XMPP clients.
Conversations (mentioned in a different sub-thread) is a nice example of a niche instant messenger focusing on good UX. It is not only standards-compliant, but the author is actively contributing XMPP extensions, moving forward the state of XMPP art.
I don't know much about niche messengers which are not based on XMPP, but most XMPP clients happen to be niche projects themselves, maintained by one or two persons in their spare time.
The argument usually is along the lines of: "it can't work because it didn't work".
Niche players take their cues from the crowd, too. If a bunch of people in a forum say that tech is bad and that's the dominant mindset, it's going to limit the people who give it a shot.
Comparing XMPP to WhatsApp or Signal is not a like-for-like comparison. XMPP is a just protocol. A solution also requires a hosted platform and an app.
Signal and WhatsApp each provide all three: a protocol, a hosted platform and an app.
XMPP is just a protocol. There's no business model in a protocol.
> Is XMPP so bad that nobody wants to do that? If so, why?
No it'd be great but unfortunately the things that make something technically great don't align with the business of acquiring monetizeable users (either directly or indirectly by selling the resulting social graph).
I'm convinced that the only reason we still have email is because it predates walled garden land grabs.
This discussion has been had on HN so many times, it would be difficult for me to summarize (but easy for one to search via algolia).
Signal's creator runs their own email server, but always points out that 99% of the time, they are communicating with gmail on the other side. This subverts the decentralized nature of email.
XMPP is not a mobile friendly protocol. Even the Matrix.org folks are doing XMPP compatibility, but not implementing XMPP directly. My point is, "don't align with the business of acquiring monetizeable users" is not entirely true, and there are technical reasons (not just business reasons). Everyone with an interest in this problem should be on the same page, and holding overly cynical views about the impediments isn't (IMO) conducive to creating solutions.
It doesn't have to be the mobile platform but it could be one interface of many. Having separate XMPP servers acting as the middle men forwarding messages to each other would have been awesome. The last leg delivery from your server to your device could be something else, possibly more optimized for the technical limitations of mobile transit.
We even had a piece of this for a while as Google and I think a couple other messaging providers had XMPP support but it's gradually been killed off.
The "business interests" part of this is that anybody creating a monetizeable user base via a messaging network wouldn't give the opening to others to come in via XMPP. It gives your users a way out and gives your competitors a way in.
Not to mention email isn't particularly distributed these days. I don't know the exact percentage, by yahoo, gmail, and microsoft definite host a large majority of the email accounts on the planet.
Anyone can register a domain, stand up a server, and start receiving email on it. Sending it a bit trickier as to get past spam filters there's a bit more to it (DKIM, SPF, static IP, etc) but it's still doable.
| The next few years were spent re-writing and modifying quite a few parts of ejabberd, including switching from XMPP to internally developed protocol, restructuring the code base and redesigning some core components, and making lots of important modifications to Erlang VM to optimize server performance.
I wasn't aware that they had switched entirely, only that they invented their own custom compression and (really bad) authentication and encryption methods.
I'm not going to say this is the whole story, but...
I recently tried XMPP on Pidgin for the first time on my laptop (Ubuntu), and I hate it. There's something very wrong and very ugly about the UI. It's feels just wrong. And not just that, I had to jump thru numerous hoops before I could get the thing working.
I also recently tried to install Signal on my Xiaomi Redmi2, and it doesn't work. I don't know why but the registration always fails when "connecting to the servers", even though everything else on my phone works. (before I start getting responses about this, if your suggestion can be found on Google I already tried it)
I think some things, like messaging where it's easy to create an MVP but hard to get the number of users that actually brings in the value, the entire game is polishing your one client to reduce frictions and increase experience. WhatsApp works as flawlessly on mi Redmi2 as it does on any Samsung or any iPhone. When you have zero friction to join over time your user base grows. When you have enormous friction to join, where users have to be wrestling with your broken app, it just fizzles. This isn't the case for every industry, but seems to be the case for messaging. Another example is Telegram. At one point they were ahead of WhatsApp in terms of features, now they're behind. Regardless, they keep growing their user base. My opinion is this is because their UX is at least as good as WhatsApp and has just as little friction.
I'm sorry you had that experience; for the record, Pidgin is not representative of the XMPP protocol (Pidgin is outdated, broken, and the XMPP side of it is mostly unmaintained). If you're one of those people who likes lots of switches and knobs and everything under the sun supported I'd recommend Gajim (personally, I don't think it's stable enough for day-to-day use, but others I know just like having all the bells and whistles it provides), if you want a bit more stability, I'd try Swift, if you want a CLI I'd try Mcabber (Possibly with the Vi-mode keyboard binding patches that are floating about on GitHub somewhere)
I don't buy this. XMPP uses no more than any other IM system, and much less than most. The military use it over HF links in theatre, for heaven's sake - this is not what you'd choose to be doing if the bandwidth was so high. (HF is STANAG 5066, and runs down to a handful of bits a second - this stuff is not fast).
And this is why in western countries the politics of encryption should be regarded as a stopgap only. It's better than allowing the police to opportunistically go fishing in your data, but it's no substitute for sound democratic rule-of-law culture.
If politics gets to the point of having to rely on encryption as your only protection then it's simply going to get banned and/or blocked.
That's true, and I think it means encryption not only protects speech but also works as a simple test for flagging nation states who're failing to protect the basic human right of privacy for their citizens. If a country tries to stop the use of encryption by its citizens then it's failing to do a good job, and its citizens (and other nations) should be working to make them aware of the problem.
additionally relying on specific applications / services that can relatively easy singled out with DPI and by that also stick out their users for "further inspection".
With DPI hardware having dropped substantially in price while at the same time expanded functionality, TelCom providers / gov. agencies can relatively easily / quickly deploy such censorship / surveillance at the edge or in the TelCom core.
I think it's unwise to rely on a sound democratic rule-of-law culture to protect our right to encryption: there's nothing which says that a majority of people won't support a law banning strong encryption.
I'd argue that the politics of encryption should be regarded as a stopgap in every country, not just western countries. Even Singapore sees value in encryption, and they aren't exactly supporters of free speech.
Isn't it "weird" that they chose to block Signal app and not the signal-protocol based Whatsapp?
If Whatsapp really implements the same kind of security and privacy measures that Signal does, why is Whatsapp allowed to continue operating?
If signal is preventing them spy on users and they ban it, is in't it safe to assume that Whatsapp is NOT preventing them spy on users, so they let it operate? Wouldn't you expect Whatsapp to be also targeted, especially considering the broad user-base it has compared to Signal?
Yes, I know they had blocked Whatsapp in the past, but they didn't block it now. Which means that something has changed in the relationship of the Egyptian gov and Whatsapp since 2015.
Whatsapp belongs to Facebook now, and Facebook is happily making tool for China to censorship. It's not out of reach to think that governments might negotiate Whatsapp too for some "tools".
Keep in mind that Egypt is practically under a dictatorship. It is not like their gov really cares if their people gets pissed off... Their government is far from carrying about peoples liberties[1].
So, for me the question remains: If what the Egyptian government wants is to apply their surveillance policies and Signal is banned because it is preventing them, doesn't the continuation of operation of other "private and encrypted" messangers say something? Especially of Whatsapp that claims that it implements the same security and privacy oriented architecture as Signal does?
> It is not like their gov really cares if their people gets pissed of
No man rules alone. Even in a dictatorship, pissed off peasants mean an army that has to do horrible things to keep them in line. That costs a dictator money.
Never said a man rules alone. Any dictatorship only takes a critical mass of powerful enough people to establish itself. This doesn't necessarily mean the people of a country as a whole, or the majority of the people, or even some times a significant and/or representative amount of the people.
In most cases of dictatorships, people end up being kind of pissed off against the dictators. That's what it takes usually for people to call their rulers "dictators". It is not how you would call someone you like.
Exactly for the same reason, the more authoritarian the establishment is - the less they respect/support liberties, personal/political rights and privacy of the people: Because the establishment expects such rights and liberties will be probably used by the people against the establishment itself. And exactly this is why such liberties and rights MUST be protected always, by all costs.
I am not Egyptian myself, but through discussions with Egyptian friends and/or Egyptians I randomly met, this is what they think of their government.
Due to cutting ties with Google and Facebook as much as possible I don't use Signal nor WhatsApp. What alternatives are there?
I have been using Tox (qTox on Desktop and Antox on phone) and XMPP (Conversations on phone). I also tried Ring (Desktop and phone)
My observation is that there is a lot of user inertia to make people use another chat app, and none of which I tried is in good shape to compete right now with WhatsApp/Signal.
XMPP and Ring share the problem that encryption was an afterthought. That alone is enough to stop widespread adoption. There must not be unencrypted chats nor different security levels. Encryption must be transparent to the user.
Tox doesn't share that problem, and is what I have the highest hopes for. The clients are not yet able to compete with WhatsApp. Antox crashes sometimes, gets reaaaal slow, and doesn't send pseudo-offline messages reliably. Multi-Device support and real offline messaging is still lacking in the protocol. Multi-Device support is not needed, see WhatsApp, but real offline messaging is a must-have. Also, messages must be reliably delivered and in the order they are intended. Tests of mine between qTox and Antox showed problems in that regard.
Moxie is open to someone writing an alternative to GCM, but nobody has stepped up and do it. It's much easier to complain about GCM, then to replace it.
Signal's use of GCM does NOT reveal who you are sending signals to, or what is in the message.
I didn't mean to critique anybody, but just pointed out why a specific solution is not okay for me. Take it as an assessment of the situation to understand what we have and were we want to go.
I might be ignorant about GCM. My understanding is that first you need to register with GCM and have the connection stay online permanent. That requires Google's Apps, which open the system to Google's Access, which clearly is not acceptable. Secondly, Google knows that way always where I am. I do not want a permanent connection to Google servers. Also, how does GCM know where to deliver my messages when it can't know who I'm contacting? I'm not saying that that is an impossible task, but to my knowledge Google isn't reliably (reliable in the sense of keeping my privacy even if Google were to become the attacker) solving it. [0]
Each of the three reasons given above are enough to not use GCM.
OK, if GCM delivers the data to Signal's servers, then Google doesn't know who I'm contacting, but the administrator of Signals server does. The two other points stay valid, though.
He said he would consider "a clean, well written, and well tested" pull request that would add WebSocket support to the Android version of Signal". That would replace GCM.
Don't confuse the issue with LibreSignal. Problem is Moxie is worried about the security of random 3rd parties publishing signal clients. Doubly so if published by f-droid (which doesn't' sign package with the developers key). Additionally he wasn't want these 3rd party client that may or may not be secure using the whisper systems infrastructure.
So it seems that signal could get a GCM replacement, if someone writes one.
Signal's use of GCM may not be particularly intrusive, but it still requires a phone with Google's services running. LibreSignal works on a Google-free phone, and Moxie told them to fuck off.
> If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.
Moxie knowingly and willingly runs a free service. Why should he feel entitled to tell people how they interact with his service? What's the point of publishing your source code under the GPL if no one can do anything with it? Keep in mind the phone server still isn't open source either, so the client source on its own is about as useful as a literal brick for phone calls.
1) he doesn't want the signal community to fracture with incompatibilities (like say XMPP)
2) he doesn't want the security of signal users compromised with less secure clients. Thus he's against SMS since it leaks metadata like crazy to 100s or 1000s of entities.
3) he doesn't particularly trust f-droid to distribute clients since they use a central key (an attractive target) instead of the developers key.
4) he wants to be able to quickly iterate improving the clients and server in sync, on his own schedule.
So generally he wants to target a large number of users with a very secure client and doesn't want to sponsor anyone that takes his source with free server infrastructure.
So he believes in audits, security, and opensource. He even will allow a GCM replacement, as long as it only runs when GCM is not available. He expects the battery life and user experience to be terrible. The main problem seems to be that google negotiates with cellular providers to not time out connections to GCM, but they silently do that (without an RST) to other connections. Thus any GCM replacement will have to spend much more power/battery maintaining a connection. Moxie specifically mentioned that even 50 seconds was too long and that some providers time out connections even quicker than that.
Y'know, every time Signal comes up on here, a small group of people show up and shit all over both it and its creator, then recommend a variety of half-baked alternatives. And Moxie pops by and patiently explains all over again why the preferred approach of that group won't work and what the options are. And you're claiming his tone is unacceptable? I mean, sure, you're free to choose. But he's shown a lot more patience than I would.
I'm a fan of Matrix (matrix.im). Encrypted (recently), federated, multi device, multi platform, has message history, voice, attachments and push notifications. Pretty much everything I've wanted.
It's not clear to me why Signal was blocked, though. Other governments have blocked messaging and chat applications before, but not for the reasons you'd think. For example, UAE blocks access to voice and video chat applications to protect the commercial interests of the telecoms companies who offer similar services. I'd be curious to know if other messaging applications were blocked in Egypt too, and why.
I'm not sure if you're joking, as the topic has been extensively discussed here in HN for the last six months, at least.
Anyway, in short: encryption-wise Signal is considered to be the state of the art, while Telegram is sneered at due to their homegrown encryption that isn't even enabled by default.
I can't say this is surprising, I was talking about the potential of Signal to be blocked by regimes with my friends a few weeks back (both the initial verification text, and client to server communication), and here we are with Egypt being the first to block it.
Perhaps integrating DNS tests and pinning DNS entries in Egypt would be a short term solution, but long term they may need to start bundling orbot with unique bridges.
SMS and MMS are a security disaster. They leak all possible metadata 100% of the time to thousands of cellular carriers worldwide. It's common to think of SMS/MMS as being "offline" or "peer to peer," but the truth is that SMS/MMS messages are still processed by servers--the servers are just controlled by the telcos. We don't want the state-run telcos in Saudi, Iran, Bahrain, Belarus, China, Egypt, Cuba, USA, etc... to have direct access to the metadata of TextSecure users in those countries or anywhere else.
Yet, Signal leaks the exact same metadata, if one serves an NSL to OWS.
In a way, Moxie's argument (don't tie things to phone numbers, don't use a centralized system for message transport) is exactly why Signal itself is so problematic.
Whisper systems did get a subpoena:
"the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service."
Retroactively, yes. But the NSA could just require them to log all messages they relay between any two users – and they’d get the same metadata as from TextSecure.
NSLs are not magic [0]. They are a legal tool that can be used to extract certain types of information (such as subscriber information and maybe a little bit of transactional information) that a service provider already has stored on their servers. However, they cannot be used to force a service provider to start collecting data or build a backdoor.
I do hope you see the differences between those scenarios, though? OWS doesn't have a presence in Egypt. If Egypt tried to serve them with some legal document requiring OWS to provide such metadata, they'd be laughed at.
Telcos, on the other hand, are usually based in the country in which they do business (and often have separate businesses in each country, e.g. Vodafone). As we've seen many times, it's pretty easy to get them to cooperate (voluntarily or by law). Much easier to get all the metadata you need that way.
Generally it seems that tying things to a SIM card (required for SMS) generally hurts privacy. Seems much better to replace centralized servers with a more distributed approach. Much like the original skype with it's supernodes.
The problem is that generally smartphones (at least on the WAN) do not accept incoming network connections except those blessed by the OS provider (Apple and Google). Said push notifications are tightly controlled and not particularly feasible as a p2p network transport.
I think what would solve this problem is a 2 level p2p system. The supernodes would be raspberry pi's,a plug computers [0], or even a wifi router. They can accept incoming connections, don't pay as much for bandwidth, could be shared among friends/family/neighbors. Even a 64GB microsd + arm would handle substantial messaging traffic.
Then the more network and power constrained phones could check in with their preferred supernode, ideally falling over to other supernodes if necessary. Messaging traffic is tiny, so storing it 3-4 times on redundant supernodes would still be cheap.
Said supernodes would earn reputation with their direct peers in the form of providing bandwidth, storage, and forwarding packets.
That way it would be much harder to censor, fairly robust, and ideally still easy to use. Whoever writes the software could charge an extra $20 for a turn key raspberry pi or plug computer.
Android as a fork of TextSecure called Silence https://github.com/SilenceIM/Silence but the metadata would be easily accessed when sending encrypted sms. While the contents of the message may be secure who and when you were talking would be easily accessed.
Geez, if only there were a protocol with as good encryption but federated so that everybody could host their own server which would make it way harder to block…
Eh, you'd have to operate a server in the country, and TLS in and out of Egypt is MITMed and outright blocked in many areas from what I've seen when playing with VOIP over there.
At least they would have proper encryption within their country. Apparently, depending on central services outside their country makes it too easy to block.
If countries will block messaging services why do you think they won't raid / shut down servers?
I really don't understand the hating on Signal for not fulfilling all of everyone's use cases. There is an SMS/ MMS fork called Silence (available on F-Droid). If that's a feature users want they have an option.
But ...
What exactly happened that XMPP lost on mobile phones? What did they do wrong? XMPP was there before smartphones came, had working clients, and had (for that time) pretty decent encryption.
While I understand that big players like WhatsApp want to bind all users to their own infrastructure, I don't understand why even the niche instant messangers go through the burden of creating their own infrastructure (or relying on Google's) instead of just concentrating on the client side to provide better XMPP clients.
Is XMPP so bad that nobody wants to do that? If so, why?