Secure messengers have long wrestled with how to balance contact discovery process with protecting both the privacy ofusers’ identity and their contact lists.
Each product team makes its decisions on how to design its apps based on the security and business models at the product’s core. Often, the choice is about balancing user privacy/anonymity against growth opportunities for the user base — obviously, such choices are never easy nor can they be made lightly.
We have been following with interest an ongoing conversation about Signal’s design choice for contact discovery. I’d like to run through some of the points made in various blog posts and comment threads to help our users and public at large understand a couple of things: 1) the inherent conflict between helping users with contact discovery vs. maintaining user privacy and trade-offs this conflict imposes; and 2) how Wickr navigates this conflict when making its design choices in both Wickr Messenger and our business products.
Let’s start at the sign-up process. When a user joins a social network one of her first tasks is to build a contact list. To facilitate this somewhat arduous procedure, networks often opt for linking user IDs to pre-existing identifying information such as emails or phone numbers. The idea being that a new user perhaps already has that information for their closest contacts, so why not make it easy to populate one’s address book within the app?
Most social networks also allow users to automatically check which of their known contacts already have accounts on the network. Yet, revealing user contacts to the network’s server is bad from a privacy standpoint. More privacy-aware systems only allow users to upload a one-way hash of each contact’s ID rather than send the ID in the clear.
An inherent downside to assisted contact discovery is that it enables an attacker to enumerate IDs by creating an address book with a list of potential IDs and joining the network to find matching accounts. In fact, even without assisted contact discovery other techniques may be available to an attacker so he/she can enumerate IDs with associated accounts. Thus any network is faced with a trade-off between usability and the anonymity of its users, often expressed through a policy governing what can be used as an account ID.
The enumeration attacks can become a real concern if IDs are not thoroughly decoupled from any de-anonymizing information. For example, requiring phone numbers as IDs can be detrimental for the anonymity of users whose real world identities are tied to their phone numbers.
As we know, in many countries anonymous phone numbers are simply not available for purchase. Phone numbers and their owners may be publicly indexed on the web or in phone books. Moreover, it is easy for phone service providers to link phone numbers to the unique IMEI number of the phone currently using the number so just buying and using a fresh phone number alone may still not be enough to decouple one’s real world identity from a phone number.
No network can have both perfect privacy and fully assisted contact discovery. In fact, this is where the road forks for every privacy-aware system or product. Many of the most widely used messaging platforms — secure or not — have made product decisions that drive users, intentionally or unknowingly, to not seek anonymity. Ease of contact discovery is certainly preferred when the priority is to grow your user base. It is a legitimate trade-off to make when network expansion trumps privacy.
When building Wickr Messenger we made a conscious decision to prioritize anonymity and understood the cost of this decision. We still believe that the privacy of user identity matters as much as the privacy and ephemerality of user communications. For a widely decentralized user base on an open network where anyone can join at any time, protecting the privacy of user identity matters. This is especially true for users concerned with targeted attacks by nation states, or when an identity of a journalist’s source must be tightly protected.
Wickr Messenger is designed to strongly favor user privacy while still allowing for as much help with contact discovery at an opt-in basis. For starters, the ID policy of Wickr Messenger allows a user to choose an arbitrary (unique) string as their ID. This already enables users to increase their defense against de-anonymization via enumeration attacks.
Further, Wickr Messenger provides users with an option to not even make their ID available for contact discovery. Similarly, users are also given the option to never use the assisted contact discovery with their own list of contacts and instead populate their contact list from scratch manually by themselves. As an opt-in feature, a user can decide to upload the hashes of her device contacts to the Wickr Messenger server to discover which of her contacts who also opted in for discovery already have Wickr accounts. This way a user can populate her contact list while never storing her address book on Wickr servers. In other words, anonymity is the default position of Wickr Messenger but users can opt in to loosen up the controls rather than having to make the proactive decision to seek privacy and anonymity.
We have made a different decision when building solutions for closed or federated networks of users managed by a centralized organization. In this scenario, the anonymity of users is usually less of a concern than an ability to easily manage the network by provisioning and de-provisioning users.
Thus, in AWS Wickr, we have opted to set IDs to be email addresses, which are already widely used to identify and communicate with users across corporate networks (e.g. via an LDAP server). With all things being equal including default ephemerality, e2e, and PFS, using emails as IDs on AWS Wickr greatly simplifies the task of populating a new contact list when a company’s employee joins its private network.
AWS Wickr and Wickr Messenger differ in contact discovery mechanisms as these tools serve different sets of users with different threat models. Our goal is to build easy-to-use, privacy-enabling products that allow users to maintain secure ephemeral messaging persona tied to their work while preserving their privacyand control over their identity in a private arena. We are excited to be sharing more on this in the coming months.