We are continuing with the APC series Building a Free Internet of the Future, our monthly series of interviews with NGI Zero (NGI0) grant recipients and consortium members. Funded by the European Commission, NGI0 supports free software, open data, open hardware and open standards projects. It provides financial and practical support in a myriad of forms, including mentoring, testing, security testing, accessibility, dissemination and more.
In 2023, the LibResilient project received an NGI Assure grant to create a “browser-based decentralized content delivery network”, which is linked to the issues of access to information and the digital human rights space.
This month, we talk to Michał "rysiek" Woźniak, the project leader. Michał is an information security and infrastructure expert and digital human rights activist (read more on his blog).
This interview has been edited for clarity and length.
What does “digital human rights space” mean for you?
One way to look at it is: people and organisations working towards preserving and advancing human rights in the digital context. Another way to look at it is: the problem space around human rights in the digital context.
Please note that I am not talking about "digital human rights", but about "human rights in the digital context". Universal human rights are relevant regardless of the means with which we communicate or the tools we use to exercise them. I strongly believe the work that is done in this space has to be grounded in the universal ideas about humanity.
In relation to human rights in the digital context, you're working on LibResilient. What is LibResilient for people unfamiliar with cybersecurity?
LibResilient is a tool to help websites stay available to their visitors even if they are experiencing technical difficulties or are being blocked.
On a technical level, LibResilient is a JavaScript library. When a website that uses this library loads for the first time for a given visitor, it loads this JavaScript code along with its configuration defined by the website's administrator, and instructs the browser to cache them – keep a copy for a longer period of time.
Now, when that visitor visits the website again and the website happens to be unavailable for whatever reason – overwhelmed by traffic, experiencing technical difficulties, or perhaps being blocked – that cached piece of JavaScript code tries to retrieve the content from other places, based on the cached configuration.
In other words, if you're visiting example.com, and it uses LibResilient, when you visit again and example.com happens to be down, you might not even notice – the piece of JavaScript code might pull the contents of the website from other places. Or, depending on the configuration, it might outright redirect you to a new domain set up by the website administrator just in case.
If you are a website administrator, LibResilient gives you a way to keep your website available to your visitors in case of technical difficulties or blocking, without relying on centralised gatekeepers like large CDNs [content distribution networks], which come with their own set of problems.
So if I take the example of the GenderIT.org website, which could be censored and/or made difficult to access by private companies and/or states, LibResilient could help internet users to access the website's content?
LibResilient would help returning internet users to continue accessing the website's content. Yes, even if the website is blocked.
Because LibResilient relies on the website telling the browser to cache a piece of JavaScript, the website needs to have been loaded at least once in a given browser. So it only works for returning readers.
My experience managing web infrastructure for the Organized Crime and Corruption Reporting Project (OCCRP) during the Panama Papers investigation and beyond taught me that most of the time it's the returning readers that website admins care about.
The other thing I learned is that if the reader is required to change anything in their set-up – download Tor Browser, install a browser extension, change their DNS settings, and such – only a very small portion of readers will actually do that.
LibResilient does not require anything of the readers, apart from having visited the site once within the previous month or so (that limitation is related to how browsers handle caching of relevant JavaScript code). This means that for any returning readers, the website will "just work", even if it is blocked, or otherwise unavailable.
The only other piece of the puzzle is for the website administrator to make the website content available under other domain names or through other protocols (LibResilient supports IPFS [InterPlanetary File System], for example, though it's slow in the browser), and then create the LibResilient configuration file referencing these alternative sources of content. This is covered in the Quickstart guide for website administrators.
In your professional career you've been involved in a number of organisations with a tech/information access as politics angle – among them the Organized Crime and Corruption Reporting Project (OCCRP). Now you're developing − alone for the time being − your own tech project with an NGI Assure grant. Why this choice?
I decided to start developing LibResilient because I felt I found a potentially powerful solution to a problem I had been dealing with time and again at OCCRP – website blocking, or websites otherwise becoming unavailable to their readers.
At the time – and that was about five years ago – I have not seen any other project that was focusing on this particular way of solving this problem.
Getting the NGI grant was of course very important: it not only allowed me to focus more time on the project, but also I got some great input from Michiel Leenaars from NLnet, for which I am very grateful and which helped get the project out of the proof-of-concept stage and into the current stable beta stage.
I also feel strongly about dealing with the problem of centralised gatekeepers like large CDNs, which I hope LibResilient can help with.
Broadly speaking, there are limited options for website administrators experiencing downtime or blocks, and these huge companies [CDNs] made it their business model to convince them that their services are the only way. I believe they are not, and in fact I believe that in the long term these centralised CDNs will create more problems than they solve.
LibResilient offers an alternative that can work here and now, today.
It is not my main focus, however, as it is not able to financially support me currently. I have a day job, and I also have some other side projects. I would very much like LibResilient to garner some interest and get deployed in production on some serious website, as that's the necessary next step for the project now.
Finally, while I am the main developer, I got a lot of input and help (and some code) from a few other people. These contributions were important and very much appreciated.
In 2024 you wrote, “We are more interconnected, yet more misinformed. At ease with more advanced technologies, but more easily mislead by them […]." So how can we collectively set up “digital human rights spaces” and take care of them?
I strongly believe we need to recognise that technosolutionism and individualism, the kind peddled by cryptocurrency folks, for example, are dead ends. “Zero trust” is a dead end.
We need trust, we need communities.
Technology is important, but it's just a tool, and can be built and wielded in many different ways. Or, as Melvin Kranzberg put it, “Technology is neither good nor bad; nor is it neutral.”
Think of a knife – it's a pretty simple piece of technology we're all familiar with. But it's design defines what it can be used for and how it affects us when it is in our immediate environment. A knife in and of itself is neither good nor bad, but having a butter knife around is very different from having a butcher's knife.
When we're talking about human rights in the digital context, we're talking about human rights intermediated by technology. Our freedom of speech is mediated by the internet messenger service we use, or the social media platform we're on, for example.
How are the tools and technologies that create the digital spaces in which we exercise our human rights designed? Do they make dogpiling easy? Do they make surveillance easy? Do they give agency to the person using them, to the community that person belongs to, or somebody else? These are questions that were also very much on my mind when I created LibResilient.
Note that I am avoiding the word "user". "User" defines a person through the service they use – I think that's a dangerous proposition. I am not a "user" of a particular service, I am a person who happens to use a particular service. This might not sound like a huge difference, but I believe it really is.
We must recognise that our own personal choices with regards to technology are political and have a moral dimension to them. And that yes, sometimes we will need to choose a less convenient tool, if we want our community to be built in a long-term resilient way.
Some popular instant messengers (IMs) might be easier to use than more privacy-preserving IMs, but that is often the case because doing certain things in an end-to-end encrypted way is genuinely more difficult and will have certain kinds of friction that an unencrypted IM will never have to deal with.
Some popular centralised social network platforms might be easier to use than federated, agency-preserving ones, but that is in no small part related to the fact that doing certain things in a federated, decentralised way is genuinely more difficult and will introduce certain kinds of friction that a centralised social network will not ever have to solve.
These unencrypted IMs and these centralised social networks come with other, more sinister issues – issues of surveillance, issues of giving power over our communication to specific companies that have shown themselves to be outright malicious. Issues that directly affect our ability to exercise our human rights in the digital context. And we know that at this point it is pretty clear to anyone who's paying attention.
So, we have to be able to make these hard choices. We have to be open to choosing a tool that might have a bit more friction, but does not create a direct threat to the human rights we want to exercise and communities we want to nurture. And we have to be ready to support such projects, including financially or with our own time and effort.
Otherwise, as Twitter and Facebook debacles show, we are building our castles in the sand.
The floor is yours: a wrap-up that doesn't end but opens up. What kind of message would you pass on to activists?
That their work is more important than ever. That even if it feels like they're not able to make any progress, that's not true – every bit does count, a lot. That the most important "digital competency" skill is empathy.
And that the fact that every now and then we win, even though we are all working on a shoestring budget, against gigantic organisations that have all the resources and power in the world, is proof positive that we're on the right side of history.
Xavier Coadic is a consultant for the NGI0 consortium, and a free/libre open source software activist with 15 years of experience in free open source cultures and communities (software, data hardware, wetware, policy makers and political groups, research and development).