[tor-bugs] #12002 [Ooni]: Initial M-Lab comments on threat model

[Tor Bug Tracker & Wiki]

#12002: Initial M-Lab comments on threat model
-------------------------+-------------------------
 Reporter:  cypherpunks  |          Owner:  hellais
     Type:  defect       |         Status:  new
 Priority:  normal       |      Milestone:
Component:  Ooni         |        Version:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:
-------------------------+-------------------------
 This issue was automatically migrated from github issue
 https://github.com/TheTorProject/ooni-probe/issues/150.

 Here are initial comments on the threat model. These are minor, and many
 are clarifying questions that most probably reflect a misunderstanding on
 my end.

 I'm happy to break these out into individual issues, if that would be more
 useful. For now, this seemed like an easy way to review in total, and
 eliminate those that don't deserve issue pride of place.

 ***Page: Roles***

 *Analyst
 An analyst may or may not publish the data, as I understand it. I’m not
 sure this impacts the taxonomy, but accessing and deducing meaning from
 the data is the core function of an analyst -- with publication being a
 very likely outcome.

 Would an analyst also reply on access to the source code, and data
 descriptions, such that they can vet the methodology?

 **

 *Bystander
 Bystander could also encompass whatever entity is implicated in the
 analysis of collected data. E.g. an ISP who’s throttling service, or a
 government who is censoring politically sensitive content. I think that
 this category of bystander (or, another title) is important in mapping the
 weight of different threats. E.g. if data is falsified and it implicates a
 powerful adversary, this could be more problematic in terms of an
 existential threat than false data that’s nonsense, or implicates an
 entity with little reason to care/little leverage. This, then, could be
 something that is included in the threat impact table -- any false data
 that’s published is, potentially, a threat to a bystander. Whether or not
 it makes sense to stretch things this far is another matter...

 In M-Lab's case, bystanders also include the other tools on the platform,
 and a given entity that relies on these tools and data (e.g. the FCC, and
 a number of other governments rely on M-Lab in this way).

 **

 *Core Developer
 Would this also be the role responsible for documenting the data format
 such that analysts can make responsible use of it? I view this as separate
 from documenting the Ooni design, although there may be a good reason to
 conflate the two.

 Would the core developer also review and accept/reject net-tests into the
 core release of ooni-probe? I'm not seeing this process mapped anywhere.
 Although it's a future feature, I think it could have implications on
 threat modeling now.

 **

 *Net-test Developer
 It seems like they’d also rely on the Core Developers to review and
 integrate their tests into the core ooni-probe release. This isn’t
 necessary in all cases, but assuming that's a common-ish goal...

 I imagine they’d also share responsibility (or, take sole responsibility?)
 for documenting the data/data format (?)

 **

 *M-LabNS Operator
 Would also rely on the Core Developer to integrate M-LabNS into the client
 build, such that it correctly queries M-LabNS prior to choosing an OONIB
 backend.

 **

 *Publisher
 While the publisher does assume liability, this is not sole liability. The
 core developers, and the net test developers also assume liability, as
 does a rogue probe operator intent on injecting bad data (etc.) (whether
 or not they can be identified is another question). In this context, we’re
 laying out less a legally binding definition of “liability” and more a map
 that can identify nodes of liability, and ensure that any risk is
 documented.

 The publisher also shouldn’t be the only role taxed with vetting the text
 decks and specifications. As above, since there are multiple nodes of
 liability, this should be part of the core developer role, and part of the
 net test developer role. (or, to put another way, the vetting is only as
 good as the documentation. (Caveat: I may be misunderstanding the
 definition of "vetting" here.)

 **

 *Reader
 Potentially also relies on access to source code (core developers
 documentation), and data (publisher), such that the assertions being made
 can be verified (similar to an Analyst)? This is an M-Lab meme, but one
 which makes sense beyond principle, in that the more contentions the
 claims made and the bigger the powers impugned, the more important it is
 that those witnessing them to confirm their veracity.

 **

 ***Page: Use Cases***

 *Initial release use cases: User Features
 Although it's certainly our aim, I am hesitant to confine our assumption
 about a probe operator to someone well-trained. There is already buzz
 around Ooni and its potential, and while we don’t want to wait to create
 something shiny and perfect, it would be good to scope this use case with
 an understanding that there may be some less-trained, less-knowledgeable
 people also attempting to run Ooni. (This includes "less knowledgeable
 about their personal risk".)

 Do we have an understanding of where the probe operator would access the
 ooni-probe to install it? This may also be a role? Or, is this covered in
 “invoking ooni-probe with an M-Lab-specific configuration”? The process
 here is a bit obscure to me.

 **

 *M-Lab deployment and management
 @stephen-soltesz  can add detail here as well.

 Ooni is also responsible for data formatting, such that the data inputted
 can be processed into long-term storage by the M-Lab pipeline.

 Placeholder, pending understanding of the collector policy implementation.
 It’s not clear to me how this is scoped, and the hope would be that a
 given collector can choose only to accept data that fits X specification
 (e.g. whitelisting the current Alexa top X00 URLs), and not rely simply on
 affirmation from the client that a given data input comes from a given
 test deck.

 **

 *Record quality and usefulness
 In the case of M-Lab, the core developers are also responsible for
 ensuring, insofar as possible, that the policies and tests deployed derive
 only from active, client-initiated tests. (This was a part of the
 application process, so many moons ago.) Ensuring this ongoing will
 require some process element, but will be an important interaction between
 M-Lab (and any publisher) and the core developers.

 **

 *Future use cases
 The “historical data” item will also imply metadata tagging on the part of
 a publisher (ideally).

 **

 ***Page: Threats***

 *Overall comment on a pretty impeccable taxonomy -- In the case of M-Lab
 operating in the role of OONIB operator, collector, publisher, any
 malicious attack that harms the operation of the infrastructure, or
 overall data collection, impacts bystanders, insofar as there are other
 tools running on the infrastructure, and other sources of data that must
 be collected for publication. I will leave this comment general to allow
 LA to fine-tune, or disregard. Happy to help elaborate if helpful.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12002>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online