- tor-commits - lists.torproject.org

[research-web/master] Automatically generate techreports.html from techreports.bib.
by karsten＠torproject.org 04 Sep '12

04 Sep '12

commit 966e8b5d27b0f517130f2c96059510c18cdd71f5 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Sep 4 15:21:35 2012 -0400 Automatically generate techreports.html from techreports.bib. --- .gitignore | 2 + generate-techreports-html | 5 + htdocs/techreports.html | 246 ----------------------------------- techreports-footer.html | 5 + techreports-header.html | 30 +++++ techreports.bib | 310 +++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 352 insertions(+), 246 deletions(-) diff --git a/.gitignore b/.gitignore index 9f9f5bf..fe28d9c 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,4 @@ htdocs/techreports/*.pdf +htdocs/techreports_bib.html +techreports.html diff --git a/generate-techreports-html b/generate-techreports-html new file mode 100755 index 0000000..f83827a --- /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 > htdocs/techreports.html +mv techreports_bib.html htdocs/ + diff --git a/htdocs/techreports.html b/htdocs/techreports.html deleted file mode 100644 index b249c33..0000000 --- a/htdocs/techreports.html +++ /dev/null @@ -1,246 +0,0 @@ -<html> -<head> -<title>Tor Tech Reports</title> -<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> -<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> -<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> -</head> -<body> - -<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> -<tr> - <td class="banner-left"> - <a href="index.html"> - <img src="/images/top-left.png" alt="Click to go to home page" - width="193" height="79"></a></td> - <td class="banner-middle"> - <a href="index.html">Home</a> - <a href="groups.html">Groups</a> - <a href="ideas.html">Ideas</a> - Tech Reports - </td> - <td class="banner-right"></td> -</tr> -</table> - -<div class="center"> -<div class="main-column"> -<h2>Tor Tech Reports</h2> -<br> - -<h3>2012</h3> -<br> - -<p>Jacob Appelbaum. -<i>Tor and NAT devices: increasing bridge & relay reachability or, -enabling the use of NAT-PMP and UPnP by default.</i> -Tor Tech Report 2012-08-001. -August 22, 2012. -<a href="techreports/tor-nat-plan-2012-08-22.pdf">PDF</a>.</p> - -<p>Steven J. Murdoch and George Kadianakis. -<i>Pluggable Transports Roadmap.</i> -Tor Tech Report 2012-03-003. -March 17, 2012. -<a href="techreports/pluggable-roadmap-2012-03-17.pdf">PDF</a>.</p> - -<p>Steven J. Murdoch. -<i>Datagram Testing Plan.</i> -Tor Tech Report 2012-03-002. -March 16, 2012. -<a href="techreports/datagram-testing-plan-2012-03-16.pdf">PDF</a>.</p> - -<p>George Kadianakis. -<i>Packet Size Pluggable Transport and Traffic Morphing.</i> -Tor Tech Report 2012-03-004. -March 13, 2012. -<a href="techreports/morpher-2012-03-13.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>What if the Tor network had 50,000 bridges?</i> -Tor Tech Report 2012-03-001. -March 9, 2012. -<a href="techreports/bridge-scaling-2012-03-09.pdf">PDF</a>.</p> - -<h3>2011</h3> -<br> - -<p>Roger Dingledine. -<i>Five ways to test bridge reachability.</i> -Tor Tech Report 2011-12-001. -December 1, 2011. -<a href="techreports/five-ways-test-bridge-reachability-2011-12-01.pdf">PDF</a>.</p> - -<p>Sebastian Hahn. -<i>Different Ways to Use a Bridge.</i> -Tor Tech Report 2011-11-002. -November 29, 2011. -<a href="techreports/different-ways-use-bridge-2011-11-29.pdf">PDF</a>.</p> - -<p>Steven J. Murdoch. -<i>Comparison of Tor Datagram Designs.</i> -Tor Tech Report 2011-11-001. -November 7, 2011. -<a href="techreports/datagram-comparison-2011-11-07.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Ten ways to discover Tor bridges.</i> -Tor Tech Report 2010-10-002. -October 31, 2011. -<a href="techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>An Analysis of Tor Bridge Stability—Making BridgeDB give out at -least one stable bridge per user.</i> -Tor Tech Report 2011-10-001. -October 31, 2011. -<a href="techreports/bridge-stability-2011-10-31.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Case study: Learning whether a Tor bridge is blocked by looking at its -aggregate usage statistics, Part one.</i> -Tor Tech Report 2011-09-002. -September 15, 2011. -<a href="techreports/blocking-2011-09-15.pdf">PDF</a>.</p> - -<p>George Danezis. -<i>An anomaly-based censorship-detection system for Tor.</i> -Tor Tech Report 2011-09-001. -September 9, 2011. -<a href="techreports/detector-2011-09-09.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Better guard rotation parameters.</i> -Tor Tech Report 2011-08-001. -August 20, 2011. -<a href="techreports/better-guard-rotation-parameters-2011-08-20.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>An Analysis of Tor Relay Stability.</i> -Tor Tech Report 2011-06-001. -June 30, 2011. -<a href="techreports/relay-stability-2011-06-30.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Strategies for getting more bridges.</i> -Tor Tech Report 2011-05-001. -May 13, 2011. -<a href="techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Overview of Statistical Data in the Tor Network.</i> -Tor Tech Report 2011-03-001. -March 14, 2011. -<a href="techreports/data-2011-03-14.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Measuring the safety of the Tor network.</i> -Tor Tech Report 2011-02-001. -February 5, 2011. -<a href="techreports/measuring-safety-tor-network-2011-02-001.pdf">PDF</a>.</p> - -<h3>2010</h3> -<br> - -<p>Karsten Loesing. -<i>Privacy-preserving Ways to Estimate the Number of Tor Users.</i> -Tor Tech Report 2010-11-001. -November 30, 2010. -<a href="techreports/countingusers-2010-11-30.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Adaptive throttling of Tor clients by entry guards.</i> -Tor Tech Report 2010-09-001. -September 19, 2010. -<a href="techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf">PDF</a>.</p> - -<h3>2009</h3> -<br> - -<p>Roger Dingledine and Steven J. Murdoch. -<i>Performance Improvements on Tor or, Why Tor is slow and what we're -going to do about it.</i> -Tor Tech Report 2009-11-001. -November 9, 2009. -<a href="techreports/performance-2009-11-09.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Comparison of GeoIP Databases for Tor.</i> -Tor Tech Report 2009-10-001. -October 23, 2009. -<a href="techreports/geoipdbcomp-2009-10-23.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Performance of Requests over the Tor Network.</i> -Tor Tech Report 2009-09-001. -September 22, 2009. -<a href="techreports/torperf-2009-09-22.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Reducing the Circuit Window Size in Tor.</i> -Tor Tech Report 2009-09-002. -September 20, 2009. -<a href="techreports/circwindow-2009-09-20.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Analysis of Circuit Queues in Tor.</i> -Tor Tech Report 2009-08-001. -August 25, 2009. -<a href="techreports/bufferstats-2009-08-25.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Measuring the Tor Network, Evaluation of Client Requests to the -Directories to determine total numbers and countries of users.</i> -Tor Tech Report 2009-06-002. -June 25, 2009. -<a href="techreports/directory-requests-2009-06-25.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Analysis of Bridge Usage in Tor.</i> -Tor Tech Report 2009-06-003. -June 22, 2009. -<a href="techreports/bridges-2009-06-22.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Measuring the Tor Network, Evaluation of Relays from Public Directory -Data.</i> -Tor Tech Report 2009-06-001. -June 22, 2009. -<a href="techreports/dirarch-2009-06-22.pdf">PDF</a>.</p> - -<p>Sebastian Hahn, Karsten Loesing, and Steven J. Murdoch. -<i>Measuring the Tor Network, Simulation of the number of Fast, Stable, -and Guard flags for changed requirements.</i> -Tor Tech Report 2009-04-001. -April 11, 2009. -<a href="techreports/flagrequirements-2009-04-11.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Overhead from directory info: past, present, future.</i> -Tor Tech Report 2009-02-001. -February 16, 2009. -<a href="techreports/overhead-directory-info-2009-02-16.pdf">PDF</a>.</p> - -<h3>2006</h3> -<br> - -<p>Roger Dingledine and Nick Mathewson. -<i>Design of a blocking-resistant anonymity system.</i> -Tor Tech Report 2006-11-001. -November 2006. -<a href="techreports/blocking-2006-11.pdf">PDF</a>.</p> - -<h3>2005</h3> -<br> - -<p>Roger Dingledine, Nick Mathewson, and Paul Syverson. -<i>Challenges in deploying low-latency anonymity.</i> -Tor Tech Report 2005-02-001. -February 2005. -<a href="techreports/challenges-2005-02.pdf">PDF</a>.</p> - -</div> -</div> -</body> -</html> - diff --git a/techreports-footer.html b/techreports-footer.html new file mode 100644 index 0000000..eb54656 --- /dev/null +++ b/techreports-footer.html @@ -0,0 +1,5 @@ +</div> +</div> +</body> +</html> + diff --git a/techreports-header.html b/techreports-header.html new file mode 100644 index 0000000..96f72e7 --- /dev/null +++ b/techreports-header.html @@ -0,0 +1,30 @@ +<html> +<head> +<title>Tor Tech Reports</title> +<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> +<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> +<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> +</head> +<body> + +<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> +<tr> + <td class="banner-left"> + <a href="index.html"> + <img src="/images/top-left.png" alt="Click to go to home page" + width="193" height="79"></a></td> + <td class="banner-middle"> + <a href="index.html">Home</a> + <a href="groups.html">Groups</a> + <a href="ideas.html">Ideas</a> + Tech Reports + </td> + <td class="banner-right"></td> +</tr> +</table> + +<div class="center"> +<div class="main-column"> +<h2>Tor Tech Reports</h2> +<br> + diff --git a/techreports.bib b/techreports.bib new file mode 100644 index 0000000..f8c2d9b --- /dev/null +++ b/techreports.bib @@ -0,0 +1,310 @@ +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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-001.pdf}, +} + +@techreport{tor-2010-11-001, + author = {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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} +

1 0

[research-web/master] Move everything to htdocs/ subdirectory.
by karsten＠torproject.org 04 Sep '12

04 Sep '12

commit ee648b57069610a437c2d149dff802dd50fde4c4 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Sep 4 15:18:27 2012 -0400 Move everything to htdocs/ subdirectory. We'll soon have scripts to automatically generate techreports.html from a BibTeX file, and we don't the webserver to serve those scripts. --- .gitignore | 2 +- css/stylesheet-ltr.css | 161 --------------------------- groups.html | 57 ---------- htdocs/css/stylesheet-ltr.css | 161 +++++++++++++++++++++++++++ htdocs/groups.html | 57 ++++++++++ htdocs/ideas.html | 116 +++++++++++++++++++ htdocs/images/favicon.ico | Bin 0 -> 1150 bytes htdocs/images/top-left.png | Bin 0 -> 11039 bytes htdocs/images/top-middle.png | Bin 0 -> 257 bytes htdocs/images/top-right.png | Bin 0 -> 462 bytes htdocs/index.html | 132 ++++++++++++++++++++++ htdocs/techreports.html | 246 +++++++++++++++++++++++++++++++++++++++++ ideas.html | 116 ------------------- images/favicon.ico | Bin 1150 -> 0 bytes images/top-left.png | Bin 11039 -> 0 bytes images/top-middle.png | Bin 257 -> 0 bytes images/top-right.png | Bin 462 -> 0 bytes index.html | 132 ---------------------- techreports.html | 246 ----------------------------------------- 19 files changed, 713 insertions(+), 713 deletions(-) diff --git a/.gitignore b/.gitignore index b163bd2..9f9f5bf 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,2 @@ -techreports/ +htdocs/techreports/*.pdf diff --git a/css/stylesheet-ltr.css b/css/stylesheet-ltr.css deleted file mode 100644 index ce0c54e..0000000 --- a/css/stylesheet-ltr.css +++ /dev/null @@ -1,161 +0,0 @@ -body { - background-color: white; - margin-top: 0px; - font-family: Arial, Helvetica, sans-serif; - font-size: 1em; - font-style: normal; - color: #000000; - padding-top: 0px; -} - -/* images */ - -img { - border: 0; -} - - -li { - margin: .2em .2em .2em 1em; -} - -/* this centers the page */ - -.center { - text-align: center; - background-color: white; - margin: 0px auto 0 auto; - width: 85%; -} - -.center table { - margin-left: auto; - margin-right: auto; - text-align: left; -} - -div.bottom { - font-size: 0.8em; - margin-top: 0.5cm; - margin-left: 1em; - margin-right: 1em; - text-align: center; -} - -/* The main column (left text) */ - -div.main-column { - padding: 15px 0 10px 10px; - text-indent: 0pt; - font-size: 1em; - direction: ltr; - text-align: left; -} - -/* formatting styles */ - -h2 { - font-size: 1.4em; - margin-bottom: 0em; - font-weight: bold; - margin-top: 0; -} - -h3 { - font-size: 1.2em; - margin-bottom: 0em; - font-weight: bold; - margin-top: 0; -} - -p { - margin-top: 0; - margin-bottom: 1em; -} - -a:link { - color: blue; - font-size: 1em; -} - -a:visited { - color: purple; - font-size: 1em; -} - -a.anchor { - font-size: 1em; - color: black; - font-weight: bold; - text-decoration: none; -} - -td { - vertical-align: top; -} - -/* the banner */ - -table.banner { - width: 100%; - height: 79px; - margin-left: auto; - margin-right: auto; -} - -td.banner-left { - /* This is done with an <img> in the HTML so it can be clickable - background-image: url("images/top-left.png"); - background-repeat: no-repeat; */ - width: 193px; -} - -td.banner-middle { - background-color: #00802B; - background-image: url("/images/top-middle.png"); - background-repeat: repeat-x; - vertical-align: bottom; - padding-bottom: 10px; - color: white; - font-weight: bold; - font-size: 1.2em; -} - -td.banner-middle a, td.banner-middle a:visited { - margin-right: 5px; - color: white; - font-weight: bold; - font-size: 1em; -} - -td.banner-middle a:hover { - color: #FF7F00; - font-weight: bold; - font-size: 1em; -} - -td.banner-right { - background-image: url("/images/top-right.png"); - background-repeat: no-repeat; - width: 15px; - background-position: right; - padding-top: 8px; -} - -.banner-middle a.current { - text-decoration: none; - color: #FF7F00; - font-weight: bold; - font-size: 1em; - width: auto; - left: -50px; -} - -hr { - background-color:#002200; - color:#666666; - font-size:1px; - height:1px; - line-height:0; - margin:15px 0 5px; -} diff --git a/groups.html b/groups.html deleted file mode 100644 index a923d6d..0000000 --- a/groups.html +++ /dev/null @@ -1,57 +0,0 @@ -<html> -<head> -<title>Tor Research: Research Groups</title> -<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> -<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> -<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> -</head> -<body> - -<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> -<tr> - <td class="banner-left"> - <a href="index.html"> - <img src="/images/top-left.png" alt="Click to go to home page" - width="193" height="79"></a></td> - <td class="banner-middle"> - <a href="index.html">Home</a> - Groups - <a href="ideas.html">Ideas</a> - <a href="techreports.html">Tech Reports</a> - </td> - <td class="banner-right"></td> -</tr> -</table> - -<div class="center"> -<div class="main-column"> -<h2>Research Groups</h2> -<br> - -<p>Interested to find other anonymity researchers? Here are some -research groups you should take a look at.</p> - -<ul> -<li>Ian Goldberg's <a href="http://crysp.uwaterloo.ca/">CrySP</a> group -at Waterloo. -</li> -<li><a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>'s -group at UMN. -</li> -<li><a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>'s -group at Illinois. -</li> -<li>Micah Sherr's <a href="https://security.cs.georgetown.edu/">SecLab</a> -group at Georgetown. -</li> -<li>Matt Wright's <a href="http://isec.uta.edu/">iSec</a> group at -UTA. -</li> -</ul> - -</div> -</div> - -</body> -</html> - diff --git a/htdocs/css/stylesheet-ltr.css b/htdocs/css/stylesheet-ltr.css new file mode 100644 index 0000000..ce0c54e --- /dev/null +++ b/htdocs/css/stylesheet-ltr.css @@ -0,0 +1,161 @@ +body { + background-color: white; + margin-top: 0px; + font-family: Arial, Helvetica, sans-serif; + font-size: 1em; + font-style: normal; + color: #000000; + padding-top: 0px; +} + +/* images */ + +img { + border: 0; +} + + +li { + margin: .2em .2em .2em 1em; +} + +/* this centers the page */ + +.center { + text-align: center; + background-color: white; + margin: 0px auto 0 auto; + width: 85%; +} + +.center table { + margin-left: auto; + margin-right: auto; + text-align: left; +} + +div.bottom { + font-size: 0.8em; + margin-top: 0.5cm; + margin-left: 1em; + margin-right: 1em; + text-align: center; +} + +/* The main column (left text) */ + +div.main-column { + padding: 15px 0 10px 10px; + text-indent: 0pt; + font-size: 1em; + direction: ltr; + text-align: left; +} + +/* formatting styles */ + +h2 { + font-size: 1.4em; + margin-bottom: 0em; + font-weight: bold; + margin-top: 0; +} + +h3 { + font-size: 1.2em; + margin-bottom: 0em; + font-weight: bold; + margin-top: 0; +} + +p { + margin-top: 0; + margin-bottom: 1em; +} + +a:link { + color: blue; + font-size: 1em; +} + +a:visited { + color: purple; + font-size: 1em; +} + +a.anchor { + font-size: 1em; + color: black; + font-weight: bold; + text-decoration: none; +} + +td { + vertical-align: top; +} + +/* the banner */ + +table.banner { + width: 100%; + height: 79px; + margin-left: auto; + margin-right: auto; +} + +td.banner-left { + /* This is done with an <img> in the HTML so it can be clickable + background-image: url("images/top-left.png"); + background-repeat: no-repeat; */ + width: 193px; +} + +td.banner-middle { + background-color: #00802B; + background-image: url("/images/top-middle.png"); + background-repeat: repeat-x; + vertical-align: bottom; + padding-bottom: 10px; + color: white; + font-weight: bold; + font-size: 1.2em; +} + +td.banner-middle a, td.banner-middle a:visited { + margin-right: 5px; + color: white; + font-weight: bold; + font-size: 1em; +} + +td.banner-middle a:hover { + color: #FF7F00; + font-weight: bold; + font-size: 1em; +} + +td.banner-right { + background-image: url("/images/top-right.png"); + background-repeat: no-repeat; + width: 15px; + background-position: right; + padding-top: 8px; +} + +.banner-middle a.current { + text-decoration: none; + color: #FF7F00; + font-weight: bold; + font-size: 1em; + width: auto; + left: -50px; +} + +hr { + background-color:#002200; + color:#666666; + font-size:1px; + height:1px; + line-height:0; + margin:15px 0 5px; +} diff --git a/htdocs/groups.html b/htdocs/groups.html new file mode 100644 index 0000000..a923d6d --- /dev/null +++ b/htdocs/groups.html @@ -0,0 +1,57 @@ +<html> +<head> +<title>Tor Research: Research Groups</title> +<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> +<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> +<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> +</head> +<body> + +<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> +<tr> + <td class="banner-left"> + <a href="index.html"> + <img src="/images/top-left.png" alt="Click to go to home page" + width="193" height="79"></a></td> + <td class="banner-middle"> + <a href="index.html">Home</a> + Groups + <a href="ideas.html">Ideas</a> + <a href="techreports.html">Tech Reports</a> + </td> + <td class="banner-right"></td> +</tr> +</table> + +<div class="center"> +<div class="main-column"> +<h2>Research Groups</h2> +<br> + +<p>Interested to find other anonymity researchers? Here are some +research groups you should take a look at.</p> + +<ul> +<li>Ian Goldberg's <a href="http://crysp.uwaterloo.ca/">CrySP</a> group +at Waterloo. +</li> +<li><a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>'s +group at UMN. +</li> +<li><a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>'s +group at Illinois. +</li> +<li>Micah Sherr's <a href="https://security.cs.georgetown.edu/">SecLab</a> +group at Georgetown. +</li> +<li>Matt Wright's <a href="http://isec.uta.edu/">iSec</a> group at +UTA. +</li> +</ul> + +</div> +</div> + +</body> +</html> + diff --git a/htdocs/ideas.html b/htdocs/ideas.html new file mode 100644 index 0000000..904ddaa --- /dev/null +++ b/htdocs/ideas.html @@ -0,0 +1,116 @@ +<html> +<head> +<title>Tor Research: Research Ideas</title> +<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> +<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> +<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> +</head> +<body> + +<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> +<tr> + <td class="banner-left"> + <a href="index.html"> + <img src="/images/top-left.png" alt="Click to go to home page" + width="193" height="79"></a></td> + <td class="banner-middle"> + <a href="index.html">Home</a> + <a href="groups.html">Groups</a> + Ideas + <a href="techreports.html">Tech Reports</a> + </td> + <td class="banner-right"></td> +</tr> +</table> + +<div class="center"> +<div class="main-column"> +<h2>Research Ideas</h2> +<br> + +<p>We need people to attack the system, quantify defenses, +etc. Here are some example projects:</p> + +<ul> + +<li>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 +<a href="https://blog.torproject.org/research-problem-better-guard-rotation-paramete…">blog +post</a> for details. +</li> + +<li>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 <a +href="https://blog.torproject.org/research-problem-measuring-safety-tor-network">blog post</a> +for details. +</li> + +<li>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 <a +href="https://blog.torproject.org/research-problem-adaptive-throttling-tor-client…">blog +post</a> for details. +</li> + +<li>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. +</li> + +<li>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 <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive +dropping</a>, 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?</li> + + + +<li>More coming soon. See also the "Research" section of the <a +href="https://www.torproject.org/getinvolved/volunteer.html.en#Research">volunteer</a> page for +other topics. +</li> + +</ul> + +</div> +</div> + +</body> +</html> + diff --git a/htdocs/images/favicon.ico b/htdocs/images/favicon.ico new file mode 100644 index 0000000..48060b1 Binary files /dev/null and b/htdocs/images/favicon.ico differ diff --git a/htdocs/images/top-left.png b/htdocs/images/top-left.png new file mode 100644 index 0000000..050adb4 Binary files /dev/null and b/htdocs/images/top-left.png differ diff --git a/htdocs/images/top-middle.png b/htdocs/images/top-middle.png new file mode 100644 index 0000000..fa612d8 Binary files /dev/null and b/htdocs/images/top-middle.png differ diff --git a/htdocs/images/top-right.png b/htdocs/images/top-right.png new file mode 100644 index 0000000..8eaa644 Binary files /dev/null and b/htdocs/images/top-right.png differ diff --git a/htdocs/index.html b/htdocs/index.html new file mode 100644 index 0000000..4f77d2a --- /dev/null +++ b/htdocs/index.html @@ -0,0 +1,132 @@ +<html> +<head> +<title>Tor Research Home</title> +<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> +<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> +<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> +</head> +<body> + +<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> +<tr> + <td class="banner-left"> + <a href="index.html"> + <img src="/images/top-left.png" alt="Click to go to home page" + width="193" height="79"></a></td> + <td class="banner-middle"> + Home + <a href="groups.html">Groups</a> + <a href="ideas.html">Ideas</a> + <a href="techreports.html">Tech Reports</a> + </td> + <td class="banner-right"></td> +</tr> +</table> + +<div class="center"> +<div class="main-column"> +<h2>Tor Research Home</h2> +<br> + +<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. +The best way to reach us about research is through the +<a href="mailto:tor-assistants@lists.torproject.org">tor-assistants</a> +list.</p> + +<ul> + +<li> +<b>Data.</b> +We've been <a href="https://metrics.torproject.org/data.html">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 +<a href="https://metrics.torproject.org/graphs.html">useful +statistics</a>. +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="papers/wecsr10.pdf">safely</a> +and robustly. +</li> + +<li> +<b>Analysis.</b> +If you're investigating Tor, or solving a Tor-related problem, +<i>_please_</i> 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> +<b>Measurement and attack tools.</b> +We're building a +<a href="https://metrics.torproject.org/tools.html">repository</a> 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> +<b>We need defenses too — not just attacks.</b> +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> +<b>In-person help.</b> +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="http://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="http://freehaven.net/anonbib/">these papers</a> (especially the +ones in boxes). +We also keep a list of <a href="techreports.html">Tor Tech Reports</a> +that are (co-)authored by Tor developers.</p> + +</div> +</div> + +</body> +</html> + diff --git a/htdocs/techreports.html b/htdocs/techreports.html new file mode 100644 index 0000000..b249c33 --- /dev/null +++ b/htdocs/techreports.html @@ -0,0 +1,246 @@ +<html> +<head> +<title>Tor Tech Reports</title> +<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> +<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> +<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> +</head> +<body> + +<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> +<tr> + <td class="banner-left"> + <a href="index.html"> + <img src="/images/top-left.png" alt="Click to go to home page" + width="193" height="79"></a></td> + <td class="banner-middle"> + <a href="index.html">Home</a> + <a href="groups.html">Groups</a> + <a href="ideas.html">Ideas</a> + Tech Reports + </td> + <td class="banner-right"></td> +</tr> +</table> + +<div class="center"> +<div class="main-column"> +<h2>Tor Tech Reports</h2> +<br> + +<h3>2012</h3> +<br> + +<p>Jacob Appelbaum. +<i>Tor and NAT devices: increasing bridge & relay reachability or, +enabling the use of NAT-PMP and UPnP by default.</i> +Tor Tech Report 2012-08-001. +August 22, 2012. +<a href="techreports/tor-nat-plan-2012-08-22.pdf">PDF</a>.</p> + +<p>Steven J. Murdoch and George Kadianakis. +<i>Pluggable Transports Roadmap.</i> +Tor Tech Report 2012-03-003. +March 17, 2012. +<a href="techreports/pluggable-roadmap-2012-03-17.pdf">PDF</a>.</p> + +<p>Steven J. Murdoch. +<i>Datagram Testing Plan.</i> +Tor Tech Report 2012-03-002. +March 16, 2012. +<a href="techreports/datagram-testing-plan-2012-03-16.pdf">PDF</a>.</p> + +<p>George Kadianakis. +<i>Packet Size Pluggable Transport and Traffic Morphing.</i> +Tor Tech Report 2012-03-004. +March 13, 2012. +<a href="techreports/morpher-2012-03-13.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>What if the Tor network had 50,000 bridges?</i> +Tor Tech Report 2012-03-001. +March 9, 2012. +<a href="techreports/bridge-scaling-2012-03-09.pdf">PDF</a>.</p> + +<h3>2011</h3> +<br> + +<p>Roger Dingledine. +<i>Five ways to test bridge reachability.</i> +Tor Tech Report 2011-12-001. +December 1, 2011. +<a href="techreports/five-ways-test-bridge-reachability-2011-12-01.pdf">PDF</a>.</p> + +<p>Sebastian Hahn. +<i>Different Ways to Use a Bridge.</i> +Tor Tech Report 2011-11-002. +November 29, 2011. +<a href="techreports/different-ways-use-bridge-2011-11-29.pdf">PDF</a>.</p> + +<p>Steven J. Murdoch. +<i>Comparison of Tor Datagram Designs.</i> +Tor Tech Report 2011-11-001. +November 7, 2011. +<a href="techreports/datagram-comparison-2011-11-07.pdf">PDF</a>.</p> + +<p>Roger Dingledine. +<i>Ten ways to discover Tor bridges.</i> +Tor Tech Report 2010-10-002. +October 31, 2011. +<a href="techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>An Analysis of Tor Bridge Stability—Making BridgeDB give out at +least one stable bridge per user.</i> +Tor Tech Report 2011-10-001. +October 31, 2011. +<a href="techreports/bridge-stability-2011-10-31.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>Case study: Learning whether a Tor bridge is blocked by looking at its +aggregate usage statistics, Part one.</i> +Tor Tech Report 2011-09-002. +September 15, 2011. +<a href="techreports/blocking-2011-09-15.pdf">PDF</a>.</p> + +<p>George Danezis. +<i>An anomaly-based censorship-detection system for Tor.</i> +Tor Tech Report 2011-09-001. +September 9, 2011. +<a href="techreports/detector-2011-09-09.pdf">PDF</a>.</p> + +<p>Roger Dingledine. +<i>Better guard rotation parameters.</i> +Tor Tech Report 2011-08-001. +August 20, 2011. +<a href="techreports/better-guard-rotation-parameters-2011-08-20.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>An Analysis of Tor Relay Stability.</i> +Tor Tech Report 2011-06-001. +June 30, 2011. +<a href="techreports/relay-stability-2011-06-30.pdf">PDF</a>.</p> + +<p>Roger Dingledine. +<i>Strategies for getting more bridges.</i> +Tor Tech Report 2011-05-001. +May 13, 2011. +<a href="techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>Overview of Statistical Data in the Tor Network.</i> +Tor Tech Report 2011-03-001. +March 14, 2011. +<a href="techreports/data-2011-03-14.pdf">PDF</a>.</p> + +<p>Roger Dingledine. +<i>Measuring the safety of the Tor network.</i> +Tor Tech Report 2011-02-001. +February 5, 2011. +<a href="techreports/measuring-safety-tor-network-2011-02-001.pdf">PDF</a>.</p> + +<h3>2010</h3> +<br> + +<p>Karsten Loesing. +<i>Privacy-preserving Ways to Estimate the Number of Tor Users.</i> +Tor Tech Report 2010-11-001. +November 30, 2010. +<a href="techreports/countingusers-2010-11-30.pdf">PDF</a>.</p> + +<p>Roger Dingledine. +<i>Adaptive throttling of Tor clients by entry guards.</i> +Tor Tech Report 2010-09-001. +September 19, 2010. +<a href="techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf">PDF</a>.</p> + +<h3>2009</h3> +<br> + +<p>Roger Dingledine and Steven J. Murdoch. +<i>Performance Improvements on Tor or, Why Tor is slow and what we're +going to do about it.</i> +Tor Tech Report 2009-11-001. +November 9, 2009. +<a href="techreports/performance-2009-11-09.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>Comparison of GeoIP Databases for Tor.</i> +Tor Tech Report 2009-10-001. +October 23, 2009. +<a href="techreports/geoipdbcomp-2009-10-23.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>Performance of Requests over the Tor Network.</i> +Tor Tech Report 2009-09-001. +September 22, 2009. +<a href="techreports/torperf-2009-09-22.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>Reducing the Circuit Window Size in Tor.</i> +Tor Tech Report 2009-09-002. +September 20, 2009. +<a href="techreports/circwindow-2009-09-20.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>Analysis of Circuit Queues in Tor.</i> +Tor Tech Report 2009-08-001. +August 25, 2009. +<a href="techreports/bufferstats-2009-08-25.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>Measuring the Tor Network, Evaluation of Client Requests to the +Directories to determine total numbers and countries of users.</i> +Tor Tech Report 2009-06-002. +June 25, 2009. +<a href="techreports/directory-requests-2009-06-25.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>Analysis of Bridge Usage in Tor.</i> +Tor Tech Report 2009-06-003. +June 22, 2009. +<a href="techreports/bridges-2009-06-22.pdf">PDF</a>.</p> + +<p>Karsten Loesing. +<i>Measuring the Tor Network, Evaluation of Relays from Public Directory +Data.</i> +Tor Tech Report 2009-06-001. +June 22, 2009. +<a href="techreports/dirarch-2009-06-22.pdf">PDF</a>.</p> + +<p>Sebastian Hahn, Karsten Loesing, and Steven J. Murdoch. +<i>Measuring the Tor Network, Simulation of the number of Fast, Stable, +and Guard flags for changed requirements.</i> +Tor Tech Report 2009-04-001. +April 11, 2009. +<a href="techreports/flagrequirements-2009-04-11.pdf">PDF</a>.</p> + +<p>Roger Dingledine. +<i>Overhead from directory info: past, present, future.</i> +Tor Tech Report 2009-02-001. +February 16, 2009. +<a href="techreports/overhead-directory-info-2009-02-16.pdf">PDF</a>.</p> + +<h3>2006</h3> +<br> + +<p>Roger Dingledine and Nick Mathewson. +<i>Design of a blocking-resistant anonymity system.</i> +Tor Tech Report 2006-11-001. +November 2006. +<a href="techreports/blocking-2006-11.pdf">PDF</a>.</p> + +<h3>2005</h3> +<br> + +<p>Roger Dingledine, Nick Mathewson, and Paul Syverson. +<i>Challenges in deploying low-latency anonymity.</i> +Tor Tech Report 2005-02-001. +February 2005. +<a href="techreports/challenges-2005-02.pdf">PDF</a>.</p> + +</div> +</div> +</body> +</html> + diff --git a/ideas.html b/ideas.html deleted file mode 100644 index 904ddaa..0000000 --- a/ideas.html +++ /dev/null @@ -1,116 +0,0 @@ -<html> -<head> -<title>Tor Research: Research Ideas</title> -<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> -<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> -<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> -</head> -<body> - -<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> -<tr> - <td class="banner-left"> - <a href="index.html"> - <img src="/images/top-left.png" alt="Click to go to home page" - width="193" height="79"></a></td> - <td class="banner-middle"> - <a href="index.html">Home</a> - <a href="groups.html">Groups</a> - Ideas - <a href="techreports.html">Tech Reports</a> - </td> - <td class="banner-right"></td> -</tr> -</table> - -<div class="center"> -<div class="main-column"> -<h2>Research Ideas</h2> -<br> - -<p>We need people to attack the system, quantify defenses, -etc. Here are some example projects:</p> - -<ul> - -<li>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 -<a href="https://blog.torproject.org/research-problem-better-guard-rotation-paramete…">blog -post</a> for details. -</li> - -<li>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 <a -href="https://blog.torproject.org/research-problem-measuring-safety-tor-network">blog post</a> -for details. -</li> - -<li>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 <a -href="https://blog.torproject.org/research-problem-adaptive-throttling-tor-client…">blog -post</a> for details. -</li> - -<li>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. -</li> - -<li>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 <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive -dropping</a>, 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?</li> - - - -<li>More coming soon. See also the "Research" section of the <a -href="https://www.torproject.org/getinvolved/volunteer.html.en#Research">volunteer</a> page for -other topics. -</li> - -</ul> - -</div> -</div> - -</body> -</html> - diff --git a/images/favicon.ico b/images/favicon.ico deleted file mode 100644 index 48060b1..0000000 Binary files a/images/favicon.ico and /dev/null differ diff --git a/images/top-left.png b/images/top-left.png deleted file mode 100644 index 050adb4..0000000 Binary files a/images/top-left.png and /dev/null differ diff --git a/images/top-middle.png b/images/top-middle.png deleted file mode 100644 index fa612d8..0000000 Binary files a/images/top-middle.png and /dev/null differ diff --git a/images/top-right.png b/images/top-right.png deleted file mode 100644 index 8eaa644..0000000 Binary files a/images/top-right.png and /dev/null differ diff --git a/index.html b/index.html deleted file mode 100644 index 4f77d2a..0000000 --- a/index.html +++ /dev/null @@ -1,132 +0,0 @@ -<html> -<head> -<title>Tor Research Home</title> -<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> -<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> -<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> -</head> -<body> - -<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> -<tr> - <td class="banner-left"> - <a href="index.html"> - <img src="/images/top-left.png" alt="Click to go to home page" - width="193" height="79"></a></td> - <td class="banner-middle"> - Home - <a href="groups.html">Groups</a> - <a href="ideas.html">Ideas</a> - <a href="techreports.html">Tech Reports</a> - </td> - <td class="banner-right"></td> -</tr> -</table> - -<div class="center"> -<div class="main-column"> -<h2>Tor Research Home</h2> -<br> - -<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. -The best way to reach us about research is through the -<a href="mailto:tor-assistants@lists.torproject.org">tor-assistants</a> -list.</p> - -<ul> - -<li> -<b>Data.</b> -We've been <a href="https://metrics.torproject.org/data.html">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 -<a href="https://metrics.torproject.org/graphs.html">useful -statistics</a>. -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="papers/wecsr10.pdf">safely</a> -and robustly. -</li> - -<li> -<b>Analysis.</b> -If you're investigating Tor, or solving a Tor-related problem, -<i>_please_</i> 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> -<b>Measurement and attack tools.</b> -We're building a -<a href="https://metrics.torproject.org/tools.html">repository</a> 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> -<b>We need defenses too — not just attacks.</b> -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> -<b>In-person help.</b> -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="http://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="http://freehaven.net/anonbib/">these papers</a> (especially the -ones in boxes). -We also keep a list of <a href="techreports.html">Tor Tech Reports</a> -that are (co-)authored by Tor developers.</p> - -</div> -</div> - -</body> -</html> - diff --git a/techreports.html b/techreports.html deleted file mode 100644 index b249c33..0000000 --- a/techreports.html +++ /dev/null @@ -1,246 +0,0 @@ -<html> -<head> -<title>Tor Tech Reports</title> -<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> -<link href="css/stylesheet-ltr.css" type="text/css" rel="stylesheet"> -<link href="/images/favicon.ico" type="image/x-icon" rel="shortcut icon"> -</head> -<body> - -<table class="banner" border="0" cellpadding="0" cellspacing="0" summary=""> -<tr> - <td class="banner-left"> - <a href="index.html"> - <img src="/images/top-left.png" alt="Click to go to home page" - width="193" height="79"></a></td> - <td class="banner-middle"> - <a href="index.html">Home</a> - <a href="groups.html">Groups</a> - <a href="ideas.html">Ideas</a> - Tech Reports - </td> - <td class="banner-right"></td> -</tr> -</table> - -<div class="center"> -<div class="main-column"> -<h2>Tor Tech Reports</h2> -<br> - -<h3>2012</h3> -<br> - -<p>Jacob Appelbaum. -<i>Tor and NAT devices: increasing bridge & relay reachability or, -enabling the use of NAT-PMP and UPnP by default.</i> -Tor Tech Report 2012-08-001. -August 22, 2012. -<a href="techreports/tor-nat-plan-2012-08-22.pdf">PDF</a>.</p> - -<p>Steven J. Murdoch and George Kadianakis. -<i>Pluggable Transports Roadmap.</i> -Tor Tech Report 2012-03-003. -March 17, 2012. -<a href="techreports/pluggable-roadmap-2012-03-17.pdf">PDF</a>.</p> - -<p>Steven J. Murdoch. -<i>Datagram Testing Plan.</i> -Tor Tech Report 2012-03-002. -March 16, 2012. -<a href="techreports/datagram-testing-plan-2012-03-16.pdf">PDF</a>.</p> - -<p>George Kadianakis. -<i>Packet Size Pluggable Transport and Traffic Morphing.</i> -Tor Tech Report 2012-03-004. -March 13, 2012. -<a href="techreports/morpher-2012-03-13.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>What if the Tor network had 50,000 bridges?</i> -Tor Tech Report 2012-03-001. -March 9, 2012. -<a href="techreports/bridge-scaling-2012-03-09.pdf">PDF</a>.</p> - -<h3>2011</h3> -<br> - -<p>Roger Dingledine. -<i>Five ways to test bridge reachability.</i> -Tor Tech Report 2011-12-001. -December 1, 2011. -<a href="techreports/five-ways-test-bridge-reachability-2011-12-01.pdf">PDF</a>.</p> - -<p>Sebastian Hahn. -<i>Different Ways to Use a Bridge.</i> -Tor Tech Report 2011-11-002. -November 29, 2011. -<a href="techreports/different-ways-use-bridge-2011-11-29.pdf">PDF</a>.</p> - -<p>Steven J. Murdoch. -<i>Comparison of Tor Datagram Designs.</i> -Tor Tech Report 2011-11-001. -November 7, 2011. -<a href="techreports/datagram-comparison-2011-11-07.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Ten ways to discover Tor bridges.</i> -Tor Tech Report 2010-10-002. -October 31, 2011. -<a href="techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>An Analysis of Tor Bridge Stability—Making BridgeDB give out at -least one stable bridge per user.</i> -Tor Tech Report 2011-10-001. -October 31, 2011. -<a href="techreports/bridge-stability-2011-10-31.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Case study: Learning whether a Tor bridge is blocked by looking at its -aggregate usage statistics, Part one.</i> -Tor Tech Report 2011-09-002. -September 15, 2011. -<a href="techreports/blocking-2011-09-15.pdf">PDF</a>.</p> - -<p>George Danezis. -<i>An anomaly-based censorship-detection system for Tor.</i> -Tor Tech Report 2011-09-001. -September 9, 2011. -<a href="techreports/detector-2011-09-09.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Better guard rotation parameters.</i> -Tor Tech Report 2011-08-001. -August 20, 2011. -<a href="techreports/better-guard-rotation-parameters-2011-08-20.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>An Analysis of Tor Relay Stability.</i> -Tor Tech Report 2011-06-001. -June 30, 2011. -<a href="techreports/relay-stability-2011-06-30.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Strategies for getting more bridges.</i> -Tor Tech Report 2011-05-001. -May 13, 2011. -<a href="techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Overview of Statistical Data in the Tor Network.</i> -Tor Tech Report 2011-03-001. -March 14, 2011. -<a href="techreports/data-2011-03-14.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Measuring the safety of the Tor network.</i> -Tor Tech Report 2011-02-001. -February 5, 2011. -<a href="techreports/measuring-safety-tor-network-2011-02-001.pdf">PDF</a>.</p> - -<h3>2010</h3> -<br> - -<p>Karsten Loesing. -<i>Privacy-preserving Ways to Estimate the Number of Tor Users.</i> -Tor Tech Report 2010-11-001. -November 30, 2010. -<a href="techreports/countingusers-2010-11-30.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Adaptive throttling of Tor clients by entry guards.</i> -Tor Tech Report 2010-09-001. -September 19, 2010. -<a href="techreports/adaptive-throttling-tor-clients-entry-guards-2010-09-19.pdf">PDF</a>.</p> - -<h3>2009</h3> -<br> - -<p>Roger Dingledine and Steven J. Murdoch. -<i>Performance Improvements on Tor or, Why Tor is slow and what we're -going to do about it.</i> -Tor Tech Report 2009-11-001. -November 9, 2009. -<a href="techreports/performance-2009-11-09.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Comparison of GeoIP Databases for Tor.</i> -Tor Tech Report 2009-10-001. -October 23, 2009. -<a href="techreports/geoipdbcomp-2009-10-23.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Performance of Requests over the Tor Network.</i> -Tor Tech Report 2009-09-001. -September 22, 2009. -<a href="techreports/torperf-2009-09-22.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Reducing the Circuit Window Size in Tor.</i> -Tor Tech Report 2009-09-002. -September 20, 2009. -<a href="techreports/circwindow-2009-09-20.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Analysis of Circuit Queues in Tor.</i> -Tor Tech Report 2009-08-001. -August 25, 2009. -<a href="techreports/bufferstats-2009-08-25.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Measuring the Tor Network, Evaluation of Client Requests to the -Directories to determine total numbers and countries of users.</i> -Tor Tech Report 2009-06-002. -June 25, 2009. -<a href="techreports/directory-requests-2009-06-25.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Analysis of Bridge Usage in Tor.</i> -Tor Tech Report 2009-06-003. -June 22, 2009. -<a href="techreports/bridges-2009-06-22.pdf">PDF</a>.</p> - -<p>Karsten Loesing. -<i>Measuring the Tor Network, Evaluation of Relays from Public Directory -Data.</i> -Tor Tech Report 2009-06-001. -June 22, 2009. -<a href="techreports/dirarch-2009-06-22.pdf">PDF</a>.</p> - -<p>Sebastian Hahn, Karsten Loesing, and Steven J. Murdoch. -<i>Measuring the Tor Network, Simulation of the number of Fast, Stable, -and Guard flags for changed requirements.</i> -Tor Tech Report 2009-04-001. -April 11, 2009. -<a href="techreports/flagrequirements-2009-04-11.pdf">PDF</a>.</p> - -<p>Roger Dingledine. -<i>Overhead from directory info: past, present, future.</i> -Tor Tech Report 2009-02-001. -February 16, 2009. -<a href="techreports/overhead-directory-info-2009-02-16.pdf">PDF</a>.</p> - -<h3>2006</h3> -<br> - -<p>Roger Dingledine and Nick Mathewson. -<i>Design of a blocking-resistant anonymity system.</i> -Tor Tech Report 2006-11-001. -November 2006. -<a href="techreports/blocking-2006-11.pdf">PDF</a>.</p> - -<h3>2005</h3> -<br> - -<p>Roger Dingledine, Nick Mathewson, and Paul Syverson. -<i>Challenges in deploying low-latency anonymity.</i> -Tor Tech Report 2005-02-001. -February 2005. -<a href="techreports/challenges-2005-02.pdf">PDF</a>.</p> - -</div> -</div> -</body> -</html> -

1 0

[tor-cloud/master] build with ubuntu precise next time
by runa＠torproject.org 04 Sep '12

04 Sep '12

commit 487c3f13204e6cbb07d084183ba1d6556d60fad6 Author: Runa A. Sandvik <runa.sandvik(a)gmail.com> Date: Tue Sep 4 20:46:45 2012 +0100 build with ubuntu precise next time --- build.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/build.sh b/build.sh index cbf2c74..26c7e79 100755 --- a/build.sh +++ b/build.sh @@ -49,7 +49,7 @@ fi echo ${region} echo ${arch} -qurl=https://uec-images.ubuntu.com/query/lucid/server/released.current.txt +qurl=https://uec-images.ubuntu.com/query/precise/server/released.current.txt curl --silent ${qurl} | grep ebs ami=$(curl --silent "${qurl}" | awk '-F\t' '$5 == "ebs" && $6 == arch && $7 == region { print $8 }' arch=$arch region=$region ) aki=$(curl --silent "${qurl}" | awk '-F\t' '$5 == "ebs" && $6 == arch && $7 == region { print $9 }' arch=$arch region=$region )

1 0

[tor/master] Remove trailing semicolon from #define TOR_ADDR_NULL.
by nickm＠torproject.org 04 Sep '12

04 Sep '12

commit 730dd9a6d0c84afb981818652c41cf14b881a2db Author: Linus Nordberg <linus(a)torproject.org> Date: Fri Aug 31 23:02:19 2012 +0200 Remove trailing semicolon from #define TOR_ADDR_NULL. Can it ever help? I can only see harm. What am I missing? --- src/common/address.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/common/address.h b/src/common/address.h index c6c1268..e0e1ec6 100644 --- a/src/common/address.h +++ b/src/common/address.h @@ -40,7 +40,7 @@ typedef struct tor_addr_port_t uint16_t port; } tor_addr_port_t; -#define TOR_ADDR_NULL {AF_UNSPEC, {0}}; +#define TOR_ADDR_NULL {AF_UNSPEC, {0}} static INLINE const struct in6_addr *tor_addr_to_in6(const tor_addr_t *a); static INLINE uint32_t tor_addr_to_ipv4n(const tor_addr_t *a);

1 0

[tor/master] Clear the ipv6_preferred flag like the others.
by nickm＠torproject.org 04 Sep '12

04 Sep '12

commit d6ad00a01f703a79d9ca6d6edd958b4d05279b4e Author: Linus Nordberg <linus(a)torproject.org> Date: Fri Aug 31 23:02:19 2012 +0200 Clear the ipv6_preferred flag like the others. I'm not entirely sure that this is meningful but I'm pretty sure it's not harmful. Seems like the logical thing to do. --- src/or/nodelist.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/or/nodelist.c b/src/or/nodelist.c index b005d06..9d0247f 100644 --- a/src/or/nodelist.c +++ b/src/or/nodelist.c @@ -260,7 +260,8 @@ nodelist_set_consensus(networkstatus_t *ns) node->is_valid = node->is_running = node->is_hs_dir = node->is_fast = node->is_stable = node->is_possible_guard = node->is_exit = - node->is_bad_exit = node->is_bad_directory = 0; + node->is_bad_exit = node->is_bad_directory = + node->ipv6_preferred = 0; } } } SMARTLIST_FOREACH_END(node);

1 0

[tor/master] Fix a comment.
by nickm＠torproject.org 04 Sep '12

04 Sep '12

commit c76a332887c2f793fd66bd02accb05a7bb0d9f83 Author: Linus Nordberg <linus(a)torproject.org> Date: Fri Aug 31 23:02:19 2012 +0200 Fix a comment. --- src/or/nodelist.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/nodelist.c b/src/or/nodelist.c index 26f1593..b005d06 100644 --- a/src/or/nodelist.c +++ b/src/or/nodelist.c @@ -196,7 +196,7 @@ nodelist_add_microdesc(microdesc_t *md) return node; } -/** Tell the nodelist that the current usable consensus to <b>ns</b>. +/** Tell the nodelist that the current usable consensus is <b>ns</b>. * This makes the nodelist change all of the routerstatus entries for * the nodes, drop nodes that no longer have enough info to get used, * and grab microdescriptors into nodes as appropriate.

1 0

[torspec/master] Specify consensus method 14 adding "a" lines.
by nickm＠torproject.org 04 Sep '12

04 Sep '12

commit e2aafe87c793bd06d432701d207d70c7744ef6e2 Author: Linus Nordberg <linus(a)torproject.org> Date: Tue Aug 28 16:51:47 2012 +0200 Specify consensus method 14 adding "a" lines. --- dir-spec.txt | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 36b4328..65163bc 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1076,6 +1076,12 @@ The "onion-key" element as specified in 2.1. + "a" SP address ":" portlist NL + + [Any number] + + The "or-address" element as specified in 2.1. + "family" names NL [At most once] @@ -1354,6 +1360,18 @@ ORPort is its current OR port, "DirPort" is its current directory port, or "0" for "none". + "a" SP address ":" portlist NL + + [Any number.] + + Present only if the OR has at least one IPv6 address. + + Address and portlist are as for "or-address" as specified in + 2.1. + + (Only included when the vote or consensus is generated with + consensus-method 13 or later.) + "s" SP Flags NL [Exactly once.] @@ -1736,6 +1754,10 @@ * If consensus method 13 or later is used, microdesc consensuses omit any router for which no microdesc was agreed upon. + * If consensus method 14 or later is used, votes and + consensuses may include "a" lines listing additional OR + ports. + The signatures at the end of a consensus document are sorted in ascending order by identity digest. @@ -1764,6 +1786,7 @@ "11" -- Don't consider BadExits when calculating bandwidth weights "12" -- Params are only included if enough auths voted for them "13" -- Omit router entries with missing microdescriptors. + "14" -- Adds support for "a" lines. Before generating a consensus, an authority must decide which consensus

1 0

[torspec/master] Fix typo in prop 186.
by nickm＠torproject.org 04 Sep '12

04 Sep '12

commit be6b22fe287e9f63e265bba9d9ff7ac17a73364b Author: Linus Nordberg <linus(a)torproject.org> Date: Thu Jul 19 23:15:20 2012 +0200 Fix typo in prop 186. --- proposals/186-multiple-orports.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/186-multiple-orports.txt b/proposals/186-multiple-orports.txt index 926f92c..9a186e0 100644 --- a/proposals/186-multiple-orports.txt +++ b/proposals/186-multiple-orports.txt @@ -175,8 +175,8 @@ Consensus directories and microdescriptors: they shouldn't include any "a" lines.) The remaining or-address lines will turn into "a" lines in the microdescriptor. - As with other data in the vote derived from the descriptor, - the vote will include whichever set of "a" lines are given by the + As with other data in the vote derived from the descriptor, the + consensus will include whichever set of "a" lines are given by the most authorities who voted for the descriptor digest that will be used for the router.

1 0

[torspec/master] Fix a white space bug.
by nickm＠torproject.org 04 Sep '12

04 Sep '12

commit 91663ae537888e552103e6ddc269989790c27e4e Author: Linus Nordberg <linus(a)torproject.org> Date: Wed Aug 29 12:13:45 2012 +0200 Fix a white space bug. --- dir-spec.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 65163bc..39b48dd 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1076,7 +1076,7 @@ The "onion-key" element as specified in 2.1. - "a" SP address ":" portlist NL + "a" SP address ":" portlist NL [Any number]

1 0

[torspec/master] Fix a missing method 13->14 change.
by nickm＠torproject.org 04 Sep '12

04 Sep '12

commit 5ddddcb5b9d755eba70ecb0f409f1c5027fed5fe Author: Linus Nordberg <linus(a)torproject.org> Date: Wed Aug 29 13:13:03 2012 +0200 Fix a missing method 13->14 change. --- dir-spec.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 39b48dd..3f88eba 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1370,7 +1370,7 @@ 2.1. (Only included when the vote or consensus is generated with - consensus-method 13 or later.) + consensus-method 14 or later.) "s" SP Flags NL

1 0