[modeless]

The vast majority of users have automatic updates enabled for their native apps which makes the security properties very similar IMO.

And if you turn off automatic updates then you don't get vulnerability fixes. So you're really at the mercy of the people providing your software updates even if we like to pretend that you're not. In the event of something like a world war, theoretical concerns like these would quickly turn into actual concerns.

[tptacek]

Having automatic updates enabled is not in fact the same thing as reloading all your cryptography code every single time you make a transaction. For a very recent and clear example of why, look what happened with xz, and note how you did not in fact get owned up (I'm sure someone did, but the odds are in my favor on this guess).

[modeless]

> you did not in fact get owned up

Not by the specific xz hack that was found. But I guarantee there are a whole lot more that haven't been found. You can't declare victory because we discovered one hacker. Effectively auditing updates for malicious code is impossible both in theory and in practice. As soon as you accept updates you're vulnerable. And if you don't accept updates you're vulnerable because it's impossible to verify that your initial install had no vulnerabilities, either intentional or accidental.

I agree that more frequent updates make a difference, but that difference can easily be in the positive direction too. And I think the overall difference is really not as big as you suggest.

Perhaps it would be useful to have something like a certificate transparency log but for the application code, so it could be retroactively audited on suspicion of foul play, and attacks that supply different updates to different users could be detected by third parties. This would be useful for native apps too.

[dspillett]

> automatic updates enabled is not in fact the same thing as reloading all your cryptography code every single time

It is absolutely the same thing as potentially reloading all the code on a regular basis. If you aren't monitoring the updates then "a regular basis" might as well be every time. Turn automatic updates off (but notifications on) on an android device and watch how many apps sometimes update a few times in a short period.

There is a minor gate in that there will be some cursory review of an update delivered via an app store, where a web server can give you updates literally every session or potentially every request, but that cursory check is not enough to give the level of assurance over js from a web server that some take.

> look what happened with xz, and note how you did not in fact get owned

The xz thing could easily have affected a great many people had it not been accidentally discovered. It shows why the app store model could be a concern as much as the js-from-a-web-server app model, not an example of how such gates truly make a difference. It likely would not have been picked up by the screening done in new app releases in a store, and likely nor would some hidden-ish exfiltration code.

The slow update process whereby changes upstream go through testing periods in "unstable" bleeding edge distro variants before getting into the officially stable ones only made a difference by chance. That upstream-to-enduser latency is much lower for E2EE apps in app stores - I'd argue that the risk is much closer to the web server model than the Linux distro model, and the distro model probably very nearly didn't help.