The dialpad: Essential tool for voice calls, or the gateway to insecurity?

Usability Report: Ostel.co, Linphone & CSipSimple

Activity: User research on open-source apps for making encrypted calls.
Takeaway: Users need interface elements they recognize, activity indicators, and clear, jargon-free wording.

With voice calls increasingly subject to surveillance, apps which can provide secure telephony are of great importance. Like many secure tools, however, secure voice apps are confusing and difficult to configure, requiring a lot of technical knowledge from users. To address this, OpenITP recently ran user tests at the Hackers On Planet Earth conference, identifying specific pain points in the interfaces of the apps CSipSimple and Linphone, and the registration website for Ostel.co. We hope that secure tool developers will take these recommendations into account when creating or updating their interfaces for voice apps.

Key Findings

1. Users need activity indicators. They are unaware of when the app is working properly, when there are network connectivity issues, or when they are waiting for an answer for a successfully placed call. This is causing users to abandon the app.
2. Users need clear, concise and jargon-free wording. This is true for the entire experience. Discrepancies in the wording between Ostel and Linphone/CSipSimple were particularly confusing.
3. Users need an interface with common affordances. Neither app adhered to Android or iOS interface guidelines and, as a result, caused frustration.
4. Users need the app’s abilities to be explained up front, with help from the interface.
5. Presenting users with a dial pad and no obvious text field leads them to make calls through the phone system — which cannot be wholly secure.
6. Neither the Ostel website nor the apps explicitly state when and how end-to-end encryption happens.

Specific, concrete suggestions by app can be found in the Issue Summary For App Developers, below.

Objectives

This study aimed:

1. To gather qualitative data on encrypted voice over IP (VoIP) usability applications across popular mobile platforms
2. To better understand users’ likelihood to adopt this technology
3. To increase users’ awareness of technology that enables them to take control over their digital footprints and overall privacy.

Overview and Methodology

Over the course of three days at the 10th Hackers On Planet Earth (HOPE X) conference, researchers conducted 16 in-depth, one-on-one user interviews using the Ostel.co SIP (session initiation protocol) provider with Linphone (iOS; 7 users) and CSipSimple (Android; 9 users). The test was designed to last for 45 minutes, with a portion of the time dedicated to educating the participant on the importance and purpose of encrypted VoIP tools using threat-modeling resources (Security In A Box and PRISM Break). Since users were asked to download Linphone/CSipSimple on their personal smartphones, the threat modeling took place while the application was installing.

The interviews focused on the participants’ ability to use Linphone or CSipSimple (NB: in the interest of time, the researchers guided the initial Ostel.co account setup process). In order to fully observe the participants’ natural tendencies and body language in reaction to the applications, the interviews relied mainly on task-based prompts. This technique also helped to avoid leading questions.

Upon written permission, the interviews were recorded using a rig that filmed the user’s phone, a separate camera recording the user’s face and upper body, as well as a laptop’s internal microphone to pick up audio.

There were three usability professionals on the team, with two assistants charged with setting up the testing rig and taking notes. The assistants were also welcome to jump in with additional questions for the users.

The test was initially intended for end-users who were less comfortable with technology; however, that kind of user was particularly difficult to track down at a hacker conference. As a result, a handful of the participants interviewed were quite technologically savvy. This ultimately led to an exceptionally interesting dataset.

Participant Profile

The participants were moderately diverse in age, technological knowledge and gender presentation and homogenous in terms of race (skewed white). Four participants presented as female, 12 presented as male. Technological knowledge ranged from those who have never used any sort of cryptography tools to others who currently work or have previously worked in the tech industry (including a systems administrator and a quality assurance analyst). Other participants currently work in fields where securing their communications is of particular importance (journalism, education, law). Because this test was conducted in the context of a technology-focused conference that tends to draw a more progressive (and oftentimes radical), politically- and socially-aware audience, these users were aware of the importance of tools like Linphone and CSipSimple (though many had never used those applications or other comparable tools).

Research Limitations

On the weekend of the tests, as it happened, Ostel.co went down. This resulted in almost every user being unable to complete a call using either app as the initial test protocol specified (connecting to Ostel.co using Linphone or CSipSimple).

Nonetheless, users were still able to interact with the apps’ interfaces, yielding much useful data. Additionally, the lack of connection revealed a number of useful findings about the utility of existing error messages.

The audio recordings of some sessions were either lost or difficult to hear due to misunderstanding the Quicktime capture setup.

User Feedback

Across the board, users did not find the overall experience — from setting up an account on Ostel.co to attempting an encrypted phone call — to be intuitive or enjoyable. Linphone and CSipSimple users alike became frustrated after failing to find or successfully use the apps’ major functionalities (successfully placing an end-to-end encrypted call, finding the contact list, interacting with the setup wizard).

Interestingly enough, users were tripping over the Ostel.co account setup process for a number of reasons (the sign up call to action on the home page moves with the carousel, for example. Users were frustrated by having to interact with a moving target to proceed). Though creating an account only takes a few minutes, the nomenclature was largely misconstrued. This was a particular issue with calling the username a “fun codename,” as users are not used to seeing that wording. This indicated a larger problem that was apparent throughout the experience: the users’ expectations for both the SIP provider and the VoIP apps are never properly or explicitly set.

Many users were unclear of when a call would be fully encrypted. Once the process was explained (i.e., having to call another Linphone user, etc.), several users expressed disappointment. Since the user’s expectations for the app’s abilities were never appropriately set (other than being presented as a secure communications tool, that is), learning that the app is only secure part of the time was a bit of a let down. This highlights the importance of managing expectations not only to keep app abandonment rates low, but to gain users’ trust.

A number of CSipSimple users found the setup process to be challenging, mainly because the list of SIP providers isn’t organized intuitively. Ostel, for example, is buried under a secondary category titled “worldwide providers,” which close to the bottom of the (very long, scrolling) list of otherwise uncategorized SIP providers. Similarly, Linphone users found the setup process relatively difficult, though they seemed to have an easier time with it overall.

Another source of frustration and confusion for both Linphone and CSipSimple users was poor wording throughout the app. Poorly-written error messages (“IO ERROR”), unclear instructions (Ostel.co asks for the user’s email address when a username is needed) and unexplained jargon (“TLS transport is needed for immediate hop”) all contribute to users feeling not only perplexed, but alienated.

Neither CSip nor Linphone adhere to current/up-to-date mobile OS-specific interface guidelines and, as a result, end up either presenting unclear affordances (i.e., right-facing chevrons in iOS to indicate a cell that leads to another screen in the navigation stack) to users or omit them entirely. This was most pronounced in Linphone, as the area where tapped numbers appear on the top of the keypad screen also doubles as a text field for entering usernames. Since Linphone does not adhere to any iOS 7 standards, users are not processing that space as something that is actively editable. Additionally, when that area is tapped, a system keyboard appears but does not block the Linphone keypad UI, therefore allowing the user to accidentally type a number into the text field. This was frustrating for a few users. Most importantly, though, many users were not able to figure out how to place a completely encrypted call for a number of reasons: the CSip contact list was difficult to find, the Linphone keypad did not indicate the ability to manually enter a username and so on.

Several users also noted an overall lack of iconography to, for example, indicate when an account is active or if the app is connected properly, differentiate between secure and insecure connections, etc. Similarly, users pointed out the need for activity indicators across the board in several use cases: poor connectivity causing longer a longer wait to log in, whether or not a call is being successfully processed (i.e., lack of a dial tone) and so on.

Overall, Ostel, Linphone and CSip would all benefit from a more intuitive and cohesive setup process, an intentional content strategy featuring precise/brief content that educates and sets expectations (including better error handling) and a streamlined and standardized interface design with clear and universally-understood affordances.

Issue summary for app developers

Design issues

All apps

1. Font — needs to be consistent with platform
2. Users need better cues that the app is doing something if it is trying to connect or register

• Particularly on Linphone
• Sound might be a good indicator, like phone ringing
• Loading wheel needs to be visible (one of apps had white on grey, other did not have one)

CSipSimple

1. Some users missed the dropdown arrows in the “setup wizard” list. Those dropdown arrows are in iOS style; they are not in the Android style guide.
2. A vision-impaired tester had a hard time with the small font.

Linphone

1. The red or yellow icon at the top, which lets you know if your account is correctly registered, confused some users into thinking that was a security indicator
2. The big orange button at the bottom gets tapped a lot when users can’t figure out what to do, but it rarely takes them to where they need to be.

Bugs

CSipSimple

1. Tapping the space at the top of the keypad where one can enter text for a buddy name sometimes did not work. However, see broader questions about entering text instead of phone numbers, below.
2. Typing an ostel.co user name into the appropriate “add contact” area, when the user had an ostel.co account, yielded a “488 not acceptable here” error at some point; not clear if that’s because ostel was down that day

Linphone

1. When the system keyboard is up over the dial pad, sometimes the dial pad registers taps too

Ostel.co

1. Users are allowed to make a password that is only 6 characters long, and only numbers

Wording

All apps

1. Lack of clarity on what to use in which field from Ostel to CSip (though that may be a classic unsolvable “what goes in this text box” problem)
2. Users expect to see a “Good job, you’re set up!” message once the service is connected

CSipSimple

1. Dialog labeled “setup wizard” might be more helpfully labeled “select SIP client” or “where did you create your account?”
2. “Registered” and “Inactive” when applied to Ostel accounts did not make sense to users. Phrasing it in terms of “there’s a problem with your account” or “Disconnected” might be clearer
3. “Route not available” meant nothing to users, and they saw it a lot.
4. Likewise, “TLS transport is used for immediate hop” was not clear even to the researchers.

Ostel.co

1. Bad instructions (conflict between “1. Enter email address” and first field, which is for username)
2. Wording of ostel fields: lack of consistency between “fun code name” and “username” was bothersome or confusing for users

Linphone

1. Badly-worded error messages, io error in particular

Navigation

All apps

1. Text field at top of dial pad is not obvious as a place to enter text; users don’t tap it

CSipSimple

1. Hard to find your contacts: not clear star icon was contacts.
2. “txt” button in lower left of dial pad should say ABC — it is for going to an alphanumeric interface, not for going to your text messages.
3. The icon for Ostel in the list of services and the name Ostel go to two different menus. This causes user confusion and should be resolved.
4. List of SIP services has unclear, confusing information architecture:

• If you have to hide services in sections like “Worldwide,” put those sections at the top of the list.
• Why is Ostel under Worldwide?
• List of services not alphabetical
• Separate section heads visibly
• Could users type to look up their service?

Ostel.co

1. The “Sign up” button on the splash screen jumps around when the graphic on the page changes. This annoyed users as a few times it switched just as they were about to click it.

Statements of broader problems

Navigating SIP connection options

1. To address:

• Users very unclear how to set up a secure SIP call.
• Can’t type in a SIP alphabetical name when offered a phone keypad

How to interface app with contact list for maximum protection?

1. Phone’s native contact database may not have a field for SIP user info (which is maybe ok, because maybe we want a separate and secure contact list?) or it may not have a domain specified (problematic given how easy it is to call a handle at the wrong domain)
2. Not clear if apps protect metadata; some users assume they will

User expectations

When prompted to explain what they thought a “secure voice app” could do, before we explained the capabilities of the software, users offered a range of capabilities. There were a number of people who expected these apps would secure their calls in ways the apps do not.

• Five users expected that the apps would protect against recording or interception of call audio, which they do. One less-technical user thought the app would NOT encrypt call audio.
• There was confusion over the relationship of SIP to the insecure phone system and other calling methods. Three users made references that implied they expected calls would go over the phone system (mentioning country codes, phone numbers, or the phone system). Four users said they expected the apps could make insecure calls to other phones; three of these said they expected to see a warning if a call was insecure.
• One user expressed confusion over the difference between a SIP account and a Linphone account (which are of course not different). Another expected to see Skype in the list of services which the apps could call.
• Only two users said they expected they could only make calls to other people who had the app. It is possible other users were not aware they needed to call someone else with a SIP client for the call to be secure.
• Users were also confused about how the apps did and did not protect metadata. Users had various expectations: they thought the app would forget contacts, encrypt call history, “protect metadata;” one said “Maybe it just hides my information, but the other person is visible.”
• Despite this confusion about metadata, there was an explicit expectation from at least six users that the apps would integrate with the phone’s built-in contact list. One more-technical user expected confirmed secure contacts to be marked as such (possibly like trust settings with public keys).
• One user expected the app would do additional kinds of secure messaging (text) in addition to encrypting calls.

Users generally thought that if calls were secure, they would see a big closed lock. But there were some assumptions that the calls would be secure just because the app offered secure calling.

Suggested wireframes

One of our researchers, Kaytee Nesmith, mocked up these revised wireframes for ostel.co: