Hanno Böck, freelance journalist and hacker.
Writing for Golem.de and others, writing monthly Bulletproof TLS Newsletter.
Fuzzing Project, funded by Linux Foundation's Core Infrastructure Initiative.
Running free software friendly hoster schokokeks.org.
Combination of well understood technologies with smart innovations that allow forward secrecy in asynchronous mode.
Sane crypto isn't obvious. A lot of apps use very questionable crypto constructions (notably iMessage and Telegram).
Signal encrypts all messages. There is no fallback to unencrypted messages in any circumstance.
While Signal technically is free software it doesn't feel like free software.
You can change it, but then you're no longer welcome in the Signal ecosystem and can't send messages to other Signal users.
"[...] SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s. To answer his question, that's how far the internet got. It got to the late 90s.
That has taken us pretty far, but it's undeniable that once you federate your protocol, it becomes very difficult to make changes.
XMPP has a wide variety of encryption technologies, yet none of them is the default.
In practice applications will often fall back to plaintext.
Never standardized and doesn't play well with existing XMPP features.
No offline messages due to forward secrecy, which means most OTR implementations fall back to plaintext.
Lack of offline messages means it's impractical as a default encryption mode.
OMEMO (XEP-0384) uses Signal-like crypto (forward secrecy, but offline messages still possible).
Needs server support.
Client support is poor (only Conversations and Gajim).
Probably most likely candidate for standard encryption.
XEP-0374 (new OpenPGP for XMPP) contains justification why this standard exists alongside OMEMO (message archiving), but it feels like a poor justification.
Similar feature could be achieved by separating message and storage encryption.
There's now OTR v4 in development.
There's a widespread idea that choice is always good.
Is it good to idealize choice and sacrifice interoperability and security?
HTTPS by default and HSTS is bad, because people should have the choice to be insecure?
Should OpenSSL have an option "enable_heartbleed_bug"?
Should we have X different encryption methods and fall back to plain text every time we can't agree?
There was an attempt to push transport encryption (TLS, not end-to-end) to the XMPP network in 2014.
This seems like a good idea: Get software developers and server operators to agree on network improvements.
Many things optional - not changing the default.
Some of the recommendations are outdated (SSLv3).
Some are contradicting each other (mandatory to implement vs. forward secrecy).
The manifesto was signed by many software developers who didn't implement the recommendations in it.
XEP-0375: XMPP Compliance Suites 2016
Only prosody is currently able to fully comply.
This does not contain any End-to-End-Encryption.
Often efforts are made to establish modern XMPP features, yet they aren't enabled by default, aren't always available and are not well documented.
If you run ejabberd: We're sharing our server config file.
Protocols often have implementation complexities that you don't want to inflict upon users.
This is a concept often inherent to decentralized services, yet it's highly counterintuitive.
The community around decentralized services often prays the "run your own infrastructure" mantra.
There are people who can't (skills) or shouldn't (security risk) run their own infrastructure.
You can get the tools to run your own infrastructure
You should run your own infrastructure
It's totally okay to say people should be able to run their own infrastructure and get the tools to do so, but not everyone should necessarily do it.
Centralized and proprietary services have considerable advantages when it comes to abuse management.
For example: Phone numbers cost money and are often tied to real-life identities.
Abuse management often relies on big data.
We haven't figured out a good way to tackle this.
The web was stuck in the early 2000s.
Microsoft had just pushed all browser competitors out of the marked, Internet Explorer 6 had a quasi monopoly.
IE6 lacked support for many modern CSS features, yet development of IE had basically stopped.
The situation is often considerably simpler: A server and a client.
In many cases the server doesn't even need any software support for modern features.
Browsers have well-funded, highly qualified development teams.
HTTP/2, Brotli compression, WebP images and many other modern web features are performance improvements.
It's okay to support them opportunistically - use them when they're there, fallback to older technology (HTTP/1.1, gzip/deflate/no compression, PNG/JPG images).
The same isn't true for security features. Fallbacks have security implications. ("Use crypto if it's there, fallback to plaintext if not.")
A considerable amount of effort has been put into making HTTPS the default.
With HSTS we have a mechanism to set defaults for certain domains.
We're not even close to disabling HTTP.
Yelling at Moxie probably won't help.
Nobody is stopping you from creating a messaging system as secure as Signal, but at the same time free of proprietary dependencies, decentralized, federated and whatever else you wish.