[chrismorgan]

You now trust the provider’s JS not to be hijacked. I know of no good infrastructure at present for managing this risk; at the very least, you’ll need an independent browser extension for auditing all the code and ensuring that no unaudited code is permitted, and you’ll need the provider to support it in some measure as well, so that the service doesn’t break when new, not-yet-audited versions of the code are rolled out.

[quickthrower2]

Yep it’s a tricky one. It has to be hosted on a domain you trust. Maybe if it’s on IPFS that’s kind of better but any registered domain name is at risk of being hacked or even DNS itself.

[chrismorgan]

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.