I somewhat share this fatalist view, but it's still worth iterating on all of this until it's possible for the trusted party to be the user's chosen auditor instead of the vendor.

Unfortunately, the vendors have little reason to facilitate that.

If you use a security-oriented Linux distribution there will be a ton of difference.

* * *

> - You're also trusting a large population of Certificate Authorities (CAs), subject to the post-compromise implications of Certificate Transparency. Only one needs to be compromised.

I fail to see the difference between Web and Native in that regards, in both case the attacker need to both:

- a compromised certificate

- a way to redirect the user to their own server (be it DNS or IP spoofing, or something more fancy like bitsquatting).

With only one of those, both the Web and Native app are safe, and with the two of them, you're screwed in both cases.

> - There are currently no sufficient mechanisms to validate the integrity of web app packages end-to-end. Not even under a trust-on-first-use (TOFU) model.

Would you mind expanding your requirements here? (Especially, what's the threat model you have in mind for which subresource integrity isn't enough but your ideal solution would be).

I suspect they want a browser feature to show fingerprints of the HTML and of subresources possibly to pin a certificate for a given domain.

A browser setting to only load subresources with integrity checks would also help

> I suspect they want a browser feature to show fingerprints of the HTML and of subresources possibly to pin a certificate for a given domain.

You can do pretty much all you want in a ServiceWorker today[1], but I'll advise against pinning certificates, because you'd just be re-marking HPKP again, with the same gigantic footgun.

> A browser setting to only load subresources with integrity checks would also help

A “browser setting”? What's the point if the user need to set it up themselves to be secure? Some kind of linting tool on CI in order to be sure you never include a resource without SRI would be nice though, but it's not really the responsibility of the browser here.

[1]: you can see an example of that here: https://arxiv.org/pdf/2105.05551.pdf (Note that I've just DuckduckGo-ed a quick example, I haven't read this particular paper and can't say if their scheme is particularly good, but that'd give you an idea).

Once a CA gives out one bad certificate, they are done. If your risk profile includes someone being willing to throw away an entire CA to get to you, then you should worry about it. For 99.999% of people and companies, I don’t imagine that is a reasonable concern.

CAs give out bad certificates all the time. Whether they are done depends on the reason. Often people give fradulent information to CAs, which leads to them issuing a certificate. This is usually discovered soon after the fradulent issuance, but for some victims it might still be too late. If the CA proves that it followed due diligence, and this happens rarely enough, they won't be distrusted by browsers.

The difference is, with the App Store there is policies against malware. Furthermore, it's harder to hide such an attack as you can't press a button to deploy a special version of the client just to Joe Doe whose private pictures you are interested in. You either have to deploy it to a large group, or not at all. With js, you have full control over the HTTP server and can give that specific person a specific version of the client.

Yes, the updates are automated on mobile devices, but not under total and full control of the app developer, unlike for websites.

And people do monitor what e.g. the Signal app is doing, or WhatsApp.

I don't agree though that all web-based cryptography is snake oil though. Targeted attacks from the site operator are not the only thing you want to defend from. Say the site operator is asked by authorities to hand over data they store of a specific user. Then the insecure web based cryptography is enough to protect the data: everything that's stored is encrypted.