If the web app is served by your email service provider, your end-to-end encryption scheme is broken and you’ve lost, unless you have the facility to verify exactly what code it is that they’re serving up. The simplest attack model is that your email service provider is compelled to serve different code that exfiltrates the secret from your browser and sends it somewhere else, for your user account only (which would, I imagine, get around things like the AABill’s idea of not introducing systemic weaknesses). Next time you access the web app, you have unwittingly granted unfettered access to all your email.

It’s a similar deal on mobile apps; the situation is probably a little better if it’s truly a native app (by which I mean: all executable code comes from the app store, rather than executing arbitrary code fetched at runtime, as with websites) in that they probably can’t serve you specifically a different version to everyone else (I expect that’d need cooperation from the app store provider—not implausible, I caution) and so any vulnerabilities are more likely to be noticed in any auditing that others may do; but it’s also much worse because there you can’t lock it down with a browser extension that intercepts and verifies all the code.

If your code running on the user’s computer can use the secret provided by the user to access email, your code can steal the secret.

Running the encryption no the user’s computer instead of your own servers is not a panacea, because you still control the code.

So, it is possible to backdoor the JS lateron, but it is impossible to use that for accessing the emails? Could you explain how that works?