<![CDATA[Consento]]>/https://write.georepublic.net/favicon.pngConsento/Ghost 3.8Mon, 05 Oct 2020 15:14:22 GMT60<![CDATA[In consent we trust]]>/blog/in-consent-we-trust/5d4270a10c68940564e15058Sun, 03 May 2020 22:30:00 GMT

The concept behind Consento - Human-Factor Authentication - requires trust. Consento aims at delivering a novel way to securely store confidential data encrypted without central cloud solution, and access them without depending on complex passwords. Instead, with Consento users can request the consents of peers they have decided to rely on. Such a new way to secure confidential data requires appropriate UX (user experience) & UI (user interface) to guide users in handling data privacy. But before discussing about the right UX/UI, we need to discuss a bit about a fundamental object: trust.

Indeed, before it comes to build trust in the  UI, we need to build trust in the system. And before the system, there is the belief in the system. Consento story requires quite some thoughts about various forms of trust: trust in the system build by the web of devices, and in the other peers who act as trustees, if not also trust in the Consento business and team itself. So, to start with, what do we speak about when we speak about trust?


We like the definition of trust as "a psychological state comprising the intention to accept vulnerability based on positive expectations of the intentions or behaviour of another" (Rousseau et al., 1998). Trust depends both on the individual abilities to trust and on the trustworthiness another is able to display.

Said otherwise, trust is neither a cognitive process nor an innate human feature, it is both (Mújdricza, 2019). Studies have shown that trust is an a priori given human faculty, and therefore the possibility of trust is always present. But visual cues, human contexts and past experiences affect positively or negatively the level of trust. Trust happens to be 'learned' more than 'earned', and it requires a certain affective warmth for a start.

Contemporary online experiences of trust

Internet users experience online services as a fast pace changing context.  They regularly confront with new offerings, new companies, new standards, etc. In such an uncertain context, the aspect of trustworthiness can be built on social constructs like reliability and on individual constructs like integrity (Rousseau et al., 1998).

Among the services internet users experience online (van der Werff et al., 2019), display of trustworthiness emerge on levels such as reputation systems, third party endorsement, transparency mechanisms, etc. And novel ones keep on emerging.

  • The reputation systems provide a hint about trustworthiness based on other peers' previous experiences, as well as an incentive to behave trustworthy. Think for instance about peer-to-peer platforms tw-ways rating systems.
In consent we trust
Efficient 2-ways rating systems can bring trust. Blablacar is a carpooling service.

In the case of a decentralised architecture like Consento, with no central platform enforcing the rules, that system in itself might be less effective than the reputation in real life of these peers. Research (Nielsen, 2012) have demonstrated also that despite a tendency to trust more people who are similar to us, high reputation of peers (and stakeholders) eventually beats strong similarity among peers.

  • The endorsement by third parties such as insurance companies, governmental institutions or civil origins is never a discrediting thing to get. Commercial companies also rely on customers' endorsements. However, studies report that online consumers pay little attention to endorsement itself. Third party endorsements bring on credibility more than trust.
In consent we trust
Dropbox display for instance its customers' endorsement.
  • The transparency mechanisms rely on disclosing the code, the information about the company activity or the team members' affiliations. Fairphone for instance, discloses its full supply chain as a token for its commitment to transparency. On this aspect, Consento intends to embed transparency at its core, even though transparency might be a concept antinomic with keeping data confidentially hidden (this will be the topic of the next article eventually).
In consent we trust
Fairphone is commited to transparency, and discloses its supply chain.
  • Third party endorsement and transparency can be complemented by public self-assessments of governance.

Digital and in-real-life consents

As for one's ability to trust, it is constantly reassessed depending on the lived experiences, online and offline. A personal dramatic event, or a worldwide pandemic for instance, do impact people's ability to trust each other or their institutions. Even if Consento is first a digital tool, we remain aware that the evolution of people's trust capacities happens mainly off-line.

The 'nudge' approach represent an interesting look into that matter. Humans are inherently biased cognitively. For instance, we would rather avoid loosing than risking to win, we weight the same information differently depending on the credits we give to the speaker, we assess value differently depending on the initial frame given to us to look at the matter, etc.

We have to remember that Cass Sustein and Richard Thaller approach spurred discussion on how much governments or corporations should be allowed to 'nudge' us to do what they want us to do. But when we speak about trust, we should not dismiss our cognitive biases, because before being rational, we are first human.


So here are the track on which we'll work and test our assumptions : build on peer's IRL reputation, third party endorsement and transparency mechanisms. On these aspects, if you have any comments or recommendations of relevant actions for Consento team to take on, we are open to suggestions.

Else, what do you think? Is there any other ways of trust building we should keep in mind while developing Consento?

Image contribution by Anemone123 / 241 (Pixabay)

<![CDATA[How to stay in control of our data?]]>/blog/how-to-stay-in-control-of-our-data/5e8e8ccf72466406a3e27ae4Thu, 09 Apr 2020 02:52:20 GMT

About the thinking behind Consento and how it is supporting the plan to stay in control of data we need to stay in control.

Giving up responsibility is comfortable. We know this because giving up the responsibility of making good backups, structuring our data and publishing articles responsibly is something we gladly hand off to online platforms.

There are many common "best practices" how to minimize the exploitation of your data by big companies: Have multiple e-Mail addresses, use a password manager, don't share too much on social media etc. But this feels like a drop in the ocean. You still need to accept the rules of the system and hope not to get caught.

But how could a better system look like? How comfortable and powerful does a system need to be for us to maintain autonomy? We have been asking thinking and tinkering around these questions for more than a year and have received support from the NGI Ledger program a half a year ahead of our current, global challenges.

Here is the set of important requirements we identified:

How to stay in control of our data?

"on our device" - the devices we own need to be capable to hold the private data we own. Even if we have a lot of data, more than our devices are capable of, this needs to work.

How to stay in control of our data?

"no server necessary" - whatever thing you are watching on the internet runs on a server and that server has costs attached! With those costs come business interests and we need our tools to be free of this dependency.

How to stay in control of our data?

"with our consent" - (spoiler alert: that is how we came up with the name 😉) Asking for consent can easily become a vain effort:

  • "Do you agree to use cookies?"
  • "Do you confirm to our terms of service?"
  • "Do you accept the license agreement?"

  • You probably know those questions and how pointless they have become. Reducing those questions to only show when they are relevant and to visualize the relevancy is very important.

    How to stay in control of our data?

    "maintaining privacy" - ending requests for consent are transferred using public infrastructure (cables, network towers, etc.). It needs to use strong cryptography and needs to make not only sure that communication is as-private-as-possible but that it also obfuscates communication to make sure no-one knows who communicates with whom.

    How to stay in control of our data?

    "controlling identity" - be it for business, family, pleasure or medical tests; many of us use more than one identity online, and many offline: multiple email addresses, google/twitter/etc. accounts. A tool that can work in its place needs to be able to have different identities to different people.

    How to stay in control of our data?

    "free for all" - web services are accessible to a very wide range of people. We can not build an internet-of-trust on technology that costs. Any cost means more to the poor of us than to the rich. For that reason, everything we publish is open source and free to download on app stores, with the goal for everyone to benefit from it.

    How to stay in control of our data?

    "human centric" - this is a big word, but in our case we identified that the thing humans are worst at is keeping a secret(password) safely. We need to accept our human limitations and fallability and take it into account.

    Under the name of Consento, we started with a mobile application that exchanges consent requests through a completely private network with anonymized identities. You can take it for a test-ride by downloading our latest release.

    As a team, we started to work on this issue with Georepublic being the primary entity. We hope that now, as we are getting to something more concrete, others will join our effort and help us make it a reality. → https://github.com/consento-org

    As a society, we are not at a place where we as individuals can take on our "data-responsibility" yet. That's why we aim to raise awareness for this topic and also reach out to non-tech-savvy people, because the issues we want to solve concern everyone!

    While the topics of the NGI Leder program are broadly spread, many of our sibling projects work on complementary goals: Cobox has been building the software infrastructure that allows us to exchange content. Iuvia has been working on a hardware one-fits-all solution that can be used as a server in house, building with similar building blocks, both necessary to take control over data storage sovereignty (read more in Jaya's post). oneHealth works on a responsible collection of medical data (think Fitbit; but also doctors offices) and Worldbrain's Memex is moving browsing information to a decentralized place.

    If you can take this as an opportunity to support all of us by sharing our work, asking us questions or contributing to our efforts, that would make our day.

    Thank you for reading.

    Photo credit by https://unsplash.com/@swimstaralex

    <![CDATA[Choosing the hard road: Mobile-first!]]>About why we chose a mobile app as a start for Consento, what challenges we encountered and what we learned on our way−so you don't need to.

    Around June of 2019, we were discussing and thinking hard about an initial version of Consento would look like−a MVP. We

    /blog/mobile-first/5e3e6c38174a5963a4c250f1Thu, 02 Apr 2020 08:49:50 GMT

    About why we chose a mobile app as a start for Consento, what challenges we encountered and what we learned on our way−so you don't need to.

    Around June of 2019, we were discussing and thinking hard about an initial version of Consento would look like−a MVP. We had a few long and hard discussions, trying to tie down what is necessary for us to figure out. Our priority No. 1 eventually landed on daily usability. We wanted to make sure that whatever product we are building will be useful in everyday life. Ultimately, it means that this has to be on a mobile device; a mobile app.

    This was a problem for us. Yes, we are developers and−yes−we have experience with desktop and server software, but no: our strength is not in mobile apps. We had to learn quickly and make choices. To make this an informed choice we looked at our requirements:

    1. We need it to be JavaScript based to stay compatible with the dat ecosystem.
    2. We do not want for the user interface to stutter. This means our code needs to run separately from the UI (in a different thread).

    Of the two popular choices we found, we went with React Native over NativeScript. It seems easier to find people with React Native experience. It has a pretty good reputation and we wanted to use React for the user interface. Choosing it seemed the straight-forward choice.

    React Native can be used as-is, but for quicker development we learned that Expo.io is really comfortable. Expo limits React Native to a pre-defined set of extensions. This restriction allows the immediate installation on any device, quickly. No need to wait for slow build or publishing processes. − Cool, we definitely want that!

    Design Process

    We want to use Open-Source software for as many tasks as possible, as it allows contributors to join freely and quickly. Sadly, we have not found a free design software that works for us. Sketch is reasonably cheap for a design software, can be used offline, allows some hacking with the format and is overall the only choice we could see−even though it runs only on MacOS. (though .sketch files can be edited using Lunacy on Windows)

    Choosing the hard road: Mobile-first!
    From sketch to mockup to prototype. Marc made some nice designs for us.

    With the design ready we need to turn it into code. We wanted to automate that so we also informed ourselves here:

    • BuilderX looked professional but has a steep price tag of 15$/month/person and the output wasn't good to use in our opinion. Repeat output would clash with expo and typescript and we had to improve the output by hand.
    • Zeplin.io is useful for communication and is okay for a copy & paste process but in the long run was going to be painful for updates: What did we already update? Where is the difference between design and code? How do we add the non-trivial features?
    • Sketch-to-react-native does sound promising but it exports to JavaScript (and we work with TypeScript) and the output is not suitable for repeat exports. This would allow us to export once and any future update would be problematic.

    After testing a few alternatives we knew what we needed.

    1. It needs to be able to change the Sketch file repeatedly without breaking the rest of the code.
    2. It needs to output all the things we need: images, fonts, elements.
    3. It needs to be free or cheap.

    Since we couldn't find any tool to do that, we wrote it ourselves. 🤓 ↓

    Hello, expo-export!

    To get the workflow right we built in parallel to our first app expo-export! It is a free and opensource software, that you can add as a plugin to Sketch. It will add a menu button that with one click exports the assets, fonts and components of the layers in that sketch file to relative folders.

    In its current version expo-export is rough around many edges but the development has been mostly a breeze and we learned a lot about the capabilities of Sketch. Now, when we create changes in Sketch we can see the updates immediately(-ish) in the mobile app.

    Choosing the hard road: Mobile-first!
    Simulator (or device) is updated quickly after sketch export is triggered.

    Security & Performance

    The last topic for this post is about performance. If you try to use Consento right now on a slower device, Consento will be slow! Particularly when adding a new Relation or adding a new file to a vault. The reason for this performance issue is tied to our initial choices (back in the first section). In order to work with dat, we need to rely on a specific encryption system (libsodium) that is not working fast on react-native.

    We thought initially that this should be the smaller issue and will be easily improved later-on but it turns out that encryption on mobile devices is a pretty big deal. The current version works more-or-less but because of time constraints the current solution is not compatible with dat. 😱

    Maybe we should have gone with NativeScript as a platform? NativeScript has a synchronous libsodium plugin after all, though without iOS support. A more straight-forward choice might have even been nodejs-mobile, a recommendation we received quickly from the mapeo team, after asking for it far too late.

    When we started we also were not aware of publication difficulties in the AppStore (specifically france) due to long-standing rules on cryptographic exports or limitations on importing cryptographic in parts of the world. China also put out new crypto laws.

    In short, we need to rethink our strategy for getting dat-compatible and fast cryptography to work on a mobile phone. Choosing the hard road: Mobile-first! to our github issue #90 to follow our progress.

    You can have a look at the Consento mobile app right now → Releases.
    The version v1.0.2 is still a very early preview, but it may inspire you.

    In the meanwhile, we will be working on several improvements. You can follow our progress on this blog, using  RSS, or in the  keybase chat.

    <![CDATA[Why we have nice illustrations.]]>/blog/nice-illustrations/5e55f364025266362e1f04a3Thu, 05 Mar 2020 01:05:49 GMTMost open source projects might have a nice logo, some even have a nice layout but very few have their own, nice illustrations. If you look at the Consento homepage or at the app you might see quite a few illustrations such as the one below.

    I will catch you.

    These have been created by Tanja who joined us to help with the user interface. For the longest time the whole team struggled to vocalize the issues we tried to solve with Consento, but only when she started to bring them to live in illustrations, we managed to communicate in a clearer way.

    The illustration above highlights one of our core values: We need to build trust with each other and Consento shall be a tool enabling this relationship.

    Open source does not only mean program code to us. The illustrations are licensed under the Creative Commons BY-NC-SA license which means that as long as you attribute Tanja and share the work under the same license you can feel free to use it in your project.

    <![CDATA[Consento receives funding by NGI!]]>The goal of Consento is to provide a free and open technology for humans. Neither free nor open rimes well with profit though, and our initial team has been thinking about how to make Consento viable from the start. It was clear to us that we will progress slowly on

    /blog/funding-ngi-2019/5cf602c9b01c0961af354a70Mon, 17 Jun 2019 05:43:40 GMTThe goal of Consento is to provide a free and open technology for humans. Neither free nor open rimes well with profit though, and our initial team has been thinking about how to make Consento viable from the start. It was clear to us that we will progress slowly on our own. Through our contacts in the DAT community, we learned about various funding opportunities and eventually found the perfect match with NGI's new LEDGER program.

    The Next Generation Internet (NGI) is an EU fund that supports the decentralization of power in the internet and the empowerment of humans in this technology-powered day and age. The LEDGER program of the NGI focuses particularly on this core topic and so we applied. (We first took the character limit for a word limit in the application, and basically we wrote a short book on Consento before we had to cut it down to the essence 😅)

    Daniel presented the general concept and the work we did on May 29th in Amsterdam. The event was stuffed with people that spoke the same language with us. This was an exhilarating experience for him, considering that we hardly found someone vaguely familiar with that topic in our physical surroundings.

    The NGI saw a lot of potential in Consento and we are now part of the first batch of projects! In this first funding we will be focusing on prototype development (giving you something you can try out) and further UX research.

    We are so excited about this and hope you join us on our way to the future!