Today, the long-awaited Covid-19 tracing app will be released in Germany, which should help to detect infection chains and warn potentially infected people that they were in contact with someone infected with the virus at some point recently. The decentralized approach of the app raises some questions: Are there parallels to the concept of Self-Sovereign Identity? And if so, are we witnessing the first broadly useable application for SSI in Germany? I will face these questions in this blog post.
Even though the app is already delayed, as it was promised to be released almost two months earlier, it still comes at the right time since life in Germany is getting back to normal again. The app was released in Germany so long after other countries due to many reasons, one of them being privacy. There should be no possibility that this app holds any form of personal information for anything beyond its actual purpose. In fact, the developed app is overall pretty solid. It respects the users’ privacy, it is simple to use, and no central institution has too much control over the data. Let’s analyze some criteria from an SSI point of view to determine if it is a self-sovereign identity:
Control
To begin with, we need to look at who has control over the identifiers. These are designed to be self-creating on the user’s device and frequently automatically changing. The user doesn’t have to create and register them manually. In fact, the user has no control over how the identifiers are being created or exchanged with others. Therefore, randomly created ids violate the principle of control over the identifier since the user does not influence it.
Forming of Connections
As the next criteria, I want to take a look at how connections are established. In the SSI ecosystem, connections with others are formed via the DID Auth protocol, which verifies that the user holds valid keys for a DID. In the tracing app, this is done via Bluetooth. The device automatically recognizes other devices in Bluetooth-range and stores their ID, timestamp, and signal-strength for 14 days. If an infected person was later identified, all the IDs would be sent to a central server from which the user’s devices are frequently polling. If the IDs match up, the app warns the user that he or she might be infected. This is also contrary to an SSI approach were connections are formed with explicit consent, and exists for as long as one party terminates the connection.
Even though more criteria help to determine if the tracing app is a Self-Sovereign Identity, it is already clear that it is not a Self-Sovereign Identity, even if it is much closer than a centralized approach. However, it would be possible to align it more with SSI principles.
Tracing App with Blockchain Integration?
Let’s say the user downloads an app that has the functionality of creating compatible key pairs for an underlying blockchain or DLT. These would also not be human-readable and would further allow interactions with the underlying blockchain. If a person was diagnosed with Covid-19, the device could perform a transaction to the ledger and its IDs would be stored in a central revocation registry that the devices pull from. Therefore, there would be no need for a centralized server that is run by a single institution. Using a blockchain here would bring some benefits as well as it could work across borders and probably for less than what SAP and T-Systems, a subsidiary from the Deutsche Telekom, charge.
In short, I hope that this app has the most success and that people will use it to combat this pandemic and end it as soon as possible. I further hope that decentralized approaches, where the privacy of the user is the main priority, are becoming more popular and allows people to see that we don’t always have to provide sensitive personal information to anyone that offers an online service. And last but not least, I hope to see more people are aware of the benefits of Self-Sovereign Identity so that its public adoption is achieved earlier than expected. The concept of this app is a step in the right direction, and I hope there will be more to come!
Do you want to know more about Self-Sovereign Identity? Read my series, watch a webinar I held recently, or contact me!
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 humanitariansupplychain 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:
A simplified chart of the authentication process.
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.
Privacy is one of most central topics of this internet connected era. People want their private data to be protected from third parties which, for instance, resell the collected information to promote personalised advertisements or worse to do things like manipulate elections with what amounts to weaponised data science. In the past it was often the case that privacy was a mere afterthought when designing an online application. That’s not the case anymore. In the wake of scandals such as Cambridge Analytica, it has become increasingly clear that system design needs to put privacy front and center if we want to avoid dystopian outcomes in our society. Thus, “Privacy by Design” was the topic of our meetup on on March 19, 2019.
Our audience at the meetup “Privacy by Design?”
The first person we invited to give some insights about this topic was Andrew Tobin, Managing Director of Evernym. Evernym is a US-based software company which develops decentralised, self-sovereign identity applications. Andrew talked about how Evernym developed and open sourced the Sovrin protocol to manage the secure and private issuance, holding and verification of digital credentials in a decentralised manner.
By using Sovrin, anyone can verify claims made by identity owners including the following four aspects of data validity without any contact with the credential issuer. This eliminates the risk that anyone can draw a correlation about private activities of credential holders based on the claims they make to verifiers.
Who issued the data to the holder?
Was it issued only to the holder, and not to anyone else?
Has the data been tampered with between issuance and time of claim?
Has the issuer revoked the credential?
He also pointed out that Sovrin is not limited to human credentials making highly useful for the M2M economy. It can also be used to issue and verify credentials for organisations and things empowering proofs for stuff like part numbers of machine components, company records or tax returns.
Sovrin enables the storage of verifiable credentials in a digital wallet. Compared to a physical wallet, there are a number of additional benefits. Backup- and recovery functionality, the ability to revoke credentials remotely and a selective disclosure functionality for the individual data points making up your identity are all made possible using this technology. The trouble with paper credentials is that they’re pretty stupid. Passports can get lost or stolen, if you show your drivers license to someone you have to show them the entire document, not just the relevant details, and if an issuer wants to revoke a credential they’re pretty much out of luck when using a traditional paper identity document. With self- sovereign identity all of these scenarios are no longer problematic.
If you want to learn more about Evernym, their solutions and tools behind it, check their website or Andy’s slides here and here.
Andrew Tobin presenting Sovrin, a self-sovereign identity solution
The second speaker of the event was Kevin Leuthardt the new Steward of Governance Working Group of the European Blockchain Association (EBA). He briefly presented the founding of the Working Group Governance in the EBA and explained how decentralised organisations can rely on a suitable governance model.
If you are interested in governance in decentralised organisations and have a law background we would appreciate if you could take a couple of minutes to fill out this survey. Thank you very much in advance.
Kevin Leuthard presenting an update on the EBA Working Group Governance
As the final speaker of the day, we invited Dr. Elad Verbin to the stage. Elad is a Berlin-based computer scientist specialising in blockchain technologies, algorithm engineering, and predictive modelling. In blockchain space, he works on blockchain filesystems, governance, and macro-cryptoeconomics. At this meetup Elad shared some insights about “Privacy on the Blockchain – Zero Knowledge Proofs and their Future Use”.
First of all he explained why people should care about privacy on the blockchain.
The first reason to do so is that privacy on the blockchain is broken. In the early bitcoin days people were buying pizza online with the same addresses they used to buy drugs on Silk Road. Even if it wasn’t clear to the users at the time, what is clear now is that the buyer of the pizza is also the buyer of the drugs. There’s a whole industry of players such as Chainalysis and BitCluster cropping up with products dedicated to tracing these transactions out there “in the clear”.
The second reason to care about privacy of the blockchain is that private computation is necessary for Web3. It is not desirable to for all transactions made on the blockchain to be public. That notwithstanding we still want the benefits that data availability provides. As a result we’re increasingly turning to computation on encrypted data, for example homomorphic encryption, to restore privacy while maintaining the availability of data sets for computational tasks.
The third reason is that more privacy establishes more trust in the system which automatically leads to more shared information and therefore more value all around for everyone.
The second aspect, Elad pointed out is the so called Secure Multiparty Computation (SMPC).
In SMPC, every player in the system learns only about their own input into the system and the output of the system without knowing the input of the other players so that privacy comes first. The special thing about SMPC is that it can be done for any function given enough time for computation and every task that can be computed can also be computed securely.
In an ideal world there would be a trusted middleman who could compute those functions. The middleman could collect all the input of the players and simply publish the result back to the players. We all know however that the trusted middle man approach usually fails due to the untrustworthiness of the “man in the middle”. SMPC protocols functionally simulate the trusted middleman scenario without actually requiring any trusted party.
As a third point he introduced applications of private computation.
Private computation has been used in a number of productive contexts already and it is starting to seep into consumer applications like such as the chat platform Telegram. The same goes for Zero Knowledge Proofs nowadays.
As a first practical example, Elad presented a case study about Sugar Beet Auctions in Denmark from 2008. The problem there was, that the participating parties in sugar beet auctions needed a secure technical means of simulating a “trusted middleman” without actually having such a party and also without revealing private bids or the demand curve of the commodities purchasers. After deploying a SMPC-protocol-based auction system, the parties only knew how much they each sold without learning anything about the overall auction results while still arriving at an efficient market clearing price at the market level.
Based on this success governments started using private computation for radio frequency spectrum auctions resulting in more efficient and more fair auctions for these public goods. Telecommunication companies didn’t have to make the prices paid for spectrum rights public and simultaneously the state received an efficient economic outcome from the auction.
Another potential use case is for private computation would be an algorithmic redistribution of wealth whereby individuals could make their finances and demographic information available in an encrypted format for algorithmic analysis. The idea here is that if the data were made available due to the advent of widespread trust in private computation, algorithmic design including reinforcement learning, control theory and optimisation theory could give us substantially better results and public policy than is available today. In the future, there will be more and more libraries available for private computation. Compared to today, the computation will also be cheaper and faster.
The last major point in Elad’s presentation was regarding practical issues in adopting this technology.
The first issue is the challenge of replacing the trusted middleman with a protocol. How is the function f defined and how to keep the privacy over time?
The second issue is the speed of SMPC. The speed of SMPC is pretty slow right now. But compared to some years ago it became significant faster.
The third issue is the current general lack of trust in SMPC. It’s a big challenge for a new innovation to gain trust of the users. It takes some time for people to trust innovations and adapt to new technology.
Dr. Elad Verbin presenting Zero Knowledge Proofs and their future use
We want to thank the speakers for their very interesting presentations at this Meetup about “Privacy by Design?”. We also want to thank Deloitte for hosting our event at their facilities and of course we want to thank our guests for coming to our meetup and asking high quality questions.
We would appreciate seeing you again at our next meetup about “The State of Secutity Token Offerings” on May 21st, 2019.
“Facebook would never change their advertsing relying on a sample size as small as we do medical research on.”
(David Wilbanks)
People want to learn about themselves and get their lives soundly supported by data. Parents record the height of their children. When we feel ill, we measure our temperature. And many people own a bathroom scales. But without context, data is little meaningful. Thus we try to compare owr measurements with those of other people.
Data that we track just for us alone
Self-tracking has been trending for years. Fitness tracker like Fitbit count our steps, training apps like Runtustic deliver to us analysis and benchmark us with others. Since 2008, a movement has been around that has put self-tracking into its center: The Quantified Self.
Self-tracking has been tending for years. In this picture you see a wristband that already made it into a museum and is now on display in the London Science Museum.
However it is not just self-optimizer and fitness junkies who measure themselves. Essential drive to self-tracking originated from self-caring chronically ill.
Data for the physician, for family members, and for nursing staff
In the US like in many countries lacking strong public health-care, it becomes increasingly common to bring self-measured data to the physician. With many examinations this saves significant consts and speeds up the treatment. With Quantified Self, many people have been able to get good laboratory analytics about their health for the first time ever. One example is kits for blood analysis that sends the measurement via mobile to the lab and then displays the results. Such kits are e.g. widely in use in India.
Also for family members and nursing staff, self-tracked data of the pations is useful. They draw a realistic picture of our conditions to those who care for us. Even automatic emergency calls based on data measured at site are possible today.
The image at the top is taken from the blog of Sara Riggere, who suffers from Parkinson. Sara tracks her medication and the syptoms of her Parkinson’s desease with her smartphone. Her story is worth reading in any case, and it shows all facettes that make the topic “own data” so fascinating: http://www.riggare.se/ and http://quantifiedself.com
Mood-tracking – a mood diary. People suffering from bipolar disorder try to help themselves by recording their mood and other influences of their lives. By doing so, they are able to counteract, when they approach a depression, and they are able to finetune their medication much better, than it would be possible by the rare visits to their psychiatrist. (Shown here is soundfeelings.com)
Data for research
Self-recorded data for the first time maps people’s actions and condition into an uninterupted image. For research, these data are significantly richer than the snap-shots made by classic clinical research – regarding case numbers as well as by making possible for the first time to include the multivariate influences of all kinds of behavior and environment. Even if only a small fraction of self-trackers is willing to share their data with researchers, it is hardly to imagine the huge value the findings will have for medicine, enabled by this.
Privacy
The difficulty with these data: they are so rich and so personal, that it is always possible to get down on the single individual. Anonymization, e.g. by deleting the user id or the IP adress is not possible. Like fingerprints, the trace we leave in the data can always identify us. This problem cannot be solved by even more privacy regulation. Already today, the mandatory committment to informed consent and to data avoidance impede research with medical data to such extent, it is hardly worthwhile to work with it, at all. The only remedy would be comprehensive legal protection. Every person sharing their data with research has to be sure that no disadvantages will come from their cooperation. Insurance companies and employers must not take advantage from the openness of people. This could be shaped similar to anti-discrimination laws. Today, e.g. insurance companies are not allowed to differenciate their rates by the insurant’s gender.
Algorithm ethics
Another issue lies within the data itself. First, arbitrary, technical differences like hardware defects, compression algorithms, or samling rates make the data hard to match. Second, it is hardly the raw data itself, but rather mathematical abstractions derived from the data, that gets further processed. Fitbit or Jawbone UP don’t store the three-dimensional measurements of the gyroscope, but the steps, calculated from it. However, what would be regarded as a step, and what would be another kind of movement, is an arbitrary decision of the author of the algorithm programmed for this task. Here it is important to open the black boxes of the algorithms. As the EU commission demands Google to open its search algorithms, because they suspect (probably with good reasons) that Google would discriminate against obnoxious content in a clandistine way, we have to demand to see behind the tracking-devices from their makers.
Data is generated by the users. The users have to be heared what is made from it.
