Dave: thanks for taking the time to write this up, and being open about your approach and the issues you foresee.
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).
My pleasure :) And thank you for your input and kind words. The excitement around the project in the last couple of weeks has been really encouraging; now it's time to put our money where our mouth is and crank out a really stellar product. I would love nothing more than to be a small drop in a big wave.
One small data point: for the one business-class customer I have that would be interested in this, I think they would be willing to pay a factor or two more than $5/month/account (although they would also need archival, which might be outside your scope).
Thanks, that's really helpful. We mostly based that price-point around Google Apps for Business, but besides offering encryption we also intend to offer way-better-than-Google-because-what-couldn't-be customer service, so I think you have an excellent point. Right now we are mostly focused on a) building an excellent product and b) getting a lot of people to use it, but we will keep your advice in mind when we're ready to offer custom domain support for businesses.
We need more user friendly tools regarding online privacy. In this regard (not talking about devs who fully understand and use GPG on a daily basis),... Email is broken.
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.
I love the idea behind this project, and sincerely wish you the best.
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.
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.
We hadn't really thought about importing existing keyrings to be honest, but it seems like a good idea. I can't immediately think of any reasons why we wouldn't do it.
It would make me very very happy, if that's a good reason to do it. :-) The user experience with encrypted email frankly sucks right now, and if you improve it, I think you'll be getting a lot of existing GPG users as well as newbies. But we all have keys already...
Seems like a good enough reason to me ;) The only challenge I see is that those users will still have to change their email addresses (it's not a huge extra step, but we don't want to worry about custom domains out of the gate) and some public key servers make it difficult to remove the old one.
I'd sign up for a "$8/mo plus four invites" plan (i.e. keep it under $100/yr), but not without custom domains. I bought my own domain a decade+ ago for the exact reason that I never have to switch addresses again.
Hmm, interesting, thanks. I don't foresee custom domains being a big challenge, and it probably won't take too long for us to add support, but I would just want to make sure we stamped out the lion's share of bugs first.
This is a great project and team. I talked with them a few weeks ago, and have a lot of confidence they'll make the right choices. It's an uphill battle to get something like this deployed widely, but I have a lot of confidence in them.
The big challenge for something like this is being your "default" mail and IM solution, vs. something you just use for one-off secure messages. My experience is that if you go for the latter, no one actually uses it. $5/mo is probably the wrong price even for individuals -- I'd go with free (on the low end) or $10-15/mo.
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.
Couldn't agree more about needing to be the "default" solution. Pricing is a big challenge... we would ultimately like to offer a free tier that is completely subsidised by business users (and possibly paid consumer plans as well) but getting there is the hard part. We're thinking about fundraising, which would help, but we would still want to have a clear monetisation strategy so that our users know what they're getting into.
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.
As always, thanks so much for your thoughts on this. It's likely that our own ideas will be tempered by reality before too long ;)
To lower the friction for new users to take up Parley, it'd be handy to allow the "import" of an existing email account.
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.
We've thought about this. I think we'd have to charge an import fee; encrypting GBs of data in small, useful chunks is not cheap. It might be something we offer one day, but probably not from the start (especially since, as you noted, there would be almost no security benefit).
I want this project to succeed, and it seems like it's headed in the right direction.
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 h...
- 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!
28 comments
[ 2.5 ms ] story [ 59.8 ms ] threadI 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).
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.
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.
https://parley.co/
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.
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:
As always, thanks so much for your thoughts on this. It's likely that our own ideas will be tempered by reality before too long ;)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.
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 h...
- 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!