Expert UX Review: Bitmask Linux Desktop Client
Activity: Expert heuristic review of a mobile VPN tool with a security focus.
Takeaway: Users need clear feedback on system state — but don’t deliver it in terms that are frightening.
Bitmask is a secure VPN developed by the LEAP Encryption Access Project. It is currently available for Android and for Linux desktop; it should be available soon for Mac.
Bernard Tyers and I recently performed an expert review of the usability of the Bitmask desktop client on Linux. Bernard installed the client on Debian 7; I installed it on Ubuntu 14. Below is a list of the issues we found in Bitmask’s Linux desktop client, ranked for the importance we felt it was to address them.
At the end of this post are some mockups with concrete suggestions for improving the Android interface, based on a previous review. Many of these suggestions for the Android client could as easily apply to the desktop client, as most of them just simplify how the state of the VPN is communicated to the user.
First, what’s going well?
In general, the reviewers agreed that Bitmask is making good decisions to present a simple interface to users. The flag indicating the gateway location is particularly nice. The pages where users download are presented in clear language, feature a nice big obvious button, and are aesthetically pleasing. While the install process for the desktop app is currently too technical (requiring command-line work on Linux), it does keep the user up-to-date with system status. Both reviewers were confident they had succeeded in setting Bitmask up on the desktop, and felt there was good feedback the tool was working (the flag and the upload and download monitors).
1) The difference between “logged in” and “connected” is confusing — High priority
This is the same issue observed on the Android app. I logged out of Bitmask and yet it still seems to have traffic on. How is this possible? I can “Turn ON” without logging in? This concept is still confusing. The reasons for being logged in (faster speed) or logged out (greater anonymity) need to be made clearer to the user, and possibly the screens for login and connection should be separated.
Recommendation: Change in how accounts and connection are handled; refer to the recommended changes to the Android interface for a potential way to do this.
2) Bitmask’s preference to fail closed is not communicated clearly — High priority
One of our reviewers came to the conclusion that Bitmask blocks all Internet traffic when it is not on. This is not actually the case: rather, if Bitmask is unable to connect securely, it “fails closed,” blocking Internet traffic.
Recommendation: When Bitmask fails closed, it needs to clearly indicate that it is doing so in its system status bar and its main window. It should say “encrypted internet failed,” and give the user a way to reconnect.
3) Interface problems when the service can’t connect — High priority, bug
Both messaging and interface problems thwart users when the service fails to connect. On registering for Calyx, one reviewer got a Nonexistent Provider response. The “use existing provider” drop-down menu responded by greying out and becoming non-responsive, making it so the user could not connect to Calyx or any other service. It seems possible this decision was made by the developers to keep users from re-connecting to a bad provider, but because the whole menu becomes non-responsive, the effect is instead to block any connection at all. The other reviewer also noted that there was no messaging about how users should proceed when the connection failed.
Recommendation: This difficulty is addressed in the revised Android interface mockup: the providers should no longer be in a drop-down, making it easier to disable a single bad provider. Please refer to the mockup for potential changes.
4) Need password length, character requirements in password creation — High priority
Currently, the password creation screen does not communicate whether a password is insufficiently strong until it has been submitted by the user.
Recommendation: Use standard ways to reflect the security of the password the user is entering, in real time.
5) Download page uses alarming language — High priority
The Bitmask download page includes this warning: “Bitmask is still experimental. Please do not use these beta releases of Bitmask for situations where a compromise of your data could put you in danger.” The words “danger” and “compromise” are frightening. While we understand the need to communicate to users that Bitmask is in beta, this language can be a barrier to adoption for some users. Consider that users may already be using other free VPNs which promise security but actually have malware installed; Bitmask represents an improvement over these services.
Recommendation: Reconsider how this is communicated, perhaps putting more emphasis on it being an experimental beta.
6) “Traffic is being routed in the clear” message is also alarming — High priority
When Bitmask is disconnecting, the message “traffic is being routed in the clear” appears. This is good to let users know, but might startle them if they don’t expect it to happen. Also, “routed in the clear” may not be as clear to users as a message about protection.
Recommendation: Consider a way to communicate that Bitmask is telling them this to help them protect themselves — something like “Please wait, Bitmask is exiting protective mode.”
7) User does not know what services are available from service provider until they sign up — Medium priority
Bitmask does not currently let users know whether a Bitmask provider offers a VPN and/or encrypted mail until they have already chosen a provider.
Recommendation: Bitmask should provide information on what services are available at the moment of choosing a provider, and provide for selection in the interface at that step.
8) “Select provider” screen should deprecate “configure provider” — Medium priority
Currently the “select provider” screen gives the user the option to either select an existing provider or configure their own. Most end-users are not likely to want to configure their own server, and will be frustrated if they try to use that option.
Recommendation: Bury “configure provider” in an “advanced options” link on that page, and making the whole list of selectable providers visible without a dropdown menu.
9) “Select provider” screen has confusing language — Medium priority
Currently the “select provider” screen asks users if they would like to “Use existing one.” Existing provider? Existing where? On my machine? One I already have? Can I connect this to my Yahoo account? This language is confusing.
Recommendation: Say “Select a provider.” See the recommended changes to the Android interface for more on how this could be accomplished.
10) Menu bar status is not identified as Bitmask’s — Medium priority
The “Encrypted Internet ON” status in the system menu bar is lovely — very easy to see, nice clear simple language. However, it is not clear that it belongs to Bitmask!
Recommendation: Consider changing the icon, or adding the word “Bitmask” to the language in that menu. Note that the Mac standard way of communicating status in the menu seems to be having the application’s logo in black and white, and turning it semitransparent when the app is not running.
11) “Help” should include a link to the Bitmask site — Medium priority, feature addition
Currently the “help” menu is not so helpful, not containing any troubleshooting or configuration tips for the user. Some trainers have asked for more help within apps, rather than online. If that won’t bloat the apps, it might be a good idea.
12) Application does not make system status visible before and after service starts — Low priority
One reviewer observed that he was not seeing the IP address of the gateway, and would have liked to see the user’s IP address reflected both before and after the user connected. Another reviewer noted that the use of a flag to indicate the gateway location was good design which previously-interviewed VPN users were likely to find satisfying. Bitmask has stated a preference to hide more-technical information like IP addresses, which is wise.
Recommendation: Reviewers agreed that making the flag interactive — having it reveal the gateway IP address when clicked or moused over; possibly adding a map as Tor does — would be a feature that users might appreciate.
13) Help page should separate out technical and less-technical information — Medium priority
The homepage (bitmask.net) provides lots of information about the software. However, it provides technical and user information in the same page. Less-technical users might be frightened off by the instructions for developers and sysadmins (fork our code, services, etc).
Recommendation: Separate this content out. The reviewers were pleased to hear that the project manager has already embarked on this project.
14) Finding Bitmask by keywords — Low priority
If a potential user doesn’t know the name “Bitmask” but is looking for a VPN, it is easier to find the desktop client than it is the Android client. A search for “journalist VPN” or “activist VPN” does turn up Bitmask on the first page of a Google search, a couple links deep from Riseup and the Rory Peck Trust (which I note doesn’t have the best link to the site). Combinations of “safe VPN” or “free VPN” don’t turn Bitmask up — there is a lot of competition.
Recommendation: Despite the challenges of SEO, a bit more work to get keywords on the download page could make it more likely that searchers could find Bitmask instead of some creepy service with no bona fides. Bitmask could ask Rory Peck to update their link. Links from VPN providers who are providing Bitmask could also help.
Recommended changes to the Android interface
These may also be applicable to the desktop interface.
