wiki:org/meetings/2015SummerDevMeeting/ResearchEthicsNotes

Research network ethics discussion

Past (questionable?) research activity

  • Relay early attack (http://www.pcworld.com/article/2456700/black-hat-presentation-on-tor-suddenly-cancelled.html)
  • Exit traffic snooping (e.g. “Shining Light in Dark Places: Understanding the Tor Network” PETS 2008)
  • Attacking HSDir ring to discover unknown onion addresses (e.g. “Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization” IEEE S&P 2013)
  • Developers gathering private statistics their own relays for purposes of evaluating design improvements (e.g. counting the number of IPs listed in descriptors at an HSDir)
  • Bandwidth weight manipulation (“Trawling for Hidden Services”)
  • Adding lots of relays reduced the requirement for the Guard flag, the number of guards spiked, and their quality plummeted (“Trawling for Hidden Services”)
  • Collecting statistics about the ASes of clients and destinations (e.g. “AS-awareness in Tor path selection” ACM CCS 2009)
  • Collecting bandwidth statistics, which Tor does and enables hidden-service guard discovery (Sec. 2.1.2, Tor directory protocol, version 3)
  • Different, secret research activities can conflict, such as the hidden-service crawlers and the HSDir fetch measurements (e.g. “Tor: Hidden Services and Deanonymisation”, Chaos Computer Congress 31c3, 2014)

Goals

  • The scope of this discussion is developing a plan for guiding responsible research on Tor.
  • We should come up with a set of guidelines for research activity that researchers can use to evaluate their proposed plan.
  • We should also figure out a “due diligence” process for research that falls in the scope of “potentially dangerous” activities. This process can require some notification and feedback from the Tor network or other third parties.

Guidelines for research

  • It is lowest risk to gather information about your own activity (e.g. your client, your hidden service).
  • These guidelines should be used for self-assessement, and they will also serve as a template for notification to Tor.
  • Tor should provide (non-exhaustive) examples of specific types of unacceptable activity. For example, it is not acceptable to run an HSDir, harvest onion addresses, and do a Web crawl of those onion services.
  • General guidelines
    1. Only collect data that is acceptable to publish. In the case of encrypted or secret-shared data, it can be acceptable to assume that the keys or some shares are not published.
    2. Only collect as much data as is needed (i.e. data minimization).
    3. Limit the granularity of the data. For example, "noise" (i.e. added data inaccuracies) should almost certainly be added.
    4. Make an explicit description of benefits and risks, and argue that the benefits outweigh the risks.
    5. Consider auxiliary data when assessing the risk of your research. For example, data from snooping exit traffic can be combined with entry traffic to deanonymize users.
    6. Use a test network when at all possible.

Process ideas

  • Notification / responsible disclosure to Tor before research
    • Review group (e.g. tor-research@…, or Request Tracker)
    • The notification process should be private to prevent researchers from being scooped, but we should make it clear that public discussion is preferred.
    • It should be acceptable for proposals that don’t receive a response within X time to proceed with waiting longer (e.g. X=7 days).
    • The review group should provide thoughts and recommendations about compliance with the research guidelines. They may work with the researcher to improve the research plan.
    • Who should be in the group?
      • Tor people already have little time.
      • Other researchers could be members, with the caveat that group members should commit to not revealing or taking advantage of their knowledge from the notification process.
  • Results should be reported in a responsible way. For example, researchers should not contribute to media exaggerations.
  • How to incentivize researchers?
    • Convince conference PCs to reject papers that don’t follow the guidelines or have not engaged sufficiently with the process.
    • Make public objections to research that doesn't follow the guidelines or engage sufficiently with the process (e.g. blog posts).
    • Our immediate goal should be to try and help the people that want to do the right thing.
  • After publication, the proposal and response should be published to make the process transparent and provide positive examples for others to follow.
  • The review group can request that certain details about an approved proposal be released (e.g. identity of researchers) to preempt rumors and FUD about ongoing research.
  • Review group process may be used as a way to provide guidance to researchers who do not have expertise in designing safe experiments.
  • In the case of researcher mistakes, unanticipated results, or a significant change in research plans that may violate research guidelines, the review group should be notified.

Outreach to research communities

  • Once guidelines and process are finalized, try and convince conferences and journal that accepted papers should be required to have followed this process and to discuss the ethical considerations that they made about their work.

Next actions

  • Post discussion notes
  • Start wiki
  • Create thread on tor-dev
  • Invite researchers to comment on proposal
Last modified 2 years ago Last modified on Oct 2, 2015, 2:18:42 PM