- tor-commits - lists.torproject.org

[translation/vidalia] Update translations for vidalia
by translation＠torproject.org 25 Jul '12

25 Jul '12

commit f2545e37cadd0f67d1ffd776f274d5f27e0c2e44 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Jul 25 13:45:11 2012 +0000 Update translations for vidalia --- lt/qt_lt.po | 171 +++++++++++++++++++++++++++--------------------------- lt/vidalia_lt.po | 95 +++++++++++++++--------------- 2 files changed, 133 insertions(+), 133 deletions(-) diff --git a/lt/qt_lt.po b/lt/qt_lt.po index 64f7cdc..08dbbd1 100644 --- a/lt/qt_lt.po +++ b/lt/qt_lt.po @@ -1,12 +1,13 @@ -# # Translators: +# Translators: +# Gediminas Golcevas <>, 2012. msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2008-08-20 03:25+0000\n" -"PO-Revision-Date: 2010-12-05 19:59+0000\n" -"Last-Translator: Automatically generated\n" +"PO-Revision-Date: 2012-07-25 13:31+0000\n" +"Last-Translator: Gediminas Golcevas <>\n" "Language-Team: none\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -18,189 +19,189 @@ msgstr "" #: qaccessibleobject.cpp:348 msgctxt "QApplication" msgid "Activate" -msgstr "" +msgstr "Aktyvuoti" #: qmessagebox.h:319 msgctxt "QApplication" msgid "Executable '%1' requires Qt %2, found Qt %3." -msgstr "" +msgstr "Programai '%1' reikia Qt %2, rasta Qt %3." #: qmessagebox.h:321 msgctxt "QApplication" msgid "Incompatible Qt Library Error" -msgstr "" +msgstr "Nesuderinamos Qt bibliotekos klaida" #: qapplication.cpp:2095 msgctxt "QApplication" msgid "QT_LAYOUT_DIRECTION" -msgstr "" +msgstr "QT_LAYOUT_DIRECTION" #: qaccessibleobject.cpp:350 msgctxt "QApplication" msgid "Activates the program's main window" -msgstr "" +msgstr "Aktyvuoja pagrindinį programos langą" #: qmessagebox.cpp:2104 msgctxt "QDialogButtonBox" msgid "OK" -msgstr "" +msgstr "Gerai" #: qdialogbuttonbox.cpp:528 msgctxt "QDialogButtonBox" msgid "Save" -msgstr "" +msgstr "Įrašyti" #: qdialogbuttonbox.cpp:531 msgctxt "QDialogButtonBox" msgid "Open" -msgstr "" +msgstr "Atverti" #: qdialogbuttonbox.cpp:534 msgctxt "QDialogButtonBox" msgid "Cancel" -msgstr "" +msgstr "Atsisakyti" #: qdialogbuttonbox.cpp:537 msgctxt "QDialogButtonBox" msgid "Close" -msgstr "" +msgstr "Uždaryti" #: qdialogbuttonbox.cpp:540 msgctxt "QDialogButtonBox" msgid "Apply" -msgstr "" +msgstr "Taikyti" #: qdialogbuttonbox.cpp:543 msgctxt "QDialogButtonBox" msgid "Reset" -msgstr "" +msgstr "Atstatyti" #: qdialogbuttonbox.cpp:546 msgctxt "QDialogButtonBox" msgid "Help" -msgstr "" +msgstr "Pagalba" #: qdialogbuttonbox.cpp:550 msgctxt "QDialogButtonBox" msgid "Don't Save" -msgstr "" +msgstr "Neįrašyti" #: qdialogbuttonbox.cpp:554 msgctxt "QDialogButtonBox" msgid "Discard" -msgstr "" +msgstr "Atmesti pakeitimus" #: qdialogbuttonbox.cpp:557 msgctxt "QDialogButtonBox" msgid "&Yes" -msgstr "" +msgstr "&Taip" #: qdialogbuttonbox.cpp:560 msgctxt "QDialogButtonBox" msgid "Yes to &All" -msgstr "" +msgstr "&Visada taip" #: qdialogbuttonbox.cpp:563 msgctxt "QDialogButtonBox" msgid "&No" -msgstr "" +msgstr "&Ne" #: qdialogbuttonbox.cpp:566 msgctxt "QDialogButtonBox" msgid "N&o to All" -msgstr "" +msgstr "Visada n&e" #: qdialogbuttonbox.cpp:569 msgctxt "QDialogButtonBox" msgid "Save All" -msgstr "" +msgstr "Įrašyti viską" #: qdialogbuttonbox.cpp:572 msgctxt "QDialogButtonBox" msgid "Abort" -msgstr "" +msgstr "Nutraukti" #: qdialogbuttonbox.cpp:575 msgctxt "QDialogButtonBox" msgid "Retry" -msgstr "" +msgstr "Pakartoti" #: qdialogbuttonbox.cpp:578 msgctxt "QDialogButtonBox" msgid "Ignore" -msgstr "" +msgstr "Ignoruoti" #: qdialogbuttonbox.cpp:581 msgctxt "QDialogButtonBox" msgid "Restore Defaults" -msgstr "" +msgstr "Atstatyti numatytuosius" #: qdialogbuttonbox.cpp:552 msgctxt "QDialogButtonBox" msgid "Close without Saving" -msgstr "" +msgstr "Užverti neįrašant" #: qdialogbuttonbox.cpp:525 msgctxt "QDialogButtonBox" msgid "&OK" -msgstr "" +msgstr "&Gerai" #: qdirmodel.cpp:423 msgctxt "QDirModel" msgid "Name" -msgstr "" +msgstr "Pavadinimas" #: qdirmodel.cpp:424 msgctxt "QDirModel" msgid "Size" -msgstr "" +msgstr "Dydis" #: qdirmodel.cpp:427 msgctxt "QDirModel" msgid "Kind" -msgstr "" +msgstr "Rūšis" #: qdirmodel.cpp:429 msgctxt "QDirModel" msgid "Type" -msgstr "" +msgstr "Tipas" #: qdirmodel.cpp:435 msgctxt "QDirModel" msgid "Date Modified" -msgstr "" +msgstr "Pakeitimo data" #: qfiledialog_win.cpp:126 msgctxt "QFileDialog" msgid "All Files (*)" -msgstr "" +msgstr "Visi failai (*.*)" #: qfiledialog.cpp:881 msgctxt "QFileDialog" msgid "Directories" -msgstr "" +msgstr "Katalogai" #: qfiledialog.cpp:2408 msgctxt "QFileDialog" msgid "&Open" -msgstr "" +msgstr "&Atverti" #: qfiledialog.cpp:919 msgctxt "QFileDialog" msgid "&Save" -msgstr "" +msgstr "&Įrašyti" #: qfiledialog.cpp:435 msgctxt "QFileDialog" msgid "Open" -msgstr "" +msgstr "Atverti" #: qfiledialog.cpp:1670 msgctxt "QFileDialog" msgid "" "%1 already exists.\n" "Do you want to replace it?" -msgstr "" +msgstr "%1 jau egzistuoja.\nAr norite perrašyti?" #: qfiledialog.cpp:1690 msgctxt "QFileDialog" @@ -208,57 +209,57 @@ msgid "" "%1\n" "File not found.\n" "Please verify the correct file name was given." -msgstr "" +msgstr "Nepavyko rasti\n%1\nPrašome patikrinti ar įvedėte teisingą pavadinimą" #: qdirmodel.cpp:833 msgctxt "QFileDialog" msgid "My Computer" -msgstr "" +msgstr "Mano kompiuteris" #: qfiledialog.cpp:462 msgctxt "QFileDialog" msgid "&Rename" -msgstr "" +msgstr "&Pervardinti" #: qfiledialog.cpp:463 msgctxt "QFileDialog" msgid "&Delete" -msgstr "" +msgstr "&Pašalinti" #: qfiledialog.cpp:464 msgctxt "QFileDialog" msgid "Show &hidden files" -msgstr "" +msgstr "Rodyti &paslėptus failus" #: ui_qfiledialog.h:264 msgctxt "QFileDialog" msgid "Back" -msgstr "" +msgstr "Atgal" #: ui_qfiledialog.h:274 msgctxt "QFileDialog" msgid "Parent Directory" -msgstr "" +msgstr "Pagrindinis katalogas" #: ui_qfiledialog.h:284 msgctxt "QFileDialog" msgid "List View" -msgstr "" +msgstr "Sąrašo rodinys" #: ui_qfiledialog.h:289 msgctxt "QFileDialog" msgid "Detail View" -msgstr "" +msgstr "Detalus rodinys" #: ui_qfiledialog.h:292 msgctxt "QFileDialog" msgid "Files of type:" -msgstr "" +msgstr "Failų tipas:" #: qfiledialog.cpp:883 msgctxt "QFileDialog" msgid "Directory:" -msgstr "" +msgstr "Katalogas" #: qfiledialog.cpp:2476 msgctxt "QFileDialog" @@ -266,170 +267,168 @@ msgid "" "%1\n" "Directory not found.\n" "Please verify the correct directory name was given." -msgstr "" +msgstr "Nerastas katalogas\n%1\nPrašome patikrinti ar teisingai įvedėte pavadinimą." #: qfiledialog.cpp:2281 msgctxt "QFileDialog" msgid "" "'%1' is write protected.\n" "Do you want to delete it anyway?" -msgstr "" +msgstr "%1 apsaugotas nuo pakeitimų.\nAr tikrai norite jį pašalinti?" #: qfiledialog.cpp:2286 msgctxt "QFileDialog" msgid "Are sure you want to delete '%1'?" -msgstr "" +msgstr "Ar tikrai norite pašalinti '%1'?" #: qfiledialog.cpp:2299 msgctxt "QFileDialog" msgid "Could not delete directory." -msgstr "" +msgstr "Nepavyko pašalinti katalogo." #: qfiledialog_win.cpp:128 msgctxt "QFileDialog" msgid "All Files (*.*)" -msgstr "" +msgstr "Visi failai (*.*)" #: qfiledialog.cpp:437 msgctxt "QFileDialog" msgid "Save As" -msgstr "" +msgstr "Irašyti kaip" #: qfileiconprovider.cpp:379 msgctxt "QFileDialog" msgid "Drive" -msgstr "" +msgstr "Diskas" #: qfileiconprovider.cpp:383 msgctxt "QFileDialog" msgid "File" -msgstr "" +msgstr "Failas" #: qfileiconprovider.cpp:412 msgctxt "QFileDialog" msgid "Unknown" -msgstr "" +msgstr "Nežinomas" #: qfiledialog.cpp:439 msgctxt "QFileDialog" msgid "Find Directory" -msgstr "" +msgstr "Rasti katalogą" #: qfiledialog.cpp:458 msgctxt "QFileDialog" msgid "Show " -msgstr "" +msgstr "Rodyti" #: ui_qfiledialog.h:269 msgctxt "QFileDialog" msgid "Forward" -msgstr "" +msgstr "Pirmyn" #: qfiledialog.cpp:2137 msgctxt "QFileDialog" msgid "New Folder" -msgstr "" +msgstr "Naujas katalogas" #: qfiledialog.cpp:465 msgctxt "QFileDialog" msgid "&New Folder" -msgstr "" +msgstr "&Naujas katalogas" #: qfiledialog.cpp:917 msgctxt "QFileDialog" msgid "&Choose" -msgstr "" +msgstr "&Pasirinkti" #: qsidebar.cpp:388 msgctxt "QFileDialog" msgid "Remove" -msgstr "" +msgstr "Pašalinti" #: qfiledialog.cpp:886 msgctxt "QFileDialog" msgid "File &name:" -msgstr "" +msgstr "Failo &pavadinimas" #: ui_qfiledialog.h:261 msgctxt "QFileDialog" msgid "Look in:" -msgstr "" +msgstr "Ieškoti" #: ui_qfiledialog.h:279 msgctxt "QFileDialog" msgid "Create New Folder" -msgstr "" +msgstr "Sukurti Naują Katalogą" #: qfilesystemmodel.cpp:761 msgctxt "QFileSystemModel" msgid "Invalid filename" -msgstr "" +msgstr "Netinkamas failo pavadinimas" #: qfilesystemmodel.cpp:763 msgctxt "QFileSystemModel" msgid "" "<b>The name \"%1\" can not be used.</b><p>Try using another name, with fewer" " characters or no punctuations marks." -msgstr "" +msgstr "<b>Negalima naudoti pavadinimo \"%1\".</b><p>Bandykite įvesti kitokį, trumpesnį, pavadinimą, be skyrybos ženklų." #: qfilesystemmodel.cpp:832 msgctxt "QFileSystemModel" msgid "Name" -msgstr "" +msgstr "Pavadinimas" #: qfilesystemmodel.cpp:834 msgctxt "QFileSystemModel" msgid "Size" -msgstr "" +msgstr "Dydis" #: qfilesystemmodel.cpp:838 msgctxt "QFileSystemModel" msgid "Kind" -msgstr "" +msgstr "Rūšis" #: qfilesystemmodel.cpp:840 msgctxt "QFileSystemModel" msgid "Type" -msgstr "" +msgstr "Tipas" #: qfilesystemmodel.cpp:847 msgctxt "QFileSystemModel" msgid "Date Modified" -msgstr "" +msgstr "Pakeitimo data" #: qfilesystemmodel_p.h:198 msgctxt "QFileSystemModel" msgid "My Computer" -msgstr "" +msgstr "Mano kompiuteris" #: qfilesystemmodel_p.h:200 msgctxt "QFileSystemModel" msgid "Computer" -msgstr "" +msgstr "Kompiuteris" #: qfilesystemmodel.cpp:677 msgctxt "QFileSystemModel" msgid "%1 TB" -msgstr "" +msgstr "%1 TB" #: qfilesystemmodel.cpp:679 msgctxt "QFileSystemModel" msgid "%1 GB" -msgstr "" +msgstr "%1 GB" #: qfilesystemmodel.cpp:681 msgctxt "QFileSystemModel" msgid "%1 MB" -msgstr "" +msgstr "%1 MB" #: qfilesystemmodel.cpp:683 msgctxt "QFileSystemModel" msgid "%1 KB" -msgstr "" +msgstr "%1 KB" #: qfilesystemmodel.cpp:684 msgctxt "QFileSystemModel" msgid "%1 bytes" -msgstr "" - - +msgstr "%1 baitų" diff --git a/lt/vidalia_lt.po b/lt/vidalia_lt.po index fa87632..113a14b 100644 --- a/lt/vidalia_lt.po +++ b/lt/vidalia_lt.po @@ -1,13 +1,14 @@ # # Translators: # <andrius.dre(a)gmail.com>, 2012. +# Gediminas Golcevas <>, 2012. msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2012-03-21 17:52+0000\n" -"PO-Revision-Date: 2012-04-24 21:58+0000\n" -"Last-Translator: vasaris <andrius.dre(a)gmail.com>\n" +"PO-Revision-Date: 2012-07-25 13:37+0000\n" +"Last-Translator: Gediminas Golcevas <>\n" "Language-Team: translations(a)vidalia-project.net\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -496,7 +497,7 @@ msgstr "" msgctxt "CountryInfo" msgid "Angola" -msgstr "" +msgstr "Angola" msgctxt "CountryInfo" msgid "Antigua & Barbuda" @@ -504,7 +505,7 @@ msgstr "" msgctxt "CountryInfo" msgid "Argentina" -msgstr "" +msgstr "Argentina" msgctxt "CountryInfo" msgid "Armenia" @@ -1020,19 +1021,19 @@ msgstr "" msgctxt "CountryInfo" msgid "Sierra Leone" -msgstr "" +msgstr "Siera Leonė" msgctxt "CountryInfo" msgid "Singapore" -msgstr "" +msgstr "Singapūras" msgctxt "CountryInfo" msgid "Slovakia" -msgstr "" +msgstr "Slovakija" msgctxt "CountryInfo" msgid "Slovenia" -msgstr "" +msgstr "Slovėnija" msgctxt "CountryInfo" msgid "Solomon Islands" @@ -1040,7 +1041,7 @@ msgstr "" msgctxt "CountryInfo" msgid "Somalia" -msgstr "" +msgstr "Somalija" msgctxt "CountryInfo" msgid "South Africa" @@ -1048,15 +1049,15 @@ msgstr "" msgctxt "CountryInfo" msgid "Spain" -msgstr "" +msgstr "Ispanija" msgctxt "CountryInfo" msgid "Sri Lanka" -msgstr "" +msgstr "Šri Lanka" msgctxt "CountryInfo" msgid "Sudan" -msgstr "" +msgstr "Sudanas" msgctxt "CountryInfo" msgid "Suriname" @@ -1068,27 +1069,27 @@ msgstr "" msgctxt "CountryInfo" msgid "Sweden" -msgstr "" +msgstr "Švedija" msgctxt "CountryInfo" msgid "Switzerland" -msgstr "" +msgstr "Šveicarija" msgctxt "CountryInfo" msgid "Syria" -msgstr "" +msgstr "Sirija" msgctxt "CountryInfo" msgid "Tajikistan" -msgstr "" +msgstr "Tadžikistanas" msgctxt "CountryInfo" msgid "Tanzania" -msgstr "" +msgstr "Tanzanija" msgctxt "CountryInfo" msgid "Thailand" -msgstr "" +msgstr "Tailandas" msgctxt "CountryInfo" msgid "Timor-Leste (East Timor)" @@ -1112,11 +1113,11 @@ msgstr "" msgctxt "CountryInfo" msgid "Turkey" -msgstr "" +msgstr "Turikija" msgctxt "CountryInfo" msgid "Turkmenistan" -msgstr "" +msgstr "Turkmėnistanas" msgctxt "CountryInfo" msgid "Tuvalu" @@ -1124,31 +1125,31 @@ msgstr "" msgctxt "CountryInfo" msgid "Uganda" -msgstr "" +msgstr "Uganda" msgctxt "CountryInfo" msgid "Ukraine" -msgstr "" +msgstr "Ukraina" msgctxt "CountryInfo" msgid "United Arab Emirates" -msgstr "" +msgstr "Jungtiniai Arabų Emyratai" msgctxt "CountryInfo" msgid "United Kingdom" -msgstr "" +msgstr "Jungtinė Karalystė" msgctxt "CountryInfo" msgid "United States" -msgstr "" +msgstr "Jungtinės Amerikos Valstijos" msgctxt "CountryInfo" msgid "Uruguay" -msgstr "" +msgstr "Urugvajus" msgctxt "CountryInfo" msgid "Uzbekistan" -msgstr "" +msgstr "Uzbekistanas" msgctxt "CountryInfo" msgid "Vanuatu" @@ -1156,15 +1157,15 @@ msgstr "" msgctxt "CountryInfo" msgid "Vatican" -msgstr "" +msgstr "Vatikanas" msgctxt "CountryInfo" msgid "Venezuela" -msgstr "" +msgstr "Venesuela" msgctxt "CountryInfo" msgid "Vietnam" -msgstr "" +msgstr "Vietnamas" msgctxt "CountryInfo" msgid "Western Sahara" @@ -1172,15 +1173,15 @@ msgstr "" msgctxt "CountryInfo" msgid "Yemen" -msgstr "" +msgstr "Jemenas" msgctxt "CountryInfo" msgid "Zambia" -msgstr "" +msgstr "Zambija" msgctxt "CountryInfo" msgid "Zimbabwe" -msgstr "" +msgstr "Zimbabvė" msgctxt "CountryInfo" msgid "Zaire" @@ -1188,7 +1189,7 @@ msgstr "" msgctxt "CountryInfo" msgid "Albania" -msgstr "" +msgstr "Albanija" msgctxt "CountryInfo" msgid "Algeria" @@ -1196,7 +1197,7 @@ msgstr "" msgctxt "CountryInfo" msgid "Austria" -msgstr "" +msgstr "Austrija" msgctxt "CountryInfo" msgid "Bahrain" @@ -1208,7 +1209,7 @@ msgstr "" msgctxt "CountryInfo" msgid "Ethiopia" -msgstr "" +msgstr "Etiopija" msgctxt "CountryInfo" msgid "Fiji" @@ -1220,7 +1221,7 @@ msgstr "" msgctxt "CountryInfo" msgid "Greece" -msgstr "" +msgstr "Graikija" msgctxt "CountryInfo" msgid "Guam" @@ -1232,27 +1233,27 @@ msgstr "" msgctxt "CountryInfo" msgid "Iceland" -msgstr "" +msgstr "Islandija" msgctxt "CountryInfo" msgid "India" -msgstr "" +msgstr "Indija" msgctxt "CountryInfo" msgid "Indonesia" -msgstr "" +msgstr "Indonezija" msgctxt "CountryInfo" msgid "Iran" -msgstr "" +msgstr "Iranas" msgctxt "CountryInfo" msgid "Iraq" -msgstr "" +msgstr "Irakas" msgctxt "CountryInfo" msgid "Ireland" -msgstr "" +msgstr "Airija" msgctxt "CountryInfo" msgid "Korea, North" @@ -1264,15 +1265,15 @@ msgstr "" msgctxt "CountryInfo" msgid "Libya" -msgstr "" +msgstr "Libija" msgctxt "CountryInfo" msgid "Maldives" -msgstr "" +msgstr "Maldyvai" msgctxt "CountryInfo" msgid "Mexico" -msgstr "" +msgstr "Meksika" msgctxt "CountryInfo" msgid "Myanmar" @@ -1280,7 +1281,7 @@ msgstr "" msgctxt "CountryInfo" msgid "Taiwan" -msgstr "" +msgstr "Taivanas" msgctxt "CrashReportDialog" msgid "Submit a Crash Report"

1 0

[metrics-web/master] Remove GetTor statistics from metrics website to see if anybody cares.
by karsten＠torproject.org 25 Jul '12

25 Jul '12

commit ac054f13d56fcbe06abec075c67d5879c560b5ce Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Jul 25 13:34:26 2012 +0200 Remove GetTor statistics from metrics website to see if anybody cares. Implements part of #6395. See the reasoning behind removing GetTor statistics there. The data import part is not removed yet, so if we re-decide about taking GetTor statistics out, we can simply reverse this patch and redeploy. --- etc/web.xml | 4 --- web/WEB-INF/banner.jsp | 4 --- web/WEB-INF/data.jsp | 11 -------- web/WEB-INF/formats.jsp | 40 +----------------------------- web/WEB-INF/graphs.jsp | 3 -- web/WEB-INF/packages.jsp | 62 ---------------------------------------------- 6 files changed, 1 insertions(+), 123 deletions(-) diff --git a/etc/web.xml b/etc/web.xml index 24f3ba2..cc9c3d5 100644 --- a/etc/web.xml +++ b/etc/web.xml @@ -207,10 +207,6 @@ </servlet-mapping> <servlet-mapping> <servlet-name>GraphImage</servlet-name> - <url-pattern>/gettor.png</url-pattern> - </servlet-mapping> - <servlet-mapping> - <servlet-name>GraphImage</servlet-name> <url-pattern>/torperf.png</url-pattern> </servlet-mapping> <servlet-mapping> diff --git a/web/WEB-INF/banner.jsp b/web/WEB-INF/banner.jsp index c31875d..38ed77f 100644 --- a/web/WEB-INF/banner.jsp +++ b/web/WEB-INF/banner.jsp @@ -17,7 +17,6 @@ <%if (currentPage.endsWith("graphs.jsp") || currentPage.endsWith("network.jsp") || currentPage.endsWith("users.jsp") || - currentPage.endsWith("packages.jsp") || currentPage.endsWith("performance.jsp")) { %><br> <font size="2"> @@ -27,9 +26,6 @@ <a <%if (currentPage.endsWith("users.jsp")) { %>class="current"<%} else {%>href="/users.html"<%} %>>Users</a> - <a <%if (currentPage.endsWith("packages.jsp")) { - %>class="current"<%} else {%>href="/packages.html"<%} - %>>Packages</a> <a <%if (currentPage.endsWith("performance.jsp")) { %>class="current"<%} else {%>href="/performance.html"<%} %>>Performance</a> diff --git a/web/WEB-INF/data.jsp b/web/WEB-INF/data.jsp index a1d0b49..06176db 100644 --- a/web/WEB-INF/data.jsp +++ b/web/WEB-INF/data.jsp @@ -28,7 +28,6 @@ <li><a href="#bridgeassignments">Bridge pool assignments</a></li> <li><a href="#performance">Performance data</a></li> <li><a href="#exitlist">Exit lists</a></li> - <li><a href="#gettor">GetTor statistics file</a></li> </ul> <p>The tarballs listed on this page and the raw files that were published on the last three days are also available via @@ -278,16 +277,6 @@ </tr> </c:forEach> </table> - <br> - <a name="gettor"></a> - <h3><a href="#gettor" class="anchor">GetTor statistics - file</a></h3> - <br> - <p>GetTor allows users to fetch the Tor software via email. - This <a href="data/gettor_stats.txt">file</a> contains statistics - on the number of packages requested from GetTor per day. - The data format is described - <a href="formats.html#gettor">here</a>.</p> </div> </div> <div class="bottom" id="bottom"> diff --git a/web/WEB-INF/formats.jsp b/web/WEB-INF/formats.jsp index 98f928b..722ef29 100644 --- a/web/WEB-INF/formats.jsp +++ b/web/WEB-INF/formats.jsp @@ -37,8 +37,7 @@ including <a href="#exitstats">exit-port statistics</a>, and <a href="#bidistats">bidirectional connection use</a>.</li> <li>Third, we delineate the output of various Tor services like -<a href="#bridgepool">BridgeDB</a>, -<a href="#gettor">GetTor</a>, or +<a href="#bridgepool">BridgeDB</a>, or <a href="#exitlist">Tor Check</a> as well as specific measurement tools like <a href="#torperf">Torperf</a>.</li> </ol> @@ -88,7 +87,6 @@ are recent: <tt>transport</tt> lines</li> <li><tt>@type torperf 1.0</tt></li> <li><tt>@type bridge-pool-assignment 1.0</tt></li> -<li><tt>@type gettor 1.0</tt></li> <li><tt>@type tordnsel 1.0</tt></li> </ul> @@ -922,42 +920,6 @@ OR port or relay flag which is defined by <tt>port=$port</tt> and/or <hr> <br> -<a name="gettor"></a> -<h3><a href="#gettor" class="anchor">GetTor statistics file</a></h3> -<br> -<p> -GetTor allows users to fetch the Tor software via email. -GetTor keeps internal statistics on the number of packages requested -every day and writes these statistics to a file. -The document below shows the statistics file for December 27, 2010. -The <tt>None</tt> entry stands for requests that don't ask for a specific -bundle, e.g. requests for the bundle list. -</p> - -<blockquote> -<p> -<i>GetTor statistics file for December 27, 2010:</i> -</p> -<p> -<tt>2010-12-27 - None:167 macosx-i386-bundle:0 macosx-ppc-bundle:0 -source-bundle:2 tor-browser-bundle:0 tor-browser-bundle_ar:0 -tor-browser-bundle_de:0 tor-browser-bundle_en:39 -tor-browser-bundle_es:0 tor-browser-bundle_fa:5 -tor-browser-bundle_fr:0 tor-browser-bundle_it:0 -tor-browser-bundle_nl:0 tor-browser-bundle_pl:0 -tor-browser-bundle_pt:0 tor-browser-bundle_ru:0 -tor-browser-bundle_zh_CN:77 tor-im-browser-bundle:0 -tor-im-browser-bundle_ar:0 tor-im-browser-bundle_de:0 -tor-im-browser-bundle_en:1 tor-im-browser-bundle_es:0 -tor-im-browser-bundle_fa:0 tor-im-browser-bundle_fr:0 -tor-im-browser-bundle_it:0 tor-im-browser-bundle_nl:0 -tor-im-browser-bundle_pl:0 tor-im-browser-bundle_pt:0 -tor-im-browser-bundle_ru:0 tor-im-browser-bundle_zh_CN:0</tt> -</p> -</blockquote> -<hr> -<br> - <a name="exitlist"> <h3><a href="#exitlist" class="anchor">Tor Check exit lists</a></h3> <br> diff --git a/web/WEB-INF/graphs.jsp b/web/WEB-INF/graphs.jsp index ae940a2..58c122c 100644 --- a/web/WEB-INF/graphs.jsp +++ b/web/WEB-INF/graphs.jsp @@ -20,9 +20,6 @@ statistics on the network of relays and bridges.</li> <li>The <a href="users.html">Users page</a> attempts to estimate the number of users in the network.</li> - <li>There are numerous ways to download the Tor software. The - <a href="packages.html">Packages page</a> has statistics on the - number of packages requested from GetTor.</li> <li>There are active and passive performance measurements of the Tor network available on the <a href="performance.html">Performance page</a>.</li> diff --git a/web/WEB-INF/packages.jsp b/web/WEB-INF/packages.jsp deleted file mode 100644 index afe5e50..0000000 --- a/web/WEB-INF/packages.jsp +++ /dev/null @@ -1,62 +0,0 @@ -<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> -<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %> -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> - <title>Tor Metrics Portal: Packages</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> - <div class="center"> - <%@ include file="banner.jsp"%> - <div class="main-column"> -<h2>Tor Metrics Portal: Packages</h2> -<br> -<a name="gettor"></a> -<h3><a href="#gettor" class="anchor">Packages requested from GetTor</a></h3> -<br> -<p>GetTor allows users to fetch the Tor software via email. The following -graph shows the number of packages requested from GetTor per day.</p> -<p> -<img src="gettor.png${gettor_url}" - width="576" height="360" alt="GetTor graph"> -<form action="packages.html#gettor"> - <div class="formrow"> - <input type="hidden" name="graph" value="gettor"> - <p> - <label>Start date (yyyy-mm-dd):</label> - <input type="text" name="start" size="10" - value="<c:choose><c:when test="${fn:length(gettor_start) == 0}">${default_start_date}</c:when><c:otherwise>${gettor_start[0]}</c:otherwise></c:choose>"> - <label>End date (yyyy-mm-dd):</label> - <input type="text" name="end" size="10" - value="<c:choose><c:when test="${fn:length(gettor_end) == 0}">${default_end_date}</c:when><c:otherwise>${gettor_end[0]}</c:otherwise></c:choose>"> - </p><p> - Language: <select name="language"> - <option value="all"<c:if test="${fn:length(gettor_language) == 0 or gettor_language[0] eq 'all'}"> selected</c:if>>All languages</option> - <option value="en"<c:if test="${gettor_language[0] eq 'en'}"> selected</c:if>>English (en)</option> - <option value="zh_CN"<c:if test="${gettor_language[0] eq 'zh_CN'}"> selected</c:if>>Simplified Chinese (zh_CN)</option> - <option value="fa"<c:if test="${gettor_language[0] eq 'fa'}"> selected</c:if>>Farsi (fa)</option> - </select> - </p><p> - Resolution: <select name="dpi"> - <option value="72"<c:if test="${gettor_dpi[0] eq '72'}"> selected</c:if>>Screen - 576x360</option> - <option value="150"<c:if test="${gettor_dpi[0] eq '150'}"> selected</c:if>>Print low - 1200x750</option> - <option value="300"<c:if test="${gettor_dpi[0] eq '300'}"> selected</c:if>>Print high - 2400x1500</option> - </select> - </p><p> - <input class="submit" type="submit" value="Update graph"> - </p> - </div> -</form> - -<p><a href="csv/gettor.csv">CSV</a> file containing all data.</p> -<br> - </div> - </div> - <div class="bottom" id="bottom"> - <%@ include file="footer.jsp"%> - </div> -</body> -</html>

1 0

[metrics-tasks/master] Move #2718 report sources to tech-reports.git.
by karsten＠torproject.org 25 Jul '12

25 Jul '12

commit fdd7a1d37813657166a66dc110952fe3e1e8ae2d Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Thu Jul 12 13:33:27 2012 +0200 Move #2718 report sources to tech-reports.git. --- task-2718/detector.tex | 169 ------------------------------------------------ 1 files changed, 0 insertions(+), 169 deletions(-) diff --git a/task-2718/detector.tex b/task-2718/detector.tex deleted file mode 100644 index 10822d5..0000000 --- a/task-2718/detector.tex +++ /dev/null @@ -1,169 +0,0 @@ -\documentclass{article} -\begin{document} -\author{George Danezis\\{\tt gdane(a)microsoft.com}} -\title{An anomaly-based censorship-detection\\system for Tor} -\date{September 9, 2011} -\maketitle - -\section{Introduction} - -The Tor project is currently the most widely used anonymity and censorship -resistance system worldwide. -As a result, national governments occasionally or regularly block access -to its facilities for relaying traffic. -Major blocking might be easy to detect, but blocking from smaller -jurisdictions, with fewer users, could take some time to detect. -Yet, early detection may be key to deploying countermeasures. -We have designed an ``early warning'' system that looks for anomalies in -the volumes of connections from users in different jurisdictions and flags -potential censorship events. -Special care has been taken to ensure the detector is robust to -manipulations and noise that could be used to block without raising an -alert. - -The detector works on aggregate number of users connecting to a fraction -of directory servers per day. -That set of statistics are gathered and provided by the Tor project in a -sanitised form to minimise the potential for harm to active users. -The data collection has been historically patchy, introducing wild -variations over time that is not due to censorship. -The detector is based on a simple model of the number of users per day per -jurisdiction. -That model is used to assess whether the number of users we observe is -typical, too high, or too low. -In a nutshell the prediction on any day is based on activity of previous -days locally as well as worldwide. - -\section{The model intuition} - -The detector is based on a model of the number of connections from every -jurisdiction based on the number of connections in the past as well as a -model of ``natural'' variation or evolution of the number of connections. -More concretely, consider that at time $t_i$ we have observed $C_{ij}$ -connections from country $j$. -Since we are concerned with abnormal increases or falls in the volume of -connections we compare this with the number of connections we observed at -a past time $t_{i-1}$ denoted as $C_{(i-1)j}$ from the same country $j$. -The ratio $R_{ij} = C_{ij} / C_{(i-1)j}$ summarises the change in the -number of users. -Inferring whether the ratio $R_{ij}$ is within an expected or unexpected -range allows us to detect potential censorship events. - -We consider that a ratio $R_{ij}$ within a jurisdiction $j$ is ``normal'' -if it follows the trends we are observing in other jurisdictions. -Therefore for every time $t_i$ we use the ratios $R_{ij}$ of many -countries to understand the global trends of usage of Tor, and we compare -specific countries' ratios to this model. -If they are broadly within the global trends we assume no censorship is -taking place, otherwise we raise an alarm. - -\section{The model details} - -We model each data point $C_{ij}$ of the number of users connected at time -$t_i$ from country $j$ as a single sample of a Poisson process with a rate -$\lambda_{ij}$ modelling the underlying number of users. -The Poisson process allows us to take into account that in jurisdictions -with very few users we will naturally have some days of relatively low or -high usage---just because a handful of users may or may not use Tor in a -day. -Even observing zero users from such jurisdictions on some days may not be -a significant event. - -We are trying to detect normal or abnormal changes in the rate of change -of the rate $\lambda_{ij}$ between time $t_i$ and a previous time -$t_{i-1}$ for jurisdiction $j$ compared with other jurisdictions. -This is $\lambda_{ij} / \lambda_{(i-1)j}$ which for jurisdictions with a -high number of users is very close to $C_{ij} / C_{(i-1)j} = R_{ij}$. -We model $R_{ij}$'s from all jurisdictions as following a Normal -distribution $N(m,v)$ with a certain mean ($m$) and variance ($v$) to be -inferred. -This is of course a modelling assumption. -We use a normal distribution because given its parameters it represents -the distribution with most uncertainty: as a result the model has higher -variance than the real world, ensuring that it gives fewer false alarms of -censorship. - -The parameters of $N(m,v)$ are inferred directly as point estimates from -the readings in a set of jurisdictions. -Then the probability of a given country ratio $R_{ij}$ is compared with -that distribution: an alarm is raised if the probability of the ratio is -above or below a certain threshold. - -\section{The model robustness} - -At every stage of detections we follow special steps to ensure the -detection is robust to manipulation by jurisdictions interested in -censoring fast without being detected. -First the parameter estimation for $N(m,v)$ is hardened: we only use the -largest jurisdictions to model ratios and within those we remove any -outliers that fall outside four inter-quartile ranges of the median. -This ensures that a jurisdiction with a very high or very low ratio does -not influence the model of ratios (and can be subsequently detected as -abnormal). - -Since we chose jurisdictions with many users to build the model of ratios, -we can approximate the rates $\lambda_{ij}$ by the actual observed number -of users $C_{ij}$. -On the other hand when we try to detect whether a jurisdiction has a -typical rate we cannot make this assumption. -The rate of a Poisson variable $\lambda_{ij}$ can be inferred by a single -sample $C_{ij}$ using a Gamma prior, in which case it follows a Gamma -distribution. -In practice (because we are using a single sample) this in turn can be -approximated using a Poisson distribution with parameter $C_{ij}$. -Using this observation we extract a range of possible rates for each -jurisdiction based on $C_{ij}$, namely $\lambda_{ij_{min}}$ and -$\lambda_{ij_{max}}$. -Then we test whether that full range is within the typical range -distribution---if not we raise an alarm. - -\section{The parameters} - -The deployed model considers a time interval of seven (7) days to model -connection rates (i.e. $t_i$ - $t_{i-1} = 7$ days). -The key reason for a weekly model is our observation that some -jurisdictions exhibit weekly patterns. -A `previous day' model would then raise alarms every time weekly patterns -emerge. -We use the 50 largest jurisdictions to build our models of typical ratios -of traffic over time---as expected most of them are in countries where no -mass censorship has been reported. -This strengthens the model as describing ``normal'' Tor connection -patterns. - -We consider that a ratio of connections is typical if it falls within the -99.99~\% percentile of the Normal distribution $N(m,v)$ modelling ratios. -This ensures that the expected rate of false alarms is about $1 / 10000$, -and therefore only a handful a week (given the large number of -jurisdictions). -Similarly, we infer the range of the rate of usage from each jurisdiction -(given $C_{ij}$) to be the 99.99~\% percentile range of a Poisson -distribution with parameter $C_{ij}$. -This full range must be within the typical range of ratios to avoid -raising an alarm. - -\section{Further work} - -The detector uses time series of user connections to directory servers to -detect censorship. -Any censorship method that does not influence these numbers would as a -result not be detected. -This includes active attacks: a censor could substitute genuine requests -with requests from adversary-controlled machines to keep numbers within -the typical ranges. - -A better model, making use of multiple previous readings, may improve the -accuracy of detection. -In particular, when a censorship event occurs there is a structural -change, and a model based on modelling the future of user loads before the -event will fail. -This is not a critical problem, as these ``false positives'' are -concentrated after real censorship events, but the effect may be confusing -to a reader. -On the other hand, a jurisdiction can still censor by limiting the rate of -censorship to be within the typical range for the time period concerned. -Therefore adapting the detector to run on longer periods would be -necessary to detect such attacks. - -\end{document} -

1 0

[metrics-tasks/master] Move #4255 report sources to tech-reports.git.
by karsten＠torproject.org 25 Jul '12

25 Jul '12

commit 5e7b421b2e46f75d559abccc5980d4ea485e1b15 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Thu Jul 12 13:26:00 2012 +0200 Move #4255 report sources to tech-reports.git. --- task-4255/README | 4 +- task-4255/report.bib | 26 --- task-4255/report.tex | 415 -------------------------------------------------- 3 files changed, 1 insertions(+), 444 deletions(-) diff --git a/task-4255/README b/task-4255/README index 7ff10c9..577f20f 100644 --- a/task-4255/README +++ b/task-4255/README @@ -23,7 +23,5 @@ Plot the results: $ R --slave -f stability.R -Compile the report: - - $ pdflatex report.tex +The report sources are in tech-reports.git/2011/bridge-stability/. diff --git a/task-4255/report.bib b/task-4255/report.bib deleted file mode 100644 index 427e27c..0000000 --- a/task-4255/report.bib +++ /dev/null @@ -1,26 +0,0 @@ -@misc{dirspec, - author = {Roger Dingledine and Nick Mathewson}, - title = {Tor directory protocol, version 3}, - note = {\url{https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/doc/spec/dir-spec.txt}}, -} - -@techreport{loesing2011analysis, - title = {An Analysis of {Tor} Relay Stability}, - author = {Karsten Loesing}, - institution = {The Tor Project}, - year = {2011}, - month = {June}, - type = {Technical Report}, - note = {\url{https://metrics.torproject.org/papers/relay-stability-2011-06-30.pdf}}, -} - -@techreport{loesing2011overview, - title = {Overview of Statistical Data in the {Tor} Network}, - author = {Karsten Loesing}, - institution = {The Tor Project}, - year = {2011}, - month = {March}, - type = {Technical Report}, - note = {\url{https://metrics.torproject.org/papers/data-2011-03-14.pdf}}, -} - diff --git a/task-4255/report.tex b/task-4255/report.tex deleted file mode 100644 index d756449..0000000 --- a/task-4255/report.tex +++ /dev/null @@ -1,415 +0,0 @@ -\documentclass{article} -\usepackage{url} -\usepackage[pdftex]{graphicx} -\usepackage{graphics} -\usepackage{color} -\begin{document} -\title{An Analysis of Tor Bridge Stability\\ -{\large --- Making BridgeDB give out at least one stable bridge per -user ---}} -\author{Karsten Loesing\\{\tt karsten(a)torproject.org}} - -\maketitle - -\section{Introducing the unstable bridges problem} - -As of October 2011, the Tor network consists of a few hundred thousand -clients, 2\,400 public relays, and about 600 non-public bridge relays. -Bridge relays (in the following: bridges) are entry points which are not -publicly listed to prevent censors from blocking access to the Tor -network. -Censored users request a small number of typically three bridge addresses -from the BridgeDB service via email or http and then connect to the Tor -network only via these bridges. -If all bridges that a user knows about suddenly stop working, the user -needs to request a new set of bridge addresses from BridgeDB. -However, BridgeDB memorizes the user's email or IP address and only gives -out new bridges every 24 hours to slow down enumeration attempts. -The result is that a user who is unlucky enough to receive only unreliable -bridges from BridgeDB won't be able to connect to the Tor network for up -to 24 hours before requesting a new set of bridges. - -In this report we propose that BridgeDB keeps bridge stability records, -similar to how the directory authorities keep relay stability records, and -includes at least one stable bridge in its responses to users. -In fact, BridgeDB currently attempts to do this by including at least one -bridge with the Stable flag assigned by the bridge authority in its -results. -This approach is broken for two reasons: -The first reason is that the algorithm that the bridge authority uses to -assign the Stable flag is broken to the extent that almost every bridge -has the Stable flag assigned. -The second reason is that the Stable flag was designed for clients to -select relays for long-running streams, not for BridgeDB to select -reliable entry points into the Tor network. -A better metric for stable bridges would be based on bridge uptime and on -the frequency of IP address changes. -We propose such a metric and evaluate its effectiveness for selecting -stable bridges based on archived bridge directories. - -\section{Defining a new bridge stability metric} -\label{sec:defining} - -The directory authorities implement a few relay stability metrics to -decide which of the relays to assign the Guard and Stable -flag~\cite{dirspec, loesing2011analysis}. -The requirements for stable bridges that we propose here are similar to -the entry guard requirements. -That is, stable bridges should have a higher fractional uptime than -non-stable ones. -Further, a stable bridge should be available under the same IP address and -TCP port. -Otherwise, bridge users who only know a bridge address won't be able to -connect to the bridge once it changes its address or port. -We propose the following requirements for a bridge to be considered -stable in the style of the Guard and Stable flag definition: - -\label{def:bridgestability} -\begin{quote} -A bridge is considered stable if its \emph{Weighted Mean Time Between -Address Change} is at least the median for known active bridges or at -least 30~days, if it is `familiar', and if its \emph{Weighted Fractional -Uptime} is at least the median for `familiar' active bridges or at least -98~\%. -A bridge is `familiar' if 1/8 of all active bridges have appeared more -recently than it, or if it has been around for a \emph{Weighted Time} of -8~days. -\end{quote} - -This bridge stability definition contains three main requirements: - -\begin{itemize} -\item The \emph{Weighted Mean Time Between Address Change (WMTBAC)} -metric is used to track the time that a bridge typically uses the same IP -address and TCP port. -The (unweighted) MTBAC measures the average time between last using -address and port $a_0$ to last using address and port $a_1$. -This metric is weighted to put more emphasis on recent events than on past -events. -Therefore, past address sessions are discounted by factor $0.95$ every -12~hours. -The current session is not discounted, so that a WMTBAC value of 30 days -can be reached after 30 days at the earliest. -\item The \emph{Weighted Fractional Uptime (WFU)} metric measures the -fraction of bridge uptime in the past. -Similar to WMTBAC, WFU values are discounted by factor $0.95$ every -12~hours, but in this case including the current uptime session. -\item The \emph{Weighted Time (WT)} metric is used to calculate a bridge's -WFU and to decide whether a bridge is around long enough to be considered -`familiar.' -WT is discounted similar to WMTBAC and WFU, so that a WT of 8 days can be -reached after around 16 days at the earliest. -\end{itemize} - -All three requirements consist of a dynamic part that depends on the -stability of other bridges (e.g., ``A bridge is familiar if 1/8 of all -active bridges have appeared more recently than it, \ldots'') and a static -part that is independent of other bridges (e.g., ``\ldots or if it has -been around for a Weighted Time of 8 days.''). -The dynamic parts ensure that a certain fraction of bridges is considered -stable even in a rather unstable network. -The static parts ensures that rather stable bridges are not excluded even -when most other bridges in the network are stable. - -\section{Extending BridgeDB to track bridge stability} - -There are at least two code bases that could be extended to track bridge -stability and include at least one stable bridge in BridgeDB results: the -bridge authority and BridgeDB. -The decision for extending either code base affects the available data -for tracking bridge stability and is therefore discussed here. - -The bridge authority maintains a list of all active bridges. -Bridges register at the bridge authority when joining the network, and the -bridge authority periodically performs reachability tests to confirm that -a bridge is still active. -The bridge authority takes snapshots of the list of active bridges every -30~minutes and copies these snapshots to BridgeDB. -BridgeDB parses these half-hourly snapshots and gives out bridges to users -based on the most recently known snapshot. - -The bridge stability history can be implemented either in the bridge -authority code or in BridgeDB. -On the one hand, an implementation in BridgeDB has the disadvantage that -bridge reachability data has a resolution of 30 minutes whereas the bridge -authority would learn about bridges joining or leaving the network -immediately. -On the other hand, the bridge stability information is not used by -anything in the Tor software, but only by BridgeDB. -Implementing this feature in BridgeDB makes more sense from a software -architecture point of view. -In the following we assume that BridgeDB will track bridge stability based -on half-hourly snapshots of active bridge lists, the bridge network -statuses. - -\section{Simulating bridge stability using archived data} - -We can analyze how BridgeDB would track bridge stability and give out -stable bridges by using archived bridge descriptors. -These archives contain the same descriptors that BridgeDB uses, but they -are public and don't contain any IP addresses or sensitive pieces of -information. -In Section~\ref{sec:missingdata} we look at the problem of missing data -due to either the bridge authority or BridgeDB failing and at the effect -on tracking bridge stability. -We then touch the topic of how bridge descriptors are sanitized and how we -can glue them back together for our analysis in -Section~\ref{sec:sanitizing}. -Next, we examine typical bridge stability values as requirements for -considering a bridge as stable in Section~\ref{sec:requirements}. -In Section~\ref{sec:fractions} we estimate what fraction of bridges would -be considered as stable depending on the chosen stability requirements. -Finally, in Section~\ref{sec:selectedstability} we evaluate how effective -different requirement combinations are for selecting stable bridges. -Result metrics are how soon selected bridges change their address or what -fractional uptime selected bridges have in the future. - -\subsection{Handling missing bridge status data} -\label{sec:missingdata} - -The bridge status data that we use in this analysis and that would also be -used by BridgeDB to track bridge stability is generated by the bridge -authority and copied over to BridgeDB every 30~minutes. -Figure~\ref{fig:runningbridge} shows the number of running bridges -contained in these snapshots from July 2010 to June 2011. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{runningbridge.pdf} -\caption{Median number of running bridges as reported by the bridge -authority} -\label{fig:runningbridge} -\end{figure} - -For most of the time the number of bridges is relatively stable. -But there are at least two irregularities, one in July 2010 and another -one in February 2011, resulting from problems with the bridge authority or -the data transfer to the BridgeDB host. -Figure~\ref{fig:runningbridge-detail} shows these two intervals in more -detail. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{runningbridge-detail.pdf} -\caption{Number of Running bridges during phases when either the bridge -authority or the BridgeDB host were broken} -\label{fig:runningbridge-detail} -\end{figure} - -The missing data from July 14 to 27, 2010 comes from BridgeDB host not -accepting new descriptors from the bridge authority because of an -operating system upgrade of the BridgeDB host. -During this time, the bridge authority continued to work, but BridgeDB was -unable to learn about new bridge descriptors from it. - -During the time from January 27 to February 16, 2011, the \verb+tor+ -process running the bridge authority silently died twice after a Tor -version upgrade, but the script to copy descriptors to BridgeDB kept -running. -In this case, BridgeDB received fresh tarballs containing stale -descriptors with a constant number of 687 relays, visualized in light -gray. -These stale descriptors have been excluded from the sanitized descriptors -and the subsequent analysis. -The bridge authority was restarted on February 16, 2011, resulting in the -number of running bridges slowly stabilizing throughout the day. - -Both this analysis and a later implementation in BridgeDB need to take -extended phases of missing or stale data into account. - -\subsection{Detecting address changes in sanitized descriptors} -\label{sec:sanitizing} - -The bridge descriptor archives that we use in this analysis have been -sanitized to remove all addresses and otherwise sensitive -parts~\cite{loesing2011overview}. -Part of this sanitizing process is that bridge IP addresses are replaced -with keyed hashes using a fresh key every month. -More precisely, every bridge IP address is replaced with the private IP -address \verb+10.x.x.x+ with \verb+x.x.x+ being the 3 most significant -bytes of \verb+SHA-256(IP address | bridge identity | secret)+. - -A side-effect of this sanitizing step is that a bridge's sanitized IP -address changes at least once per month, even if the bridge's real IP -address stays the same. -We need to detect these artificial address changes and distinguish them -from real IP address changes. - -In this analysis we use a simple heuristic to distinguish between real IP -address changes and artifacts from the sanitizing process: -Whenever we find that a bridge has changed its IP address from one month -to the next, we look up how long both IP addresses were in use in either -month. -If both addresses were contained in bridge descriptors that were published -at least 36~hours apart, we consider them stable IP addresses and -attribute the apparent IP address change to the sanitizing process. -Otherwise, we assume the bridge has really changed its IP address. -Obviously, this simple heuristic might lead us to false conclusions in -some cases. -But it helps us handle cases when bridges rarely or never change their IP -address which would otherwise suffer from monthly address changes in this -analysis. - -\subsection{Examining typical stability metric values} -\label{sec:requirements} - -The definition of bridge stability on page~\pageref{sec:defining} contains -three different metrics, each of which having a dynamic and a static part. -The dynamic parts compares the value of a bridge's stability metric to the -whole set of running bridges. -Only those bridges are considered as stable that exceed the median value -(or the 12.5th percentile) of all running bridges. -The static requirement parts are fixed values for all stability metrics -that don't rely on the stability of other bridges. - -Figure~\ref{fig:requirements} visualizes the dynamic (solid lines) and -static parts (dashed lines) of all three requirements. -The dynamic WMTBAC requirements are higher than previously expected. -A value of 60 means that, on average, bridges keep their IP address and -port for 60 days. -The dynamic values are cut off at 30 days by the static requirement which -should be a high enough value. -The goal here is to give blocked users a stable enough set of bridges so -that they don't have to wait another 24~hours before receiving new ones. - -We can further see that the dynamic requirements are relatively stable -over time except for the two phases of missing bridge status data. -The first phase in July 2010 mostly affects WT, but neither WMTBAC nor -WFU. -The second phase in February 2011 affects all three metrics. -We can expect the selection of stable bridges during February 2010 to be -more random than at other times. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{requirements.pdf} -\caption{Dynamic requirements for considering a bridge as stable} -\label{fig:requirements} -\end{figure} - -\subsection{Estimating fractions of bridges considered as stable} -\label{sec:fractions} - -Requiring a bridge to meet or exceed either or both WMTBF or WFU metric -results in considering only a subset of all bridges as stable. -The first result of this analysis is to outline what fraction of bridges -would be considered as stable if BridgeDB used either or both -requirements. -In theory, all parameters in the bridge stability definition on -page~\pageref{def:bridgestability} could be adjusted to change the set of -stable bridges or focus more on address changes or on fractional uptime. -We're leaving the fine-tuning for future work when specifying and -implementing the BridgeDB extension. - -Figure~\ref{fig:stablebridge} shows the fraction of stable bridges over -time. -If we only require bridges to meet or exceed the median WMTBAC or the -fixed value of 30 days, roughly 55~\% of the bridges are considered as -stable. -If bridges are only required to meet or exceed the WT and WFU values, -about $7/8 \times 1/2 = 43.75~\%$ of bridges are considered as stable. -Requiring both WFU and WMTBAC leads to a fraction of roughly 35~\% stable -bridges. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{stablebridge.pdf} -\caption{Impact of requiring stable bridges to meet or exceed the median -WFU and/or WMTBAC on the fraction of running bridges considered as stable} -\label{fig:stablebridge} -\end{figure} - -The fraction of 33~\% stable bridges seems appropriate if 1 out of -3~bridges in the BridgeDB results is supposed to be a stable bridge. -If more than 1~bridge should be a stable bridge, the requirements need to -be lowered, so that a higher fraction of bridges is considered stable. -Otherwise, the load on stable bridges might become too high. - -\subsection{Evaluating different requirements on stable bridges} -\label{sec:selectedstability} - -The main purpose of this analysis is to compare the quality of certain -requirements and requirement combinations on the stability of selected -bridges. -Similar to the previous section, we only compare whether or not the WMTBAC -or WFU requirement is used, but don't change their parameters. - -The first result is the future uptime that we can expect from a bridge -that we consider stable. -We calculate future uptime similar to past uptime by weighting events in -the near future more than those happening later. -We are particularly interested in the almost worst-case scenario here, -which is why we're looking at the 10th percentile weighted fractional -uptime in the future. -This number means that 10~\% of bridges have a weighted fractional uptime -at most this high and 90~\% of bridges have a value at least this high. - -Figure~\ref{fig:fwfu-sim} visualizes the four possible combinations of -using or not using the WMTBAC and WFU requirements. -In this plot, the ``WFU \& WMTBAC'' and ``WFU'' lines almost entirely -overlap, meaning that the WMTBAC requirement doesn't add anything to -future uptime of selected bridges. -If the WFU requirement is not used, requiring bridges to meet the WMTBAC -requirement increases future uptime from roughly 35~\% to maybe 55~\%. -That means that there is a slight correlation between the two metrics, -which is plausible. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{fwfu-sim.pdf} -\caption{Impact of requiring stable bridges to meet or exceed the median -WFU and/or WMTBAC on the 10th percentile weighted fractional uptime in the -future} -\label{fig:fwfu-sim} -\end{figure} - -The second result is the time that a selected bridge stays on the same -address and port. -We simply measure the time that the bridge will keep using its current -address in days. -Again, we look at the 10th percentile. -90~\% of selected bridges keep their address longer than this time. - -Figure~\ref{fig:tosa-sim} shows for how long bridges keep their address -and port. -Bridges meeting both WFU and WTMBAC requirements keep their address for 2 -to 5~weeks. -This value decreases to 1 to 3~weeks when taking away the WFU requirement, -which is also a result of the two metrics beeing correlated. -The bridges that only meet the WFU requirement and not the WMTBAC -requirement change their address within the first week. -If we don't use any requirement at all, which is what BridgeDB does today, -10~\% of all bridges change their address within a single day. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{tosa-sim.pdf} -\caption{Impact of requiring stable bridges to meet or exceed the median -WFU and/or WMTBAC on the 10th percentile time on the same address} -\label{fig:tosa-sim} -\end{figure} - -\section{Concluding the bridge stability analysis} - -In this report we propose to extend BridgeDB to make it give out at least -one stable bridge per user. -Bridge stability can be calculated based on bridge status information over -time, similar to how the directory authorities calculate relay stability. -The bridge stability metric proposed here is based on a bridge's past -uptime and the frequency of changing its address and/or port. -Requiring at least 1 bridge of the 3 to be given out to users greatly -reduces the worst case probability of all bridges being offline or -changing their addresses or ports. -The price for this increase in stability is that stable bridges will be -given out more often than non-stable bridges and will therefore see more -usage. - -We suggest to implement the described bridge stability metric in BridgeDB -and make it configurable to tweak the requirement parameters if needed. -Maybe it turns out to be more useful to lower the requirements for a -bridge to become stable and give out two stable bridges per response. -It's also possible that the requirement for a bridge to keep its address -becomes less important in the future when bridge clients can request a -bridge's current address from the bridge authority. -All these scenarios can be analyzed before deploying them using archived -data as done in this report. - -\bibliography{report} -\bibliographystyle{plain} - -\end{document} -

1 0

[metrics-tasks/master] Move #4030 report sources to tech-reports.git.
by karsten＠torproject.org 25 Jul '12

25 Jul '12

commit 1d5ee34828c92c70d27a5c28d1885b27317e16c9 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Thu Jul 12 13:29:30 2012 +0200 Move #4030 report sources to tech-reports.git. --- task-4030/README | 2 +- task-4030/blocking.tex | 237 ------------------------------------------------ 2 files changed, 1 insertions(+), 238 deletions(-) diff --git a/task-4030/README b/task-4030/README index 53ffb68..ed7a16c 100644 --- a/task-4030/README +++ b/task-4030/README @@ -5,5 +5,5 @@ $ javac DetectBridgeBlockings.java && java DetectBridgeBlockings $ R --slave -f bridge-blockings.R -$ pdflatex blocking.tex +The report sources are in tech-reports.git/2011/bridge-blockings/. diff --git a/task-4030/blocking.tex b/task-4030/blocking.tex deleted file mode 100644 index bb2ad90..0000000 --- a/task-4030/blocking.tex +++ /dev/null @@ -1,237 +0,0 @@ -\documentclass{article} -\usepackage[pdftex]{graphicx} -\usepackage{graphics} -\usepackage{color} -\usepackage{url} - -\begin{document} - -\author{Karsten Loesing\\{\tt karsten(a)torproject.org}} -\title{Case study:\\Learning whether a Tor bridge is blocked\\by looking -at its aggregate usage statistics\\-- Part one --} -\maketitle - -\section{Introduction} - -Tor bridges\footnote{\url{https://www.torproject.org/docs/bridges}} are -relays that are not listed in the main directory. -Clients which cannot access the Tor network directly can try to learn a -few bridge addresses and use these bridges to connect to the Tor network. -Bridges have been introduced to impede censoring the Tor network, but in -the past we experienced successful blocking of bridges in a few countries. - -In this report we investigate whether we can learn that a bridge is -blocked in a given country only by looking at its reported aggregate -statistics on usage by country. -By knowing that a bridge is blocked, we can, for example, avoid giving -out its address to users from that country. - -Learning whether a bridge is blocked is somewhat related to our recent -efforts to detect censorship of direct access to the Tor -network.\footnote{\url{https://metrics.torproject.org/papers/detector-2011-09-09.pdf}} -The main difference is that we want to know which bridges are blocked and -which are not, whereas we don't care which relays are accessible in the -case of blocked direct access. -It's easy to block all relays, but it should be difficult to block all -bridges. - -This report can only be seen as a first step towards researching bridge -blocking. -Even if a bridge reports that it had zero users from a country, we're -lacking the confirmation that the bridge was really blocked. -There can be other reasons for low user numbers which may be completely -unrelated. -The results of this analysis should be considered when actively scanning -bridge reachability from inside a country, both to decide how frequently a -bridge should be scanned and to evaluate how reliable an analysis of -passive usage statistics can be. - -\section{Bridge usage statistics} - -Bridges report aggregate usage statistics on the number of connecting -clients. -Bridges gather these statistics by memorizing unique IP addresses of -connecting clients over 24 hour periods and resolving IP addresses to -country codes using an internal GeoIP database. -Archives of these statistics are available for analysis from the metrics -website.\footnote{\url{https://metrics.torproject.org/data.html#bridgedesc}} -Figure~\ref{fig:bridgeextrainfo} shows an example of bridge usage -statistics. -This bridge observed 41 to 48 connecting clients from Saudi Arabia -(all numbers are rounded up to the next multiple of 8), 33 to 40 -connecting clients from the U.S.A., 25 to 32 from Germany, 25 to 32 from -Iran, and so on. -These connecting clients were observed in the 24~hours (86,400 seconds) -before December 27, 2010, 14:56:29 UTC. - -\begin{figure}[h] -\begin{quote} -\begin{verbatim} -extra-info Unnamed A5FA7F38B02A415E72FE614C64A1E5A92BA99BBD -published 2010-12-27 18:55:01 -[...] -bridge-stats-end 2010-12-27 14:56:29 (86400 s) -bridge-ips sa=48,us=40,de=32,ir=32,[...] -\end{verbatim} -\end{quote} -\caption{Example of aggregate bridge usage statistics} -\label{fig:bridgeextrainfo} -\end{figure} - -An obvious limitation of these bridge usage statistics is that we can only -learn about connecting clients from bridges with at least 24 hours uptime. -It's still unclear how many bridge users are not included in the -statistics because of this, which is left for a different analysis. - -We further decided to exclude bridges running Tor versions 0.2.2.3-alpha -or earlier. -These bridges report similar statistics as the later Tor versions that -we're considering here, but do not enforce a measurement interval of -exactly 24 hours which would have slightly complicated the analysis. -We don't expect the bridge version to have an influence on bridge usage -or on the likelihood of the bridge to be blocked in a given country. - -\section{Case study: China in the first half of 2010} - -The major limitation of this analysis is that we don't have the data -confirming that a bridge was actually blocked. -We may decide on a case-by-case basis whether a blocking is a plausible -explanation for the change in observed users from a given country. -Anything more objective requires additional data, e.g., data obtained from -active reachability scans. - -We decided to investigate bridge usage from China in the first half of -2010 as a case study. -Figure~\ref{fig:bridge-users} shows estimated daily bridge users from China -since July 2009. -The huge slope in September and October 2009 is very likely a result from -China blocking direct access to the Tor network. -It seems plausible that the drops in March and May 2010 result from -attempts to block access to bridges, too. -We're going to focus only on the interval from January to June 2010 which -promises the most interesting results. -We should be able to detect these blockings in the reported statistics of -single bridges. -Obviously, it may be hard or impossible to transfer the findings from this -case study to other countries or situations. - -\begin{figure} -\includegraphics[width=\textwidth]{bridge-users.png} -\caption{Estimated daily bridge users from China} -\label{fig:bridge-users} -\end{figure} - -\paragraph{Definition of bridge blocking} - -We have a few options to define when we consider a bridge to be blocked -from a given country on a given day. - -\begin{itemize} -\item \textbf{Absolute threshold:} -The absolute number of connecting clients from a country falls below a -fixed threshold. -\item \textbf{Relative threshold compared to other countries:} -The fraction of connecting clients from a country drops below a fixed -percent value. -\item \textbf{Estimated interval based on history:} -The absolute or relative number of connecting clients falls outside an -estimated interval based on the recent history. -\end{itemize} - -For this case study we decided to stick with the simplest solution being -an absolute threshold. -We define a somewhat arbitrary threshold of 32 users to decide whether a -bridge is potentially blocked. -A blocked bridge does not necessarily report zero users per day. -A likely explanation for reporting users from a country that blocks a -bridge is that our GeoIP is not 100~\% accurate and reports a few users -which in fact come from other countries. - -The reason against using a relative threshold was that it depends on -development in other countries. -As we can see in the example of China, bridge usage can depend on the -abilty to directly access the Tor network. -A sudden increase in country $A$ could significantly lower the relative -usage in country $B$. -We should probably consider both absolute and relative thresholds in -future investigations. -Maybe we also need to take direct usage numbers into account. - -We also didn't build our analysis upon an estimated interval based on the -recent history, because it's unclear how fast a bridge will be blocked -after being set up. -If it only takes the censor a few hours, the bridge may never see much use -from a country at all. -An estimate based on the bridge's history may not detect the censorship at -all, because it may look like a bridge with only few users from that -country. - -We plan to reconsider other options for deciding that a bridge is blocked -once we have data confirming this. - -\paragraph{Visualization of bridge blockings} - -Figure~\ref{fig:bridge-blockings} shows a subset of the raw bridge usage -statistics for clients connecting from China in the first half of 2010. -Possible blocking events are those when the bridge reports 32 or fewer -connecting clients per day. -These events are marked with red dots. - -We decided to only include bridges in the figure that report at least -100~Chinese clients on at least one day in the whole interval. -Bridges with fewer users than that have a usage pattern that makes it much -more difficult to detect blockings at all. -The figure also shows only bridges reporting statistics on at least 30 -days in the measurement interval. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{bridge-blockings.png} -\caption{Subset of bridge usage statistics for Chinese clients in the -first half of 2010} -\label{fig:bridge-blockings} -\end{figure} - -The single bridge usage plots indicate how difficult it is to detect -blockings only from usage statistics. -About 10 of the displayed 27 plots have a pattern similar to the expected -pattern from Figure~\ref{fig:bridge-users}. -The best examples are probably bridges \verb+C037+ and \verb+D795+. -Interestingly, bridge \verb+A5FA+ was unaffected by the blocking in March -2010, but affected by the blocking in May 2010. - -\paragraph{Aggregating blocking events} - -As the last step of this case study we want to compare observed bridge -users to the number of blocked bridges as detected by our simple threshold -approach. -We would expect most of our bridges to exhibit blockings in March 2010 and -from May 2010 on. -Figure~\ref{fig:bridge-users-blockings} plots users and blocked bridges -over time. -The two plots indicate that our detection algorithm is at least not -totally off. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{bridge-users-blockings.png} -\caption{Estimated users and assumed bridge blockings in China in the -first half of 2010} -\label{fig:bridge-users-blockings} -\end{figure} - -\section{Conclusion} - -Passively collected bridge usage statistics seem to be a useful tool to -detect whether a bridge is blocked from a country. -However, the main conclusion from this analysis is that we're lacking the -data to conduct it usefully. -One way to obtain the data we need are active scans. -When conducting such scans, passively collected statistics may help reduce -the total number and frequency of scans. -For example, when selecting a bridge to scan, the reciprocal of the last -reported number of connecting clients could be used as a probability -weight. -Once we have better data confirming bridge blocking we shall revisit the -criteria for deriving the blocking from usage statistics. - -\end{document} -

1 0

[metrics-tasks/master] Move #2911 report sources to tech-reports.git.
by karsten＠torproject.org 25 Jul '12

25 Jul '12

commit 3295fef470687e7228f5d3e215edebffa6a0e250 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Thu Jul 12 13:38:04 2012 +0200 Move #2911 report sources to tech-reports.git. --- task-2911/README | 4 +- task-2911/report.bib | 31 --- task-2911/report.tex | 534 -------------------------------------------------- 3 files changed, 1 insertions(+), 568 deletions(-) diff --git a/task-2911/README b/task-2911/README index e2ae1d0..18e71b0 100644 --- a/task-2911/README +++ b/task-2911/README @@ -137,7 +137,5 @@ Plot the graphs for the tech report: $ R --slave -f stability.R -Compile the tech report: - - $ pdflatex report.tex +The report sources are in tech-reports.git/2011/relay-stability/. diff --git a/task-2911/report.bib b/task-2911/report.bib deleted file mode 100644 index 63ab260..0000000 --- a/task-2911/report.bib +++ /dev/null @@ -1,31 +0,0 @@ -@misc{proposal146, - author = {Nick Mathewson}, - title = {Add new flag to reflect long-term stability}, - note = {\url{https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/146-long-term-stability.txt}}, -} - -@misc{dirspec, - author = {Roger Dingledine and Nick Mathewson}, - title = {Tor directory protocol, version 3}, - note = {\url{https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/doc/spec/dir-spec.txt}}, -} - -@phdthesis{loesing2009thesis, - title = {Privacy-enhancing Technologies for Private Services}, - author = {Karsten Loesing}, - school = {University of Bamberg}, - year = {2009}, - month = {May}, - note = {\url{http://www.opus-bayern.de/uni-bamberg/volltexte/2009/183/pdf/loesingopusneu.pdf}}, -} - -@techreport{loesing2011overview, - title = {Overview of Statistical Data in the {Tor} Network}, - author = {Karsten Loesing}, - institution = {The Tor Project}, - year = {2011}, - month = {March}, - type = {Technical Report}, - note = {\url{https://metrics.torproject.org/papers/data-2011-03-14.pdf}}, -} - diff --git a/task-2911/report.tex b/task-2911/report.tex deleted file mode 100644 index 96fe38f..0000000 --- a/task-2911/report.tex +++ /dev/null @@ -1,534 +0,0 @@ -\documentclass{article} -\usepackage{url} -\usepackage[pdftex]{graphicx} -\usepackage{graphics} -\usepackage{color} -\begin{document} -\title{An Analysis of Tor Relay Stability} -\author{Karsten Loesing\\{\tt karsten(a)torproject.org}} -\date{June 30, 2011} - -\maketitle - -\section{Introduction} - -The Tor network consists of around 2,000 relays and 500 bridges run by -volunteers, some of which are on dedicated servers and some on laptops or -mobile devices. -Obviously, we can expect the relays run on dedicated servers to be more -``stable'' than those on mobile phones. -But it is difficult to draw a line between stable and unstable relays. -In most cases it depends on the context which relays count as stable: - -\begin{enumerate} -\item A stable relay that is supposed to be part of a circuit for a -\emph{long-running stream} should not go offline during the next day. -If only 1 of typically 3 relays in a circuit goes away, the stream -collapses and must be rebuilt. -\item A stable relay that clients pick as \emph{entry guard} doesn't have -to be running continuously, but should be online most of the time in the -upcoming weeks. -In addition to being stable, an entry guard should have reasonable -bandwidth capacity in order not to slow down clients. -\item A stable relay that acts as \emph{hidden-service directory} should -be part of a relay subset that mostly overlaps with the subsets 1, 2, or -even 3 hours in the future. -That means that the relays in this set should be stable, but also that not -too many new relays should join the set at once. -\item A stable relay that clients use in a \emph{fallback consensus} -\cite{proposal146} that is already a few days or even weeks old should -still be available on the same IP address and port, but -doesn't necessarily have to run without interruption. -\item A stable \emph{bridge relay} should be running on the same IP -address a few days after a client learns about the bridge and should be -available most of the time in the upcoming weeks. -\end{enumerate} - -The Tor directory authorities measure relay stability for the first three -contexts listed above and assign the Stable, Guard, and HSDir flags that -clients use to select relays. -Figure~\ref{fig:relayflags} shows the number of relays with relay flags -assigned between July and December 2010 which will be our analysis -interval. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{relayflags.pdf} -\caption{Number of relays with relay flags Running, Stable, and Guard -assigned by the directory authorities between July and December 2010} -\label{fig:relayflags} -\end{figure} - -In this analysis, we use a simulator to resemble how the directory -authorities assign the Stable and Guard relay flags. -This simulator uses archived directory data to decide when a relay was -running and when it failed or was restarted. -We further use this simulator to calculate future stability metrics that -help us evaluate the quality of a given relay flag assignment. -We modify the input parameters to Tor's stability metrics to see whether -we can improve how the directory authorities should assign relay flags. -The analysis data and simulator used in this report are available on the -Tor metrics website at \url{https://metrics.torproject.org/}. - -\section{Requirements for Stable and Guard flags} - -The requirements for assigning the Stable and the Guard flags are defined -in the Tor directory protocol specification \cite{dirspec}. -These definitions are revised here to better reflect what is implemented -in the code: - -\begin{quote} -``A router is `Stable' if it is active, and either its Weighted MTBF is at -least the median for known active routers or its Weighted MTBF corresponds -to at least [5] days. -[...] -A router is a possible `Guard' [if it is `familiar',] if its -Weighted Fractional -Uptime is at least the median for `familiar' active routers [or its -Weighted Fractional Uptime is at least 98~\%], and if -its [advertised] bandwidth is at least median [of all active routers] or -at least 250KB/s. -[...] -A node is `familiar' if 1/8 of all active nodes have appeared more -recently than it, or it has been around for [a weighted time of 8 days].'' -\end{quote} - -These definitions entail four requirements for assigning relay flags, one -for the Stable flag and three for the Guard flag: -\begin{description} -\item[Weighted Mean Time Between Failure (WMTBF):] -The WMTBF metric is used to track the length of continuous uptime sessions -over time. -The (unweighted) MTBF part measures the average uptime between a relay -showing up in the network and either leaving or failing. -In the weighted form of this metric, which is used here, past sessions -are discounted by factor $0.95$ every $12$~hours. -Current uptime sessions are not discounted, so that a WMTBF value of -5~days can be reached after 5~days at the earliest. -\item[Weighted Fractional Uptime (WFU):] The WFU metric measures the -fraction of uptime of a relay in the past. -Similar to WMTBF, WFU values are discounted by factor $0.95$ every -$12$~hours, but in this case including the current uptime session. -\item[Weighted Time:] The Weighted Time metric is used to calculate a -relay's WFU and to decide whether a relay is around long enough to be -considered `familiar.' -The Weighted Time is discounted similar to WMTBF and WFU, so that a -Weighted Time of 8 days can be reached after around 16 days at the -earliest. -\item[Advertised Bandwidth:] The Advertised Bandwidth of a relay is the -minimum of its configured average bandwidth rate and the maximum observed -bandwidth over any ten second period in the past day. -It should be noted that the advertised bandwidth is self-reported by -relays and has been misused in the past to attract more traffic than a -relay should see. -In theory, using the advertised bandwidth value has become discouraged -for anything critical. -\end{description} - -All four requirements have in common that they consist of a dynamic part -that relies on the current network situation (e.g., median of all WMTBF -values for the Stable flag) and a static part that is independent -of other relays (e.g., WMTBF value of 5 days or higher). -The dynamic part ensures that a certain fraction of relays get the -Stable and Guard flags assigned even in a rather unstable network. -The static part ensures that rather stable (or fast) relays are not denied -the flags even when most of the other relays in the network are highly -stable (or very fast). - -\section{Obtaining data for relay stability analysis} - -The internal data that the directory authorities use to decide whether a -relay should get the Stable or Guard flag assigned is not publicly -available. -Instead, we rely on the network status consensuses and server descriptors -that are archived and publicly available since October -2007. -The network status consensuses tell us which relays were available with a -granularity of 1~hour, and the server descriptors help us figure out -whether a relay was restarted in the 1~hour before being listed in a -network status. -We further learn whether a relay got the Stable and/or Guard flag assigned -and what bandwidth it advertised and actually used for relaying data at a -given time. -In detail, we obtain the following data for this analysis: - -\begin{description} -\item[Valid-after time:] The time when a network status consensus was -published. -\item[Fingerprint:] A relay's unique public key fingerprint. -\item[Restarted:] Was a relay restarted within the last hour before the -valid-after time based on its self-reported uptime? -\item[Stable:] Did the directory authorities assign the Stable flag to a -relay? -\item[Guard:] Did the directory authorities assign the Guard flag to a -relay? -\item[Advertised bandwidth:] A relay's self-reported advertised bandwidth. -\item[Bandwidth history:] How many bytes did the relay write on a given -day? -\end{description} - -The choice for using these archived data instead of, e.g., trying to -obtain the internal relay stability data that the directory authorities -use has a few advantages and disadvantes. -The main disadvantage is that our data has a granularity of one hour and -can only detect a single failure or restart within this hour. -It's unclear which effect this lack of detail has on less stable relays. - -But there are a few advantages of using the archived network data: -We have a few years of data available that we can use for the analysis. -If we started obtaining original stability data from the directory -authorities, we'd have to wait a few months before conducting this -analysis. -Also, it's still unclear whether the Tor code that assigns relay flags is -correct, so it makes sense to use a different data basis. -Finally, we need the directory archives anyway to evaluate how stable or -fast a relay turned out to be after being selected. - -\section{Simulating current Stable/Guard assignments} - -The first step before varying the requirements for assigning relay flags -is to run a simulation with the current default requirements. -Only if we manage to come up with similar results as the directory -authorities, we can hope that our suggested parameter changes will have -similar effects in the real Tor network. - -Figure~\ref{fig:default-reqs} shows the fractions of relays that got the -Stable and Guard flags assigned by the directory -authorities (``observed'' lines) and in our simulation with default -requirements (``simulated'' lines). -Ideally, the observed lines should match the simulated lines. -The two Guard lines overlap for about half of the observed time interval -and the difference is always below 5~\% of running relays, which seems to -be acceptable. -The fraction of Guard relays in the simulation is rather stable at 28~\% -whereas the observed fraction goes up to 33~\% for three months. -The observed Stable line seems to be systematically 5 to 10~\% higher than -the simulated line. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{default-reqs.pdf} -\caption{Fraction of relays that got the Stable and Guard flag assigned by -the directory authorities and in our simulation with default requirements} -\label{fig:default-reqs} -\end{figure} - -We first investigate the differences by looking in how far the sets of -observed and simulated sets overlap. -After all, it could be that our simulated 30~\% of Guard relays are a -completely different subset of relays than the observed 30~\%. -Figure~\ref{fig:diff-sim-obs} shows the absolute number of relays in the -intersection and the sets of only observed or only simulated relays. -This graph shows that the majority of relay assignments overlap for both -flags. -The sets of Stable relays that are only found in the simulation is rather -small with around 50 relays. -Compared to that, there are between 100 and 200 relays on average that got -the Stable flag assigned by the directory authorities but which did not -qualify for that flag in the simulation. -The situation of assigned Guard flags is somewhat different. -In July and August 2010, there are about 50 relays in the only-observed -and only-simulated sets. -From September 2010 on, there are hardly any relays in the only-simulated -set, but the number of relays in the only-observed set goes up to nearly -100. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{diff-sim-obs.pdf} -\caption{Number of relays that got the Stable and Guard flag assigned by -both the directory authorities and by our simulator or by just one of -them} -\label{fig:diff-sim-obs} -\end{figure} - -Before accepting these deviations as a given, we take a quick look at the -actual requirements to learn whether the dynamic or the static part of -requirements was more relevant. -Figure~\ref{fig:requirements} shows the dynamic parts as daily means (dark -gray lines) and daily min-max ranges (light gray ribbons) as well as the -static parts (dashed lines). -The dashed lines act as a limit here: if a dynamic requirement based on -the other relays exceeds the dashed line, the requirement is cut to the -fixed value and the fraction of relays meeting the requirement increases. -Whenever the dynamic requirement remains below the dashed line, the -fraction of relays that get flags assigned should remain more or less the -same. -For example, the top left graph indicates that it's quite possible that -more than 50~\% of relays got the Stable flag assigned from July -to November, but that this fraction should have dropped to 50~\% in -December 2010. -However, this was not the case. -The graph also indicates that the 250 KiB/s limit was never reached, so -that relays were always selected based on the comparison to the advertised -bandwidth of the other relays. - -\begin{figure} -\includegraphics[width=\textwidth]{requirements.pdf} -\caption{Simulated requirements for assigning the Stable and Guard flags} -\label{fig:requirements} -\end{figure} - -Possible reasons for deviation of simulation and actual assignments by the -directory authorities are: - -\begin{enumerate} -\item The simulator code may contain bugs. -\item Our data with a granularity of 1~hour lack the details for detecting -restarts and failures and thereby make it hard to observe uptime sessions -correctly. -\item The directory authorities have slightly different views on the -network which then get mixed in the voting process. -\item The implementation of relay history on the directory authorities may -contain bugs. -\end{enumerate} - -For the remainder of this analysis we will assume that the simulated -number of Stable relays is 5 to 10~\% lower than in reality and that the -simulation of Guard is more or less accurate. - -\section{Choosing relays for long-lived streams} -\label{sec:mtbf-sim} - -After learning that our simulation of relay stability is at least not -totally off, we want to take a closer look at the Stable flag. -Whenever clients request Tor to open a long-lived stream, Tor should try -to pick only those relays for the circuit that are not likely to disappear -shortly after. -If only a single relay in the circuit fails, the stream collapses and a -new circuit needs to be built. -Depending on how well the application handles connection failures this may -impact usability significantly. - -The WMTBF metric as the requirement for assigning the Stable flag has -already been discussed above. -Now we want to find out how useful WMTBF is to predict which relays are -not likely to leave or crash in the near future. -In order to evaluate future relay stability we measure the \emph{time -until next failure}. -There is no need to measure more than the current uptime session length, -and hence there is no need to weight measurements. -For a given set of relays with the Stable flag we determine the 10th -percentile of time until next failure. -This is the time when 10~\% of relays have failed and 90~\% are still -running. -Under the (grossly simplified) assumption that relays are chosen -uniformly, $1 - 0.9^3 = 27.1~\%$ of streams using relays from this set -would have been interrupted up to this point. - -The default requirement is that a relay's WMTBF is at least the median for -known relays or at least 5 days. -We simulate times until next failure for the 30th, 40th, 50th, 60th, and -70th percentiles of WMTBF values in the network while leaving the fixed -5-day constant unchanged. -We also look up times until next failure for the set of Stable relays that -got their flags from the directory authorities. -Figure~\ref{fig:wmtbf-tunf-sim} shows the results. -The artificial steps come from our limitation to measure time until next -failure in more detail than in full hours. -The further right a line is the higher is the time until next failure for -the considered consensuses from July to December 2010. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{wmtbf-tunf-sim.pdf} -\caption{Impact of changing the WMTBF percentile requirement for assigning -the Stable flag on the expected time until next failure} -\label{fig:wmtbf-tunf-sim} -\end{figure} - -The first finding that comes to mind is that the observed line is much -farther left than the simulated 50th percentile line. -In theory, both lines use the 50th percentile as requirement and should -therefore have similar results. -However, since the directory authorities assign the Stable flag to almost -60~\% of all relays, it's likely that their overall stability is lower -than the stability of the most stable 50~\% of all relays. -It's unclear why observed results are even worse than those from the -simulated 40th percentile. -It might be that the directory authorities don't just assign the -Stable flag to too many relays, but also to the wrong relays. - -Apart from that, the graph shows the large influence of different WMTBF -percentiles on relay stability. -If we lowered the requirement to the 30th WMTBF percentile, thus assigning -the Stable flag to at least 70~\% of all relays, the 10th percentile of -time until next failure would be reached after 6 to 24 hours in most -cases. -The 40th and 50th percentile requirements move this point to 12 to 36 and -18 to 54 hours, respectively. -If we changed the requirement to the 60th WMTBF percentile, this point -would only be reached after 24 to 60 hours. -The 70th percentile requirement is not even shown in the graph, because -this requirement is so high that the fixed 5-day constant applies in most -cases here, making the dynamic percentile requirement meaningless. - -As an intermediate conclusion, we could improve relay stability a lot by -raising the WMTBF percentile requirement a bit. -A good next step might be to find out why the directory authorities assign -the Stable flag to 55 to 60~\% of all relays and not 50~\%. -Of course, a higher requirement would result in fewer relays with the -Stable flag. -But having 40~\% of relays with that flag should still provide for enough -diversity. - -\section{Picking stable entry guards} - -The second flag that we're going to analyze in more detail is the -Guard flag. -Clients pick a set of entry guards as fixed entry points into the Tor -network. -Optimally, clients should be able to stick with their choice for a few -weeks. -While it is not required for all their entry guards to be running all the -time, at least a subset of them should be running, or the client needs to -pick a new set. - -As discussed above, Tor's primary metric for deciding which relays are -stable enough to be entry guards is \emph{weighted fractional uptime -(WFU)}. -WFU measures the fraction of uptime of a relay in the past with older -observations weighted to count less. -The assumption is that a relay that was available most of the time in the -past will also be available most of the time in the future. - -In a first analysis we simulate the effect of varying the percentile -requirements for becoming an entry guard on the relay stability in the -future. -We measure future stability by using the same WFU metric, but for uptime -in the future. -We similarly weight observations farther in the future less than -observations in the near future. -The rationale is that a high fractional uptime in the next few days is -slightly more important than in a month. -For a given set of relays we measure the 10th percentile of WFU in the -future as an indication of relay stability. -The result is that 10~\% of relays will have a lower uptime than this -value and 90~\% of relays will have a higher uptime. - -Figure~\ref{fig:wfu-wfu-sim} shows the 10th percentile of WFU for simulations -using the 30th, 40th, 50th, and 60th WFU percentile as requirement for -assigning the Guard flag. -This graph also shows the future WFU of relays that got their Guard flag -assigned by the directory authorities. -Here, the simulation using the default 50th percentile is much closer to -the flags assigned by the directory authorities than in the case of the -Stable flag. -Unsurprisingly, the 30th percentile requirement has the worst stability, -because it includes up to 70\% of all relays, minus the non-familiar ones -and those that don't meet the bandwidth requirement. -Relay stability increases for raising the WFU requirement to the 40th, -50th, and 60th percentile, but in most cases the outcome is an uptime of -more than 85~\% or even more than 90~\%. -Under the assumption that a client needs only one or two working guards at -a time and can pick a new set of guards easily, these stabilities seem to -be sufficiently high. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{wfu-wfu-sim.pdf} -\caption{Impact of changing the WFU percentile requirement for assigning -the Guard flag on WFU in the future} -\label{fig:wfu-wfu-sim} -\end{figure} - -\section{Selecting high-bandwidth entry guards} - -A second question regarding Guard flag assignments is whether we can raise -the advertised bandwidth requirement to end up with faster entry guards. -The fixed set of entry guards determines to a certain extent what overall -performance the client can expect. -If a client is unlucky and picks only slow guards, the overall Tor -performance can be bad, in particular because clients don't drop slow -guards, but only failing ones. - -We introduce a new metric to evaluate how much bandwidth capacity a relay -will provide in the future: the \emph{weighted bandwidth}. -This metric is not based on a relay's advertised bandwidth, but on the -actual written bytes as reported by the relay. -Again, we're more interested in the bandwidth in the near future, so we -discount observations 12 hours further in the future by factor 0.95. - -Figure~\ref{fig:advbw-wb-sim} shows the effect of changing the advertised -bandwidth requirement from the 50th percentile to the 40th, 60th, or even -70th percentile on the 10th percentile of weighted bandwidth. -Similar to the graphs above, 10~\% of relays have a lower weighted -bandwidth and 90~\% have a higher weighted bandwidth. -Here, the observed 50th percentile is almost identical to the simulated -50th percentile. -The graph shows that raising the requirement to the 60th percentile of -advertised bandwidth would shift this percentile line by roughly 10 KiB/s -to the right. -The 70th percentile would ensure that 90~\% of the selected -Guard relays have a weighted bandwidth of at least between 60 and -170~KiB/s depending on the current network situation. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{advbw-wb-sim.pdf} -\caption{Impact of changing the advertised bandwidth percentile for -assigning the Guard flag on bandwidth capacity in the future} -\label{fig:advbw-wb-sim} -\end{figure} - -Of course, raising the advertised bandwidth requirement for becoming a -guard node results in having fewer possible guard nodes. -Figure~\ref{fig:advbw-frac-relays-sim} shows the effect of raising the -advertised bandwidth requirement from the 50th to the 60th or 70th -percentile. -The 60th percentile requirement would reduce the fraction of relays with -the Guard flag from 28~\% to around 25~\%, and the 70th percentile even to -a value below 20~\%. -There's a clear trade-off here between raising the bandwidth capacity of -entry guards and having fewer guards to distribute one third of the -network load to. -Having fewer than 20~\% of all relays being possible Guard nodes is -probably not enough and will generate new performance problems. - -\begin{figure}[t] -\includegraphics[width=\textwidth]{advbw-frac-relays-sim.pdf} -\caption{Influence of changing the advertised bandwidth percentile on the -fraction of relays getting the Guard flag assigned} -\label{fig:advbw-frac-relays-sim} -\end{figure} - -\section{Discussion and future work} - -In this report we used a simulator to evaluate Tor's relay stability -metrics for assigning Stable and Guard flags to relays. -We introduced three metrics to evaluate how stable or fast a set of relays -is that got the Stable or Guard flag assigned. -Our simulator uses the same algorithms to decide whether a relay is stable -as the directory authorities and can be parameterized to analyze different -requirements. -We could further add new algorithms to the simulator and see what subsets -of Stable and Guard relays that would produce. - -Using our simulator we found that the fraction of relays with the Stable -flag in the current network is higher than it probably should be. -We also learned that the WFU requirements for assigning the Guard flag are -quite reasonable and lead to stable guards. -But we might consider raising the advertised bandwidth requirement a bit -to have higher-bandwidth guard nodes. -Medium-term, we should get rid of a requirement that is based on the -self-reported advertised bandwidth. - -Possible next steps are to review the Tor source code for assigning flags -and compare the internal relay stability data from the directory -authorities to simulated values. -It would be interesting to know why the directory authorities assign the -Stable flag so generously. -Also, it would be interesting to compare the internal stability data from -multiple directory authorities to see in how far they agree. -Another possible next step might be to turn the four requirement -percentiles (WMTBF, WFU, Weighted Time, and Advertises Bandwidth) into -consensus parameters to be able to test parameter changes in the real -network. - -We also left the analysis of relay stability for hidden-service -directories, fallback consensuses, and bridge relays as future work. -Possible starting points are an earlier analysis of hidden-service -directory stability \cite{loesing2009thesis}, the Tor proposal -describing fallback consensuses \cite{proposal146}, and a tech report -explaining how bridge descriptors are sanitized to make them publicly -available \cite{loesing2011overview}. - -\bibliography{report} -\bibliographystyle{plain} - -\end{document} -

1 0

[metrics-tasks/master] Move #2754 report sources to tech-reports.git.
by karsten＠torproject.org 25 Jul '12

25 Jul '12

commit 8de9c40b7347436202bc75e2a4d3020e43e2d595 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Thu Jul 12 13:44:16 2012 +0200 Move #2754 report sources to tech-reports.git. --- task-2754/data.bib | 45 --- task-2754/data.tex | 772 ---------------------------------------------------- 2 files changed, 0 insertions(+), 817 deletions(-) diff --git a/task-2754/data.bib b/task-2754/data.bib deleted file mode 100644 index caec3b8..0000000 --- a/task-2754/data.bib +++ /dev/null @@ -1,45 +0,0 @@ -@misc{dirspec, - author = {Roger Dingledine and Nick Mathewson}, - title = {Tor directory protocol, version 3}, - note = {\url{https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/doc/spec/dir-spec.txt}}, -} - -@inproceedings{loesing2009measuring, - title = {Measuring the {Tor} Network from Public Directory Information}, - author = {Karsten Loesing}, - booktitle = {Proc.\ HotPETS}, - year = {2009}, - month = Aug, - address = {Seattle, WA}, - note = {\url{https://metrics.torproject.org/papers/hotpets09.pdf}}, -} - -@inproceedings{loesing2010case, - title = {A Case Study on Measuring Statistical Data in the {Tor} Anonymity Network}, - author = {Karsten Loesing and Steven J. Murdoch and Roger Dingledine}, - booktitle = {Proc.\ Workshop on Ethics in Computer Security Research}, - year = {2010}, - month = Jan, - address = {Tenerife, Canary Islands, Spain}, - note = {\url{https://metrics.torproject.org/papers/wecsr10.pdf}}, -} - -@techreport{hahn2010privacy, - title = {Privacy-preserving Ways to Estimate the Number of Tor Users}, - author = {Sebastian Hahn and Karsten Loesing}, - institution = {The Tor Project}, - year = {2010}, - month = Nov, - type = {Technical Report}, - note = {\url{https://metrics.torproject.org/papers/countingusers-2010-11-30.pdf}}, -} - -@techreport{loesing2009analysis, - title = {Analysis of Circuit Queues in {Tor}}, - author = {Karsten Loesing}, - institution = {The Tor Project}, - year = {2009}, - month = Aug, - note = {\url{https://metrics.torproject.org/papers/bufferstats-2009-08-25.pdf}}, -} - diff --git a/task-2754/data.tex b/task-2754/data.tex deleted file mode 100644 index 1a2745d..0000000 --- a/task-2754/data.tex +++ /dev/null @@ -1,772 +0,0 @@ -\documentclass{article} -\usepackage{url} -\usepackage[pdftex]{graphicx} -\usepackage{graphics} -\usepackage{color} -\begin{document} -\title{Overview of Statistical Data in the Tor Network} -\author{Karsten Loesing} -\maketitle - -\section{Introduction} - -Statistical analysis in the Tor network can be performed using various -kinds of data. -In this report we give an overview of three major data sources for -statistics in the Tor network: -First, we recap measuring the Tor network from public directory -information \cite{loesing2009measuring} in Section~\ref{sec:serverdesc} -and explain the sanitzation process of (non-public) bridge directory -information in Section~\ref{sec:bridgesan}. -Second, we describe the numerous aggregate statistics that relays publish -about their usage \cite{loesing2010case} -in Sections~\ref{sec:bytehist} to \ref{fig:connbidirect}. -Third, we delineate the output of various Tor services like BridgeDB, -GetTor, or -Tor Check as well as specific measurement tools like Torperf in -Sections~\ref{sec:torperf} to \ref{sec:exitlist}. -All data described in this report are available for download on the -metrics -website.\footnote{\texttt{https://metrics.torproject.org/data.html}} - -\section{Server descriptors and network statuses} -\label{sec:serverdesc} - -Relays in the Tor network report their capabilities by publishing server -descriptors to the directory authorities. -The directory authorities confirm reachability of relays and assign flags -to help clients make good path selections. -Every hour, the directory authorities publish a network status consensus -with all known running relays at the time. -Both server descriptors and network statuses constitute a solid data basis -for statistical analysis in the Tor network. -We described the approach to measure the Tor network from public directory -information in \cite{loesing2009measuring} and provide interactive -graphs on the metrics -website.\footnote{\texttt{https://metrics.torproject.org/graphs.html}} -In this section, we briefly describe the most interesting pieces of the -two descriptor formats that can be used for statistics. - -\paragraph{Server descriptors} - -The server descriptors published by relays at least once every 18 hours -contain the necessary information for clients to build circuits using a -given relay. -These server descriptors can also be useful for statistical analysis of -the Tor network infrastructure. - -We assume that the majority of server descriptors are correct. -But when performing statistical analysis on server descriptors, one has to -keep in mind that only a small subset of the information written to server -descriptors is confirmed by the trusted directory authorities. -In theory, relays can provide false information in their server -descriptors, even though the incentive to do so is probably low. - -Figure~\ref{fig:serverdesc} shows an example server descriptor. -The following data fields in server descriptors may be relevant to -statistical analysis: - -\begin{figure} -\begin{verbatim} -router blutmagie 192.251.226.206 443 0 80 -platform Tor 0.2.2.20-alpha on Linux x86_64 -opt protocols Link 1 2 Circuit 1 -published 2010-12-27 14:35:27 -opt fingerprint 6297 B13A 687B 521A 59C6 BD79 188A 2501 EC03 A065 -uptime 445412 -bandwidth 14336000 18432000 15905178 -opt extra-info-digest 5C1D5D6F8B243304079BC15CD96C7FCCB88322D4 -opt caches-extra-info -onion-key -[...] -signing-key -[...] -family $66CA87E164F1CFCE8C3BB5C095217A28578B8BAF - $67EC84376D9C4C467DCE8621AACA109160B5264E - $7B698D327F1695590408FED95CDEE1565774D136 -opt hidden-service-dir -contact abuse(a)blutmagie.de -reject 0.0.0.0/8:* -reject 169.254.0.0/16:* -reject 127.0.0.0/8:* -reject 192.168.0.0/16:* -reject 10.0.0.0/8:* -reject 172.16.0.0/12:* -reject 192.251.226.206:* -reject *:25 -reject *:119 -reject *:135-139 -reject *:445 -reject *:465 -reject *:563 -reject *:587 -reject *:1214 -reject *:4661-4666 -reject *:6346-6429 -reject *:6660-6999 -accept *:* -router-signature -[...] -\end{verbatim} -\vspace{-1em} -\caption{Server descriptor published by relay \texttt{blugmagie} (without -cryptographic keys and hashes)} -\label{fig:serverdesc} -%---------------------------------------------------------------- -\end{figure} - -\begin{itemize} -\item \textit{IP address and ports:} Relays provide their IP address -and ports where they accept requests to build circuits and directory -requests. -These data fields are contained in the first line of a server descriptor -starting with \verb+router+. -Note that in rare cases, the IP address provided here can be different -from the IP address used for exiting to the Internet. -The latter can be found in the exit lists produced by Tor Check as -described in Section~\ref{sec:exitlist}. -\item \textit{Operating system and Tor software version:} Relays include -their operating system and Tor software version in their server -descriptors in the \verb+platform+ line. -While this information is very likely correct in most cases, a few relay -operators may try to impede hacking attempts by providing false platform -strings. -\item \textit{Uptime:} Relays include the number of seconds since the -last restart in their server descriptor in the \verb+uptime+ line. -\item \textit{Own measured bandwidth:} Relays report the bandwidth that -they are willing to provide on average and for short periods of time. -Relays also perform periodic bandwidth self-tests and report their actual -available bandwidth. -The latter was used by clients to weight relays in the path selection -algorithm and was sometimes subject to manipulation by malicious relays. -All three bandwidth values can be found in a server descriptor's -\verb+bandwidth+ line. -With the introduction of bandwidth scanners, the self-reported relay -bandwidth in server descriptors has become less -relevant.\footnote{\url{http://gitweb.torproject.org/torflow.git/}} -\item \textit{Relay family:} Some relay operators who run more than one -relay organize their relays in relay families, so that clients don't pick -more than one of these relays for a single circuit. -Each relay belonging to a relay family lists the members of that family -either by nickname or fingerprint in its server descriptor in the -\verb+family+ line. -\item \textit{Exit policy:} Relays define their exit policy by including -firewall-like rules which outgoing connections they reject or accept in -the \verb+reject+ and \verb+accept+ lines. -\end{itemize} - -These are just a subset of the fields in a server descriptor that seem -relevant for statistical analysis. -For a complete list of fields in server descriptors, see the directory -procol specification \cite{dirspec}. - -\paragraph{Network statuses} - -Every hour, the directory authorities publish a new network status that -contains a list of all running relays. -The directory authorities confirm reachability of the contained relays and -assign flags based on the relays' characteristics. -The entries in a network status reference the last published server -descriptor of a relay. - -The network statuses are relevant for statistical analysis, because they -constitute trusted snapshots of the Tor network. -Anyone can publish as many server descriptors as they want, but only the -directory authorities can confirm that a relay was running at a given -time. -Most statistics on the Tor network infrastructure rely on network statuses -and possibly combine them with the referenced server descriptors. -Figure~\ref{fig:statusentry} shows the network status entry referencing -the server descriptor from Figure~\ref{fig:serverdesc}. -In addition to the reachability information, network statuses contain the -following fields that may be relevant for statistical analysis: - -\begin{figure} -\begin{verbatim} -r blutmagie YpexOmh7UhpZxr15GIolAewDoGU - lFY7WmD/yvVFp9drmZzNeTxZ6dw 2010-12-27 14:35:27 192.251.226.206 - 443 80 -s Exit Fast Guard HSDir Named Running Stable V2Dir Valid -v Tor 0.2.2.20-alpha -w Bandwidth=30800 -p reject 25,119,135-139,445,465,563,587,1214,4661-4666,6346-6429, - 6660-6999 -\end{verbatim} -%---------------------------------------------------------------- -\vspace{-1em} -\caption{Network status entry of relay \texttt{blutmagie}} -\label{fig:statusentry} -\end{figure} - -\begin{itemize} -\item \textit{Relay flags:} The directory authorities assign flags to -relays based on their characteristics to the line starting with \verb+s+. -Examples are the \verb+Exit+ flag if a relay permits exiting to the -Internet and the \verb+Guard+ flag if a relay is stable enough to be -picked as guard node -\item \textit{Relay version:} The directory authorities include the -version part of the platform string written to server descriptors in the -network status in the line starting with \verb+v+. -\item \textit{Bandwidth weights:} The network status contains a bandwidth -weight for every relay in the lines with \verb+w+ that clients shall use -for weighting relays in their path selection algorithm. -This bandwidth weight is either the self-reported bandwidth of the relay -or the bandwidth measured by the bandwidth scanners. -\item \textit{Exit policy summary:} Every entry in a network status -contains a summary version of a relay's exit policy in the line starting -with \verb+p+. -This summary is a list of accepted or rejected ports for exit to most IP -addresses. -\end{itemize} - -\section{Sanitized bridge descriptors} -\label{sec:bridgesan} - -Bridges in the Tor network publish server descriptors to the bridge -authority which in turn generates a bridge network status. -We cannot, however, make the bridge server descriptors and bridge network -statuses available for statistical analysis as we do with the relay server -descriptors and relay network statuses. -The problem is that bridge server descriptors and network statuses contain -bridge IP addresses and other sensitive information that shall not be made -publicly available. -We therefore sanitize bridge descriptors by removing all potentially -identifying information and publish sanitized versions of the descriptors. -The processing steps for sanitizing bridge descriptors are as follows: - -\begin{enumerate} -\item \textit{Replace the bridge identity with its SHA1 value:} Clients -can request a bridge's current descriptor by sending its identity string -to the bridge authority. -This is a feature to make bridges on dynamic IP addresses useful. -Therefore, the original identities (and anything that could be used to -derive them) need to be removed from the descriptors. -The bridge identity is replaced with its SHA1 hash value. -The idea is to have a consistent replacement that remains stable over -months or even years (without keeping a secret for a keyed hash function). -\item \textit{Remove all cryptographic keys and signatures:} It would be -straightforward to learn about the bridge identity from the bridge's -public key. -Replacing keys by newly generated ones seemed to be unnecessary (and would -involve keeping a state over months/years), so that all cryptographic -objects have simply been removed. -\item \textit{Replace IP address with IP address hash:} Of course, the IP -address needs to be removed, too. -It is replaced with \verb+10.x.x.x+ with \verb+x.x.x+ being the 3 byte -output of \verb+H(IP address | bridge identity | secret)[:3]+. -The input \verb+IP address+ is the 4-byte long binary representation of -the bridge's current IP address. -The \verb+bridge identity+ is the 20-byte long binary representation of -the bridge's long-term identity fingerprint. -The \verb+secret+ is a 31-byte long secure random string that changes once -per month for all descriptors and statuses published in that month. -\verb+H()+ is SHA-256. -The \verb+[:3]+ operator means that we pick the 3 most significant bytes -of the result. -\item \textit{Replace contact information:} If there is contact -information in a descriptor, the contact line is changed to -\verb+somebody+. -\item \textit{Replace nickname with Unnamed:} The bridge nicknames might -give hints on the location of the bridge if chosen without care; e.g.\ a -bridge nickname might be very similar to the operators' relay nicknames -which might be located on adjacent IP addresses. -All bridge nicknames are therefore replaced with the string -\verb+Unnamed+. -\end{enumerate} - -Figure~\ref{fig:bridgeserverdesc} shows an example bridge server -descriptor that is referenced from the bridge network status entry in -Figure~\ref{fig:bridgestatusentry}. -For more details about this process, see the bridge descriptor sanitizer -and the metrics database -software.\footnote{\texttt{https://metrics.torproject.org/tools.html}} - -\begin{figure} -\begin{verbatim} -router Unnamed 10.74.150.129 443 0 0 -platform Tor 0.2.2.19-alpha (git-1988927edecce4c7) on Linux i686 -opt protocols Link 1 2 Circuit 1 -published 2010-12-27 18:55:01 -opt fingerprint A5FA 7F38 B02A 415E 72FE 614C 64A1 E5A9 2BA9 9BBD -uptime 2347112 -bandwidth 5242880 10485760 1016594 -opt extra-info-digest 86E6E9E68707AF586FFD09A36FAC236ADA0D11CC -opt hidden-service-dir -contact somebody -reject *:* -\end{verbatim} -\vspace{-1em} -\caption{Sanitized bridge server descriptor} -\label{fig:bridgeserverdesc} -%---------------------------------------------------------------- -\end{figure} - -\begin{figure} -\begin{verbatim} - -r Unnamed pfp/OLAqQV5y/mFMZKHlqSupm70 dByzfWWLas9cen7PtZ3XGYIJHt4 - 2010-12-27 18:55:01 10.74.150.129 443 0 -s Fast Guard HSDir Running Stable Valid -\end{verbatim} -\vspace{-1em} -\caption{Sanitized bridge network status entry} -\label{fig:bridgestatusentry} -%---------------------------------------------------------------- -\end{figure} - -\section{Byte histories} -\label{sec:bytehist} - -Relays include aggregate statistics in their descriptors that they upload -to the directory authorities. -These aggregate statistics are contained in extra-info descriptors that -are published in companion with server descriptors. -Extra-info descriptors are not required for clients to build circuits. -An extra-info descriptor belonging to a server descriptor is referenced by -its SHA1 hash value. - -Byte histories were the first statistical data that relays published about -their usage. -Relays report the number of written and read bytes in 15-minute intervals -throughout the last 24 hours. -The extra-info descriptor in Figure~\ref{fig:extrainfo} contains the byte -histories in the two lines starting with \verb+write-history+ and -\verb+read-history+. -More details about these statistics can be found in the directory protocol -specification~\cite{dirspec}. - -\begin{figure} -\begin{verbatim} -extra-info blutmagie 6297B13A687B521A59C6BD79188A2501EC03A065 -published 2010-12-27 14:35:27 -write-history 2010-12-27 14:34:05 (900 s) 12902389760, - 12902402048,12859373568,12894131200,[...] -read-history 2010-12-27 14:34:05 (900 s) 12770249728,12833485824, - 12661140480,12872439808,[...] -dirreq-write-history 2010-12-27 14:26:13 (900 s) 51731456, - 60808192,56740864,54948864,[...] -dirreq-read-history 2010-12-27 14:26:13 (900 s) 4747264,4767744, - 4511744,4752384,[...] -dirreq-stats-end 2010-12-27 10:51:09 (86400 s) -dirreq-v3-ips us=2000,de=1344,fr=744,kr=712,[...] -dirreq-v2-ips ??=8,au=8,cn=8,cz=8,[...] -dirreq-v3-reqs us=2368,de=1680,kr=1048,fr=800,[...] -dirreq-v2-reqs id=48,??=8,au=8,cn=8,[...] -dirreq-v3-resp ok=12504,not-enough-sigs=0,unavailable=0, - not-found=0,not-modified=0,busy=128 -dirreq-v2-resp ok=64,unavailable=0,not-found=8,not-modified=0, - busy=8 -dirreq-v2-share 1.03% -dirreq-v3-share 1.03% -dirreq-v3-direct-dl complete=316,timeout=4,running=0,min=4649, - d1=36436,d2=68056,q1=76600,d3=87891,d4=131294,md=173579, - d6=229695,d7=294528,q3=332053,d8=376301,d9=530252,max=2129698 -dirreq-v2-direct-dl complete=16,timeout=52,running=0,min=9769, - d1=9769,d2=9844,q1=9981,d3=9981,d4=27297,md=33640,d6=60814, - d7=205884,q3=205884,d8=361137,d9=628256,max=956009 -dirreq-v3-tunneled-dl complete=12088,timeout=92,running=4, - min=534,d1=31351,d2=49166,q1=58490,d3=70774,d4=88192,md=109778, - d6=152389,d7=203435,q3=246377,d8=323837,d9=559237,max=26601000 -dirreq-v2-tunneled-dl complete=0,timeout=0,running=0 -entry-stats-end 2010-12-27 10:51:09 (86400 s) -entry-ips de=11024,us=10672,ir=5936,fr=5040,[...] -exit-stats-end 2010-12-27 10:51:09 (86400 s) -exit-kibibytes-written 80=6758009,443=498987,4000=227483, - 5004=1182656,11000=22767,19371=1428809,31551=8212,41500=965584, - 51413=3772428,56424=1912605,other=175227777 -exit-kibibytes-read 80=197075167,443=5954607,4000=1660990, - 5004=1808563,11000=1893893,19371=130360,31551=7588414, - 41500=756287,51413=2994144,56424=1646509,other=288412366 -exit-streams-opened 80=5095484,443=359256,4000=4508,5004=22288, - 11000=124,19371=24,31551=40,41500=96,51413=16840,56424=28, - other=1970964 -\end{verbatim} -%---------------------------------------------------------------- -\vspace{-1em} -\caption{Extra-info descriptor published by relay \texttt{blutmagie} -(without cryptographic signature and with long lines being truncated)} -\label{fig:extrainfo} -\end{figure} - -\section{Directory requests} - -The directory authorities and directory mirrors report statistical data -about processed directory requests. -Starting with Tor version 0.2.2.15-alpha, all directories report the -number of written and read bytes for answering directory requests. -The format is similar to the format of byte histories as described in the -previous section. -The relevant lines are \verb+dirreq-write-history+ and -\verb+dirreq-read-history+ in Figure~\ref{fig:extrainfo}. -These two lines contain the subset of total read and written bytes that -the directory mirror spent on responding to any kind of directory request, -including network statuses, server descriptors, extra-info descriptors, -authority certificates, etc. - -The directories further report statistics on answering directory requests -for network statuses only. -For Tor versions before 0.2.3.x, relay operators had to manually enable -these statistics, which is why only a few directories report them. -The lines starting with \verb+dirreq-v3-+ all belong to the directory -request statistics (the lines starting with \verb+dirreq-v2-+ report -similar statistics for version 2 of the directory protocol which is -deprecated at the time of writing this report). -The following fields may be relevant for statistical analysis: - -\begin{itemize} -\item \textit{Unique IP addresses:} The numbers in \verb+dirreq-v3-ips+ -denote the unique IP addresses of clients requesting network statuses by -country. -\item \textit{Network status requests:} The numbers in -\verb+dirreq-v3-reqs+ constitute the total network status requests by -country. -\item \textit{Request share:} The percentage in \verb+dirreq-v3-share+ is -an estimate of the share of directory requests that the reporting relay -expects to see in the Tor network. -In \cite{hahn2010privacy} we found that this estimate isn't very useful -for statistical analysis because of the different approaches that clients -take to select directory mirrors. -The fraction of written directory bytes (\verb+dirreq-write-history+) can -be used to derive a better metric for the share of directory requests. -\item \textit{Network status responses:} The directories also report -whether they could provide the requested network status to clients in -\verb+dirreq-v3-resp+. -This information was mostly used to diagnose error rates in version 2 of -the directory protocol where a lot of directories replied to network -status requests with \verb+503 Busy+. -In version 3 of the directory protocol, most responses contain the status -code \verb+200 OK+. -\item \textit{Network status download times:} The line -\verb+dirreq-v3-direct-dl+ contains statistics on the download of network -statuses via the relay's directory port. -The line \verb+dirreq-v3-tunneled-dl+ contains similar statistics on -downloads via a 1-hop circuit between client and directory (which is the -common approach in version 3 of the directory protocol). -Relays report how many requests have been completed, have timed out, and -are still running at the end of a 24-hour time interval as well as the -minimum, maximum, median, quartiles, and deciles of download times. -\end{itemize} -More details about these statistics can be found in the directory protocol -specification~\cite{dirspec}. - -\section{Connecting clients} - -Relays can be configured to report per-country statistics on directly -connecting clients. -This metric includes clients connecting to a relay in order to build -circuits and clients creating a 1-hop circuit to request directory -information. -In practice, the latter number outweighs the former number. -The \verb+entry-ips+ line in Figure~\ref{fig:extrainfo} shows the number -of unique IP addresses connecting to the relay by country. -More details about these statistics can be found in the directory protocol -specification~\cite{dirspec}. - -\section{Bridge users} - -Bridges report statistics on connecting bridge clients in their extra-info -descriptors. -Figure~\ref{fig:bridgeextrainfo} shows a bridge extra-info descriptor -with the bridge user statistics in the \verb+bridge-ips+ line. - -\begin{figure} -\begin{verbatim} -extra-info Unnamed A5FA7F38B02A415E72FE614C64A1E5A92BA99BBD -published 2010-12-27 18:55:01 -write-history 2010-12-27 18:43:50 (900 s) 151712768,176698368, - 180030464,163150848,[...] -read-history 2010-12-27 18:43:50 (900 s) 148109312,172274688, - 172168192,161094656,[...] -bridge-stats-end 2010-12-27 14:56:29 (86400 s) -bridge-ips sa=48,us=40,de=32,ir=32,[...] -\end{verbatim} -\vspace{-1em} -\caption{Sanitized bridge extra-info descriptor} -%---------------------------------------------------------------- -\label{fig:bridgeextrainfo} -\end{figure} - -Bridges running Tor version 0.2.2.3-alpha or earlier report bridge users -in a similar line starting with \verb+geoip-client-origins+. -The reason for switching to \verb+bridge-ips+ was that the measurement -interval in \verb+geoip-client-origins+ had a variable length, whereas the -measurement interval in 0.2.2.4-alpha and later is set to exactly -24~hours. -In order to clearly distinguish the new measurement intervals from the old -ones, the new keywords have been introduced. -More details about these statistics can be found in the directory protocol -specification~\cite{dirspec}. - -\section{Cell-queue statistics} - -Relays can be configured to report aggregate statistics on their cell -queues. -These statistics include average processed cells, average number of queued -cells, and average time that cells spend in circuits. -Circuits are split into deciles based on the number of processed cells. -The statistics are provided for circuit deciles from loudest to quietest -circuits. -Figure~\ref{fig:cellstats} shows the cell statistics contained in an -extra-info descriptor by relay \texttt{gabelmoo}. -An early analysis of cell-queue statistics can be found in -\cite{loesing2009analysis}. -More details about these statistics can be found in the directory protocol -specification~\cite{dirspec}. - -\begin{figure} -\begin{verbatim} -cell-stats-end 2010-12-27 09:59:50 (86400 s) -cell-processed-cells 4563,153,42,15,7,7,6,5,4,2 -cell-queued-cells 9.39,0.98,0.09,0.01,0.00,0.00,0.00,0.01,0.00, - 0.01 -cell-time-in-queue 2248,807,277,92,49,22,52,55,81,148 -cell-circuits-per-decile 7233 -\end{verbatim} -%---------------------------------------------------------------- -\vspace{-1em} -\caption{Cell statistics in extra-info descriptor by relay -\texttt{gabelmoo}} -\label{fig:cellstats} -\end{figure} - -\section{Exit-port statistics} - -Exit relays running Tor version 0.2.1.1-alpha or higher can be configured -to report aggregate statistics on exiting connections. -These relays report the number of opened streams, written and read bytes -by exiting port. -Until version 0.2.2.19-alpha, relays reported all ports exceeding a -threshold of 0.01~\% of all written and read exit bytes. -Starting with version 0.2.2.20-alpha, relays only report the top 10 ports -in exit-port statistics in order not to exceed the maximum extra-info -descriptor length of 50 KB. -Figure~\ref{fig:extrainfo} on page \pageref{fig:extrainfo} contains -exit-port statistics in the lines starting with \verb+exit-+. -More details about these statistics can be found in the directory protocol -specification~\cite{dirspec}. - -\section{Bidirectional connection use} -\label{sec:bidistats} - -Relays running Tor version 0.2.3.1-alpha or higher can be configured to -report what fraction of connections is used uni- or bi-directionally. -Every 10 seconds, relays determine for every connection whether they read -and wrote less than a threshold of 20 KiB. -Connections below this threshold are labeled as ``Below Threshold''. -For the remaining connections, relays report whether they read/wrote at -least 10 times as many bytes as they wrote/read. -If so, they classify a connection as ``Mostly reading'' or ``Mostly -writing,'' respectively. -All other connections are classified as ``Both reading and writing.'' -After classifying connections, read and write counters are reset for the -next 10-second interval. -Statistics are aggregated over 24 hours. -Figure~\ref{fig:connbidirect} shows the bidirectional connection use -statistics in an extra-info descriptor by relay \texttt{zweifaltigkeit}. -The four numbers denote the number of connections ``Below threshold,'' -``Mostly reading,'' ``Mostly writing,'' and ``Both reading and writing.'' -More details about these statistics can be found in the directory protocol -specification~\cite{dirspec}. - -\begin{figure} -\begin{verbatim} -conn-bi-direct 2010-12-28 15:55:11 (86400 s) 387465,45285,55361, - 81786 -\end{verbatim} -%---------------------------------------------------------------- -\vspace{-1em} -\caption{Bidirectional connection use statistic in extra-info descriptor -by relay \texttt{zweifaltigkeit}} -\label{fig:connbidirect} -\end{figure} - -\section{Torperf output files} -\label{sec:torperf} - -Torperf is a little tool that measures Tor's performance as users -experience it. -Torperf uses a trivial SOCKS client to download files of various sizes -over the Tor network and notes how long substeps take. -Torperf can be downloaded from the metrics -website.\footnote{\texttt{https://metrics.torproject.org/tools.html}} - -Torperf can produce two output files: \verb+.data+ and \verb+.extradata+. -The \verb+.data+ file contains timestamps for nine substeps and the byte -summaries for downloading a test file via Tor. -Figure~\ref{fig:torperf} shows an example output of a Torperf run. -The timestamps in the upper part of this output are seconds and -nanoseconds since 1970-01-01 00:00:00.000000. - -Torperf can be configured to write \verb+.extradata+ files by attaching -a Tor controller and writing certain controller events to disk. -The content of a \verb+.extradata+ line is shown in the lower part of -Figure~\ref{fig:torperf}. -The first column indicates if this circuit was actually used to fetch -the data (\verb+ok+) or if Tor chose a different circuit because this -circuit was problematic (\verb+error+). -For every \verb+error+ entry there should be a following \verb+ok+ entry, -unless the network of the Torperf instance is dead or the resource is -unavailable. -The circuit build completion time in the \verb+.extradata+ line is the -time between Torperf sent a SOCKS request and received a SOCKS response in -the \verb+.data+ file. -The three or more hops of the circuit are listed by relay fingerprint and -nickname. -An \verb+=+ sign between the two means that a relay has the \texttt{Named} -flag, whereas the \verb+~+ sign means it doesn't. - -\begin{figure} -\begin{verbatim} -# Timestamps and byte summaries contained in .data files: -1293543301 762678 # Connection process started -1293543301 762704 # After socket is created -1293543301 763074 # After socket is connected -1293543301 763190 # After authentication methods are negotiated - # (SOCKS 5 only) -1293543301 763816 # After SOCKS request is sent -1293543302 901783 # After SOCKS response is received -1293543302 901818 # After HTTP request is written -1293543304 445732 # After first response is received -1293543305 456664 # After payload is complete -75 # Written bytes -51442 # Read bytes - -# Path information contained in .extradata files: -ok # Status code -1293543302 # Circuit build completion time -$2F265B37920BDFE474BF795739978EEFA4427510=fejk4 # 1st hop -$66CA87E164F1CFCE8C3BB5C095217A28578B8BAF=blutmagie3 # 2nd hop -$76997E6557828E8E57F70FDFBD93FB3AA470C620~Amunet8 # 3rd hop -\end{verbatim} -%---------------------------------------------------------------- -\vspace{-1em} -\caption{Torperf output lines for a single request to download a 50~KiB -file (reformatted and annotated with comments)} -\label{fig:torperf} -\end{figure} - -\section{BridgeDB pool assignment files} - -BridgeDB is the software that receives bridge network statuses containing -the information which bridges are running from the bridge authority, -assigns these bridges to persistent distribution rings, and hands them out -to bridge users. -BridgeDB periodically dumps the list of running bridges with information -about the rings, subrings, and file buckets to which they are assigned to -a local file. -The sanitized versions of these lists containing SHA-1 hashes of bridge -fingerprints instead of the original fingerprints are available for -statistical analysis. - -\begin{figure} -\begin{verbatim} -bridge-pool-assignment 2011-03-13 14:38:03 -00b834117566035736fc6bd4ece950eace8e057a unallocated -00e923e7a8d87d28954fee7503e480f3a03ce4ee email port=443 - flag=stable -0103bb5b00ad3102b2dbafe9ce709a0a7c1060e4 https ring=2 port=443 - flag=stable -[...] -\end{verbatim} -%---------------------------------------------------------------- -\vspace{-1em} -\caption{BridgeDB pool assignment file from March 13, 2011} -\label{fig:bridgeassignments} -\end{figure} - -Figure~\ref{fig:bridgeassignments} shows a BridgeDB pool assignment file -from March 13, 2011. -Every such file begins with a line containing the timestamp when BridgeDB -wrote this file. -Subsequent lines always start with the SHA-1 hash of a bridge fingerprint, -followed by ring, subring, and/or file bucket information. -There are currently three distributor ring types in BridgeDB: - -\begin{enumerate} -\item \texttt{unallocated}: These bridges are not distributed by BridgeDB, -but are either reserved for manual distribution or are written to file -buckets for distribution via an external tool. -If a bridge in the \texttt{unallocated} ring is assigned to a file bucket, -this is noted by \verb+bucket=$bucketname+. -\item \texttt{email}: These bridges are distributed via an e-mail -autoresponder. Bridges can be assigned to subrings by their OR port or -relay flag which is defined by \verb+port=$port+ and/or \verb+flag=$flag+. -\item \texttt{https}: These bridges are distributed via https server. -There are multiple https rings to further distribute bridges by IP address -ranges, which is denoted by \verb+ring=$ring+. -Bridges in the \texttt{https} ring can also be assigned to subrings by -OR port or relay flag which is defined by \verb+port=$port+ and/or -\verb+flag=$flag+. -\end{enumerate} - -\section{GetTor statistics file} - -GetTor allows users to fetch the Tor software via email. -GetTor keeps internal statistics on the number of packages requested -every day and writes these statistics to a file. -Figure~\ref{fig:gettor} shows the statistics file for December 27, 2010. -The \verb+None+ entry stands for requests that don't ask for a specific -bundle, e.g.\ requests for the bundle list. - -\begin{figure} -\begin{verbatim} -2010-12-27 - None:167 macosx-i386-bundle:0 macosx-ppc-bundle:0 - source-bundle:2 tor-browser-bundle:0 tor-browser-bundle_ar:0 - tor-browser-bundle_de:0 tor-browser-bundle_en:39 - tor-browser-bundle_es:0 tor-browser-bundle_fa:5 - tor-browser-bundle_fr:0 tor-browser-bundle_it:0 - tor-browser-bundle_nl:0 tor-browser-bundle_pl:0 - tor-browser-bundle_pt:0 tor-browser-bundle_ru:0 - tor-browser-bundle_zh_CN:77 tor-im-browser-bundle:0 - tor-im-browser-bundle_ar:0 tor-im-browser-bundle_de:0 - tor-im-browser-bundle_en:1 tor-im-browser-bundle_es:0 - tor-im-browser-bundle_fa:0 tor-im-browser-bundle_fr:0 - tor-im-browser-bundle_it:0 tor-im-browser-bundle_nl:0 - tor-im-browser-bundle_pl:0 tor-im-browser-bundle_pt:0 - tor-im-browser-bundle_ru:0 tor-im-browser-bundle_zh_CN:0 -\end{verbatim} -%---------------------------------------------------------------- -\vspace{-1em} -\caption{GetTor statistics file for December 27, 2010} -\label{fig:gettor} -\end{figure} - -\section{Tor Check exit lists} -\label{sec:exitlist} - -TorDNSEL is an implementation of the active testing, DNS-based exit list -for Tor exit -nodes.\footnote{\texttt{https://www.torproject.org/tordnsel/dist/}} -Tor Check makes the list of known exits and corresponding exit IP -addresses available in a specific format. -Figure~\ref{fig:exitlist} shows an entry of the exit list written on -December 28, 2010 at 15:21:44 UTC. -This entry means that the relay with fingerprint \verb+63Ba..+ which -published a descriptor at 07:35:55 and was contained in a version 2 -network status from 08:10:11 uses two different IP addresses for exiting. -The first address \verb+91.102.152.236+ was found in a test performed at -07:10:30. -When looking at the corresponding server descriptor, one finds that this -is also the IP address on which the relay accepts connections from inside -the Tor network. -A second test performed at 10:35:30 reveals that the relay also uses IP -address \verb+91.102.152.227+ for exiting. - -\begin{figure} -\begin{verbatim} -ExitNode 63BA28370F543D175173E414D5450590D73E22DC -Published 2010-12-28 07:35:55 -LastStatus 2010-12-28 08:10:11 -ExitAddress 91.102.152.236 2010-12-28 07:10:30 -ExitAddress 91.102.152.227 2010-12-28 10:35:30 -\end{verbatim} -\vspace{-1em} -\caption{Exit list entry written on December 28, 2010 at 15:21:44 UTC} -\label{fig:exitlist} -\end{figure} - -\bibliography{data} -\bibliographystyle{plain} - -\end{document} -

1 0

[tech-reports/master] Use .pdf graphs instead of .png.
by karsten＠torproject.org 25 Jul '12

25 Jul '12

commit 1b4942c719cc7859bbbbd545025c3ac83b8a122b Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Jul 25 12:48:21 2012 +0200 Use .pdf graphs instead of .png. --- 2011/bridge-blockings/blocking.tex | 6 +++--- 2011/bridge-blockings/bridge-blockings.pdf | Bin 0 -> 78657 bytes 2011/bridge-blockings/bridge-blockings.png | Bin 646431 -> 0 bytes 2011/bridge-blockings/bridge-users-blockings.pdf | Bin 0 -> 6848 bytes 2011/bridge-blockings/bridge-users-blockings.png | Bin 91721 -> 0 bytes 2011/bridge-blockings/bridge-users.pdf | Bin 0 -> 9385 bytes 2011/bridge-blockings/bridge-users.png | Bin 67922 -> 0 bytes 7 files changed, 3 insertions(+), 3 deletions(-) diff --git a/2011/bridge-blockings/blocking.tex b/2011/bridge-blockings/blocking.tex index ddd8620..628c27d 100644 --- a/2011/bridge-blockings/blocking.tex +++ b/2011/bridge-blockings/blocking.tex @@ -115,7 +115,7 @@ Obviously, it may be hard or impossible to transfer the findings from this case study to other countries or situations. \begin{figure} -\includegraphics[width=\textwidth]{bridge-users.png} +\includegraphics[width=\textwidth]{bridge-users.pdf} \caption{Estimated daily bridge users from China} \label{fig:bridge-users} \end{figure} @@ -204,14 +204,14 @@ The two plots indicate that our detection algorithm is at least not totally off. \begin{figure}[t] -\includegraphics[width=\textwidth]{bridge-users-blockings.png} +\includegraphics[width=\textwidth]{bridge-users-blockings.pdf} \caption{Estimated users and assumed bridge blockings in China in the first half of 2010} \label{fig:bridge-users-blockings} \end{figure} \begin{figure}[t] -\includegraphics[width=\textwidth]{bridge-blockings.png} +\includegraphics[width=\textwidth]{bridge-blockings.pdf} \caption{Subset of bridge usage statistics for Chinese clients in the first half of 2010} \label{fig:bridge-blockings} diff --git a/2011/bridge-blockings/bridge-blockings.pdf b/2011/bridge-blockings/bridge-blockings.pdf new file mode 100644 index 0000000..90c41fd Binary files /dev/null and b/2011/bridge-blockings/bridge-blockings.pdf differ diff --git a/2011/bridge-blockings/bridge-blockings.png b/2011/bridge-blockings/bridge-blockings.png deleted file mode 100755 index 2538795..0000000 Binary files a/2011/bridge-blockings/bridge-blockings.png and /dev/null differ diff --git a/2011/bridge-blockings/bridge-users-blockings.pdf b/2011/bridge-blockings/bridge-users-blockings.pdf new file mode 100644 index 0000000..4319ab5 Binary files /dev/null and b/2011/bridge-blockings/bridge-users-blockings.pdf differ diff --git a/2011/bridge-blockings/bridge-users-blockings.png b/2011/bridge-blockings/bridge-users-blockings.png deleted file mode 100755 index d86e2c9..0000000 Binary files a/2011/bridge-blockings/bridge-users-blockings.png and /dev/null differ diff --git a/2011/bridge-blockings/bridge-users.pdf b/2011/bridge-blockings/bridge-users.pdf new file mode 100644 index 0000000..3c8e128 Binary files /dev/null and b/2011/bridge-blockings/bridge-users.pdf differ diff --git a/2011/bridge-blockings/bridge-users.png b/2011/bridge-blockings/bridge-users.png deleted file mode 100755 index 45595a4..0000000 Binary files a/2011/bridge-blockings/bridge-users.png and /dev/null differ

1 0

[tech-reports/master] Update bridge-stability graphs.
by karsten＠torproject.org 25 Jul '12

25 Jul '12

commit 8ccae45ddb522083ef57811222454e07898ba5b2 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Jul 25 12:52:42 2012 +0200 Update bridge-stability graphs. --- 2011/bridge-stability/fwfu-sim.pdf | Bin 40046 -> 12268 bytes 2011/bridge-stability/requirements.pdf | Bin 38630 -> 11396 bytes 2011/bridge-stability/runningbridge-detail.pdf | Bin 122071 -> 13681 bytes 2011/bridge-stability/runningbridge.pdf | Bin 21675 -> 6582 bytes 2011/bridge-stability/stablebridge.pdf | Bin 34888 -> 10511 bytes 2011/bridge-stability/tosa-sim.pdf | Bin 40391 -> 12347 bytes 6 files changed, 0 insertions(+), 0 deletions(-) diff --git a/2011/bridge-stability/fwfu-sim.pdf b/2011/bridge-stability/fwfu-sim.pdf index 8565aba..5eac173 100755 Binary files a/2011/bridge-stability/fwfu-sim.pdf and b/2011/bridge-stability/fwfu-sim.pdf differ diff --git a/2011/bridge-stability/requirements.pdf b/2011/bridge-stability/requirements.pdf index 4871677..48939ba 100755 Binary files a/2011/bridge-stability/requirements.pdf and b/2011/bridge-stability/requirements.pdf differ diff --git a/2011/bridge-stability/runningbridge-detail.pdf b/2011/bridge-stability/runningbridge-detail.pdf index 32120e7..d4abfc7 100755 Binary files a/2011/bridge-stability/runningbridge-detail.pdf and b/2011/bridge-stability/runningbridge-detail.pdf differ diff --git a/2011/bridge-stability/runningbridge.pdf b/2011/bridge-stability/runningbridge.pdf index c0bac36..d693d82 100755 Binary files a/2011/bridge-stability/runningbridge.pdf and b/2011/bridge-stability/runningbridge.pdf differ diff --git a/2011/bridge-stability/stablebridge.pdf b/2011/bridge-stability/stablebridge.pdf index c20804e..7b9222c 100755 Binary files a/2011/bridge-stability/stablebridge.pdf and b/2011/bridge-stability/stablebridge.pdf differ diff --git a/2011/bridge-stability/tosa-sim.pdf b/2011/bridge-stability/tosa-sim.pdf index 9fea0b8..cee92ca 100755 Binary files a/2011/bridge-stability/tosa-sim.pdf and b/2011/bridge-stability/tosa-sim.pdf differ

1 0

[tech-reports/master] Update relay-stability graphs.
by karsten＠torproject.org 25 Jul '12

25 Jul '12

commit b5eb43b9add3fc90748217123e39535bccd62187 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Jul 25 12:54:01 2012 +0200 Update relay-stability graphs. --- 2011/relay-stability/advbw-frac-relays-sim.pdf | Bin 20434 -> 9109 bytes 2011/relay-stability/advbw-wb-sim.pdf | Bin 358595 -> 101316 bytes 2011/relay-stability/default-reqs.pdf | Bin 20121 -> 9011 bytes 2011/relay-stability/diff-sim-obs.pdf | Bin 28027 -> 11190 bytes 2011/relay-stability/relayflags.pdf | Bin 16284 -> 8081 bytes 2011/relay-stability/requirements.pdf | Bin 51526 -> 17773 bytes 2011/relay-stability/wfu-wfu-sim.pdf | Bin 358058 -> 73731 bytes 2011/relay-stability/wmtbf-tunf-sim.pdf | Bin 357667 -> 55646 bytes 8 files changed, 0 insertions(+), 0 deletions(-) diff --git a/2011/relay-stability/advbw-frac-relays-sim.pdf b/2011/relay-stability/advbw-frac-relays-sim.pdf index 2523a74..fa5422d 100755 Binary files a/2011/relay-stability/advbw-frac-relays-sim.pdf and b/2011/relay-stability/advbw-frac-relays-sim.pdf differ diff --git a/2011/relay-stability/advbw-wb-sim.pdf b/2011/relay-stability/advbw-wb-sim.pdf index be82838..f2a5654 100755 Binary files a/2011/relay-stability/advbw-wb-sim.pdf and b/2011/relay-stability/advbw-wb-sim.pdf differ diff --git a/2011/relay-stability/default-reqs.pdf b/2011/relay-stability/default-reqs.pdf index 49789ef..3bee9a4 100755 Binary files a/2011/relay-stability/default-reqs.pdf and b/2011/relay-stability/default-reqs.pdf differ diff --git a/2011/relay-stability/diff-sim-obs.pdf b/2011/relay-stability/diff-sim-obs.pdf index c6086e4..ae6ff09 100755 Binary files a/2011/relay-stability/diff-sim-obs.pdf and b/2011/relay-stability/diff-sim-obs.pdf differ diff --git a/2011/relay-stability/relayflags.pdf b/2011/relay-stability/relayflags.pdf index 88fc59e..7969ccb 100755 Binary files a/2011/relay-stability/relayflags.pdf and b/2011/relay-stability/relayflags.pdf differ diff --git a/2011/relay-stability/requirements.pdf b/2011/relay-stability/requirements.pdf index 54cc3d6..fa979c5 100755 Binary files a/2011/relay-stability/requirements.pdf and b/2011/relay-stability/requirements.pdf differ diff --git a/2011/relay-stability/wfu-wfu-sim.pdf b/2011/relay-stability/wfu-wfu-sim.pdf index d8b8dd3..8c3c2f8 100755 Binary files a/2011/relay-stability/wfu-wfu-sim.pdf and b/2011/relay-stability/wfu-wfu-sim.pdf differ diff --git a/2011/relay-stability/wmtbf-tunf-sim.pdf b/2011/relay-stability/wmtbf-tunf-sim.pdf index 0896dc5..2ec35c0 100755 Binary files a/2011/relay-stability/wmtbf-tunf-sim.pdf and b/2011/relay-stability/wmtbf-tunf-sim.pdf differ

1 0