The threat model I stated included the future compromise of the second party (the hoster). SRI only helps against untrustworthy 3rd parties (CDNs). So it does not really address the issue.

I've been thinking about this problem for Airborn OS. In my opinion, the best place to put signatures of the "main resource" would be the website's certificate. [1]

I created a Firefox extension that can check signatures both in the certificate and (in the meantime) hardcoded in the extension. [2]

[1]: http://blog.airbornos.com/post/2015/04/25/Secure-Delivery-of...

[2]: http://blog.airbornos.com/post/2016/02/23/The-first-web-appl...

Well if you trust the website at least once, it can load a service worker which will verify signatures of any app/script updates from any party before allowing them to update the locally cached version of the script.

Service workers can get wiped on hard refreshes or due to space constraints. And they are not easily transferred to new devices, unlike packaged applications. They're not a security mechanism.

And it does not necessarily address the compromise of the hoster either, since the attacker who has control over that may also have access to the signing keys. Especially in the case of a court order.

That effectively is a silent, user-targetable auto-update of software to which you entrust your secret data.

Auto-updates for crypto software should be verifiable through other channels, require user confirmation and use a distribution method that is difficult to scope to a single user to make targeted attacks harder.

Trusting someone to honestly serve you a piece of html is an easier thing to develop and check. You can always save a copy of it to your machine and check it and run it from there.

It's true that these are not great against a state level actor deliberately targetting an individual (but then, not much is), but e.g. in a lot of situations I would trust github to serve me unmodified html and s3 to store my encrypted data, where I might have not trusted a single entity to provide me with an integrated solution.

It would be great though if a page could indicate that it is sensitive and then if the browser sees it change it pops up a message on the client giving the user a fingerprint and notifying them of the change.

If I publish my application on GitHub, how can you know for sure I didn't make changes on the server side? Appearance looks the same m, hence why SRI only solves the front end trust, but the entire as a whole remains a blackbox, thus what previous OP meant.

Depends on the app. If you are making a storage app then you can do client side encryption so that it doesn't matter if s3 is compromised, they don't have access to your data.

SRI means you don't have to worry about your js getting modified so all that's left is the html. My claim is that there are lots of situations where I can trust something to serve html honestly enough for my use.

It is possible that my bias for web apps that connect to real services (of the sort a desktop app might) rather than as a thin veneer over a black box service gives us a different perspective.

But I do ultimately agree that some support for enhancing trust in the initial html document should be built into browsers. I guess such a thing should involve being able to get a hash of the actually downloaded and running code and document and being able to postpone an update until I've had the opportunity to check it's legitimate.