On the basis of our humanitarian supply chain project with the UK Government, we explore how to combine security and UX best practices.

A question we have in each of our blockchain projects is that of the user-friendliness of having a decentralised architecture. In fact, it’s not only us having that problem but, according to a survey of 160 DApp projects in 2018 by the good people at Fluence Network, 75% of all mentioned new user onboarding as a major hurdle for adoption of blockchain. Additionally, the second biggest pain points for Dapp developers was “Bad UX of crypto”. In the following post I would like to show how we solved the largest of the issues with UX in blockchain, the key management.

For a couple of months, we have been building a Proof-of-Technology as part of the Frontier Technology Livestreaming (FTL) programme of the UK Department for International Development (DFID). The technology to be “proven” in this case is blockchain, specifically within the setting of humanitarian supply chain management — here’s a link to a medium post for more on the topic.

We’ve been advancing according to plan, successfully finishing our first sprint and working hard to finish the second. This will be the final sprint before we enter the live test phase, where we will field-test the system with a real life humanitarian logistics supply chain. The “real life”-test in this case will mean tracking a regular shipment of goods to a disaster-stricken area, using the application we are building. In this post, I’d like to share some of our experiences in trying to make blockchain as user-friendly and safe as possible, two goals normally seen as diametrically opposed.

Firstly, the most basic user-experience (UX) consideration when implementing a permissioned (more on what this means: here) blockchain solution is: if and through what medium does the user interact with the blockchain system? One can imagine solutions ranging from a completely “authoritative” system where the end-user is happily ignorant of any blockchain activities going on in the background, much like few internet users are aware of exactly how passwords are checked when logging in to a service, to products where each user is trusted (and in some cases required) to set up and run their own node, manage keys, interact through API calls and verify all activities. We attempt to find some middle-ground by reasoning about what our users are actually likely to use and appreciate in a system.

In our case, the users range from technologically savvy, well-connected DFID professionals with up-to-date hardware down to logistics service provider personnel with limited connectivity and first generation android smart phones. Since we are working in a PoT, with a relatively limited scope and time frame, we decided to make some assumptions on the user constraints. Roughly, we assume all of our users:

• Speak and read English
• Have a device (mobile or not) with an updated browser installed
• Have a working Internet connection with sufficient bandwidth to serve a React-based web application (React is one of the most common web programming frameworks for UI’s)

These assumptions allow us to target a very wide audience, and to extend functionality in the future to cover, for example, off-line use cases.

We do this by building a progressive web application — meaning that it is reliable, fast and flexible enough to be used on mobile or desktop — with a simple login procedure to separate user types from each other. The application is hosted on our cloud provider which connects to a database as well as our — wait for it — blockchain!

This means that a logistics planner in the offices of DFID can access the web application by opening a standard browser typing in the address of the application in the URL window and can then login using his or her personal username and password. Similarly, a user on the “ground” can accept an order for his or her leg of the shipment by logging in to the application over a browser on a mobile device.

After having established the point of access for the users to the blockchain, we needed to determine which actions a user should be required or allowed to take with respect to the blockchain system. Our aim was to empower the users to have as much control of the most critical parts in the supply chain as possible. This was partly to ensure trust in the system — the purpose of having a blockchain is to remove a single point-of-control of the data — and partly to communicate clearly to the user exactly what information comes onto the blockchain.

We’re working with an Ethereum-based system, which allows for smart contracts. This means that we could encode large parts of the business logic, such as in the chain, if we would like to. But, the more functionality which is on-chain, the more users have to interact with the blockchain. The interactions which affect the complexity on-chain are operations where the user needs to add new information. More interactions lead to more signing of messages or transactions to the chain. More signing means more usage of the key pair of the user, which is mostly quite awkward and non-intuitive for users.

This is why we opted for a solution where the user still has full possession of the private key, and no one else can manipulate signed information posted to the blockchain by them. By helping the user generate a new key pair upon registration and then allowing them to store it locally on their device, we hope to give as much responsibility to the user as they would like, while still keeping security risks to a minimum.

So, when does the user have to sign transactions?

So, when does the user have to sign transactions? Exactly then, when custodianship is changed. The absolutely critical information, which must not be corrupted, is thereby secured the most. Custodianship change contains two steps: first, it needs to be handed over by the current custodian, and secondly, it has to be accepted by the custodian-to-be. Before both those transactions have been signed, custodianship still lies with the previous user. We try to make the “signing” as non-invasive as possible, by applying known procedures like “Username and password” plus a special key-file which needs to be provided by the user. It’s shown in a simplified form below:

The risk of such a system of user-controled keys is that the user loses the private key, but in our case, since we are working within a permissioned setting, there is a mitigation. Access to the platform is dependent on verifying the real identity of each user. Therefore, in the case of a lost key, the user has to re-register, but the information isn’t lost. The user will then have to re-verify the identity to regain access to the account, where a new key-pair can be generated.

In a future solution, there should not be a central authority to reset a password without the identity checks having been verified, but for the PoT it is acceptable.

We’ve now seen some of the challenges of usability we’ve been facing in building a humanitarian supply chain blockchain-solution within FTL. Usability and accessibility is an immense problem for blockchain in general. It strives to empower people but it is at risk of confusing and alienating people with complicated key management procedures and lacking interfaces. At Datarella, we don’t see the point in building technology that the end user can’t understand properly or feels uncomfortable using. Especially when the users are strapped for time, trying to help others in dire need, we have a responsibility to create technology which does not obstruct but enables our users.