The terrifying thing is that they could be required to keep doing this in the background indefinitely, compromising both all the data and any future users -- sort of like the Hushmail compromise.
Using AWS the way cpercival does for tarsnap (with keys managed outside, and S3 as dumb storage) is reasonable. Using AWS to run a game or other toy app is reasonable. Using AWS if you yourself are a USG entity (and thus immune to lesser legal action) is fine.
I can't imagine using AWS (or any outsourced cloud provider) to run sensitive apps using current EC2-type technology in the current legal climate in the US. The other scary thing is AWS is probably among the best providers for technical security, and still has this vulnerability (disclaimer: I haven't yet checked out Google Cloud Engine much).
Colocation or managed hosting is borderline in some situations too (particularly if you allow the provider unlimited access to singleuser mode on your boxes, don't encrypt drives, manage keys and credentials through the provider, etc.), but it's a lot better than virtual hosting for anything at all sensitive.
It's not just official USG action to fear; it's provider staff or technical compromise as well.
Hushmail had you log in with u/p first, then would serve an applet, which would then download your encrypted private key and you'd decrypt it locally. They used your public key to encrypt incoming mail and store it until you wanted to log in to view it (which is a fundamentally reasonable approach; the problem is compatibility with existing mail clients, and search, but you can solve that by downloading to a local mail client using something "special" and running search locally as well.)
The enemy made Hushmail serve a "bad" applet to certain users which (in addition to decrypting) sent back either credentials or key to hushmail (and thus allowed decrypting of the mail).
There are ways to address this attack but they're essentially in the realm of release engineering and separation of control; you have one group develop, another group serve, another group execute, and the groups have to be mutually distrustful and audit everything that passes between them. This is hard.
The irony is I worked for the company which developed the initial hushmail product back in 1998/1999. It had to be done by non-US Citizens due to export control, so I wasn't involved, but pretty much as soon as it was clear they weren't going to address this (obvious) attack in their threat model, I assumed they were either incredibly incompetent or an active honeypot, so I ceased any involvement and never used the product. (an adequate solution for java applets would have been putting the signing key under neutral third-party control; I don't think a java applet based solution is viable today, since java is such a clusterfuck; I'd just do a secure iOS or Android app instead and stick to mobile users, like silenttext does from silentcircle).
I'd personally skip webmail or even desktopmail and just build something which is mobile-secure-mail/messages/voice.
Silentcircle is my favorite voice product right now, but it's fundamentally doomed (IMO) due to being commercial on both sides. I'd want something where at most one party in every communication is a paid user, and the counterparty uses a free and lightweight app. And/or something with great group management functionality, which it also doesn't do. The market for discrete individuals who both pay for the service and only communicate with other discrete disconnected individuals is kind of zero.
Crypto.cat seems to be a browser extension only model now, which is a lot better. I don't use it and haven't looked at it seriously, so I don't know what kind of auto-updating it does, which would be a problem. Assuming the authors (or someone else in control of their extension-submitting password) wanted to serve malicious code, they'd either need to get users to manually download a "bad" extension, or auto-update. To the extent that the browser vendors can be trusted, this isn't as big a problem -- you couldn't backdoor just a given ephemeral applet, so someone might catch it. OTOH, I think a browser vendor could choose to give a single user a "bad" extension, and could modify it themselves without crypto.cat's involvement, so you can only trust it as much as you trust the weakest of Apple, Microsoft, Google, Mozilla, Crypto.Cat, or anyone who can technically or legally compromise any of them.
Crypto.cat internally implements OTR now, so it has forward secrecy. So all of these attacks are around gaining limited access -- to the contents sent using the exploited application.
The old javascript version was at risk to cloudflare, the crypto.cat team, and everyone else. Plus browser exploits. It was horrible. The worst part was the crypto.cat developers responded very...emotionally...to any criticism of their security, which kind of detracted from the whole thing.
This whole "binaries distributed by a third party" model used on mobile and for browsers does expose a lot of problems. Since there isn't a strong cryptographic signature on the binaries linked to a key uniquely controlled by a developer and securely distributed to the end user and verified in something the user can trust, the platform or store vendors (Apple, Microsoft, Google, Mozilla, ...) can pretty much screw users at will. (they can just use a different trusted key to sign the binary).
The old "distribute source code with PGP signatures or signed hashes of the tarballs" is still the best way to distribute secure software.
My #1 feeling about crypto.cat is extreme envy for the Catalan domain name.
Using AWS the way cpercival does for tarsnap (with keys managed outside, and S3 as dumb storage) is reasonable. Using AWS to run a game or other toy app is reasonable. Using AWS if you yourself are a USG entity (and thus immune to lesser legal action) is fine.
I can't imagine using AWS (or any outsourced cloud provider) to run sensitive apps using current EC2-type technology in the current legal climate in the US. The other scary thing is AWS is probably among the best providers for technical security, and still has this vulnerability (disclaimer: I haven't yet checked out Google Cloud Engine much).
Colocation or managed hosting is borderline in some situations too (particularly if you allow the provider unlimited access to singleuser mode on your boxes, don't encrypt drives, manage keys and credentials through the provider, etc.), but it's a lot better than virtual hosting for anything at all sensitive.
It's not just official USG action to fear; it's provider staff or technical compromise as well.