This seems to argue that accessing a web app (assuming an important piece of software that handles private encrypted data) is no less secure than loading software from a package repository, because a web server requesting the JavaScript and a software updater loading binary code from a server is structurally identical.<p>The obvious response to this is offline signatures: For package managers, app stores, updaters and the like, the integrity of the update server itself doesn't really matter, because the installer verifies a cryptographic signature from an offline key.<p>This argument is acknowledged, but seems to be dismissed without a real explanation:<p>> More astutely, there's also the distinction that either a file system compromise or a key compromise is required to serve malicious code to users with TLS, but software repositories can be architected such that a key compromise is required, through the implementation of offline keys. Despite this, though, there are several examples of secure software repositories that successfully use TLS. This isn't a grave concern (and they probably won't be converting soon) because the decision to use offline keys is palliative, at best, and only marginally increases a system's level of security.<p>> However, I openly concede that there are cases where a software repository can offer a higher level of security than a browser is currently capable of. I plan to discuss this later.<p>AFAICT, this "later" doesn't happen in this article, though I might have missed something. I really don't see why offline signatures are only "palliative". Web servers are hacked all the time, DNS misconfigurations happen, but organizations losing control of their software signature keys is comparatively rare. Why would you give up a very effective level of defense if it's so easily available?