[dspillett]

> You have to trust the server not to corrupt the JS context to exfiltrate secrets.

Yes, you do have to trust the web server(s) in that way so it isn't E2E in that sense. Though with native code E2E you need to trust the source of your app (and subsequent updates) similarly so it isn't entirely different.

You are still protected in cases where a third party attacker gains access to the data but not access to subvert the web server(s) so they send code to perform exfiltration, so there is more protection than with just TLS (or TLS plus plain encryption-at-rest).

Whether this is useful or pointless is going to be dictated by your threat model, though I'd agree it might be worth having some sort of disclaimer stating that the E2E promise might not be as solid as for other systems. Thought said promise may not be as solid elsewhere either: have you verified WhatApp's code at all? (not picking on them intentionally, just plucked them out as the first example that sprang to mind, the question is more valid with less well known services that are less likely to have any worthwhile independent checking/oversight).

[tptacek]

Right, I'm trying to figure out a coherent threat model that this addresses, in which the client-side cryptography really is load-bearing.

[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.

[saurik]

Some people finally are -- and, frankly, all of them should be, though that's another argument -- building web applications where the code for the web application itself is being loaded off of a decentralized system via a newer protocol or a gateway that they can control and which verifies the hash of the site being loaded. Also: even for services like WhatsApp Web, there are browser extensions such as Code Verify that provide most -- if not "all" or even "more than" -- the benefits you supposedly are getting by having your automatic updates re-distributed via a third-party package manager.