[tor-commits] [tech-reports/master] Reformat Sponsor 19 report 2 as Tor tech report.

karsten at torproject.org karsten at torproject.org
Tue Jun 25 21:03:18 UTC 2019


commit 39e8759af1c267b30c74a816d6065ca58d54d20d
Author: Karsten Loesing <karsten.loesing at gmx.net>
Date:   Tue Jun 25 22:59:30 2019 +0200

    Reformat Sponsor 19 report 2 as Tor tech report.
---
 2019/sponsor19/report2/bridges.tex                |  34 +--
 2019/sponsor19/report2/dos-censorship-report2.tex | 258 +++-------------------
 2019/sponsor19/report2/gettor.tex                 |  44 ++--
 2019/sponsor19/report2/help-with-bridges.tex      |   4 +-
 2019/sponsor19/report2/pt-infra-maintenance.tex   |  26 +--
 2019/sponsor19/report2/pt-other-ngen.tex          |   6 +-
 2019/sponsor19/report2/pt-snowflake.tex           |  64 +++---
 2019/sponsor19/report2/tails.tex                  |  18 +-
 2019/sponsor19/report2/tor-censorship.tex         |  14 +-
 2019/sponsor19/report2/tortechrep.cls             |   1 +
 2019/sponsor19/report2/ux-in-bad-networks.tex     |   8 +-
 11 files changed, 140 insertions(+), 337 deletions(-)

diff --git a/2019/sponsor19/report2/bridges.tex b/2019/sponsor19/report2/bridges.tex
index 17d3827..89c4228 100644
--- a/2019/sponsor19/report2/bridges.tex
+++ b/2019/sponsor19/report2/bridges.tex
@@ -22,9 +22,9 @@ addresses of all of the currently known public bridges.
 
 Several areas of work to improve BridgeDB are detailed below.
 
-\section{Improve BridegDB's user experience}
+\subsection{Improve BridegDB's user experience}
 
-\subsection{Localization}
+\subsubsection{Localization}
 
 We need to localize all aspects of the BridgeDB user flow. In some cases, this
 will involve investigating why localization that has already been implemented
@@ -36,7 +36,7 @@ geolocation.
 \maybeurl{https://bugs.torproject.org/26543} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/15404}
 
-\subsection{Improve CAPTCHA usability}
+\subsubsection{Improve CAPTCHA usability}
 
 Users requesting bridge addresses from the BridgeDB web interface are required
 to solve a CAPTCHA before receiving bridge addresses. Our current CAPTCHA
@@ -49,9 +49,9 @@ usable for more people.
 \maybeurl{https://bugs.torproject.org/24607} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/10831}
 
-\section{Investigate design improvements}
+\subsection{Investigate design improvements}
 
-\subsection{Improve the current BridgeDB implementation}
+\subsubsection{Improve the current BridgeDB implementation}
 
 We need to consider ways to improve the design of the BridgeDB service. First
 we need to assess current usage patterns such as which distribution mechanisms
@@ -73,7 +73,7 @@ bridges.
 
 \maybeurl{https://bugs.torproject.org/29288}
 
-\subsection{Add automated monitoring}
+\subsubsection{Add automated monitoring}
 
 The BridgeDB service needs automated monitoring to ensure availability of all
 aspects of the service. This should include whether the email request mechanism
@@ -84,13 +84,13 @@ anti-censorship infrastructure.
 \maybeurl{https://bugs.torproject.org/12802} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/30152}
 
-\subsection{Monitor the bridge authority \bluesmallcaps{completed}}
+\subsubsection{Monitor the bridge authority \bluesmallcaps{completed}}
 
 The bridge authority is currently monitored by sysmon.
 
 \maybeurl{https://bugs.torproject.org/29229}
 
-\section{Assess and improve the email distribution mechanism}
+\subsection{Assess and improve the email distribution mechanism}
 
 We need to assess whether BridgeDB's email request mechanism is working
 correctly, and consider ways to improve it. One area to address is that an
@@ -109,7 +109,7 @@ user privacy.
 
 \maybeurl{https://bugs.torproject.org/11330}
 
-\section{Current implementation: status and cleanup \bluesmallcaps{completed}}
+\subsection{Current implementation: status and cleanup \bluesmallcaps{completed}}
 
 There are a few areas where we cleaned up BridgeDB's configuration and
 start-up system:
@@ -135,16 +135,16 @@ start-up system:
 \maybeurl{https://bugs.torproject.org/29273} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/29483}
 
-\subsection{Address continuous integration error \bluesmallcaps{completed}}
+\subsubsection{Address continuous integration error \bluesmallcaps{completed}}
 
 We use the Travis continuous integration system for BridgeDB. We closed a ticket
 concerning a temporary error that is no longer happening.
 
 \maybeurl{https://bugs.torproject.org/26154}
 
-\section{Improve BridgeDB deployment}
+\subsection{Improve BridgeDB deployment}
 
-\subsection{Create a software release for BridgeDB}
+\subsubsection{Create a software release for BridgeDB}
 
 Historically, BridgeDB has been deployed and run by the BridgeDB developers. It
 would be better to decouple the development from the deployment and
@@ -156,14 +156,14 @@ easier for NGOs to use private bridges, see Section~\ref{sec:bridges-for-ngos}.
 
 \maybeurl{https://bugs.torproject.org/29276}
 
-\subsection{Document BridgeDB Infrastructure \bluesmallcaps{completed}}
+\subsubsection{Document BridgeDB Infrastructure \bluesmallcaps{completed}}
 
 We documented the configuration of the currently running BridgeDB so that
 we can replicate it when needed.
 
 \maybeurl{https://bugs.torproject.org/29273}
 
-\section{Consider alternative methods of bridge distribution}
+\subsection{Consider alternative methods of bridge distribution}
 
 The traditional way of distributing bridge information is for BridgeDB to give
 out bridge connection information that is then added to the Tor Browser
@@ -176,7 +176,7 @@ be required at the client side to make this work.
 
 \maybeurl{https://bugs.torproject.org/29296}
 
-\section{Distribute IPv6 bridges}
+\subsection{Distribute IPv6 bridges}
 
 BridgeDB does not currently distribute IPv6 bridge addresses, but IPv6
 reachability testing is enabled from the bridge authority and Tor Metrics
@@ -185,7 +185,7 @@ does not distribute these bridges and fix the issue.
 
 \maybeurl{https://bugs.torproject.org/26542}
 
-\section{Protect bridges with robust pluggable transports \bluesmallcaps{completed}}
+\subsection{Protect bridges with robust pluggable transports \bluesmallcaps{completed}}
 
 Many Tor bridges can be used either as regular bridges or as bridges with
 pluggable transports. In these cases, the pluggable transport is reachable on
@@ -212,7 +212,7 @@ if a bridge offers obfs4, BridgeDB only distributes its connection information
 
 \maybeurl{https://bugs.torproject.org/28655}
 
-\section{Collect and export statistics}
+\subsection{Collect and export statistics}
 
 In order to understand how BridgeDB is being used and how we might improve the
 service, we need to collect statistics. Useful metrics might include the number
diff --git a/2019/sponsor19/report2/dos-censorship-report2.tex b/2019/sponsor19/report2/dos-censorship-report2.tex
index 2a9c247..4eab535 100644
--- a/2019/sponsor19/report2/dos-censorship-report2.tex
+++ b/2019/sponsor19/report2/dos-censorship-report2.tex
@@ -1,4 +1,5 @@
-\documentclass[twoside,openright,11pt]{report}
+\documentclass{tortechrep}
+
 
 % Turning the following line into a comment removes our internal trac URLs from
 % the report.
@@ -15,15 +16,18 @@
 
 \newcommand{\todo}[1]{[{\textbf{todo}}: {\em\color{red} #1}]}
 
-\newcommand{\deliverabletitle}{Final Report}
-\newcommand{\deliverabletitleshort}{Final Report}
-\newcommand{\reportnumber}{2}
-\newcommand{\deliverabledate}{May 2019}
+\newcommand{\deliverabletitle}{Addressing Denial of Service Attacks on Free and
+Open Communication on the Internet}
+\newcommand{\deliverablesubtitle}{Final Report}
+\newcommand{\reportnumber}{2019-05-001}
+\newcommand{\deliverabledate}{May 31, 2019}
+\newcommand{\deliverablecontact}{kat at torproject.org}
+\newcommand{\deliverablefootnote}{This work is licensed under a \href{https://creativecommons.org/licenses/by/4.0/legalcode}{Creative Commons Attribution 4.0 International License}. \ccby}
 
 \newcommand{\eg}{\mbox{e.g.}\xspace}
 \newcommand{\ie}{\mbox{i.e.}\xspace}
 
-\newcommand{\deliverableauthorlist}{Cecylia Bocovich, Roger Dingledine, Alexander F\ae r\o y, Kat Hanna, \\ Philipp Winter, Taylor Yu}
+\newcommand{\deliverableauthorlist}{Cecylia Bocovich, Roger Dingledine, Alexander F\ae r\o y, \\ Kat Hanna, Philipp Winter, Taylor Yu}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -32,31 +36,15 @@
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% Document geometry
-%
-
-% Set up for letter rather than A4
-\usepackage[left=.75in,right=.75in,top=1in,bottom=1in,foot=48pt]{geometry}
-
-%\setlength{\textheight}{230mm}
-%\setlength{\textwidth}{160mm}
-%\setlength{\voffset}{-25mm}
-%\setlength{\oddsidemargin}{0mm}
-%\setlength{\evensidemargin}{0mm}
-\addtolength{\parskip}{0.33\baselineskip}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 % Package definitions
 %
 
-\usepackage{helvet}
 \usepackage{graphicx}
 \usepackage{subfigure}
 \usepackage{color}
 \usepackage{xcolor}
 \usepackage{chngcntr}
 \usepackage{longtable}
-\usepackage{lastpage}
 \usepackage{fancyhdr}
 \usepackage{setspace}
 \usepackage{url}
@@ -70,97 +58,11 @@
 \usepackage{ccicons}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% Font definitions
-%
-\renewcommand\familydefault{\sfdefault}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 % Heading style definitions
 %
 
 \setcounter{secnumdepth}{4}
 
-\makeatletter
-\renewcommand{\chapter}{\@startsection{chapter}{0}{0mm}
-  {\baselineskip}%
-  {\baselineskip}{\clearpage\LARGE\bf\color{black}}}
-\renewcommand{\section}{\@startsection{section}{1}{0mm}
-  {\baselineskip}%
-  {\baselineskip}{\LARGE\color{black}}}%
-\renewcommand{\subsection}{\@startsection{subsection}{2}{0mm}
-  {\baselineskip}%
-  {\baselineskip}{\Large\color{black}}}%
-\renewcommand{\subsubsection}{\@startsection{subsubsection}{3}{0mm}
-  {\baselineskip}%
-  {\baselineskip}{\large\color{black}}}%
-\makeatother
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% Table of contents styling
-%
-% Finamore: added dotted lines also for chapters
-% solution found at http://tex.stackexchange.com/questions/62438/how-to-add-leaders-to-table-of-contents-without-tocloft
-\makeatletter
-\renewcommand*\l at chapter[2]{%
-    \ifnum \c at tocdepth >\m at ne
-        \addpenalty{-\@highpenalty}%
-        \vskip 1.0em \@plus\p@
-        \setlength\@tempdima{1.5em}%
-        \begingroup
-        \parindent \z@ \rightskip \@pnumwidth
-        \parfillskip -\@pnumwidth
-        \leavevmode %\bfseries
-        \advance\leftskip\@tempdima
-        \hskip -\leftskip
-        #1\nobreak
-        \xleaders\hbox{$\m at th
-        \mkern \@dotsep mu\hbox{.}\mkern \@dotsep mu$}\hfill%
-        \nobreak\hb at xt@\@pnumwidth{\hss #2}\par
-        \penalty\@highpenalty
-        \endgroup
-    \fi}
-\renewcommand*\l at section{\@dottedtocline{1}{1.5em}{2.3em}}
-\renewcommand*\l at subsection{\@dottedtocline{2}{3.8em}{3.2em}}
-\renewcommand*\l at subsubsection{\@dottedtocline{3}{7.0em}{4.1em}}
-\renewcommand*\l at paragraph{\@dottedtocline{4}{10em}{5em}}
-\renewcommand*\l at subparagraph{\@dottedtocline{5}{12em}{6em}}
-\renewcommand*{\@dotsep}{1}
-\makeatother
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% Header and footer definitions
-%
-
-%\setlength{\headheight}{52pt}
-%\setlength{\footskip}{47pt}
-\renewcommand{\headrulewidth}{0pt}
-\pagestyle{fancyplain}
-
-%\fancyhead[L]{\textsf{DoS Resilience \\ D\reportnumber ~\deliverabletitleshort}}
-\fancyhead[L]{\textsf{Addressing Denial of Service Attacks on Free and Open Communication on the Internet \\ \deliverabletitleshort}}
-\fancyhead[R]{\setlength{\unitlength}{1mm}
-\begin{picture}(0,0)
-  %\put(-70,-4){\includegraphics[width=70mm]{logos/EC-H2020.png}}
-\end{picture}
-}
-\fancyfoot[L]{\setlength{\unitlength}{1mm}
-\begin{picture}(0,0)
-  \put(0,6){\includegraphics[width=10mm]{../torlogo.png}}
-\end{picture}
-}
-\fancyfoot[C]{\vspace{-10mm}\textsf{\thepage\hspace{0.3em}of \pageref{LastPage}}}
-\fancyfoot[R]{\vspace{-10mm}\textsf{\deliverabledate}}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% Miscellaneous document adjustments go here
-
-% Call the bibliography a references section
-\renewcommand*{\bibname}{References}
-
-% Number figures and tables globally
-\counterwithout{figure}{chapter}
-\counterwithout{table}{chapter}
-
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 % Define some colors
 
@@ -172,29 +74,6 @@
 \definecolor{measurementred}{RGB}{255, 128, 128}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% Define some useful commands
- %\EDNOTE{who}{what} - place an editor's note in the document.
- %\INNOTE{who}{what} - place an inline note in the document
-
-\newcommand{\EDNOTE}[2]{
-  \par\large\centerline{
-  \mbox{
-  \begin{tabular}{ll}
-    \textsf{\textbf{#1}} &
-    \fbox{
-    \begin{minipage}{0.6\linewidth}
-      \em\color{red} #2
-    \end{minipage}
-    }
-  \end{tabular}
-  }}
-  \par\vspace{4mm}
-}
-
-\newcommand{\INNOTE}[2]{[\textsf{\textbf{#1}}: {\em\color{red} #2}]}
-
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \acrodef{AQM}{Active Queue Management}
 \acrodef{ECN}{Explicit Congestion Notification}
@@ -219,154 +98,77 @@
 % Front page
 %
 \begin{document}
-\thispagestyle{empty}
-\parindent0pt
-
-\newcolumntype{R}[1]{>{\raggedleft}p{#1}}
 
-%\begin{tabular}{R{130mm} p{26mm}}
-%    \vspace{0pt}
-%    {\bf\small\color{darkgray} H2020 European Union funding \\ for Research \& Innovation}
-%    {\small\color{darkgray} This project has received funding from the funder \\
-%    research and innovation programme under grant agreement No $x$ where $x > 0$.}
-%
-%    &
-%    \vspace{0pt}
-%    %\includegraphics[width=26mm]{logos/eu_flag_small.jpg}
-%\end{tabular}
-
-\vspace{20mm}
-
-\begin{center}
-\hspace{-3mm}\includegraphics[width=90mm]{../torlogo.png}
-\end{center}
-
-\vspace{5mm}
-\centerline{\rule{0em}{1.5em}\LARGE\bf\color{black}Addressing Denial of Service Attacks on}
-\vspace{5mm}
-\centerline{\rule{0em}{1.5em}\LARGE\bf\color{black}Free and Open Communication on the Internet}
-%\vspace{5mm}
-%\centerline{\rule{0em}{1.5em}\bf\Large\color{darkgray}H2020-ICT-688421}
-
-\vspace{20mm}
-
-\begin{centering}
-\fbox{
-  \begin{minipage}{\linewidth}
-    \vspace*{1mm}
-    \center
-    \huge\em\bf\color{darkred}\deliverabletitle
-  \end{minipage}
-}
-%\centerline{\huge\em\bf\color{sangria}\deliverabletitle}
-
-\vspace{2mm}
-
-\fbox{
-  \begin{minipage}{\linewidth}
-      \large\textsf{
-        \begin{tabular}{lll}
-          \textbf{Authors:}
-          \deliverableauthorlist
-        \end{tabular}}
-  \end{minipage}
-}
-
-\vspace{5mm}
-
-\mbox{\begin{minipage}{\linewidth}
-    \textsf{\begin{tabular}{ll}
-        %\textbf{Report Number:}             & D\reportnumber \\
-        \textbf{Date of Delivery:} \deliverabledate\\
-		\\
-		\textbf{Distribution Statement A.} Approved for Public Release, Distribution Unlimited \\
-		\\
-		This work is licensed under a \href{https://creativecommons.org/licenses/by/4.0/legalcode}{Creative Commons Attribution 4.0 International License}. \ccby
-    \end{tabular}}
-
-\end{minipage}
-}
+\title{\deliverabletitle}
+\subtitle{\deliverablesubtitle}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% Disclaimer
-%
-%\clearpage
-%
-% \mbox{\begin{minipage}{\linewidth}
-% \addcontentsline{toc}{chapter}{Disclaimer}
-% {\LARGE\em\bf\color{black}{Disclaimer}}
-%
-% \vspace{10mm}
-% \em{
-% \todo{I guess we need some disclaimer here related to the funding}
-% }
-% \end{minipage}}
+\author{\deliverableauthorlist}
+\contact{\deliverablecontact}
 
+\reportid{\reportnumber\footnote{\deliverablefootnote}}
 
- \end{centering}
+\date{\deliverabledate}
+\maketitle
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 % Table of contents
 %
-\clearpage
 \tableofcontents
 
-\chapter{Introduction}
-%\addcontentsline{toc}{chapter}{Introduction}
+\section{Introduction}
 \label{chap:intro}
 
 \input{intro.tex}
 
-\chapter{Improving the BridgeDB Service}
+\section{Improving the BridgeDB Service}
 \label{chap:bridgedb}
 
 \input{bridges.tex}
 
-\chapter{Improving the GetTor Service}
+\section{Improving the GetTor Service}
 \label{chap:gettor}
 
 \input{gettor.tex}
 
-\chapter{Pluggable Transports: Infrastructure and Maintenance}
+\section{Pluggable Transports: Infrastructure and Maintenance}
 
 \input{pt-infra-maintenance.tex}
 
-\chapter{Pluggable Transports: Snowflake}
+\section{Pluggable Transports: Snowflake}
 
 \input{pt-snowflake.tex}
 
-\chapter{Pluggable Transports: Other Next Generation PTs}
+\section{Pluggable Transports: Other Next Generation PTs}
 
 \input{pt-other-ngen.tex}
 
-\chapter{Improving User Experience for Poor Networks}
+\section{Improving User Experience for Poor Networks}
 
 \input{ux-in-bad-networks.tex}
 
-\chapter{Understanding Censorship of the Tor Network}
+\section{Understanding Censorship of the Tor Network}
 
 \input{tor-censorship.tex}
 
-\chapter{Making Tor Bridges Easier to Use}
+\section{Making Tor Bridges Easier to Use}
 
 \input{help-with-bridges.tex}
 
-\chapter{Expanding Community Outreach}
+\section{Expanding Community Outreach}
 
 \input{community.tex}
 
-\chapter{Tails}
+\section{Tails}
 
 \input{tails.tex}
 
-\chapter{Conclusion}
+\section{Conclusion}
 
 \input{conclusion.tex}
 
-\chapter{Acknowledgements}
+\section{Acknowledgements}
 \input{acknowledgements.tex}
 
-\bibliographystyle{plain}
 \bibliography{../sponsor19,../rfc,../tortechreports,../references}
 
 \end{document}
diff --git a/2019/sponsor19/report2/gettor.tex b/2019/sponsor19/report2/gettor.tex
index 840713f..529a436 100644
--- a/2019/sponsor19/report2/gettor.tex
+++ b/2019/sponsor19/report2/gettor.tex
@@ -12,9 +12,9 @@ Email and Twitter have been the channels used in the past, but we are exploring
 new channels, as well. GetTor also uses multiple providers to host the
 Tor Browser software bundles that users download.
 
-\section{Assess and improve distribution channels and software providers}
+\subsection{Assess and improve distribution channels and software providers}
 
-\subsection{Consider more channels and providers}
+\subsubsection{Consider more channels and providers}
 
 GetTor currently delivers links to the Tor Browser software through email and
 over Twitter. We need to evaluate using other messaging platforms to deliver
@@ -26,7 +26,7 @@ additional providers to host the bundles.
 
 \maybeurl{https://bugs.torproject.org/28231}
 
-\subsection{Twitter}
+\subsubsection{Twitter}
 
 There are a few issues related to the Twitter distribution method that need
 addressing.
@@ -47,9 +47,9 @@ addressing.
 
 \end{itemize}
 
-\section{Improve software bundle distribution}
+\subsection{Improve software bundle distribution}
 
-\subsection{Automate updates to providers}
+\subsubsection{Automate updates to providers}
 
 In order to ensure that we are always serving links to the latest Tor Browser
 packages, we need to automate the delivery of the packages to each of the
@@ -63,7 +63,7 @@ recent version.
 \maybeurl{https://bugs.torproject.org/14744} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/22664}
 
-\subsection{Create more secure cloud accounts}
+\subsubsection{Create more secure cloud accounts}
 
 The Github repository is part of the official Tor Project Github account, but
 the accounts at other providers are currently personal accounts. We need to
@@ -74,7 +74,7 @@ inauthentic versions of Tor Browser.
 
 \maybeurl{https://bugs.torproject.org/10692}
 
-\subsection{Consider providing links to the alpha bundle}
+\subsubsection{Consider providing links to the alpha bundle}
 
 We don't currently make the alpha version of Tor Browser available through
 GetTor, but we should consider doing so because some users in censored
@@ -85,13 +85,13 @@ trade-off between offering this previous version or the alpha version.
 
 \maybeurl{https://bugs.torproject.org/20770}
 
-\section{Improve software integrity checks}
+\subsection{Improve software integrity checks}
 
 Because GetTor helps users retrieve software from a variety of locations with
 varying levels of security, we need to make sure there are easy ways for users
 to verify the integrity of the software they get.
 
-\subsection{Improve instructions for checking software bundle integrity}
+\subsubsection{Improve instructions for checking software bundle integrity}
 
 We need to provide simple, straightforward instructions to help users verify
 the integrity of the software bundles they download. We want to do this by
@@ -101,7 +101,7 @@ walks the users through doing the check.
 
 \maybeurl{https://bugs.torproject.org/17425}
 
-\subsection{Deliver checksums for the software bundles}
+\subsubsection{Deliver checksums for the software bundles}
 
 Sometimes GetTor needs to deliver the Tor Browser software over insecure
 channels, for example, if the software bundle is too large to be allowed over
@@ -113,7 +113,7 @@ to the bundle.
 
 \maybeurl{https://bugs.torproject.org/3980}
 
-\subsection{Check integrity of hosted software periodically}
+\subsubsection{Check integrity of hosted software periodically}
 
 We should create an automated script that periodically downloads our software
 from the cloud providers we use to serve it and checks its integrity. This
@@ -121,7 +121,7 @@ would alert us in case files are altered or otherwise become corrupted.
 
 \maybeurl{https://bugs.torproject.org/17214}
 
-\section{Improve translation coverage}
+\subsection{Improve translation coverage}
 
 We need to add the GetTor service to our translation process and get it
 translated into our standard languages. It is especially important that we have
@@ -136,16 +136,16 @@ Transifex, which is the tool we currently use for translations.
 \maybeurl{https://bugs.torproject.org/28284} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/19693}
 
-\section{Improve logging and monitoring}
+\subsection{Improve logging and monitoring}
 
-\subsection{Add monitoring}
+\subsubsection{Add monitoring}
 
 As part of our larger effort to monitor all of our anti-censorship
 infrastructure, we need to start monitoring the GetTor service.
 
 \maybeurl{https://bugs.torproject.org/30152}
 
-\subsection{Improve log handling}
+\subsubsection{Improve log handling}
 
 We need to update GetTor's logging to make it more useful for debugging and to
 collect usage statistics. More specifically, we need to implement log levels to
@@ -156,9 +156,9 @@ GetTor.
 
 \maybeurl{https://bugs.torproject.org/28339}
 
-\section{Improve documentation}
+\subsection{Improve documentation}
 
-\subsection{Specification document}
+\subsubsection{Specification document}
 
 There is an old draft of a specification document that was created several
 years ago. We need to update it to reflect the current state of GetTor, as well
@@ -166,7 +166,7 @@ as our near-term plans for the project.
 
 \maybeurl{https://bugs.torproject.org/3781}
 
-\subsection{Documentation included with the code \bluesmallcaps{completed}}
+\subsubsection{Documentation included with the code \bluesmallcaps{completed}}
 
 We updated some of the GetTor documentation: 
 
@@ -185,9 +185,9 @@ We updated some of the GetTor documentation:
 
 \maybeurl{https://bugs.torproject.org/28234}
 
-\section{Improve the code base}
+\subsection{Improve the code base}
 
-\subsection{Use the Twisted framework \bluesmallcaps{completed}}
+\subsubsection{Use the Twisted framework \bluesmallcaps{completed}}
 
 We have refactored the GetTor code to create a Twisted daemon.  We have chosen
 the Twisted framework because it handles all of the necessary networking
@@ -202,14 +202,14 @@ the latest version of Tor Browser.
 
 \maybeurl{https://bugs.torproject.org/28152}
 
-\subsection{Port to Python 3 \bluesmallcaps{completed}}
+\subsubsection{Port to Python 3 \bluesmallcaps{completed}}
 
 GetTor was originally written in Python 2, which goes out of support in 2020.
 In preparation, we ported GetTor to Python 3.
 
 \maybeurl{https://bugs.torproject.org/28091}
 
-\subsection{Implement test functionality}
+\subsubsection{Implement test functionality}
 
 We need to implement unit tests and ensure adequate coverage of the code base.
 
diff --git a/2019/sponsor19/report2/help-with-bridges.tex b/2019/sponsor19/report2/help-with-bridges.tex
index 3719c95..26bdaf0 100644
--- a/2019/sponsor19/report2/help-with-bridges.tex
+++ b/2019/sponsor19/report2/help-with-bridges.tex
@@ -1,4 +1,4 @@
-\section{Help NGOs use private bridges}
+\subsection{Help NGOs use private bridges}
 \label{sec:bridges-for-ngos}
 
 While our eventual goal is to create automated methods for bridge address
@@ -28,7 +28,7 @@ to host the private bridges.
 \maybeurl{https://bugs.torproject.org/28526} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/28015}
 
-\section{Improve automated bridge set-up}
+\subsection{Improve automated bridge set-up}
 \label{sec:auto-bridge-setup}
 
 The introduction of the moat feature in Tor Browser 8.0 significantly
diff --git a/2019/sponsor19/report2/pt-infra-maintenance.tex b/2019/sponsor19/report2/pt-infra-maintenance.tex
index c6daa98..2148e28 100644
--- a/2019/sponsor19/report2/pt-infra-maintenance.tex
+++ b/2019/sponsor19/report2/pt-infra-maintenance.tex
@@ -17,7 +17,7 @@ these areas, we must also continue to research and develop the next generation
 of pluggable transports; Sections~\ref{sec:pt-snowflake}
 and~\ref{sec:pt-other-ngen} describe that work.
 
-\section{Improve logging and status messages \bluesmallcaps{partially completed}}
+\subsection{Improve logging and status messages \bluesmallcaps{partially completed}}
 
 \label{sec:pt-log-message-passing}
 
@@ -69,7 +69,7 @@ account. A possible order follows:
 \maybeurl{https://bugs.torproject.org/28925} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/28930}
 
-\section{Specify which outbound interface to use}
+\subsection{Specify which outbound interface to use}
 
 Tor can be configured to use a particular outbound network interface, but there
 is currently no way to tell a pluggable transport that it should use that
@@ -79,7 +79,7 @@ look for and honor the preference.
 
 \maybeurl{https://bugs.torproject.org/5304}
 
-\section{Make pluggable transports more mobile friendly}
+\subsection{Make pluggable transports more mobile friendly}
 
 Currently, when a pluggable transport has been launched but is not being used,
 it remains running in the background, sometimes even making network
@@ -95,7 +95,7 @@ pluggable transports and Tor.
 
 \maybeurl{https://bugs.torproject.org/28849}
 
-\section{Better testing for pluggable transports}
+\subsection{Better testing for pluggable transports}
 
 We need to ensure that we have good test coverage for pluggable transports.
 This includes getting common pluggable transports included in our Chutney
@@ -113,7 +113,7 @@ for all current and future pluggable transports.
 \maybeurl{https://bugs.torproject.org/29259} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/29274}
 
-\subsection{Reachability self testing}
+\subsubsection{Reachability self testing}
 
 Bridges that offer pluggable transports don't currently have a way to test
 their reachability. This means that operators may not be able to tell if their
@@ -135,7 +135,7 @@ BridgeDB.
 
 \maybeurl{https://bugs.torproject.org/30472}
 
-\section{Enable Tor Browser to use other circumvention tools}
+\subsection{Enable Tor Browser to use other circumvention tools}
 
 Sometimes when access to the Tor network is blocked, other censorship
 circumvention tools may still work in the censored location. In such a case,
@@ -162,7 +162,7 @@ cooperation with the makers of the tools.
 	\item Design and implement an update to Tor Launcher so that it can configure Tor Browser to use the tools and add them as options in Tor Browser's pluggable transport selection menu.
 \end{enumerate}
 
-\section{Maintain currently deployed pluggable transports}
+\subsection{Maintain currently deployed pluggable transports}
 
 Although it is important to look ahead to the next generation of pluggable
 transports (see Sections~\ref{sec:pt-snowflake} and~\ref{sec:pt-other-ngen}), we
@@ -175,7 +175,7 @@ which countries, as well as how censors block Tor, is essential to maintaining
 current pluggable transports and designing new ones. For more information on
 understanding how Tor is blocked, see Section~\ref{sec:tor-censorship}.
 
-\subsection{obfs4proxy}
+\subsubsection{obfs4proxy}
 
 Obfs4proxy (or obfs4) is a pluggable transport that defends against active
 probing attacks so it is resilient against blocking by many censored countries,
@@ -204,7 +204,7 @@ and work to fix it. If it is not, then it is one of the viable pluggable
 transports, so we need to allocate resources to fixing known issues and
 maintaining its code base.
 
-\subsection{Domain fronting}
+\subsubsection{Domain fronting}
 \label{sec:domain-fronting}
 
 Domain fronting---a system in which a client makes a connection to an
@@ -232,15 +232,15 @@ server to host multiple websites, may offer some possibilities for domain
 fronting as it gains wider deployment. We should monitor developments in this
 area.
 
-\subsection{meek}
+\subsubsection{meek}
 
 As part of ongoing maintenance of meek, we fixed a bug where the meek client
 for Tor Browser and its child Firefox process would continue to run after Tor
 Browser was closed.
 
-\section{Looking to the future}
+\subsection{Looking to the future}
 
-\subsection{Maintain relationships with research groups}
+\subsubsection{Maintain relationships with research groups}
 
 One Tor Project priority is maintaining good relationships with academic
 research groups that study privacy enhancing technologies in general, and
@@ -254,7 +254,7 @@ Open Communications on the Internet and the Privacy Enhancing Technologies
 Symposium, and by visiting their institutions. We also plan to invite pluggable
 transport researchers to our biannual Tor meetings.
 
-\subsection{Consider ways to improve the pluggable transport specification}
+\subsubsection{Consider ways to improve the pluggable transport specification}
 
 We want to make it easier for developers and academics to design and
 implement new pluggable transports and get them easily integrated with Tor so
diff --git a/2019/sponsor19/report2/pt-other-ngen.tex b/2019/sponsor19/report2/pt-other-ngen.tex
index 28a1dc9..d0b55f4 100644
--- a/2019/sponsor19/report2/pt-other-ngen.tex
+++ b/2019/sponsor19/report2/pt-other-ngen.tex
@@ -1,6 +1,6 @@
 \label{sec:pt-other-ngen}
 
-\section{Marionette}
+\subsection{Marionette}
 
 Marionette, an open source pluggable transport designed and
 developed by RedJack, LLC, can make Tor traffic look like traffic from a
@@ -17,7 +17,7 @@ running Marionette.
 \maybeurl{https://bugs.torproject.org/29272} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/26920}
 
-\section{HTTPS proxy}
+\subsection{HTTPS proxy}
 
 HTTPS proxy uses the HTTPS CONNECT method to instruct a proxy server to relay
 traffic between a Tor client and a Tor relay. The traffic between the client
@@ -43,7 +43,7 @@ them.
 \maybeurl{https://bugs.torproject.org/26923} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/29278}
 
-\section{Design and develop new pluggable transports}
+\subsection{Design and develop new pluggable transports}
 
 Censorship circumvention is an arms race, so it is prudent to be looking ahead
 to the next technique. We need to begin planning, designing, and implementing
diff --git a/2019/sponsor19/report2/pt-snowflake.tex b/2019/sponsor19/report2/pt-snowflake.tex
index b3a7248..5c1271e 100644
--- a/2019/sponsor19/report2/pt-snowflake.tex
+++ b/2019/sponsor19/report2/pt-snowflake.tex
@@ -26,7 +26,7 @@ Figure~\ref{fig:snowflake-arch} illustrates Snowflake's architecture.
 \label{fig:snowflake-arch}
 \end{figure}
 
-\section{Document the current broker implementation \bluesmallcaps{completed}}
+\subsection{Document the current broker implementation \bluesmallcaps{completed}}
 
 An experimental Snowflake prototype is currently integrated in Tor Browser's
 alpha releases for Mac OS and Linux, but much work remains to make it ready for
@@ -38,7 +38,7 @@ implementation.
 
 \maybeurl{https://bugs.torproject.org/28848}
 
-\section{Improve the Snowflake Protocol}
+\subsection{Improve the Snowflake Protocol}
 
 We plan to redesign the Snowflake protocol to make it extensible and to enable
 us to collect useful metrics. This section outlines ideas and questions for
@@ -46,7 +46,7 @@ this redesign.
 
 See also: \url{https://github.com/ahf/snowflake-notes/blob/master/Protocol.markdown}
 
-\subsection{Client to snowflake proxy protocol}
+\subsubsection{Client to snowflake proxy protocol}
 
 A Snowflake client connects to a snowflake to send traffic to a Tor bridge and
 then on to the Tor network. We want to add the ability to send some control
@@ -66,7 +66,7 @@ messages between the client and snowflake.
 
 \end{itemize}
 
-\subsection{Snowflake to broker protocol}
+\subsubsection{Snowflake to broker protocol}
 
 Currently snowflakes do a \emph{long poll} to the broker. A long poll in this
 context is an HTTP request where the server reads the request, but doesn't send
@@ -109,7 +109,7 @@ to signal an overly eager snowflake to wait before attempting to connect again.
 	
 \end{itemize}
 
-\subsection{Client to broker protocol}
+\subsubsection{Client to broker protocol}
 
 A Snowflake client asks the Snowflake broker to give it a snowflake to relay
 its traffic through.
@@ -151,7 +151,7 @@ We should explore using various options for connecting to the broker:
 
 \maybeurl{https://bugs.torproject.org/29293}
 
-\subsection{Broker to broker protocol}
+\subsubsection{Broker to broker protocol}
 
 Currently, we have a single Snowflake broker. If that broker were to become
 unavailable, it would be impossible for snowflakes to announce themselves and
@@ -167,7 +167,7 @@ system as a whole.
 
 This protocol is lower priority than the others in this section.
 
-\subsection{Better resilience against Dos attacks for the broker}
+\subsubsection{Better resilience against Dos attacks for the broker}
 
 The broker needs to be more resilient against DoS attacks. In addition to
 traditional DoS techniques (for example SYN floods, packet floods, memory
@@ -181,7 +181,7 @@ a client.
 \maybeurl{https://bugs.torproject.org/25593} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/25681}
 
-\section{Useful metrics}
+\subsection{Useful metrics}
 
 We need to collect some information to better understand where Snowflake users
 are located, where volunteer snowflakes are located, what kind of load the
@@ -226,14 +226,14 @@ many times.
 
 https://bugs.torproject.org/21315
 
-\section{Build Snowflake into Tor Browser}
+\subsection{Build Snowflake into Tor Browser}
 
 This section describes several areas of work we need to do to create a viable
 version of Snowflake that we will integrate into the main Tor Browser release.
 
 \maybeurl{https://bugs.torproject.org/19001}
 
-\subsection{Reproducible builds}
+\subsubsection{Reproducible builds}
 
 We need to examine Snowflake's dependencies and analyze how difficult it will
 be to integrate into Tor's build processes.
@@ -241,7 +241,7 @@ be to integrate into Tor's build processes.
 \maybeurl{https://bugs.torproject.org/28672} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/25483}
 
-\subsection{Include libwebrtc license files in software release}
+\subsubsection{Include libwebrtc license files in software release}
 
 We need to ensure that we include the appropriate Chromium license files for
 the WebRTC library in our software release. If we decide to use another
@@ -249,12 +249,12 @@ library, we need to include the appropriate license files for that library.
 
 \maybeurl{https://bugs.torproject.org/19315}
 
-\subsection{Add Snowflake to Tor Launcher}
+\subsubsection{Add Snowflake to Tor Launcher}
 
 We need to add Snowflake to Tor Launcher so that a user can select Snowflake
 from the pluggable transport menu.
 
-\section{More Snowflake bridges}
+\subsection{More Snowflake bridges}
 
 The current implementation of Snowflake's client-side proxy hard codes the URL
 of the Snowflake bridge. To provide more resiliency and to support more load, we
@@ -290,7 +290,7 @@ located in areas where censorship is not a big concern.
 
 \maybeurl{https://bugs.torproject.org/28651}
 
-\section{Easier ways to run a snowflake}
+\subsection{Easier ways to run a snowflake}
 
 We are in the process of revamping the web page a volunteer visits to make
 their browser a snowflake. User experience is important here so that the
@@ -328,9 +328,9 @@ more fun.
 
 \maybeurl{https://bugs.torproject.org/20813}
 
-\section{Snowflake connection multiplexing}
+\subsection{Snowflake connection multiplexing}
 
-\subsection{One snowflake supports multiple clients}
+\subsubsection{One snowflake supports multiple clients}
 
 Currently, each snowflake can handle one client at a time. This is fine if the
 number of snowflakes is always much bigger than the number of clients. It
@@ -340,7 +340,7 @@ in clients.
 
 \maybeurl{https://bugs.torproject.org/25601}
 
-\subsection{One client uses multiple snowflakes}
+\subsubsection{One client uses multiple snowflakes}
 
 Currently, each client sends traffic through a single snowflake. If that
 snowflake is slow, performance is degraded. We would like to allow a client
@@ -354,9 +354,9 @@ being used.
 
 \maybeurl{https://bugs.torproject.org/25723}
 
-\section{Improve safety for users}
+\subsection{Improve safety for users}
 
-\subsection{End-to-end confidentiality for client registration}
+\subsubsection{End-to-end confidentiality for client registration}
 
 A Snowflake client uses domain fronting to connect to the broker. The
 connection to the front domain uses TLS, as does the connection from the front
@@ -373,7 +373,7 @@ server and facilitator CGI.
 
 \maybeurl{https://bugs.torproject.org/22945}
 
-\subsection{Sanitize Snowflake logs \bluesmallcaps{completed}}
+\subsubsection{Sanitize Snowflake logs \bluesmallcaps{completed}}
 
 In certain error situations, for example, when the WebSocket server panics,
 client IP addresses are written to Snowflake logs. Because this compromises
@@ -388,14 +388,14 @@ proxy.
 \maybeurl{https://bugs.torproject.org/21304} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/30125}
 
-\subsection{Fingerprinting resistance}
+\subsubsection{Fingerprinting resistance}
 
 In order to defeat DPI, Snowflake's traffic patterns need to be as
 indistinguishable as possible from regular WebRTC traffic. We need to analyze
 WebRTC's network layer so that we understand how both DataChannel traffic and
 MediaStream traffic look and compare that to how Snowflake traffic looks.
 
-\section{An improved WebRTC library}
+\subsection{An improved WebRTC library}
 
 In addition to data channels for communication between peers, WebRTC comes with
 a variety of audio and video capabilities that include various codecs.
@@ -420,9 +420,9 @@ and Tor Browser disables WebRTC to avoid leaks of IP addresses.
 
 \maybeurl{https://bugs.torproject.org/29205}
 
-\section{Test environments}
+\subsection{Test environments}
 
-\subsection{Better test coverage}
+\subsubsection{Better test coverage}
 
 To make sure Snowflake is reliable, we need to ensure that our code has a high
 degree of test coverage. Part of this will be accomplished by including it in
@@ -430,7 +430,7 @@ our Chutney continuous integration process.
 
 \maybeurl{https://bugs.torproject.org/29024}
 
-\subsection{An automated local test environment \bluesmallcaps{completed}}
+\subsubsection{An automated local test environment \bluesmallcaps{completed}}
 
 We created a locally networked testing environment for Snowflake that can
 easily and automatically be set up and run. This includes easy installation and
@@ -446,7 +446,7 @@ continuous integration with gitlab:
 
 \maybeurl{https://bugs.torproject.org/29489}
 
-\subsection{Test suite for NAT topologies}
+\subsubsection{Test suite for NAT topologies}
 
 One of the strengths of Snowflake (as opposed to Flashproxy) is that WebRTC
 allows incoming connections to computers that are subject to NAT---a very
@@ -456,7 +456,7 @@ NAT topologies.
 
 \maybeurl{https://bugs.torproject.org/25595}
 
-\section{Add disk space monitoring}
+\subsection{Add disk space monitoring}
 
 We need to set up disk space monitoring at both the broker and the default
 Snowflake bridge to avoid situations where full disks prevent Snowflake from
@@ -466,12 +466,12 @@ ant-censorship infrastructure.
 \maybeurl{https://bugs.torproject.org/30152} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/29863}
 
-\section{Address known issues}
+\subsection{Address known issues}
 
 We have identified several known issues that it is a priority to investigate
 and address.
 
-\subsection{snowflake-client needs to stop using my network when I'm not giving it requests}
+\subsubsection{snowflake-client needs to stop using my network when I'm not giving it requests}
 
 When the user turns Snowflake off, the Snowflake client continues to contact
 the broker every 10 seconds to ask for a snowflake, resulting in unnecessary
@@ -481,7 +481,7 @@ received a request or whenever it isn't handling a request.
 
 \maybeurl{https://bugs.torproject.org/21314}
 
-\subsection{Need something better than client's `checkForStaleness`}
+\subsubsection{Need something better than client's `checkForStaleness`}
 
 We currently have code in place to check the staleness of a connection between
 a client and a snowflake to prevent long-lived, broken connections from
@@ -492,7 +492,7 @@ in a way that does not result in these repeated disconnections.
 
 \maybeurl{https://bugs.torproject.org/25429}
 
-\subsection{proxy-go is still deadlocking occasionally \bluesmallcaps{completed}}
+\subsubsection{proxy-go is still deadlocking occasionally \bluesmallcaps{completed}}
 
 Our test snowflakes were hanging after they had been running for a few days.
 All of the snowflakes exhibited this behavior, but the more heavily used
@@ -511,7 +511,7 @@ the connection is complete.
 
 \maybeurl{https://bugs.torproject.org/25688}
 
-\subsection{Guard against large reads \bluesmallcaps{completed}}
+\subsubsection{Guard against large reads \bluesmallcaps{completed}}
 
 The broker sends and receives relatively small messages when it communicates
 with the clients and the snowflakes. We have limited the resources we allocate
diff --git a/2019/sponsor19/report2/tails.tex b/2019/sponsor19/report2/tails.tex
index e315249..4da302a 100644
--- a/2019/sponsor19/report2/tails.tex
+++ b/2019/sponsor19/report2/tails.tex
@@ -12,7 +12,7 @@ safe, including Tor Browser, an instant messaging client, and an email client.
 All of the applications on Tails are configured to connect to the internet over
 the Tor network.
 
-\section{Address known clock-related issues}
+\subsection{Address known clock-related issues}
 
 When the hardware clock of the computer Tails is running on is not set to the
 current, correct UTC time, it is very difficult for applications to connect to
@@ -45,7 +45,7 @@ the local time zone on the desktop.
 %   for all Tails users and improve UX by displaying time in the local
 %   timezone in the desktop.
 
-\section{Cache the Tor consensus}
+\subsection{Cache the Tor consensus}
 
 Many users in censored locations have slow internet connections. To improve
 usability, Tails plans to cache Tor consensus information, so that it can be
@@ -60,7 +60,7 @@ fetched less frequently, which will improve usability.
 %
 %   This requires fixing our time synchronization system (1).
 
-\section{Improve network connection UX}
+\subsection{Improve network connection UX}
 
 In the context of an operating system such as Tails, whether or not Tor is
 blocked is only part of the story: users also encounter captive portals,
@@ -82,9 +82,9 @@ with paper prototypes.
 %   We have a design that has already gone through usability testing
 %   with paper prototypes.
 
-\section{Make bridges easier to use}
+\subsection{Make bridges easier to use}
 
-\subsection{Better bridge configuration}
+\subsubsection{Better bridge configuration}
 \label{sec:tails-bridge-config}
 
 Currently, Tails does not include default bridges for applications other than
@@ -107,7 +107,7 @@ planned.
 %   feature requires allowing Tails users to configure their own
 %   bridges/PTs in a persistent manner.
 
-\subsection{Moat}
+\subsubsection{Moat}
 
 The Tails team plans to integrate automatic bridge and pluggable transport
 configuration using Tor Browser's moat feature. Implementing this depends on
@@ -120,9 +120,9 @@ the Tor Network.
 %   For the same reasons as Tor Browser. Same technical difficulty
 %   as Meek.
 
-\section{Support more pluggable transports}
+\subsection{Support more pluggable transports}
 
-\subsection{meek}
+\subsubsection{meek}
 
 Because the meek pluggable transport (see Section~\ref{sec:domain-fronting})
 has proven resilient to blocking in some of the more challenging censored
@@ -151,7 +151,7 @@ application that connects to the internet without using Tor.
 %   work with Wayland anymore so we need to find and implement
 %   another one.
 
-\subsection{Snowflake}
+\subsubsection{Snowflake}
 
 After Snowflake is offered in the stable version of Tor Browser, the Tails team
 plans to offer Snowflake support as well.
diff --git a/2019/sponsor19/report2/tor-censorship.tex b/2019/sponsor19/report2/tor-censorship.tex
index 1cfd812..7702836 100644
--- a/2019/sponsor19/report2/tor-censorship.tex
+++ b/2019/sponsor19/report2/tor-censorship.tex
@@ -25,7 +25,7 @@ which use DPI to detect and disconnect pluggable transport connections;
 which degrade performance for protocols they don't like. When we create this
 snapshot, we should also put into place a process for keeping it up to date.
 
-\section{A Tor Browser that detects censorship}
+\subsection{A Tor Browser that detects censorship}
 
 In order to get a better understanding of which censored locations specific
 pluggable transports work in, we need a tool for testing them. Some
@@ -47,7 +47,7 @@ had and give us a better idea of what works where.
 \maybeurl{https://bugs.torproject.org/23839} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/28531}
 
-\section{Create and maintain an authoritative list of default bridges}
+\subsection{Create and maintain an authoritative list of default bridges}
 
 Default bridges are the bridges that are pre-configured in Tor Browser. The
 list of these bridges is currently part of the Tor Browser software repository.
@@ -58,7 +58,7 @@ projects.
 
 \maybeurl{https://bugs.torproject.org/30121}
 
-\section{Assess status and reachability of default bridges}
+\subsection{Assess status and reachability of default bridges}
 \label{sec:default-bridges}
 
 Default bridges are the set of bridges that are preconfigured in Tor Browser.
@@ -67,7 +67,7 @@ have a good understanding of whether they are still acting as bridges or from
 which locations they may be censored. We need to implement a process for
 scanning these bridges to answer these questions. 
 
-\subsection{Default bridge reachability \bluesmallcaps{completed}}
+\subsubsection{Default bridge reachability \bluesmallcaps{completed}}
 
 A default bridge may become unreachable because the operator decides not to run
 it anymore. We need an automated way of discovering when a default bridge
@@ -80,7 +80,7 @@ our anti-censorship infrastructure.
 \maybeurl{https://bugs.torproject.org/30152} \maybelinebreak
 \maybeurl{https://bugs.torproject.org/30006}
 
-\subsection{Default bridge blocking}
+\subsubsection{Default bridge blocking}
 
 Default bridges may become unreachable because a censor is blocking them.
 Currently, in some locations, OONI Probe tests whether these bridges are
@@ -104,7 +104,7 @@ Planet~\cite{censored-planet}, or others.
 
 \maybeurl{https://bugs.torproject.org/29277}
 
-\section{Understand bridge load and blocking}
+\subsection{Understand bridge load and blocking}
 \label{sec:bridge-load-blocking}
  
 In order to make good use of Tor bridges, we need to better understand their
@@ -113,7 +113,7 @@ we need to answer include: how are bridges being used; is there a relationship
 between how BridgeDB distributes them and how much load they have; are they
 overloaded; are they long or short lived; who runs them and where?
 
-\section{Get more accurate counts of Tor users}
+\subsection{Get more accurate counts of Tor users}
 \label{sec:better-user-counts}
   
 In order to recognize and respond to censorship events---that is, instances
diff --git a/2019/sponsor19/report2/tortechrep.cls b/2019/sponsor19/report2/tortechrep.cls
new file mode 120000
index 0000000..ce75af9
--- /dev/null
+++ b/2019/sponsor19/report2/tortechrep.cls
@@ -0,0 +1 @@
+../../../tortechrep.cls
\ No newline at end of file
diff --git a/2019/sponsor19/report2/ux-in-bad-networks.tex b/2019/sponsor19/report2/ux-in-bad-networks.tex
index fa2fe43..5832f4f 100644
--- a/2019/sponsor19/report2/ux-in-bad-networks.tex
+++ b/2019/sponsor19/report2/ux-in-bad-networks.tex
@@ -6,7 +6,7 @@ locations with poor network infrastructure or mobile-only connectivity. People
 in censored locations need to take additional steps to connect to the open
 internet and we need to focus on the user experience of those steps, as well.
 
-\section{Make the bootstrapping process faster}
+\subsection{Make the bootstrapping process faster}
 
 We need to better understand the points in the bootstrap process that cause
 delay. Some of the work outlined in~Section \ref{sec:pt-log-message-passing}
@@ -16,7 +16,7 @@ transport, or a proxy used to bypass a firewall. Additional planned work will
 add more granular reporting of events during the bootstrap process, which will
 allow us to pinpoint the activities that are contributing to delay. 
 
-\section{Better support users on slow networks}
+\subsection{Better support users on slow networks}
 
 There are a variety of tuning parameters, possibly at every level of the Tor
 code base, that we need to examine with slow networks in mind. Many of these
@@ -26,7 +26,7 @@ Browser as extremely slow or completely unusable. We need to identify the
 parameters that might be causing poor performance for people on slow networks
 and design solutions that will work for all of our users.
 
-\section{Test pluggable transport latency}
+\subsection{Test pluggable transport latency}
 
 OnionPerf~\cite{onionperf} measures the performance of the Tor network by
 downloading files of various sizes from a web server and recording how long
@@ -38,7 +38,7 @@ each pluggable transport will help us focus our efforts on improving
 performance and allow us to make better recommendations to users on slow
 networks.
 
-\section{Keep the Tor network healthy}
+\subsection{Keep the Tor network healthy}
 
 The health of the Tor network is crucial to all of the services Tor provides,
 including the ability of users to bypass censorship. While it might be ideal to



More information about the tor-commits mailing list