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).
150 tiny orders is like cutting down a forest with a herring. Catering events is where the real cash is at. Large universities like Stanford operate like cities with 100s of autonomous departments free to choose whichever vendor/s they like.
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.
I think you're going to have to work harder to show the value of this. "Make email simpler to deal with" doesn't say anything to me. I also don't see why I would want to use this instead of, say, gchat.
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.
Regardless of how safe it is, the problem is still social engineering hacks, key loggers etc (you'll always have this issue) - just wondering to what lengths a government will go...
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.
So now I really don't understand how this is any different from using Thunderbird and EnigMail/PGP to encrypt your mail - and if I've understood correctly then it actually isn't any different, you are just providing a glossier interface.
I think it's a worthwhile project, but beyond the tech community, I'm not entirely sure how much traction usage will get... Thunderbird/Enigmail is a PITA to setup and use for sure. A step in the right direction, but all m00t unless everyone is using encryption and it becomes the defacto when communication via email.
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.
Lavabit had a similar architecture, only with the password could the server-side email be unencrypted. Although we don't know for sure, it appears that the government insisted that they trojan their client side code to retrieve the password.
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.
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?
> 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.
Thanks for the response. I would look back at some of the articles that came out on the imessage protocol several months back. They face a similar key distribution problem given that iMessages can potentially be delivered to multiple devices. I don't remember if the reverse engineering ever figured out exactly how they cracked that nut, but I seem to remember that there were some reasonable hypothesis.
I imagine that you can then solve those other problems one at a time by implementing alternatives in your webmail client. The interface to the user can stay the same, but you can add additional more secure transports underneath that the client can opt to use when there is indication that the person they are communicating with uses a mail system that supports that upgraded security solution. In the interface, you just need an indicator of what information is being leaked on a recipient by recipient basis.
At the end of the day this is how filesharing evolved... from FTP to Napster to Kazaa to Torrents to Magnet links. They slowly solved each of the attacks out there.
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.
JS crypto makes sense, but I'm confused as to why a browser extension is necessary—you can safely deliver the JS crypto solution over an https connection, so the critical component is keeping the user's private decryption key distinct from their login/password.
Seems a shame to depend on a browser extension—you lose most of the advantages of webmail when you can't log into it from anywhere.
The usual argument against JS crypto is that a compromised (either technically or legally) host could send a malicious version of the code to steal your keys/data.
A browser extension could in theory be used to verify the code against a signature or something to that effect, or it could sandbox the crypto routines and keys from the app itself (though that wouldn't prevent the app from stealing the decrypted data)
What needs to happen for this to become generally usable is for the crypto part to be built into the browser - that way you only need to trust your browser and not a somewhat random plugin, nor the .js being served from a particular server.
And it'll "just work", so ordinary people have a chance to use and trust it too.
Sure, eventually, however I'd be just as comfortable using a plugin from, say, the EFF as I would having it built into the browser. It would be a fine stepping-stone (similar to how Google Gears contained many features which influenced HTML5)
And as I mentioned, merely having the crypto parts and key management built into the browser isn't good enough because a malicious site could still trick you into decrypting data which it could then steal, even if the keys themselves are perfectly safe.
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
Gotcha, makes sense. Still, I wonder if there might be a clever solution which exploits the same-domain policy to isolate the decryption activity from the rest of the app. That would considerably reduce the attack surface if it handles collecting the key and then you just postMessage strings back and forth.
As you hint at in the other comment, there are various ways that third-parties could vouch for the code running on the decryption domain.
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.
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.
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.
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.
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.
I'm "sure enough" though, that they can't read my EncFS/GPG/TrueCrypt protected data without me knowing about it. Not even the data synced to Dropbox/GoogleDrive/Jottacloud.
> 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?
