4 ms·

Parley.co Project Outline: Encrypted Email and IM for Everyone

40 points by napoleond 14y ago

redacted 14y ago
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).
- napoleond 14y ago
  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.
tptacek 14y ago
These guys have their heads screwed on right. Best of luck to them.
- napoleond 14y ago
  Wow Thomas, thank you. I think I might have to frame this.
- d_runs_far 14y ago
  I concur; definitely got the right minds to work on this.
thaumaturgy 14y ago
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).
- napoleond 14y ago
  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.
peterhost 14y ago
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. Way to go.
- napoleond 14y ago
  Your blessings are worth a lot to me; thank you Peter.
HorizonXP 14y ago
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.
gcb0 14y ago
try to include that as the standard IM for ubuntu.. maybe as a pidgin/empathy plugin for the instant messager at first. instant million users.
Jabbles 14y ago
Why is your site not (yet) available over HTTPS? https://parley.co/ https://parley.co/
- napoleond 14y ago
  Because it's just a static public site. The Parley.co service will most definitely be served over HTTPS :)
- deleted 14y ago
  [deleted]
ajdecon 14y ago
I want this to succeed so much. 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.
- napoleond 14y ago
  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.
  - ajdecon 14y ago
    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...
    - napoleond 14y ago
      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.
      - bstpierre 14y ago
        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.
        napoleond 14y ago
rdl 14y ago
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.
- napoleond 14y ago
  Ryan, your confidence means the world to us. Thanks! (And we'll try not to let you down!)
rdl 14y ago
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.
- napoleond 14y ago
  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 ;)
premasagar 14y ago
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.
- napoleond 14y ago
  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).
bstpierre 14y ago
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 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.)

40 points by napoleond 14y ago

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).

napoleond 14y ago
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.

tptacek 14y ago

These guys have their heads screwed on right. Best of luck to them.

napoleond 14y ago
Wow Thomas, thank you. I think I might have to frame this.
d_runs_far 14y ago
I concur; definitely got the right minds to work on this.

thaumaturgy 14y ago

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).

napoleond 14y ago
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.

peterhost 14y ago

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. Way to go.

napoleond 14y ago
Your blessings are worth a lot to me; thank you Peter.

HorizonXP 14y ago

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.

gcb0 14y ago

try to include that as the standard IM for ubuntu.. maybe as a pidgin/empathy plugin for the instant messager at first. instant million users.

Jabbles 14y ago

Why is your site not (yet) available over HTTPS? https://parley.co/ https://parley.co/

napoleond 14y ago
Because it's just a static public site. The Parley.co service will most definitely be served over HTTPS :)
deleted 14y ago
[deleted]

ajdecon 14y ago

I want this to succeed so much. 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.

napoleond 14y ago
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.
- ajdecon 14y ago
  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...
  - napoleond 14y ago
    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.
    - bstpierre 14y ago
      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.
      - napoleond 14y ago

rdl 14y ago

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.

napoleond 14y ago
Ryan, your confidence means the world to us. Thanks! (And we'll try not to let you down!)

rdl 14y ago

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.

napoleond 14y ago
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 ;)

premasagar 14y ago

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.

napoleond 14y ago
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).

bstpierre 14y ago

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 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.)