Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Inbox




The Inbox screen is where the user can view and send messages from other users.

The inbox is designed to look and feel like a traditional text message/chat mobile application so that learnability is made easier. We designed a number of visual cues to help the user quickly assess the security level of particular conversations and messages -- the icon suggests the number of participants and whether the users are verified by color. Individual messages and also marked in the appropriate color, and an icon further reinforces whether the person who they are communicating with has been verified. We decided to leave multiple indicators in after noticing numerous mentions in the heuristic evaluation about how different users may not be able to perceive some of these essential security indicators (such as colorblind people).

Efficiency was also considered to streamline some of the verification process when having conversations. Unknown users can directly be added to the contacts list and their verification process updates all existing messages.

Contacts



The Contacts screen is where users can browse and edit the users to whom they expect to communicate securely with.

This screen is designed to look and feel much like existing contacts applications to enhance learnability.  A sorted list of known users is displayed, and can be paged through and data modified. What is unique is that the data stored includes a secure key which identifies that person (required for secure communication), and a flag to denote whether that person is known to the user. These data elements simplify the transactional needs of encrypted communication, the first of which can also be passed physically with a barcode (see My Identity below). There were debates on how much data to allow the user to see/mess around with in terms of contact data, and we settled on trying to keep things simple and uncluttered with lots of contact data.

Efficiency was taken into account when creating the delete contact feature, which can optionally also automatically remove past messages from that user so that the user doesn't have to delete them manually. In addition, we allow the user to add new contacts in two ways -- one is manually entering in their secure key, while the second uses the built in camera on the phone to take a photo of a 2d barcode. This is a vast improvement in efficiency for passing secure keys in person.

Security is also emphasized as any non-reversible tasks require a confirmation before they will execute.

My Identity

'My Identity' is a simple screen that shows the user's profile data, and a large 2d barcode that can be used to physically share their encryption key with another user of the application.

Heuristic feedback suggested that users were not entirely who's identity this page was meant for, so we added a new title to signify that it was their personal identity.

With QR codes becoming more ubiquitous, they afford being scanned by many people who are familiar with them.

Settings

This is a basic settings screen with gives a place for the user to modify application settings. This is designed much like any typical settings screen, and as of now only allows the user to edit their password.

Implementation

Our application was built as an Android application. It leverages a SQLite database to manage all contact information, messages, etc.

We used standard toolkit for much of the UI components.

We created custom colored images to represent different ideas throughout our interface. This was done with freely available images which were then colored, scaled and composed to give the desired resources.

Individual tabs in the UI were defined as separate Activities, which helped allow the team subdivide tasks across each of screens. This is a robust part of Android and so is very responsive and usable.

Open Source packages were found and integrated for the barcode reader and QR code generator. This package also deals with ensuring the user can get access to a barcode reader if they do not already have one. This ensure setup of the additional dependencies is as easy as possible for the user.

The backend server handles  handles all the routing of messages between clients. Android devices will be able to communicate directly with each other without any setup besides adding someone as a contact. This simplifies the setup and use for the end user. This was intentionally designed such that the server could be untrusted. Therefore, there is no authentication; all verification is done through encryption. The underlying protocol is HTTP. was intentionally designed such that the server could
be untrusted. Therefore, there is no authentication; all verification is done
through encryption. The underlying protocol is HTTP

We used standard toolkit for much of the UI components, such as.....

Individual tabs in the UI were defined as separate Activities, which helped allow the team subdivide tasks across each of screens.

Open Source packages were found and integrated for the barcode reader, numerous icons....

Evaluation

Three user tests were performed in order to investigate the effectiveness of our interface. One developer acted as both facilitator and observer for each test. We located users who we thought we be good targets for the application -- users who were interested in securely communicating with others, but not necessarily those who understood the technicalities of encrypted communication. One user test was performed using the application running on an Android phone, while the others we performed using the Android emulator.

...