[zAy0LfpBZLC8mAC]

The problem is simply that you expect the impossible.

Either you give the factual power to access your emails to some party, then whoever you give that power to can as a matter of fact access your emails, and in particular that means that they can be coerced into accessing your emails, or you don't give them the power, then they can't.

You are demanding that they offer a product where they have the power to access your emails (as an unavoidable technical necessity for what you expect from the product) while they at the same time can truthfully state that they can not access your emails. That is simply a logial contradiction that cannot exist, and any PR that pretends that it did would be simply marketing bullshit.

[quickthrower2]

Not sure what you are getting at exactly, but you can provide browser based email where the browser using J.S. decrypts the email. Obviously need to figure a way to make that AA proof.

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

[zAy0LfpBZLC8mAC]

Yes, you can provide such a service. With such a service, you have the power to access the emails. Telling people that you can not access the emails would be marketing bullshit.

[quickthrower2]

Nope because the user encrypts them using their own secret. No access to historical emails but possible to backdoor the JS later on.

[chrismorgan]

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.

[zAy0LfpBZLC8mAC]

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?