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

Since posting the manifesto a few weeks ago, there has been considerable interest in our ambitious attempt to bring encrypted email and instant messaging to everyone. We think that earning the trust of technical and security-minded people such as yourself is an essential part of that, and in the past several weeks we've had the privilege of exchanging emails with many such people about the details of what we're doing.

Thanks again to those of you who took time out of your days to show interest in our project, providing feedback, advice, and encouragement. This document is borne of a desire to bring the crux of those conversations to light (and to avoid some repetition moving forward)—we know that transparency is a necessary, though not sufficient, aspect of earning your trust.

Parley is primarily trying to solve the chicken-and-egg network effect which has plagued encrypted email since its inception. We're trying to solve other big problems, too, because they are attached to that problem: secure and convenient key management (in such a way that no one can intercept private keys, even if the server is fully compromised), useful inbox search (on an encrypted inbox), a monetisation scheme that is both accessible to everyone and doesn't rely on advertising, all of the UX challenges associated with encouraging strong passwords/passphrases (complicated by the fact that we'll require the user to have two of them, and the most important one can only be changed on the client) and making security levels obvious, plus all of the "normal" challenges that come with creating a product compelling enough to have lots of users make the switch—"just" offering convenient encryption is far from enough.

For a tiny software company that started in Winnipeg, Manitoba, Canada, maybe "ambitious" doesn't even begin to describe it. Nevertheless, here's the plan:

First, a few general notes:

• None of the problems outlined above are crypto problems. Better minds than ours have already solved those. We're using established OpenPGP implementations, SSL/TLS (over which all client-server communications will be carried out), and bcrypt. (We thought hard about S/MIME, but the web of trust ecosystem is much further along with PGP, and we want to be a part of that.) 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.
• Compromises will need to be made. People who are actively evading government surveillance should continue hosting their own inbox and managing their own keys (as should people who just like doing that stuff), but we hope to be a place where they can confidently send their less tech-savvy friends. Parley will be fully compliant with the existing PGP/GPG ecosystem, and is designed in such a way that no one, even with full server access, even under subpoena, can read your inbox except for you. Nevertheless, we intend to abide by the laws of our jurisdiction (currently Canada) and expect our service providers to do so as well (we will be using US-based Amazon Web Services to start). That means that we could be compelled by subpoena to provide user data including a record of when messages were exchanged, whom with, and the subject lines of those messages. Again, the intent of our design is such that the bodies of those messages would still not be released in that situation.
• Parley is not webmail, at least not primarily. We thought hard about building a browser plugin, but in that scenario it would be very difficult to prevent someone from sending out malicious Javascript if they compromised the server or injected it somewhere along the way. There will be a browser interface for sending messages (since that only requires the recipient's public key) and if someone sends a user an unencrypted message while they are logged in they will be able to read it. (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 would allow for SSL encrypted instant messaging in the browser between Parley users (and unencrypted IM with anyone else using XMPP), where the record is still stored on the server using PGP encryption. This feature is mostly a stopgap, but might be useful in internet cafes and the like. The core Parley experience is centred around standalone apps.
• As alluded to above, our most secure level of instant messaging is PGP over XMPP, and the default isn't even that—it's simply XMPP over SSL (don't worry, the difference will be made clear in the UI—more on that below). It will not use OTR. OTR is excellent, but storing records of the conversation alongside an entire inbox of emails defeats most of the benefits OTR sets out to accomplish. We don't want to provide a false sense of security, and we do want to store records of each conversation just like emails—securely encrypted, and retrievable after the fact, but only to the people who were part of that conversation. It also happens to simplify the programming (and the UI)—emails and instant messages are each a subclass of messages, but with different transport protocols.
• Anonymity is not a goal for Parley. We certainly welcome the use of pseudonyms, and intend to (optionally) accept Bitcoin for payment, but the system is not designed in any way to protect or hide the identity of our users (to the extent that it is made known to us).

Key Management

Distributing public keys among and on behalf of our users is trivial. When it comes to finding public keys for non-Parley PGP users, Parley will automatically look at popular keyservers when possible to determine whether or not a public key exists for the desired recipient and savvy users will obviously be welcome to enter the recipient's public key manually. If no key exists, the user will be presented with the options of sending an unencrypted message and/or sending an invitation to use Parley.

Private keys are trickier. We are targeting users who won't want to move private keys around with a USB stick, but as developers and administrators we can't put ourselves in a position where we (or anyone else who has gained server access) could gain access to a user's private key—ie. neither the key nor the passphrase protecting it can ever touch our server.

Enter the second passphrase. Whenever users want to install a client, they will authenticate with the server using their "normal" passphrase, receive their bcrypted keyring, and decrypt it locally using their second "special" passphrase. After that, all interaction with the installed client and the server is done using the "normal" passphrase once more, ie. the second passphrase is only used locally during new client installations to decrypt the user's keyring.

This is the major compromise behind Parley: the bcrypted keyring stored on the server reduces the strength of the system to that of the second passphrase rather than that of a key. Bcrypt is extremely solid (it would take years for "regular" law enforcement to crack a sufficiently strong passphrase) so we feel like that's a reasonable compromise for most people.

Inbox Search

Searching a bunch of encrypted text is difficult. We will never reach Gmail levels of search (partly because we're not a search company) but we think we can get close enough for a lot of people. PGP header information is not encrypted, so we have date, time, sender, recipient, and subject line to work with. The search UI will be set up to encourage pre-filtering by these parameters, but quick searches will be possible using "smart" defaults (eg. assume the user is searching for recent exchanges with the person who's messages they are currently reading and having any subject). The client will request messages matching those filters (and merge with messages already downloaded, if there is a local match) and decrypt them in chunks before performing a deeper keyword search on the body of the messages.

Money

Even if we could get advertisers interested in a system that is incapable of mining private user data for them, we think it would be a dangerous misalignment of incentives. There's nothing inherently wrong with ads, but private communication isn't a good place for them—we want our users to be our customers. Of course, that's kind of at odds with establishing a big network of encrypted email/IM users, because a lot of people like things to be free (in the beer sense).

We're still working on this, but right now we like the idea of offering multiple free invites with every paid account (and free beta access for anyone on the pre-beta list) at a price point close to $5 per month. Our hope is that users who receive the free invites will feel motivated to "pay it forward" if they like Parley, and people who can't or wouldn't pay for the service will be able to get a free invite from a friend.

User Experience

There are enormous UI and UX challenges to overcome, many centred around the creation and usage of multiple passwords and the importance of denoting the different levels of security at play (unencrypted and outside of Parley, so a cleartext version exists on another server, unencrypted but with another Parley user so all storage is PGP encrypted and all transfer is over SSL, and finally end-to-end PGP encrypted).

The levels of security will be abstracted by some form of "high, medium, and low" with clear visual indicators as to which messages have been sent which way (and an obvious way of switching between them when possible, with sensible security-focused defaults). The password challenge is something we're still thinking a lot about—the concept of the user having two passwords or passphrases isn't inherently challenging, but making it clear when each is to be used will take some work and encouraging the creation of strong, memorable passphrases is an age-old problem to which we cannot yet claim a perfect solution.

The search limitations described above present their own UX challenges as well, and email inboxes themselves are ripe for UX improvement. We're taking user experience seriously, partly because that is what we do and partly because we feel that's one of the big pieces missing from existing encrypted email systems (and IM, but possibly to a lesser extent).

Conclusion

This was long, but it beats hijacked message board threads and email essays where we're bound to forget things. There is probably still a lot missing from this document—we'll try to add to it as we go, and maybe put together a separate FAQ at some point that is more easily digestible. At any rate, this is our honest attempt at explaining the details behind what we're doing. We hope it makes sense, we hope you like it. Whether you like it or hate it, we hope you send us love/hate emails and sign up for the pre-beta list for free access to the beta when it's ready.

We are Parley.co :)