commit a80cfa08c5252ac44b331dd6823893d373639306 Author: George Kadianakis desnacked@riseup.net Date: Fri Jan 9 13:28:18 2015 +0200
Remove our own hardcoded section numbers from subsubsections.
If we need them in the future, check this git history. --- 2015/hidden-service-stats/hidden-service-stats.tex | 49 +++++++++----------- 1 file changed, 21 insertions(+), 28 deletions(-)
diff --git a/2015/hidden-service-stats/hidden-service-stats.tex b/2015/hidden-service-stats/hidden-service-stats.tex index d3ad6c4..d2650ea 100644 --- a/2015/hidden-service-stats/hidden-service-stats.tex +++ b/2015/hidden-service-stats/hidden-service-stats.tex @@ -547,7 +547,7 @@ This could reveal the introduction points of hidden services with encrypted descriptors.
\subsubsection{Time from establishing introduction point to tearing down -circuit (1.1.4.)} +circuit} \label{subsubsec:time_intro_to_teardown}
\textbf{Details:} @@ -566,7 +566,7 @@ This statistic can also be used to analyze what fraction of services is available for a short time only, and what fraction is available most of the time.
-\subsubsection{Number of hidden service descriptors seen by directory (3.1.1.)} +\subsubsection{Number of hidden service descriptors seen by directory} \label{subsubsec:num_descriptor_publish}
\textbf{Details:} @@ -621,7 +621,7 @@ period. If this ever becomes a problem we can imagine publishing fake descriptors
-\subsubsection{Number of descriptor updates per service (3.1.2.)} +\subsubsection{Number of descriptor updates per service} \label{subsubsec:num_decriptor_updates}
\textbf{Details:} @@ -668,8 +668,7 @@ introduction points change. There is an upper bound on this statistic at 24 hours, because that's when descriptor identifiers change.
-\subsubsection{Number of introduction points contained in descriptors -(3.1.4.)} \label{subsubsec:num_ips_in_descriptors} +\subsubsection{Number of introduction points contained in descriptors} \label{subsubsec:num_ips_in_descriptors}
\textbf{Details:} % @@ -702,7 +701,7 @@ The following statistics are about service usage, where performance-related statistics and failure statistics are covered at a later time.
-\subsubsection{Number of descriptor fetch requests (3.2.1.)} +\subsubsection{Number of descriptor fetch requests} \label{subsubsec:num_desc_fetches}
\textbf{Details:} @@ -728,8 +727,7 @@ the target HS is assigned to them. This is a major problem that doesn't seem resolvable without some kind of anonymization or private aggregation of the per-relay stats.
-\subsubsection{Number of descriptor fetch requests by service identity -(3.2.2.)} \label{subsubsec:num_descriptor_fetches_per_hs} +\subsubsection{Number of descriptor fetch requests by service identity} \label{subsubsec:num_descriptor_fetches_per_hs}
\textbf{Details:} % @@ -752,7 +750,7 @@ then this statistic could give that adversary an exact measure of popularity. %
-\subsubsection{Number of established rendezvous points (2.1.1.)} +\subsubsection{Number of established rendezvous points} \label{subsubsec:num_rps}
\textbf{Details:} @@ -777,7 +775,7 @@ total number of such cells in the network. There is no obvious risk from sharing this number if aggregated over a large enough time period.
-\subsubsection{Number of introductions received from clients (1.2.1.)} +\subsubsection{Number of introductions received from clients} \label{subsubsec:num_intros_from_clients}
\textbf{Details:} @@ -816,7 +814,7 @@ to avoid this problem. % [dgoulet]: No they don't, I confirmed in the code.
\subsubsection{Number of introductions received by established -introduction point (1.2.2.)} \label{subsubsec:num_intros_per_circ} +introduction point} \label{subsubsec:num_intros_per_circ}
\textbf{Details:} % @@ -839,7 +837,7 @@ potentially makes it even easier to differentiate introductions due to different HSes with the same IP. %
-\subsubsection{Number of server rendezvous (2.2.1.)} +\subsubsection{Number of server rendezvous} \label{subsubsec:num_server_rendezvous}
\textbf{Details:} @@ -875,7 +873,7 @@ given client or server.
\subsubsection{Number of cells sent over rendezvous circuits in either -direction (2.3.2.)} \label{subsubsection:num_cells_rend_circ} +direction} \label{subsubsection:num_cells_rend_circ}
\textbf{Details:} % @@ -912,8 +910,7 @@ While total number of cells by direction aggregated over a certain time period should be okay to measure, any statistics going further than that need closer analysis.
-\subsubsection{Time from first client data to tearing down circuit -(2.3.3.)} \label{subsubsec:time_client_data_to_teardown} +\subsubsection{Time from first client data to tearing down circuit} \label{subsubsec:time_client_data_to_teardown}
\textbf{Details:} % @@ -978,7 +975,7 @@ noticeable. \subsection{Performance-related statistics}
\subsubsection{Time from establishing introduction point to receiving -first client introduction (1.2.4.)} +first client introduction} \label{subsubsec:time_ip_est_to_introduce1}
\textbf{Details:} @@ -1005,7 +1002,7 @@ This may not be very useful, but is listed here for completeness. No obvious risks.
\subsubsection{Time from establishing a rendezvous point to receiving the -server rendezvous (2.2.2.)} \label{subsubsec:time_rp_to_rend1} +server rendezvous} \label{subsubsec:time_rp_to_rend1}
\textbf{Details:} % @@ -1027,7 +1024,7 @@ way to measure effectiveness of improvements in the deployed network. % Again, there are at least no obvious risks from gathering this statistic.
-\subsubsection{Time from server rendezvous to first client data (2.3.1.)} +\subsubsection{Time from server rendezvous to first client data} \label{subsubsec:time_rend1_to_data}
\textbf{Details:} @@ -1054,7 +1051,7 @@ Could be a starting point to look at actual logs from relays. But is this what statistics are for?
\subsubsection{Number of failed attempts to establish an introduction -point (1.1.3.)} \label{subsubsec:num_failed_ips} +point} \label{subsubsec:num_failed_ips}
\textbf{Details:} % @@ -1085,8 +1082,7 @@ or a deliberate action (data mangling, unknown attack, DoS, ...). % No obvious risks.
-\subsubsection{Reasons for terminating established introduction points -(1.1.5.)} \label{subsubsec:reasons_end_ips} +\subsubsection{Reasons for terminating established introduction points} \label{subsubsec:reasons_end_ips}
\textbf{Details:} % @@ -1102,8 +1098,7 @@ things more robust. % No obvious risks.
-\subsubsection{Number of descriptors published to the wrong directory -(3.1.7.)} \label{subsubsec:num_descriptors_wrong_hsdir} +\subsubsection{Number of descriptors published to the wrong directory} \label{subsubsec:num_descriptors_wrong_hsdir}
\textbf{Details:} % @@ -1111,7 +1106,7 @@ A relay reports the number of published descriptors that it is not responsible for.
\subsubsection{Number of descriptor fetch requests for non-existent -descriptor (3.2.3.)} \label{subsubsec:num_fetch_nonexistent} +descriptor} \label{subsubsec:num_fetch_nonexistent}
\textbf{Details:} % @@ -1135,8 +1130,7 @@ might reveal information about specific services.
-\subsubsection{Number of discarded client introductions by reason -(1.2.3.)} \label{subsubsec:num_discarded_client_intros} +\subsubsection{Number of discarded client introductions by reason} \label{subsubsec:num_discarded_client_intros}
\textbf{Details:} % @@ -1161,8 +1155,7 @@ More precisely, if absolute numbers are reported, the risk is the same as the risk of reporting the number of received \verb+INTRODUCE1+ cells; if only fractions are reported, it's not that bad. % -\subsubsection{Number of server rendezvous with unknown rendezvous cookie -(2.2.3.)} \label{subsubsec:num_server_rend_unknown_cookie} +\subsubsection{Number of server rendezvous with unknown rendezvous cookie} \label{subsubsec:num_server_rend_unknown_cookie}
\textbf{Details:} %
tor-commits@lists.torproject.org