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.
Matrix/Riot is too new to have those, they have never deprecated a cipher yet.
Would love to have a chat with you about the issues the people you train have come across with Matrix
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.
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.
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...
[edit: grammar, formatting]
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.
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.)
> one really needs ... trusted discovery
Or an 'introduction' protocol.
(And I'm sure some people are very happy GPG users. But the majority of email users are not and will probably never be)
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).
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.
I find it so ironic that he doesn't "support federated systems" when the Signal is tied to one.
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.
It’s definitely possible, easy, and cheap.
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 mean, they ran their own full MVNO, with their own SIM cards, with their own code on the cards, and operated their own tower.
That isn’t a simple number.
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.
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?
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.
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
Just want to plug Tox: https://tox.chat/
I recommend "Isotoxin" client.
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.
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.
[0] https://github.com/TokTok/c-toxcore/issues/426
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.
Those are not single entity, but federated.
(Or maybe there's a "Signal Lite" I'm not aware of?)
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.
> 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.
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.
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.
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 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.
To substantiate that, I want to add following:
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.
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...