This post is part of a series on the Five Tenets of a Modern, Multi-Modal, Real-Time Communications Application.
Trust can be a difficult thing to get right. Even just defining it can be tricky: what does it mean to make a user trust you or your application? Much of what a user perceives as trust comes down to properly setting up their expectations and avoiding surprises. But trust is also about knowing the identity of the person in front of the other screen, and making sure they are who they say they are.
For an app to gain a users trust, there are a few items to consider. These are just highlights to illustrate how to avoid negative surprises, especially with voice & video:
- Make sure the user is always in full control of how and when the communication is occurring. For example, don’t enable the camera automatically on every call; make sure the user has clicked or selected something to indicate that the camera will be enabled.
Make sure the user knows when communication is happening, and when it is not. We’ve all been there – on a conference call, or after a call has ended, thinking the phone was hung up, but actually the other party is still listening, and then we say something we wish we had not….
Make sure the user knows who is party to the communication. If a conversation starts directly between to people, and a third wants to join, be explicit about how the history will be handled. Will the new participant be able to see what has been said? Or will the addition of a third party trigger a new conversation with a clean history. If a conversation’s history is saved, the application must be careful to only make that history accessible to those who were party to the original conversation.
Asserting and handling Identity
An item related to trust is identity. Do I know who is calling? Does the system make strong guarantees about who it claims is calling? In the traditional telecom world, most of us trust caller ID. However, those who work in that industry know just how trivial it is to fake caller ID.
In the world of web browsers, passwords and strong encryption, we have the ability to be much more certain about to whom we are talking. Application designers must take identity into account. Where possible, we should select user-centric identities, such as email address, Twitter handle, or real name, and avoid network-centric identities like IP addresses or telephone numbers.
Alternatively, if your app is designed to be anonymous, take care to ensure that anonymity is preserved. Use strongly random IDs (if you use IDs at all). If possible, expire the ID at the end of the conversation and never use it again. Proxy all communications through your server so you don’t give away the location of each party, perhaps even hide IP addresses in the SDP generated by WebRTC.
Trust & Identity
The above can probably be summed as “Don’t surprise the user.” While this is a good idea in almost every facet of application design, it’s especially important when concerning trust. Whenever making choices about how to handle user data or display information, take a minute to consider: if it was your conversation, and it was shared with the wrong person, would you be embarrassed?