Parley.co Project Outline: Encrypted Email and IM for Everyone
parley.co
parley.co
Some thoughts, in no particular order:
The outline would be clearer with a couple of diagrams.
How do I convince my { family, non-geek friends, etc } to give up their gmail when I send them their free invite to Parley? I'm not above using FUD to win converts, but I worry that apathy, inertia, laziness, and fear of trusting small, unproven companies are non-trivial factors to overcome, even with some really good FUD.
Will this be built on standard protocols? It seems like the answer for SMTP has to be yes, because it sounds like parley will receive "legacy" email from non-parley users and be able to send (unencrypted) email to them as well. But it also seems like there's room for something nonstandard on the client side -- will this just be using IMAP+TLS to fetch the encrypted messages and then decrypt them in the client? I guess my real question is: will there be third-party clients? Is it going to work on my { linux, androis, ios, windows, etc } device?
How are you going to handle the inevitable "I forgot my private password, and now all my email is lost and gone forever, and Parley refuses to help me!" ? (Parley can't help, of course, because it's designed to be unable to recover messages...) This, to me, seems like the biggest UX hurdle. It's like offering the most secure door locks for your underground bunker that are available -- it comes with the risk that you'll somehow lock the keys inside the bunker and then be screwed. (Lame analogy but you get the point.)
> (All messages are stored encrypted, but if they are sent > unencrypted then they are encrypted at the server, and can > be displayed to a logged in user first.)
This makes me wonder about spam handling. The fact that (unencrypted) messages from outside the system will be encrypted at the server seems like a giant flashing billboard with an invitation for DDoS.
When using webmail to send messages, does the unencrypted message hit the server? In general, it seems like the most secure avenue would be for encryption to happen in the clients. (Including fetching PGP keys for non-parley users.)
Regarding key management, what happens when a user needs to create a new private key? Some key revocation stuff will need to happen on the server, but then there are all those encrypted messages out there too. Will those be decrypted with the old key, reencrypted with the new key, and then the old copies destroyed?
A list of the expected methods of attack and how these attacks are mitigated would be nice to see. (Mainly, so I can see how much my security depends on parley's ops team, dev team, myself, and my correspondents, respectively.) In particular, it seems like it's worth mentioning that rubber hose crypto will crack messages when used on either the sender or the receiver of a particular message.
> Everything will be open sourced in time for the beta, and we > will have a security audit performed by a reputable firm before > the beta period is up.
This is great. I like this about tarsnap too -- note that "Open Source" isn't strictly necessary, but "source available for inspection" is a real winner. In fact, tarsnap is IMO a great model for how to behave as a service. Colin is not perfect, and tarsnap has had some bugs and an outage or two, but it is clear you're dealing with a human and the communication and level of openness has been without peer (perhaps more open than some "open source" projects).
The other great thing about tarsnap is the pricing. I don't know if this is practical for messaging (and it would make it hard to handle the free invites), but if you were to charge something like $0.50/GB-month for stored messages and $1.00/GB for sent messages it would provide a disincentive for abuse by users, and seems like it would make pricing fairer (for some definitions of fair). I'd guess that at least for me I'd end up spending around $3-5/month, but I'm a relatively light email user. Spam of course makes it harder to charge for incoming messages.
On the flip side: make it clear how users can get their messages out and return to legacy email solutions. Because if you turn out to suck, I don't want to be locked in. (I don't expect you will suck, but it seems like the easier it is for me to get out, the less likely it is that you'll suck over the long term.)
- We will be releasing less technically-focused promotional materials as we approach the beta. If we can earn the trust of our technical friends to do some pointing and sharing, we're more than happy to do the convincing :)
- Feedback so far indicates a wide spread of platforms being used, so we're shooting for a cross-platform launch. We will use standards as much as possible, including IMAP and SMTP over TLS, but with an extra HTTPS interface for our clients to use. Since the whole thing will be open source, we would love to see third-party clients emerge, but our first priority will be getting the first-party clients to be flawless.
- The forgotten password situation scares us, too. It's a really angry blog post waiting to happen. All we can really do is a) make the risk very clear and b) make the "private password" (we'll need to come up with a better designation for each password) recoverable/changeable locally, ie. once a client is successfully installed, the keyring is only encrypted using the "normal" password so we could either store the private password there too or allow the user to re-encrypt the keyring using a new private password. Part of this falls unnder the category of "UX stuff we're still trying to figure out".
- Spam will be an issue, and I should have included it in the outline (I forgot, and plan to add it at some point). Unencrypted messages hitting the server will be spam-filtered before encryption. We'll have to come up with something smarter once people start sending encrypted spam.
- Using the webmail feature is not the "most secure" because, as you say, PGP encryption needs to happen at the client. In the webmail scenario, the message hits the server unencrypted and public keys are sought out by the server. The rest of the time, all PGP functions occur at the client. Webmail is really just an "add-on" and we're downplaying it as much as possible because it's causing too much confusion.
- I don't see how Parley can be compatible with a revoked key scenario, and in practice I'm not sure how that is different from current PGP/GPG use. Do people re-encrypt multiple GBs of data when they revoke their old key? I would recommend that Parley users in that situation download their old messages and store them however they wish, then create a new key and request that their old messages be deleted (we will try to keep backups separated by user account so that this is actually possible). As always, I'm open to any suggestions you might have, and please let me know if you think I'm understating the issue.
- We'll try to put together some threat profile stuff at some point. You're right that rubber hose crypto can break Parley in a number of ways, as could the usual other deus ex machinas of security (keylogger on the client, etc).
- We are huge fans of what Colin has done with Tarsnap. If we together can be half of what he is all on his own, I think that would count as a success. FWIW, we do mean "open source" in the traditional sense, at least for the clients (leaning towards MIT license), and all code will be "source available for inspection".
- We're not a fan of what Colin has done with Tarsnap pricing. I mean, we like it for us but I don't want to subject "normal" consumers to that. But pricing is hard, so we're still thinking about it a lot.
- Excellent point. Users will be able to export their keyring from installed clients, and all messages will be retrievable via IMAP over TLS. We'll try to make that as clear as we can without confusing less technical users. (And thanks for the vote of confidence ;) We'll try not to suck :) )
Again, thank you so much for your detailed thoughts on this!
EDIT: Good point about the diagrams, too. We're juggling a few balls, of which publishing information is only one, but we'll try to get some diagrams up eventually!
This has little security benefit, since the emails will exist on other servers already (although when I switch mail services, at least my mail will now be stored encrypted). But it would allow me to just use Parley, including for searching or categorising my old messages. I could then delete my current webmail account and there'd be one less insecure node in the system.
IMAP import would bring in old messages as well as category (label / folder) structure. Perhaps there's even a way to pull in Gmail / Thunnderbird / other message filter rules(?). It's all time saved by not having to set things up again.
Most people don't even realize their gmail/whatever account is like them standing naked (literally more naked than any psychanalist would ever dream to see you naked) in [google/whatever]land.
Stasibook is quite good in that regard too. To sortof paraphrase [obfuscated]berg, <<Privacy for the masses is sooo 2008>>.
As long as you keep true to your users, don't store any users metadata except the bare minimum to make the service work, try and be what spideroak is to dropbox, or wickr is to imessage, you have my (worthless but sincere) blessings.
Way to go.
The big thing would be interoperability with everyone else not already using the service (easy for email, harder for IM), and then providing network-effects benefits if both sides of a conversation are subscribers.
The business/group space is a lot more interesting, I think. $500/yr for a few secure mailboxes (5? 10?) would be less work for you than a few $5/mo individual clients.
We've thought a lot about selling to businesses first (and have discussed similar projects with some clients) and may still choose to go that route but:
- Businesses already have access to a multitude of solutions for
secure *internal* communications.
- External communications face the same network problem as consumers,
but are compounded by the fact that businesses are far less likely
to send an invite or buy a "gift" subscription for their
clients/suppliers/etc.
- Businesses are far more resistant to changes in process/UX. We think
UX is going to be a big part of the solution.
- This may be more emblematic of my own ignorance than anything else,
but it is easier for me to think of consumer companies that have moved
"up" to enterprise sales than the other way around. I realise how naive
this sounds, but the purpose of this project really is to make encrypted
email/IM usable for *everyone*--it requires a consumer focus at some point.
I am really rooting for Parley here (along with many other HN readers I assume). Moving towards secure communication methods, however small a step Parley might turn out to be, is key for the long-term survival of the internet as we know it (and even more important to those suffering under oppressive or totalitarian governments).
Out of curiosity, will there be options in the client to either (a) keep private keys un-synced (but still be part of the public key network), or (b) import an existing keyring? Or other mechanisms for someone who is already using PGP, but unsatisfied with the experience, to join without needing to generate new keys.
My biggest issue with sending encrypted e-mail is that none of the people I send it to would know what to do with it. Secure e-mail needs to be more widespread, and it sounds like you guys are taking a good first step towards that.
instant million users.