Exactly, with all cryptographic software you are trusting the distribution and update provider, along with your OS. There is always a level of trust.

With an app from an App Store you are trusting at a minimum:

- the vendor

- the App Store

- the update system for your OS

For a web app (via SSL) you are trusting:

- the vendor

- the browser and it's update system

- the OS and its update system

There is barely a difference in a world of auto updating software.

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.

I agree it isn't snake oil, but from my PoV it's barely moving the scale back from the "use an E2E IM to protect against tour state", while either recommending closed source apps or close source origins (downloading an open source app from Google Play Store or App Store who owns the encryption keys is pretty much the same security as close source app)

A jilted jealous former lover dropping a hardware bug in someone's home doesn't really seem that far fetched, but maybe I've been watching too many TV shows. Something off Amazon for < $100 can record audio for hundreds of hours to a microSD card, and it's only active when there's noise.

This line of thinking is analogous to handing competent threat actors a skeleton key to your system with only one condition - the attack must not be trivial - and then you'll grant them full access.

These kinds of attacks can be made trivial with the engineering capability, capacity, and systems employed by large tech firms like Google, Apple, Facebook, et al. even in the context of these firms as third party platform providers, to say nothing of their own first-party software.

These systems can already classify your political views with a high degree of accuracy, and platforms like the iTunes / Apple App Store and Google Play are already designed with the capability to serve different versions of applications to different requestors (think beta programs), in addition to being the signing entity, for package formats that are entirely within their capability to supplement with additional code.

To be clear - it's entirely plausible that one day, the rogue, evil, mean government voted into power by the evil bad party of your choice could compel Apple, or Google, to backdoor all applications going to clients with the same known political views as yours.

You believe this to be too complex or unrealistic to be plausible (Occam's Razor, right?) but in doing so (and lowering your guard to such threat), YOU are the one that makes this go from impossible to possible.

Also, using normative adjectives like "'normal people' shouldn't worry about this in this in their threat model" implies that those who do have competent threat actors after them aren't "normal", but we know that to be untrue - competent threat actors are, to some degree or another, after everyone. There is no need to "otherize" people for simply being aware of this.

Instead of proscribing behavior, consider that maybe individuals are better equipped to understand their own threat models than you are, and explain the pros and cons of various courses of actions, rather than implying everyone who isn't a sheep isn't normal, and everyone who is a sheep doesn't have real threat actors interested in them.

I have to disagree with you, the ability for threat actors and LE to selectively backdoor code on server is important in any TM.

Practicality is dynamic, TAs use the easiest method within the parameters of their objectives. It is reasonable to assume this attack would be the easiest given lack of other options.

By your logic,56 bit DES is fine because most people won't see attackers that spend >$20k to crack their keys. Just like they won't see robbers who spend that much to break into their homes.

Infosec is different than IRL because TAs can attack arbitrary targets easily with little personal risk. Also, hard attacks today can become common attacks a year from now and security for even the 99th percentile of users who get targeted attacks is important.