Skip to content

GitLab

Commit 5afd7344 authored by Iain R. Learmonth's avatar Iain R. Learmonth
Browse files

Initial commit of Hugo port

parents
Hide whitespace changes
Inline Side-by-side
.gitignore 0 → 100644
View file @ 5afd7344
# Hugo default output directory
/public
## OS Files
# Windows
Thumbs.db
ehthumbs.db
Desktop.ini
$RECYCLE.BIN/
# OSX
.DS_Store
.gitmodules 0 → 100644
View file @ 5afd7344
[submodule "themes/torproject"]
path = themes/torproject
url = https://github.com/irl/torproject-hugo.git
Makefile 0 → 100644
View file @ 5afd7344
server: content/techreports.html
hugo serve
content/techreports.html: techreports-header.html techreports-footer.html techreports.bib
./generate-tech-reports
staging: content/techreports.html
hugo -b https://research-staging.torproject.org/
rsync -avz public/* staticiforme.torproject.org:/srv/research.torproject.org/htdocs-staging/
ssh staticiforme.torproject.org static-update-component research-staging.torproject.org
production: content/techreports.html
hugo -b https://research.torproject.org/
rsync -avz public/* staticiforme.torproject.org:/srv/research.torproject.org/htdocs/
ssh staticiforme.torproject.org static-update-component research.torproject.org
README.md 0 → 100644
View file @ 5afd7344
Tor Research Portal Website
===========================
This repository contains the source code for the Tor Research Portal.
The portal is a static website generated with the [Hugo](https://gohugo.io/)
static site generator. It uses a [Hugo theme
port](https://github.com/irl/torproject-hugo) of the [Tor
Styleguide](https://styleguide.torproject.org/). In the event that you are
looking to add/modify a technical report, you will also need to have
bibtex2html in your path.
Build and serve on localhost
----------------------------
```
make server
```
Deploy your changes to staging
------------------------------
```
make staging
```
Your changes will shortly appear at https://research-staging.torproject.org/.
Deploy your changes to production
---------------------------------
```
make production
```
Your changes will shortly appear at https://research.torproject.org/.
Adding a technical report
-------------------------
To add a technical report, place the final PDF to be published in the
`static/techreports/` directory. Add an entry to the BibTeX file
`techreports.bib`. This change will be made when you next run `make
server|staging|production` or you can perform only the update step by running
the `update-techreports-html` script.
archetypes/default.md 0 → 100644
View file @ 5afd7344
---
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
draft: true
---
config.toml 0 → 100644
View file @ 5afd7344
baseURL = "https://research-staging.torproject.org/"
languageCode = "en-us"
title = "Research"
theme = "torproject"
[[menu.main]]
name = "Home"
title = "Research Portal Home Page"
url = "/"
weight = -200
[[menu.main]]
name = "Safety Board"
title = "Tor Research Safety Board"
url = "/safetyboard"
weight = -190
[[menu.main]]
name = "Research Groups"
title = "Tor-related Research Groups"
url = "/groups"
weight = -180
[[menu.main]]
name = "Research Ideas"
title = "Research Ideas with Tor"
url = "/ideas"
weight = -170
[[menu.main]]
name = "Tech Reports"
title = "Tor Project Technical Reports"
url = "/techreports"
weight = -160
[[menu.main]]
name = "Mailing Lists"
title = "Tor Researchers Mailing List"
url = "/mailinglist"
weight = -150
content/_index.html 0 → 100644
View file @ 5afd7344
<div class="container mt-5 py-3 preamble">
<p>Many people around the world are doing research on how to improve the Tor
design, what's going on in the Tor network, and more generally on attacks and
defenses for anonymous communication systems. This page summarizes the
resources we provide to help make your Tor research more effective. You can
reach us about research by picking one of the channels listed
<a href="https://www.torproject.org/about/contact.html">here</a>.</p>
</div>
<div class="container content">
<ul>
<li><strong>Data</strong>. We've been <a href="https://metrics.torproject.org/">collecting data to learn more about the Tor
network</a>: how
many relays and clients there are in the network, what capabilities they
have, how fast the network is, how many clients are connecting via bridges,
what traffic exits the network, etc. We are also developing tools to process
these huge data archives and come up with useful statistics. Let us know what
other information you'd like to see, and we can work with you to help make
sure it gets collected
<a href="https://www.freehaven.net/anonbib/#wecsr10measuring-tor">safely</a> and
robustly.</li>
<li><strong>Analysis</strong>. If you're investigating Tor, or solving a Tor-related problem,
<em>please</em> talk to us somewhere along the way — the earlier the better. These
days we review too many conference paper submissions that make bad
assumptions and end up solving the wrong problem. Since the Tor protocol and
the Tor network are both moving targets, measuring things without
understanding what's going on behind the scenes is going to result in bad
conclusions. In particular, different groups often unwittingly run a variety
of experiments in parallel, and at the same time we're constantly modifying
the design to try new approaches. If you let us know what you're doing and
what you're trying to learn, we can help you understand what other variables
to expect and how to interpret your results.</li>
<li><strong>Measurement and attack tools</strong>. We're building a repository of tools that
can be used to measure, analyze, or perform attacks on Tor. Many research
groups end up needing to do similar measurements (for example, change the Tor
design in some way and then see if latency improves), and we hope to help
everybody standardize on a few tools and then make them really good. Also,
while there are some really neat Tor attacks that people have published
about, it's hard to track down a copy of the code they used. Let us know if
you have new tools we should list, or improvements to the existing ones. The
more the better, at this stage.</li>
<li><strong>We need defenses too — not just attacks</strong>. Most researchers find it easy
and fun to come up with novel attacks on anonymity systems. We've seen this
result lately in terms of improved congestion attacks, attacks based on
remotely measuring latency or throughput, and so on. Knowing how things can
go wrong is important, and we recognize that the incentives in academia
aren't aligned with spending energy on designing defenses, but it sure would
be great to get more attention to how to address the attacks. We'd love to
help brainstorm about how to make Tor better. As a bonus, your paper might
even end up with a stronger "countermeasures" section.</li>
<li><strong>In-person help</strong>. If you're doing interesting and important Tor research
and need help understanding how the Tor network or design works, interpreting
your data, crafting your experiments, etc, we can send a Tor researcher to
your doorstep. As you might expect, we don't have a lot of free time; but
making sure that research is done in a way that's useful to us is really
important. So let us know, and we'll work something out.</li>
</ul>
<p>If you're interested in anonymity research, you must make it to the <a href="https://petsymposium.org/">Privacy
Enhancing Technologies Symposium</a>. Everybody who's
anybody in the anonymity research world will be there. Stipends are generally
available for people whose presence will benefit the community.</p>
<p>To get up to speed on anonymity research, read <a href="https://www.freehaven.net/anonbib/">these
papers</a> (especially the ones in boxes). We
also keep a list of <a href="/techreports/">Tor Tech Reports</a> that are (co-)authored by
Tor developers.</p>
</div>
content/groups.md 0 → 100644
View file @ 5afd7344
---
title: Research Groups
aliases:
- "/groups.html"
---
Interested to find other anonymity researchers? Here are some researchers and
research groups you should take a look at.
* [Traffic Security Group of the Formal Methods Section, U.S. Naval Research Laboratory](#nrl)
* [Information Security Research Group, University College London](#ucl)
* [Nick Hopper, University of Minnesota](#hopper)
* [Cryptography, Security, and Privacy (CrySP) Research Group, University of Waterloo](#crysp)
* [Other groups](#other)
* [Add your group](#add)
<div class="card p-5 mb-3">
<h3 id="nrl" class="card-title"><a href="https://www.nrl.navy.mil/itd/chacs/5543">Traffic Security Group of the Formal Methods Section</a>, <a href="https://www.nrl.navy.mil/">U.S. Naval Research Laboratory</a></h3>
<dl>
<dt>Location</dt><dd>Washington, DC, USA</dd>
<dt>Key People</dt><dd><a href="https://www.robgjansen.com/">Rob Jansen</a>, <a href="https://ohmygodel.com/">Aaron Johnson</a> , <a href="http://www.syverson.org/">Paul Syverson</a>, <a href="https://matt.traudt.xyz/">Matt Traudt</a>, <a href="https://ryanwails.com/">Ryan Wails</a></dd>
</dl>
<p>Onion routing and Tor were invented at NRL, and researchers in the Formal
Methods Section continue to investigate ways to improve communications privacy
in general and Tor in particular. Topics of recent activity include improving
Tor’s performance (e.g. congestion handling and bandwidth measurement),
improved Tor’s security (e.g. improved guard-selection algorithms), improved
onion services (e.g. single onion services and onion-service naming), and
better Tor measurements (e.g. PrivCount and onion-service statistics). In
addition, the Shadow network simulator is developed and maintained by the
group.</p>
<h4>Additional links</h4>
<p><a class="btn btn-outline-primary mr-2" href="https://www.nrl.navy.mil/itd/chacs/publications">Publications</a></p>
</div>
<div class="card p-5 mb-3">
<h3 id="ucl" class="card-title"><a href="http://sec.cs.ucl.ac.uk/home/">Information Security Research Group</a>, <a href="http://www.cs.ucl.ac.uk/home/">University College London</a></h3>
<dl>
<dt>Location</dt><dd>London, United Kingdom</dd>
<dt>Key People</dt><dd>Emiliano De Cristofaro,
<a href="http://sec.cs.ucl.ac.uk/users/smurdoch/">Steven Murdoch</a>,
<a href="http://www0.cs.ucl.ac.uk/staff/G.Danezis/">George Danezis</a></dd>
</dl>
<p>The group comprised expertise across all filed of security, cryptography and
privacy, including the study of anonymous communications, traffic analysis,
censorship resistance, measurement studies, and privacy related cryptography.
In related areas the group studies human factors and usability of privacy systems,
genetic privacy, infrastructure privacy and abuse in online communities and
media.</p>
<h4>Additional links</h4>
<p><a class="btn btn-outline-primary mr-2" href="http://sec.cs.ucl.ac.uk/publications/">Publications</a></p>
</div>
<div class="card p-5 mb-3">
<h3 id="hopper" class="card-title"><a href="https://www-users.cs.umn.edu/~hoppernj/research.html">Nick Hopper</a>, <a href="https://www.umn.edu/">University of Minnesota</a></h3>
<dl>
<dt>Location</dt><dd>Minneapolis, MN, USA</dd>
<dt>Key People</dt><dd>Nick Hopper, <a href="https://www-users.cs.umn.edu/~hoppernj/advising.html">Current Students</a></dd>
<p>The group has worked on several projects seeking methods to improve
Tor's performance and to understand the degradation of anonymity
resulting from these methods. This includes understanding attacks on
and improvements to many mechanisms used by Tor to improve
performance, including load balancing, admission control, congestion
control, hidden services, circuit selection, and circuit scheduling.
We have also worked on accurately measuring and modeling the Tor
network. Our group developed shadow, a network emulator that allows
accurate large-scale simulations of Tor's performance and security,
and developed algorithms for producing accurate reduced-scale models
of the network. We have recently worked to develop methods for
privately measuring improved models of Tor network traffic. Finally,
the group has recently worked on understanding the limitations of website
fingerprinting attacks and possible mitigation strategies.</p>
<h4>Additional links</h4>
<p><a class="btn btn-outline-primary mr-2" href="https://www-users.cs.umn.edu/~hoppernj/publications.html">Publications</a></p>
</div>
<div class="card p-5 mb-3">
<h3 id="crysp" class="card-title"><a href="https://crysp.uwaterloo.ca/">Cryptography, Security, and Privacy (CrySP) Research Group</a>, <a href="https://uwaterloo.ca/">University of Waterloo</a></h3>
<dl>
<dt>Location</dt><dd>Waterloo, Ontario, Canada</dd>
<dt>Key People</dt><dd><a href="https://cs.uwaterloo.ca/~iang/">Ian Goldberg</a>, <a href="https://crysp.uwaterloo.ca/people/">All members</a></dd>
</dl>
<p>The CrySP research group at the University of Waterloo has been
researching privacy-preserving communications networks for over a
decade. They work on improving the security, privacy, and performance of
such networks, and a number of their results have been incorporated into
the Tor network. They also work on improved testbeds for Tor
experimentation, including Shadow and NetMirage. The group maintains
the CrySP RIPPLE Facility, a large experimentation testbed for privacy
enhancing technologies like Tor; the largest single machine in the
facility has 144 CPU cores and 12 TB of RAM.</p>
<h4>Additional links</h4>
<p><a class="btn btn-outline-primary mr-2" href="https://crysp.uwaterloo.ca/publications/">Publications</a></p>
</div>
<a id="other"></a>
## Other groups
* [Nikita Borisov](http://www.hatswitch.org/~nikita/)'s group at Illinois.
* Micah Sherr's [SecLab](https://security.cs.georgetown.edu/) group at
Georgetown.
* Matt Wright's [iSec](http://isec.uta.edu/) group at UTA.
<a id="add"></a>
## Add your group
If your research group, in industry or academia, is involved in research on Tor
then please send a mail to
[research@torproject.org](mailto:research@torproject.org) with the details you
would like to have added.
content/ideas.md 0 → 100644
View file @ 5afd7344
---
title: Research Ideas
aliases:
- "/ideas.html"
---
<!-- TODO: Link to impactful research -->
We need people to attack the system, quantify defenses, etc. Here are some
example projects:
* What algorithm should we use to assign Guard flags such that a) we assign
the flag to as many relays as possible, yet b) we minimize the chance that
Alice will use an attacker's node as a guard? See the [blog
post](https://blog.torproject.org/research-problem-better-guard-rotation-parameters)
for details.
* For various diversity metrics, how has the diversity of the Tor network
changed over time? How robust is it to change or attack? These results can
help us make better design decisions. See the [blog
post](https://blog.torproject.org/research-problem-measuring-safety-tor-network)
for details.
* If we prevent the really loud users from using too much of the Tor network,
how much can it help? We've instrumented Tor's entry relays so they can
rate-limit connections from users, and we've instrumented the directory
authorities so they can change the rate-limiting parameters globally across
the network. Which parameter values improve performance for the Tor network
as a whole? How should relays adapt their rate-limiting parameters based on
their capacity and based on the network load they see, and what
rate-limiting algorithms will work best? See the [blog
post](https://blog.torproject.org/research-problem-adaptive-throttling-tor-clients-entry-guards)
for details.
* Right now Tor clients are willing to reuse a given circuit for ten minutes
after it's first used. The goal is to avoid loading down the network with
too many circuit creations, yet to also avoid having clients use the same
circuit for so long that the exit node can build a useful pseudonymous
profile of them. Alas, ten minutes is probably way too long, especially if
connections from multiple protocols (e.g. IM and web browsing) are put on
the same circuit. If we keep fixed the overall number of circuit extends
that the network needs to do, are there more efficient and/or safer ways
for clients to allocate streams to circuits, or for clients to build
preemptive circuits? Perhaps this research item needs to start with
gathering some traces of what requests typical clients try to launch, so
you have something realistic to try to optimize.
* The "website fingerprinting attack": make a list of a few hundred popular
websites, download their pages, and make a set of "signatures" for each
site. Then observe a Tor client's traffic. As you watch him receive data,
you quickly approach a guess about which (if any) of those sites he is
visiting. First, how effective is this attack on the deployed Tor design?
The problem with all the previous attack papers is that they look at timing
and counting of IP packets on the wire. But OpenSSL's TLS records, plus
Tor's use of TCP pushback to do rate limiting, means that tracing by IP
packets produces very poor results. The right approach is to realize that
Tor uses OpenSSL, look inside the TLS record at the TLS headers, and figure
out how many 512-byte cells are being sent or received. Then start
exploring defenses: for example, we could change Tor's cell size from 512
bytes to 1024 bytes, we could employ padding techniques like [defensive
dropping](http://freehaven.net/anonbib/#timing-fc2004), or we could add
traffic delays. How much of an impact do these have, and how much usability
impact (using some suitable metric) is there from a successful defense in
each case?
* More coming soon. See also the "Research" section of the
[volunteer](https://www.torproject.org/getinvolved/volunteer.html.en#Research)
page for other topics.
content/mailinglist.md 0 → 100644
View file @ 5afd7344
---
title: Mailing Lists
---
Tor Project maintains a number of mailing lists for discussion about
Tor-related topics. These mailing lists may be of particular interest to
researchers:
## tor-dev
* Post address: [tor-dev@lists.torproject.org](mailto:tor-dev@lists.torproject.org)
* Subscribe: https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
* Archives: http://lists.torproject.org/pipermail/tor-dev/
This is a public mailing list for discussion about the development of Tor.
Examples of on-topic discussions would include (where there is a clear relation
to Tor): Path selection algorithms, Post-quantum cryptography, Privacy
preserving telemetry, Congestion control, Attacks and Mitigations.
## tor-researchers
* Post address: [tor-researchers@lists.torproject.org](mailto:tor-researchers@lists.torproject.org)
* Subscribe: https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-researchers
* Archives (Private): http://lists.torproject.org/pipermail/tor-researchers/
This is a private list to facilitate research related to Tor: It's a place to
discuss with other like-minded reseachers, get in touch with core members of
the Tor team, and build collaboration for research projects. It's also a new
list and an experiment that we are not sure which direction it will go, let's
all shape it together.
We understand the value of early feedback in a private setting, that academia
can be a competitive environment and also that research may be subject to
embargoes while work is under submission for publication. However, please note
that Tor Project strives to be as transparent as possible, and we encorage you
to move discussion to the public tor-dev mailing list once it is ready for
public review/commentary.
<!-- To join this list please XXXX TODO. -->
<!-- ## pet
TODO: https://lists.links.org/mailman/listinfo/pet -->
## tor-relays-universities
* Post address: [tor-relays-universities@lists.torproject.org](mailto:tor-relays-universities@lists.torproject.org)
* Subscribe: https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays-universities
* Archives: http://lists.torproject.org/pipermail/tor-relays-universities/
Many computer science departments, university libraries, and individual
students and faculty run relays from university networks. These universities
include the Massachusetts Institute of Technology (MIT CSAIL), Boston
University, the University of Waterloo, the University of Washington,
Northeastern University, Karlstad University, Universitaet Stuttgart, and
Friedrich-Alexander University Erlangen-Nuremberg. To learn more about how to
get support for a relay on your university's network, check out [EFF's
resources](https://www.eff.org/torchallenge/tor-on-campus.html).
This is a public lists with archives to build a community of Tor relay ops at
universities, colleges, and other education institutions that can help each
other to solve issues and help prospective ops at other institutions to get
started.
content/safetyboard.md 0 → 100644
View file @ 5afd7344
---
title: Research Safety Board
aliases:
- "/safetyboard.html"
---
* [What is the Tor Research Safety Board?](#what)
* [What are the safety guidelines?](#guidelines)
* [How can I submit a request for advice?](#how)
* [What are some examples of research that is in-scope?](#examples)
* [Who is on the Board?](#who)
* [FAQ](#faq)
<a id="what"></a>
### [What is the Tor Research Safety Board?](#what)
We are a group of researchers who study Tor, and who want to **minimize privacy risks while fostering a better understanding of the Tor network and its users**. We aim to accomplish this goal in three ways:
1. developing and maintaining a set of guidelines that researchers can use to
assess the safety of their Tor research.
2. giving feedback to researchers who use our guidelines to assess the safety
of their planned research.
3. teaching program committees about our guidelines, and encouraging reviewers
to consider research safety when reviewing Tor papers.
<a id="guidelines"></a>
### [What are the safety guidelines?](#guidelines)
Here's a start:
1. Use a test Tor network whenever possible.
2. It's safest to only attack yourself / your own traffic.
3. Only collect data that is safe to make public.
4. Don't collect data you don't need (minimization).
5. Take reasonable security precautions, e.g. about who has access to your
data sets or experimental systems.
6. Limit the granularity of data (e.g. use bins or add noise).
7. The benefits should outweigh the risks.
8. Consider auxiliary data (e.g. third-party data sets) when assessing the risks.
9. Consider whether the user meant for that data to be private.
There's plenty of room for further improvement here. In fact, we think this
list itself is a really interesting research area. One of our next steps is to
flesh out each of these points with a few paragraphs of explanation. Please
help!
<a id="how"></a>
### [How can I submit a request for advice?](#how)
The vision is that you (the researchers) think through the safety of your
planned activity, write up an assessment based on our guidelines, and send it
to us. Then we look it over and advise you about how to make your plan safer,
how to make your arguments crisper, or what parts really seem too dangerous to
do. Later (e.g. when your paper gets published) we'll encourage you to make
your assessment public. Over time we'll grow a library of success cases, which
will provide best practices guidance for being safe, and also provide templates
for writing good assessments.
We hope that going through this process will help you think clearly about the
benefits and risks of your experiment. Hopefully our feedback on your thoughts
will help too. At the same time, this process will help Tor by letting us know
what research is happening — which in turn can help you, since we might be able
to let you know about a concurrent experiment (with their permission of course)
that will mess up your results. Also, we can let you know about upcoming Tor
design changes that might influence your plans or analysis.
To best help you, we want to hear about four aspects of your proposed
experiment or research plan:
1. What are you trying to learn, and why is that useful for the world? That
is, what are the hoped-for benefits of your experiment?
2. What exactly is your plan? That is, what are the steps of your experiment,
what will you collect, how will you keep it safe, and so on.
3. What attacks or risks might be introduced or assisted because of your
actions or your data sets, and how well do you resolve each of them? Use
the "safety guidelines" above to help in the brainstorming and analysis.
4. Walk us through why the benefits from item 1 outweigh the remaining risks
from item 3: why is this plan worthwhile despite the remaining risks?
We encourage you to include your assessment as a section of your research
paper: one of the goals here is that reviewers on program committees come to
expect a section in Tor papers that explains what mechanisms the researchers
used for ensuring that privacy risks were handled, and argues that the balance
between new understanding and risk is worthwhile. For space reasons, you might
include a streamlined version in the main body of the paper and a more detailed
version in an appendix.
In the future, we'd like to come up with a more thorough template for
self-assessments, to help you make sure you don't miss any critical areas.
Please let us know what would help you most. In the mean time, be sure to check
out the past examples below.
Please submit your written assessment to us at
[https://safetyboard.torproject.net/submit/](https://safetyboard.torproject.net/submit/).
The review process is not anonymous, and reviewers may contact authors for
clarifications.
<a id="examples"></a>
### [What are some examples of research that is in-scope?](#examples)
We are publishing safety board cases in this section, to help you craft your own submission. Note that some cases are still private, for example because the researchers are waiting for their paper to become public first.
2016-01: Studying reachability of Tor Browser's default bridges
* [request](/trsb/2016-01-request.txt)
* [questionnaire](/trsb/2016-01-questionnaire.txt)
* [questionnaire answers](/trsb/2016-01-questionnaire-answers.txt)
* [response](/trsb/2016-01-response.txt)
2016-02: [still anonymized during paper review]
2016-03: Understanding "dark web" cultures and communities
* [request](/trsb/2016-03-request.txt)
* [response](/trsb/2016-03-response.txt)
2017-01: [still anonymized during paper review]
2017-02: Running HSDir relays to measure longevity of onion services
* [request](/trsb/2017-02-request.txt)
* [request pdf](/trsb/2017-02-request.pdf)
* [response](/trsb/2017-02-response.txt)
* [research project page](http://tor.ccs.neu.edu/)
2017-03: Running middle relays to measure onion service popularity
* [request](/trsb/2017-03-request.txt)
* [response](/trsb/2017-03-response.txt)
* [research project page](https://onionpop.github.io/)
* [Accepted paper forthcoming at NDSS 2018]
2017-04: [under review]
2017-05: [under review]
2017-06: [under review]
<a id="who"></a>
### [Who is on the Board?](#who)
The current members of the board are:
* George Danezis
* Roger Dingledine
* Tariq Elahi
* Ian Goldberg
* Rob Jansen
* Aaron Johnson
* Damon McCoy
* Wendy Seltzer
* Micah Sherr
* Paul Syverson
<a id="faq"></a>
### [FAQ](#faq)
**Why now?** The importance of Tor is growing in the world, and interest from
researchers remains high as ever. Each week we run across a new paper that
maybe didn't think things through in terms of keeping their users safe. We've
seen lately that simply having a sensitive data set, even if you plan to never
give it out, can put users at real risk. At the same time, we've seen exciting
papers like PrivEx, which show that studying how to do research safely can be a
research field in itself. Now is the perfect time for us to work to shape
future research so we build habits of safety in our community, and so we help
people to understand what is possible.
**What about bad people who don't care about being safe?** A safety board
cannot by itself stop all dangerous Tor research. Plenty of people out there
don't play the academic game, and some people don't care about user safety at
all. Our goal here is to support the people who want to cooperate, while
showing to the world that it's possible to do good Tor research safely.
**Can't I just run Tor relays and do my experiment without telling you?**
Please don't! The directory authority operators have been much more
conservative lately (after the CMU incident in particular) in terms of looking
for suspicious patterns or behavior, and removing suspicious relays from the
network. If the directory authority operators know about you, understand your
research, and can read about why the benefits are worth the risks in your case,
they will likely leave your relays in place, rather than surprising you by
kicking your relays out of the network mid experiment.
**Can I do this assessment and review process even if I'm not writing an
academic paper?** Please do! Our goal as stated above is "to minimize privacy
risks while fostering a better understanding of the Tor network and its users".
If your end goal is something other than a research paper, that's great too.
**Is this an ethics board?** We framed this idea as a safety board, not an
ethics board. We think safety is a narrower scope: we aim to describe _how_ to
be safe, and we aim to make it the norm that reviewers and program committees
expect to see an analysis of why an experiment or measurement is safe. We also
are not adding new bottlenecks to the research process, such as mandating that
we have to vet the analysis first — that's ultimately between the researchers
and the program committees. We aren't trying to replace