E2EE on the web: is the web really that bad?
In my last blog post, I discussed why people often view the web as a uniquely unsuited platform for implementing end-to-end encryption (E2EE). This view is that the web doesn’t offer a long-term trustable notion of what the application is. In that earlier post, I explored the idea of treating the application as untrustworthy and isolating sensitive data from it. In this post, I’m going to pontificate on whether web applications are truly less trustworthy than native applications, especially in an E2EE setting, and if so, how we should bridge the gap. The gap is narrower than it appears at first glance, especially with desktop applications. To close it, though, the devil is in the (UX- and deployment-related) details.
Often, security experts argue that the web isn’t suited for E2EE applications because of the vast attack surface for code injection – abusable by the developer or by an external attacker. For many web applications, a web browser receives and runs code from a zillion servers, retrieved over a zillion TLS connections. Compromising just one of those servers or connections is enough to inject untrustworthy code into the application, likely without detection. This is different from any other mainstream platform, all of which offer stronger statements about the integrity and/or provenance of the application code.
On mobile platforms, the allegedly stronger security model comes from the policies, review processes, and distribution models of app stores, as well as the operating system’s design of security principles and use of sandboxing. Apps are signed with an offline developer key, and usually distributed through a store, with human review against anti-abuse policies and a centralized distribution point operated by the OS vendor. Individually, each of these properties might not provide much in the way of hard guarantees, but together they form a nice defense-in-depth model.
