[tor-commits] [tech-reports/master] Remove our own hardcoded section numbers from subsubsections.

[karsten at torproject.org]

commit a80cfa08c5252ac44b331dd6823893d373639306
Author: George Kadianakis <desnacked at 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:}
 %