'joecool1029 links[0] to an interesting Github thread[1]. It starts with Moxie not being OK with LibreSignal using Signal's name and servers, but quickly turns into a discussion about federation.
Moxie:
"I understand that federation and defined protocols that third parties can develop clients for are great and important ideas, but unfortunately they no longer have a place in the modern world. Even less of a place for an organization the size of ours. Everyone outside the FOSS community seems to know it, but it took actually building the service for me to come to the same understanding, so I don't expect you to believe me."
Now, I understand Moxie's goal is to (quoting from further down that thread) "make mass surveillance impossible for the world we live in, not a fantasy land inhabited only by cryptonerds and moralists (...) to produce technology that is privacy preserving but feels just like everything else people already use, not somehow convince everyone to fundamentally change their workflow and their expectations.", but still - is that the consensus now? That federated protocols are dead and "no longer have a place in the modern world"?
I can't help but feeling that Moxie's opinions about federation is nothing more to protect is business interests, which is to sell the Signal protocol to chat companies like Google and Facebook/WhatsApp.
Matrix/Riot is a good example of a federated chat protocol which supports all the latest and shiny things you could find on a chat service (cross-platform, E2E encryption, audio/video group calls, multimedia content, etc) and which is also very easy to use and which has great UX. I would say that Matrix/Riot is even more feature complete than Signal.
I get that the guy thinks non-federation makes things simpler for himself but the way he argues against federation is nonsensical.
You're taking a new thing and assuming it's the same forever. His point was that upgrading all clients/servers on a federated network is difficult/impossible and you end up with compatibility issues.
Matrix/Riot is too new to have those, they have never deprecated a cipher yet.
While I love Signal for its simplicity and Matrix/Riot for its features. I regularly train high risk activists/journalists/aid workers on both and they always default to Signal. Matrix unfortunately suffers because it has too many features - and by far the biggest one we hear about is key exchange. I love the granular options but the vast majority of people just looking to communicate don't.
We have a matrix chatroom for three colleagues. The list of keys and devices we have to verify against each other does not fit anyone's screen, it is insane.
> His point was that upgrading all clients/servers on a federated network is difficult/impossible and you end up with compatibility issues.
I think that he exaggerates the problem. Right now, it's possible for someone to install the Signal client, and then never upgrade it: the Signal servers must have a way, eventually, to refuse service to that client (upon which it will receive a message from the server stating something to the effect of 'your client is too outdated; please update it').
With a federated system, eventually some servers will be so out of date that other servers will refuse service to them. They'll have to send a message to those servers to the effect of 'you are too outdated; please update yourself'; the server can forward that message to its administrator. The clients of such servers might also receive a message stating 'your server is too outdated; please ask your administrator to upgrade or switch servers.'
A similar pattern exists with respect to client updates in a federated network.
Moxie's just wrong on this, I think: it's not significantly worse; the pattern with federation is very similar to the pattern with centralisation; and there are real benefits to federation & decentralisation.
If we are going to make the argument that updating all servers and clients on a federated network to follow the latest and securest crypto is a big issue, we also have to pull the argument that the crypto of a non-federated network can be manipulated at any time without your consent.
In other words, you are at the mercy of whoever owns the chat platform. To me, this is a bigger privacy issue than the issue with updating servers/clients on a non-federated network.
> but still - is that the consensus now? That federated protocols are dead and "no longer have a place in the modern world"?
Having see what has happened (is happening?) to Mastodon, I can see where Moxie is coming from; as much as I hate to accept it.
Moxie also doesn't seem particularly happy with the situation; notes in the same post:
"Truly though, I wish you well in the endeavor, it's something that I'd love to be proven wrong about."
He notes two issue in particular:
- Degradation of UX
- Loss of development effort
From what I've seen, Mastodon suffered from similar problems (certainly as a user, I can attest to the first one). It seems those are inevitable consequences (along with performance/scalability issues) of the loss of control that comes from federation. Personally, I don't think those are necessarily insurmountable, but they are non-trivial, and will require effort and commitment -- including from the end users -- to resolve.
All other things being equal, a project focusing on federation will be at a disadvantage compared to a centralized one when it comes to delivering good UX. So lamentably, I don't see a federated platform becoming mainstream outside tech culture, and that is what Moxie's vision for Signal is...
Perhaps because your goal isn't blanket, end-to-end privacy?
To work on end to end privacy one really needs to control the experience end to end; trusted clients and a solid protocol, plus trusted discovery.
Email is not that thing. Email is postcards.
At a technical level, email works well from the perspective of "the mail must get through", although practically speaking, spammers ruined things to the point that most people are feudalised because defending spam raised the bar of technical expertise too high for most people.
And the small number left who can run their own infra are often locked out by the feudal overlords (big 4 + every isp ever) because an untrusted ingress is basically a spam loophole.
Ironically the closer you get to spam free the more you have to police, because the value of a spam injection point goes up commensurably when most people are no longer exposed to it.
Overall, the war on spam was won, but at the cost of freedom for the people who would like to run their own infra but aren't technical and patient enough to do it in today's environment.
> Ironically the closer you get to spam free the more you have to police
The root problem of bare-bones email is that user identity and user-agent address (mbox) are conflated. (A social layer would effectively address this fundmental flaw.)
Moxie is talking specifically about making a secure (particularly, end-to-end secure) federated communication protocol. Making insecure federated communication protocols is pretty much a solved problem, yes.
(And I'm sure some people are very happy GPG users. But the majority of email users are not and will probably never be)
Been working on a mail.ru pet projects in my teens (Moikrug), people were telling that PGP/GPG adoption was at around 8-9% in Russia in 2006.
Among corporate users, there are some rather big companies with 100% adoption. How they achieve it? With a simple policy "anybody sending unencrypted email is fired," and training to make sure that even least technically literate people on the company get it (a person is not let to handle anything until he is examined by a specialist).
What is the problem with Mastodon? It is the most populus federated network I have seen. (Other than the Internet, if you count it as one) It's striving among several interest groups around the world.
> It is the most populus federated network I have seen.
Yes, same; but that's kind of the point. Mastodon is the best effort I have seen so far; which is why it was disappointing to see it falter shortly after it started to really pick up.
There seem to be a mass exodus from Twitter (at least, among the people I follow), precipitated by Twitter's latest unwelcome UI tweaks. Initially, it seemed really cool -- it was specifically addressing Twitters biggest pain points (longer messages, chronological timeline, saner threading), and was OSS and federated to boot.
However, quickly the veiner started to crumble, with there appearing to be an increasing number of issues, such as undelivered DMs, scrambled threads, dropped mentions. A lot of them seemed specifically related to interactions between federated instances. To make matters worse, the UI seemed to be getting increasingly slower.
Eventually, the combined frustrations, and to some extent perhaps network effects, resulted to gradual return back to Twitter.
This is, admittedly, a skewed view based on the observation of the small slice of Twitter community that I follow, and my own limited experience with the platform (spanning a few weeks).
I am still hoping that Mastodon (or something like it) makes it, but I'm not holding my breath.
Signal is built on top of the phone number system (ie. falling back to SMS, phone numbers as ids). Telephony is pretty clearly a federated system - somebody on one carrier can talk to another; even internationally.
I find it so ironic that he doesn't "support federated systems" when the Signal is tied to one.
And yet you can't create your own small phone network, assign whatever numbers you want to your users, and expect others to interconnect with you or honor your numbers. Telephony is federated within an internationally regulated system, to claim that this in any way supports federation in a similar manner as what is being discussed is to fundamentally misunderstand how the system works.
> And yet you can't create your own small phone network, assign whatever numbers you want to your users, and expect others to interconnect with you or honor your numbers.
Actually you can quite easily, and quite a few people have done so. Including hacker clubs for events (the CCC operating a local custom GSM network with their own SIMs, and working numbers a few years back for their congress comes to mind), small ISPs with only a few hundred or thousand customers, and more.
I wouldn't call these event networks "part of the federated phone system". They are clients of companies that are part of it. External numbers into these networks are extensions of a public number they get from the upstream - just like any company having a PBX, they do not participate in any of the inter-provider infrastructure, do not own the phone numbers, ...
The internet equivalent to what they are doing would be getting a business line with a fixed, provider-owned IP prefix. The equivalent to what the parent describes would be getting a prefix delegation from a registry and peering with other networks.
It's still really cool for island systems though, which is the more important thing for those events.
> I wouldn't call these event networks "part of the federated phone system". They are clients of companies that are part of it. External numbers into these networks are extensions of a public number they get from the upstream - just like any company having a PBX, they do not participate in any of the inter-provider infrastructure, do not own the phone numbers, ...
I mean, they ran their own full MVNO, with their own SIM cards, with their own code on the cards, and operated their own tower.
I meant purely from a "connection to the general phone system" perspective - at all events I've been they only had internal numbers and you could be called from the outside through an extension. If there was an event where that wasn't the case I stand corrected.
Having the entire (mostly/entirely? open-source) GSM network is really really cool and important, but from the perspective of the wider phone network still "only" a "fancy internal phone system", with the limitations of control that come with that.
> And yet you can't create your own small phone network, assign whatever numbers you want to your users, and expect others to interconnect with you or honor your numbers. Telephony is federated within an internationally regulated system, to claim that this in any way supports federation in a similar manner as what is being discussed is to fundamentally misunderstand how the system works.
Wait, but if telephony is regulated then so is our DNS system. After all, Verisign (I think) owns "dot com". I am not sure about the last statement but the point is that you have to go to a registrar to get a domain name. So, is email not truly federated either?
Thinking about the problem, we need some kind of identifier that is not controlled by a single entity and yet there is a consensus as to how we route traffic designated to that identifier. Ideally, we want to be able to designate multiple clients with the same identifier which only complicates the issue. Is there a solution to this?
"Wait, but if telephony is regulated then so is our DNS system."
What do you mean by "our"?
There is nothing that "forces" anyone to use ICANN DNS.
(There is certainly coercion and peer pressure to follow along, but as a technical matter anyone can break free at anytime. It is just a matter of changing some defaults and running some software yourself.)
People use ICANN DNS for one of the following reasons
1. because they do understand the technical details such as changing defaults and running a local authoritative server serving a root.zone file,
2. because their business relies on ICANN DNS somehow or
3. "because that is what everyone else is using" or some similar belief where any variance from status quo is per se failure.
The encryption that Signal uses is not likely to be broken. Because Marlinspike did not write it.
The protocol is a different matter. Uncertainties abound.
The author of the encryption is not the author of the protocol and if I recall the author of the encryption questioned why the distribution of the software has to be controlled by one company. (Answer: It doesn't.)
Signal is a classic example of some software (in this case written in Java) whose adoption on its own merits the author has deemed "inadequate" and so the author attaches it to some very widely adopted platform or other widely adopted software. This results in instant mass adoption.FN1 It is like entering into a distribution agreement.
Challenging this decision with respect to Signal results in mundane philosophical arguments about "user experience".
The beautiful thing about the encryption that Signal uses is that it is not attached to any particular software or platform. It gains adoption on it own merits, not by making a deal with a company like WhatsApp/Facebook.
Anyone can write software with the same encryption that Signal uses, and it does not have to be entwined with a protocol controlled by Facebook.
FN1. Another recent thread mentioned how web browser authors partner with popular software such as "CCleaner" to silently install their browser along with "CCleaner". As a result, every user who installs "CCleaner" also installs Chrome (and maybe some other malware). Parasitic software distribution.
When it comes time to boast about browser "market share", the method of distribution, the presence or absence of conscious choice by the user, is not reported.
Telephony is federated, in some senses. But not as is generally accepted when speaking about internet communication protocols. Compared to SMTP or IRC, the average person can't start their own telephony service provider - to do so is highly regulated and involves organisations such as the ITU. I'm sure, given such an infrastructure, Signal could be relatively easily moved to a "federated" set-up. But that wouldn't solve the issues that people who complain "Signal isn't federated" want fixed.
I am not sure what he means by that since the contact he provides on his personal page is e-mail. Which works through federation. Which he knows, since his e-mail is working on his own domain (not a 3rd party provider like gmail).
Yep, some of the imposed limitations (single server, necessary to sign up with your phone number) make the conspiracy-theorist part of my brain fire up. And the longer this goes, the less beliveable are Moxie's excuses for doing it that way.
Conspiracy-theorist mode: spooks wanted to control the scene once it was obvious that it will be impossible to stop the proliferation of the idea of 'e2e encrypted secure messaging'. For this, they had to have an actually secure product without obvious backdoors (to gain and keep marketshare), but also some way to sidestep it. As long as they have the necessary metadata (who is contacting who, and the phone numbers they use), they can just sidestep the end-to-end encryption and hack the endpoints to access data. And moxie is insisting pretty hard on the 2 aspects of Signal that are unnecessary for the stated goal of the project, but are necessary for this purpose: 1) single central server, 2) having to share your phone number to communicate
It is server-less, no phone numbers required (Sorry NSA :( )
I looked at all the "secure" chat clients (Facebook, WhatsApp, Riot, Matrix, etc.) and Tox seems to be the only one that is SECURE (read: encrypted) and more importantly PRIVACY-FOCUSED (no phone numbers & central servers).
After ICQ, MSN, AIM, XMPP, Jabber, GoogleTalk, etc. I learned my lesson:
Not gonna trust any single entity EVER! No matter how "secure" they say they are.
> and Tox seems to be the only one that is SECURE (read: encrypted) and more importantly PRIVACY-FOCUSED (no phone numbers & central servers).
I wouldn't bet on that just yet. Tox is not secure right now. [0]
For now Riot (Matrix) through Tor fills this purpose nicely. It's completely encrypted end to end, and Tor avoids being identified from metadata. It does use servers, but you can choose any of the public servers available[1] or create one yourself and have people use it for plausible deniability (while you use it through Tor). There's interest in making Tor-only Matrix servers that can communicate with regular servers[2] but I think Matrix clients through Tor is secure enough.
Also, allowing using phone numbers for authentication is in my opinion very important for a service to reach some level of popularity (and therefore more work put into it, more audits, and not having to use a gazillion of clients yourself, etc). Riot main server has it but of course it's not required at all.
The problem that unless you are going to blow up the Empire State Building it's very hard to convince people to use yet another not to mention switch to a different messaging app.
What happens is that the person who does it effectively being cut out of the loop with maybe a handful of their contacts becoming partial converts that might serve as human routers for a while.
WhatsApp and Signal work because they are easy they are mom/grandpa proof and they have a huge user base.
Can I add the amount of required permissions to the conspiracy theory? For a privacy-oriented app, requiring access to EVERYTHING is what has kept me away so far.
(Or maybe there's a "Signal Lite" I'm not aware of?)
Right from the get go, if you deny it access to SMS it forces you to wait 2 minutes (no way to skip), then only gives you the option to receive a phone call with a code to enter.
Why not work like every other app and allow me to just enter the code from the SMS I received?
As someone whose primary motivation had little to do with "hiding my conversations" and much more to do with "not having my entire address book, unrelated SMS history, and identity sucked up and sent to some company I don't trust", Signal just wasn't a great onboarding process at all. In the time I spent waiting to see what happened when the SMS timed out, I'd already installed Telegram and gotten setup. And if I remember correctly, even once I went through the phonecall process Signal was basically non-functional without access to my contacts.
So Telegram it's been - shitty crypto and all. Though I'm open to other recommendations.
The server is open source, you can run your own private Signal network and rewrite the authentication if you wanted or remove the sms verification. Now that there's no longer a google play dependency this is possible. There's other software that is designed for nyms and is federated I don't get why people demand Moxie cram more features when what they want is already built.
I don't understand why are you accusing me of 'demanding moxie cram more features'. I do not use signal at all.
> you can run your own private Signal network and rewrite the authentication if you wanted or remove the sms verification.
You can. What's your point? Most important thing with IM is network effect, i.e. how many people can you contact with it.
You propose putting effort into rewriting the code, then running your own server, then only talking to people who you get to install your modified version of signal on their devices. This is not a solution to the problem, because if you're gonna put all that effort in, there already are viable alternatives.
My main point with my 'conspiracy theory' was that spooks would want to control the scene by being in control of the most popular IM networks. I do not see how you disprove that.
I'll grant that the conspiracy theory does explain the facts you mention (as well as the fact that Signal shares contacts with OWS), but I think that a simpler theory explains the facts too: the the OWS guys really do want to get some crypto into the hands of the masses, and are willing for their product to be less secure than it could be if it means that end users are more secure than they'd otherwise be (i.e., they believe the alternative to Signal-as-it-is is not Signal-as-it-could-be but rather SMS).
Tying things to a phone number makes sense in order to reduce Sybil attacks, but I think that OWS could operate a phone-number-based identity service which would be relied upon by federated Signal servers, reducing the degree centralisation while still preserving Sybil resistance. This matters because without Sybil resistance it'd be pretty easy for a malicious party to send a Signal user 10,000,000 messages per second, saturating his data connexion and depleting his battery; tying identity to phone number makes it easier to limit & block such bad actors.
> Tying things to a phone number makes sense in order to reduce Sybil attacks, but I think that OWS could operate a phone-number-based identity service which would be relied upon by federated Signal servers, reducing the degree centralisation while still preserving Sybil resistance. This matters because without Sybil resistance it'd be pretty easy for a malicious party to send a Signal user 10,000,000 messages per second, saturating his data connexion and depleting his battery; tying identity to phone number makes it easier to limit & block such bad actors.
I think people who are for anonymous use of Signal don't understand that the bulk of Signals users don't want anyone who is anonymous to contact them. If I don't know who you are or I can not track you down, then you can't contact me.
I don't think too many people want the people they communicate with using Signal to be anonymous to them; they want them to be anonymous to Open Whisper Systems. Ideally, OWS would have no way to know that I'm talking to my best friend, or who we are.
Getting that to work is tricky, but it'd be awesome.
I can imagine a system where users prove possession to OWS of their phone numbers via SMS — as they currently do — and OWS issues them certificates using some sort of blind signature scheme; they can then use those certificates to prove to any server they talk to that they are someone with an identity, and the server can use a subsidiary certificate to demonstrate to other servers that it's acting on behalf of someone with an identity (but not whose identity), and the recipient's server can rate-limit based on that identity, and potentially even record information to aid in manually tracking someone down — without revealing the identity in normal use.
I could be wrong, and I've definitely not proven that it can work. But I think it can be made to.
I agree with you; I'm not some crazy kookoo yelling about judgement day on the corner, this is just some 'food for thought' discussion.
For the first part of your argument, the issues I mention do not affect the security of the product (signal) itself, they would just enable spooks to more easily sidestep the whole product.
I also do not have anything against using the phone number as uid, it's 'good enough' for most people, and it greatly simplifies things. It is a very sensible default. What I'm questioning is the hardline stance of not allowing anything else at all - while 90% of people would be fine with signal as is, why not give the remaining 10% of us kookoos a bit more freedom?
As for the Sybil attack, does signal allow users not in your 'buddy list' to send you messages?
I'm with you — I'd love it if (internally) Signal user IDs were URLs, e.g. tel:+12025551212 — which would mean they could also be email addresses or anything else.
I think Signal allows anyone to send messages; I don't think it only permits communication when both parties have one another in their contact lists.
1. During the FB backdoor scandal, rather than giving any elaboration on the issue of the retransmission hole, he rallied his troops to shower the legitimate point raised by Guardian article with FUD, and rain ad hominems on critics with aim to discredit them.
He completely diverted the point of discussion from the fact that there is a retransmission hole, to "guys attacking me have no credit" , "guys attacking me endanger people who need encryption", "People will not benefit from it, giving out fact of strong encryption usage is worse than having bad encryption", "adding retransmission hole is a compromise", and e.t.c. He can not be doing this discussion diversion not purposefully, without deliberation
2. He claimed that he attacked Signal clones "for benefit of users," yet it is not hard to imagine that he does it with no other purpose than getting more users on his own service. Again, a demonstrated show of deceitfulness from his side. Yet again, he parried criticism of this move with discussion diversion.
3. In this instance, he reflected the allegation, by mirroring it against the opponent.
It's frustrating that there are now so many "secure messengers" but none of them is so much better than the others to cause consolidation. I end up needing to communicate over 20-30 of them with different people.
Signal has the worst app (on iOS) and worst UX of anything I regularly use. There's unlikely to be a desktop client which is actually usable (doesn't depend on a phone, works on platforms I care about). The app is less buggy on iOS than it used to be, but it's still not great. Also doesn't work well with groups. And tied to PSTN identities, and the "talk to a new person on the street" interaction sucks. But, the most widely audited crypto, a good development model, and good adoption within some activist communities.
Wire is great, although it's a little "game-like" vs. professional for certain UX. I know the developers and really like it, and it's great for group chat and desktop, but doesn't have much adoption. But, one big global system, too.
Riot/Matrix and Mattermost are nice because you can run them on private networks. Nice apps. I've not seen as much analysis of their security as Signal.
Whatsapp, Telegram, etc. have massive adoption. Whatsapp is now solid security for user to user.
Apple's stuff is great but is Apple-only, and I'm wary, even if I trust the security model, to let a single company own my OS (and update whenever, without really auditing it) and my "end to end encrypted" apps -- way too easy to slip in any kind of backdoor there if they want.
etc. I'd happily trade in 50 ok to good systems for one great standard and then OS/other-application integration -- but it seems like we don't do standards anymore.
> There's unlikely to be a desktop client which is actually usable
Check out eul, it's a native desktop client for all major messaging platforms. Signal support is coming in October.
It's only 4 MB, and it can handle thousands of messages without lag.
Music Bee is pretty good. Not sure if it's still around though, I mostly listen to music on my phone/youtube nowadays and work doesn't let me download music to my computer.
Agreed. The polish, development schedule, and binary-only distribution all say "commercial software", but the lack of license or obvious commercial strategy say "what's going on here".
Looking at your comment history (on both your accounts), you say you plan to open-source it, but you're not sure under what license, and you also hope to make money off it but you're not sure how - possibly through a "paid option"? I commend your effort, but until the exact nature of the project is settled, I would expect confusion and reluctance on the part of your potential users.
Personally, I would never use a secure messenger I couldn't compile myself.
WhatsApp also has the glaring vulnerability that Facebook could at any time reset your key to a compromised one without your knowledge, and WhatsApp will resend any hanging messages automatically upon the change, making any undelivered messages available to the one who has the decryption capability associated with that new key. It's possible they've put in a method to do this without notifying the user. Also, this "automatic resend" behavior means that a physical attack can be made simply by switching SIMs on the phone before the message is sent. It requires some careful timing to be a real vulnerability and anyone using a phone to communicate will certainly opt for a more secure platform for critical applications.
This article explains a lot better than I can some of the security tradeoffs with Whatsapp, particularly in regard to metadata and data collection.
Also, the worst UX? IMO Signal looks and feels much better and less cluttered than WhatsApp, Wire and Hangouts. Only Telegram has a superior UX (and a really nice QT native desktop app), IMO.
> to let a single company own my OS (and update whenever, without really auditing it) and my "end to end encrypted" apps -- way too easy to slip in any kind of backdoor there if they want.
Strange. We have opposite conclusions from the same data. I figure I need to minimize the amount of people that "have root" so to speak. If I can't trust Apple, it doesn't matter if I trust Signal. Apple controls what actually gets downloaded to my phone.
I use signal for a different reason: mark certain conversations as "phone only" so notifications don't come up at inopportune times like when I'm at thanksgiving dinner with my extended family.
Yasha Levine, the other person in the conversation attacking Signals credibility, is another person to take very lightly in these conversation. He's a Russian pop-tech author known for his research into Russian/US espionage, but following his twitter for the last 2yrs he also seems to dabble in plenty of borderline conspiracy theorists stuff with. He seems to have a strong bias against anything American (occasionally rightfully but many times seemingly for just the sake of it). In conversations I've had with him he also demonstrated a poor understanding of crypto/software development - but those things are not uncommon for journalists covering infosec from the outside-in.
Either way I'm not surprised he is included here accusing Signal of colluding with the US gov merely because it indirectly took funding... all of those espionage fans see "US gov funding" and instantly assume collusion - but the reality is typically much more boring. Maybe not so much in Russia where money from the state often comes with expectation of favours in return (the opposite of America where money going in to the state demands favours in return)...
Originally, I didn't install signal because i have a google-free android smartphone, and signal depends/depended HARD on the play framework, even though that's not necessary. [1]
> Marlinspike reiterated that the whole point of end-to-end encryption is that users no longer need to trust anyone if the protocol works — and Signal does.
But it depended on the google play framework - and I don't trust google. So where does that leave me?
EDIT:
To reiterate: As far as I can tell Signal itself is secure enough. However, the most secure chat app is insecure if it is run on an insecure operating system.
Now, I don't want to start a discussion about android security. But:
- The update situation is quite bad, leaving (for example) my phone with exploitable bluetooth
- Google itself ... could at least be coerced by a state actor into compromising anyone's privacy
With those two facts given, the practical difference between signal and telegram seems... less relevant.
[1]: Look at the "conversations" app. Yes, it is for XMPP, which is old and uncool - but it (a) doesn't use the play framework either and (b) uses very little battery on my phone, despite holding an open connection most of the time. That IMO proves that depending on the play framework is unnecessary in this case.
Telegram doesn't drain battery at all and doesn't need Google. Not sure what Signal and others do, but of Wire I know that they drain battery as fast as if I had a game running constantly in the background.
Signal I'd use, but it (still) doesn't work on my phone because I've got many Google software firewalled. When reporting this bug years ago it was a WONTFIX. I also heard they removed that dependency months ago and I keep trying every few months, but Signal won't even let me confirm my phone number because it relies on Google so deeply, so I can't use it.
So unfortunately Telegram is still my messenger of choice: high usability, everyone has it, it's not owned by some big corporation and it's not of the USA, and optional encryption (for non-group chats) is better than nothing.
It's strictly worse than nothing. Opting to use optional end-to-end encryption basically shouts to your local friendly dictatorship, "Hey, look at this person!" Would you like that kind of attention? There are no such concerns with mandatory end-to-end encryption. It probably would be banned altogether, but that's a different problem.
Have you tried CopperheadOS ? It doesn't include any google services, and signal/noise still works on it from what I've read. So the dependence on google might be a superficial misconfiguration.
The apk can be directly downloaded on their website [0]. It is signed by OWS, runs without gapps installed via websockets and should be 'auto-updating'.
f-droid would be nice, I agree. I did not really follow the whole political discussion about why moxie refuses to cooperate, but at least I can use signal again after some years without gapps.
> I did not really follow the whole political discussion about why moxie refuses to cooperate, but at least I can use signal again after some years without gapps.
F-Droid offers two options (a) they build your app, or (b) you use reproducible builds, they rebuild your app, and verify that it produces the same result.
Moxie raged that people should trust him instead of F-Droid for builds, so (a) wouldn’t be an option, and was awfully silent about (b), especially considering that Signal now has reproducible builds, but he refuses to allow that option, too.
Last time I looked Telegram wasn't recommended by Moxie and a few other people. That was 2-3 years ago. What's the status now?
They came up with their own encryption protocol and they are not trained or known as cryptographers, that's a warning sign.
> [Durov] The encryption of Signal (=WhatsApp, FB) was funded by the US Government. I predict a backdoor will be found there within 5 years from now...
That's another red flag, needing to spread fud and lies about Signal. Another reason not to trust Telegram. Indicates that maybe their ethics and integrity are a bit too flexible.
> During our team's 1-week visit to the US last year we had two attempts to bribe our devs by US agencies + pressure on me from the FBI.
Some people might read it as "these guys are so good, FBI is begging to backdoor them". But it can also be read as FBI suspects they are ethically compromised and they have a chance of succeeding.
> Last time I looked Telegram wasn't recommended by Moxie and a few other people. That was 2-3 years ago. What's the status now?
I honestly don't think it matters. The fact they lie about a large number of items, such as the nature of their relationship/business and have repeatedly is proof enough they can't be trusted.
> For starters, Durov and other Telegram employees had repeatedly claimed their app was nonprofit, which wasn’t technically true. (“The Telegram team declared numerous times in its FAQs and public statements that Telegram was a non-profit,” Durov wrote to Neff in an email made public in court documents. “… The for-profit entity that we currently have, especially a U.S.-based one, raises questions among our audience.”)
> That's another red flag, needing to spread fud and lies about Signal. Another reason not to trust Telegram. Indicates that maybe their ethics and integrity are a bit too flexible.
Lying has been their modus operandi since the start.
> You must not have followed Telegram much. From the beginning they've done nothing but pretend their protocol is absolutely secure ("military-grade encryption", "world's most secure protocol", etc) and rejected any attempt from the crypto community to help them fix problems before they endanger people.
The sheer pervasiveness of their lies and the fact it ranges from the quality of their cryptographic skills to the nature of their business should have prevented its adoption. Unfortunately, lying at scale appears to work because most people simply dismiss it as "competitors" attacking their competition. :\
> [Durov] The encryption of Signal (=WhatsApp, FB) was funded by the US Government. I predict a backdoor will be found there within 5 years from now...
To emphasize even more why this is silly: nobody from the government (well, at least nobody who has said they're from the US or any other government) was involved with the actual development of the Signal Protocol. It was just funded by the government, through the Open Technology Fund, a project of Radio Free Asia (which is itself under the Department of State; the OTF was largely an initiative of Sec. Clinton). This is an extremely different part of the government from either NIST or any of the three-letter agencies.
There has been exactly one backdoor found in crypto relating to the US government (Dual_EC_DRBG), and it was in crypto developed by the NSA and basically pushed into a standard. It was also crypto that looked extremely suspicious, immediately, to any cryptographer who looked at it: it had a contrived design for no good reason, ran much slower than the existing options in the space, and appeared to support a backdoor. A lot of people have looked at the Signal Protocol and found nothing like this.
The US government has been accused of hiding backdoors before in one case, DES. It turned out that they were hiding a way of strengthening DES against an attack that was not yet public (differential cryptanalysis) but had been discovered by the NSA. Nothing like this happened to Signal: the developers were not told by the government "Great, just use these S-boxes instead."
(In fact, it occurs to me that there's not much room in Signal for a backdoor along the above lines: no S-boxes, no constants, etc. The closest it gets to that is picking Curve25519 and Curve448, both of which are well-known curves, predating Signal, with simple mathematical descriptions that make them essentially impossible to have backdoors. Perhaps he means that the Signal software is backdoored? But that wouldn't make sense with the reference to WhatsApp and Facebook, and also is a much more easily disprovable assertion than that crypto is backdoored.)
The US government also, of course, weakened crypto with the ridiculous export rules of the '90s. But that wasn't a backdoor, and they were pretty explicit that the intention was to weaken crypto. The OTF has no such motivation here; their goal was to produce secure tools that can be used by dissidents around the world, and intentionally-weakened crypto would be dangerous in such a context.
I worked on three OTF-funded security audits a few years ago (though not of Signal). No spook crossed my radar at any time. I'd have been very surprised if any had tried to pressure us at that work; you can read Bamford or the Snowden stories to get a better idea of how they seem to work.
(Despite having some security experience I'm not a cryptographer, and I feel kind of silly speaking up here. But the FUD is even sillier.)
> they are not trained or known as cryptographers, that's a warning sign.
Actually, they are. Or a few of Durov's family members are. IIRC it was his brother that developed Telegram's cryptography. His family has a pretty impressive academic mathematical background.
The warning sign is that, academic credentials or not, they still rolled their own crypto, and didn't use common ( = "crypto community" vetted/approved) cryptographic primitives and techniques, but came up with new stuff that isn't vetted properly. And that is a warning sign.
What is also problematic is that Telegram's encryption is not enabled by default. Even if the crypto turns out to be flawless, that is still a big problem.
One other thing I wonder sometimes myself--though I'm not knowledgeable enough to lean either way--is about this crypto community. I know it's international, in principle. But how inclusive is it in practice? I'm probably biased from reading most on the topic via HN, but how much of it is US-based? Does Russian academia take part in it too? Honest question.
BTW I use Telegram (also Whatsapp, Signal and recently Matrix) myself. I just don't consider any of it (Telegram) encrypted. Really fast postcards. But the UI and functionality (especially with the desktop app) is a joy. Why can't they all just team up or something and have the Telegram guys do the UX part? :)
> [Durov] The encryption of Signal (=WhatsApp, FB) was funded by the US Government. I predict a backdoor will be found there within 5 years from now...
If you can't win an argument on the merits, spew unfounded sensational accusations to confuse and distract the technically illiterate and conspiracy minded.
It's the same status as it's always been. Nothing fundamental has changed about their technology, which is materially inferior to that of Signal, WhatsApp, Wire, even Facebook Messenger.
As someone who is not exactly versed in the jurisdictions of the TLAs, wouldn't it be the CIA's role to put backdoors in Telegram? The FBI would be doing counter-intelligence and would only approach Telegram if they suspected wrongdoings on their parts, no?
They don't need to backdoor it. The re-transmission with a different key feature is the very definition of a vulnerability. For as long any encryption protocol allows for it to happen, one can trigger a key renegotiation that can be taped.
And it was used few times already. Some of such occurrences were well documented.
In 2015, in a lobby discussion on DEFCON two people confronted Marlinspike about the retransmission vulnerability in the Signal. He was asked to give a _yes or no answer_ to whether the central server can trigger the key renegotiation by sending the "I lost my phone" command to both parties. And he answered this question _no_. This was long before the Guardian lashed at FB with the backdoor article.
Actually, in Signal more recently now you don't even get to confirm the new key, it just says "hey, the key changed" in the conversation text and keeps going.
I'm not exactly comfortable with this now - it seems like someone may be able to spam messages to hide the key change.
If you manually verify safety numbers and mark your contact as verified, it will hard-stop you and require confirmation if your contact's identity key changes afterwards.
Because the Signal Crypto Protocol is completely open & the client is open source. A backdoor in Signal would require the keys to be exported to the Signal servers (by compromising the source code), which would be visible to every open source developer.
I'm using Telegram client compiled from sources right now...
Edit: The main problem with Telegram is not the crypto, but the fact that end-to-end crypto is not used by default. Except with calls, those are always end to end encrypted.
With all those controversial statements Moxie was making and questionable decisions in development Signal lost its initial attractiveness and, in my opinion, relevance. Even Wire opened their server-side source code by now (not that Signal hadn't). While this was happening, we got Matrix[0] and GNU Ring[1] in a usable state, and I can't see any reason to use Signal (let alone Telegram) any more.
This is all very unfortunate, because the success of this type of services depend strongly on its initial user-base size. For a while, with the rise of mobile there seemed to appear a critical window (from the public perspective: ICQ forgotten, XMPP not even noticed, Skype annoyed everyone, Google talk ?) for a new IM to fit itself, but it seems lost. I fear enticing users to switch to the reasonable solutions, like those mentioned, is already a Sisyphean task. Don't know about you, but I'm not valuable enough contact to keep one more application installed on someone's smartphone to contact me exclusively. "Cut showing off, use what everyone's using!" Even in a rarest occasion when I manage to successively tempt anyone, with the first bug or UX flaw they jump ship and become even more opposite to the idea of trying what's supposed to be a better solution.
I'm sorry to say that but... have you actually tried GNU Ring? It is the least usable IM-thingy I've ever tried.
I tried it in 3 different plaforms (OSX, Android, Linux) and in every case I found (different) experience-breaking bugs (>30min to find a contact, registration timeouts, missing GUI buttons, and so on). Also, you can have multiple devices connected but not all messages will reach all devices, and of course an offline device will not receive messages sent since it was last online.
I really wanted to like it and push for it, but I just can't in its state :(
Matrix/Riot.im works pretty well. It's a bit of a hassle getting the devices verified[0], and (imho) a bit unintuitive about how it shows contacts, chats and rooms. But it works.
[0] Tip: name the devices and remove any you don't recognize, I just have three devices with Riot.im installed but during setup some others appeared, maybe duplicates or a web session, I got rid of those. Less devices is less verifications.
Yeah, it's far from perfect, and I wasn't saying it's ready for prime time. However, it's a much more complex piece of engineering, being a P2P messenger. I'm impressed with the development even considering all the bugs.
You would only use Signal (or Telegram) if you want to talk to other people. Metcalf's Law is a bitch, and neither Matrix nor Ring are going to make it over the bar. They are both far too late to the mobile party and desktop IM usage is not even a rounding error at this point.
An honest analysis would be that the Signal protocol will survive as a part of WhatsApp and Facebook Messenger, and the rest of the secure comm protocols and apps are doomed to a slow slide into irrelevance. Most will linger as a mechanism for making traffic analysis of their users just a bit easier, but in general their future is grim.
That's because they refuse to make it seamless in a way iMessage is. Or Telegram. Both of those will work on several devices, have dedicated clients, synchronize messages and iMessage will transparently use SMS (on all platforms).
Signal does nothing of the sort - it's impossible to backup conversations, they won't sync to a new device, it won't work on a tablet, it's SMS support is buggy and incomplete and their desktop client is based on a dead technology (and limited to a single machine without SMS support). It also doesn't offer anything over builtin SMS/call support like Telegram does. To top it off, it hijacks SMS store meaning you can't even use OS-based software to backup at least SMS conversations.
I can't give Signal to non-tech users and just say "hey, use this instead of SMS", because it won't work and it'll lose their conversations. I can do so with iMessage.
Regardless of your opinion of it, it's not "dead technology" like Chrome apps are, i.e. apps written using it are not guaranteed to stop working at some point.
Yeah, I'm actually more worried about Electron devs manpower/ability to catch regressions on the very big and simultaneously fast moving codebase where the upstream project doesn't really care about their use cases. This must be total PITA. Otherwise it's an ok platform, I guess.
My guess is it's because it still feels a little rough around the edges as a chat application, which shows its open source origin (most open source projects lack sufficient funding, etc)
Every 6 months or so I try pushing it onto "normal" people, and then I realize something is not working quite right. A while ago it was the Signal desktop app that wasn't importing contacts. I also have an issue now where I can't delete/hide a contact from the contacts list in there, even though it doesn't appear on the mobile app.
Speaking of which, I wonder what's their plan for the desktop app, as I believe Google has deprecated those types of apps in Chrome and I don't think it will work anymore in about a year. I've also used WhatsApp more because the native desktop app seems much more reliable.
Then it was messages arriving too slow (waiting many minutes to be "pushed" as a notification, which is pretty bad for a chat application). I think it still has this issue.
The video call still doesn't seem to work as well as the WhatsApp video call. It seems buggy and the connection is not of the same quality. WhatsApp video calls are more resilient than Google's Duo, too, which switches to audio often.
Even the ringtone the video call uses by default is worse than the one WhatsApp uses. I know it seems like a little thing to complain about, and if it was just this one little thing, I probably wouldn't complain about it. But it's all of these together that still stop me from pressing others too much to use it.
I would also like to complain about OWS/Moxie's inability to "build a community". Yes, many cryptographers and security people like the app for the good tech it uses and such, but the organization is not actively trying to build a community or care much for it from what I've noticed. I think Durov and Telegram work on that much more, and it's important. In fact, it may be one of the primary reasons why Telegram is so much more popular.
OWS/Moxie barely even post on Twitter anymore. They release a blog post every few months. It's hard to "get excited" about the app or want to follow them closely too much when they do this.
I think this is also the reason why they're losing/have already lost an opportunity to become the default secure messenger in the Democratic party to Wickr, which is much more active on outreach and stuff like that, even though Clinton's team used Signal in the campaign and they got a lot of good press for it. But they're now blowing all of that away because of their "silence" and non-marketing focus.
Tracking the changes to the Signal Desktop Application on the WhisperSystems github, it looks like they're moving to an Electron app (like Slack). Thumbs down from me for code bloat, but it'll be nice to have a separate app and not be required to keep Chrome open all the time.
Video calling on Signal works a little differently than WhatsApp to my understanding; it's decentralized and so the quality is lower, but the Signal server manages to keep from collecting any data, and backdoors can't be added (it just sets up the call and then bows out).
> Thumbs down from me for code bloat, but it'll be nice to have a separate app and not be required to keep Chrome open all the time.
In the sense of having a separate instance of Chrome, dedicated to Signal, open all the time:-)
It's probably still the best, quickest cross-platform solution — which is just sad. Although I wonder how bad the current Java compatibility story is: if they used Java maybe they could reuse some of their Android code.
The infuriating thing is that Telegram makes it harder. Some of these have been convinced to give Telegram a try sometime in the past, some actually still use it and like it, but in any case: they believe that Telegram's privacy was good enough, and why would they give yet another app a try now?
Telegram privacy is not "good enough" for a commonly used communication platform. Most messages are actually stored in plain-text on middleware servers.
I'd be surprised if some state actors don't have access most Telegram messages.
If you're switching from WhatsApp to Telegram, you're actually going backwards in terms of privacy, so if that's what you were led to believe, you've been misled.
Not sure if it changed but one of the most frustrating aspects of it has been finding out who actually still uses signal. The few people I knew used it stopped using it and that eventually sealed the deal.
It's a struggle getting privacy minded people to switch to signal, since it requires giving out your phone number. This is especially an issue for privacy minded women. The Signal team really did not think that through.
Is there any messaging app that uses a single chain of US, Russian and Chinese encryption technology so that neither of them can decrypt the whole thing? I would only trust such an app ;-)
I wish there was a way to do signed, git-verified builds for phone apps. Right now even if a project is opensource there's no way to tell that the version I have on my phone actually matches the source code I read in github.
I'm imagining a process where you point Apple or Google to your project's source tree. They download it and do the actual build process, and then the git SHA of the codebase they compiled gets signed and embedded in the build artifact. As a result, I could go into my phone and see the SHA of the code thats actually running, to make sure the developer of an opensource app hasn't quietly bundled in any changes that don't appear in the source tree.
Of course, this is still vulnerable to tampering from Apple or Google, but they have that capability anyway.
I've been compiling and running Signal on Android for years. Every week I check the git repository for new tags, check them out, recompile a new signed build, then update my phone.
Care to share how you do this? Last time I tried, my self compiled Signal wouldn't work with Signal's servers. I just assumed I needed some sort of key. Perhaps my problem was something else?
A self built Signal would go a long way to be usable for me. One that didn't depend on Google Services would be even better.
Sure. You should just open the project in Android Studio and it will download all the dependencies it needs. After that it's more fun to compile from the command line, you just need to create a key and then make sure local.properties and signing.properties are filled in correctly[0] and then run `./gradlew aR` to build a signed release build with your own key.
Doesn't OWS distribute free-software-licensed APKs? Does F-Droid have a policy of not accepting things that aren't uploaded by the original authors, or something?
How useful is this attitude really? I understand the underlying aspiration of creating a 'known' ecosystem, but passive-aggressive callouts like this doesn't do anyone any good. Signal has done us a lot of good, let's keep that at the front of mind instead of trying to impart weird statements like this. Kinda sick of this internet logic.
Why is anything against Telegram FUD but anything against Signal is clear sailing.
I'm dubious about Signal, it has the same issues as most other encrypted communication channels (metadata leakage) but surely competition in this space is good.
Being "owned" by Facebook for me is a large red flag, as Facebook have an incentive to gobble up data- not saying the same is not true for telegram either- the only messenger I actually trust is iMessage but that's purely for reasons of: "Apple has no incentive at all to snoop".
It's not FUD to criticise Signal.
It's not FUD to question Telegrams crypto.
Holding Moxie and Durov to account for releasing servers that can actually be used would be a great help in being able to independently assess their claims. And even then, I might still err on the side of Durov purely for the fact that after doing what he did (telling the Russian government they couldn't do anything to Telegram) he fled the country, lost most of his fortune, his company. Etc.
Can you elaborate on the "owned by Facebook" part? I couldn't find any link between OpenWhisperSystems and Facebook apart from OWS helping WhatsApp integrating their Crypto.
Once you are on the payroll as a contractor or FTE you are in the employee DB table and show up in the internal wiki as a current or former employee. Moxie was a consultant with the WhatsApp team to integrate the signal protocol (putting it into Messenger was done independently out of the London office without direct input from Moxie or his team IIRC) so he should show up if you do an employee search.
Are you sure that is an employee roster, or does it have contractors too? Moxie isn't even his real name, so it seems unlikely that it would be displayed this way if he were a real FTE.
I can imagine that being some leftover from the days when he worked on WhatsApp integrating the Signal protocol, because he works for/leads Open Whisper Systems.
Moxie:
"I understand that federation and defined protocols that third parties can develop clients for are great and important ideas, but unfortunately they no longer have a place in the modern world. Even less of a place for an organization the size of ours. Everyone outside the FOSS community seems to know it, but it took actually building the service for me to come to the same understanding, so I don't expect you to believe me."
Now, I understand Moxie's goal is to (quoting from further down that thread) "make mass surveillance impossible for the world we live in, not a fantasy land inhabited only by cryptonerds and moralists (...) to produce technology that is privacy preserving but feels just like everything else people already use, not somehow convince everyone to fundamentally change their workflow and their expectations.", but still - is that the consensus now? That federated protocols are dead and "no longer have a place in the modern world"?
--
[0] - https://news.ycombinator.com/item?id=15282380
[1] - https://github.com/LibreSignal/LibreSignal/issues/37#issueco...