No, because the provider would be in the position to change the SRI hashes. Sub Resource Integrity protects you against malicious CDNs and so on, but needs a non-compromised HTML page to provide correct hashes.

You could however probably provide a signed entry point via a webextension or so and a an audit trail via a trusted distribution plattform, like addons.mozilla.org. Are there apps which use a mechanism like this?

> No, because the provider would be in the position to change the SRI hashes. Sub Resource Integrity protects you against malicious CDNs and so on, but needs a non-compromised HTML page to provide correct hashes.

Can you not trust the originating site to serve non-compromised HTML if using HSTS and a trusted local certificate store (eliminating MITM as an attack vector)?

Not if the originating site is the potential attacker, which was the initial scenario: Protonmail sending you page that leaks your decrypted mail to them.

There was a way to make a permanent site installation on most browsers using HTML5 appcache, which even the web host couldn't update, but that API is deprecated in favor of the service worker's Cache API.

It's not clear to me that the Cache API offers the same level of security guarantee.

> It's not clear to me that the Cache API offers the same level of security guarantee.

Last I checked it seemed there wasn’t any way to prevent the service worker itself from being updated.

If you can change out the JS payload, you can probably also swap out the HTML which supposedly "secures" it.

If the users had the option of "locking" a JS version with the Subresource Integrity attribute that they are currently using, it might help.

Wouldn't you also need to lock down all the UI code and everything that interacts with the library?

This solves a different problem. Say actor A makes a website and uses CDNs provided by actor B. This protects users from actor B changing their scripts, but not from a malicious actor A. In this case I'm presuming ProtonMail is actor A.