Mailpile – taking e-mail back
indiegogo.com
indiegogo.com
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 repackaging of the pile of hacks.
We need to start again and do it properly and consider: encryption, modern content encapsulation (better than mime), authentication, PKI, secure storage, mandatory authentication/authorisation and SPAM control.
modern content encapsulation / PKI / mandatory authentication / SPAM control.
Does it encrypt the "from" and "to" headers?
Heck, they often get the source IP address and subject line, which is just a bonus.
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 alone a mail server hosting environment or a private key securely.
c) Security is still optional. It uses the same insecure protocols as a baseline.
d) It doesn't solve endpoint / mailbox security.
e) There is no technical information or credibility. It's not been field tested, no security reviews have taken place.
f) PGP only encrypts the contents, not the envelope. The envelope is enough to warrant digging out the $5 wrench and whacking you with it until the key appears.
I'm proposing verifiable mandatory protocol level encryption and authentication end to end (MUA to MUA) which is the RIGHT solution. If there is the ability to plausibly deny a message then that's even better (which goes against sender verification so this should be choosable).
The only thing going for it is it looks like a reasonable webmail client (probably better than roundcube)
Regarding your points: a-d) I assume that mailpile to mailpile communications will be PGP armed by default. It's enough for them to clear this unambiguously (for instance with a STAR next to "secure" addresses or a popup that says "you are sendind a message to a gmail account, be aware that...)
e) alright
f) there are other quite trivial ways to protect identities, such as a pen-name and a starbucks connection. Those are quite useless, however, if the message is not encrypted.
As for a second point F, the identity can be derived from the unencrypted headers in PGP.
Before PGP:
From: bob@alqaeda.org
To: bill@gmail.com
Subject: The snow this year is better at Innsbrook.
But not at St. Moritz.
From: bob@alqaeda.org
To: bill@gmail.com
Mime-shit....
DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod==
Hmm.
> atob("DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod==")
" AJ&, ¢í᢬ *ᢨ£
¢
¨ØjÂ"
From: anonymous_acct_101@mailpile.is
To: anonymous_acct_77@mailpile.is
Mime-shit....
DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod==
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 other posted mentioned, the correct solution is definitely full security across the board, with full encryption MTA->MTA. That needs to happen so it can't be sniffed on the wire. But of course full security between Alice's MTA and Bob's MTA is ultimately pointless when Bob's MTA (e.g. Gmail) is sleeping with Evan (the NSA).
The actual message contents need to be decrypted with keys that only the recipient has access to, and GPG is as good a solution as any for that. You can only trust what only you have. Don't trust Google. Don't trust Mailpile, either.
^ anon.penet.fi was an OK solution, but still was subject to possible timing attacks (and legal attacks since a table exists SOMEWHERE in the universe that correlates your name to your nym).
A nym.alias.net solution is better when you're chaining remailers and using random timing delays.
Deadrops are better, post your message anonymously to a newsgroup/forum/etc via a Tor or other anonymous connection, and your recipient does the same to retrieve the message anonymous. There's no metadata there to capture.
The server decrypts EM2 revealing EM1 and some plaintext metatdata arbitrarily specified by Alice. The MTA random-delays to keep them all out of order, and sends it on to Bob with encrypted body, whatever Alice felt like putting in the plaintext metadata supposedly representing the prior travels, and no attempt to disguise the MTA's IP, etc..
NSA now can see Alice's post to the MTA, but none of the mails coming out of the MTA match the text of Alice's email. The best the wiretapper can do is decide "someone in set A sent to someone in set B", and maybe apply statistical analysis. It is easy for the wiretapper if there are only a few people using this and hard if there are a lot.
The objection will be, but NSA/FBI etc. will trojan the code, coerce the secret keys, make the server deceive users. So the server owner would like to put in something that makes it all unavoidably, and conspicuously break if the code is compromised. Securing the latter behavior remains a problem when the adversary has, one must assume, physical control of the server.
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 problems are inherent in the protocol. Ideally I'd like messages to have exactly one cleartext field - "To" - and servers to be dumb async routers communicating over encrypted channels. Make it computationally expensive, I don't mind: it will send us back to '90s-style "wait for POP download" timeouts, but if it's the price for half-decent security, I'll pay it.
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?
Jk, the main difference is that mailpile wants to be fully web-based, whereas Enigmail is a fat client. I guess they plan on working heavily on key generation and storage (which is typically the sore point in tools like Enigmail).
As for good, it's not even that. See my comment here: https://news.ycombinator.com/item?id=6244196
Also, bear in mind I had the unfortunate job of designing and running ISP mail systems for a number of years so I know the whole stack inside out.
Taking the piss out of the mailpile folks is probably professionally satisfying, on some level, but I think you have to admit that, once your done, we're still left with a fundamental problem. Your objections are perfectly correct, but surely you can appreciate the frustration when folks who should know what they're doing can only contribute a, "well, someone else should design a new email system with these features." Thanks for the help.
Yes, it is not perfect. Yes, traffic analysis is still a problem. Yes, it has not yet been vetted (because it doesn't really exist yet, which I think you have to admit is a pretty good reason). Still, it's better than flapping your arms about, helpfully declaring, "THE PROBLEM IS UNSOLVABLE!!"
If there is only a small flaw in an encryption system, be assured that it will be exploited to break down the whole system. A simple example are all the issues with random number generators producing not perfectly random numbers; yes, it is just a slight problem in an otherwise good solution but that problem completely debases the overall system.
With luck, they'll deliver a good, self-hosted gmail replacement with a secure mail store that's easy for folks to install on their own. That's surely a step forward.
Mailpile will not change that.
At the very least, we need metadata encryption right about now.
End to end encryption and MITM countermeasures should solve the issue, no? Then all the NSA knows is which mail server is talking to which mail server.
I admit, I could be very wrong. Please tell me why.
Email only works at the moment because in this scenario, usually the sending MTA just says "what the hell" and delivers it over the wire in plain text anyway.
The moment you force TLS as a requirement, the internet starts having lots of large black holes in it due to the number of SMTP servers that don't support it (still) or don't have valid certificates. At that point email fails.
However, the moment you agree to it, you are at the mercy of the root PKI (certificate authorities) who aren't necessarily all that trustworthy. Any fucker can buy an SSL certificate and masquerade as someone else. Also don't forget that CRL (revocation lists) exist that list naff CA certs that have been compromised. At that point, encryption fails.
That's why it's fucked - whack-a-mole all over the place.
If the DNSSEC secured DANE records specify that connections to this server must be encrypted, then I guess at that point, you drop the connection and bounce the message back to the sender.
I know of at least the Exim and Postfix projects which are both working on adding DANE support to their MTAs.
Also, even without any certificate verification, opportunistic SSL is extremely useful. It may not be able to stop targetted surveilance, but it can sure stop a large chunk (most?) of the dragnet style surveilance that has recently been reported.
We should do the best we can with our current system until a new system is deployed. We don't know how long we'll be waiting.
The fact that a simple delivery stack turns into a mish-mash of SpamAssassin, virus scanning, DKIM, DNSSEC, DANE, SPF, PGP, certificates, CA's, numerous ports open, severla products and many more TLA's is the problem.
Complexity does not breed security.
I would say it’s patching a hole, and it’s the feasible way to make email secure, rather than throw it all out and convince the world to switch to a new system.
Most (internet) standards evolve this way. That’s the curse of evolving a standard that is already in widespread use.
The problem is that sometimes standards are no longer fit for purpose on multiple levels. At this point, migration is required to new standards.
This does happen quite regularly. Look at IPv4 to IPv6. The change should be of the same magnitude.
We've done this before. First UUCP, then SMTP, then XYZ.
You will use a mail client that requires SSL to connect to our mail server, or one that does support SSL will be provided for you.
Would you ever allow fallback to HTTP of authentication or credit card data? NO! It is time for unencrypted mail transport to die.
Unencrypted email is like unencrypted telephone calls. Imagine how to get the world to switch to using encrypted handsets.
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.
I can't remember calling a landline last couple years, except for public offices and banks.
> Any fucker can buy an SSL certificate and
> masquerade as someone else.
How might I simply buy an SSL certificate and masquerade as https://www.google.com?
Unless they have backdoor access to one of the mail servers themselves (e.g., apparently, gmail).
Even without that, knowing "which mail server is talking to which mail server" could be enough to get a good amount of information. This would be especially true if you're using a relatively small mail provider (like Lavabit) or especially so with your own dedicated mail server.
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 their anonymous addresses informing them of the next large anonymous mailbox you'll be using with other people.
Everyday, your mailclient would download the entirety of all new encrypted messages for your peer group and would parse out your messages using your private key.
Let's say that every shared mailbox is capped at 10GB of total shared mailbox space. Every peer in the swarm using that mailbox replicates that mailbox. Once that mailbox hits 9GB of total messages, your client attaches to a new 10GB mailbox being created with a random set of N strangers. It then takes the address of that new mailbox and mails all your contacts a special kind of "update your address book" message with a new mailbox address and a new private key. Upon receiving that message, their client now knows to send any messages addressed to you to the new mailbox and use a new private key.
This approach makes it nearly impossible to perform social network analysis because your address essentially betweens a cross between that shared box and your private key that only you have.
There has been work done de-anonymizing alt.anonymous.messages [0], but a lot of the attacks all relied on the small number of participants on alt.anonymous.messages using that same shared mailbox over many many years. At scale with many more participants and automatic mailbox rotation, these types of attacks become far more difficult.
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(mix networks, nymservers) and those tools are developed to high enough quality(which is not the case today) , and enough people are using the service , the anonymity achieved can be very high using standard mailboxes.
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.
Regarding multiple keys: Using multiple emails/nym accounts gives you that.
It would be ungainly, especially at first, and just as easy to scoop associations between users (although, not subject lines or other metadata) by tracing the limited paths. As a critical mass were achieved (yay network effects), along with peer-to-peer sharing, you could source route your messages to anyone.
Given this message:
From: reeses
To: hagbard
Subject: fnord
Please immanentize the eschaton at your earliest convenience.
Next: baz
Data:
Ardhrcbeebdhvfdhnzrfgdhvqbyber
zvcfhz,pbafrpgrghe,nqvcvfpviryvg
Multipath routing and multiple recipient support would be possible by having additional Next: headers and the encrypted blob would serve as a sufficient identifier, or input into an identifier generator, to deduplicate messages if a transmission fork were coalesced.
This is off the top of my head, so it's wrong in a bunch of ways, but it's a simple model that could easily be deployed among circles of people who need a degree of anonymity. As in the later days of UUCP, with comp.mail.maps and the like mapping a combination of FQDNs to named hosts, initial, intermediate, or terminal nodes could involve forwarding over (E)SMTP. (foo!{bar|baz}|quux|reeses@example.com) would route through a number of machines, and the message in my inbox would look like the following:
From: POSTMASTER@quux.com
To: reeses@example.com
Subject: (none)
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
PnyyzrVfuznry.Fbzrlrnefntb-arirezvaqubjybat
...
Plus, rubber hose.
SMTP is presumed to go directly between trusted parties, but this is clearly not the case any longer.
I should have just said "TOR back ported to UUCP" and saved time. :)
timely interception of content would be significantly reduced
The thing is, most people are not interested in such security because they don't see themselves as engaged in a race against government surveillance. You want privacy on general principles, that makes perfect sense. But if you're proposing obfuscation of message paths as a temporizing tactic, it becomes attractive of attention because the naturally question to ask is 'what's the rush, exactly?'. If anything, this gives ammunition to the proponents of 'ticking time bomb' scenarios, notwithstanding the inherent flaws in their arguments. I don't really think that the smart response to their claims is to propose that everyone carry loud mechanical alarm clocks, for the same reason that the 4th amendment is not best upheld by advising everyone to carry miniature safes.
I'm not so concerned about the "timeliness" issue on a sub-yearly scale. It was a throwaway possible benefit of using multiple keys, cryptosystems, and decentralized transmission. As one of the elements is compromised by advancements in the art, they can be deprecated in favor of a stronger one.
By timely, I meant that it would be less economical to slurp up everything with the goal of SNA on a cohort of college friends or whatever.
I'd like an increase in the reasonable expectation of privacy with email. I would of course comply with a legal demand, authorized by a judge in my country, to surrender cleartext emails that are on my systems or in my accounts. I would expect my partners in conversation to do the same.
What I do not like, and I think we agree, is the convenient slurping of all the traffic, storing that, and then mining it for correlations with "un-American" conduct.
What I've found to be a more useful explanation trying to explain "security" as we usually mean it is to get to the reason why I think people should have privacy from their government or the agencies to whom they willingly transmit information about individuals. We've come a long way in securing rights for people who are not white, christian (of accepted denominations), straight, men. We have a lot longer to go.
I am really quite uncomfortable with a HUAC-style group having access to all electronic communications. It was communism fifty years ago, it's obviously terrorism now, but it will always be some threat to "national security" that is used as an excuse to be proactive about looking for suspicious characters because of what crimes they may be inclined to commit.
(And I kept using my own boot-root installation on my first Linux box (which could now legally buy alcohol in the USA) until 2000 or 2001, when I tried this "Redhat" thing. :-))
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 innovating here don't even bother. If we can successfully make the transition back to local MUAs, however, we might have a chance to try something new.
Even if we can't leverage it to get a full end-to-end mail encryption, here's why I want something like Mailpile:
Right now, every single email I receive is encrypted. I have my public GPG key on my mail server, and every incoming email that's not already encrypted is encrypted using that public key. That way if the anyone compels my VPS provider for access, they just get a bunch of encrypted email. So my problem isn't receiving or encrypting email, it's reading it. The only real option I have right now is Thunderbird, which isn't great, and is no longer under development. As a browser-based but locally-hosted MUA, Mailpile might be the remedy to Thunderbird that we need.
> 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.
Solving that problem would go a long way in making secure communication more accessible, but it's a hard problem.
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.
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)
And it'll "just work", so ordinary people have a chance to use and trust it too.
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 you hint at in the other comment, there are various ways that third-parties could vouch for the code running on the decryption domain.
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...
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.
I think that what you are missing is that the server stores encrypted keys, rather than no key.
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?
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.
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.
The only way I can think that webmail could be secured is through changing HTTP and HTML standards to allow the web browser to arbitrarily encrypt forms and decrypt elements with keys unknown to the web server plus disable JS inspection of form elements and elements set as encrypted.
I can't imagine the difficulty in getting it through the standards process let alone implementing it securely though.
Sure, if the authorities targeted you specifically, they could probably pry the unencrypted keys from the server's memory (although with considerable effort it it was a dedicated or collocated machine) but widespread adoption of that model would completely stop dragnets. Only narrowly tailored investigations would be feasible, no mass surveillance.
There's a whole chapter dedicated to HSMs in Security Engineering [2], which is available online. There are clever ways to attack them, and yes, the booby trap idea has been done, typically by using something light-sensitive. I'm not aware of any concrete-encased HSMs, however...
It's an interesting topic. That are lots of challenges around them too. It will probably have a battery backup, so how do you allow someone to replace the battery without wiping the keys? Or can only people with access to the keys replace the batteries? That won't work if you're doing mathematical secret sharing, however, since there's no physical way to do that.
[1] http://en.wikipedia.org/wiki/Hardware_security_module
[2] http://www.cl.cam.ac.uk/~rja14/book.htmlAs far as some of the issues you raised like battery replacement, I would treat them as disposable. In the next few years a complete computer will be available for so little that we will consider it disposable. Prepare a server once, enclose it, make sure the only way in or out is an SSH connection. When it's time to set up a clone to replace it, clone everything via an SSH session and trash the first server.
Sure, your local machine could also be raided and the keys grabbed from that, but that's not a problem with using a VPS so much as a problem with your local setup.
It's also the focus of some of the speculation about the unknown demand that triggered the Lavabit shutdown.
Private keys are kept in the domain of a browser extension, so even if your webmail provider served up malicious javascript (via xss or court order), they would not be able to directly read the contents of your emails since they are being encrypted/decrypted in a separate domain.
Ideally the crypto APIs in browsers would work nicer with hardware tokens etc, but until then, at least people can start moving towards GPG without having to trust large, scary, poorly maintained email clients like thunderbird and evolution, which tend to segfault with a terrifying frequency.
Lots of people are thinking about the problems we have right now.
I have been thinking of the following and want to get some feedback on the idea:
ComBoxen! Comm box is a VM image that, when run, launches with a set of services that allow fully encrypted communications between other ComBoxes.
Basically a secure linux distro on full lockdown that will register with a central directory only to state it is online. Messages are directly passed between comboxes when both are online. Messages are stored locally on the Combox until a secure direct connection can be made to the recipient.
The whole VM could be a stripped down truecrypted message store that only talks to others on a trust list.
But that is only one of many things it can do. Could it establish secure end-to-end connections with other people running the same System? Of course. Could you form your own overlay networks? Yes. Could you run email on top of these overlays? Yes, you could. In fact, you could run almost any program over these networks that you could run on a LAN.
This has all been possible for many years. More than a few people know how to implement it.
Whether there is consumer demand (cf. enterprise demand) for this solution is an open question. At least, so I thought.
There's also advantage in offering up a single appliance for people that don't have the technical expertise to set up the necessary services on their own, who don't have a spare i386 they can use, or even people who just want something to work without spending too much time on it.
Secure communication requires parties on both sides to be capable of it, and it stands to reason that more people would buy into a system that provides the capability if you make it really easy to use. Of course, the communication network itself should be fully interoperable with whatever hardware you want to use to connect to it.
The System on a Stick could only be surreptitiously altered by remounting the root device as read-write. This is difficult for any non-technical user to do without instructions.
The System on a Stick is fully preconfigured. Insert Stick, turn on computer and away you go. It is every bit as easy as a new piece of hardware with its OS and configurations flashed on ROM.
I do not see a small, low power, fanless device as being incompatible with a System on a Stick. Plug computers or credit card sized computers should have slots for USB sticks, SD cards or CF cards. And they should be able to boot from them (no on-disk bootloader needed).
Not every consumer may be ready to make a purchase of new hardware. Evidence of this is the fact there are a suprising large number of people still using what we would consider "old" hardware. Desktop PC's in fact. Regardless of a consumer's appetite and budget for new gadgets, certainly they can afford a USB stick, SD card or a CF card. They probably own one already. They might even have a CF card left over from the days when digital cameras used CF cards. The System on a Stick will fit on a 16MB card.
I would imagine most people indeed currently have some i386 hardware, either a PC or a laptop. Thus they have what they need to try out the System _right now_, without making a new hardware purchase. When they eventually make their next hardware purchase (maybe an ARM tablet), they will then have spare i386 hardware.
As the System can run without touching the disk, there is no install anything. It can be used on i386 with OSX or Windows installed without affecting those systems. A user can perform tests of end-to-end connectivity and communications using any smartphone with a web browser.
I like the sound the AdTrap Kickstarter project. An additonal computer ("router") that sits between the user and her modem is I believe the right way forward for solving problems of privacy (e.g. blocking ads) and security (e.g. secure communications), not to mention other increased functionality. I simply wanted to point out that purchasing new hardware is not necessary to get started.
Whatever shape or form that router takes, I think it must be bootable from external media with the bootloader of the user's choosing. Any less means we are purchasing yet another closed system and putting someone else in control. By all means make this router function without any user input (turn it on and you're done). But by no means should the ability of the (more conscious) user to fully control the router be limited. That means open source OS and open source bootloader.
Further, I was thinking of the following scenario for message validation - (this is just a thought experiment, so it really needs some critical examination I am not sure this even gains one anything):
You run two instances of your VM. One is run locally to you - another is hosted. When a message is sent to you from another peer - it must reach both the hosted and the local one to be opened. When both instances are online at the same time - a hash is shared of the message between both instances and the local master can trust and open the message.
When you're locally off line and a message is sent - Thus, if your locally offline - your hosted instance receives the message. When you come online - your local instance will receive the message from your hosted instance AND a hash from the senders hosted instance. If the hash from the sender matches the message hash from your hosted instance - the message is trusted and can be opened. Else it is dropped.
The problem is that all these p2p secure connections can still always be slurped.
The addresses are only within the system and one would never know which hosted instance belongs to what actual address.... (This area needs a lot more thought)
This is a problem for a lot of these ideas, not only yours and mine (see my other post where the difficulty comes down to verifying the server).
Logically, the solution would seem to be a tamper-proof (or tamper-evident) hardware subsystem, working much like the evil, so-called "Trusted computing" scheme, except with the owner having full control of all the keys.
>You run two instances of your VM. One is run locally to you - another is hosted. When a message is sent to you from another peer - it must reach both the hosted and the local one to be opened. When both instances are online at the same time - a hash is shared of the message between both instances and the local master can trust and open the message.
When you're locally off line and a message is sent - Thus, if your locally offline - your hosted instance receives the message. When you come online - your local instance will receive the message from your hosted instance AND a hash from the senders hosted instance. If the hash from the sender matches the message hash from your hosted instance - the message is trusted and can be opened. Else it is dropped.
The problem is that all these p2p secure connections can still always be slurped.
The addresses are only within the system and one would never know which hosted instance belongs to what actual address.... (This area needs a lot more thought)
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 :/).
There are many challenges to overcome and basically as you stated, the whole concept of email needs a complete overhaul. It needs to be secure, distributed and open source.
Unfortunately, much as I'd like to claim the expertise to be able to put all this together, I would need a team of experts to help me solve the problems any solution is going to face and get it to market. This is by no means a one person job, the challenges are hard-to-solve problems and the solution needs to be usable. The reason that nobody encrypts their email now is because the payoff isn't worth the headache of trying to understand what needs to be done. I'm struggling to understand what I need to do to get GPG installed on my computer for crying out loud.
Improving e-mail security, flawed as the underlying protocols may be, is long overdue. We don't promise perfection, but we do have clear ideas about things that can be improved and how. We strongly believe in a pragmatic, backwards compatible approach that helps people slowly migrate to better habits.
For some background on the wider philosophy of the project, check out the slides from my OHM presentation where I launched this: http://mailpile.is/files/OHM2013%20-%20Rescuing%20e-mail%20f... - this project is as much about rebooting FOSS e-mail development and fostering decentralization, as it is about encryption and security.
We will be posting more details to our blog at http://www.mailpile.is/blog/ as soon as we get stuff written down. :-)
This sounds like more of the same of what we've had so far, perhaps with the ability to become a little more mainstream, but I don't see any breakthroughs in terms of encryption here, like say the way Bitmessage is. I think that if we want NSA-proof secure messaging we'll need to come up with new stuff, and not just use the same old PGP with centralized email databases.
This could definitely be a (very short-term) win against NSA if say Gmail implemented PGP in a very user-friendly way, but for something starting from scratch, I'd rather it was a breakthrough in security.
Why even bother with S/MIME? How long until the
government corrupts the certificate for it if Mailpipe
becomes as important to them as Lavabit was, in the
future?
I have a machine with a certificate authority that issues S/MIME certs for us to use internally for sensitive emails. Currently we use Thunderbird and Mac Mail to handle this but people like web mail and we need a system that can run a web interface (or phone app) to handle these certificates.
If you're right - what does Mailpile solve ?
I can set up the CA and generate user (employee) certificates on my own, there's no way the end-user should have to do that. But what's frustrating right now is that the current tools for configuring S/MIME signing and encryption for email either (a) don't exist, or (b) are heinously complicated to use.
Have you ever tried getting S/MIME certificate auth set up in Mac Mail? It's doable but I had difficulty walking my tech-savvy brother through the process over the phone.
If Mailpile has a simple method of selecting a certificate file for an email account then the hard part is done IMO. The process just becomes IT issuing new certificates every year to employees, and employees uploading said certificates through their (web) mail app.
The biggest value here is having a web mail client, hosted locally, that can support PGP/SMIME in a user friendly way. Then signed/encrypted emails are that much easier to configure for the masses.
* A very fast, scalable search engine
I'd like to know how they achieve both without having the keys, and without shipping code (JS, java applet) that has access to the keys.
Also, excuse my lack of trust, but why should I trust a SaaS created by a Google employee, as opposed to trusting a SaaS created by Google ? That makes no sense to me.
If you're worried about privacy, store your own emails. Period.
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.
Sure, why not? No one is stopping you.
> I wish someone could explain this phenomenon to me.
Many people invest small amounts of money in a person or group of people. There are risks, like any investment, and the payoff is a product which the investors will find useful or entertaining.
They tell you beforehand exactly what the payoff will be. If that doesn't sound economical to you, you don't pay in. There's absolutely no deception here. There's no promise of riches. There's just a promise of a product that is worth what you paid for it.
> and you have a risk of loosing it all.
...which is exactly like every other investment in the history of commerce.
If you have a SaaS app that's not open source and you're making money off then it's probably not going to be so successful in the crowd-funding arena - but you're still welcome to try.
So, I guess what I'm saying is:
1) Are you working on an inherently-secure messaging protocol? Awesome! Link to the project?
2) If you're not, shut the fuck up. Any improvement is better than no improvement, and dismissing any attempts to fix some of these problems while you wait for The Perfect Solution™ is why we're in this mess in the first place.
http://www.computer.org/csdl/proceedings/cse/2008/3193/00/31...
I installed the current version last week to have a play. Even in its current state it's very promising - too far away to really be used yet but once it matures it could be a great product.
There's very little that's more demoralizing then spending months cultivating a relationship with somebody in a company you want to work for, getting glowing recommendations, prepping yourself diligently for the interview then showing up to a cattle call where half the interviewers can't even be bothered to show up and the recruiters are a blind mess the entire day.
You aren't even being treated with basic human dignity at that point, there's no respect for your time and you've just wasted a good deal of effort to get into a hiring process where the candidates are selected for non-interview talents anyways...like what school they graduated from or the roll of some dice.
$1 Binary E-mail User: You're part of the revolution, baby! - the revolution that started in the 1960's with the creation of the first e-mail systems.
$8 Futurist Telegrapher: Having not spent a dime on webmail for the last decade, you've realized that the telegraph operators of the world have been keeping copies, and it's time to change that. Thanks for helping us help you!
So what do the contributors actually get for $1 or $8?
Just my 2 cents I guess.
A system like this can succeed, but I think it's too early to judge.
You can't encrypt the message headers, so the To/From addresses, subject line, sender's IP (usually), and timestamp will all be recoverable.
IMHO, the plus for this is that if more and more people move to encrypted communication across the board, it will a) increase the work load of the likes of the NSA and GCHQ, and b) send a message to government.
Nothing, of course, will work as well as people actually voting for real change. Of course the tragedy of that is that after the scary Bush years, the US people thought they were voting for changes, and all they got was more of the same. I despised Bush, but like we Brits used to say about Thatcher, at least we all knew where we stood. (Blair was our Obama, we thought we were voting for change.)
Sooner or later, we will realize we need to break away from our traditional parties, and vote for something very different, instead of voting int he same thing over and over again because we are too scared of fundamental change, and frankly risk.
For now, we are all too spaced out with our retail and media narcotics to notice or want to change.
"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.
Obviously, the vast majority of emails would still be unencrypted, and this does nothing for metadata. But anything that makes encryption less cumbersome to use is a good thing in my book.
I think this is a great product and will contribute but I could not understand this part the about source code
Crowdfunding really is the modern pyramid scheme.