

Parley.co Project Outline: Encrypted Email and IM for Everyone - napoleond
http://parley.co/outline.html

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

~~~
napoleond
Thank you so much for your thoughts! In order:

\- 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!

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

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

~~~
napoleond
Wow Thomas, thank you. I think I might have to frame this.

------
peterhost
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
Your blessings are worth a lot to me; thank you Peter.

------
rdl
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
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 ;)

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

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

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

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

------
rdl
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
Ryan, your confidence means the world to us. Thanks! (And we'll try not to let
you down!)

------
Jabbles
Why is your site not (yet) available over HTTPS?

<https://parley.co/>

~~~
napoleond
Because it's just a static public site. The Parley.co service will most
definitely be served over HTTPS :)

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

