More on E2EE apps for the web: is the web really that bad for E2EE compared to mobile/native? And some (IMO) unappreciated challenges in bridging the gaps https://emilymstark.com/2024/02/09/e2ee-on-the-web-is-the-web-really-that-bad.html
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.

Emily M. Stark

@estark Thoughtful and needed - still reading, but have already learned a few things!

Hot-take observation: one thing I've seen pushback about, that you haven't explicitly called out, is the attack surface of Electron itself - claims of it being a proliferation of patch-lagged browsers with browser security features explicitly disabled. Grappling with that head-on for this topic seems high-leverage.

@estark I wonder if a good solution to the UX problem could be to let the web page handle it.

For example, if a service worker fails to update due to a network error or invalid status code, the old service worker is kept around.
If some kind of mechanism is provided to check the signature of a new service worker before installing, then the existing service worker could capture the error and notify the user in whatever way the developer deems appropriate.

@estark this is a great read- in-browser code verification has long been on the wishlist for @securedrop , especially via in-browser support as opposed to web extensions and such.
@estark thank you for sharing! I’m curious about the ways in which OS vendor app stores help mitigate the malicious app dev threat. Are there examples where gatekeepers have prevented a malicious app update from an authentic dev? Or is it mostly that app devs cannot easily target specific victims, since all users receive the same code from the store?
@sq my understanding is that people seem to value the latter property: that is, the OS vendor would have to collude with the app developer in order to target specific users with a malicious update
@estark thank you for throwing light on this! 🙏 As a web app dev I just wish there was a simple way I could sign a bundle of resources as a package (not tied to a domain) so users could tell it's my build.