I came here to comment about this. Rainloop is amazing.
It also has some extra security features for the end user. For instance, you can tell Rainloop to proxy images from the email and serve them to you instead of your browser getting them from a remote source. It's amazing because you get faster load times and don't leak your desktop IP, only whatever server your running Rainloop on.
The only thing it's lacking is PGP, which is very sad.
That does look nice, looks like they've come quite a way very quickly too. Still a little put off by the idea of host PHP apps for such critical systems but hats probably my internal bias towards using Ruby/Python/Go.
StartSSL [1] and COMODO [2] still offer them (of course, there's still the CA compromise issue you mentioned). Keep in mind, however, that a hierarchical, centralized trust model can still be useful (e.g. in medium-to-large organizations, where having an internal CA and delegating identity verification to a few knowledgeable employees is more practical than having everyone build a web of trust).
> Keep in mind, however, that a hierarchical, centralized trust model can still be useful (e.g. in medium-to-large organizations, where having an internal CA and delegating identity verification to a few knowledgeable employees is more practical than having everyone build a web of trust).
Sure, but it's easy to build that kind of model on top of OpenPGP (just have an organizational signing key and tell everyone to trust that), whereas it's almost impossible to build a CA-independent model on top of SSL.
yes. And it's already supported in many clients without plugins, many companies just sign their mails. You probably don't even notice that if you don't know where to look. It's very unobtrusive compared to gpg.
For everyone who (like me) wondered what happened to "Roundcube Next", they released a statement 8 days ago[1] about it. Sounds like they had personal problems getting in the way. Glad to see the project is still alive.
Thanx for the update, I tweeted them repeatedly, never getting any reply. It looks pretty bad that the last tweet is so old. In the meantime, I've been using Nylas N1 (local mail client) and ownCloud mail (webmail), both have become pretty good!
Oh, thanx for the product! One question, I just read here on HN that Nylas stores certain data on Nylas servers. I actually thought it was just a local mail client like Thunderbird (only better looking and more modern). It's not very clear from the website what exactly happens to my mail and login credentials, do you have some pointers?
It's nice to hear about the server-side PGP support (searching!), although it's unfortunate that the client-side solution, Mailvelope (or more specifically, the OpenPGP.js library it uses), still doesn't support any ECC algorithms.
Fortunately Google's End-to-End extension does support ECC algorithms (no idea if it integrates with Roundcube though), but it seems like it still isn't ready for production distribution on the Chrome Web Store yet.
I may be wrong (and hope to be corrected!), but I think that End-to-End is never expected to be in the Chrome Web Store. I think they feel that this kind of encryption is too complicated for the average user. It's intended more for "power users" who already know that they want it.
They've discouraged people from compiling builds and then uploading it to the store, but I believe this is because they don't want a half-implemented/untested PGP library posted -- especially one with their name on it.
I haven't seen any concrete plans about how they plan to distribute it when it's done, but I didn't get the same sense about them not wanting to upload it themselves. In fact, I think Google would be thrilled to push proper end-to-end support in Gmail.
They couldn't. They would have to show ads from other history and not the email's contents. This would also break features such as (server-side) search and reminders (eg. flight tomorrow) via Google Now.
End-to-end is a tradeoff. But presumably they wouldn't be working on the technology if they weren't prepared to offer it in some fashion. Probably as an opt-in? Hopefully a Googler can offer more insight as I can only speculate.
Or they could run a few algorithms client side on the text, return some sufficiently anonymized data and show ads based on that. So if you are emailing about organizing a birthday party you get balloon recommendations, but if you got a ransom letter with only an address, a photo and a a big number after the dollar sign, they might opt to not send data back to their ad servers.
If they think there is money to be made on this despite the hardness of the problem, they will come up with some okay-ish solution.
Or just make e2e 5 usd/month.
Though I never clicked on any ads in GMail, nor did I see anyone do it, so maybe GMail is not a great source of ad income.
>They couldn't. They would have to show ads from other history and not the email's contents. This would also break features such as (server-side) search and reminders (eg. flight tomorrow) via Google Now.
Sure they could, all incoming emails aren't magically going to become e2e encrypted.
Well, no. But that's not really end-to-end, is it?
If the goal is to make E2E more accessible then eventually more emails will come in encrypted. Maybe Google will let users with the extension find each other, or Gmail might help coordinate that.
Sure, but I'd imagine that most email traffic is automated non-sensitive stuff (i.e. flight confirmations for example). That stuff is simply not going to be e2e encrypted any time soon, if ever.
Are people going to start filling in their pubkeys when they book a flight? What about when they're at the airport and need to pull up the record locator on a different device?
I'm sure more emails will start being encrypted, but that'll mostly be communications between people. Those probably aren't particularly interesting to google anyway.
I'd give it time. People won't enter their public keys when booking a flight, but it might be associated with their email address automatically. I could see Google running a service like Keybase. Or even integrating it further into whatever the next hip "online identity" service is. Built in privacy would be a huge boon.
The flight company (or email sender they use) could then request your public key and send off your message. And with some common protocols and APIs the complexity could be largely abstracted away.
I wouldn't underestimate the technology. When you look at more complex systems like internet routing tables, these problems feel a lot more solvable. We already have the technology for most of this. The problem right now is making it accessible.
They indicate in the GitHub repo that this should eventually be ready for the Chrome Web Store, so they definitely plan on distributing it there eventually.
Worst case, it reaches a more or less "finished" state and Google doesn't upload it to the CWS—anyone else can still upload it since it's Apache licensed. I doubt it will ever come to that though.
"You can [then] access it over the network using your web browser" https://www.mailpile.is/faq/#wha-2 seems to challenge your knowledge. I don't know if using it so compromises privacy in unexpected ways, or indeed even works satisfactorily; I am not a user.
It now indeed seems to be the planned path to create a full webmail service out of Mailpile. Though right now the developers still say its "written as a personal application": https://www.mailpile.is/faq/#tec-8
It's designed to run on your local machine and be accessed by your browser. You can run it on a server if you like, but the give-away is the fact that it only supports single users — the original conception was for personal use.
I heard they're moving in the direction of supporting multiple users, which will be fantastic. Then you really can use it as a proper webmail client for a small email server.
I guess this means you have to upload your private key to the server. I always wonder what happens when the key is copied and used by someone else. Can you revoke the key? What happens to sent and received messages from the past? Do you still need the old key (private or public) to read those? Is there a private master key that can create a private sub key that can be used to upload to that server?
Encryption is also supported via a browser plugin, so it's not necessary to upload the private key to the server. Regarding your questions:
1) yes, you can revoke the key by generating a revocation certificate and publishing it on a public keyserver (of course, your correspondents would need to refresh the public key from the keyserver to know it was revoked, which is something they might not do);
2) sent and received messages from the past, unfortunately, are readable by the person who is in possession of the private key, if such key is not protected by a strong password;
3) yes, you still need the old private key to read the old messages;
4) you can generate a master key (to be kept strictly offline) and several, frequently rotating subkeys for encryption purposes. It's not a silver bullet solution (in the sense that a thief would still have access to all your subkeys, meaning he could read all your messages up to the point the keys are stolen, but it mitigates the damage somehow). See here: https://alexcabal.com/creating-the-perfect-gpg-keypair
Yes, you can revoke the key and publish the revocation. This means that it will be flagged as revoked in the server keys and assuming that senders keep their GPG keybase up to date with server keys, they'll get a warning that this key is out of date. All e-mails already encrypted with the key can still be decrypted though.
As for the second part of your post, you're probably asking about this:
If you generated a revocation certificate, yes, you can revoke it. Otherwise no. The private key is protected (should be) by a password, so even in the event it gets compromised it should be OK.
Encrypted messages from the past are unreadable, unless you have the private key. No private "master" that I know of.
If you don't use the browser extension you would probably only want to use this feature if you control that Roundcube instance yourself because yes if you upload it to the server and your key gets lost all past and future communication with that key is only as secure as your keys password.
I still use RC despite the long history of XSS attacks against it. Luckily RC uses progressive enhancement, so it still works with JS turned off. I just assume emails can still execute JS in 2016? Perhaps it's wrong of me to use RC with JS turned off as a preventative measure, but you have to adore that user interface! It's the only reason I choose RC over other self-hosted email web apps (and there are few to choose from in this space). I like the simplicity of Squirrel-mail, but Roundcube looks and feels too good not to use.
You're right. Before any integration of a server-side PGP key like this, they ought to have deployed some basic hygiene like a strict Content Security Policy (CSP) and a better sanitization library like HTMLpurifier. I don't trust webmail software, and definitely not PHP webmail software, to hold my keys for me otherwise.
ha i remember long time ago chasing for the perfect webmail system.. before gmail of course.
Horde,Roundcube, squirrel god... I've never found the perfect one!
nice, I use Roundcube a lot for new clients looking to set up their email for the first time. Glad to support this project, and really stoked it has PGP.
Been using it for a year or so now, it's fantastic and has never let me down.