[tor-commits] [research-web/master] Initial commit of Hugo port
irl at torproject.org
irl at torproject.org
Thu May 2 18:09:13 UTC 2019
commit 5afd73442cbf04bd8f3c6620db484e1994a75330
Author: Iain R. Learmonth <irl at fsfe.org>
Date: Fri Feb 22 23:51:57 2019 +0000
Initial commit of Hugo port
---
.gitignore | 12 +
.gitmodules | 3 +
Makefile | 15 +
README.md | 44 ++
archetypes/default.md | 6 +
config.toml | 40 ++
content/_index.html | 66 +++
content/groups.md | 112 ++++
content/ideas.md | 63 +++
content/mailinglist.md | 63 +++
content/safetyboard.md | 243 +++++++++
content/techreports.html | 509 ++++++++++++++++++
generate-techreports-html | 5 +
...ottling-tor-clients-entry-guards-2010-09-19.pdf | Bin 0 -> 156008 bytes
...better-guard-rotation-parameters-2011-08-20.pdf | Bin 0 -> 56652 bytes
static/techreports/blocking-2006-11.pdf | Bin 0 -> 149691 bytes
static/techreports/blocking-2011-09-15.pdf | Bin 0 -> 153328 bytes
static/techreports/botnet-tr-2013-11-20.pdf | Bin 0 -> 314361 bytes
.../bridge-report-usage-stats-2012-04-30.pdf | Bin 0 -> 318705 bytes
static/techreports/bridge-scaling-2012-03-09.pdf | Bin 0 -> 50333 bytes
static/techreports/bridge-stability-2011-10-31.pdf | Bin 0 -> 141760 bytes
static/techreports/bridges-2009-06-22.pdf | Bin 0 -> 53558 bytes
static/techreports/bufferstats-2009-08-25.pdf | Bin 0 -> 194376 bytes
.../censorship-analysis-tool-2013-02-06.pdf | Bin 0 -> 70127 bytes
static/techreports/challenges-2005-02.pdf | Bin 0 -> 265430 bytes
static/techreports/circwindow-2009-09-20.pdf | Bin 0 -> 135038 bytes
.../counting-daily-bridge-users-2012-10-24.pdf | Bin 0 -> 193760 bytes
static/techreports/countingusers-2010-11-30.pdf | Bin 0 -> 229230 bytes
static/techreports/data-2011-03-14.pdf | Bin 0 -> 100202 bytes
.../techreports/datagram-comparison-2011-11-07.pdf | Bin 0 -> 191424 bytes
.../datagram-testing-plan-2012-03-16.pdf | Bin 0 -> 61928 bytes
static/techreports/detector-2011-09-09.pdf | Bin 0 -> 56185 bytes
.../different-ways-use-bridge-2011-11-29.pdf | Bin 0 -> 58684 bytes
static/techreports/dirarch-2009-06-22.pdf | Bin 0 -> 572226 bytes
.../techreports/directory-requests-2009-06-25.pdf | Bin 0 -> 145115 bytes
.../dos-censorship-report1-2018-11-19.pdf | Bin 0 -> 1373245 bytes
static/techreports/dos-taxonomy-2015-10-29.pdf | Bin 0 -> 67428 bytes
.../extrapolating-hidserv-stats-2015-01-31.pdf | Bin 0 -> 327762 bytes
...ve-ways-test-bridge-reachability-2011-12-01.pdf | Bin 0 -> 72567 bytes
static/techreports/flagrequirements-2009-04-11.pdf | Bin 0 -> 213263 bytes
static/techreports/geoipdbcomp-2009-10-23.pdf | Bin 0 -> 520677 bytes
.../hidden-service-stats-2015-04-28.pdf | Bin 0 -> 135310 bytes
static/techreports/libutp-2013-10-30.pdf | Bin 0 -> 96357 bytes
.../measuring-safety-tor-network-2011-02-06.pdf | Bin 0 -> 73875 bytes
static/techreports/metrics-2009-08-07.pdf | Bin 0 -> 562366 bytes
static/techreports/modern-collector-2018-12-19.pdf | Bin 0 -> 340684 bytes
static/techreports/morpher-2012-03-13.pdf | Bin 0 -> 146481 bytes
.../overhead-directory-info-2009-02-16.pdf | Bin 0 -> 57701 bytes
static/techreports/performance-2009-11-09.pdf | Bin 0 -> 229560 bytes
.../techreports/pluggable-roadmap-2012-03-17.pdf | Bin 0 -> 55935 bytes
.../techreports/privacy-in-memory-2017-04-28.pdf | Bin 0 -> 317875 bytes
static/techreports/relay-stability-2011-06-30.pdf | Bin 0 -> 367947 bytes
...es-getting-more-bridge-addresses-2011-05-13.pdf | Bin 0 -> 49976 bytes
.../tbb-forensic-analysis-2013-06-28.pdf | Bin 0 -> 98145 bytes
.../ten-ways-discover-tor-bridges-2011-10-31.pdf | Bin 0 -> 87207 bytes
static/techreports/tor-growth-2014-10-04.pdf | Bin 0 -> 839456 bytes
static/techreports/tor-nat-plan-2012-08-22.pdf | Bin 0 -> 69673 bytes
static/techreports/torflow-2009-08-07.pdf | Bin 0 -> 386046 bytes
static/techreports/torperf-2009-09-22.pdf | Bin 0 -> 344759 bytes
static/techreports/torperf2-2013-10-30.pdf | Bin 0 -> 88301 bytes
.../virtual-private-services-2008-07-25.pdf | Bin 0 -> 124717 bytes
static/techreports_bib.html | 579 +++++++++++++++++++++
static/trsb/2016-01-questionnaire-answers.txt | 113 ++++
static/trsb/2016-01-questionnaire.txt | 115 ++++
static/trsb/2016-01-request.txt | 193 +++++++
static/trsb/2016-01-response.txt | 42 ++
static/trsb/2016-03-request.txt | 67 +++
static/trsb/2016-03-response.txt | 201 +++++++
static/trsb/2017-02-request.pdf | Bin 0 -> 46014 bytes
static/trsb/2017-02-request.txt | 15 +
static/trsb/2017-02-response.txt | 192 +++++++
static/trsb/2017-03-request.txt | 124 +++++
static/trsb/2017-03-response.txt | 118 +++++
techreports-footer.html | 1 +
techreports-header.html | 6 +
techreports.bib | 481 +++++++++++++++++
techreports.html | 502 ++++++++++++++++++
themes/torproject | 1 +
78 files changed, 3931 insertions(+)
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..958340e
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,12 @@
+# Hugo default output directory
+/public
+
+## OS Files
+# Windows
+Thumbs.db
+ehthumbs.db
+Desktop.ini
+$RECYCLE.BIN/
+
+# OSX
+.DS_Store
diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000..edde79b
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "themes/torproject"]
+ path = themes/torproject
+ url = https://github.com/irl/torproject-hugo.git
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..77d3f0a
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,15 @@
+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
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..89e1ddf
--- /dev/null
+++ b/README.md
@@ -0,0 +1,44 @@
+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.
diff --git a/archetypes/default.md b/archetypes/default.md
new file mode 100644
index 0000000..00e77bd
--- /dev/null
+++ b/archetypes/default.md
@@ -0,0 +1,6 @@
+---
+title: "{{ replace .Name "-" " " | title }}"
+date: {{ .Date }}
+draft: true
+---
+
diff --git a/config.toml b/config.toml
new file mode 100644
index 0000000..eca81cf
--- /dev/null
+++ b/config.toml
@@ -0,0 +1,40 @@
+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
diff --git a/content/_index.html b/content/_index.html
new file mode 100644
index 0000000..fcde235
--- /dev/null
+++ b/content/_index.html
@@ -0,0 +1,66 @@
+<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>
diff --git a/content/groups.md b/content/groups.md
new file mode 100644
index 0000000..6746c08
--- /dev/null
+++ b/content/groups.md
@@ -0,0 +1,112 @@
+---
+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 at torproject.org](mailto:research at torproject.org) with the details you
+would like to have added.
diff --git a/content/ideas.md b/content/ideas.md
new file mode 100644
index 0000000..d411d4f
--- /dev/null
+++ b/content/ideas.md
@@ -0,0 +1,63 @@
+---
+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.
diff --git a/content/mailinglist.md b/content/mailinglist.md
new file mode 100644
index 0000000..f255dd9
--- /dev/null
+++ b/content/mailinglist.md
@@ -0,0 +1,63 @@
+---
+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 at lists.torproject.org](mailto:tor-dev at 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 at lists.torproject.org](mailto:tor-researchers at 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 at lists.torproject.org](mailto:tor-relays-universities at 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.
diff --git a/content/safetyboard.md b/content/safetyboard.md
new file mode 100644
index 0000000..a5f1806
--- /dev/null
+++ b/content/safetyboard.md
@@ -0,0 +1,243 @@
+---
+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 IRBs or other projects
+like ethicalresearch.org.
+
+**So I still need to go to my IRB?** This safety board is orthogonal to the IRB
+concept. We hope that the evaluation process here will help you organize your
+thoughts for your IRB, but it does not replace your IRB process (if you have
+one).
+
+**What about confidentiality?** Unless you tell us otherwise, we will keep
+assessments that we receive confidential in the same way that program
+committees do. You're coming to us much earlier in the process (ideally before
+the research is performed and before the paper is written), which we recognize
+requires more trust. We hope we add enough value to your research that you find
+this tradeoff worthwhile.
+
+**How will you know the right balance between benefits and risks?** This is a
+tough one. We want Tor to get stronger long-term, but we don't want to put
+people into danger to do it. One answer is that most of this board is made up
+of professors and other online safety, security, and privacy researchers, who
+can provide a more neutral perspective on the right balance. The other answer
+is that this process is a feedback loop and we can adapt as we go: once
+successful assessments have gone up on this page, and people are including
+assessments in their papers, everybody else can look at them and decide if they
+used the right balance.
+
+**So you want conferences to adopt your guidelines?** Not quite. We would be
+sad if program chairs told their reviewers "Make sure the paper follows Tor's
+guidelines for safe research." We would instead like the chairs to tell the
+reviewers "Make sure the paper has performed safe research. If you're unsure
+what that means, I encourage you to read Tor's guidelines to get ideas on what
+to consider." That is, we want the reviewers to always be thinking through, for
+each paper, whether this is a safe or unsafe situation. Reviewers should
+enforce the ethical requirements of the conference they're reviewing for — or
+their own ethical principles, if the conference neglected to have an opinion on
+the topic. Our goal here is to help them think through what to look for.
+
+**Is Tor going to do this assessment process for its own design decisions and
+statistics collection?** Absolutely! You'll notice a big improvement over the
+years between [our early statistics collection
+choices](https://trac.torproject.org/13988) and [our later
+ones](https://blog.torproject.org/blog/some-statistics-about-onions). That
+learning process is part of what led to this safety board. We'd like to revisit
+many of Tor's design choices, especially once we've worked through some other
+examples here. We'd love to have your help there.
diff --git a/content/techreports.html b/content/techreports.html
new file mode 100644
index 0000000..c1e210c
--- /dev/null
+++ b/content/techreports.html
@@ -0,0 +1,509 @@
+---
+title: "Technical Reports"
+aliases:
+ - "/techreports.html"
+---
+
+
+<!-- This document was automatically generated with bibtex2html 1.99
+ (see http://www.lri.fr/~filliatr/bibtex2html/),
+ with the following command:
+ bibtex2html -d -r -nodoc -nokeys -q techreports.bib -->
+
+
+
+
+<p><a name="tor-2018-12-001"></a>
+
+Iain R. Learmonth and Karsten Loesing.
+ Towards modernising data collection and archive for the Tor
+ network.
+ Technical Report 2018-12-001, The Tor Project, December 2018.
+[ <a href="../techreports_bib.html#tor-2018-12-001">bib</a> |
+<a href="https://research.torproject.org/techreports/modern-collector-2018-12-19.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2018-11-001"></a>
+
+Antonela Debiasi, Roger Dingledine, Arthur Edelstein, Alexander Færøy,
+ Matthew Finkel, David Goulet, Kat Hanna, Maggie Haughey, George Kadianakis,
+ Iain R. Learmonth, Alison Macrina, and Maria Xynou.
+ Addressing denial of service attacks on free and open communication
+ on the internet.
+ Technical Report 2018-11-001, The Tor Project, November 2018.
+[ <a href="../techreports_bib.html#tor-2018-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/dos-censorship-report1-2018-11-19.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2017-04-001"></a>
+
+Karin Herm.
+ Privacy analysis of Tor's in-memory statistics.
+ Technical Report 2017-04-001, The Tor Project, April 2017.
+[ <a href="../techreports_bib.html#tor-2017-04-001">bib</a> |
+<a href="https://research.torproject.org/techreports/privacy-in-memory-2017-04-28.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2015-10-001"></a>
+
+Nick Mathewson.
+ Denial-of-service attacks in Tor: Taxonomy and defenses.
+ Technical Report 2015-10-001, The Tor Project, October 2015.
+[ <a href="../techreports_bib.html#tor-2015-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/dos-taxonomy-2015-10-29.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2015-04-001"></a>
+
+David Goulet, Aaron Johnson, George Kadianakis, and Karsten Loesing.
+ Hidden-service statistics reported by relays.
+ Technical Report 2015-04-001, The Tor Project, April 2015.
+[ <a href="../techreports_bib.html#tor-2015-04-001">bib</a> |
+<a href="https://research.torproject.org/techreports/hidden-service-stats-2015-04-28.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2015-01-001"></a>
+
+George Kadianakis and Karsten Loesing.
+ Extrapolating network totals from hidden-service statistics.
+ Technical Report 2015-01-001, The Tor Project, January 2015.
+[ <a href="../techreports_bib.html#tor-2015-01-001">bib</a> |
+<a href="https://research.torproject.org/techreports/extrapolating-hidserv-stats-2015-01-31.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2014-10-001"></a>
+
+Virgil Griffith.
+ Tor growth rates and improving Torperf throughput.
+ Technical Report 2014-10-001, The Tor Project, October 2014.
+[ <a href="../techreports_bib.html#tor-2014-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/tor-growth-2014-10-04.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2013-11-001"></a>
+
+Nicholas Hopper.
+ Protecting Tor from botnet abuse in the long term.
+ Technical Report 2013-11-001, The Tor Project, November 2013.
+[ <a href="../techreports_bib.html#tor-2013-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/botnet-tr-2013-11-20.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2013-10-001"></a>
+
+Karsten Loesing, Steven J. Murdoch, and Rob Jansen.
+ Evaluation of a libutp-based Tor datagram implementation.
+ Technical Report 2013-10-001, The Tor Project, October 2013.
+[ <a href="../techreports_bib.html#tor-2013-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/libutp-2013-10-30.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2013-10-002"></a>
+
+Karsten Loesing, Sathyanarayanan Gunasekaran, and Kevin Butler.
+ Requirements and software design for a better Tor performance
+ measurement tool.
+ Technical Report 2013-10-002, The Tor Project, October 2013.
+[ <a href="../techreports_bib.html#tor-2013-10-002">bib</a> |
+<a href="https://research.torproject.org/techreports/torperf2-2013-10-30.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2013-06-001"></a>
+
+Runa A. Sandvik.
+ Forensic analysis of the Tor Browser Bundle on OS X, Linux, and
+ Windows.
+ Technical Report 2013-06-001, The Tor Project, June 2013.
+[ <a href="../techreports_bib.html#tor-2013-06-001">bib</a> |
+<a href="https://research.torproject.org/techreports/tbb-forensic-analysis-2013-06-28.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2013-02-001"></a>
+
+Philipp Winter.
+ Design requirements for a Tor censorship analysis tool.
+ Technical Report 2013-02-001, The Tor Project, February 2013.
+[ <a href="../techreports_bib.html#tor-2013-02-001">bib</a> |
+<a href="https://research.torproject.org/techreports/censorship-analysis-tool-2013-02-06.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-10-001"></a>
+
+Karsten Loesing.
+ Counting daily bridge users.
+ Technical Report 2012-10-001, The Tor Project, October 2012.
+[ <a href="../techreports_bib.html#tor-2012-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/counting-daily-bridge-users-2012-10-24.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-08-001"></a>
+
+Jacob Appelbaum.
+ Tor and NAT devices: increasing bridge & relay reachability or,
+ enabling the use of NAT-PMP and UPnP by default.
+ Technical Report 2012-08-001, The Tor Project, August 2012.
+[ <a href="../techreports_bib.html#tor-2012-08-001">bib</a> |
+<a href="https://research.torproject.org/techreports/tor-nat-plan-2012-08-22.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-04-001"></a>
+
+Karsten Loesing.
+ What fraction of our bridges are not reporting usage statistics?
+ Technical Report 2012-04-001, The Tor Project, April 2012.
+[ <a href="../techreports_bib.html#tor-2012-04-001">bib</a> |
+<a href="https://research.torproject.org/techreports/bridge-report-usage-stats-2012-04-30.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-03-001"></a>
+
+Karsten Loesing.
+ What if the Tor network had 50,000 bridges.
+ Technical Report 2012-03-001, The Tor Project, March 2012.
+[ <a href="../techreports_bib.html#tor-2012-03-001">bib</a> |
+<a href="https://research.torproject.org/techreports/bridge-scaling-2012-03-09.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-03-004"></a>
+
+George Kadianakis.
+ Packet size pluggable transport and traffic morphing.
+ Technical Report 2012-03-004, The Tor Project, March 2012.
+[ <a href="../techreports_bib.html#tor-2012-03-004">bib</a> |
+<a href="https://research.torproject.org/techreports/morpher-2012-03-13.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-03-002"></a>
+
+Steven J. Murdoch.
+ Datagram testing plan.
+ Technical Report 2012-03-002, The Tor Project, March 2012.
+[ <a href="../techreports_bib.html#tor-2012-03-002">bib</a> |
+<a href="https://research.torproject.org/techreports/datagram-testing-plan-2012-03-16.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-03-003"></a>
+
+Steven J. Murdoch and George Kadianakis.
+ Pluggable transports roadmap.
+ Technical Report 2012-03-003, The Tor Project, March 2012.
+[ <a href="../techreports_bib.html#tor-2012-03-003">bib</a> |
+<a href="https://research.torproject.org/techreports/pluggable-roadmap-2012-03-17.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-12-001"></a>
+
+Roger Dingledine.
+ Five ways to test bridge reachability.
+ Technical Report 2011-12-001, The Tor Project, December 2011.
+[ <a href="../techreports_bib.html#tor-2011-12-001">bib</a> |
+<a href="https://research.torproject.org/techreports/five-ways-test-bridge-reachability-2011-12-01.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-11-001"></a>
+
+Steven J. Murdoch.
+ Comparison of Tor datagram designs.
+ Technical Report 2011-11-001, The Tor Project, November 2011.
+[ <a href="../techreports_bib.html#tor-2011-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/datagram-comparison-2011-11-07.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-11-002"></a>
+
+Sebastian Hahn.
+ Different ways to use a bridge.
+ Technical Report 2011-11-002, The Tor Project, November 2011.
+[ <a href="../techreports_bib.html#tor-2011-11-002">bib</a> |
+<a href="https://research.torproject.org/techreports/different-ways-use-bridge-2011-11-29.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-10-001"></a>
+
+Karsten Loesing.
+ An analysis of Tor bridge stability---making BridgeDB give out at
+ least one stable bridge per user.
+ Technical Report 2011-10-001, The Tor Project, October 2011.
+[ <a href="../techreports_bib.html#tor-2011-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/bridge-stability-2011-10-31.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-10-002"></a>
+
+Roger Dingledine.
+ Ten ways to discover Tor bridges.
+ Technical Report 2011-10-002, The Tor Project, October 2011.
+[ <a href="../techreports_bib.html#tor-2011-10-002">bib</a> |
+<a href="https://research.torproject.org/techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-09-001"></a>
+
+George Danezis.
+ An anomaly-based censorship-detection system for Tor.
+ Technical Report 2011-09-001, The Tor Project, September 2011.
+[ <a href="../techreports_bib.html#tor-2011-09-001">bib</a> |
+<a href="https://research.torproject.org/techreports/detector-2011-09-09.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-09-002"></a>
+
+Karsten Loesing.
+ Case study: Learning whether a Tor bridge is blocked by looking at
+ its aggregate usage statistics, part one.
+ Technical Report 2011-09-002, The Tor Project, September 2011.
+[ <a href="../techreports_bib.html#tor-2011-09-002">bib</a> |
+<a href="https://research.torproject.org/techreports/blocking-2011-09-15.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-08-001"></a>
+
+Roger Dingledine.
+ Better guard rotation parameters.
+ Technical Report 2011-08-001, The Tor Project, August 2011.
+[ <a href="../techreports_bib.html#tor-2011-08-001">bib</a> |
+<a href="https://research.torproject.org/techreports/better-guard-rotation-parameters-2011-08-20.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-06-001"></a>
+
+Karsten Loesing.
+ An analysis of Tor relay stability.
+ Technical Report 2011-06-001, The Tor Project, June 2011.
+[ <a href="../techreports_bib.html#tor-2011-06-001">bib</a> |
+<a href="https://research.torproject.org/techreports/relay-stability-2011-06-30.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-05-001"></a>
+
+Roger Dingledine.
+ Strategies for getting more bridges.
+ Technical Report 2011-05-001, The Tor Project, May 2011.
+[ <a href="../techreports_bib.html#tor-2011-05-001">bib</a> |
+<a href="https://research.torproject.org/techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-03-001"></a>
+
+Karsten Loesing.
+ Overview of statistical data in the Tor network.
+ Technical Report 2011-03-001, The Tor Project, March 2011.
+[ <a href="../techreports_bib.html#tor-2011-03-001">bib</a> |
+<a href="https://research.torproject.org/techreports/data-2011-03-14.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-02-001"></a>
+
+Roger Dingledine.
+ Measuring the safety of the Tor network.
+ Technical Report 2011-02-001, The Tor Project, February 2011.
+[ <a href="../techreports_bib.html#tor-2011-02-001">bib</a> |
+<a href="https://research.torproject.org/techreports/measuring-safety-tor-network-2011-02-06.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2010-11-001"></a>
+
+Sebastian Hahn and Karsten Loesing.
+ Privacy-preserving ways to estimate the number of Tor users.
+ Technical Report 2010-11-001, The Tor Project, November 2010.
+[ <a href="../techreports_bib.html#tor-2010-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/countingusers-2010-11-30.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2010-09-001"></a>
+
+Roger Dingledine.
+ Adaptive throttling of Tor clients by entry guards.
+ Technical Report 2010-09-001, The Tor Project, September 2010.
+[ <a href="../techreports_bib.html#tor-2010-09-001">bib</a> |
+<a href="https://research.torproject.org/techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-11-001"></a>
+
+Roger Dingledine and Steven J. Murdoch.
+ Performance improvements on Tor or, why Tor is slow and what
+ we're going to do about it.
+ Technical Report 2009-11-001, The Tor Project, November 2009.
+[ <a href="../techreports_bib.html#tor-2009-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/performance-2009-11-09.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-10-001"></a>
+
+Karsten Loesing.
+ Comparison of GeoIP databases for Tor.
+ Technical Report 2009-10-001, The Tor Project, October 2009.
+[ <a href="../techreports_bib.html#tor-2009-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/geoipdbcomp-2009-10-23.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-09-002"></a>
+
+Karsten Loesing.
+ Reducing the circuit window size in Tor.
+ Technical Report 2009-09-002, The Tor Project, September 2009.
+[ <a href="../techreports_bib.html#tor-2009-09-002">bib</a> |
+<a href="https://research.torproject.org/techreports/circwindow-2009-09-20.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-09-001"></a>
+
+Karsten Loesing.
+ Performance of requests over the Tor network.
+ Technical Report 2009-09-001, The Tor Project, September 2009.
+[ <a href="../techreports_bib.html#tor-2009-09-001">bib</a> |
+<a href="https://research.torproject.org/techreports/torperf-2009-09-22.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-08-003"></a>
+
+Mike Perry.
+ TorFlow: Tor network analysis.
+ Technical Report 2009-08-003, The Tor Project, August 2009.
+[ <a href="../techreports_bib.html#tor-2009-08-003">bib</a> |
+<a href="https://research.torproject.org/techreports/torflow-2009-08-07.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-08-002"></a>
+
+Karsten Loesing.
+ Measuring the Tor network from public directory information.
+ Technical Report 2009-08-002, The Tor Project, August 2009.
+[ <a href="../techreports_bib.html#tor-2009-08-002">bib</a> |
+<a href="https://research.torproject.org/techreports/metrics-2009-08-07.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-08-001"></a>
+
+Karsten Loesing.
+ Analysis of circuit queues in Tor.
+ Technical Report 2009-08-001, The Tor Project, August 2009.
+[ <a href="../techreports_bib.html#tor-2009-08-001">bib</a> |
+<a href="https://research.torproject.org/techreports/bufferstats-2009-08-25.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-06-001"></a>
+
+Karsten Loesing.
+ Measuring the Tor network, evaluation of relays from public
+ directory data.
+ Technical Report 2009-06-001, The Tor Project, June 2009.
+[ <a href="../techreports_bib.html#tor-2009-06-001">bib</a> |
+<a href="https://research.torproject.org/techreports/dirarch-2009-06-22.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-06-003"></a>
+
+Karsten Loesing.
+ Analysis of bridge usage in Tor.
+ Technical Report 2009-06-003, The Tor Project, June 2009.
+[ <a href="../techreports_bib.html#tor-2009-06-003">bib</a> |
+<a href="https://research.torproject.org/techreports/bridges-2009-06-22.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-06-002"></a>
+
+Karsten Loesing.
+ Measuring the Tor network, evaluation of client requests to the
+ directories to determine total numbers and countries of users.
+ Technical Report 2009-06-002, The Tor Project, June 2009.
+[ <a href="../techreports_bib.html#tor-2009-06-002">bib</a> |
+<a href="https://research.torproject.org/techreports/directory-requests-2009-06-25.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-04-001"></a>
+
+Sebastian Hahn, Karsten Loesing, and Steven J. Murdoch.
+ Measuring the Tor network, simulation of the number of fast,
+ stable, and guard flags for changed requirements.
+ Technical Report 2009-04-001, The Tor Project, April 2009.
+[ <a href="../techreports_bib.html#tor-2009-04-001">bib</a> |
+<a href="https://research.torproject.org/techreports/flagrequirements-2009-04-11.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-02-001"></a>
+
+Roger Dingledine.
+ Overhead from directory info: past, present, future.
+ Technical Report 2009-02-001, The Tor Project, February 2009.
+[ <a href="../techreports_bib.html#tor-2009-02-001">bib</a> |
+<a href="https://research.torproject.org/techreports/overhead-directory-info-2009-02-16.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2008-07-001"></a>
+
+Karsten Loesing and Guido Wirtz.
+ Virtual private services.
+ Technical Report 2008-07-001, The Tor Project, July 2008.
+[ <a href="../techreports_bib.html#tor-2008-07-001">bib</a> |
+<a href="https://research.torproject.org/techreports/virtual-private-services-2008-07-25.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2006-11-001"></a>
+
+Roger Dingledine and Nick Mathewson.
+ Design of a blocking-resistant anonymity system.
+ Technical Report 2006-11-001, The Tor Project, November 2006.
+[ <a href="../techreports_bib.html#tor-2006-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/blocking-2006-11.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2005-02-001"></a>
+
+Roger Dingledine, Nick Mathewson, and Paul Syverson.
+ Challenges in deploying low-latency anonymity.
+ Technical Report 2005-02-001, The Tor Project, February 2005.
+[ <a href="../techreports_bib.html#tor-2005-02-001">bib</a> |
+<a href="https://research.torproject.org/techreports/challenges-2005-02.pdf">.pdf</a> ]
+
+</p><hr><p><em>This file was generated by
+<a href="http://www.lri.fr/~filliatr/bibtex2html/">bibtex2html</a> 1.99.</em></p>
+
diff --git a/generate-techreports-html b/generate-techreports-html
new file mode 100755
index 0000000..d3e3da6
--- /dev/null
+++ b/generate-techreports-html
@@ -0,0 +1,5 @@
+#!/bin/sh
+bibtex2html -d -r -nodoc -nokeys -q techreports.bib
+cat techreports-header.html techreports.html techreports-footer.html > content/techreports.html
+mv techreports_bib.html static/
+sed -i 's/techreports_bib/..\/techreports_bib/' content/techreports.html
diff --git a/static/techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf b/static/techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf
new file mode 100644
index 0000000..05c3eaf
Binary files /dev/null and b/static/techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf differ
diff --git a/static/techreports/better-guard-rotation-parameters-2011-08-20.pdf b/static/techreports/better-guard-rotation-parameters-2011-08-20.pdf
new file mode 100644
index 0000000..fcc561f
Binary files /dev/null and b/static/techreports/better-guard-rotation-parameters-2011-08-20.pdf differ
diff --git a/static/techreports/blocking-2006-11.pdf b/static/techreports/blocking-2006-11.pdf
new file mode 100644
index 0000000..d4097de
Binary files /dev/null and b/static/techreports/blocking-2006-11.pdf differ
diff --git a/static/techreports/blocking-2011-09-15.pdf b/static/techreports/blocking-2011-09-15.pdf
new file mode 100644
index 0000000..5f6ccb3
Binary files /dev/null and b/static/techreports/blocking-2011-09-15.pdf differ
diff --git a/static/techreports/botnet-tr-2013-11-20.pdf b/static/techreports/botnet-tr-2013-11-20.pdf
new file mode 100644
index 0000000..37aee52
Binary files /dev/null and b/static/techreports/botnet-tr-2013-11-20.pdf differ
diff --git a/static/techreports/bridge-report-usage-stats-2012-04-30.pdf b/static/techreports/bridge-report-usage-stats-2012-04-30.pdf
new file mode 100644
index 0000000..ce344ff
Binary files /dev/null and b/static/techreports/bridge-report-usage-stats-2012-04-30.pdf differ
diff --git a/static/techreports/bridge-scaling-2012-03-09.pdf b/static/techreports/bridge-scaling-2012-03-09.pdf
new file mode 100644
index 0000000..acf241f
Binary files /dev/null and b/static/techreports/bridge-scaling-2012-03-09.pdf differ
diff --git a/static/techreports/bridge-stability-2011-10-31.pdf b/static/techreports/bridge-stability-2011-10-31.pdf
new file mode 100644
index 0000000..6e38d6b
Binary files /dev/null and b/static/techreports/bridge-stability-2011-10-31.pdf differ
diff --git a/static/techreports/bridges-2009-06-22.pdf b/static/techreports/bridges-2009-06-22.pdf
new file mode 100644
index 0000000..c9dbdd8
Binary files /dev/null and b/static/techreports/bridges-2009-06-22.pdf differ
diff --git a/static/techreports/bufferstats-2009-08-25.pdf b/static/techreports/bufferstats-2009-08-25.pdf
new file mode 100644
index 0000000..153d114
Binary files /dev/null and b/static/techreports/bufferstats-2009-08-25.pdf differ
diff --git a/static/techreports/censorship-analysis-tool-2013-02-06.pdf b/static/techreports/censorship-analysis-tool-2013-02-06.pdf
new file mode 100644
index 0000000..10a4cdb
Binary files /dev/null and b/static/techreports/censorship-analysis-tool-2013-02-06.pdf differ
diff --git a/static/techreports/challenges-2005-02.pdf b/static/techreports/challenges-2005-02.pdf
new file mode 100644
index 0000000..7ac234c
Binary files /dev/null and b/static/techreports/challenges-2005-02.pdf differ
diff --git a/static/techreports/circwindow-2009-09-20.pdf b/static/techreports/circwindow-2009-09-20.pdf
new file mode 100644
index 0000000..9293767
Binary files /dev/null and b/static/techreports/circwindow-2009-09-20.pdf differ
diff --git a/static/techreports/counting-daily-bridge-users-2012-10-24.pdf b/static/techreports/counting-daily-bridge-users-2012-10-24.pdf
new file mode 100644
index 0000000..fb474f1
Binary files /dev/null and b/static/techreports/counting-daily-bridge-users-2012-10-24.pdf differ
diff --git a/static/techreports/countingusers-2010-11-30.pdf b/static/techreports/countingusers-2010-11-30.pdf
new file mode 100644
index 0000000..340672a
Binary files /dev/null and b/static/techreports/countingusers-2010-11-30.pdf differ
diff --git a/static/techreports/data-2011-03-14.pdf b/static/techreports/data-2011-03-14.pdf
new file mode 100644
index 0000000..0d49b4c
Binary files /dev/null and b/static/techreports/data-2011-03-14.pdf differ
diff --git a/static/techreports/datagram-comparison-2011-11-07.pdf b/static/techreports/datagram-comparison-2011-11-07.pdf
new file mode 100644
index 0000000..b90f027
Binary files /dev/null and b/static/techreports/datagram-comparison-2011-11-07.pdf differ
diff --git a/static/techreports/datagram-testing-plan-2012-03-16.pdf b/static/techreports/datagram-testing-plan-2012-03-16.pdf
new file mode 100644
index 0000000..3ac933d
Binary files /dev/null and b/static/techreports/datagram-testing-plan-2012-03-16.pdf differ
diff --git a/static/techreports/detector-2011-09-09.pdf b/static/techreports/detector-2011-09-09.pdf
new file mode 100644
index 0000000..ae0724a
Binary files /dev/null and b/static/techreports/detector-2011-09-09.pdf differ
diff --git a/static/techreports/different-ways-use-bridge-2011-11-29.pdf b/static/techreports/different-ways-use-bridge-2011-11-29.pdf
new file mode 100644
index 0000000..fc5c4b7
Binary files /dev/null and b/static/techreports/different-ways-use-bridge-2011-11-29.pdf differ
diff --git a/static/techreports/dirarch-2009-06-22.pdf b/static/techreports/dirarch-2009-06-22.pdf
new file mode 100644
index 0000000..ec7eae0
Binary files /dev/null and b/static/techreports/dirarch-2009-06-22.pdf differ
diff --git a/static/techreports/directory-requests-2009-06-25.pdf b/static/techreports/directory-requests-2009-06-25.pdf
new file mode 100644
index 0000000..b6ad061
Binary files /dev/null and b/static/techreports/directory-requests-2009-06-25.pdf differ
diff --git a/static/techreports/dos-censorship-report1-2018-11-19.pdf b/static/techreports/dos-censorship-report1-2018-11-19.pdf
new file mode 100644
index 0000000..96b477e
Binary files /dev/null and b/static/techreports/dos-censorship-report1-2018-11-19.pdf differ
diff --git a/static/techreports/dos-taxonomy-2015-10-29.pdf b/static/techreports/dos-taxonomy-2015-10-29.pdf
new file mode 100644
index 0000000..a7cdb8c
Binary files /dev/null and b/static/techreports/dos-taxonomy-2015-10-29.pdf differ
diff --git a/static/techreports/extrapolating-hidserv-stats-2015-01-31.pdf b/static/techreports/extrapolating-hidserv-stats-2015-01-31.pdf
new file mode 100644
index 0000000..e6ab6ed
Binary files /dev/null and b/static/techreports/extrapolating-hidserv-stats-2015-01-31.pdf differ
diff --git a/static/techreports/five-ways-test-bridge-reachability-2011-12-01.pdf b/static/techreports/five-ways-test-bridge-reachability-2011-12-01.pdf
new file mode 100644
index 0000000..81283a8
Binary files /dev/null and b/static/techreports/five-ways-test-bridge-reachability-2011-12-01.pdf differ
diff --git a/static/techreports/flagrequirements-2009-04-11.pdf b/static/techreports/flagrequirements-2009-04-11.pdf
new file mode 100644
index 0000000..ccf7753
Binary files /dev/null and b/static/techreports/flagrequirements-2009-04-11.pdf differ
diff --git a/static/techreports/geoipdbcomp-2009-10-23.pdf b/static/techreports/geoipdbcomp-2009-10-23.pdf
new file mode 100644
index 0000000..c966111
Binary files /dev/null and b/static/techreports/geoipdbcomp-2009-10-23.pdf differ
diff --git a/static/techreports/hidden-service-stats-2015-04-28.pdf b/static/techreports/hidden-service-stats-2015-04-28.pdf
new file mode 100644
index 0000000..1bfe994
Binary files /dev/null and b/static/techreports/hidden-service-stats-2015-04-28.pdf differ
diff --git a/static/techreports/libutp-2013-10-30.pdf b/static/techreports/libutp-2013-10-30.pdf
new file mode 100644
index 0000000..35beba1
Binary files /dev/null and b/static/techreports/libutp-2013-10-30.pdf differ
diff --git a/static/techreports/measuring-safety-tor-network-2011-02-06.pdf b/static/techreports/measuring-safety-tor-network-2011-02-06.pdf
new file mode 100644
index 0000000..b2bdce0
Binary files /dev/null and b/static/techreports/measuring-safety-tor-network-2011-02-06.pdf differ
diff --git a/static/techreports/metrics-2009-08-07.pdf b/static/techreports/metrics-2009-08-07.pdf
new file mode 100644
index 0000000..264ca91
Binary files /dev/null and b/static/techreports/metrics-2009-08-07.pdf differ
diff --git a/static/techreports/modern-collector-2018-12-19.pdf b/static/techreports/modern-collector-2018-12-19.pdf
new file mode 100644
index 0000000..3e4ff65
Binary files /dev/null and b/static/techreports/modern-collector-2018-12-19.pdf differ
diff --git a/static/techreports/morpher-2012-03-13.pdf b/static/techreports/morpher-2012-03-13.pdf
new file mode 100644
index 0000000..115f1c9
Binary files /dev/null and b/static/techreports/morpher-2012-03-13.pdf differ
diff --git a/static/techreports/overhead-directory-info-2009-02-16.pdf b/static/techreports/overhead-directory-info-2009-02-16.pdf
new file mode 100644
index 0000000..9cfa919
Binary files /dev/null and b/static/techreports/overhead-directory-info-2009-02-16.pdf differ
diff --git a/static/techreports/performance-2009-11-09.pdf b/static/techreports/performance-2009-11-09.pdf
new file mode 100644
index 0000000..6c9cd10
Binary files /dev/null and b/static/techreports/performance-2009-11-09.pdf differ
diff --git a/static/techreports/pluggable-roadmap-2012-03-17.pdf b/static/techreports/pluggable-roadmap-2012-03-17.pdf
new file mode 100644
index 0000000..985b66b
Binary files /dev/null and b/static/techreports/pluggable-roadmap-2012-03-17.pdf differ
diff --git a/static/techreports/privacy-in-memory-2017-04-28.pdf b/static/techreports/privacy-in-memory-2017-04-28.pdf
new file mode 100644
index 0000000..e47e934
Binary files /dev/null and b/static/techreports/privacy-in-memory-2017-04-28.pdf differ
diff --git a/static/techreports/relay-stability-2011-06-30.pdf b/static/techreports/relay-stability-2011-06-30.pdf
new file mode 100644
index 0000000..9a8357e
Binary files /dev/null and b/static/techreports/relay-stability-2011-06-30.pdf differ
diff --git a/static/techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf b/static/techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf
new file mode 100644
index 0000000..5802f63
Binary files /dev/null and b/static/techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf differ
diff --git a/static/techreports/tbb-forensic-analysis-2013-06-28.pdf b/static/techreports/tbb-forensic-analysis-2013-06-28.pdf
new file mode 100644
index 0000000..87a12ce
Binary files /dev/null and b/static/techreports/tbb-forensic-analysis-2013-06-28.pdf differ
diff --git a/static/techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf b/static/techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf
new file mode 100644
index 0000000..bd779d8
Binary files /dev/null and b/static/techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf differ
diff --git a/static/techreports/tor-growth-2014-10-04.pdf b/static/techreports/tor-growth-2014-10-04.pdf
new file mode 100644
index 0000000..d9397d2
Binary files /dev/null and b/static/techreports/tor-growth-2014-10-04.pdf differ
diff --git a/static/techreports/tor-nat-plan-2012-08-22.pdf b/static/techreports/tor-nat-plan-2012-08-22.pdf
new file mode 100644
index 0000000..c6bb70f
Binary files /dev/null and b/static/techreports/tor-nat-plan-2012-08-22.pdf differ
diff --git a/static/techreports/torflow-2009-08-07.pdf b/static/techreports/torflow-2009-08-07.pdf
new file mode 100644
index 0000000..ebc6e6c
Binary files /dev/null and b/static/techreports/torflow-2009-08-07.pdf differ
diff --git a/static/techreports/torperf-2009-09-22.pdf b/static/techreports/torperf-2009-09-22.pdf
new file mode 100644
index 0000000..9fcf90d
Binary files /dev/null and b/static/techreports/torperf-2009-09-22.pdf differ
diff --git a/static/techreports/torperf2-2013-10-30.pdf b/static/techreports/torperf2-2013-10-30.pdf
new file mode 100644
index 0000000..908ae41
Binary files /dev/null and b/static/techreports/torperf2-2013-10-30.pdf differ
diff --git a/static/techreports/virtual-private-services-2008-07-25.pdf b/static/techreports/virtual-private-services-2008-07-25.pdf
new file mode 100644
index 0000000..c01b9b8
Binary files /dev/null and b/static/techreports/virtual-private-services-2008-07-25.pdf differ
diff --git a/static/techreports_bib.html b/static/techreports_bib.html
new file mode 100644
index 0000000..dced0e7
--- /dev/null
+++ b/static/techreports_bib.html
@@ -0,0 +1,579 @@
+<h1>techreports.bib</h1><a name="tor-2018-12-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2018-12-001">tor-2018-12-001</a>,
+ author = {Iain R. Learmonth and Karsten Loesing},
+ title = {Towards Modernising Data Collection and Archive for the {Tor} Network},
+ institution = {The Tor Project},
+ number = {2018-12-001},
+ year = {2018},
+ month = {December},
+ url = {https://research.torproject.org/techreports/modern-collector-2018-12-19.pdf}
+}
+</pre>
+
+<a name="tor-2018-11-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2018-11-001">tor-2018-11-001</a>,
+ author = {Antonela Debiasi and Roger Dingledine and Arthur Edelstein and Alexander F\ae r\o y and Matthew Finkel and David Goulet and Kat Hanna and Maggie Haughey and George Kadianakis and Iain R. Learmonth and Alison Macrina and Maria Xynou},
+ title = {Addressing Denial of Service Attacks on Free and Open Communication on the Internet},
+ institution = {The Tor Project},
+ number = {2018-11-001},
+ year = {2018},
+ month = {November},
+ url = {https://research.torproject.org/techreports/dos-censorship-report1-2018-11-19.pdf}
+}
+</pre>
+
+<a name="tor-2017-04-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2017-04-001">tor-2017-04-001</a>,
+ author = {Karin Herm},
+ title = {Privacy analysis of {Tor}'s in-memory statistics},
+ institution = {The Tor Project},
+ number = {2017-04-001},
+ year = {2017},
+ month = {April},
+ url = {https://research.torproject.org/techreports/privacy-in-memory-2017-04-28.pdf}
+}
+</pre>
+
+<a name="tor-2015-10-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2015-10-001">tor-2015-10-001</a>,
+ author = {Nick Mathewson},
+ title = {Denial-of-service attacks in {Tor}: Taxonomy and defenses},
+ institution = {The Tor Project},
+ number = {2015-10-001},
+ year = {2015},
+ month = {October},
+ url = {https://research.torproject.org/techreports/dos-taxonomy-2015-10-29.pdf}
+}
+</pre>
+
+<a name="tor-2015-04-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2015-04-001">tor-2015-04-001</a>,
+ author = {David Goulet and Aaron Johnson and George Kadianakis and Karsten Loesing},
+ title = {Hidden-service statistics reported by relays},
+ institution = {The Tor Project},
+ number = {2015-04-001},
+ year = {2015},
+ month = {April},
+ url = {https://research.torproject.org/techreports/hidden-service-stats-2015-04-28.pdf}
+}
+</pre>
+
+<a name="tor-2015-01-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2015-01-001">tor-2015-01-001</a>,
+ author = {George Kadianakis and Karsten Loesing},
+ title = {Extrapolating network totals from hidden-service statistics},
+ institution = {The Tor Project},
+ number = {2015-01-001},
+ year = {2015},
+ month = {January},
+ url = {https://research.torproject.org/techreports/extrapolating-hidserv-stats-2015-01-31.pdf}
+}
+</pre>
+
+<a name="tor-2014-10-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2014-10-001">tor-2014-10-001</a>,
+ author = {Virgil Griffith},
+ title = {{Tor} growth rates and improving {Torperf} throughput},
+ institution = {The Tor Project},
+ number = {2014-10-001},
+ year = {2014},
+ month = {October},
+ url = {https://research.torproject.org/techreports/tor-growth-2014-10-04.pdf}
+}
+</pre>
+
+<a name="tor-2013-11-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2013-11-001">tor-2013-11-001</a>,
+ author = {Nicholas Hopper},
+ title = {Protecting {Tor} from botnet abuse in the long term},
+ institution = {The Tor Project},
+ number = {2013-11-001},
+ year = {2013},
+ month = {November},
+ url = {https://research.torproject.org/techreports/botnet-tr-2013-11-20.pdf}
+}
+</pre>
+
+<a name="tor-2013-10-002"></a><pre>
+ at techreport{<a href="techreports.html#tor-2013-10-002">tor-2013-10-002</a>,
+ author = {Karsten Loesing and Sathyanarayanan Gunasekaran and Kevin Butler},
+ title = {Requirements and Software Design for a better {Tor} Performance Measurement Tool},
+ institution = {The Tor Project},
+ number = {2013-10-002},
+ year = {2013},
+ month = {October},
+ url = {https://research.torproject.org/techreports/torperf2-2013-10-30.pdf}
+}
+</pre>
+
+<a name="tor-2013-10-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2013-10-001">tor-2013-10-001</a>,
+ author = {Karsten Loesing and Steven J. Murdoch and Rob Jansen},
+ title = {Evaluation of a libutp-based {Tor} datagram implementation},
+ institution = {The Tor Project},
+ number = {2013-10-001},
+ year = {2013},
+ month = {October},
+ url = {https://research.torproject.org/techreports/libutp-2013-10-30.pdf}
+}
+</pre>
+
+<a name="tor-2013-06-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2013-06-001">tor-2013-06-001</a>,
+ author = {Runa A. Sandvik},
+ title = {Forensic Analysis of the {Tor Browser Bundle} on {OS X},
+ {Linux}, and {Windows}},
+ institution = {The Tor Project},
+ number = {2013-06-001},
+ year = {2013},
+ month = {June},
+ url = {https://research.torproject.org/techreports/tbb-forensic-analysis-2013-06-28.pdf}
+}
+</pre>
+
+<a name="tor-2013-02-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2013-02-001">tor-2013-02-001</a>,
+ author = {Philipp Winter},
+ title = {Design Requirements for a {Tor} Censorship Analysis Tool},
+ institution = {The Tor Project},
+ number = {2013-02-001},
+ year = {2013},
+ month = {February},
+ url = {https://research.torproject.org/techreports/censorship-analysis-tool-2013-02-06.pdf}
+}
+</pre>
+
+<a name="tor-2012-10-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2012-10-001">tor-2012-10-001</a>,
+ author = {Karsten Loesing},
+ title = {Counting daily bridge users},
+ institution = {The Tor Project},
+ number = {2012-10-001},
+ year = {2012},
+ month = {October},
+ url = {https://research.torproject.org/techreports/counting-daily-bridge-users-2012-10-24.pdf}
+}
+</pre>
+
+<a name="tor-2012-08-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2012-08-001">tor-2012-08-001</a>,
+ author = {Jacob Appelbaum},
+ title = {{Tor} and {NAT} devices: increasing bridge \& relay reachability or, enabling the use of {NAT-PMP} and {UPnP} by default},
+ institution = {The Tor Project},
+ number = {2012-08-001},
+ year = {2012},
+ month = {August},
+ url = {https://research.torproject.org/techreports/tor-nat-plan-2012-08-22.pdf}
+}
+</pre>
+
+<a name="tor-2012-04-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2012-04-001">tor-2012-04-001</a>,
+ author = {Karsten Loesing},
+ title = {What fraction of our bridges are not reporting usage statistics?},
+ institution = {The Tor Project},
+ number = {2012-04-001},
+ year = {2012},
+ month = {April},
+ url = {https://research.torproject.org/techreports/bridge-report-usage-stats-2012-04-30.pdf}
+}
+</pre>
+
+<a name="tor-2012-03-003"></a><pre>
+ at techreport{<a href="techreports.html#tor-2012-03-003">tor-2012-03-003</a>,
+ author = {Steven J. Murdoch and George Kadianakis},
+ title = {Pluggable Transports Roadmap},
+ institution = {The Tor Project},
+ number = {2012-03-003},
+ year = {2012},
+ month = {March},
+ url = {https://research.torproject.org/techreports/pluggable-roadmap-2012-03-17.pdf}
+}
+</pre>
+
+<a name="tor-2012-03-002"></a><pre>
+ at techreport{<a href="techreports.html#tor-2012-03-002">tor-2012-03-002</a>,
+ author = {Steven J. Murdoch},
+ title = {Datagram Testing Plan},
+ institution = {The Tor Project},
+ number = {2012-03-002},
+ year = {2012},
+ month = {March},
+ url = {https://research.torproject.org/techreports/datagram-testing-plan-2012-03-16.pdf}
+}
+</pre>
+
+<a name="tor-2012-03-004"></a><pre>
+ at techreport{<a href="techreports.html#tor-2012-03-004">tor-2012-03-004</a>,
+ author = {George Kadianakis},
+ title = {Packet Size Pluggable Transport and Traffic Morphing},
+ institution = {The Tor Project},
+ number = {2012-03-004},
+ year = {2012},
+ month = {March},
+ url = {https://research.torproject.org/techreports/morpher-2012-03-13.pdf}
+}
+</pre>
+
+<a name="tor-2012-03-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2012-03-001">tor-2012-03-001</a>,
+ author = {Karsten Loesing},
+ title = {What if the {Tor} network had 50,000 bridges},
+ institution = {The Tor Project},
+ number = {2012-03-001},
+ year = {2012},
+ month = {March},
+ url = {https://research.torproject.org/techreports/bridge-scaling-2012-03-09.pdf}
+}
+</pre>
+
+<a name="tor-2011-12-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-12-001">tor-2011-12-001</a>,
+ author = {Roger Dingledine},
+ title = {Five ways to test bridge reachability},
+ institution = {The Tor Project},
+ number = {2011-12-001},
+ year = {2011},
+ month = {December},
+ url = {https://research.torproject.org/techreports/five-ways-test-bridge-reachability-2011-12-01.pdf}
+}
+</pre>
+
+<a name="tor-2011-11-002"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-11-002">tor-2011-11-002</a>,
+ author = {Sebastian Hahn},
+ title = {Different Ways to Use a Bridge},
+ institution = {The Tor Project},
+ number = {2011-11-002},
+ year = {2011},
+ month = {November},
+ url = {https://research.torproject.org/techreports/different-ways-use-bridge-2011-11-29.pdf}
+}
+</pre>
+
+<a name="tor-2011-11-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-11-001">tor-2011-11-001</a>,
+ author = {Steven J. Murdoch},
+ title = {Comparison of {Tor} Datagram Designs},
+ institution = {The Tor Project},
+ number = {2011-11-001},
+ year = {2011},
+ month = {November},
+ url = {https://research.torproject.org/techreports/datagram-comparison-2011-11-07.pdf}
+}
+</pre>
+
+<a name="tor-2011-10-002"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-10-002">tor-2011-10-002</a>,
+ author = {Roger Dingledine},
+ title = {Ten ways to discover {Tor} bridges},
+ institution = {The Tor Project},
+ number = {2011-10-002},
+ year = {2011},
+ month = {October},
+ url = {https://research.torproject.org/techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf}
+}
+</pre>
+
+<a name="tor-2011-10-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-10-001">tor-2011-10-001</a>,
+ author = {Karsten Loesing},
+ title = {An Analysis of {Tor} Bridge Stability---Making {BridgeDB} give out at least one stable bridge per user},
+ institution = {The Tor Project},
+ number = {2011-10-001},
+ year = {2011},
+ month = {October},
+ url = {https://research.torproject.org/techreports/bridge-stability-2011-10-31.pdf}
+}
+</pre>
+
+<a name="tor-2011-09-002"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-09-002">tor-2011-09-002</a>,
+ author = {Karsten Loesing},
+ title = {Case study: Learning whether a {Tor} bridge is blocked by looking at its aggregate usage statistics, Part one},
+ institution = {The Tor Project},
+ number = {2011-09-002},
+ year = {2011},
+ month = {September},
+ url = {https://research.torproject.org/techreports/blocking-2011-09-15.pdf}
+}
+</pre>
+
+<a name="tor-2011-09-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-09-001">tor-2011-09-001</a>,
+ author = {George Danezis},
+ title = {An anomaly-based censorship-detection system for {Tor}},
+ institution = {The Tor Project},
+ number = {2011-09-001},
+ year = {2011},
+ month = {September},
+ url = {https://research.torproject.org/techreports/detector-2011-09-09.pdf}
+}
+</pre>
+
+<a name="tor-2011-08-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-08-001">tor-2011-08-001</a>,
+ author = {Roger Dingledine},
+ title = {Better guard rotation parameters},
+ institution = {The Tor Project},
+ number = {2011-08-001},
+ year = {2011},
+ month = {August},
+ url = {https://research.torproject.org/techreports/better-guard-rotation-parameters-2011-08-20.pdf}
+}
+</pre>
+
+<a name="tor-2011-06-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-06-001">tor-2011-06-001</a>,
+ author = {Karsten Loesing},
+ title = {An Analysis of {Tor} Relay Stability},
+ institution = {The Tor Project},
+ number = {2011-06-001},
+ year = {2011},
+ month = {June},
+ url = {https://research.torproject.org/techreports/relay-stability-2011-06-30.pdf}
+}
+</pre>
+
+<a name="tor-2011-05-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-05-001">tor-2011-05-001</a>,
+ author = {Roger Dingledine},
+ title = {Strategies for getting more bridges},
+ institution = {The Tor Project},
+ number = {2011-05-001},
+ year = {2011},
+ month = {May},
+ url = {https://research.torproject.org/techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf}
+}
+</pre>
+
+<a name="tor-2011-03-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-03-001">tor-2011-03-001</a>,
+ author = {Karsten Loesing},
+ title = {Overview of Statistical Data in the {Tor} Network},
+ institution = {The Tor Project},
+ number = {2011-03-001},
+ year = {2011},
+ month = {March},
+ url = {https://research.torproject.org/techreports/data-2011-03-14.pdf}
+}
+</pre>
+
+<a name="tor-2011-02-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2011-02-001">tor-2011-02-001</a>,
+ author = {Roger Dingledine},
+ title = {Measuring the safety of the {Tor} network},
+ institution = {The Tor Project},
+ number = {2011-02-001},
+ year = {2011},
+ month = {February},
+ url = {https://research.torproject.org/techreports/measuring-safety-tor-network-2011-02-06.pdf}
+}
+</pre>
+
+<a name="tor-2010-11-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2010-11-001">tor-2010-11-001</a>,
+ author = {Sebastian Hahn and Karsten Loesing},
+ title = {Privacy-preserving Ways to Estimate the Number of {Tor} Users},
+ institution = {The Tor Project},
+ number = {2010-11-001},
+ year = {2010},
+ month = {November},
+ url = {https://research.torproject.org/techreports/countingusers-2010-11-30.pdf}
+}
+</pre>
+
+<a name="tor-2010-09-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2010-09-001">tor-2010-09-001</a>,
+ author = {Roger Dingledine},
+ title = {Adaptive throttling of {Tor} clients by entry guards},
+ institution = {The Tor Project},
+ number = {2010-09-001},
+ year = {2010},
+ month = {September},
+ url = {https://research.torproject.org/techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf}
+}
+</pre>
+
+<a name="tor-2009-11-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-11-001">tor-2009-11-001</a>,
+ author = {Roger Dingledine and Steven J. Murdoch},
+ title = {Performance Improvements on {Tor} or, Why {Tor} is slow and what we're going to do about it},
+ institution = {The Tor Project},
+ number = {2009-11-001},
+ year = {2009},
+ month = {November},
+ url = {https://research.torproject.org/techreports/performance-2009-11-09.pdf}
+}
+</pre>
+
+<a name="tor-2009-10-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-10-001">tor-2009-10-001</a>,
+ author = {Karsten Loesing},
+ title = {Comparison of {GeoIP} Databases for {Tor}},
+ institution = {The Tor Project},
+ number = {2009-10-001},
+ year = {2009},
+ month = {October},
+ url = {https://research.torproject.org/techreports/geoipdbcomp-2009-10-23.pdf}
+}
+</pre>
+
+<a name="tor-2009-09-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-09-001">tor-2009-09-001</a>,
+ author = {Karsten Loesing},
+ title = {Performance of Requests over the {Tor} Network},
+ institution = {The Tor Project},
+ number = {2009-09-001},
+ year = {2009},
+ month = {September},
+ url = {https://research.torproject.org/techreports/torperf-2009-09-22.pdf}
+}
+</pre>
+
+<a name="tor-2009-09-002"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-09-002">tor-2009-09-002</a>,
+ author = {Karsten Loesing},
+ title = {Reducing the Circuit Window Size in {Tor}},
+ institution = {The Tor Project},
+ number = {2009-09-002},
+ year = {2009},
+ month = {September},
+ url = {https://research.torproject.org/techreports/circwindow-2009-09-20.pdf}
+}
+</pre>
+
+<a name="tor-2009-08-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-08-001">tor-2009-08-001</a>,
+ author = {Karsten Loesing},
+ title = {Analysis of Circuit Queues in {Tor}},
+ institution = {The Tor Project},
+ number = {2009-08-001},
+ year = {2009},
+ month = {August},
+ url = {https://research.torproject.org/techreports/bufferstats-2009-08-25.pdf}
+}
+</pre>
+
+<a name="tor-2009-08-002"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-08-002">tor-2009-08-002</a>,
+ author = {Karsten Loesing},
+ title = {Measuring the {Tor} Network from Public Directory Information},
+ institution = {The Tor Project},
+ number = {2009-08-002},
+ year = {2009},
+ month = {August},
+ url = {https://research.torproject.org/techreports/metrics-2009-08-07.pdf}
+}
+</pre>
+
+<a name="tor-2009-08-003"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-08-003">tor-2009-08-003</a>,
+ author = {Mike Perry},
+ title = {{TorFlow}: {Tor} Network Analysis},
+ institution = {The Tor Project},
+ number = {2009-08-003},
+ year = {2009},
+ month = {August},
+ url = {https://research.torproject.org/techreports/torflow-2009-08-07.pdf}
+}
+</pre>
+
+<a name="tor-2009-06-002"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-06-002">tor-2009-06-002</a>,
+ author = {Karsten Loesing},
+ title = {Measuring the {Tor} Network, Evaluation of Client Requests to the Directories to determine total numbers and countries of users},
+ institution = {The Tor Project},
+ number = {2009-06-002},
+ year = {2009},
+ month = {June},
+ url = {https://research.torproject.org/techreports/directory-requests-2009-06-25.pdf}
+}
+</pre>
+
+<a name="tor-2009-06-003"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-06-003">tor-2009-06-003</a>,
+ author = {Karsten Loesing},
+ title = {Analysis of Bridge Usage in {Tor}},
+ institution = {The Tor Project},
+ number = {2009-06-003},
+ year = {2009},
+ month = {June},
+ url = {https://research.torproject.org/techreports/bridges-2009-06-22.pdf}
+}
+</pre>
+
+<a name="tor-2009-06-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-06-001">tor-2009-06-001</a>,
+ author = {Karsten Loesing},
+ title = {Measuring the {Tor} Network, Evaluation of Relays from Public Directory Data},
+ institution = {The Tor Project},
+ number = {2009-06-001},
+ year = {2009},
+ month = {June},
+ url = {https://research.torproject.org/techreports/dirarch-2009-06-22.pdf}
+}
+</pre>
+
+<a name="tor-2009-04-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-04-001">tor-2009-04-001</a>,
+ author = {Sebastian Hahn and Karsten Loesing and Steven J. Murdoch},
+ title = {Measuring the {Tor} Network, Simulation of the number of Fast, Stable, and Guard flags for changed requirements},
+ institution = {The Tor Project},
+ number = {2009-04-001},
+ year = {2009},
+ month = {April},
+ url = {https://research.torproject.org/techreports/flagrequirements-2009-04-11.pdf}
+}
+</pre>
+
+<a name="tor-2009-02-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2009-02-001">tor-2009-02-001</a>,
+ author = {Roger Dingledine},
+ title = {Overhead from directory info: past, present, future},
+ institution = {The Tor Project},
+ number = {2009-02-001},
+ year = {2009},
+ month = {February},
+ url = {https://research.torproject.org/techreports/overhead-directory-info-2009-02-16.pdf}
+}
+</pre>
+
+<a name="tor-2008-07-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2008-07-001">tor-2008-07-001</a>,
+ author = {Karsten Loesing and Guido Wirtz},
+ title = {Virtual Private Services},
+ institution = {The Tor Project},
+ number = {2008-07-001},
+ year = {2008},
+ month = {July},
+ url = {https://research.torproject.org/techreports/virtual-private-services-2008-07-25.pdf}
+}
+</pre>
+
+<a name="tor-2006-11-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2006-11-001">tor-2006-11-001</a>,
+ author = {Roger Dingledine and Nick Mathewson},
+ title = {Design of a blocking-resistant anonymity system},
+ institution = {The Tor Project},
+ number = {2006-11-001},
+ year = {2006},
+ month = {November},
+ url = {https://research.torproject.org/techreports/blocking-2006-11.pdf}
+}
+</pre>
+
+<a name="tor-2005-02-001"></a><pre>
+ at techreport{<a href="techreports.html#tor-2005-02-001">tor-2005-02-001</a>,
+ author = {Roger Dingledine and Nick Mathewson and Paul Syverson},
+ title = {Challenges in deploying low-latency anonymity},
+ institution = {The Tor Project},
+ number = {2005-02-001},
+ year = {2005},
+ month = {February},
+ url = {https://research.torproject.org/techreports/challenges-2005-02.pdf}
+}
+</pre>
+
+<hr><p><em>This file was generated by
+<a href="http://www.lri.fr/~filliatr/bibtex2html/">bibtex2html</a> 1.99.</em></p>
diff --git a/static/trsb/2016-01-questionnaire-answers.txt b/static/trsb/2016-01-questionnaire-answers.txt
new file mode 100644
index 0000000..0f1e909
--- /dev/null
+++ b/static/trsb/2016-01-questionnaire-answers.txt
@@ -0,0 +1,113 @@
+
+From: QI ZHONG <zhongqi92 at berkeley.edu>
+Date: Mon, 10 Oct 2016 02:34:11 -0700
+
+A draft template/questionaire to promote safer Tor experiments
+
+1a. What are you trying to learn about? Is it:
+- New algorithm(s) that enhances current algorithm(s) in Tor.
+- New system that interacts with Tor.
+- New attack(s) that degrade(s) Tor properties.
+- The characteristics of the real-world Tor network and its clients, operators, network topology, etc.
+- Something else.
+
+The characteristics of the real-world Tor network and its clients, operators, network topology, etc.
+
+1b. What about the above are you trying to learn? Is it:
+- Performance enhancement/reduction.
+- Security enhancement/reduction.
+- Privacy enhancement/reduction.
+- Actual real-world trends, details, etc of the Tor network.
+-- Could we use this data to construct models about the Tor network?
+- Something else.
+
+Actual real-world trends, details, etc of the Tor network. It might be possible to construct better model.
+
+1c. Why is it important to learn the above?
+- It justifies the new algorithm/system/attack.
+- It would reveal (alarming) significant information about the Tor network, and:
+-- Tor should change its design (and we have suggestions on how).
+-- We can model this aspect of the Tor network and use it henceforth (and avoid collecting data like this again).
+- Something else.
+
+Something else. We hope it can make Tor more censorship-resistant.
+
+2. Could you learn this by doing a closed-form analysis from the design?
+- Yes, and it would be pretty close to reality.
+- Yes, but it would not be realistic.
+-- Can you estimate how significant a deviation you expect from the closed-form analysis compared to the real-world results? Is it more like a) anyone's guess, or b) bounded by some amount/factor.
+- No, due to difficulties in performing closed-form analysis from the design.
+- No, because it would not be the real-world behavior of the network.
+
+No, because it would not be the real-world behavior of the network.
+
+3a. What data points do you need to learn the above?
+- How many?
+We will be testing the reachability of the default bridges.
+- Over what time period and duration?
+Indefinite.
+- From which vanatage points on the network? (e.g. clients, relays, directory servers, network, ISP, HSdir, etc).
+We test it from off the network.
+- What granularity is the data that is collected.
+It is only the reachability of different bridges during different time.
+- How will they be kept ``safe'' while they are collected and stored?
+We don't have any secret data. All our results will be published after our research.
+-- Describe what you mean by ``safe'' here.
+
+3b. How do these data points tell you about the thing you want to learn about?
+- Would it be conclusive?
+No, but it would give us better insights.
+- Would it be valid for only a snap-shot-in time?
+Yes.
+- Would it have to be updated regularly to remain relevant?
+Yes.
+
+3c. Does the data need to be released to justify your experiments/system?
+- Yes.
+-- With what granularity would it be reported?
+-- Would it be obfuscated in some fashion?
+- No.
+-- How will you justify your results instead?
+Yes. We will obfuscate our probe locations. None of the other data is secret.
+
+4. Is there an alternative, and existing, source of data you could use instead of collecting your own?
+- Yes.
+- No, it
+-- doesn't exist.
+-- is too old.
+-- is not released by the collector.
+No, it doesn't exist. We can use Tor collector data as supplyment though.
+
+5. Could you evaluate your enhancement/attack on a (local) test Tor network?
+- Yes.
+- Yes, but limited by the models we could use.
+- No, since the models we have are insufficient, or don't exist, or not robust enough. We need:
+-- Realistic client behviour.
+-- Realistic networking behaviour.
+-- Realistic bandwidth and computation load.
+-- Realistic system/Tor interaction.
+- No, for another reason.
+No. We need a realistic adversary.
+
+6. Describe your experimental methodology for running experiments to learn about/attack the live Tor-network.
+6a. When running your experiment on the live-network, you will collect and/or process:
+- Only data generated and realted to our own clients and nodes.
+- The above as well as those of other users of the Tor network.
+- Only data of other users of the Tor network.
+Only data generated and realted to our own clients and nodes.
+
+6b. Will you introduce resources (relays and bandwidth) into the network.
+- Yes.
+-- We will run clients (honest but curious, and/or malicious).
+-- We will run Directories (honest but curious, and/or malicious).
+-- We will run relays (guard, middle, exit) (honest but curious, and/or malicious).
+- No.
+-- How will you observe/influence the network if not directly through Tor nodes?
+We will run clients (honest but curious, and/or malicious).
+
+6c. Will you run custom Tor code on your Tor nodes?
+- Yes, but only to log certain events.
+- Yes, but it changes the original behavior.
+-- How would this affect the Tor network in general? Is it part of an attack? Describe the impact.
+No.
+
diff --git a/static/trsb/2016-01-questionnaire.txt b/static/trsb/2016-01-questionnaire.txt
new file mode 100644
index 0000000..7603966
--- /dev/null
+++ b/static/trsb/2016-01-questionnaire.txt
@@ -0,0 +1,115 @@
+
+From: "M. Tariq Elahi" <Tariq.Elahi at esat.kuleuven.be>
+Date: Fri, 30 Sep 2016 14:08:13 +0200
+
+Hi David,
+Thanks for reaching out about conducting safer experiments on the Tor
+network. I am taking the lead to assist you with that.
+I have gone over your responses to the guide questions and think you
+have done a pretty good job of figuring things out on your own.
+
+I have created a template (to someday replace the more generic questions
+on the webpage) that I am attaching here which is aimed at helping
+researchers work through their methodology and aims. Since you have
+already provided a lot of the responses, you can ignore those parts of
+the document, but do take a look at section 3(a-c), 4, and 6(a-c). It is
+more about how you'd do your experiments, store the data you collect,
+and keep everything super safe.
+
+The plan is to take those responses, get together and discuss/clarify
+where needed, and then I would write a recommendation for you and the
+board to consume stating whether your plan seems plausible. Since this
+is our first time and still figuring things out ourselves there is a lot
+of flexibility about how we go about this and the end result. Hopefully,
+it will be useful for your project, and for the Tor community.
+
+Look forward to hearing back from you.
+
+Cheers,
+Tariq
+
+A draft template/questionaire to promote safer Tor experiments
+
+1a. What are you trying to learn about? Is it:
+- New algorithm(s) that enhances current algorithm(s) in Tor.
+- New system that interacts with Tor.
+- New attack(s) that degrade(s) Tor properties.
+- The characteristics of the real-world Tor network and its clients, operators, network topology, etc.
+- Something else.
+
+1b. What about the above are you trying to learn? Is it:
+- Performance enhancement/reduction.
+- Security enhancement/reduction.
+- Privacy enhancement/reduction.
+- Actual real-world trends, details, etc of the Tor network.
+-- Could we use this data to construct models about the Tor network?
+- Something else.
+
+1c. Why is it important to learn the above?
+- It justifies the new algorithm/system/attack.
+- It would reveal (alarming) significant information about the Tor network, and:
+-- Tor should change its design (and we have suggestions on how).
+-- We can model this aspect of the Tor network and use it henceforth (and avoid collecting data like this again).
+- Something else.
+
+2. Could you learn this by doing a closed-form analysis from the design?
+- Yes, and it would be pretty close to reality.
+- Yes, but it would not be realistic.
+-- Can you estimate how significant a deviation you expect from the closed-form analysis compared to the real-world results? Is it more like a) anyone's guess, or b) bounded by some amount/factor.
+- No, due to difficulties in performing closed-form analysis from the design.
+- No, because it would not be the real-world behavior of the network.
+
+3a. What data points do you need to learn the above?
+- How many?
+- Over what time period and duration?
+- From which vanatage points on the network? (e.g. clients, relays, directory servers, network, ISP, HSdir, etc).
+- What granularity is the data that is collected.
+- How will they be kept ``safe'' while they are collected and stored?
+-- Describe what you mean by ``safe'' here.
+
+3b. How do these data points tell you about the thing you want to learn about?
+- Would it be conclusive?
+- Would it be valid for only a snap-shot-in time?
+- Would it have to be updated regularly to remain relevant?
+
+3c. Does the data need to be released to justify your experiments/system?
+- Yes.
+-- With what granularity would it be reported?
+-- Would it be obfuscated in some fashion?
+- No.
+-- How will you justify your results instead?
+
+4. Is there an alternative, and existing, source of data you could use instead of collecting your own?
+- Yes.
+- No, it
+-- doesn't exist.
+-- is too old.
+-- is not released by the collector.
+
+5. Could you evaluate your enhancement/attack on a (local) test Tor network?
+- Yes.
+- Yes, but limited by the models we could use.
+- No, since the models we have are insufficient, or don't exist, or not robust enough. We need:
+-- Realistic client behviour.
+-- Realistic networking behaviour.
+-- Realistic bandwidth and computation load.
+-- Realistic system/Tor interaction.
+- No, for another reason.
+
+6. Describe your experimental methodology for running experiments to learn about/attack the live Tor-network.
+6a. When running your experiment on the live-network, you will collect and/or process:
+- Only data generated and realted to our own clients and nodes.
+- The above as well as those of other users of the Tor network.
+- Only data of other users of the Tor network.
+6b. Will you introduce resources (relays and bandwidth) into the network.
+- Yes.
+-- We will run clients (honest but curious, and/or malicious).
+-- We will run Directories (honest but curious, and/or malicious).
+-- We will run relays (guard, middle, exit) (honest but curious, and/or malicious).
+- No.
+-- How will you observe/influence the network if not directly through Tor nodes?
+6c. Will you run custom Tor code on your Tor nodes?
+- Yes, but only to log certain events.
+- Yes, but it changes the original behavior.
+-- How would this affect the Tor network in general? Is it part of an attack? Describe the impact.
+
diff --git a/static/trsb/2016-01-request.txt b/static/trsb/2016-01-request.txt
new file mode 100644
index 0000000..3e01adc
--- /dev/null
+++ b/static/trsb/2016-01-request.txt
@@ -0,0 +1,193 @@
+
+Date: Thu, 18 Aug 2016 10:47:45 -0700
+From: David Fifield <david at bamsoftware.com>
+Subject: Tor Research Safety Board: default bridge reachability
+
+We're seeking comments on a continuation of our research on the blocking
+of default Tor Browser bridges. What we've done so far on this subject
+is covered in our FOCI 2016 paper, "Censors' Delay in Blocking
+Circumvention Proxies":
+https://www.bamsoftware.com/proxy-probe/
+
+The short summary of what we want to do is to greatly expand our
+measurement locations, by using existing platforms such as ICLab, OONI,
+or RIPE Atlas. We want to start doing traceroutes in addition to TCP
+reachability. We want to control how new bridges are introduced, in
+order to test specific hypotheses, such as whether there is a difference
+in detection between stable and alpha.
+
+
+== 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?
+
+1. Where the default bridges are blocked, globally. We know that China
+ (eventually) blocks them, and Iran (currently) does not; but we don't
+ know the situation anywhere else.
+2. In places where the default bridges get blocked, the dynamics of
+ blocking, such as how long it takes, its granularity (IP only or
+ IP/port), and whether blocks are eventually removed.
+3. How bridge addresses are discovered (e.g. through traffic analysis,
+ tickets, or source code), and how they are extracted (e.g. manually
+ or through automated parsing).
+
+The overarching, abstract benefit of the experiment is a better
+understanding of censorship, leading to the development of better
+informed circumvention.
+
+The latest bridge users' guide
+(https://blog.torproject.org/blog/breaking-through-censorship-barriers-even-when-tor-blocked)
+recommends using meek to users in China, because obfs4 is blocked. This
+research would let us know whether to expand that advice beyond China.
+
+By comparing reachability timelines across many censors, we may find
+evidence for or against censors sharing a common data source. For
+example, if two countries block a set of bridges at the same moment, it
+is probably because there is something in common in their detection.
+
+We may uncover specific operational weaknesses of censors that can be
+exploited. To choose an invented but plausible scenario, maybe a censor
+only does black-box testing of new bundles on the day of release: in
+that case, the browser could avoid connecting to a subset of bridges
+until after a certain date.
+
+If we are able to reachability publish data online on a frequently
+updated basis, someone could use it to build a Weather-like service that
+notifies operators of default bridges when their bridge stops running.
+This happened a few times already: some of the default bridges stopped
+running because of lost iptables rules after a reboot, and we were the
+first to notice, only because we were looking at the graphs every once
+in a while. (This would not always be possible using only Collector
+data, because for example the bridge might be running, but its obfs4
+port closed because of a firewall misconfiguration.)
+
+
+== 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.
+
+So far, we have only run from a handful of VPSes, never more than 4 at a
+time. We only had visibility into the U.S., China, and Iran. We
+carefully watched for the introduction of new obfs4 bridges (in some
+cases being privately informed in advance), and added them to a probe
+list, which got probed every 20 minutes by a cron job on the VPSes.
+
+We want to greatly expand our probe sites, by using existing measurement
+platforms such as ICLab, OONI, or RIPE Atlas. We hope to be able to
+measure from dozens or hundreds of diverse locations. We have already
+talked to ICLab and they are willing to probe our destinations from
+their endpoints, which mostly consist of commercial VPNs in various
+countries. The probes will consist of periodic TCP connections to Tor
+Browser default obfs4 bridges (released and not-yet-released) and
+control destinations. We want to start doing traceroutes as well.
+
+We expect that the TCP reachability data we collect will be similar to
+what we have collected so far. It looks like this:
+ date,site,host,port,elapsed,success,errno,errmsg
+ 1449892115.2,bauxite,178.209.52.110,443,10.0101830959,False,None,timed out
+ 1449901202.36,eecs-login,192.30.252.130,443,0.0761489868164,True,,
+ 1450858800.18,eecs-login,109.105.109.165,24215,0.189998865128,False,146,[Errno 146] Connection refused
+For traceroutes we will collect hop information (perhaps with some hops
+obscured; see the risks in the next section). We expect to be able to
+publish everything we collect in an immediate and ongoing basis.
+
+We also want to test some specific hypotheses by controlling the
+circumstances of bridge release. Here are specific experiments we have
+thought of (see corresponding risks in the next section):
+a. Rotating bridge ports with every release. Since the GFW blocks based
+ on IP/port, we can try just changing the port number of each bridge
+ in every release (using iptables forwarding for example).
+b. Putting different subsets of bridges in stable and alpha releases. We
+ saw that Orbot-only bridges did not get blocked; we wonder if
+ stable-only or alpha-only bridges also will not get blocked.
+c. Leaving a bridge commented out in bridge_prefs.js. This may help us
+ distinguish between black-box testing and manual source code review.
+
+
+== 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?
+
+The main risk is potentially enabling censors to discover new bridge
+addresses early, by monitoring our probe sites. Even though "default
+bridges" are conceptually broken, they do in fact work for many people,
+and we wouldn't want to reduce their utility.
+
+In our research so far, we've identified a number of ways that censors
+can discover new bridges: by watching the bug tracker, by reading source
+code, or by inspecting releases. Whenever possible, we want to start
+monitoring new bridges even before they enter the bug tracker. If a
+censor discovers one of our probe sites (which would not be hard to do),
+then they could watch for new addresses being connected to and add them
+to a blocklist. An adversary keeping netflow records could identify
+probe sites retroactively: download Tor Browser and get the new bridges,
+then find the clients that made the earliest connections to those
+addresses.
+
+We mitigate this risk partially by only testing default bridges, not
+secret BridgeDB bridges. That way, even if a censor discovers them, it
+doesn't affect users of secret bridges. Also, we suspect that, because
+default bridges are, in theory, easily discoverable, adding another
+potential discovery mechanism of medium difficult does not greatly
+increase the risk of their being blocked.
+
+If early blocking of bridges as a result of our experiment becomes a
+problem, we can adjust the protocol, for example not to monitor bridges
+in advance of their ticket being filed.
+
+Our heretofore published data do not include the IP addresses of the
+probe locations. The people who supplied us with the probe locations
+asked us not to reveal them. Traceroute will make it harder to conceal
+the source of probes in our published data. We can, for example, omit
+the first few hops in each trace, but we don't know the best practices
+along these lines. The potential harm to probe site operators is
+probably less when we use existing measurement platforms rather than
+VPSes acquired through personal contacts.
+
+Our results may be contaminated by other experiments being run from the
+same source address. The measurement platforms we propose to use already
+are running various other experiments, so they may be treated
+differently by firewalls. The most likely wrong outcome is that we
+falsely detect a bridge being blocked, when it is really the client
+address being blocked (because it is a VPN node, for example). The risk
+goes in the other direction as well: our experiment might affect others
+running on the same endpoint.
+
+Here are the risks related to testing the specific bridge-blocking
+hypotheses enumerated in the previous section:
+a. The risk in rotating bridge ports is that eventually the censor
+ catches on to the pattern and develops more sophisticated, automated
+ blocking. If the censor doesn't react, it means we have better
+ reachability; but if it does, we lose what small window of
+ post-release reachability we have.
+b. The risk in segregating bridge addresses across stable and alpha is
+ that a network observer can tell which a user is running by observing
+ what addresses they connect to. This may, for example, enable them to
+ target an exploit that only works on a specific version.
+c. The risk in playing games like commenting out bridge lines is slight:
+ a commented-out bridge may get blocked even before it has had any
+ real users.
+
+
+== 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?
+
+The main risk, bridge discovery by censors, has low potential harm, and
+can be mitigated if necessary by changing when we start monitoring
+bridges, or even ceasing the experiment altogether. The risk of our
+measurements is probably less than that of even having default bridges
+in the first place, because our probes are not connected to any
+real-world circumventor.
+
+The risks associated with our specific bridge-blocking hypotheses are
+variable, and we would appreciate discussion on them. The one we planned
+to try first is the commenting-out one, because it seems to have the
+best risk/reward tradeoff.
+
+Incidentally, OONI already has a bridge_reachability nettest that is
+similar to what we have proposed:
+https://ooni.torproject.org/nettest/tor-bridge-reachability/
+However their bridge list is not up to date,
+https://gitweb.torproject.org/ooni-probe.git/tree/var/example_inputs/bridges.txt?id=v1.6.1
+and a perusal of http://measurements.ooni.torproject.org/ shows that the
+test is not being run regularly.
+
diff --git a/static/trsb/2016-01-response.txt b/static/trsb/2016-01-response.txt
new file mode 100644
index 0000000..e6b4306
--- /dev/null
+++ b/static/trsb/2016-01-response.txt
@@ -0,0 +1,42 @@
+
+Date: Fri, 16 Dec 2016 16:54:52 +0100
+From: "M. Tariq Elahi" <Tariq.Elahi at esat.kuleuven.be>
+Subject: Re: Tor Research Safety Board: default bridge reachability
+
+Yesterday, I wrote to David et al. with a short summary of our review.
+The tl;dr was that we (Damon McCoy and I) don't see anything
+particularly wrong with their experimental setup and their proposed
+research. Here is a less terse version of the review.
+
+Summary of request:
+
+The goal of the experiments is to gain more extensive empirical data
+about how censors block Tor bridges. The experiments will measure where
+in the world bridges are blocked, how many are blocked, how long before
+they are blocked and other similar statistics and data points. The
+overarching goal is to use this new found information to aid in better
+bridge distribution schemes and censorship resistance in general.
+
+Experimental setup:
+
+Mainly the setup is to try to access bridges from many points on the
+Internet (through VPS hosting providers) and record if they were
+successfully connected to. There doesn't seem to be anything
+particularly risky here. For bridges that do get burned because of these
+probes we suggested that perhaps replacing them might be fair.
+
+Risks:
+
+The risk to users or the testing nodes do not seem high. The expected to
+be released data does not contain identifying information. The risk to
+public bridges is that they get blocked. However, as noted in the
+request as well, bridges that are public are not particularly well
+defended. However, this state of affairs seems to be OK in situations
+where the censor is not actively trying to find bridges to block.
+
+
+Recommendation:
+
+We believe that these experiments do not significantly increase the
+threat level of the Tor network, its operators, or its clients.
+
diff --git a/static/trsb/2016-03-request.txt b/static/trsb/2016-03-request.txt
new file mode 100644
index 0000000..3c8b1f7
--- /dev/null
+++ b/static/trsb/2016-03-request.txt
@@ -0,0 +1,67 @@
+Date: Wed, 26 Oct 2016 19:10:45 -0400
+From: Kymberlee McMaster <kymberlee.mcmaster at gmail.com>
+Subject: Re: Tor Research Safety Board
+
+Please see below for our answers to the questions on the website.
+
+ - 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?
+ - Team DIRE plans to analyze major events relating to the Dark Internet
+ and the substituent community response, the culture of the Dark Internet
+ community, and bitcoin's use as a form of currency in Dark Internet
+ marketplaces. The communication of a community during and after events can
+ provide insight into the culture of the people immersed in that community.
+ In order to understand the culture found on Dark Internet marketplaces,
+ Team DIRE plans to study the communication among individuals within the
+ Dark Internet community during events, such as the shutdown of a popular
+ marketplace.
+ - Our goal is to answer the following question: How does the
+ communities response to major events reflect the underlying culture? We
+ hypothesize that, although members of the Dark Internet are anonymous,
+ these events will bring the community together and give a representation of
+ the Dark Internet's culture that is different from the day to day. It is
+ useful for the world to understand the culture of the Dark Internet as it
+ expands its reach and is used by more and more people.
+ - 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.
+ - Our plan is twofold. We plan to collect texts form sources such as
+ blogs, Reddit, and news websites that all discuss the Dark Internet so we
+ can analyze their view of the Dark Internet. We then plan to take this
+ analysis and compare it to some events that have occurred involving the
+ Dark net to see if their view or user reactions change during those times
+ of crisis. All texts being used are public information available to anyone
+ with access to the Internet. Each text is coded so that we only use the
+ coded values in our analysis of those texts. We also plan to purchase items
+ from both Dark net and traditional Internet marketplaces and compare the
+ experiences involved with both and the quality of the products received in
+ relation to the price of the product.
+ - 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.
+ - Our data sets will be limited to the coding of the articles that we
+ read that have been published for public view on the Internet and Dark
+ Internet as well as the products that we receive from the purchasing we are
+ going through. Due to the nature of our project and the fact that we are
+ only looking to compare the views and products of the marketplaces on the
+ Dark and traditional Internet, there will be no attacks or risks to Tor due
+ to our actions and data sets.
+ - 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
+ - Since we believe there are no risks associated with the conduction of
+ this study, the benefits of learning about the differences in the way Dark
+ and traditional Internet marketplaces behave and are viewed can only
+ provide valuable insight into their cultures.
+
+Please let me know if you have any questions or need further information on
+the above information. We tried to keep it short but also descriptive
+enough that you would understand what we were trying to do without bogging
+you down with the exact things we are coding in our textual analysis.
+
+Additionally, my team will need to present our thesis next semester to a
+panel of experts, and we were wondering if you would be interested in
+serving as a member of the panel.
+
+Thank you for all of your help with our team!
+
+-Kym
+
diff --git a/static/trsb/2016-03-response.txt b/static/trsb/2016-03-response.txt
new file mode 100644
index 0000000..8dbf64d
--- /dev/null
+++ b/static/trsb/2016-03-response.txt
@@ -0,0 +1,201 @@
+Date: Thu, 22 Dec 2016 01:07:53 -0500
+From: Paul Syverson <paul.syverson at nrl.navy.mil>
+Subject: Re: Tor Research Safety Board
+
+Hi Kymberlee,
+
+Here is the TRSB response to your proposal.
+Please share with your team.
+
+May the season make sense to you and yours,
+Paul
+
+----------------------------------------
+
+Dear UMD Gemstone Team DIRE,
+
+Thank you for your submission of proposed research to the Tor Research
+Safety Board. Your proposal was reviewed by three members of the
+Board. I have assembled this response from the reviews each has
+given. There was no significant discussion since reviews were largely
+in agreement.
+
+Aside from safety considerations, all reviewers noted that they found
+the research to be potentially quite interesting. That is not always
+so, even for seasoned researchers much less undergraduates. Thus
+congratulations already in that respect.
+
+All reviewers agreed that there are no Tor-specific safety concerns
+for your research project. Nonetheless, all noted similar concerns
+for such research on the Internet, whether concerning Tor or not.
+
+Details can be found in the comments of each reviewer, included below.
+But in summary the concerns are
+
+1. Make sure that you take adequate security precautions for yourselves
+not just those you research.
+
+2. Be aware that when coding input from multiple sources, potential
+exists for privacy or safety risks to emerge out of the synthesis,
+even if the individual items being coded are safe in isolation.
+
+3. What constitutes "public" information may not be black-and-white and
+can have lots of context to it.
+
+Any or all of these may require the input or analysis of your IRB. In
+any case you should look over our comments and make sure that you are
+both taking them into consideration yourselves and making appropriate
+decisions with respect to your IRB.
+
+Please let me know if you have any further questions or comments.
+I look forward to seeing how your work progresses.
+
+Sincerely,
+Paul Syverson
+
+---------------------------------------------------------------
+Comments from Reviewer A
+---------------------------------------------------------------
+Based on the answers to the questionnaire, I would flag up the
+following issues that may be helpful to the research team:
+
+- The data collected is referred to as "public", and as I understand
+ it consists of discussion forum posts etc associated with specific
+ "darkweb" topics. While, the "public" nature of those posts does to
+ some extent mitigate the risks introduced by the research per se,
+ that data has the potential to be personally identifiable,
+ particularly when it is subject to coding on the basis of the
+ content. Thus I would advise the researchers to seek advice at their
+ institution on whether specific protocols and approvals are needed
+ when handling such PII. I know for a fact that institutions in the
+ EU -- where horizontal data protection provisions are in place --
+ would have to go through a (lightweight) approval process to collect
+ and handle such personal information. Probably procedures to ensure
+ the "anonymity" of the coded transcripts would also have to be
+ described as part of the approval process.
+
+- There is a little ambiguity in the description in relation to the
+ phrase "compare the views and products of the marketplaces". This
+ may mean simply browsing the pages of underground marketplaces,
+ which I think is fine (subject to the above). However, if products
+ are to be bought a certain amount of care should be taken. (1) the
+ safety of researchers should be thought of when it comes to payment
+ options, as well as shipping addresses -- ensuring that the
+ researchers personal information does not end up in the hands of
+ criminal organizations; (2) there are delicacies associated with
+ purchasing controlled substances, or other restricted items or
+ material from specific jurisdictions -- and probably some sound
+ legal advice will be needed in case this is the plan; (3) there are
+ ethical issues about providing payment for, or to anyone involved,
+ in criminal activity, since this may be seen as financially
+ supporting crime. Note that doing the above for research purposes
+ per se, is probably not a sufficient moral or legal defence, and
+ some sound legal & ethical reasoning may be required -- as well as
+ clear protocols to minimize risks to researchers or society at
+ large.
+
+- Besides the above, the research seems to be using Tor as a browser;
+ it does not involve any access that all other Tor users would not
+ have (eg. it does not involve observing traffic, running
+ infrastructure or even hidden services); and no other streams of
+ data, besides what is made available by hidden services, is likely
+ to be affected. Thus, I would think that the usual protocols for
+ collecting PII, and safely interacting with potentially criminal
+ activity while conducting research, should cover most concerns.
+
+- Beyond the strict remit of the board: this does sound like an
+ interesting project!
+
+---------------------------------------------------------------
+Comments from Reviewer B
+---------------------------------------------------------------
+[Note these are written in the context of Reviewer A's comments. -PFS]
+
+Interesting, I agree!
+
+I want to underscore two of Reviewer A's points:
+
+1) If you're giving money to bad people, you need to think through the
+ethics of that.
+
+2) It's important to consider your own safety when you're buying arbitrary
+things from arbitrary people on the Internet.
+
+Both of those are standard IRB topics, and not particularly Tor related,
+so we are right to send them to their IRB for more thoughts on those.
+
+And then here's a third one:
+
+3) Some marketplaces (both in onionspace and on the insecure web)
+require logins before you can browse the wares -- and some of them put
+up barriers to creating the account. At what point do the pages behind
+such login requirements stop counting as 'public'? "Anybody could have
+done these eighteen steps, so the stuff I found after that isn't private"
+is a slippery argument.
+
+But overall, sounds great, thumbs up!
+
+
+---------------------------------------------------------------
+Comments from Reviewer C
+---------------------------------------------------------------
+This looks like very interesting and potentially quite useful work. I
+look forward to seeing its results. I see no show-stoppers, but I do
+have a few safety recommendations and considerations.
+
+The proposed research is "limited to the coding of the articles that
+ we read that have been published for public view on the Internet
+ and Dark Internet as well as the products that we receive from
+ the purchasing we are going through."
+
+The researchers therefore conclude that there is no risk expected in
+conducting this work. Construed strictly in terms of expected Tor
+protocol use or gathering of Tor usage network data, that is
+true. However there are a few concerns.
+
+1. Safety of the researchers is as important as safety of those
+researched. While obviously you can give yourselves informed consent,
+you should take the same precautions as when purchasing or downloading
+anything from the Internet, perhaps with a slight increase in caution
+if purchasing items or visiting forums that seem potentially to have
+higher than normal likelihood of malicious activity, e.g., if focused
+on sensitive or controversial issues or goods. That will of course
+depend on the forums in which you participate. To the extent
+practicable, you should at least protect your own identities and
+network location. It would make sense to conduct all your research
+via Tor running on a suitably up-to-date and protected system except
+where something specific precludes that, e.g. visiting a forum/site
+that restricts access from the Tor network). Discussing the context of
+and extent to which such blockage is encountered could be a useful
+research output of this work.
+
+2. "[P]ublished for public view" is not as straightforward as that
+expression might seem.
+
+First of all, as Vitaly Shmatikov is fond of saying, there is no
+PII... it's all PII. Cf. his work w/ Arvind Narayanan on deanonymizing
+highly dimensional public data using, e.g., publicly posted IMDb
+reviews. Coding information from multiple sources potentially runs
+that risk, and the research should be conducted cognizant of the sorts
+of concerns that research in this space has identified.
+
+Second, you have not said whether sites you will visit/purchase-from
+require registration to participate. That is one indicator of privacy
+assumptions. But whether the sites require registration or not,
+certainly some forums assume information is to be shared only among
+participants or otherwise expect discretion and respect for privacy,
+e.g., forums for discussion amongst crime or disease abuse
+victims. Similarly, for participants in a purchase or other financial
+transaction.
+
+Third, even if information is publicly available, it may be that
+original sources of that information intended it to remain private in
+a way that is violated by public posting. Public posting may have
+occurred when others violated those assumptions.
+
+None of these are Tor-specific safety considerations, but the
+researchers should be cautious and cognizant of these themselves and
+should make sure that their intended research is acceptable given the
+guidelines or evaluation of UMD's IRB or its other institutional bodies
+for research involving (even public) data about individuals.
+
diff --git a/static/trsb/2017-02-request.pdf b/static/trsb/2017-02-request.pdf
new file mode 100644
index 0000000..706ed20
Binary files /dev/null and b/static/trsb/2017-02-request.pdf differ
diff --git a/static/trsb/2017-02-request.txt b/static/trsb/2017-02-request.txt
new file mode 100644
index 0000000..a18a00f
--- /dev/null
+++ b/static/trsb/2017-02-request.txt
@@ -0,0 +1,15 @@
+Date: Thu, 11 May 2017 03:18:19 -0400 (EDT)
+From: Guevara Noubir <noubir at ccs.neu.edu>
+Subject: Privacy-Preserving Longevity Study of Hidden Services
+
+Dear Tor Safety Board members,
+
+We have a collaboration between three teams, Erik Blass (Airbus),
+Aziz Mohaisen (University of Buffalo), Guevara Noubir (Northeastern
+University), and have been working on the design of a privacy-preserving
+study of the lifespan of hidden services. Please find attached our
+proposed design. We look forward to your feedback.
+
+Best regards,
+Guevara
+
diff --git a/static/trsb/2017-02-response.txt b/static/trsb/2017-02-response.txt
new file mode 100644
index 0000000..e485755
--- /dev/null
+++ b/static/trsb/2017-02-response.txt
@@ -0,0 +1,192 @@
+Date: Tue, 20 Jun 2017 04:12:52 -0400
+From: Roger Dingledine <arma at mit.edu>
+Subject: Re: Privacy-Preserving Longevity Study of Hidden Services
+
+--- My first thoughts ---
+
+Initial thoughts on angles to consider:
+
+A) The traditional question for this group: Is their methodology safe
+enough? Do they provide enough detail and specificity for us to decide
+whether it's safe?
+
+B) Assuming yes, do we have faith that they can build and implement
+and deploy the thing they describe?
+
+This piece is interesting, because the bad-relays team already identified
+and kicked out their relays from the network, since they looked like
+an unidentified Sybil attack (and then Donncha contacted them, since
+some of the relays were from neu, and then a few days later they sent
+us this pdf).
+
+I think ultimately they should get the bad-relays team to be comfortable
+with the plan (else the bad-relays team will quite reasonably wonder
+what the next Sybil attack is for, and try to disrupt it). And I think
+we here can play a big role in either reassuring the bad-relays team or
+not doing that.
+
+C) What other steps should they take when deploying their experimental
+relays, like labelling their relay nicknames, setting contactinfo,
+setting myfamily, etc? Maybe there's a set of best practices we can
+invent and then recommend.
+
+We might also choose to recommend that they go public about the
+experiment, before they do it -- unless they have a compelling need for
+secrecy, e.g. because it would mess up the experiment, and I don't see
+one here?
+
+D) Do we think their mechanism is measuring things correctly, and
+measuring the right things?
+
+That is, if they collect things and compute them as they describe,
+will they indeed get the results they think they'll get? Part A is
+"is it safe to do", and part D is "will it actually work".
+
+E) Is it worthwhile, that is, how valuable are the outcomes they're
+aiming for?
+
+That is, what do we think about the risk (A) vs the accuracy (D) vs the
+benefit (E)?
+
+E) They seem to have some weird assumptions in their hypothesis,
+e.g. "Short-lived hidden services could indicate not to be legitimate
+domains, as compared to long-lived domains." Many short-lived services
+could be things other websites, such as onionshare addresses. The HSDirs
+can't distinguish what protocol the onion service speaks. These sorts
+of issues aren't killers, but it would be polite of us to point them
+out while we're noticing them.
+
+F) What do I leave out?
+
+And finally, I'll note that this submission has a lot of overlap with
+what I would expect to see in a hypothetical future Privcount submission,
+so here we are with a chance to set the precedent well. :)
+
+--- Anonymous reviewer 2 ---
+
+Motivation
+- Why would short-lived hidden services denote illegitimate domains? Onion
+share and Ricochet are legitimate applications that likely have
+short-lived hidden services.
+- How would an unusual lifetime identify a hidden service?
+
+Data Collection
+- The protocol isn't active secure. For example, consider a malicious
+HSDir or client that "marks" each hash-table entry by adding in some
+value that is a unique multiple of a base value larger than the largest
+expected count. Other well-known active attacks can be used as well.
+- Malicious inputs can arbitrarily increase the counts.
+- How many parties are controlling the HSDirs? Three?
+- Are the HSDirs running as normal? Will they run only for the lifetime
+of the study or are they more stable? How many HSDirs will be controlled
+by any one entity?
+- Can the output be made noisy? The data has the flavor of "anonymized"
+data, which can frequently be deanonymized by an adversary with auxiliary
+information.
+- For how long will measurement occur before aggregation?
+- Who is in control of the measurement study? Can that entity set
+the measurement interval arbitrarily short (thus eliminating any
+aggregation over time) or otherwise change the measurement parameters
+to defeat privacy protections (e.g. by modifying the key/identities of
+the participants)?
+- Will the protocol implementation be made publicly available? Will it
+receive any scrutiny outside of the implementor(s)?
+
+Overall, the risk seems minimal against the most likely threats (passive
+observation, post-hoc compulsion). Reasonable steps are taken to secure
+individual and intermediate data, and the output should be aggregated to
+a fairly high degree. However, I do worry that this is a bit of security
+theater, as it doesn't seem unlikely that the measurement will suffer
+from easily exploitable weaknesses that eliminate its purported security
+properties, such as
+ 1. Control of crucial measurement parameters by a single entity
+ 2. Active attacks that can be easily run by any single party, *including
+ malicious clients*
+ 3. Common implementation oversights/shortcuts (e.g. not using/verifying
+ long-term public keys, use of an insecure broadcast protocol, using
+ a language such as Python that doesn't support secure deletion of keys)
+
+I do also worry about the validity of claims that can be made from
+this measurement study. How big is the hash table? If there are lots
+of collisions, then the apparent lifetimes will actually be the sum of
+lifetimes of many colliding services. You should be able to bound the
+chance that this case occurs or detect when it does. Also, it seems as if
+the protocol couldn't tell the difference between an onion service that
+frequently publishes its descriptor (e.g. due to frequently-changing
+Introduction Points) and one that is around for a long time. Those are
+very different cases.
+
+--- Anonymous Reviewer 3 ---
+
+Recommendations:
+
+Correctly marking relays as family, adding contact info, a public page
+describing the study and research protocol and linking it in the contact
+info for the relays.
+
+Question of sniffing onions for discovery versus using other discovery
+methods. This is a question of how much is gained by measuring "private
+onion sites" versus only measuring "public onion sites"? Limiting to
+public onions without sniffing can be done as in prior work:
+http://s3.eurecom.fr/docs/www17_darktracing.pdf
+
+--- My meta-review putting the above together ---
+
+I think the discussion comes down to three points for analysis:
+
+(A) Is your plan more dangerous than you think? That is, did we find
+new risks in the proposed protocol / methodology?
+
+Reviewer 2 identified some issues where a malicious component of your
+system, e.g. one of the relays, or any client, could influence the
+resulting data. They also suggested adding noise into the aggregated
+output. These sound like good points, either for modifying the protocol
+before you do the experiment, or at least for acknowledging in the
+paper. Having good answers to Reviewer 2's methodology clarifying
+questions seems smart, especially for item (C) below.
+
+Overall, the consensus is that it's pretty low risk: the safety board
+people are ok with the research, especially once you've thought through
+the analysis from Reviewer 2.
+
+(B) Are you on track to being able to answer your research questions,
+if you do the proposed experiments?
+
+This one is trickier. I think there are real concerns about whether you
+would be able to answer your research questions as currently posed --
+short lived onion services could be Onionshare users, Ricochet users,
+or something else. It's a poor assumption that they're all websites,
+and it gets especially poor when you're grabbing them at the HSDirs
+because nobody knows even what fraction of onion services are websites
+or Ricochet or whatever.
+
+I think you should rethink whether you'll be able to answer your research
+questions this way, because I suspect you won't. That said, ultimately
+this is a safety board, so technically our perspectives on this part
+are out of scope and you don't need to care about them. :)
+
+(C) What are our recommendations for how to best deploy these relays in
+the real Tor network while keeping the network operators happy?
+
+I think Reviewer 3's recommendations here are a great start: set your
+MyFamily lines correctly -- one family for all three research groups
+-- and set each ContactInfo accurately too, and include a url in the
+ContactInfo to a page that describes who you are, what you're doing,
+why it's useful, and why your methodology is as safe as you can make it.
+
+The reason it's not workable to convince only the directory authority
+operators in private is that there's a community of people on the
+tor-relays list who are hunting for Sybils and other anomalies, and
+there's a good chance they will find your relay family after a while,
+and I expect the directory authority operators won't want to be in
+the position then of saying "yes, we know about this, but don't worry,
+you don't need to know."
+
+All of this said, assuming you want to proceed, I will volunteer to be
+the mediator to explain to the other directory authority operators why
+your plan seems to be a safe enough plan. I can't speak for all of them
+or predict what they'll want to learn, but I'm optimistic we'd be able
+to find some way forward.
+
+--Roger
+
diff --git a/static/trsb/2017-03-request.txt b/static/trsb/2017-03-request.txt
new file mode 100644
index 0000000..1cafc20
--- /dev/null
+++ b/static/trsb/2017-03-request.txt
@@ -0,0 +1,124 @@
+From: Rob Jansen <rob.g.jansen at nrl.navy.mil>
+Subject: Request for feedback on measuring popularity of Facebook onion site front page
+Date: Sun, 2 Jul 2017
+
+# Overview
+
+We have been working on exploring the website fingerprinting problem in
+Tor. In website fingerprinting, either a client's guard or someone that
+can observe the link between the client and its guard is adversarial and
+attempts to link the client to its destination. This linking is attempted
+by first crawling common destinations and gathering a dataset of webpage
+features, and then training a classifier to recognize those features,
+and finally using the trained classifier to guess the destination to
+which an observed traffic stream connected.
+
+A common assumption in research papers that explore these attacks is
+that the adversary controls the guard or client-to-guard link. We are
+attempting to understand how effective fingerprinting would be for a
+weaker node adversary that runs only middle nodes, and who focuses on
+onion service websites. This involves 1.) guessing if an observed circuit
+is a hidden service circuit (already done by Kwon et al. from a guard node
+position); 2.) guessing that you are in a middle position, specifically
+the middle position next to the client-side guard; and 3.) if both 1 and
+2 are true, then guessing the onion service website based on a trained
+classifier. We would like to apply these classifiers to Tor traffic and
+use them to measure the popularity of the Facebook onion site front page.
+
+# Where we are
+
+We have already used our own client and middle to crawl the onion
+service space. Our client built circuits to a list of onions, and our
+client pinned middle relays under our control so that all circuits were
+built through our middles. The clients sent a special signal to our
+middles so that the middles could tag the circuits that were created by
+us (so that it only logged our circuits and not circuits of legitimate
+clients). Our middles then logged ground truth information about these
+circuits, as well as features that could be used for guessing the circuit
+type, position, and onion site being accessed. We used this data set to
+train classifiers and run analysis.
+
+# Where we want to go
+
+In our version of website fingerprinting, we guess the circuit type,
+position, and onion site. Since we are doing this from a middle node,
+even if all of those guesses work out, the adversary learns that someone
+with a specific guard went to a given onion site. This is not enough for
+deanonymization. Although there are several strategies that could leak
+information about the client once a middle is successful at fingerprinting
+(guard profiling, latency attacks to geolocate clients, legal attacks
+on guards), we would like to show a potentially interesting application
+of website fingerprinting beyond client deanonymization.
+
+If fingerprinting at the middle is successful, then it can be used to
+discover onion service popularity; we first identify the onion site, and
+then measure the frequency that each onion site is accessed. Because this
+measurement is done from the middle position, we will more quickly gain
+a representative sample of all circuits built in Tor (because new middles
+are chosen for each circuit with fewer biases than guards and exits). We
+would like to use PrivCount to do such a popularity measurement safely,
+following the methods and settings set out in the "Safely Measuring Tor"
+CCS paper by Jansen and Johnson. This is where we are requesting feedback.
+
+We would like to measure the following:
+1. The fraction of all circuits that we classify as hidden service circuits
+2. The fraction of hidden service circuits that we classify as accessing
+the Facebook onion front page
+
+We want to do this measurement safely, because it will involve measuring
+circuits of real users. We hope to be able to do this from the first
+client-side middle node (which will involve guessing the circuit,
+position, and the site) as well as from the rendezvous position (which
+will only involve guessing the site). The classifiers necessary to perform
+these guesses will be trained on our previously crawled onion data set
+and a dataset of circuit information that we generated synthetically
+in Shadow.
+
+During the measurement process, circuit and cell metadata will be used
+by the classifiers to make their guesses. Circuit meta-data includes
+a description of the previous and next relay in the circuit, as well
+as the previous and next circuit ID and channel ID. Cell metadata
+includes whether the cell was sent or received and from which side of
+the circuit, the previous and next circuit ID and channel ID, the cell
+type and cell command type if known, and a timestamp relative to the
+start of the circuit.
+
+The meta-data will be sent in real time to PrivCount where it will be
+stored in volatile memory (RAM); the longest time that PrivCount will
+store the data in RAM is the lifetime of the circuit. When the circuit
+closes, PrivCount will pass the meta-data to the previously-trained
+classifier, which will make the guesses as appropriate. The following
+counters will be incremented in PrivCount according to the results of
+the guesses:
+
+1. Total number of circuits
+2. Total number of onion service circuits
+3. Number of onion service circuits accessing facebook onion frontpage
+4. Number of onion service circuits NOT accessing facebook onion frontpage
+
+Once these counters are incremented, all meta-data corresponding to
+circuit and its cells are destroyed. The PrivCount counters are initiated
+to noisy values to ensure differential privacy is maintained (cf. "Safely
+Measuring Tor"), and are then blinded and distributed across several
+share keepers to provide secure aggregation. At the end of the process,
+we learn *only* the value of these noisy counts aggregated across all data
+collectors, and nothing else about the information that was used during
+the measurement process. Specifically, client usage of Tor during our
+measurement will be protected under differential privacy. (We currently
+plan to run at least 3 share keepers and more than 10 data collectors.)
+
+# Value
+
+This work has value to the community that we believe offsets the potential
+risks associated with the measurement. Understanding Facebook popularity
+and having raw numbers to report, while is in itself interesting, also
+allows us to focus a popularity measurement on the positive use cases
+of Tor and onion service rather than the not-so-positive. We believe
+that showing how website fingerprinting can be applied to purposes
+other than client deanonymization is novel and interesting and may
+spur additional research that may ultimately help us better understand
+the real world risks associated with fingerprinting techniques (which
+may lead to better fingerprinting defenses). Finally, risk from middle
+nodes is often overlooked, and we think there is value in showing what
+is possible from the position with the fewest requirements.
+
diff --git a/static/trsb/2017-03-response.txt b/static/trsb/2017-03-response.txt
new file mode 100644
index 0000000..20a4478
--- /dev/null
+++ b/static/trsb/2017-03-response.txt
@@ -0,0 +1,118 @@
+Date: Sun, 16 Jul 2017 01:00:40 -0400
+From: Roger Dingledine <arma at mit.edu>
+Subject: Re: [tor-research-safety] Request for feedback on measuring popularity of Facebook onion site front page
+
+Here are some thoughts that are hopefully useful. I encourage other safety
+board people to jump in if they have responses or other perspectives.
+
+A) Here's an attack that your published data could enable.
+
+Let's say there is another page somewhere in onion land that looks
+just like the Facebook frontpage, from your classifier's perspective.
+
+In that case you're going to be counting, and publishing, what you think
+are Facebook frontpage visits, but if somebody knows the ground truth
+for the Facebook visits (and at least Facebook does), then they can
+subtract out the ground truth and learn the popularity of that other page.
+
+Counterintuitively, the more "colliding" pages there are, or rather,
+the more colliding pages there are that are sufficiently popular, the
+less scary things get, since you're publishing popularity of "Facebook +
+all the others that look like Facebook", and if that second part of the
+number is a broad variety of pages, it's not so scary to publish it.
+
+I guess you can look through your training traces to see if there are
+traces that look very similar, to get a handle on whether there are zero
+or some or many. But even if you find zero, (1) are your training traces
+just the front pages of other onion sites? In that case you'll be missing
+many internal pages, and maybe there is a colliding internal page. And
+(2) you don't have a comprehensive onion list (whatever that even means),
+so you can't assess closeness for the pages you don't know about. And
+(3) remember dynamic pages -- like a duckduckgo search for a particular
+sensitive word that you didn't think to search for. (I don't think that
+particular example will produce a collision with the Facebook frontpage,
+but maybe there's some similar example that would.)
+
+So, principle 1: publishing a sum of popularity of a small number of
+sites is inherently more revealing than publishing the sum of popularity
+of a broader set of sites, because the small number is more precise.
+
+And principle 1b: if an external party has a popularity count for a subset
+of your sum, they can get more precision than you originally intended.
+
+Unless the differential privacy that you talked about handles this case?
+I have been assuming it focuses on making it hard to reconstruct exactly
+how many hits a given relay saw, but maybe it does more magic than that?
+
+B) You mention picking Facebook in particular, and I assume you'll be
+naming them in your paper. Have you asked them if they're ok with this?
+
+Getting consent when possible would go a long way to making your approach
+as safe as it can be. I can imagine that Facebook would say it's ok,
+while I could imagine that a particular SecureDrop deployment might ask
+you to please not do it.
+
+In particular, two good contacts for Facebook would be Alec Muffett
+and <other Facebook security person anonymized for publication>.
+
+The service side is of course only half of the equation: in an ideal
+world it would be best to get consent from all the clients too. But since
+your experiment's approach aggregates all the clients, yet singles out
+the service, I think it's much more important to think about consent
+from the service side for this case.
+
+So, principle 2: the more you're going to single out and then name a
+particular entity, the more important it is for you to get consent from
+that entity before doing so.
+
+C) In fact, it would probably be good in your paper to specify *why*
+the safety board thought that doing this measurement was ok -- that
+you got consent and that's why you were comfortable naming them and
+publishing a measurement just for them.
+
+I think mentioning it in the paper is important because if this general
+"popularity measurement" attack works, I can totally imagine somebody
+wanting to do a follow-on paper measuring individual popularity for a big
+pile of other onion services, first because it would seem cool to do it
+in bulk (the exact opposite of the reason why you decided not to do it in
+bulk), and second because eventually people will realize that measuring
+popularity is a key stepping stone to building a bayesian prior, which
+could make website fingerprinting attacks work better than the default
+"assume a uniform prior" that I guess a lot of them do now.
+
+So, principle 3: explicitly say in your paper where your
+lines-you-didn't-want-to-cross are, so readers can know which follow-on
+activities are things you wouldn't have wanted to do (and so future PCs
+reviewing future follow-on papers have something concrete to point to
+when they're expressing concern about methodology).
+
+D) I actually expect your Facebook popularity measurement to show
+that it's not very popular right now. That's because, at least last I
+checked, all of the automated apps and stuff use facebook.com as their
+destination. The Facebook folks have talked about putting the onion
+address by default in their various mobile apps if it detects that Orbot
+is running, but as far as I know they haven't rolled that out yet. So
+(1) doing a measurement now will allow you to do another measurement
+later once Facebook has made some changes, and you'll have a baseline for
+comparison; and (2) if you coordinate better with the Facebook people,
+you can learn the state and expected timing for their "onion address by
+default" roll-out -- or heck, you might learn other confounding factors
+that Facebook can explain for you.
+
+E) If you're planning to use PrivCount, does that mean you are running
+more than one relay to do this measurement? I think yes because "and
+more than 10 data collectors"?
+
+For the last person who asked us about running many relays for doing
+measurements, we suggested that they label their relays in the ContactInfo
+section, and put up a little page explaining what their research is and
+why it's useful (I think the text you sent us would do fine).
+
+Here is their page for an example: http://tor.ccs.neu.edu/
+
+I think that step would be wise here too.
+
+Hope those are helpful! Let me know if you have any questions.
+
+--Roger
+
diff --git a/techreports-footer.html b/techreports-footer.html
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/techreports-footer.html
@@ -0,0 +1 @@
+
diff --git a/techreports-header.html b/techreports-header.html
new file mode 100644
index 0000000..5467ca8
--- /dev/null
+++ b/techreports-header.html
@@ -0,0 +1,6 @@
+---
+title: "Technical Reports"
+aliases:
+ - "/techreports.html"
+---
+
diff --git a/techreports.bib b/techreports.bib
new file mode 100644
index 0000000..7e0a90e
--- /dev/null
+++ b/techreports.bib
@@ -0,0 +1,481 @@
+ at techreport{tor-2018-12-001,
+ author = {Iain R. Learmonth and Karsten Loesing},
+ title = {Towards Modernising Data Collection and Archive for the {Tor} Network},
+ institution = {The Tor Project},
+ number = {2018-12-001},
+ year = {2018},
+ month = {December},
+ url = {https://research.torproject.org/techreports/modern-collector-2018-12-19.pdf},
+}
+
+ at techreport{tor-2018-11-001,
+ author = {Antonela Debiasi and Roger Dingledine and Arthur Edelstein and Alexander F\ae r\o y and Matthew Finkel and David Goulet and Kat Hanna and Maggie Haughey and George Kadianakis and Iain R. Learmonth and Alison Macrina and Maria Xynou},
+ title = {Addressing Denial of Service Attacks on Free and Open Communication on the Internet},
+ institution = {The Tor Project},
+ number = {2018-11-001},
+ year = {2018},
+ month = {November},
+ url = {https://research.torproject.org/techreports/dos-censorship-report1-2018-11-19.pdf},
+}
+
+ at techreport{tor-2017-04-001,
+ author = {Karin Herm},
+ title = {Privacy analysis of {Tor}'s in-memory statistics},
+ institution = {The Tor Project},
+ number = {2017-04-001},
+ year = {2017},
+ month = {April},
+ url = {https://research.torproject.org/techreports/privacy-in-memory-2017-04-28.pdf},
+}
+
+ at techreport{tor-2015-10-001,
+ author = {Nick Mathewson},
+ title = {Denial-of-service attacks in {Tor}: Taxonomy and defenses},
+ institution = {The Tor Project},
+ number = {2015-10-001},
+ year = {2015},
+ month = {October},
+ url = {https://research.torproject.org/techreports/dos-taxonomy-2015-10-29.pdf},
+}
+
+ at techreport{tor-2015-04-001,
+ author = {David Goulet and Aaron Johnson and George Kadianakis and Karsten Loesing},
+ title = {Hidden-service statistics reported by relays},
+ institution = {The Tor Project},
+ number = {2015-04-001},
+ year = {2015},
+ month = {April},
+ url = {https://research.torproject.org/techreports/hidden-service-stats-2015-04-28.pdf},
+}
+
+ at techreport{tor-2015-01-001,
+ author = {George Kadianakis and Karsten Loesing},
+ title = {Extrapolating network totals from hidden-service statistics},
+ institution = {The Tor Project},
+ number = {2015-01-001},
+ year = {2015},
+ month = {January},
+ url = {https://research.torproject.org/techreports/extrapolating-hidserv-stats-2015-01-31.pdf},
+}
+
+ at techreport{tor-2014-10-001,
+ author = {Virgil Griffith},
+ title = {{Tor} growth rates and improving {Torperf} throughput},
+ institution = {The Tor Project},
+ number = {2014-10-001},
+ year = {2014},
+ month = {October},
+ url = {https://research.torproject.org/techreports/tor-growth-2014-10-04.pdf},
+}
+
+ at techreport{tor-2013-11-001,
+ author = {Nicholas Hopper},
+ title = {Protecting {Tor} from botnet abuse in the long term},
+ institution = {The Tor Project},
+ number = {2013-11-001},
+ year = {2013},
+ month = {November},
+ url = {https://research.torproject.org/techreports/botnet-tr-2013-11-20.pdf},
+}
+
+ at techreport{tor-2013-10-002,
+ author = {Karsten Loesing and Sathyanarayanan Gunasekaran and Kevin Butler},
+ title = {Requirements and Software Design for a better {Tor} Performance Measurement Tool},
+ institution = {The Tor Project},
+ number = {2013-10-002},
+ year = {2013},
+ month = {October},
+ url = {https://research.torproject.org/techreports/torperf2-2013-10-30.pdf},
+}
+
+ at techreport{tor-2013-10-001,
+ author = {Karsten Loesing and Steven J. Murdoch and Rob Jansen},
+ title = {Evaluation of a libutp-based {Tor} datagram implementation},
+ institution = {The Tor Project},
+ number = {2013-10-001},
+ year = {2013},
+ month = {October},
+ url = {https://research.torproject.org/techreports/libutp-2013-10-30.pdf},
+}
+
+ at techreport{tor-2013-06-001,
+ author = {Runa A. Sandvik},
+ title = {Forensic Analysis of the {Tor Browser Bundle} on {OS X},
+ {Linux}, and {Windows}},
+ institution = {The Tor Project},
+ number = {2013-06-001},
+ year = {2013},
+ month = {June},
+ url = {https://research.torproject.org/techreports/tbb-forensic-analysis-2013-06-28.pdf},
+}
+
+ at techreport{tor-2013-02-001,
+ author = {Philipp Winter},
+ title = {Design Requirements for a {Tor} Censorship Analysis Tool},
+ institution = {The Tor Project},
+ number = {2013-02-001},
+ year = {2013},
+ month = {February},
+ url = {https://research.torproject.org/techreports/censorship-analysis-tool-2013-02-06.pdf},
+}
+
+ at techreport{tor-2012-10-001,
+ author = {Karsten Loesing},
+ title = {Counting daily bridge users},
+ institution = {The Tor Project},
+ number = {2012-10-001},
+ year = {2012},
+ month = {October},
+ url = {https://research.torproject.org/techreports/counting-daily-bridge-users-2012-10-24.pdf},
+}
+
+ at techreport{tor-2012-08-001,
+ author = {Jacob Appelbaum},
+ title = {{Tor} and {NAT} devices: increasing bridge \& relay reachability or, enabling the use of {NAT-PMP} and {UPnP} by default},
+ institution = {The Tor Project},
+ number = {2012-08-001},
+ year = {2012},
+ month = {August},
+ url = {https://research.torproject.org/techreports/tor-nat-plan-2012-08-22.pdf},
+}
+
+ at techreport{tor-2012-04-001,
+ author = {Karsten Loesing},
+ title = {What fraction of our bridges are not reporting usage statistics?},
+ institution = {The Tor Project},
+ number = {2012-04-001},
+ year = {2012},
+ month = {April},
+ url = {https://research.torproject.org/techreports/bridge-report-usage-stats-2012-04-30.pdf},
+}
+
+ at techreport{tor-2012-03-003,
+ author = {Steven J. Murdoch and George Kadianakis},
+ title = {Pluggable Transports Roadmap},
+ institution = {The Tor Project},
+ number = {2012-03-003},
+ year = {2012},
+ month = {March},
+ url = {https://research.torproject.org/techreports/pluggable-roadmap-2012-03-17.pdf},
+}
+
+ at techreport{tor-2012-03-002,
+ author = {Steven J. Murdoch},
+ title = {Datagram Testing Plan},
+ institution = {The Tor Project},
+ number = {2012-03-002},
+ year = {2012},
+ month = {March},
+ url = {https://research.torproject.org/techreports/datagram-testing-plan-2012-03-16.pdf},
+}
+
+ at techreport{tor-2012-03-004,
+ author = {George Kadianakis},
+ title = {Packet Size Pluggable Transport and Traffic Morphing},
+ institution = {The Tor Project},
+ number = {2012-03-004},
+ year = {2012},
+ month = {March},
+ url = {https://research.torproject.org/techreports/morpher-2012-03-13.pdf},
+}
+
+ at techreport{tor-2012-03-001,
+ author = {Karsten Loesing},
+ title = {What if the {Tor} network had 50,000 bridges},
+ institution = {The Tor Project},
+ number = {2012-03-001},
+ year = {2012},
+ month = {March},
+ url = {https://research.torproject.org/techreports/bridge-scaling-2012-03-09.pdf},
+}
+
+ at techreport{tor-2011-12-001,
+ author = {Roger Dingledine},
+ title = {Five ways to test bridge reachability},
+ institution = {The Tor Project},
+ number = {2011-12-001},
+ year = {2011},
+ month = {December},
+ url = {https://research.torproject.org/techreports/five-ways-test-bridge-reachability-2011-12-01.pdf},
+}
+
+ at techreport{tor-2011-11-002,
+ author = {Sebastian Hahn},
+ title = {Different Ways to Use a Bridge},
+ institution = {The Tor Project},
+ number = {2011-11-002},
+ year = {2011},
+ month = {November},
+ url = {https://research.torproject.org/techreports/different-ways-use-bridge-2011-11-29.pdf},
+}
+
+ at techreport{tor-2011-11-001,
+ author = {Steven J. Murdoch},
+ title = {Comparison of {Tor} Datagram Designs},
+ institution = {The Tor Project},
+ number = {2011-11-001},
+ year = {2011},
+ month = {November},
+ url = {https://research.torproject.org/techreports/datagram-comparison-2011-11-07.pdf},
+}
+
+ at techreport{tor-2011-10-002,
+ author = {Roger Dingledine},
+ title = {Ten ways to discover {Tor} bridges},
+ institution = {The Tor Project},
+ number = {2011-10-002},
+ year = {2011},
+ month = {October},
+ url = {https://research.torproject.org/techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf},
+}
+
+ at techreport{tor-2011-10-001,
+ author = {Karsten Loesing},
+ title = {An Analysis of {Tor} Bridge Stability---Making {BridgeDB} give out at least one stable bridge per user},
+ institution = {The Tor Project},
+ number = {2011-10-001},
+ year = {2011},
+ month = {October},
+ url = {https://research.torproject.org/techreports/bridge-stability-2011-10-31.pdf},
+}
+
+ at techreport{tor-2011-09-002,
+ author = {Karsten Loesing},
+ title = {Case study: Learning whether a {Tor} bridge is blocked by looking at its aggregate usage statistics, Part one},
+ institution = {The Tor Project},
+ number = {2011-09-002},
+ year = {2011},
+ month = {September},
+ url = {https://research.torproject.org/techreports/blocking-2011-09-15.pdf},
+}
+
+ at techreport{tor-2011-09-001,
+ author = {George Danezis},
+ title = {An anomaly-based censorship-detection system for {Tor}},
+ institution = {The Tor Project},
+ number = {2011-09-001},
+ year = {2011},
+ month = {September},
+ url = {https://research.torproject.org/techreports/detector-2011-09-09.pdf},
+}
+
+ at techreport{tor-2011-08-001,
+ author = {Roger Dingledine},
+ title = {Better guard rotation parameters},
+ institution = {The Tor Project},
+ number = {2011-08-001},
+ year = {2011},
+ month = {August},
+ url = {https://research.torproject.org/techreports/better-guard-rotation-parameters-2011-08-20.pdf},
+}
+
+ at techreport{tor-2011-06-001,
+ author = {Karsten Loesing},
+ title = {An Analysis of {Tor} Relay Stability},
+ institution = {The Tor Project},
+ number = {2011-06-001},
+ year = {2011},
+ month = {June},
+ url = {https://research.torproject.org/techreports/relay-stability-2011-06-30.pdf},
+}
+
+ at techreport{tor-2011-05-001,
+ author = {Roger Dingledine},
+ title = {Strategies for getting more bridges},
+ institution = {The Tor Project},
+ number = {2011-05-001},
+ year = {2011},
+ month = {May},
+ url = {https://research.torproject.org/techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf},
+}
+
+ at techreport{tor-2011-03-001,
+ author = {Karsten Loesing},
+ title = {Overview of Statistical Data in the {Tor} Network},
+ institution = {The Tor Project},
+ number = {2011-03-001},
+ year = {2011},
+ month = {March},
+ url = {https://research.torproject.org/techreports/data-2011-03-14.pdf},
+}
+
+ at techreport{tor-2011-02-001,
+ author = {Roger Dingledine},
+ title = {Measuring the safety of the {Tor} network},
+ institution = {The Tor Project},
+ number = {2011-02-001},
+ year = {2011},
+ month = {February},
+ url = {https://research.torproject.org/techreports/measuring-safety-tor-network-2011-02-06.pdf},
+}
+
+ at techreport{tor-2010-11-001,
+ author = {Sebastian Hahn and Karsten Loesing},
+ title = {Privacy-preserving Ways to Estimate the Number of {Tor} Users},
+ institution = {The Tor Project},
+ number = {2010-11-001},
+ year = {2010},
+ month = {November},
+ url = {https://research.torproject.org/techreports/countingusers-2010-11-30.pdf},
+}
+
+ at techreport{tor-2010-09-001,
+ author = {Roger Dingledine},
+ title = {Adaptive throttling of {Tor} clients by entry guards},
+ institution = {The Tor Project},
+ number = {2010-09-001},
+ year = {2010},
+ month = {September},
+ url = {https://research.torproject.org/techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf},
+}
+
+ at techreport{tor-2009-11-001,
+ author = {Roger Dingledine and Steven J. Murdoch},
+ title = {Performance Improvements on {Tor} or, Why {Tor} is slow and what we're going to do about it},
+ institution = {The Tor Project},
+ number = {2009-11-001},
+ year = {2009},
+ month = {November},
+ url = {https://research.torproject.org/techreports/performance-2009-11-09.pdf},
+}
+
+ at techreport{tor-2009-10-001,
+ author = {Karsten Loesing},
+ title = {Comparison of {GeoIP} Databases for {Tor}},
+ institution = {The Tor Project},
+ number = {2009-10-001},
+ year = {2009},
+ month = {October},
+ url = {https://research.torproject.org/techreports/geoipdbcomp-2009-10-23.pdf},
+}
+
+ at techreport{tor-2009-09-001,
+ author = {Karsten Loesing},
+ title = {Performance of Requests over the {Tor} Network},
+ institution = {The Tor Project},
+ number = {2009-09-001},
+ year = {2009},
+ month = {September},
+ url = {https://research.torproject.org/techreports/torperf-2009-09-22.pdf},
+}
+
+ at techreport{tor-2009-09-002,
+ author = {Karsten Loesing},
+ title = {Reducing the Circuit Window Size in {Tor}},
+ institution = {The Tor Project},
+ number = {2009-09-002},
+ year = {2009},
+ month = {September},
+ url = {https://research.torproject.org/techreports/circwindow-2009-09-20.pdf},
+}
+
+ at techreport{tor-2009-08-001,
+ author = {Karsten Loesing},
+ title = {Analysis of Circuit Queues in {Tor}},
+ institution = {The Tor Project},
+ number = {2009-08-001},
+ year = {2009},
+ month = {August},
+ url = {https://research.torproject.org/techreports/bufferstats-2009-08-25.pdf},
+}
+
+ at techreport{tor-2009-08-002,
+ author = {Karsten Loesing},
+ title = {Measuring the {Tor} Network from Public Directory Information},
+ institution = {The Tor Project},
+ number = {2009-08-002},
+ year = {2009},
+ month = {August},
+ url = {https://research.torproject.org/techreports/metrics-2009-08-07.pdf},
+}
+
+ at techreport{tor-2009-08-003,
+ author = {Mike Perry},
+ title = {{TorFlow}: {Tor} Network Analysis},
+ institution = {The Tor Project},
+ number = {2009-08-003},
+ year = {2009},
+ month = {August},
+ url = {https://research.torproject.org/techreports/torflow-2009-08-07.pdf},
+}
+
+ at techreport{tor-2009-06-002,
+ author = {Karsten Loesing},
+ title = {Measuring the {Tor} Network, Evaluation of Client Requests to the Directories to determine total numbers and countries of users},
+ institution = {The Tor Project},
+ number = {2009-06-002},
+ year = {2009},
+ month = {June},
+ url = {https://research.torproject.org/techreports/directory-requests-2009-06-25.pdf},
+}
+
+ at techreport{tor-2009-06-003,
+ author = {Karsten Loesing},
+ title = {Analysis of Bridge Usage in {Tor}},
+ institution = {The Tor Project},
+ number = {2009-06-003},
+ year = {2009},
+ month = {June},
+ url = {https://research.torproject.org/techreports/bridges-2009-06-22.pdf},
+}
+
+ at techreport{tor-2009-06-001,
+ author = {Karsten Loesing},
+ title = {Measuring the {Tor} Network, Evaluation of Relays from Public Directory Data},
+ institution = {The Tor Project},
+ number = {2009-06-001},
+ year = {2009},
+ month = {June},
+ url = {https://research.torproject.org/techreports/dirarch-2009-06-22.pdf},
+}
+
+ at techreport{tor-2009-04-001,
+ author = {Sebastian Hahn and Karsten Loesing and Steven J. Murdoch},
+ title = {Measuring the {Tor} Network, Simulation of the number of Fast, Stable, and Guard flags for changed requirements},
+ institution = {The Tor Project},
+ number = {2009-04-001},
+ year = {2009},
+ month = {April},
+ url = {https://research.torproject.org/techreports/flagrequirements-2009-04-11.pdf},
+}
+
+ at techreport{tor-2009-02-001,
+ author = {Roger Dingledine},
+ title = {Overhead from directory info: past, present, future},
+ institution = {The Tor Project},
+ number = {2009-02-001},
+ year = {2009},
+ month = {February},
+ url = {https://research.torproject.org/techreports/overhead-directory-info-2009-02-16.pdf},
+}
+
+ at techreport{tor-2008-07-001,
+ author = {Karsten Loesing and Guido Wirtz},
+ title = {Virtual Private Services},
+ institution = {The Tor Project},
+ number = {2008-07-001},
+ year = {2008},
+ month = {July},
+ url = {https://research.torproject.org/techreports/virtual-private-services-2008-07-25.pdf},
+}
+
+ at techreport{tor-2006-11-001,
+ author = {Roger Dingledine and Nick Mathewson},
+ title = {Design of a blocking-resistant anonymity system},
+ institution = {The Tor Project},
+ number = {2006-11-001},
+ year = {2006},
+ month = {November},
+ url = {https://research.torproject.org/techreports/blocking-2006-11.pdf},
+}
+
+ at techreport{tor-2005-02-001,
+ author = {Roger Dingledine and Nick Mathewson and Paul Syverson},
+ title = {Challenges in deploying low-latency anonymity},
+ institution = {The Tor Project},
+ number = {2005-02-001},
+ year = {2005},
+ month = {February},
+ url = {https://research.torproject.org/techreports/challenges-2005-02.pdf},
+}
+
diff --git a/techreports.html b/techreports.html
new file mode 100644
index 0000000..3132b85
--- /dev/null
+++ b/techreports.html
@@ -0,0 +1,502 @@
+
+<!-- This document was automatically generated with bibtex2html 1.99
+ (see http://www.lri.fr/~filliatr/bibtex2html/),
+ with the following command:
+ bibtex2html -d -r -nodoc -nokeys -q techreports.bib -->
+
+
+
+
+<p><a name="tor-2018-12-001"></a>
+
+Iain R. Learmonth and Karsten Loesing.
+ Towards modernising data collection and archive for the Tor
+ network.
+ Technical Report 2018-12-001, The Tor Project, December 2018.
+[ <a href="techreports_bib.html#tor-2018-12-001">bib</a> |
+<a href="https://research.torproject.org/techreports/modern-collector-2018-12-19.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2018-11-001"></a>
+
+Antonela Debiasi, Roger Dingledine, Arthur Edelstein, Alexander Færøy,
+ Matthew Finkel, David Goulet, Kat Hanna, Maggie Haughey, George Kadianakis,
+ Iain R. Learmonth, Alison Macrina, and Maria Xynou.
+ Addressing denial of service attacks on free and open communication
+ on the internet.
+ Technical Report 2018-11-001, The Tor Project, November 2018.
+[ <a href="techreports_bib.html#tor-2018-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/dos-censorship-report1-2018-11-19.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2017-04-001"></a>
+
+Karin Herm.
+ Privacy analysis of Tor's in-memory statistics.
+ Technical Report 2017-04-001, The Tor Project, April 2017.
+[ <a href="techreports_bib.html#tor-2017-04-001">bib</a> |
+<a href="https://research.torproject.org/techreports/privacy-in-memory-2017-04-28.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2015-10-001"></a>
+
+Nick Mathewson.
+ Denial-of-service attacks in Tor: Taxonomy and defenses.
+ Technical Report 2015-10-001, The Tor Project, October 2015.
+[ <a href="techreports_bib.html#tor-2015-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/dos-taxonomy-2015-10-29.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2015-04-001"></a>
+
+David Goulet, Aaron Johnson, George Kadianakis, and Karsten Loesing.
+ Hidden-service statistics reported by relays.
+ Technical Report 2015-04-001, The Tor Project, April 2015.
+[ <a href="techreports_bib.html#tor-2015-04-001">bib</a> |
+<a href="https://research.torproject.org/techreports/hidden-service-stats-2015-04-28.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2015-01-001"></a>
+
+George Kadianakis and Karsten Loesing.
+ Extrapolating network totals from hidden-service statistics.
+ Technical Report 2015-01-001, The Tor Project, January 2015.
+[ <a href="techreports_bib.html#tor-2015-01-001">bib</a> |
+<a href="https://research.torproject.org/techreports/extrapolating-hidserv-stats-2015-01-31.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2014-10-001"></a>
+
+Virgil Griffith.
+ Tor growth rates and improving Torperf throughput.
+ Technical Report 2014-10-001, The Tor Project, October 2014.
+[ <a href="techreports_bib.html#tor-2014-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/tor-growth-2014-10-04.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2013-11-001"></a>
+
+Nicholas Hopper.
+ Protecting Tor from botnet abuse in the long term.
+ Technical Report 2013-11-001, The Tor Project, November 2013.
+[ <a href="techreports_bib.html#tor-2013-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/botnet-tr-2013-11-20.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2013-10-001"></a>
+
+Karsten Loesing, Steven J. Murdoch, and Rob Jansen.
+ Evaluation of a libutp-based Tor datagram implementation.
+ Technical Report 2013-10-001, The Tor Project, October 2013.
+[ <a href="techreports_bib.html#tor-2013-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/libutp-2013-10-30.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2013-10-002"></a>
+
+Karsten Loesing, Sathyanarayanan Gunasekaran, and Kevin Butler.
+ Requirements and software design for a better Tor performance
+ measurement tool.
+ Technical Report 2013-10-002, The Tor Project, October 2013.
+[ <a href="techreports_bib.html#tor-2013-10-002">bib</a> |
+<a href="https://research.torproject.org/techreports/torperf2-2013-10-30.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2013-06-001"></a>
+
+Runa A. Sandvik.
+ Forensic analysis of the Tor Browser Bundle on OS X, Linux, and
+ Windows.
+ Technical Report 2013-06-001, The Tor Project, June 2013.
+[ <a href="techreports_bib.html#tor-2013-06-001">bib</a> |
+<a href="https://research.torproject.org/techreports/tbb-forensic-analysis-2013-06-28.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2013-02-001"></a>
+
+Philipp Winter.
+ Design requirements for a Tor censorship analysis tool.
+ Technical Report 2013-02-001, The Tor Project, February 2013.
+[ <a href="techreports_bib.html#tor-2013-02-001">bib</a> |
+<a href="https://research.torproject.org/techreports/censorship-analysis-tool-2013-02-06.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-10-001"></a>
+
+Karsten Loesing.
+ Counting daily bridge users.
+ Technical Report 2012-10-001, The Tor Project, October 2012.
+[ <a href="techreports_bib.html#tor-2012-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/counting-daily-bridge-users-2012-10-24.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-08-001"></a>
+
+Jacob Appelbaum.
+ Tor and NAT devices: increasing bridge & relay reachability or,
+ enabling the use of NAT-PMP and UPnP by default.
+ Technical Report 2012-08-001, The Tor Project, August 2012.
+[ <a href="techreports_bib.html#tor-2012-08-001">bib</a> |
+<a href="https://research.torproject.org/techreports/tor-nat-plan-2012-08-22.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-04-001"></a>
+
+Karsten Loesing.
+ What fraction of our bridges are not reporting usage statistics?
+ Technical Report 2012-04-001, The Tor Project, April 2012.
+[ <a href="techreports_bib.html#tor-2012-04-001">bib</a> |
+<a href="https://research.torproject.org/techreports/bridge-report-usage-stats-2012-04-30.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-03-001"></a>
+
+Karsten Loesing.
+ What if the Tor network had 50,000 bridges.
+ Technical Report 2012-03-001, The Tor Project, March 2012.
+[ <a href="techreports_bib.html#tor-2012-03-001">bib</a> |
+<a href="https://research.torproject.org/techreports/bridge-scaling-2012-03-09.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-03-004"></a>
+
+George Kadianakis.
+ Packet size pluggable transport and traffic morphing.
+ Technical Report 2012-03-004, The Tor Project, March 2012.
+[ <a href="techreports_bib.html#tor-2012-03-004">bib</a> |
+<a href="https://research.torproject.org/techreports/morpher-2012-03-13.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-03-002"></a>
+
+Steven J. Murdoch.
+ Datagram testing plan.
+ Technical Report 2012-03-002, The Tor Project, March 2012.
+[ <a href="techreports_bib.html#tor-2012-03-002">bib</a> |
+<a href="https://research.torproject.org/techreports/datagram-testing-plan-2012-03-16.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2012-03-003"></a>
+
+Steven J. Murdoch and George Kadianakis.
+ Pluggable transports roadmap.
+ Technical Report 2012-03-003, The Tor Project, March 2012.
+[ <a href="techreports_bib.html#tor-2012-03-003">bib</a> |
+<a href="https://research.torproject.org/techreports/pluggable-roadmap-2012-03-17.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-12-001"></a>
+
+Roger Dingledine.
+ Five ways to test bridge reachability.
+ Technical Report 2011-12-001, The Tor Project, December 2011.
+[ <a href="techreports_bib.html#tor-2011-12-001">bib</a> |
+<a href="https://research.torproject.org/techreports/five-ways-test-bridge-reachability-2011-12-01.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-11-001"></a>
+
+Steven J. Murdoch.
+ Comparison of Tor datagram designs.
+ Technical Report 2011-11-001, The Tor Project, November 2011.
+[ <a href="techreports_bib.html#tor-2011-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/datagram-comparison-2011-11-07.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-11-002"></a>
+
+Sebastian Hahn.
+ Different ways to use a bridge.
+ Technical Report 2011-11-002, The Tor Project, November 2011.
+[ <a href="techreports_bib.html#tor-2011-11-002">bib</a> |
+<a href="https://research.torproject.org/techreports/different-ways-use-bridge-2011-11-29.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-10-001"></a>
+
+Karsten Loesing.
+ An analysis of Tor bridge stability---making BridgeDB give out at
+ least one stable bridge per user.
+ Technical Report 2011-10-001, The Tor Project, October 2011.
+[ <a href="techreports_bib.html#tor-2011-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/bridge-stability-2011-10-31.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-10-002"></a>
+
+Roger Dingledine.
+ Ten ways to discover Tor bridges.
+ Technical Report 2011-10-002, The Tor Project, October 2011.
+[ <a href="techreports_bib.html#tor-2011-10-002">bib</a> |
+<a href="https://research.torproject.org/techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-09-001"></a>
+
+George Danezis.
+ An anomaly-based censorship-detection system for Tor.
+ Technical Report 2011-09-001, The Tor Project, September 2011.
+[ <a href="techreports_bib.html#tor-2011-09-001">bib</a> |
+<a href="https://research.torproject.org/techreports/detector-2011-09-09.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-09-002"></a>
+
+Karsten Loesing.
+ Case study: Learning whether a Tor bridge is blocked by looking at
+ its aggregate usage statistics, part one.
+ Technical Report 2011-09-002, The Tor Project, September 2011.
+[ <a href="techreports_bib.html#tor-2011-09-002">bib</a> |
+<a href="https://research.torproject.org/techreports/blocking-2011-09-15.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-08-001"></a>
+
+Roger Dingledine.
+ Better guard rotation parameters.
+ Technical Report 2011-08-001, The Tor Project, August 2011.
+[ <a href="techreports_bib.html#tor-2011-08-001">bib</a> |
+<a href="https://research.torproject.org/techreports/better-guard-rotation-parameters-2011-08-20.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-06-001"></a>
+
+Karsten Loesing.
+ An analysis of Tor relay stability.
+ Technical Report 2011-06-001, The Tor Project, June 2011.
+[ <a href="techreports_bib.html#tor-2011-06-001">bib</a> |
+<a href="https://research.torproject.org/techreports/relay-stability-2011-06-30.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-05-001"></a>
+
+Roger Dingledine.
+ Strategies for getting more bridges.
+ Technical Report 2011-05-001, The Tor Project, May 2011.
+[ <a href="techreports_bib.html#tor-2011-05-001">bib</a> |
+<a href="https://research.torproject.org/techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-03-001"></a>
+
+Karsten Loesing.
+ Overview of statistical data in the Tor network.
+ Technical Report 2011-03-001, The Tor Project, March 2011.
+[ <a href="techreports_bib.html#tor-2011-03-001">bib</a> |
+<a href="https://research.torproject.org/techreports/data-2011-03-14.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2011-02-001"></a>
+
+Roger Dingledine.
+ Measuring the safety of the Tor network.
+ Technical Report 2011-02-001, The Tor Project, February 2011.
+[ <a href="techreports_bib.html#tor-2011-02-001">bib</a> |
+<a href="https://research.torproject.org/techreports/measuring-safety-tor-network-2011-02-06.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2010-11-001"></a>
+
+Sebastian Hahn and Karsten Loesing.
+ Privacy-preserving ways to estimate the number of Tor users.
+ Technical Report 2010-11-001, The Tor Project, November 2010.
+[ <a href="techreports_bib.html#tor-2010-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/countingusers-2010-11-30.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2010-09-001"></a>
+
+Roger Dingledine.
+ Adaptive throttling of Tor clients by entry guards.
+ Technical Report 2010-09-001, The Tor Project, September 2010.
+[ <a href="techreports_bib.html#tor-2010-09-001">bib</a> |
+<a href="https://research.torproject.org/techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-11-001"></a>
+
+Roger Dingledine and Steven J. Murdoch.
+ Performance improvements on Tor or, why Tor is slow and what
+ we're going to do about it.
+ Technical Report 2009-11-001, The Tor Project, November 2009.
+[ <a href="techreports_bib.html#tor-2009-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/performance-2009-11-09.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-10-001"></a>
+
+Karsten Loesing.
+ Comparison of GeoIP databases for Tor.
+ Technical Report 2009-10-001, The Tor Project, October 2009.
+[ <a href="techreports_bib.html#tor-2009-10-001">bib</a> |
+<a href="https://research.torproject.org/techreports/geoipdbcomp-2009-10-23.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-09-002"></a>
+
+Karsten Loesing.
+ Reducing the circuit window size in Tor.
+ Technical Report 2009-09-002, The Tor Project, September 2009.
+[ <a href="techreports_bib.html#tor-2009-09-002">bib</a> |
+<a href="https://research.torproject.org/techreports/circwindow-2009-09-20.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-09-001"></a>
+
+Karsten Loesing.
+ Performance of requests over the Tor network.
+ Technical Report 2009-09-001, The Tor Project, September 2009.
+[ <a href="techreports_bib.html#tor-2009-09-001">bib</a> |
+<a href="https://research.torproject.org/techreports/torperf-2009-09-22.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-08-003"></a>
+
+Mike Perry.
+ TorFlow: Tor network analysis.
+ Technical Report 2009-08-003, The Tor Project, August 2009.
+[ <a href="techreports_bib.html#tor-2009-08-003">bib</a> |
+<a href="https://research.torproject.org/techreports/torflow-2009-08-07.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-08-002"></a>
+
+Karsten Loesing.
+ Measuring the Tor network from public directory information.
+ Technical Report 2009-08-002, The Tor Project, August 2009.
+[ <a href="techreports_bib.html#tor-2009-08-002">bib</a> |
+<a href="https://research.torproject.org/techreports/metrics-2009-08-07.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-08-001"></a>
+
+Karsten Loesing.
+ Analysis of circuit queues in Tor.
+ Technical Report 2009-08-001, The Tor Project, August 2009.
+[ <a href="techreports_bib.html#tor-2009-08-001">bib</a> |
+<a href="https://research.torproject.org/techreports/bufferstats-2009-08-25.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-06-001"></a>
+
+Karsten Loesing.
+ Measuring the Tor network, evaluation of relays from public
+ directory data.
+ Technical Report 2009-06-001, The Tor Project, June 2009.
+[ <a href="techreports_bib.html#tor-2009-06-001">bib</a> |
+<a href="https://research.torproject.org/techreports/dirarch-2009-06-22.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-06-003"></a>
+
+Karsten Loesing.
+ Analysis of bridge usage in Tor.
+ Technical Report 2009-06-003, The Tor Project, June 2009.
+[ <a href="techreports_bib.html#tor-2009-06-003">bib</a> |
+<a href="https://research.torproject.org/techreports/bridges-2009-06-22.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-06-002"></a>
+
+Karsten Loesing.
+ Measuring the Tor network, evaluation of client requests to the
+ directories to determine total numbers and countries of users.
+ Technical Report 2009-06-002, The Tor Project, June 2009.
+[ <a href="techreports_bib.html#tor-2009-06-002">bib</a> |
+<a href="https://research.torproject.org/techreports/directory-requests-2009-06-25.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-04-001"></a>
+
+Sebastian Hahn, Karsten Loesing, and Steven J. Murdoch.
+ Measuring the Tor network, simulation of the number of fast,
+ stable, and guard flags for changed requirements.
+ Technical Report 2009-04-001, The Tor Project, April 2009.
+[ <a href="techreports_bib.html#tor-2009-04-001">bib</a> |
+<a href="https://research.torproject.org/techreports/flagrequirements-2009-04-11.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2009-02-001"></a>
+
+Roger Dingledine.
+ Overhead from directory info: past, present, future.
+ Technical Report 2009-02-001, The Tor Project, February 2009.
+[ <a href="techreports_bib.html#tor-2009-02-001">bib</a> |
+<a href="https://research.torproject.org/techreports/overhead-directory-info-2009-02-16.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2008-07-001"></a>
+
+Karsten Loesing and Guido Wirtz.
+ Virtual private services.
+ Technical Report 2008-07-001, The Tor Project, July 2008.
+[ <a href="techreports_bib.html#tor-2008-07-001">bib</a> |
+<a href="https://research.torproject.org/techreports/virtual-private-services-2008-07-25.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2006-11-001"></a>
+
+Roger Dingledine and Nick Mathewson.
+ Design of a blocking-resistant anonymity system.
+ Technical Report 2006-11-001, The Tor Project, November 2006.
+[ <a href="techreports_bib.html#tor-2006-11-001">bib</a> |
+<a href="https://research.torproject.org/techreports/blocking-2006-11.pdf">.pdf</a> ]
+
+</p>
+
+<p><a name="tor-2005-02-001"></a>
+
+Roger Dingledine, Nick Mathewson, and Paul Syverson.
+ Challenges in deploying low-latency anonymity.
+ Technical Report 2005-02-001, The Tor Project, February 2005.
+[ <a href="techreports_bib.html#tor-2005-02-001">bib</a> |
+<a href="https://research.torproject.org/techreports/challenges-2005-02.pdf">.pdf</a> ]
+
+</p><hr><p><em>This file was generated by
+<a href="http://www.lri.fr/~filliatr/bibtex2html/">bibtex2html</a> 1.99.</em></p>
diff --git a/themes/torproject b/themes/torproject
new file mode 160000
index 0000000..b07708c
--- /dev/null
+++ b/themes/torproject
@@ -0,0 +1 @@
+Subproject commit b07708c422241f1bfc8d5dc312d7a45deb5dec5c
More information about the tor-commits
mailing list