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.
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 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.
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.
> 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 :/).
Silly question: If you can trust DNS, and require every client to connect to an SMTP server with TLS/SSL, and only permit SMTP server->SMTP server connections over SSL, how does that not fix the problem?
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.
Did you read what Mailpile is doing? Basically making PGP easy to use which solves the lions share of the issues at stake here with the NSA and your complaints.
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 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.
Agreed, I've been trying to consider an end to end solution. A single site by a single company is a bad idea... easy to shut down... PGP encryption at the client requires delivery of public keys from the desired recipient, but potential man-in-the-middle attacks mean you can't even trust that the public key you're receiving is from the recipient you think it does, your mail server could act as a go-between on behalf of your client software to go get the public key for the recipient, but that's not safe either. In the end, when nothing electronic can be trusted as sacred, how do you encrypt in such a manner as your recipient can decrypt it reliably without it being insecure... plus, if you encrypt messages end to end, how do you handle the issue of SPAM?
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.
We have options already, although we abandoned them once the Internet became ubiquitous. UUCP would allow encrypted envelopes that would only allow trusted nodes to decrypt enough to forward to the next destination or to the local user.
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.
I could route it through the equivalent of a bang path (foo!bar!baz!bob), each step of which is a trusted node whose private key(s) I have in my routing table. Instead of bang paths, however, the envelope could be something as simple as:
baz would receive the "Ardhrcbeebdhvfdhnzrfgdhvqbyberzvcfhzdhvnqbybefvgnzrg,pbafrpgrghe,nqvcvfpviryvg" blob and unwrap it, forwarding it to bob, who would have exchanged keys with reeses.
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|[email protected]) would route through a number of machines, and the message in my inbox would look like the following:
Again, at the beginning, it would just be necessary to know about quux (or just the message fingerprint) and monitor its traffic to identify [email protected] as someone up to no good and watch for sidechannel communications to create a correlation between conversants. "Hmm, reeses received a message at 3:14pm from an unknown source. Ah, he received a phone call from 415-555-1212 at 2:58pm and called that number at 3:18pm." Multiple transmission sources, split messages (torrent file pointing to message, etc.), unconventional channels, and the like could wrap enough layers of encryption (and yes, STO) that the feasibility of a timely interception of content would be significantly reduced.
Hey all! Mailpile tech lead here. Just wanted to say THANKS to those of you who helped make this happen so quickly.
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. :-)
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? And I hope their PGP implementation is really user-friendly.
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?
The way I see it, Mailpile won't be issuing certificates for people to use, they merely enable you to use your existing certificate infrastructure.
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.
* User-friendly support for both OpenPGP and S/MIME encryption and signatures
* 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.
I don't understand, are you generally concerned that Mailpile's web JS can search emails, and therefore has access to private user keys/certificates? I mean, doesn't that just come to whether or not you trust the javascript that Mailpile is writing? I don't think this any less secure than say Thunderbird with respect to PGP/SMIME.
Unless I'm misunderstanding, the goal of the Mailpile project is to create a user-friendly client for an arbitrary (including self-hosted) email server.
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.
Well, we're crowd funding an open source email client. Maybe it's not how these things have been done in the past but I'm happy to pay in advance to get someone to else to do most of the build. I can hack on it once it's more mature and stable.
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.
> If I'm having trouble financing the development new features for my SaaS application, should I just create a funding project for it?
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.
People have the option of paying people to work on projects. I don't see why this is so complicated. If you want to try to get people to crowd fund your project then go ahead and try. If you don't think someone else's project is worthwhile then don't contribute to it.
Each time someone attempts to make email more secure, the HN response is "no use! need to start from scratch, do it right!"
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.
It seems to me it's time email followed the file-sharing industry and moved to a distributed, peer-to-peer system. End-to-end encryption and no servers to shut down... There's a couple of research papers on the topic:
Congratulations on getting the funding. I really hope that over the next 22 days it's pushed much higher so you can develop the product faster.
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.
Maybe the better solution is a completely new distributed delayed messaging system that works just like e-mail, but fixes all the crustiness and problems that we know about these days.
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.
So there are no actual "perks" for the $1 and $8 contribution levels listed under the "Select a Perk" table?
$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?
They get nothing. I think those “reward” levels are just a cute way to trigger anchoring (http://en.wikipedia.org/wiki/Anchoring) and make the job of choosing how much money to give easier by suggesting some choices. In fact, the $13 contributors don’t get anything extra either – they get “access to Mailpile's online source code”, but that’s already available at https://github.com/pagekite/Mailpile.
I would like to mention that the details of this project seem a little sparse. For a truly secure solution, this system will need to (1) define a secure standard and (2) allow domain owners to personally host this system which can connect to legacy mail servers as well as the "new" secure standard. This way, when persons communicate within the same email domain and between secure systems, the communication can be considered secure.
Just my 2 cents I guess.
A system like this can succeed, but I think it's too early to judge.
What bothers me a little is this is basically a reinvention of the wheel for sup-mail, developer by a Twitter developer and was/is very cool (I use it on Mac occasionally for backups of email I have in a Maildir). Maipile would add the web interface, and they just started transitioning to that idea in the sup community, calling it heliotrope.
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.
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...
as ever, the criminals and terrorists have already solved the problem; they communicate privately using closed community forums (search for "carding/carder forums"). The people left using SMTP e-mail are mostly PETA, EFF and other political groups the government is interested in monitoring.
[+] [-] harrytuttle|12 years ago|reply
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.
[+] [-] moxie|12 years ago|reply
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.
[+] [-] samstave|12 years ago|reply
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.
[+] [-] Aloisius|12 years ago|reply
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 :/).
[+] [-] toomuchtodo|12 years ago|reply
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.
[+] [-] modoc|12 years ago|reply
[+] [-] malandrew|12 years ago|reply
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.
[0] http://ritter.vg/blog-deanonymizing_amm.html
[+] [-] harrytuttle|12 years ago|reply
[+] [-] balabaster|12 years ago|reply
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.
[+] [-] sipior|12 years ago|reply
[+] [-] reeses|12 years ago|reply
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:
I could route it through the equivalent of a bang path (foo!bar!baz!bob), each step of which is a trusted node whose private key(s) I have in my routing table. Instead of bang paths, however, the envelope could be something as simple as: baz would receive the "Ardhrcbeebdhvfdhnzrfgdhvqbyberzvcfhzdhvnqbybefvgnzrg,pbafrpgrghe,nqvcvfpviryvg" blob and unwrap it, forwarding it to bob, who would have exchanged keys with reeses.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|[email protected]) would route through a number of machines, and the message in my inbox would look like the following:
Again, at the beginning, it would just be necessary to know about quux (or just the message fingerprint) and monitor its traffic to identify [email protected] as someone up to no good and watch for sidechannel communications to create a correlation between conversants. "Hmm, reeses received a message at 3:14pm from an unknown source. Ah, he received a phone call from 415-555-1212 at 2:58pm and called that number at 3:18pm." Multiple transmission sources, split messages (torrent file pointing to message, etc.), unconventional channels, and the like could wrap enough layers of encryption (and yes, STO) that the feasibility of a timely interception of content would be significantly reduced.Plus, rubber hose.
[+] [-] FooBarWidget|12 years ago|reply
[+] [-] colin001|12 years ago|reply
[+] [-] HerraBRE|12 years ago|reply
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. :-)
[+] [-] devx|12 years ago|reply
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.
[+] [-] mikegioia|12 years ago|reply
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.
[+] [-] jvehent|12 years ago|reply
* 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.
[+] [-] HerraBRE|12 years ago|reply
[+] [-] mikegioia|12 years ago|reply
[+] [-] dangerlibrary|12 years ago|reply
[+] [-] mikegioia|12 years ago|reply
[+] [-] ghc|12 years ago|reply
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.
[+] [-] aidos|12 years ago|reply
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.
[+] [-] nollidge|12 years ago|reply
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.
[+] [-] InclinedPlane|12 years ago|reply
[+] [-] 21echoes|12 years ago|reply
[+] [-] tim_hutton|12 years ago|reply
[+] [-] samuelfine|12 years ago|reply
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.
[+] [-] Fuzzwah|12 years ago|reply
[+] [-] madcat123|12 years ago|reply
http://www.computer.org/csdl/proceedings/cse/2008/3193/00/31...
http://www.freepatentsonline.com/y2009/0144380.html
[+] [-] aidos|12 years ago|reply
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.
[+] [-] bane|12 years ago|reply
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.
[+] [-] brown9-2|12 years ago|reply
$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?
[+] [-] roryokane|12 years ago|reply
[+] [-] umsm|12 years ago|reply
Just my 2 cents I guess.
A system like this can succeed, but I think it's too early to judge.
[+] [-] 616c|12 years ago|reply
https://github.com/sup-heliotrope/
[+] [-] tokenizer|12 years ago|reply
[+] [-] alan_cx|12 years ago|reply
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.
[+] [-] swdunlop|12 years ago|reply
"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.
[+] [-] JshWright|12 years ago|reply
You can't encrypt the message headers, so the To/From addresses, subject line, sender's IP (usually), and timestamp will all be recoverable.
[+] [-] mope|12 years ago|reply
[+] [-] soapdog|12 years ago|reply
I think this is a great product and will contribute but I could not understand this part the about source code
[+] [-] ptaffs|12 years ago|reply
[+] [-] orestmayski|12 years ago|reply