Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My company is working on this: http://parley.co

EDIT: As mentioned a few times elsewhere on this thread, the biggest barrier to encrypted email adoption is the network effect, ie. both ends need to be using it. That is the core problem we're trying to solve--making an email system that would be better than the rest even if it weren't encrypted, but that's the icing on the cake.



If "works anywhere on any device" means it crypto code is loaded over Javascript without browser extensions, that's a goal that cannot share a project with "make it impossible for admins to read email even with a subpoena".

The reason it's 2012 and there's still no universal solution for encrypting email is that it's a hard problem. If you care about the security of your mail, you should use GPG.


We are in full agreement. Parley.co does not use Javascript crypto or browser plugins, ie. it is not webmail. (There is a webmail component that can be used to send messages which are encrypted at the server, and can allow synchronous two-way communications for logged in Parley users that is not end-to-end, but it is only provided as a stop-gap and the trade-offs are clearly presented. Discussing it usually ends up as a distraction, since our core offering is based on installing standalone clients.)

We'll be posting more information about the whole thing soon, but if anyone has any questions I'm always happy to discuss what we're doing either by email (in my profile) or (at risk of derailing the thread) here.

EDIT: Also, Parley uses OpenPGP. People who are happy with their PGP/GPG setup should continue using it, but the goal is to create a compatible service which those people would feel comfortable recommending to less tech-savvy friends.


Don't blame subpoenas for the problem of spineless admins that will actively hack their clients because the government asked them to. Backdoors can't be mandated by a subpoena, only the recording of server-side data (unless I am grossly misinformed).


This is why I like OTR clients. You just check a box and if the other client has it, it automatically starts an encrypted session. Otherwise it works normally. It's seamless. And it gives you forward secrecy.


Very interesting project. Since I watched the "what happened to the cryptodream" video, I have finally begun to understand that we need more tools like yours or say Wickr (closest to secure IM on ios...), tools which my mother who know shit about aes but know her history and what an enigma machine was, can use.

The fact that your code will (?) be opensourced, is a big +1 The fact that it's secure by design is a big +1

Count me in, and go defeat gmail, icloud, and all those monstrosities,... one user at a time !


Our code will absolutely be open source, and relies on established open source crypto libraries for the actual crypto. Thanks so much for the encouragement peterhost, and please tell your friends about Parley!


where are your servers located?


USA, with backups in Canada (we're a Canadian company). But the whole point is that not even us, with full server access, should be able to access your data (even under subpoena) so using third-party servers close to where we expect most of our users to be shouldn't raise any eyebrows.

We would eventually like to offer multiple options for server location, but that isn't feasible in the short term.


I think there is a real business opportunity in hosting email offshore for US customers, out of the reach of US laws and subpoena's.

I know you preach encryption, but there is a lot that can still be subpoenad outside of the encrypted message payloads, such as login IP addresses, destination email adresses, frequency of messages, etc.


That's a really good point, and I agree. Offering multiple server locations is definitely on the road-map, but doing it well (ie. without providing a false sense of security) is an entirely separate and mostly legal challenge--as a Canadian company, we would be susceptible to mutual legal assistance treaties with the US, so we'd have to set up companies in a few different countries with different legal environments and then lay out the trade-offs in a transparent way.

Hopefully, we'll get to it, but if another startup gets there first we'd be much obliged ;) In the meantime we will focus on the big problem that's already right in front of us; I would encourage anyone who needs to operate outside of US legal influence to use a different mailserver (perhaps their own) and manage their own PGP keys.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: