Thank you so much for trying the application! I apologize again, it is in the beta, and it is hard to test for all environments. I would be eternally grateful if you sent me an email at ofer at enterthemist dot com with the operating system and version. Ill try to fix it right away. Also, it may simply load slowly, could you try running it again and see if it works? Thanks!
Hi, We've been working on this for far too long without releasing it. It is still a Beta and has a few rough edges, but we would appreciate any and all feedback.
Hi, I am building a messaging client that is designed to be cross compatible with all types of messaging (email, sms, xmpp) but more importantly sort / group the messages in an easy to use way. I could really use some feedback on the product and website: http://raven.enterthemist.com you can email me at my gmail address: ofer dot sadgat.
There is a donut place in Berkeley that works very similar to that. The reason for them is that there are a lot of large-scale orders that want the donuts for breakfast (e.g. the school dining facilities).
Hi, I've been working hard on my startup: Raven. It attempts to make email simpler to deal with by letting you separate your messages however you like: by sender, by tag, by group of people. Furthermore, it can aggregate all of the sources of a message (email, SMS, chat, etc) into one contact so that you can see all messages from one person in a single place. For more information, see the website. I would appreciate any feedback that you might have to help me improve on it.
> Your secret sauce, if I understand it correctly, is open sourcing the client side code and providing some mechanisms to assure end users that what they are executing matches the publically published code.
Yes, the js client is fully intended to work exactly this way.
> That makes sense to me, but I don't see why you wouldn't go one step further and store the secret key in the browser plug-in. Is it an multiple-installation issue?
There are a few issues here.
1. The first is the general crypto principle: minimize your TCB. I want the key to have to touch as few places as possible. For this reason, I have plans on moving the keys from the server to a clients machine(s). Doing so, however, involves a lot more problems including: NAT and the lack of a fallback. In the future, when I have more time to work on these details, I want to try and make that an option for people.
2. Another problem with placing the key in the browser is as you say: it allows anyone who is able to access the browser to access your key (including malware and other users).
3. Lastly, where would this key come from (remember rule #1: the server never has access to an unencrypted key)? If it is generated on the local machine that would then mean that you have no way of distributing it to your other machines (or at least not in ways that your grandmother will be able to do). Even if there were some super snazzy interface, it would be prone to attack as well.
The container is abstracted, so it can receive whatever type of js the server wants to send. Specifically, the js that we will use will not be compiled so that it can be verified (and it will also be open source). The main problem with this is that it wastes bandwidth which shouldnt be a problem for two reasons: the architecture can cache the js intelligently and the extension will have a lot of the crypto stuff embedded meaning that it wont need to be redistributed per access.
It is different in that it creates a key distribution interface for the average person. This interface allows things like decrypting emails in the browser and transparent security. It also allows you to know who has security and who doesnt (this allows people to incrementally start using encryption without the headaches of wondering who else is using it). These are problems that are not solved with any PGP type interface today.
I think that what you are missing is that the server stores encrypted keys, rather than no key.
Some key differences are that we do not store your emails, your email provider does. We do not ever, at any point, have access to your unencrypted keys. Therefore, we cannot, even if forced to turn over access to your data. That being said, as with all secure systems there may be bugs. The client however, is (will be) open source so that everyone can help solve whatever problems that may arise. The key point is that the architecture is set up so that we dont ever need access to your keys or data.
As tlrobinson says, the problem is that we dont want you to have to trust us. One of our goals is to minimize the amount of trust you have to place in us. Therefore, we want you to be safe if we are forced to try and steal your keys. See my other comment for more info: https://news.ycombinator.com/item?id=6245617
You are probably correct. In fact, our solution allows for this type of checking explicitly so that we can (when possible) migrate to better protocols. Interestingly enough, I like your analogy because in all honesty, email is simply file sharing with routing and in path storage.
Rome wasnt built in a day, as the saying goes. Our solution here tries to solve a few of the problems to start with. The goal, however, is to maintain a list of urls, sha1 hashes, update times, and a list of verifiers. The sha1 hashes make sure that the js that you have is the one being distributed (although the hash may soon be upgraded to a different one). The update times and list of verifiers are used to be able to update the code as safely as possible. The verifiers are a list of people who sign the code (with a timestamp). This is used to make sure that any individual isnt sending you a modified version of the js. Those are the goals for that compartment of the code, but as is right now, we are the only signers and so the basic point of the extension is so that we ourselves cant update your code by ourselves (you'd have to update the extension). This means that if we are forced somehow to change the js to get your key, that code will be available to anyone who wants to look at the diff where it should be staring you in the face.
Firstly, I want to applaud mailpile for their efforts. Next, I'd like to respond to you with what our product is aiming to solve (because that is what I know best).
> All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail.
We are working on solving this very problem. We do this via js crypto. The main problem with js crypto is modification of the crypto with the transfer. We aim to solve this via having a browser extension be the default js store (so that all the crypto is verifiable by outside sources).
> That way if the anyone compels my VPS provider for access, they just get a bunch of encrypted email.
This is also true of any service which provides end-to-end encryption (With the exception of the plaintext headers).
> So my problem isn't receiving or encrypting email, it's reading it.
We use SMIME for encryption which is supported by a variety of clients: Outlook, iMail, and our own client. For internet mail, as I said, we are working on browser extensions for gMail.
The main problem that this does not solve is the routing and timestamp metadata problem as that is still necessary for the transfer of the email.
Hello, we are working on this startup to help people regain control of their freedom of speech. As we near a beta, we would like any feedback that you have. Also feel free to sign up for the mailing list! Thanks for spending the time to check it out.
> I'm under no doubt whatsoever that if the NSA show up and grab all my hardware, and wave their $5 wrench menacingly, I'll give them all the keys/passphrases they ask for.
True enough, but we could also implement a duress code which would wipe data of your choosing and unlock the rest. There has also been some research into learned passwords (passwords which you dont consciously know, but rather exist in a mannerism of yours. e.g. the path your eyes take when trying to read some lines of code). That aside, no solution today protects against this including your truecrypt partition.
> I'm "sure enough" though, that they can't read my EncFS/GPG/TrueCrypt protected data without me knowing about it.
If they plant malware on your computer (without you knowing about it) would you still be so sure?
What you describe is a simple man in the middle attack albeit executed in a very complicated manner. With public key encryption using SSL you have end to end security under two assumptions: the NSA cannot break the public key structure and that the NSA cannot fake a public certificate. The latter is resolved with public key pinning and the former is highly unlikely.
We are working on a simple end-to-end encrypted email solution with the encryption being nearly completely transparent to the user (i.e. simple enough for the average person to use). Furthermore, with our solution, if the government ordered us to help, we couldn't. Even more, if they steal your computer, plant malware, or do any number of other shady tactics they wont be able to access your email.