[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [tech-reports/master] Remove our own hardcoded section numbers from subsubsections.
commit a80cfa08c5252ac44b331dd6823893d373639306
Author: George Kadianakis <desnacked@xxxxxxxxxx>
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 mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits