While I'm reasonably sure GPG/encfs on my phone will reduce my exposure to "dragnet style, intercept and archive everything" surveillance, if the NSA are after _me_, I've no doubt that there are people at the NSA who've already worked out how to coerce Apple into pushing a software update to my phone that sniffs around with root access looking for things that look like private keys, and keylogs things that look like passphrases - and ships them all off to Utah.
(And, truth be told, I strongly suspect all my Windows and Mac OS X boxes would fall in exactly the same fashion, and it wouldn't surprise me too much to find the firmware in my bios or USB bridge or ethernet adaptor or hard drive on my linux boxes is equally traitorous and ready to "sell me out"…)
And yeah, I hadn't followed your links, and made poor assumptions about your project. I just briefly skimmed through some of them and I've got a question - have you got a way to protect the passphrase from ending up somewhere the browser can see it? (or, if the decryption is "passphraseless" from the browsers point of view, how do you ensure rogue javascript could pass encrypted data in and retrieve cleartext?)
One of the factors which can narrow the scope of attackers is to use products like crypto stick, but then again what is preventing a computer from being rootkitted and having it's keys stolen as soon as they are exposed in the system?
Developers can of course only address weaknesses in what they have control over. We can't stop your computer from being infected by neither rootkits nor rogue JavaScript from plugins that you have volontarily installed. My advice would be to be careful and audit everything that may be a threat in order to at least try and minimize the risks. Unfortunately I don't think many users do that but it's not something we as developers can address and prevent.
The dilemma here is the same as with filesharing: if it's accessible it can be copied and transferred. There's no patch against that.
If you see encryption tools that others have written - and all you can imagine is implementing them in insecure ways, then that's your own issue.
"(And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfortable having my private keys and passphrases hanging around in the process space where rogue javascript and/or plugins might be able to scoop them up…)"
Your sarcasm is entirely valid, but you didn't actually look at the project that you are criticizing. The entire point of what I linked in my comment is that nothing critical should be exposed to the JavaScript, just an API that it can interact with to send commands to: such as keygen, verify this message, send cleartext and receive ciphertext in response, etc. You're preaching to a believer here, :-)
Your ~/.gpg/ is -not- accessible to JavaScript. The interface, the GnuPG binary, is. That's the point. Now we can both agree that exposing private keys in such an API is a bad idea.