This seems drastically overpriced. $4k/month for a year just to develop a webmail CLIENT? Crowdfunding really is the modern pyramid scheme.
[deleted]
Mailpile – taking e-mail back
61–70 of 157 posts
Re: Mailpile – taking e-mail back
#62So will this bypass prism-like surveillance methods?
Not at all.
"Mailpile will download your e-mail from a mail server much like Thunderbird or Mail.app and process it locally."
PRISM and other efforts at tracking associations operate at the server and header level, this is not a useful countermeasure. It may reduce the amount of mail you leave on the server -- but so would a reasonable mail reader configuration.
Re: Mailpile – taking e-mail back
#63Earlier quoted context omitted.
Yes. Being a bit Theo de Raadt here, but it's a stupid proposition which makes security guarantees that are disingenuous. a) This assumes that everyone is going to be using Mailpile or something which makes PGP easy to use. This is unrealistic. The moment you fart out an email to gmail, it's useless. b) this assumes people actually understand PKI. This is unrealistic. Most people can't even manage their own data let…
I've spoken to one of the Mailpile guys on twitter, and his answer was that they're trying to improve adoption and implementation of existing standards, before they look at improving transports. Giving their timescales are already measured in years, I don't think Mailpile will significantly change the game. Kudos to them, but they'll just be Yet Another Commercial Pseudo-Secure-Email Seller . I agree that the problem…
Erm, isn't that what Thunderbird and Enigmail were doing/already do?
https://addons.mozilla.org/en-US/thunderbird/addon/enigmail/
What am I missing that Mailpile will do, aside from possibly a better interface and lots of marketing?
Re: Mailpile – taking e-mail back
#64Earlier 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…
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.
Re: Mailpile – taking e-mail back
#65How many times do people have to say this: There is no such thing as secure email. Assume everything is being read. You can't bolt security on (SSL, mailbox encryption, PKI). You have to design it in from the start. SMTP/IMAP etc have crudely hacked on TLS implementations which aren't even guaranteed to be operational site to site. PGP is just an encapsulation which is rarely used. It's a mess. This is just a repacka…
> You can't bolt security on (SSL, mailbox encryption, PKI). You have to design it in from the start. SMTP/IMAP etc have crudely hacked on TLS implementations which aren't even guaranteed to be operational site to site. PGP is just an encapsulation which is rarely used.
They are proposing making an email client that uses PGP. PGP does in fact let you bolt security on and end up with passable end-to-end security. Sure it has its problems (still a single public/private keypair, leaked headers), but it is, for lack of a better phrase, pretty good privacy.
Now I don't know why this is different than all the other email clients that support PGP. I use Mail.app with https://gpgtools.org/ and it works just fine (though I can't figure out how to keep it from signing every single message I send :/).
Re: Mailpile – taking e-mail back
#66Earlier 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…
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.
Re: Mailpile – taking e-mail back
#67Earlier 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…
How trust worthy is the js crypto? For a long time people believed hushmail to be safe: http://en.wikipedia.org/wiki/Hushmail#Compromises_to_email_p...
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...
Re: Mailpile – taking e-mail back
#68Earlier quoted context omitted.
Fast? IE6 was released in 2001 and people didn't start "dropping support" until 2008 or 2009. Unencrypted email is like unencrypted telephone calls. Imagine how to get the world to switch to using encrypted handsets.
GSM communication is actually encrypted [1], albeit lightly. I remember having an unencrypted NMT handset and ditching it circa 2000 in favor of a GSM handset. NMT support was dropped by my service provider 3-4 years later. So transitions like this are definitely possible, though not overnight. Remember the slow introduction of https. [1] http://en.wikipedia.org/wiki/GSM#GSM_service_security
I think the parent comment was referring to end-to-end encrypted handsets. Phone calls are like email in that only some hops are encrypted.
Re: Mailpile – taking e-mail back
#69Earlier 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.
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)
Re: Mailpile – taking e-mail back
#70Earlier quoted context omitted.
Ultimately we need something that is a cross between Skype's old decentralized architecture and alt.anonymous.messages. We can now stream videos of a few gigabytes with a large enough swarm. That should be enough to create large shared mailboxen among several hundred random people that lasts about a month at a time, at the end of which your mail program would automatically mail all the people in your address book at…
Won't mailbox rotation enables attacking it by comparing users in different mailboxes - the users who stayed over some time in shared mailboxes , probably want to communicate with each other ? And few hundreds is a pretty small group if you want anonymity. And according to the presentation in the link you gave(very interesting work on the subject of anonymity) - if messages are posted correctly, using the right tools…
I would imagine that any shared mailboxes should be capped to force mailbox rotation at the exact same time. Once a mailbox hits a predetermined limit, all the peers refuse to accept additional messages. Basically the exodus of users from a mailbox should happen all at the same time. Those users then randomly choose any of the other new mailboxen out there being formed. You would never be with the same cohort from one mailbox to the next. A few hundred randomly allocated and rotated monthly should help. I need to go back through that presentation again. Anyone thinking about anonymity should read it. It's brilliant.
The other thing we need is a way to easily handle multiple keys so that if one key is comprimised then we only get up a small amount of data. Ideally we would want one key per contact, but this of course would be prohibitively expensive computationally because I'd have to compare every message in that 10GB against every key I have per person. However being able to have maybe a half dozen public keys randomly distributed among your contact list would help. A totalitarian government forcing key disclosure with the threat of jail time would have to have all your public keys to determine whether or not you have disclosed all the information you have received. This would do the same for shared mailboxes as Truecrypt did for deniability that additional partitions exist. You can even distribute your keys among the different bootable Truecrypt volumes you have.
At the end of the day, public key disclosure shouldn't be a lookup but a give a key, get a key system. Basically, I would submit a new public key to you via some secure web interface which would deliver a one time message to you at the shared mailbox you're using. At some later date, you generate a new public key for communicating with me (or use one of your current keys in rotation) and send me a message that contains the address of the mailbox I'm currently using and that key which I should use until I revoke it or issue a new one.
Ultimately we need a system that disguises how many people we are communicating with, partitions those people with multiple keys, that affords me plausible deniability since an attacker wouldn't know how many keys or mailboxes I'm using and where the level of security I am afforded is only bounded by the disk space, bandwidth and CPU time I'm willing to throw at the problem. This scales with paranoia.
On top of that we need a system that provides us temporal security. If all my files and communications are partitioned cryptographically by date, I can aquiesce to a warrant that specifically details the dates in which they are interested instead of giving them everything I have. If they have a specific crime they are investigating (which they should have), then they should be able to state the specific date ranges that contain the evidence they are looking for. This prevents fishing for dirt.