Use Cases

OONI • Threat-Model • Roles • Use-Cases • Threats • Impacts • Disclosure

---

Contents

• User Features
• M-Lab Deployment & Management
• Record Quality & Usefulness

The page describes the use cases or stories for the initial release of OONI. If a use case is present here, everything needed to support it will be present in OONI's initial release. If a use case is deferred, that doesn't mean it's not important, just that it is not part of the minimal possible first release for OONI.

Initial Release Use Cases

User Features

A field operator, who is a well trained ooniprobe Operator, downloads and installs ooniprobe on a dedicated test-bench machine, goes to a specific location on the network and tests against oonib on M-Lab infrastructure, provided by the oonib Operator:

1. The ooniprobe Operator installs ooniprobe on a dedicated test-bench machine.

• This machine is configured to minimize interference with ooniprobe measurements. For example, it should not run other networking applications.

1. The ooniprobe Operator invokes ooniprobe with an MLab-specific configuration which includes directory service connection details.
2. ooniprobe contacts a directory service, provided by the Directory Service Operator, and learns connection info for collector(s) and test helpers.
3. ooniprobe contacts a collector, provided by a oonib Operator, to fetch test deck(s).
4. ooniprobe executes net-tests as specified by the test deck; these may interact with test helpers, provided by a oonib Operator; they also interact with unaffiliated sites and network infrastructure.
5. As ooniprobe executes net-tests, it updates a report on the collector, provided by the oonib Operator.
6. If the ooniprobe Operator is sensitive to forensics risk, they take precautions to sanitize the probe machine or network infrastructure.

• Issue #145: Is this an "Initial Release" use case? If so, do we need documentation for this?

• Note: ooniprobe runs on the command line, on a Debian stable laptop.

M-Lab Deployment & Management

• The OONI/M-Lab team are aware of the overall level of functionality of oonib across M-Lab.
• The OONI/M-Lab team identify a new build of oonib, and conclude that it is stable and ready to deploy on M-Lab.
• The OONI/M-Lab team non-destructively upgrade all of M-Lab infrastructure to a new stable build of oonib.

Roles:

Note: These responsibility prescriptions may not be accurate. See Ticket #146.

• The OONI team plays the role of Core Developer and Net-Test Developer, so they are responsible for clearly documenting oonib, ooniprobe, and the integration interface with the Directory Service`.
• The MLab team plays the role of Publisher, and is responsible for aggregating reports from oonib collectors and publishing that data.
• Both teams play the role of oonib Operator, responsible for operational management of oonib. The responsibilities are separated out as follows so that there is a single organization solely responsible for a given detail. (This reduces confusion, especially in the case of emergencies.)
  • MLab - verifying official test inputs & test decks.
  • OONI - release schedule.
  • OONI - unit testing, package-management testing.
  • MLab - deployment integration testing - ensuring a new release will properly deploy on MLab infrastructure.
  • MLab - executing deployments and upgrades of new oonib software onto live "staging" infrastructure.
  • MLab - Ensuring oonib collectors are correctly configured to serve the blessed test decks.
  • OONI - operational integration testing - ensuring a live staging environment performs as expected.
  • MLab - executing deployments and upgrades of new oonib software onto live "production" infrastructure.
  • OONI - operational smoke testing - ensuring a live production environment passes basic sanity checks.
  • MLab - infrastructure monitoring - noticing when something goes wrong with MLab networking, VM resources, etc...
  • OONI - application monitoring - noticing when a collector or net-test is behaving unexpectedly.
  • MLab - Fire Fighting - Quickly responding to emergency situations.

Record Quality & Usefulness

1. An Analyst, such as an employee of a human rights organization, downloads tarballs of OONI records from M-Lab, which serves as the Publisher.
2. As the Publisher, MLab is responsible to ensure data includes only records of client-initiated active measurements.
3. The OONI Core Developers ensures OONI's records include both ooniprobe and oonib version numbers (for both collectors and test helpers).

Future Release Use Cases

• Historical data about the functionality of the OONI service allows a Reader to identify which parts of the data may be unreliable.
• A community of Net-Test Developers implement and distribute their own OONI tests.
• A community of ooniprobe Operators run net-tests using their own input sets.
• Analysts (human rights organizations) view OONI data in a visualization and query-support tool.
• Analysis of data produced by OONI allows us to reach useful conclusions about censorship.
• Citizens in oppressive regimes can participate in various ways:
  • As a Reader, they can safely read reports about their Internet access.
  • As a ooniprobe Operator, they can acquire and run ooniprobe with a clear understanding of the risk that poses to them.
  • As a Net-Test Developer, they can develop and distribute net-tests that address previously unmeasured censorship techniques, especially those relevant to their Internet access.
• The OONI community of Net-Test Developers can contribute new tests to the core OONI platform.
  • Submitted net-tests could be incorporated into new core releases of OONI.
  • Extensions could allow ooniprobe Operators and oonib Operators to use net-tests which are not included in the core OONI distribution.
• If the reporting channel fails during a test, ooniprobe can recover and resume reporting.