Privacy is at the core of everything we do at Status and this permeates into every design decision of our Status messenger.
In the previous two articles in this series, we talked about why privacy is important and how Status compares to other messengers in the privacy building blocks. In this article, we reflect on the topic of ‘privacy versus convenience’ and how they often seem to conflict with each other.
We explore this in the context of account identifiers on Status messenger and evaluate this choice in light of the recent debate around PIN-related features of the Signal messenger.
We explain the rationale behind the use of phone numbers as identifiers by popular messengers and contrast that to our choice of using cryptographic keys for a privacy-centric design. Additionally, we outline the challenges in achieving parity with other messengers on features of convenience but strictly in a privacy-first manner with the goal of being the ultimate privacy-preserving messenger built using decentralised P2P technology.
Identifier: Phone or Phony
Every messenger needs to create a unique account for a user which is then used to identify and connect that user to his contacts. The most commonly used credential for an account identifier happens to be the phone number for various reasons.
Many people around the world already own a mobile phone — either a smartphone or a feature phone — and this trend is only increasing. So a phone number is readily available.
Moreover, unlike emails, it’s a bit harder to acquire multiple mobile phone numbers from network carriers without required verification of government issued documents (although this is getting easier with services like Twilio, Google Voice and other similar on-demand VoIP services). Nevertheless, most people typically use a single phone number as their personal one for communication.
Therefore, for a majority of the people around the world, we can say that a phone number might loosely serve as a digital identity — something that is not issued by the government such as a passport, birth certificate or social security number. This is perfect if we want to automatically build a social network for a user in our messenger app because the phone numbers in the user’s contact list are his network, at least a part of it.
Convenience and inherent network effect are really the reasons why Signal and other messengers use phone numbers as identifiers.
This is an excellent approach if we are building a messenger for the masses like WhatsApp or nudging SMS users to upgrade to a better experience. But is this perceived convenience really worth it for people looking for the most private messenger that will keep their data (and meta-data) secure from the prying eyes of anyone, including the government, that wants to snoop on them for some or no particular reason?
Phones can be tracked and tapped. Even for end-to-end encryption to be trusted, the end points and the applications have to be trusted. With only the knowledge of phone numbers, one’s adversaries can carry out legal/illegal wiretaps, track physical location (using GPS) or even subvert specific applications on the phone using malware exploits for surveillance. It gets even worse if they can execute a SIM swapping attack.
At Status, we strongly believe that the convenience of letting a messenger application use your phone number to automatically build your social network is not worth the risk of privacy invasion from entities that have both the motive and resources to do so. This is especially true when people do not trust legal processes to be fair and so rely fundamentally on technology to protect their privacy and perhaps even their lives. For such people, code is law.
Ultimate privacy is therefore the reason why the Status messenger relies on a randomly generated cryptographic key pair as the user’s identity. This is a “phony” identifier that has nothing to do with the user’s real world identity.
A user on Status is identified only by his chat key — a 65 byte uncompressed ECDSA secp256k1 public key. The registration onboarding does not require any identifying information such as a name, email address or a phone number.
As these identities are easily generated without any connection to the user’s real identity, they provide a high level of pseudonymity. Of course, the user is allowed to personalise his experience by attributing personal information to this generated identity. But that’s a choice. The user is pseudonymous as far as Status is concerned.
All features of Status messenger and the underlying P2P protocol are based on this chat key being the foundational pseudonymous identity.
This sounds great. But how do people view the use of phone numbers as chat identifiers? If privacy-conscious people are happy with the convenient use of phone numbers then we have a fundamental problem with the Status messenger because chat keys prevent us from automatically inheriting the user’s social network via his phone’s contact list and leveraging the explicit network effects thereof.
Choice: Privacy or Convenience
While the choice is not that stark binary, designing for higher privacy certainly lowers the convenience that users have gotten accustomed to with the popular messengers.
This tension between privacy and convenience is best illustrated in the context of the recent debate around Signal messenger’s introduction of their PIN feature.
For those who aren’t familiar with Signal, it’s a very popular open-source privacy-centric messenger developed by Moxie Marlinkspike’s Signal Technology Foundation. It apparently has more than 15 million users and is endorsed by the former NSA contractor whistleblower Edward Snowden, Twitter/Square CEO Jack Dorsey and several prominent security researchers. It has been recommended by Electronic Frontier Foundation (EFF), American Civil Liberties Union (ACLU) and European Commission among other well-known global organisations for its focus on security and privacy.
The privacy-centric foundation of Signal is best highlighted by Moxie as follows:
"The only Signal user data we have, and the only data the US government obtained as a result, was the date of account creation and the date of last use – not user messages, groups, contacts, profile information, or anything else.
Signal uses end-to-end encryption so that we never have access to the contents of the messages you send; they are only visible to you and the intended recipients.
Signal also does not have access to your contacts, social graph, group data, group membership, profile name, profile avatar, location data, gif searches, etc. – and we don’t include trackers, ads, or analytics in our software at all."
Signal is the most popular privacy-friendly messenger used in the world today.
At Status, we deeply respect the philosophy behind the Signal messenger, its underlying protocols and the privacy-centric features. We even implement some encryption algorithms specified by them e.g. X3DH and Double Ratchet.
However, Signal relies on phone numbers as identifiers like many other messengers. The reason for using this and not alternative usernames is justified by Signal as follows:
"As an example, social apps need a social network, and Signal’s is built on the phone numbers that are stored in your device’s address book. The address book on your device is in some ways a threat to the traditional social graphs controlled by companies like Facebook, since it is user-owned, portable, and accessible to any app you approve. For Signal, that has meant that we can leverage and contribute to a user-owned portable network without having to force users to build a new closed one from scratch.
However, many Signal users would also like to be able to communicate without revealing their phone numbers, in part because these identifiers are so portable that they enable a user’s conversation partner to contact them through other channels in cases where that might be less desirable. One challenge has been that if we added support for something like usernames in Signal, those usernames wouldn’t get saved in your phone’s address book. Thus if you reinstalled Signal or got a new device, you would lose your entire social graph, because it’s not saved anywhere else.
Other messaging apps solve this by storing a plaintext copy of your address book, social graph, and conversation frequency on their servers. That way your phone can get run over by a car without flattening your social graph in those apps, but it comes at a high privacy price."
Signal has prioritised convenience over privacy with phone number identifiers.
While this may be tolerable by many of their users, either because they don’t have an alternative choice or because they don’t understand or care about the implications, it certainly has remained a popular concern for a long time.
This Intercept article does a great job of breaking down Signal’s use of phone numbers, the risks associated with it and possible ways to use Signal with a phone number different from your personal one.
As explained earlier, the key reason for this choice is the convenient portability of the user's social network that is tied to his phone contacts. Without using phone numbers, any messenger would have to backup the user’s social graph to their servers so it can be recovered by that user on a different device if/when needed i.e. loss or theft of the phone.
The obvious solution here is to backup everything in plaintext which is what many messengers do. The data at rest on the company’s servers may be encrypted but they have the encryption keys and you have to trust them with it. Solving this problem in a privacy-preserving way is extremely challenging when the threat model includes a service provider that may accidentally leak the encrypted data or be forced to submit them to authorities in response to legal requests.
This titanic problem is evidently not lost on the talented Signal team which has addressed many aspects of this over time such as concerns around sharing numbers with contacts, registration lock, private groups, private contact discovery, private profiles and the use of a safety number.
While these mitigations significantly limit the unintended/unnecessary exposure and exploitation of the user’s phone number, it does not prevent a message recipient from knowing the user’s phone number. There is only one solution here: do not use the phone number as the user’s identifier.
PIN has caused so much brouhaha in the media (for e.g., here, here, here) that Moxie himself clarified the thinking behind PIN on Twitter. Matthew Green, Associate Professor of Computer Science at the Johns Hopkins University and renowned cryptographer, best summed up the concerns and the underlying technology in his blog post.
Briefly, what PIN does right now is to allow Signal users to securely backup their profile, settings, and contacts on Signal’s servers so that they can be restored when Signal is reinstalled on a different device, without revealing any of this to Signal’s servers. This feature is built using Signal’s Secure Value Recovery technology which depends on a security feature in Intel processors called Software Guard Extensions (SGX).
As mentioned earlier, this capability will enable Signal to migrate to non-phone-number-based identifiers at a later time. One would imagine that this would be welcome as excellent news because it addresses the biggest concern with Signal i.e. use of phone number. But this hasn’t entirely been the case.
There appear to be many reasons for this perceived skepticism around PIN. First, users would like this feature to be optional and not be forced into using a PIN. Second, there are users who are skeptical about uploading any data to the cloud, no matter how strong the cryptographic guarantees. Third, there are users who value any probable loss of privacy more than the convenience of restoring their contacts from cloud backups. Finally, the underlying technology of Intel SGX, which enables PIN, has seen several security issues (mostly from side-channel attacks) over the years since its release that there is a deep mistrust about this technology even within the security community.
Signal listened to its users and announced a beta which lets users disable PINs.
Status: Privacy with Convenience
With Status messenger, we have always prioritised privacy first. And of course, convenience and a frictionless user experience come a very close second.
Privacy is also one of our core principles:
Privacy is the power to selectively reveal oneself to the world. For us, it's essential to protect privacy in both communications and transactions, as well as being a pseudo-anonymous platform. Additionally, we strive to provide the right of total anonymity.
Making cryptographic keys as the chat identity is at the heart of this privacy-centric design. These keys are derived from a BIP39 seed phrase which needs to be backed up by the user. To make this a bit user-friendly, we generate a random three word username from the public key, e.g. Beautiful Attractive Fox. We realise that this is not as convenient as simply using your name, email address or phone number which your friends already identify. We are targeting those who do not want to be identified as such, by default.
Because of this choice, the user is expected to create his own social network on Status messenger, from scratch, by manually adding his friends’ chat keys to his contacts or finding them in public channels. But many of his friends may not even be on Status messenger. The network effect is therefore hindered and the value of Status network is arguably diminished to begin with.
We fully understand this and yet remain committed to privacy first. To address this, we are exploring privacy-preserving ways to achieve a custom referral program which incentivises users to onboard their friends onto the Status app but without revealing their identifying details.
At a protocol level, with Whisper and now Waku, we remain committed to enabling privacy-centric P2P protocols powering the Status messenger. Peer discovery, message relaying on resource-constrained nodes, scalability, spam, offline nodes and node incentivisation are some of the biggest challenges on which we continue to do active research and break new ground.
Sticking steadfastly to this privacy-first discipline while being painfully aware of the increasing feature disparity with popular messengers is incredibly hard. We are just beginning to add support for notifications, images, stickers, mentions, audio messages, emojis and a desktop version, but we don’t yet support videos, GIFs, files, voice calls and video calls. We support device-to-device syncing but not cloud-backup based recovery.
And to make it more complicated, we bundle a crypto wallet and a web3 browser along with the messenger. One of our main target audiences has always been the crypto enthusiasts but we are revisiting that assumption while analysing our user growth and retention metrics (which also is very hard without intrusive in-app analytics).
In this article, we’ve explored the concept of an “account” on Status messenger which forms the basis for our no-compromise privacy-centric design. We contrasted our choice of using cryptographic keys as account identifiers with that of Signal’s phone numbers.
Finally, in the context of the recent debate around Signal’s PIN feature, we highlighted the challenges of prioritizing privacy while offering features of convenience that users have been conditioned to expect in this data economy.
If data is the new oil, we are carbon-free.
We have a long way to go before we achieve feature-parity with Signal and other messengers strictly in a privacy-preserving manner. We have several fundamental problems to solve in the P2P space, a big one being the design of incentivisation for running nodes that support the rest of the network.
While we revisit some of our product-market fit strategies and course-correct as required, what is non-negotiable is the strong foundation of privacy. Because without that, we are yet another messenger and that’s not what we set out to be.
Status messenger aims to be the ultimate privacy-preserving messenger built using decentralised P2P technology.
(Thanks to André Medeiros, Corey Petty, Jonathan Zerah, Oskar Thorén and Simon Astaburuaga for reviewing drafts of this article and providing helpful feedback. Thanks to Alex Howell for the thoughtful illustration.)