With the news breaking that tech entrepreneur Elon Musk could acquire Twitter, we’re seeing fresh calls for Twitter to encrypt messages. That’s undeniably the right path forward, but we need to go even further. You may not realize it, but a broadly adopted protocol that enables encrypted communications — HTTPS — is what makes your online browsing and transactions secure. We can and should do the same thing for messaging services — implement end-to-end encryption (E2EE) technology and protocols to allow for both security and interoperability of private messaging between platforms.
In its recent human rights impact assessment of Meta’s plan to expand E2EE for messaging, Business for Social Responsibility (BSR) concluded that strong encryption is beneficial for human rights. As a technologist who has worked for more than 10 years to protect human rights defenders around the world, this is obvious to me, but it is great to see it confirmed in a major independent report.
It should be clear to everyone now: E2EE is beneficial and desirable to support a rights-respecting society. If E2EE is desirable, then conceptually, it’s also desirable to make secure messaging interoperable across major communications platforms. I’ll explain why.
Why interoperability matters
Interoperability is key to counter Big Tech’s lock-in effect — a.k.a. “walled gardens.” If you don’t have a way to message people who use other platforms, you have no choice but to use the app your friends, family, or colleagues are using. Ideally, a Signal user should be able to exchange messages with someone on WhatsApp, and should be able to do so with the same level of security. That is exactly what E.U. legislators have already agreed upon in the Digital Markets Act (DMA) proposal. Yet some security researchers have also criticized the DMA as unfeasible to implement. Some even imply that any attempt to implement this interoperability would necessarily result in compromised security. I agree that cryptography is hard, and cross-platform interoperable cryptography is even harder, but it is by no means impossible. Let’s examine why.
Meta is already doing this
Meta built its own platforms, such as Facebook, and acquired other platforms, such as Instagram and WhatsApp, yet have recently prototyped interoperability of E2EE between those platforms. Thus, the interoperability of E2EE messaging has already been proven possible, if there is an impetus, reason, or motivation to implement it. There are also past examples of cryptographic interoperability that we should examine, for the successes, challenges, and conditions to make it work. Take, for example, the most widely adopted and interoperable cryptographic system in use today: HTTPS, and the Transport Layer Security (TLS) that underpins it. These protocols make it so the majority of web traffic today is encrypted. But how did this interoperability come about?
How open protocols + encryption made the internet more secure
The U.S. National Institute of Standards and Technology (NIST) ran an open competition to select a cryptographic algorithm intended for government use. The fact that the competition was open and visible for all cryptographers to assess and participate in was a major factor in all sectors, not just the U.S. government, adopting the winning algorithm. Meanwhile, the Internet Engineering Task Force (IETF), an internet governance body, proposed making the HTTPS protocol, which Netscape Communications originally developed for its Netscape web browser, a formal standard in 2000. The IETF had already proposed using Advanced Encryption Standard (AES) for their Transport Layer Security (TLS) standard the previous year. So when they moved to make HTTPS a standard, they baked TLS into it. At this point, all the standards were in place to make interoperable encrypted web traffic possible.
The release of robust cryptographic code libraries implementing AES, TLS, and HTTPS quickly followed, but adoption of those libraries into existing internet applications was slow. Many application developers and content publishers lacked incentive to undertake the necessary work to add HTTPS to their apps and websites. When security researchers discovered there were critical vulnerabilities in HTTPS, requiring updates to the TLS and HTTPS specifications, that further slowed adoption. What’s worse, developers that did not want to cut off people still using aging versions of browsers without the new TLS kept their applications “backwards compatible” with the older, insecure versions of the protocols.
It was not until the industry body Certificate Authority/Browser Forum was created in 2005 and began working to keep certificate authorities, browser vendors, and developers of web server technology in sync that things began to move forward again. At the time, the bold leadership of two tech giants, Google and Cloudflare, and one NGO, the Internet Society Research Group (ISRG), incentivized web publishers to adopt HTTPS, and addressed the obstacles to doing so. Google increased the search engine optimization rating for websites implementing HTTPS. Cloudflare created a technology that enabled it to provide HTTPS on behalf of websites at great scale. ISRG created the certificate authority Let’s Encrypt, which provides free X.509 certificates for TLS to anyone who wants one. This leadership is why we now see more than 90% of all web traffic encrypted with HTTPS.
What HTTPS has done for web browsing, E2EE can do for private messaging
HTTPS is now universal, and enables so many of the wonderful things we take for granted: online banking, ecommerce and online shopping, civil engagement with government services, and the ability to protect searches for healthcare information and interactions with healthcare providers, to name just a few. E2EE enables even more rights, to more people, in more vulnerable situations as the BSR report demonstrates. This raises the question: what can we take from the history of TLS and HTTPS, and the experience of Meta in implementing E2EE interoperability across their platforms, to provide universal E2EE across all major messaging platforms?
There are already strong algorithm and protocol contenders for the adoption of interoperable E2EE, such as the Signal protocol, and the IETF’s Messaging Layer Security (MLS) protocol. Code library implementations already exist. Additional standards for E2EE interoperability would be advantageous for application developers, and standards setting bodies should take up the task of creating them. The proposed E.U. DMA legislation also helps, as it creates impetus for large technology companies to work together and focus their energies in a common direction. As it stands today, the proposal even contains wording that mitigates the concerns security researchers have raised. We know E2EE is beneficial for society. Therefore it is desirable. There is already technical momentum with Double Ratchet algorithms. Meta has proven these algorithms work in an E2EE interoperability context. If the E.U. adopts the DMA this summer, we will see significant progress toward E2EE interoperability.
Since E2EE interoperability is both possible and worthwhile, I would like to see less complaining that it is too hard, and more action toward making it a reality, and the default approach for all future messaging applications.