RESOURCES FOR HUMAN RIGHTS DOCUMENTERS

Key considerations for decision-making around documentation tools

This section is designed to support civil society human rights documenters in making decisions around tech tools.

The key considerations below are based on our research findings. As such, they are not meant as a fully-comprehensive checklist, but rather a starting point for documenters interested in integrating tech tools into their work.

Initial questions to ask about tools

The questions below are based on our initial set of selection criteria for tools that we focused on for our research. To find answers, it can help to check a tool’s website and, if possible, get in touch with the tool’s developer directly.

  • Has the tool been intentionally designed to address the needs of civil society documenters working in a human rights or social justice context?
  • Is the tool’s business model non-exploitative (in that their underlying business models do not make money through collecting data or locking organisations into ongoing, prohibitive charges)
  • Was the tool developed with input and feedback from documenters themselves?
  • Is the tool free and open source? (i.e. can anyone download the code and set up their own instance? Can anyone audit the code to see how well security has been implemented?)

Understanding the answers to these questions can begin the process of assessing the fit of the tool to your organisation’s needs, capacity and values

Designing a system to support your entire workflow

Most civil society documenters of human rights violations rely on a selection of different tools across their workflow, but these don’t always work together well. As such, it can be helpful to consider tools in relation to other tools in your overall ecosystem.

There are two main ways in which your data can move between tools: through built-in interoperability, or through import/export functionality.

Interoperability


Some tools are designed to work with certain other tools (sometimes tool developers will also collaborate on this) so it can be worth looking at groups of tools that work well together. See the Tools Table for some examples.

Import/export options


Import and export options are important when you’re going to need to move information from one tool to another, or receive information from particular sources, or certain types of outputs for sharing (e.g. pdf reports).

When exploring options, take into account that importing and exporting data can add an extra manual step to your workflow, and has its own security implications.

Important ‘non-technical’ questions to ask

Alongside technical considerations, the following ‘non-tech’ considerations can be crucial to consider before adopting a specific tool.

  • Have you defined your documentation goals and objectives as clearly as possible? These will determine, among other things, what information is collected in the first place, and how it is analysed.
  • Does your organisation have the capacity to set up and maintain robust methodologies and systems for using the tools you have chosen? These are crucial for success – for more, see the research findings on human rights documentation.

Security features and considerations

Human rights documentation can be sensitive and risky work, but these risks vary widely depending on context. As such, there is no single set of risks that all human rights documentation tools are designed to respond to.

When evaluating whether a tool is a good fit for your work, you’ll need to weigh up the specific risks involved against the capacities and limitations of both the tool you’re looking at, and those who will be using the tool.

Below are some key features to look for. (For some examples of tools that include the features mentioned, see the Tools Table).

Features designed to protect information collectors


Many documenters use their phones to collect evidence, but face scenarios where they might be stopped by an authority or perpetrator (these might be the same) and have their phone searched.

Some mobile collection apps above offer functionalities for this scenario, including:

  • The option to replace the app’s icon and name on your phone with something more innocuous, such as a calculator icon.
  • One-button instant app shutdown, and automatic removal of the app from the phone’s “recently used apps” list.
  • Easy and quick deletion of the app, and media captured, from within the app itself. This can be useful if, for example, a documenter sees they are about to be stopped.

Features designed to obscure identity


Some apps allow users to upload data to a shared folder or server pseudonymously, to protect their identity in case the data is compromised at the management or storage location.

Different types of encryption


Encryption is a key strategy for mitigating risks around evidence being accessed, tampered with, stolen or deleted by unauthorised parties. Encryption can be employed in different ways:

  • Encrypting data within a tool. Some collection apps, for example, enable images and videos to be taken using the app, where they are automatically encrypted. This mitigates the risk of the data being accessed or tampered with if the device is stolen and/or broken into.
  • Making sure data travels through a secure connection (for example, via TLS/SSL). Data might need to travel, for example, from a collection app to a designated secure server (where it is managed or archived), or data travelling between the browser and a website or web app. A secure connection mitigates the risk of data being accessed or tampered with in transit and is generally standard practice for any tool that takes data protection seriously.
  • End-to-end encryption. End-to-end encryption goes a step further, security- wise, and encrypts data from one end device or system to another. This type of encryption is used currently in a few widely-used secure messaging apps (e.g. Signal.) End-to-end encryption has also been used by some well-known documentation tools in the past – for example, Martus, which was sunsetted in 2018 after 15 years.

This resource from the Electronic Frontier Foundation (EFF) shows the key differences between transport-layer encryption (e.g. TLS/SSL) and end-to-end encryption.

Different hosting options


Some tools have options around where and how they can be hosted.

  • Self-hosting. With some tools, organisations have the option to set it up on their own servers. This can allow full control over the data, but self-hosting also requires a certain level of technical knowledge and skill.
  • Hosted instances of the tool. Many tool developers in the human rights documentation space offer hosted instances of their tool – in other words, an organisation’s data is hosted on servers maintained by the tool developer themselves, or by a trusted hosting partner.
    Tool developers will have varying levels of control and access here.
  • Hosting in different countries. Some tool developers or hosting partners offer hosting in different countries. Decisions here can take into account which authorities could potentially access the data.

Passwords and 2FA (Two-Factor Authentication)


Passwords are an important part of any secure system, but these too can be implemented in different ways.

  • Mobile apps: Though mobile apps in general tend not to require a user to enter a separate password after they have unlocked the phone, some can require one as an extra layer of security.
  • Web-based tools: For web-based software, an extra layer of protection can be added through 2FA (Two-Factor Authentication), which helps keep data secure in case your password is compromised.

For more explanation on what 2FA is and how it works, see this guide from Electronic Frontier Foundation.

Access permissions and monitoring


  • Many tools offer different levels of access permissions. Minimising the number of people in an organisation who have access to the most sensitive data in your system can be an important security strategy.
  • Activity logs can enable an organisation to keep an eye on who has accessed what in the system.

Security audits


Security audits involve external experts checking the security of a tool’s code on a regular basis. If the code of a tool is open source, organisations wishing to adopt the tool can also get an independent security audit done themselves.

Note that security audits can be complicated and/or expensive. Particularly for organisations with lower technical proficiency, additional support may be necessary to navigate this process.

Features to support verification and chain of custody

As photos and videos become increasingly easy to manipulate, verifiability of evidence is an ongoing challenge for documenters. And for evidence to be admissible in a legal context, proving chain of custody is key.

Human rights documentation tools can support chain of custody in a number of ways, including security protocols, audit logs (which can keep a running list of when something was accessed or modified and by whom), and automatically adding significant metadata at time of capture.
Functionalities that allow you to add extra metadata manually can also be useful.

Automatically-added metadata can include:

  • information about the file – including a cryptographic hash, which can be used to determine if a file has been altered.
  • the device the photo or video was captured on (manufacturer, hardware, device ID, screen size, and so on)
  • the environment in which the photo or video was captured (GPS location, information about nearby cell towers, wifi networks, and bluetooth signals, date, time, and so on).

It’s important to note, however, that chain of custody and verifiability of evidence can be just as much – if not more – about policies and practices around how data is managed than about technology features.

Chain of custody