How to engage ooniprobe users in the most ethical way possible

This session was facilitated by OONI and included a discussion about OONI's approaches and methodology in terms of informing its users about potential risks associated with the use of ooniprobe. Participants provided feedback on how to improve OONI's existing documentation and had a discussion about how to address associated risks.

Specifically, the session started off with a presentation of OONI's new web user interface (UI) which includes a set-up wizard that requires users to read documentation about potential risks associated with the use of ooniprobe. Once users have read this documentation, they are required to answer a few quiz questions correctly (demonstrating their understanding of risks associated with the use of ooniprobe) as a prerequisite to using the software. If users do not answer all the quiz questions correctly, they are redirected back to the "Risks" documentation. Once users have demonstrated their understanding of associated risks by answering the quiz questions correctly, they are then presented with configuration options. These options provide users with choices in terms of which data to share (ASN, IP address, etc.), how to upload their measurements (via Tor hidden services, cloud-fronting, or HTTPS collectors), and whether to have their measurements published by OONI (on OONI Explorer) or not. Furthermore, the configuration options of the web UI also enable users to choose whether they would like the HTTP-invalid-request-line test to be included in their deck or not.

Upon completion of all the steps in the set-up wizard, users can begin running tests with the click of a button, and they can view the results of their measurements directly within the web UI. The aforementioned steps included in the set-up wizard help ensure that ooniprobe users are aware of some of the basic risks associated with the sofware, and that they consent to them prior to using the software.

Furthermore, this session also included a discussion of other documentation created by OONI in an attempt to inform its users. Such documentation includes the following:

1. OONI's Data Policy: https://ooni.torproject.org/about/data-policy/

2. Test descriptions (what each OONI software test does): https://ooni.torproject.org/nettest/

3. Risks (longer and more comprehensive documentation about associated risks): https://ooni.torproject.org/about/risks/

4. Opt-out (user choices in terms of tests, data collection, etc.): https://ooni.torproject.org/install/ooniprobe/#opt-out

The above documentation is publicly available via OONI's main website and is shared with all partner organizations prior to establishing partnerships.

As OONI's software is free and open source, anyone around the world can run it. The above documentation and wizard included in the web UI are created to help ensure that users around the world can be more informed when using ooniprobe. OONI only actively engages users through the establishment of partnerships with local organizations around the world that are interested in studying internet censorship. As part of the process of establishing partnerships, OONI shares all relevant documentation, discusses risks with partners in real-time (via VoIP calls), and evaluates "best practices" on a case-to-case basis. In most cases, partner organizations have in-house lawyers who are in a position to assess legal risks and provide support when necessary. As part of OONI's Memorandum of Understanding (MoU), partner organizations are required to share relevant documentation and communicate potential risks to any third parties that they engage to host and deploy probes.

Some of the questions that OONI raised in this session include the following:

1. How can we improve our documentation and practices (as explained above)?

2. Should we be creating a methodology for risk assessment around the URLs that are tested for censorship? Different URLs present different levels of risk, and perhaps it might be useful to inform users of such risk, so that they can make more informed choices in terms of which URLs to test?

3. If we agree to create a methodology for risk assessment around test lists, should this include legal and socio-political criteria? If not, what types of criteria would you include, and which questions would you ask?

4. How can we ensure that probe hosts (who are 2 or more hops away from partner organizations) understand what ooniprobe does and what the associated risks are?

Feedback from participants:

1. Consider re-phrasing the term "risks" to something like "detectability" (which is less scary)?

2. Instead of creating criteria for URL risk assessment, consider whitelisting and blacklisting URLs per country? Whitelists can include URLs that are commonly accessed and present almost no risk (e.g. Alexa top 100), while blacklists can include pornography, hate speech, and other objectionable categories.

3. State in the 1st paragraph of the risks documentation that to OONI's knowledge, none of the risks detailed in the documentation have actually happened...and that all of this is just speculative (in an attempt to inform users of what could potentially happen, though none of this has actually happened).

4. Set-up wizard: Perhaps allow users to select options based on their threat models? Or make it clearer that the default options are actually the default (and why)? Provide "threat model questions" and based on those, provide suggestions to users?

5. Set-up wizard: Include a reset ("Get me out of here") button which allows users to exit the GUI if they do not consent to the risks.

6. Options to upload measurements: Briefly/concisely explain what each of the options are, or why they are recommended. For example, next to Tor hidden services, we can say "more private, but slower", or "recommended".

7. Include simpler English in the documentation -- perhaps refer to Wikipedia Simple English?

8. Translations? It's important to ensure that users are able to read and understand the documentation in their local languages...

9. To ensure that new probe hosts understand the risks, configure the Raspberry Pi GUI so that it is de-activated after it has been used (and so that new probe hosts will have to consent when they use it).