Live data from Hacker News

Mailpile – taking e-mail back

indiegogo.com

71–80 of 157 posts

Re: Mailpile – taking e-mail back

#72
post #52

Earlier quoted context omitted.

I don't think Mailpile is potentially valuable because it immediately solves the encryption problem, but because it solves the MUA problem. All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail . It is simply not possible to develop a secure email solution if webmail is the only viable option for accessing mail, so most people who would be interested in innova…

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 th…

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.

Re: Mailpile – taking e-mail back

#74

Earlier quoted context omitted.

No, it does not. Take this message: From: anonymous_acct_101@mailpile.is To: anonymous_acct_77@mailpile.is Mime-shit.... DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod== This is quite a secure message and it would be as easy to send as any other email with mailpile or similar services. My point is that security is not a black&white concept. There is a continuous of security, and part of the job of mailpile could be to g…

No. That really looks like another anon.penet.fi. If that is the case, then if 101 (let's call 101 Alice) or 77 (let's call 77 Bob) are using providers that are in bed with the NSA, the NSA can easily still grab the metadata from this. If Mailpile is the MTA, and the NSA is following the connections to Mailpile's servers they can use time correlation to find out the metadata. Metadata is hard to hide^. Anyway, as the…

Metadata is most hideable (but still exists) in a crowd. At scale (i.e. millions of users) an improved version of shared shared mailboxes like alt.anonymous.messages can be effective. I reckon that it can be effective at a lesser scale if initial participants all generate enough random noise to protect anonymity of the first users to adopt the system. Once it has scaled in users, they can scale back the random noise generated.

Re: Mailpile – taking e-mail back

#75
post #58

Okay, so we're crowd-funding an email client now? Is there any reason to not just put up all of my random project ideas on indiegogo and see if they get funded? If I'm having trouble financing the development new features for my SaaS application, should I just create a funding project for it? Because I'm really not seeing the difference between that and this...I wish someone could explain this phenomenon to me.

if you think there's potential demand for your product from the sorts of people who fund projects, then by all means you should ask.

Re: Mailpile – taking e-mail back

#77

Earlier quoted context omitted.

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 th…

Is your browser extension a generic solution to the "browser JS crypto" problem, or specific to your application? Solving that problem would go a long way in making secure communication more accessible, but it's a hard problem.

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.

Re: Mailpile – taking e-mail back

#78
Great work guys, it would be great this takes off and introduces PGP to a wider audience. Maybe one day we can stop sending electronic postcards to each other. Now if only someone would restart Mixminion development...

Re: Mailpile – taking e-mail back

#79

Earlier quoted context omitted.

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 th…

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…

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.

Re: Mailpile – taking e-mail back

#80

Earlier quoted context omitted.

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 th…

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.

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
Post reply on HN