Import PhD thesis

author: Rasmus Dahlberg <rasmus@rgdd.se> 2024-10-15 16:08:16 +0200
committer: Rasmus Dahlberg <rasmus@rgdd.se> 2024-10-15 16:08:16 +0200
commit: 385cc92bc91e1a6c3724085c060e76bf40c13ed3 (patch)
tree: 26d0a8f81f2caa472830fd40a51844bb202c1355 /summary
178 files changed, 18568 insertions, 0 deletions
diff --git a/summary/.gitignore b/summary/.gitignore
new file mode 100644
index 0000000..34841bf
--- /dev/null
+++ b/summary/.gitignore
@@ -0,0 +1,17 @@
+*.aux
+*.fdb_latexmk
+*.fls
+*.log
+*.pap
+*.pcp
+*.sum
+*.toc
+*.bbl
+*.blg
+*.idx
+*.ilg
+*.ind
+*.log
+*.out
+*.run.xml
+main.pdf
diff --git a/summary/clean.sh b/summary/clean.sh
new file mode 100755
index 0000000..0553bcc
--- /dev/null
+++ b/summary/clean.sh
@@ -0,0 +1,13 @@
+#!/bin/bash
+
+to_remove=$(cat .gitignore)
+
+rm -f $to_remove
+for subdir in $(ls -l src/ | grep '^d' | awk '{print $9}'); do
+	pushd src/$subdir >/dev/null
+	rm -f $to_remove
+	popd >/dev/null
+done
+
+clear
+ls -l
diff --git a/summary/kauclear.sty b/summary/kauclear.sty
new file mode 100644
index 0000000..79f1705
--- /dev/null
+++ b/summary/kauclear.sty
@@ -0,0 +1,53 @@
+%%
+%% This is file `kauclear.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kautools.dtx  (with options: `clear')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kautools.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesPackage{kauclear}
+    [2014/10/22 v1.15 Karlstad University kautools bundle]
+\ProcessOptions\relax
+\newcommand\kuc@currentpagestyle{plain}
+\let\pagestyle@orig\pagestyle
+\renewcommand\pagestyle[1]{%
+  \renewcommand\kuc@currentpagestyle{#1}%
+  \pagestyle@orig{#1}%
+}
+\newcommand\kuc@restorepagestyle{%
+  \pagestyle@orig{\kuc@currentpagestyle}%
+}
+\let\cleardoubpage@orig\cleardoublepage
+\renewcommand\cleardoublepage{%
+  \clearpage%
+  \pagestyle@orig{empty}%
+  \cleardoubpage@orig%
+  \kuc@restorepagestyle%
+}
+\endinput
+%%
+%% End of file `kauclear.sty'.
diff --git a/summary/kaucollection.cls b/summary/kaucollection.cls
new file mode 100644
index 0000000..000a356
--- /dev/null
+++ b/summary/kaucollection.cls
@@ -0,0 +1,112 @@
+%%
+%% This is file `kaucollection.cls',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kauthesis.dtx  (with options: `collection')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kauthesis.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesClass{kaucollection}
+    [2014/12/04 v1.16 Karlstad University thesis layout]
+\LoadClass{article}
+\RequirePackage{kauclear}
+\RequirePackage{kaumeta}
+\RequirePackage{kaulist}
+\RequirePackage{kaulanguage}
+\RequirePackage{kaustudies}
+\RequirePackage{kauenvironments}
+\RequirePackage{tikz}
+\RequirePackage{kaupaper}
+\ProcessOptions\relax
+\AtBeginDocument{%
+  \setname{acknowledgementname}{Acknowledgements}{Tacks\"agelser}%
+}
+\AtBeginDocument{%
+  \setname{keywordname}{Keywords}{Nyckelord}%
+}
+\AtBeginDocument{%
+  \setname{introname}{Introductory Summary}{Inledande sammanfattning}%
+}
+\let\kauths@maketitle\maketitle
+\renewcommand\maketitle{%
+  \PackageWarning{maketitle does not serve any purpose in this class.
+    The abstract environment reproduces the title instead.}%
+}
+\let\kauths@abstract\abstract%
+\let\kauths@endabstract\endabstract%
+\newcommand*\frontmatter{%
+  \clearpage%
+  \setcounter{page}{3}%
+  \renewcommand\thepage{\roman{page}}%
+  \renewenvironment{abstract}{%
+    \newcommand\keywords{\paragraph{\keywordname:}}%
+    \newenvironment{english}{%
+      \renewcommand\keywords{\paragraph{Keywords:}}%
+      \section*{Abstract}%
+    }{%
+    }
+    \cleardoublepage%
+    \section*{\@title}%
+    \textsc{\prettylist{\@author}}\par%
+    \noindent\textit{\@institute}%
+    \section*{\abstractname}%
+  }{%
+    \cleardoublepage%
+  }%
+}
+\newenvironment{acknowledgements}{%
+  \cleardoublepage%
+  \section*{\acknowledgementname}%
+}{%
+  \par\bigskip\bigskip\bigskip\noindent\@place, \@date\hfill \prettylist{\@author}%
+  \cleardoublepage%
+}
+\let\kauths@tableofcontents\tableofcontents
+\renewcommand\tableofcontents{%
+  \cleardoublepage%
+  \kauths@tableofcontents%
+}
+\newcommand\mainmatter[1][]{%
+  \cleardoublepage%
+  \renewenvironment{abstract}{\kauths@abstract}{\kauths@endabstract}%
+  \setcounter{page}{1}%
+  \pagenumbering{arabic}%
+  \kaupart*[body={#1}]{\introname}%
+}
+\newcommand\vanityquote[2]{%
+  \begin{tikzpicture}[remember picture,overlay]%
+    \path (current page.south east) +(-3,3.5)%
+      node%
+        [ anchor=south east%
+        , font=\large%
+        , text width=28em%
+        ] {\raggedleft``#1\rlap{''}%
+           \normalfont\par\medskip\itshape #2\par};%
+  \end{tikzpicture}%
+}
+\endinput
+%%
+%% End of file `kaucollection.cls'.
diff --git a/summary/kauenvironments.sty b/summary/kauenvironments.sty
new file mode 100644
index 0000000..15dd4c8
--- /dev/null
+++ b/summary/kauenvironments.sty
@@ -0,0 +1,55 @@
+%%
+%% This is file `kauenvironments.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kautools.dtx  (with options: `environments')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kautools.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesPackage{kauenvironments}
+    [2014/10/22 v1.15 Karlstad University kautools bundle]
+\ProcessOptions\relax
+\RequirePackage{xspace}
+\RequirePackage{xcolor}
+\newenvironment{researchquestions}%
+  {\begin{enumerate}%
+    \let\kue@item\item%
+    \renewcommand\item[1][Research question]%
+      {\kue@item\emph{##1}\nopagebreak\par}%
+  }%
+  {\end{enumerate}}%
+\newenvironment{contributions}%
+  {\begin{enumerate}%
+    \let\kue@item\item%
+    \renewcommand\item[1][%
+      \textcolor{red}{\emph{write your contribution between brackets
+        as optional argument of \texttt{\string\item}.}}]%
+      {\kue@item\emph{##1}\nopagebreak\par}%
+  }%
+  {\end{enumerate}}%
+\endinput
+%%
+%% End of file `kauenvironments.sty'.
diff --git a/summary/kauhead.sty b/summary/kauhead.sty
new file mode 100644
index 0000000..14f3a62
--- /dev/null
+++ b/summary/kauhead.sty
@@ -0,0 +1,71 @@
+%%
+%% This is file `kauhead.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kauprotocol.dtx  (with options: `head')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kauprotocol.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesPackage{kauhead}
+    [2013/09/11 v1.11 Karlstad University protocol bundle]
+\ProcessOptions\relax
+\RequirePackage[urw-garamond]{mathdesign}
+\RequirePackage[paper=a4,pagesize]{typearea}
+\RequirePackage{xkeyval}
+\RequirePackage{graphicx}
+\RequirePackage{tikz}
+\RequirePackage{ragged2e}
+\define@cmdkeys[kauhed]{general}[kauhed@]%
+  { title, date%
+  , faculty, department%
+  , logofile%
+  }
+\newcommand\headdata[1]{\setkeys[kauhed]{general}{#1}}
+\setkeys[kauhed]{general}%
+  { title=, date=\today%
+  , faculty={Faculty of Health, Science and Technology}%
+  , department={Department of Mathematics and Computer Science}%
+  , logofile={kau_2012_cmyk_eps_14679}%
+  }
+\let\kauhed@maketitle\maketitle
+\renewcommand\maketitle{
+  \thispagestyle{empty}
+  \begin{tikzpicture}[overlay,remember picture]
+    \path (current page.north)
+      node[below=5mm, text centered, text width=\textwidth] (top)
+      {\includegraphics[width=33mm]{\kauhed@logofile}\\[3mm]%
+      \kauhed@faculty\\%
+      \kauhed@department}
+    ;
+  \end{tikzpicture}
+  \vspace{1.5cm}\\
+  \mbox{}\hfill\kauhed@date\\
+  \centering\Large\scshape\kauhed@title\\
+  \justifying\normalfont\bigskip\normalsize
+}
+\endinput
+%%
+%% End of file `kauhead.sty'.
diff --git a/summary/kaulanguage.sty b/summary/kaulanguage.sty
new file mode 100644
index 0000000..e87df75
--- /dev/null
+++ b/summary/kaulanguage.sty
@@ -0,0 +1,53 @@
+%%
+%% This is file `kaulanguage.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kautools.dtx  (with options: `language')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kautools.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\ProvidesPackage{kaulanguage}
+    [2014/10/22 v1.15 Karlstad University kautools bundle]
+\ProcessOptions\relax
+\newif\ifbabel
+\babelfalse
+\AtBeginDocument{%
+  \@ifpackageloaded{babel}%
+    {\babeltrue}%
+    {\babelfalse}%
+}
+\newcommand\setname[3]{%
+  \IfFileExists{swedish.ldf}{%
+    \ifbabel%
+      \expandafter\edef\csname #1\endcsname{\noexpand\iflanguage{swedish}{#3}{#2}}%
+    \else%
+      \expandafter\edef\csname #1\endcsname{#2}%
+    \fi%
+  }%
+  {\expandafter\edef\csname #1\endcsname{#2}}%
+}
+\endinput
+%%
+%% End of file `kaulanguage.sty'.
diff --git a/summary/kaulist.sty b/summary/kaulist.sty
new file mode 100644
index 0000000..322ccb8
--- /dev/null
+++ b/summary/kaulist.sty
@@ -0,0 +1,64 @@
+%%
+%% This is file `kaulist.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kautools.dtx  (with options: `list')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kautools.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesPackage{kaulist}
+    [2014/10/22 v1.15 Karlstad University kautools bundle]
+\ProcessOptions\relax
+\RequirePackage{kaulanguage}
+\RequirePackage{tikz}
+\AtBeginDocument{%
+  \setname{commasign}{}{,}%
+}
+\AtBeginDocument{%
+  \setname{andname}{and}{och}%
+}
+\newcommand\prettylist[1]{%
+  \foreach[count=\xi] \x in #1 {}%
+  \let\num=\xi%
+  \foreach[count=\xi] \x in #1 {%
+    \ifnum \xi=1%
+      \x%
+    \else%
+      \ifnum \xi=\num%
+        \ifnum \num=2%
+          {} \andname{} \x%
+        \else%
+          \commasign{} \andname{} \x%
+        \fi%
+      \else%
+        , \x%
+      \fi%
+    \fi%
+  }%
+}%
+\endinput
+%%
+%% End of file `kaulist.sty'.
diff --git a/summary/kaumasters.cls b/summary/kaumasters.cls
new file mode 100644
index 0000000..e76504b
--- /dev/null
+++ b/summary/kaumasters.cls
@@ -0,0 +1,138 @@
+%%
+%% This is file `kaumasters.cls',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kauthesis.dtx  (with options: `masters')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kauthesis.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesClass{kaumasters}
+    [2014/12/04 v1.16 Karlstad University thesis layout]
+\LoadClass{article}
+\RequirePackage{kauclear}
+\RequirePackage{kaumeta}
+\RequirePackage{kaulist}
+\RequirePackage{kaulanguage}
+\newif\if@kaufont\@kaufontfalse
+\DeclareOption{garamond}{\@kaufonttrue}
+\ProcessOptions\relax
+\if@kaufont
+\RequirePackage{garamondx}
+\RequirePackage[garamondx,cmbraces]{newtxmath}
+\fi
+\RequirePackage[paper=a4,pagesize,twoside=semi]{typearea}
+\AtBeginDocument{%
+  \setname{acknowledgementname}{Acknowledgements}{Tacks\"agelser}%
+}
+\AtBeginDocument{%
+  \setname{keywordname}{Keywords}{Nyckelord}%
+}
+\AtBeginDocument{%
+  \setname{approvalname}{Approved}{Godk\"and}%
+}
+\AtBeginDocument{%
+  \setname{examinationname}{Master's degree}{magisterexamen}%
+}
+\AtBeginDocument{%
+  \setname{approvaltext}%
+    {This thesis is submitted in partial fulfillment of the %
+      requirements for the \examinationname{} in Computer Science. %
+      All material in this thesis which is not my own work has been %
+      identified and no material is included for which a degree has %
+      previously been conferred.}%
+    {Denna uppsats \"ar skriven som en del av det arbete som kr\"avs %
+      f\"or att erh\aa lla en \examinationname{} i datavetenskap. Allt %
+      material i denna rapport, vilket inte \"ar mitt eget, har blivit %
+      tydligt identifierat och inget material \"ar inkluderat som %
+      tidigare anv\"ants f\"or erh\aa llande av annan examen.}%
+}
+\AtBeginDocument{%
+  \setname{supervisorname}{Supervisor}{Handledare}%
+}
+\AtBeginDocument{%
+  \setname{examinername}{Examiner}{Examinator}%
+}
+\let\kauths@maketitle\maketitle
+\renewcommand\maketitle{%
+  \PackageWarning{maketitle does not serve any purpose in this class.
+    The abstract environment reproduces the title instead.}%
+}
+\let\kauths@abstract\abstract%
+\let\kauths@endabstract\endabstract%
+\newcommand*\frontmatter{%
+  \clearpage%
+  \setcounter{page}{3}%
+  \renewcommand\thepage{\roman{page}}%
+  \renewenvironment{abstract}{%
+    \newcommand\keywords{\paragraph{\keywordname:}}%
+    \newenvironment{english}{%
+      \renewcommand\keywords{\paragraph{Keywords:}}%
+      \section*{Abstract}%
+    }{%
+    }
+    \cleardoublepage%
+    \section*{\@title}%
+    \textsc{\prettylist{\@author}}\par%
+    \noindent\textit{\@institute}%
+    \section*{\abstractname}%
+  }{%
+    \cleardoublepage%
+  }%
+}
+\newcommand\approvalpage{%
+  \cleardoublepage%
+  \newcommand\sig{\makebox[7cm]{\hrulefill}\\}%
+  \newcommand\signer[1]{\begin{quote}\sig ##1\end{quote}\mbox{}}%
+  \noindent\approvaltext\\\mbox{}\bigskip%
+  \foreach \x in \@author {\signer{\x}}%
+  \\\mbox{}\bigskip\\\mbox{}\bigskip%
+  \approvalname,\\\mbox{}\bigskip%
+  \begin{quote}%
+    \sig\supervisorname: \@supervisor\\\mbox{}\bigskip\\%
+    \sig\examinername: \@examiner
+  \end{quote}%
+}
+\newenvironment{acknowledgements}{%
+  \cleardoublepage%
+  \section*{\acknowledgementname}%
+}{%
+  \par\bigskip\bigskip\bigskip\noindent\@place, \@date\hfill \prettylist{\@author}%
+  \cleardoublepage%
+}
+\let\kauths@tableofcontents\tableofcontents
+\renewcommand\tableofcontents{%
+  \cleardoublepage%
+  \kauths@tableofcontents%
+}
+\newcommand\mainmatter[1][]{%
+  \cleardoublepage%
+  \renewenvironment{abstract}{\kauths@abstract}{\kauths@endabstract}%
+  \setcounter{page}{1}%
+  \pagenumbering{arabic}%
+}
+\endinput
+%%
+%% End of file `kaumasters.cls'.
diff --git a/summary/kaumeeting.cls b/summary/kaumeeting.cls
new file mode 100644
index 0000000..638be63
--- /dev/null
+++ b/summary/kaumeeting.cls
@@ -0,0 +1,82 @@
+%%
+%% This is file `kaumeeting.cls',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kauprotocol.dtx  (with options: `meeting')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kauprotocol.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesClass{kaumeeting}
+    [2013/09/11 v1.11 Karlstad University protocol bundle]
+\ProcessOptions\relax
+\LoadClass{article}
+\RequirePackage{kauhead}
+\RequirePackage{tabularx}
+\define@cmdkeys[kaumet]{general}[kaumet@]%
+  { meeting, protocol, place%
+  , start, end%
+  , participants, excused, missing%
+  , distribution%
+  }
+\define@cmdkey[kaumet]{general}[kaumet@]{date}%
+  {\setkeys[kauhed]{general}{date={#1}}}
+\define@cmdkey[kaumet]{general}[kaumet@]{faculty}%
+  {\setkeys[kauhed]{general}{faculty={#1}}}
+\define@cmdkey[kaumet]{general}[kaumet@]{department}%
+  {\setkeys[kauhed]{general}{department={#1}}}
+\define@cmdkey[kaumet]{general}[kaumet@]{logofile}%
+  {\setkeys[kauhed]{general}{logofile={#1}}}
+\newcommand\metadata[1]{\setkeys[kaumet]{general}{#1}}
+\setkeys[kauhed]{general}{title=Meeting record}%
+\setkeys[kaumet]{general}%
+  { meeting=, protocol=, place=%
+  , date=\today, start=, end=%
+  , participants=, excused=, missing=%
+  , distribution=%
+  , faculty={Faculty of Health, Science and Technology}%
+  , department={Department of Mathematics and Computer Science}%
+  , logofile={kau_2012_cmyk_eps_14679}%
+  }
+\let\kaumet@maketitle\maketitle
+\renewcommand\maketitle{
+  \kaumet@maketitle%
+  \noindent\small%
+  \begin{tabularx}{\textwidth}{@{}>{\bfseries\vphantom{Xy}}rX}
+    subject & \kaumet@meeting\\
+    place & \kaumet@place\\
+    start & \kaumet@start\\
+    end & \kaumet@end\\
+    participants & \kaumet@participants\\
+    recording & \kaumet@protocol\\
+    excused & \kaumet@excused\\
+    missing & \kaumet@missing\\
+    distribution & \kaumet@distribution
+  \end{tabularx}\smallskip
+  \justifying\normalfont\normalsize
+}
+\endinput
+%%
+%% End of file `kaumeeting.cls'.
diff --git a/summary/kaumeta.sty b/summary/kaumeta.sty
new file mode 100644
index 0000000..4d1758d
--- /dev/null
+++ b/summary/kaumeta.sty
@@ -0,0 +1,56 @@
+%%
+%% This is file `kaumeta.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kautools.dtx  (with options: `meta')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kautools.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesPackage{kaumeta}
+    [2014/10/22 v1.15 Karlstad University kautools bundle]
+\ProcessOptions\relax
+\usepackage{ifthen}
+\newcommand*\@subject{}
+\newcommand\subject[1]{\renewcommand*\@subject{#1}}
+\newcommand*\@institute{}
+\newcommand*\@shortinstitute{}
+\newcommand\institute[2][]{%
+  \renewcommand*\@institute{#2}%
+  \ifthenelse{\equal{#1}{}}{%
+    \renewcommand*\@shortinstitute{#2}%
+  }{%
+    \renewcommand*\@shortinstitute{#1}%
+  }%
+}
+\newcommand*\@place{}
+\newcommand\place[1]{\renewcommand*\@place{#1}}
+\newcommand\@supervisor{}
+\newcommand\supervisor[1]{\renewcommand*\@supervisor{#1}}
+\newcommand\@examiner{}
+\newcommand\examiner[1]{\renewcommand*\@examiner{#1}}
+\endinput
+%%
+%% End of file `kaumeta.sty'.
diff --git a/summary/kaunote.cls b/summary/kaunote.cls
new file mode 100644
index 0000000..13742af
--- /dev/null
+++ b/summary/kaunote.cls
@@ -0,0 +1,46 @@
+%%
+%% This is file `kaunote.cls',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kauprotocol.dtx  (with options: `note')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kauprotocol.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesClass{kaunote}
+    [2013/09/11 v1.11 Karlstad University protocol bundle]
+\ProcessOptions\relax
+\LoadClass{article}
+\RequirePackage{kauhead}
+\newcommand\metadata[1]{\setkeys[kauhed]{general}{#1}}
+\let\kaunot@title\title
+\renewcommand\title[1]{\setkeys[kauhed]{general}{title={#1}}}
+\let\kaunot@maketitle\maketitle
+\renewcommand\maketitle{%
+  \kaunot@maketitle\par\medskip\@afterindentfalse\@afterheading%
+}
+\endinput
+%%
+%% End of file `kaunote.cls'.
diff --git a/summary/kaupaper.sty b/summary/kaupaper.sty
new file mode 100644
index 0000000..505072a
--- /dev/null
+++ b/summary/kaupaper.sty
@@ -0,0 +1,225 @@
+%%
+%% This is file `kaupaper.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kautools.dtx  (with options: `paper')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kautools.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesPackage{kaupaper}
+    [2014/10/22 v1.15 Karlstad University kautools bundle]
+\RequirePackage{xkeyval}
+\PassOptionsToPackage{hypertexnames=false}{hyperref}
+
+\define@cmdkeys[kua]{paper}[kua@]{author,title,subtitle,refprefix,reference,refnote,email,refstr,vanity,subdelimiter,label,summary,limitations,participation}
+\define@cmdkeys[kua]{paperlist}[kua@]{printparticipation,tocline}
+\setkeys[kua]{paper}{refstr=\reprintedname}
+
+\ProcessOptionsX[kua]<paper>
+
+\RequirePackage{kauparts}
+\RequirePackage{ifthen}
+\RequirePackage{tikz}
+
+\RequirePackage{ragged2e}
+\RequirePackage{hyphenat}
+
+\RequirePackage{kaulanguage}
+
+\AtBeginDocument{%
+  \setname{reprintedname}{Reprinted from}{Ursprungligen publicertad i}%
+  \setname{appendedpapersname}{List of Appended Papers}{Bifogade publiceringar}%
+  \setname{participationname}{Comments on my Participation}{Kommentarer p\aa{} min medverka}%
+  \setname{papername}{Paper}{Publicering}%
+}
+
+\newcounter{kua@section}
+\newcounter{kua@equation}
+\newcounter{kua@figure}
+\newcounter{kua@table}
+
+\newcounter{kua@paper}
+
+\providecommand\thepaper{}
+\providecommand\thepapertitle{}
+
+\newcommand\kua@warning\relax
+\newcommand\kua@dowarn{\gdef\kua@warning{\@latex@warning@no@line{List data created from the kaupaper environment was outdated. Rerun to get the lists right}}}
+\AtEndDocument{\kua@warning}
+
+\newcommand\kua@listof[4]{%
+  \IfFileExists{\jobname.#1}%
+    {% check whether empty file
+      \newread\reader%
+      \openin\reader\jobname.#1%
+      \read\reader to \readmacro%
+      \ifeof\reader%
+        \textcolor{red}{\ldots{} will be available after the next \LaTeX{} run.}%
+        \@starttoc{#1}%
+        %\AtEndDocument{\@latex@warning@no@line{Rerun to get the list of #2 right}}%
+        \kua@dowarn%
+      \else% file not empty -> create list
+        #3\@starttoc{#1}#4%
+      \fi%
+    }%
+    {% file does not exist
+      \textcolor{red}{\ldots{} will be available after the next \LaTeX{} run.}%
+      \@starttoc{#1}%
+      %\AtEndDocument{\@latex@warning@no@line{Rerun to get the list of #2 right}}%
+      \kua@dowarn%
+    }%
+}
+\newcommand\listofpapers[1][]{%
+  \setkeys[kua]{paperlist}{printparticipation=yes,tocline=yes,#1}
+  \section*{\appendedpapersname}%
+  \ifthenelse{\equal{\kua@tocline}{yes}}{%
+    \addcontentsline{toc}{section}{\appendedpapersname}%
+  }{}%
+  \kua@listof{pap}{appended papers}{%
+    \begin{enumerate}%
+    \renewcommand\theenumi{\textbf{\Roman{enumi}}}%
+  }{\end{enumerate}}%
+  \ifthenelse{\equal{\kua@printparticipation}{yes}}{%
+    \subsection*{\participationname}%
+    \kua@listof{pcp}{participation in appended papers}{}{}%
+  }{}%
+}
+
+\newcommand\l@paper[2]{%
+  \item #1%
+}
+
+\newcommand\listofsummaries{%
+  \kua@listof{sum}{paper summaries}{}{}%
+}
+
+\newcommand\l@summary[2]{%
+  #1%
+}
+
+\newcommand\l@limit[2]{%
+  %\paragraph{Limitations.}
+  #1%
+}
+
+\newcommand\l@participation[2]{%
+  #1%
+}
+
+\newcommand\papercover{%
+  \begin{tikzpicture}[remember picture,overlay]%
+    \path (current page.center)%
+      node%
+        [ node distance=\baselineskip%
+        , text width=\textwidth%
+        , text centered%
+        ] (refstr) {\kua@refstr};%
+      \ifthenelse{\equal{\kua@subtitle}{}}{%
+        \node%
+          [ node distance=1.5\baselineskip%
+          , above=of refstr%
+          , text width=\textwidth%
+          , text centered%
+          , font=\LARGE\bfseries%
+          ] {\nohyphens{\kua@title}};%
+      }{%
+        \node%
+          [ node distance=1.5\baselineskip%
+          , above=of refstr%
+          , text width=\textwidth%
+          , text centered%
+          , font=\large\bfseries%
+          ] (sub) {\nohyphens{\kua@subtitle}};%
+        \node%
+          [ node distance=1pt%
+          , above=of sub%
+          , text width=\textwidth%
+          , text centered%
+          , font=\LARGE\bfseries%
+          ] {\nohyphens{\kua@title}};%
+      }%
+      \node%
+        [ node distance=\baselineskip%
+        , below=of refstr%
+        , text width=\textwidth%
+        , text centered%
+        , font=\large%
+        ] {\nohyphens{\kua@reference}\ifthenelse{\equal{\kua@refnote}{}}{}{\mbox{}\\\medskip\nohyphens{\kua@refnote}}}%
+    ;%
+  \end{tikzpicture}%
+}
+
+\newenvironment{kaupaper}[1][]{%
+  \setcounter{kua@section}{\value{section}}%
+  \setcounter{kua@equation}{\value{equation}}%
+  \setcounter{kua@figure}{\value{figure}}%
+  \setcounter{kua@table}{\value{table}}%
+  \setcounter{section}{0}%
+  \setcounter{equation}{0}%
+  \setcounter{figure}{0}%
+  \setcounter{table}{0}%
+  \setkeys[kua]{paper}{subtitle=,vanity=,subdelimiter={---},refprefix=,refnote=,label=,summary={\string\textcolor{red}{Use the \string\texttt{summary} key in the \string\texttt{kaupaper} environment to add a summary.}},participation={\string\textcolor{red}{Use the \string\texttt{participation} key in the \string\texttt{kaupaper} environment to add a comment.}},limitations={},#1}%
+  \setcounter{kua@paper}{\value{kup@part}}\stepcounter{kua@paper}%
+  \kaupart[tocentry=false,label=\kua@label,body=\papercover\kua@vanity]{\papername}%
+  \ifthenelse{\equal{\kua@subtitle}{}}%
+    {\ifthenelse{\equal{\kua@refnote}{}}%
+      {\addcontentsline{pap}{paper}{\kua@author. \kua@title. \kua@refprefix\kua@reference.}}%
+      {\addcontentsline{pap}{paper}{\kua@author. \kua@title. \kua@refprefix\kua@reference.\smallskip\\\kua@refnote}}%
+     \addcontentsline{toc}{part}{\textsc{\papername} \Roman{kua@paper}: \\\kua@title}}%
+    {\ifthenelse{\equal{\kua@refnote}{}}%
+      {\addcontentsline{pap}{paper}{\kua@author. \kua@title\kua@subdelimiter\kua@subtitle. \kua@refprefix\kua@reference.}}%
+      {\addcontentsline{pap}{paper}{\kua@author. \kua@title\kua@subdelimiter\kua@subtitle. \kua@refprefix\kua@reference.\smallskip\\\kua@refnote}}%
+     \addcontentsline{toc}{part}{\textsc{\papername} \Roman{kua@paper}: \\\kua@title\kua@subdelimiter\kua@subtitle}}%
+  \addcontentsline{sum}{summary}{\string\subsubsection*{\papername~\Roman{kua@paper} -- \kua@title}\kua@summary}%
+  \ifthenelse{\equal{\kua@limitations}{}}{}{%
+    \addcontentsline{sum}{limit}{\kua@limitations}}%
+  \addcontentsline{pcp}{participation}{\string\paragraph{\papername~\Roman{kua@paper}}\kua@participation}%
+  \renewcommand*\thepaper{\papername~\Roman{kua@paper}}%
+  \renewcommand*\thepapertitle{\kua@title}%
+  \renewcommand\maketitle{%
+    \thispagestyle{plain}%
+    \centering%
+      \Large\bfseries%
+      \vspace*{0.15\textheight}%
+      \kua@title\par%
+      \addvspace{1ex}%
+      \ifthenelse{\equal{\kua@subtitle}{}}{}{\large\kua@subtitle}%
+      \par\addvspace{\baselineskip}%
+      \normalsize%
+      \kua@author\\[0.25\baselineskip]%
+      \normalfont%
+    \par\addvspace{2\baselineskip}\justifying%
+  }%
+}{%
+  \setcounter{section}{\value{kua@section}}%
+  \setcounter{equation}{\value{kua@equation}}%
+  \setcounter{figure}{\value{kua@figure}}%
+  \setcounter{table}{\value{kua@table}}%
+  \clearpage%
+}
+\endinput
+%%
+%% End of file `kaupaper.sty'.
diff --git a/summary/kauparts.sty b/summary/kauparts.sty
new file mode 100644
index 0000000..5252ba6
--- /dev/null
+++ b/summary/kauparts.sty
@@ -0,0 +1,109 @@
+%%
+%% This is file `kauparts.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kautools.dtx  (with options: `parts')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kautools.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesPackage{kauparts}
+    [2014/10/22 v1.15 Karlstad University kautools bundle]
+\RequirePackage{xkeyval}
+
+\define@cmdkeys[kup]{pkg}[kup@]{vshift,vstep}
+\setkeys[kup]{pkg}{vshift=2,vstep=0.8}
+
+\ProcessOptionsX[kup]<pkg>
+
+\RequirePackage{calc}
+\RequirePackage{ifthen}
+\RequirePackage{suffix}
+\RequirePackage{tikz}
+\usetikzlibrary{positioning}
+
+\define@cmdkeys[kup]{part}[kup@]{body,label}
+\define@boolkeys[kup]{part}[kup@]{tocentry}
+
+\newcounter{kup@part}
+\newcounter{kup@vertical}
+\setcounter{kup@vertical}{0}
+
+\newcommand*\@titlepagestyle{empty}
+\newcommand\titlepagestyle[1]{\renewcommand*\@titlepagestyle{#1}}
+
+\newcommand\kup@partheadline[2]{%
+  \path[node distance=1ex] (current page.north east) +(3pt,\kup@vshift+\kup@vstep*\arabic{kup@vertical}) %
+    node%
+      [ anchor=north east%
+      , minimum width=2cm+3pt%
+      %, minimum height=7mm%
+      %, draw=black%
+      %, fill=black%
+      , left color=white%
+      , right color=black%
+      , text=white%
+      , font=\LARGE\bfseries%
+      ] (bar) {#1}%
+    node[base left=of bar,font=\LARGE\bfseries] {#2};%
+}
+\newcommand\kaupart[2][]{%
+  \cleardoublepage%
+  \thispagestyle{\@titlepagestyle}%
+  \stepcounter{kup@part}%
+  \setkeys[kup]{part}{body=\relax,label=,tocentry=true,#1}%
+  \providecommand\phantomsection{}%
+  \phantomsection%
+  \ifkup@tocentry%
+    \addcontentsline{toc}{part}{\numberline{\Roman{kup@part}}\textsc{#2}}%
+  \fi%
+  \renewcommand\@currentlabel{\Roman{kup@part}}%
+  \ifthenelse{\equal{\kup@label}{}}{}{\label{\kup@label}}%
+  \begin{tikzpicture}[remember picture,overlay,yscale=-1]%
+    \kup@partheadline{\Roman{kup@part}}{#2}%
+  \end{tikzpicture}%
+  \kup@body
+  \stepcounter{kup@vertical}%
+  \cleardoublepage%
+}
+\WithSuffix\newcommand\kaupart*[2][]{%
+  \cleardoublepage%
+  \thispagestyle{\@titlepagestyle}%
+  \setkeys[kup]{part}{body=\relax,tocentry=true,#1}%
+  \providecommand\phantomsection{}%
+  \phantomsection%
+  \ifkup@tocentry%
+    \addcontentsline{toc}{part}{\textsc{#2}}%
+  \fi%
+  \begin{tikzpicture}[remember picture,overlay,yscale=-1]%
+    \kup@partheadline{\vphantom{X}}{#2}%
+  \end{tikzpicture}%
+  \kup@body
+  \stepcounter{kup@vertical}%
+  \cleardoublepage%
+}
+\endinput
+%%
+%% End of file `kauparts.sty'.
diff --git a/summary/kaureport.cls b/summary/kaureport.cls
new file mode 100644
index 0000000..d8de211
--- /dev/null
+++ b/summary/kaureport.cls
@@ -0,0 +1,109 @@
+%%
+%% This is file `kaureport.cls',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kauthesis.dtx  (with options: `report')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kauthesis.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesClass{kaureport}
+    [2014/12/04 v1.16 Karlstad University thesis layout]
+\LoadClass{article}
+\RequirePackage{kauclear}
+\RequirePackage{kaumeta}
+\RequirePackage{kaulist}
+\RequirePackage{kaulanguage}
+\RequirePackage{kaustudies}
+\RequirePackage{kauenvironments}
+\RequirePackage{tikz}
+\RequirePackage{kauparts}
+\ProcessOptions\relax
+\AtBeginDocument{%
+  \setname{acknowledgementname}{Acknowledgements}{Tacks\"agelser}%
+}
+\AtBeginDocument{%
+  \setname{keywordname}{Keywords}{Nyckelord}%
+}
+\let\kauths@maketitle\maketitle
+\renewcommand\maketitle{%
+  \PackageWarning{maketitle does not serve any purpose in this class.
+    The abstract environment reproduces the title instead.}%
+}
+\let\kauths@abstract\abstract%
+\let\kauths@endabstract\endabstract%
+\newcommand*\frontmatter{%
+  \clearpage%
+  \setcounter{page}{3}%
+  \renewcommand\thepage{\roman{page}}%
+  \renewenvironment{abstract}{%
+    \newcommand\keywords{\paragraph{\keywordname:}}%
+    \newenvironment{english}{%
+      \renewcommand\keywords{\paragraph{Keywords:}}%
+      \section*{Abstract}%
+    }{%
+    }
+    \cleardoublepage%
+    \section*{\@title}%
+    \textsc{\prettylist{\@author}}\par%
+    \noindent\textit{\@institute}%
+    \section*{\abstractname}%
+  }{%
+    \cleardoublepage%
+  }%
+}
+\newenvironment{acknowledgements}{%
+  \cleardoublepage%
+  \section*{\acknowledgementname}%
+}{%
+  \par\bigskip\bigskip\bigskip\noindent\@place, \@date\hfill \prettylist{\@author}%
+  \cleardoublepage%
+}
+\let\kauths@tableofcontents\tableofcontents
+\renewcommand\tableofcontents{%
+  \cleardoublepage%
+  \kauths@tableofcontents%
+}
+\newcommand\mainmatter[1][]{%
+  \cleardoublepage%
+  \renewenvironment{abstract}{\kauths@abstract}{\kauths@endabstract}%
+  \setcounter{page}{1}%
+  \pagenumbering{arabic}%
+}
+\newcommand\vanityquote[2]{%
+  \begin{tikzpicture}[remember picture,overlay]%
+    \path (current page.south east) +(-3,3.5)%
+      node%
+        [ anchor=south east%
+        , font=\large%
+        , text width=28em%
+        ] {\raggedleft``#1\rlap{''}%
+           \normalfont\par\medskip\itshape #2\par};%
+  \end{tikzpicture}%
+}
+\let\part\kaupart
+\endinput
+%%
+%% End of file `kaureport.cls'.
diff --git a/summary/kaustudies.sty b/summary/kaustudies.sty
new file mode 100644
index 0000000..83a7eb6
--- /dev/null
+++ b/summary/kaustudies.sty
@@ -0,0 +1,60 @@
+%%
+%% This is file `kaustudies.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kautools.dtx  (with options: `studies')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kautools.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesPackage{kaustudies}
+    [2014/10/22 v1.15 Karlstad University kautools bundle]
+\RequirePackage{xkeyval}
+
+\define@boolkey[kus]{pkg}[kus@]{tinyfontswitch}[true]{}
+
+\presetkeys[kus]{pkg}{tinyfontswitch}{}
+\ProcessOptionsX[kus]<pkg>
+
+\RequirePackage[twoside]{geometry}
+\RequirePackage{garamondx}
+\RequirePackage[garamondx,cmbraces]{newtxmath}
+
+\geometry
+  { paperwidth=165mm
+  , paperheight=242mm
+  , inner=27mm
+  , outer=27mm
+  , top=24mm
+  , bottom=22mm
+  }
+
+\ifkus@tinyfontswitch
+  \let\kus@tiny@orig\tiny
+  \renewcommand*\tiny{\sffamily\kus@tiny@orig}
+\fi
+\endinput
+%%
+%% End of file `kaustudies.sty'.
diff --git a/summary/kautitle.sty b/summary/kautitle.sty
new file mode 100644
index 0000000..824b531
--- /dev/null
+++ b/summary/kautitle.sty
@@ -0,0 +1,88 @@
+%%
+%% This is file `kautitle.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kautools.dtx  (with options: `title')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kautools.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesPackage{kautitle}
+    [2014/10/22 v1.15 Karlstad University kautools bundle]
+\ProcessOptions\relax
+\RequirePackage{xkeyval}
+\RequirePackage{tikz}
+\RequirePackage{hyphenat}
+\RequirePackage{kaumeta}
+\define@cmdkeys[kut]{pkg}[kut@]{normalfont,titlefont}
+\setkeys[kut]{pkg}%
+  { normalfont=\fontfamily{aun}\fontsize{18}{21.6}\selectfont\bfseries
+  , titlefont=\fontfamily{aub}\fontsize{28}{33.6}\selectfont }
+\newcommand\setkautitlefont[1]{\setkeys[kut]{pkg}{#1}}
+\let\kut@maketitle\maketitle
+\renewcommand\maketitle{%
+  \thispagestyle{empty}
+  \begin{tikzpicture}[remember picture, overlay]%
+    \path (current page.north west) +(-4pt,4pt) node (NW) {};
+    \path (current page.south east) +(4pt,-4pt) node (SE) {};
+    \path (current page.north west) +(-3pt,3pt) node (NWC) {};
+    \path (current page.south east) +(3pt,-3pt) node (SEC) {};
+    \path[clip] (NWC) rectangle (SEC);
+    \path (current page.south west) node[rotate=243.5] {\pgfimage{kau-logo-tryck}};%
+    \path (current page.north east) node[rotate=175] {\pgfimage{kau-logo-tryck}};%
+    \path (current page.north west) node
+      [shift={(10pt,-12pt)},anchor=south west,rotate=270
+      ,font=\kut@normalfont\vphantom{Xy}]
+      {\@subject};
+    \path (current page.south east) node
+      [shift={(-8pt,6pt)},anchor=north east,rotate=270
+      ,rounded corners,fill=black,text=white,inner sep=8pt
+      ,font=\kut@normalfont\vphantom{Xy}]
+      {\@shortinstitute};
+    \path
+      (current page.east) node[shift={(-10,0)}] (A) {}
+      (current page.east) node[shift={(0,-2.5)}] (B) {}
+      [shading=axis,left color=white,right color=black] (A) rectangle (B.south east)
+    ;
+    \path (B) node
+      [anchor=north east
+      ,inner sep=8pt
+      ,text=black
+      ,font=\kut@normalfont\vphantom{Xy}
+      ,text width=14cm,text ragged left]
+      {\@author};
+    \path[fill=white,opacity=0.90,transparency group] (NW) rectangle (SE);
+    \path (B) node
+      [anchor=south east,shift={(-3pt,0)}
+      ,text=yellow!75!red
+      ,font=\kut@titlefont\vphantom{Xy}
+      ,text width=14cm,text ragged left]
+      {\nohyphens{\@title}};
+  \end{tikzpicture}%
+  \clearpage%
+}
+\endinput
+%%
+%% End of file `kautitle.sty'.
diff --git a/summary/main.tex b/summary/main.tex
new file mode 100644
index 0000000..23e50d7
--- /dev/null
+++ b/summary/main.tex
@@ -0,0 +1,183 @@
+%%
+%% This is file `kaucollectiontemplate.tex',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kauthesis.dtx  (with options: `collectiontemplate')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kauthesis.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\documentclass{kaucollection}
+
+%%%
+% Template preamble
+%%%
+\usepackage{xstring}
+\usepackage{scrlayer-scrpage}
+\pagestyle{scrheadings}
+\renewcommand*\headfont{\normalfont\small}
+\rehead{\thepaper}
+\lohead{\thepapertitle}
+\lohead{%
+  \IfStrEq{\thepapertitle}{Privacy-Preserving \& Incrementally-Deployable Support for Certificate Transparency in Tor}%
+    {Privacy-Preserving \& Incrementally-Deployable Support for Certificate Transpa...}%
+    {\IfStrEq{\thepapertitle}{Sauteed Onions: Transparent Associations from Domain Names to Onion Addresses}%
+      {Sauteed Onions: Transparent Associations from Domain Names to Onion Add...}%
+      {\thepapertitle}%
+    }%
+}
+
+%%%
+% Template metadata
+%%%
+\title{%
+  On Certificate Transparency Verification and\\
+  Unlinkability of Websites Visited by Tor Users
+}
+
+\author{%
+  Rasmus Dahlberg
+}
+\institute{%
+  Department of Mathematics and Computer Science
+}
+\place{%
+  Karlstad University
+}
+
+%%%
+% Thesis preamble
+%%%
+\usepackage[sectionbib]{natbib}
+\usepackage{chapterbib}
+
+% Better line breaks
+\usepackage{microtype}
+
+% Appendix that starts from A for each paper
+\usepackage{appendix}
+\renewcommand{\restoreapp}{}
+
+% Crypto notation
+\usepackage[
+    lambda, advantage, operators, sets, adversary, landau, probability, notions,
+    logic, ff, mm, primitives, events, complexity, asymptotics, keys
+]{cryptocode}
+
+% Tables
+\usepackage{booktabs}
+
+% Figures
+\usepackage{graphicx}
+\usepackage{subcaption}
+\usepackage{tikz}
+\usepackage{tikz-qtree}
+\usetikzlibrary{shapes.misc,positioning,arrows,snakes}
+
+\usepackage{rotating}
+
+% Colors
+\usepackage{color}
+\usepackage{colortbl}
+\definecolor{rgddTeal}{HTML}{009999}
+\definecolor{rgddLime}{HTML}{809933}
+\definecolor{rgddPurple}{HTML}{993380}
+\definecolor{rgddRed}{HTML}{E04644}
+\definecolor{rgddGreen}{HTML}{008000}
+\definecolor{rgddBlue}{HTML}{2809B2}
+\definecolor{rgddBlack}{HTML}{000000}
+
+% Links
+\usepackage{hyperref}
+\hypersetup{
+  colorlinks = true,                              % Color links instead of boxes
+  urlcolor   = rgddBlue,                            % Color external hyper links
+  linkcolor  = rgddBlue,                                  % Color internal links
+  citecolor  = rgddGreen,                                      % Color citations
+}
+\def\UrlBreaks{\do\/\do-}                       % More flexible line-break rules
+
+% Code listings
+\usepackage{listings}
+
+% Theorems with s/openbox/rgddopenbox in rgddamsthm.sty to avoid package class
+\usepackage{rgddamsthm}
+\theoremstyle{definition}
+\newtheorem{definition}{Definition}
+
+% Command to underscore
+\usepackage{stackengine}
+\newcommand\barbelow[1]{\stackunder[1.2pt]{#1}{\rule{.8ex}{.075ex}}}
+
+%%%
+% Document start
+%%%
+\begin{document}
+  \frontmatter
+
+  \begin{abstract}
+    \input{src/abstract}
+  \end{abstract}
+
+  \section*{Kring verifiering av Certificate Transparency samt länkbarhet av Tor-användare och besökta webbplatser}
+  \textsc{Rasmus Dahlberg}\\
+  \noindent\textit{Institutionen för matematik och datavetenskap}
+  \section*{Sammanfattning}
+  \input{src/sammanfattning}
+  \cleardoublepage
+
+  \begin{acknowledgements}
+    \input{src/acknowledgements}
+  \end{acknowledgements}
+
+  \input{src/abbr}\addcontentsline{toc}{section}{List of Acronyms}%
+  \cleardoublepage
+
+  {
+    \hypersetup{linkcolor=black}
+    \listofpapers
+  }
+  \cleardoublepage
+
+  \input{src/other}\addcontentsline{toc}{section}{List of Other Contributions}%
+  \cleardoublepage
+
+  {
+    \hypersetup{linkcolor=black}
+    \tableofcontents
+  }
+
+  \mainmatter
+  \include{src/introduction/main}\setcounter{footnote}{0}
+  \include{src/lwm/main}\setcounter{footnote}{0}
+  \include{src/ctga/main}\setcounter{footnote}{0}
+  \include{src/ctor/main}\setcounter{footnote}{0}
+  \include{src/sauteed/main}\setcounter{footnote}{0}
+  \include{src/cat/main}\setcounter{footnote}{0}
+  \include{src/tlwo/main}\setcounter{footnote}{0}
+  
+\end{document}
+\endinput
+%%
+%% End of file `kaucollectiontemplate.tex'.
diff --git a/summary/pgfcropmarks.sty b/summary/pgfcropmarks.sty
new file mode 100644
index 0000000..f23adcb
--- /dev/null
+++ b/summary/pgfcropmarks.sty
@@ -0,0 +1,84 @@
+%%
+%% This is file `pgfcropmarks.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% kautools.dtx  (with options: `crop')
+%% 
+%% This is a generated file.
+%% 
+%% Copyright (c) 2011-2014 Stefan Berthold <stefan.berthold@kau.se>
+%% 
+%% This file is part of the kauthesis bundle.
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `author-maintained'.
+%% 
+%% The Current Maintainer and author of this work is Stefan Berthold.
+%% 
+%% This work consists of all files listed in manifest.txt.
+%% 
+%% kautools.dtx
+%% Copyright (c) 2011-2015 Stefan Berthold <stefan.berthold@kau.se>
+\NeedsTeXFormat{LaTeX2e}[1999/12/01]
+\ProvidesPackage{pgfcropmarks}
+    [2014/10/22 v1.15 Karlstad University kautools bundle]
+\ProcessOptions\relax
+\RequirePackage{pgfpages}%
+\nofiles%
+\newif\if@kus@isodd%
+\@kus@isoddtrue%
+\newlength{\cropmarklen}\setlength{\cropmarklen}{40pt}%
+\newlength{\cropmarksep}\setlength{\cropmarksep}{15pt}%
+\pgfpagesdeclarelayout{cropmarks}%
+{%
+}%
+{%
+  \pgfpagesphysicalpageoptions%
+  {%
+    logical pages=1,%
+    physical height=297mm,%
+    physical width=210mm%
+  }%
+  \pgfpageslogicalpageoptions{1}%
+  {%
+    border code=%
+      \if@kus@isodd
+        \global\@kus@isoddfalse
+        \pgfsetlinewidth{0.6pt}%
+        \pgfusepath{discard}%
+        \pgfmoveto{\pgfpoint{-\cropmarksep}{0pt}}%
+          \pgflineto{\pgfpoint{-\cropmarklen}{0pt}}%
+        \pgfmoveto{\pgfpoint{0pt}{-\cropmarksep}}%
+          \pgflineto{\pgfpoint{0pt}{-\cropmarklen}}%
+        \pgfmoveto{\pgfpoint{\paperwidth+\cropmarksep}{0pt}}%
+          \pgflineto{\pgfpoint{\paperwidth+\cropmarklen}{0pt}}%
+        \pgfmoveto{\pgfpoint{\paperwidth}{-\cropmarksep}}%
+          \pgflineto{\pgfpoint{\paperwidth}{-\cropmarklen}}%
+        \pgfmoveto{\pgfpoint{-\cropmarksep}{\paperheight}}%
+          \pgflineto{\pgfpoint{-\cropmarklen}{\paperheight}}%
+        \pgfmoveto{\pgfpoint{0pt}{\paperheight+\cropmarksep}}%
+          \pgflineto{\pgfpoint{0pt}{\paperheight+\cropmarklen}}%
+        \pgfmoveto{\pgfpoint{\paperwidth}{\paperheight+\cropmarksep}}%
+          \pgflineto{\pgfpoint{\paperwidth}{\paperheight+\cropmarklen}}%
+        \pgfmoveto{\pgfpoint{\paperwidth+\cropmarksep}{\paperheight}}%
+          \pgflineto{\pgfpoint{\paperwidth+\cropmarklen}{\paperheight}}%
+        \pgfusepath{stroke}%
+      \else
+        \global\@kus@isoddtrue
+      \fi,%
+    center=\pgfpoint{.5\pgfphysicalwidth}{.5\pgfphysicalheight}%
+  }%
+}%
+\pgfpagesuselayout{cropmarks}%
+\endinput
+%%
+%% End of file `pgfcropmarks.sty'.
diff --git a/summary/preprint/thesis-preprint.pdf b/summary/preprint/thesis-preprint.pdf
new file mode 100644
index 0000000..97f63c9
--- /dev/null
+++ b/summary/preprint/thesis-preprint.pdf
diff --git a/summary/rgddamsthm.sty b/summary/rgddamsthm.sty
new file mode 100644
index 0000000..85aadce
--- /dev/null
+++ b/summary/rgddamsthm.sty
@@ -0,0 +1,444 @@
+%%
+%% This is file `amsthm.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% amsclass.dtx  (with options: `amsthm')
+%% This is a generated file.
+%% 
+%% Copyright 1995, 1999, 2004, 2009-2020 American Mathematical Society.
+%% 
+%% American Mathematical Society
+%% Technical Support
+%% Publications Technical Group
+%% 201 Charles Street
+%% Providence, RI 02904
+%% USA
+%% tel: (401) 455-4080
+%%      (800) 321-4267 (USA and Canada only)
+%% fax: (401) 331-3842
+%% email: tech-support@ams.org
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either version 1.3c
+%% of this license or (at your option) any later version.
+%% The latest version of this license is in
+%%   http://www.latex-project.org/lppl.txt
+%% and version 1.3c or later is part of all distributions of LaTeX
+%% version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status `maintained'.
+%% 
+%% The Current Maintainer of this work is the American Mathematical
+%% Society.
+%% 
+%% ========================================================================
+%% 
+\NeedsTeXFormat{LaTeX2e}% LaTeX 2.09 can't be used (nor non-LaTeX)
+[1995/06/01]% LaTeX date must be June 1995 or later
+\ProvidesPackage{amsthm}[2020/05/29 v2.20.6]
+\let\@xp=\expandafter
+\let\@nx=\noexpand
+\def\@oparg#1[#2]{\@ifnextchar[{#1}{#1[#2]}}
+\long\def\@ifempty#1{\@xifempty#1@@..\@nil}
+\long\def\@xifempty#1#2@#3#4#5\@nil{%
+  \ifx#3#4\@xp\@firstoftwo\else\@xp\@secondoftwo\fi}
+\long\def\@ifnotempty#1{\@ifempty{#1}{}}
+\def\setboxz@h{\setbox\z@\hbox}
+\def\@addpunct#1{%
+  \relax\ifhmode
+    \ifnum\spacefactor>\@m \else#1\fi
+  \fi}
+\def\nopunct{\spacefactor 1007 }
+\def\frenchspacing{\sfcode`\.1006\sfcode`\?1005\sfcode`\!1004%
+  \sfcode`\:1003\sfcode`\;1002\sfcode`\,1001 }
+\DeclareOption*{\input{\CurrentOption .thm}}
+\ProcessOptions
+
+\newcommand{\theoremstyle}[1]{%
+  \@ifundefined{th@#1}{%
+    \PackageWarning{amsthm}{Unknown theoremstyle `#1'}%
+    \thm@style{plain}%
+  }{%
+    \thm@style{#1}%
+  }%
+}
+\newtoks\thm@style
+\thm@style{plain}
+\newtoks\thm@bodyfont  \thm@bodyfont{\itshape}
+\newtoks\thm@headfont  \thm@headfont{\bfseries}
+\newtoks\thm@notefont  \thm@notefont{}
+\newtoks\thm@headpunct \thm@headpunct{.}
+\newskip\thm@preskip \newskip\thm@postskip
+\def\thm@space@setup{%
+  \thm@preskip=\topsep \thm@postskip=\thm@preskip
+}
+\renewcommand{\newtheorem}{\@ifstar{\@xnthm *}{\@xnthm \relax}}
+\def\@xnthm#1#2{%
+  \let\@tempa\relax
+  \@xp\@ifdefinable\csname #2\endcsname{%
+    \global\@xp\let\csname end#2\endcsname\@endtheorem
+    \ifx *#1% unnumbered, need to get one more mandatory arg
+      \edef\@tempa##1{%
+        \gdef\@xp\@nx\csname#2\endcsname{%
+          \@nx\@thm{\@xp\@nx\csname th@\the\thm@style\endcsname}%
+            {}{##1}}}%
+    \else % numbered theorem, need to check for optional arg
+      \def\@tempa{\@oparg{\@ynthm{#2}}[]}%
+    \fi
+  }%
+  \@tempa
+}
+\def\@ynthm#1[#2]#3{%
+  \ifx\relax#2\relax
+    \def\@tempa{\@oparg{\@xthm{#1}{#3}}[]}%
+  \else
+    \@ifundefined{c@#2}{%
+      \def\@tempa{\@nocounterr{#2}}%
+    }{%
+      \@xp\xdef\csname the#1\endcsname{\@xp\@nx\csname the#2\endcsname}%
+      \toks@{#3}%
+      \@xp\xdef\csname#1\endcsname{%
+        \@nx\@thm{%
+          \let\@nx\thm@swap
+            \if S\thm@swap\@nx\@firstoftwo\else\@nx\@gobble\fi
+          \@xp\@nx\csname th@\the\thm@style\endcsname}%
+            {#2}{\the\toks@}}%
+      \let\@tempa\relax
+    }%
+  \fi
+  \@tempa
+}
+\def\@xthm#1#2[#3]{%
+  \ifx\relax#3\relax
+    \newcounter{#1}%
+  \else
+    \newcounter{#1}[#3]%
+    \@xp\xdef\csname the#1\endcsname{\@xp\@nx\csname the#3\endcsname
+      \@thmcountersep\@thmcounter{#1}}%
+  \fi
+  \toks@{#2}%
+  \@xp\xdef\csname#1\endcsname{%
+    \@nx\@thm{%
+      \let\@nx\thm@swap
+        \if S\thm@swap\@nx\@firstoftwo\else\@nx\@gobble\fi
+      \@xp\@nx\csname th@\the\thm@style\endcsname}%
+      {#1}{\the\toks@}}%
+}
+\def\@thm#1#2#3{%
+  \ifhmode\unskip\unskip\par\fi
+  \normalfont
+  \trivlist
+  \let\thmheadnl\relax
+  \let\thm@swap\@gobble
+  \thm@notefont{\fontseries\mddefault\upshape}%
+  \thm@headpunct{.}% add period after heading
+  \thm@headsep 5\p@ plus\p@ minus\p@\relax
+  \thm@space@setup
+  #1% style overrides
+  \@topsep \thm@preskip               % used by thm head
+  \@topsepadd \thm@postskip           % used by \@endparenv
+  \def\@tempa{#2}\ifx\@empty\@tempa
+    \def\@tempa{\@oparg{\@begintheorem{#3}{}}[]}%
+  \else
+    \refstepcounter{#2}%
+    \def\@tempa{\@oparg{\@begintheorem{#3}{\csname the#2\endcsname}}[]}%
+  \fi
+  \@tempa
+}
+\def\@restorelabelsep{\relax}
+\let\@ythm\relax
+\let\thmname\@iden \let\thmnote\@iden \let\thmnumber\@iden
+\providecommand\@upn{\textup}
+\def\thmhead@plain#1#2#3{%
+  \thmname{#1}\thmnumber{\@ifnotempty{#1}{ }\@upn{#2}}%
+  \thmnote{ {\the\thm@notefont(#3)}}}
+\let\thmhead\thmhead@plain
+\def\swappedhead#1#2#3{%
+  \thmnumber{#2}%
+  \thmname{\@ifnotempty{#2}{~}#1}%
+  \thmnote{ {\the\thm@notefont(#3)}}}
+\let\swappedhead@plain=\swappedhead
+\let\thmheadnl\relax
+\let\thm@indent\noindent
+\let\thm@swap\@gobble
+\def\@begintheorem#1#2[#3]{%
+  \deferred@thm@head{\the\thm@headfont \thm@indent
+    \@ifempty{#1}{\let\thmname\@gobble}{\let\thmname\@iden}%
+    \@ifempty{#2}{\let\thmnumber\@gobble}{\let\thmnumber\@iden}%
+    \@ifempty{#3}{\let\thmnote\@gobble}{\let\thmnote\@iden}%
+    \thm@swap\swappedhead\thmhead{#1}{#2}{#3}%
+    \the\thm@headpunct
+    \thmheadnl % possibly a newline.
+    \hskip\thm@headsep
+  }%
+  \ignorespaces}
+\newskip\thm@headsep
+\thm@headsep=5pt plus1pt minus1pt\relax
+\let\adjust@parskip@nobreak=\@nbitem
+\newtoks\dth@everypar
+\dth@everypar={%
+  \@minipagefalse \global\@newlistfalse
+  \@noparitemfalse
+  \if@inlabel
+    \global\@inlabelfalse
+    \begingroup \setbox\z@\lastbox
+     \ifvoid\z@ \kern-\itemindent \fi
+    \endgroup
+    \unhbox\@labels
+  \fi
+  \if@nobreak \@nobreakfalse \clubpenalty\@M
+  \else \clubpenalty\@clubpenalty \everypar{}%
+  \fi
+}%
+\def\deferred@thm@head#1{%
+  \if@inlabel \indent \par \fi % eject a section head if one is pending
+  \if@nobreak
+    \adjust@parskip@nobreak
+  \else
+    \addpenalty\@beginparpenalty
+    \addvspace\@topsep
+    \addvspace{-\parskip}%
+  \fi
+  \global\@inlabeltrue
+  \everypar\dth@everypar
+  \sbox\@labels{\normalfont#1}%
+  \ignorespaces
+}
+\def\nonslanted{\relax
+  \@xp\let\@xp\@tempa\csname\f@shape shape\endcsname
+  \ifx\@tempa\itshape\upshape
+  \else\ifx\@tempa\slshape\upshape\fi\fi}
+\def\swapnumbers{\edef\thm@swap{\if S\thm@swap N\else S\fi}}
+\def\thm@swap{N}%
+\let\@opargbegintheorem\relax
+\def\th@plain{%
+%%  \let\thm@indent\noindent % no indent
+%%  \thm@headfont{\bfseries}% heading font is bold
+%%  \thm@notefont{}% same as heading font
+%%  \thm@headpunct{.}% add period after heading
+%%  \let\thm@swap\@gobble
+%%  \thm@preskip\topsep
+%%  \thm@postskip\theorempreskipamount
+  \itshape % body font
+}
+\def\th@definition{%
+  \normalfont % body font
+}
+\def\th@remark{%
+  \thm@headfont{\itshape}%
+  \normalfont % body font
+  \thm@preskip\topsep \divide\thm@preskip\tw@
+  \thm@postskip\thm@preskip
+}
+\def\@endtheorem{\endtrivlist\@endpefalse }
+\newcommand{\newtheoremstyle}[9]{%
+  \@ifempty{#5}{\dimen@\z@skip}{\dimen@#5\relax}%
+  \ifdim\dimen@=\z@
+    \toks@{#4\let\thm@indent\noindent}%
+  \else
+    \toks@{#4\def\thm@indent{\noindent\hbox to#5{}}}%
+  \fi
+  \def\@tempa{#8}\ifx\space\@tempa
+    \toks@\@xp{\the\toks@ \thm@headsep\fontdimen\tw@\font\relax}%
+  \else
+    \def\@tempb{\newline}%
+    \ifx\@tempb\@tempa
+      \toks@\@xp{\the\toks@ \thm@headsep\z@skip
+        \def\thmheadnl{\newline}}%
+    \else
+      \toks@\@xp{\the\toks@ \thm@headsep#8\relax}%
+    \fi
+  \fi
+  \begingroup
+  \thm@space@setup
+  \@defaultunits\@tempskipa#2\thm@preskip\relax\@nnil
+  \@defaultunits\@tempskipb#3\thm@postskip\relax\@nnil
+  \xdef\@gtempa{\thm@preskip\the\@tempskipa
+    \thm@postskip\the\@tempskipb\relax}%
+  \endgroup
+  \@temptokena\@xp{\@gtempa
+    \thm@headfont{#6}\thm@headpunct{#7}%
+  }%
+  \@ifempty{#9}{%
+    \let\thmhead\thmhead@plain
+  }{%
+    \@namedef{thmhead@#1}##1##2##3{#9}%
+    \@temptokena\@xp{\the\@temptokena
+      \@xp\let\@xp\thmhead\csname thmhead@#1\endcsname}%
+  }%
+  \@xp\xdef\csname th@#1\endcsname{\the\toks@ \the\@temptokena}%
+}
+\DeclareRobustCommand{\qed}{%
+  \ifmmode \mathqed
+  \else
+    \leavevmode\unskip\penalty9999 \hbox{}\nobreak\hfill
+    \quad\hbox{\qedsymbol}%
+  \fi
+}
+\let\QED@stack\@empty
+\let\qed@elt\relax
+\newcommand{\pushQED}[1]{%
+  \toks@{\qed@elt{#1}}\@temptokena\expandafter{\QED@stack}%
+  \xdef\QED@stack{\the\toks@\the\@temptokena}%
+}
+\newcommand{\popQED}{%
+  \begingroup\let\qed@elt\popQED@elt \QED@stack\relax\relax\endgroup
+}
+\def\popQED@elt#1#2\relax{#1\gdef\QED@stack{#2}}
+\newcommand{\qedhere}{%
+  \begingroup \let\mathqed\math@qedhere
+    \let\qed@elt\setQED@elt \QED@stack\relax\relax \endgroup
+}
+\newif\ifmeasuring@
+\newif\iffirstchoice@ \firstchoice@true
+\def\setQED@elt#1#2\relax{%
+  \ifmeasuring@
+  \else \iffirstchoice@ \gdef\QED@stack{\qed@elt{}#2}\fi
+  \fi
+  #1%
+}
+\def\qed@warning{%
+  \PackageWarning{amsthm}{The \@nx\qedhere command may not work
+    correctly here}%
+}
+\newcommand{\mathqed}{\quad\hbox{\qedsymbol}}
+\def\linebox@qed{\hfil\hbox{\qedsymbol}\hfilneg}
+\@ifpackageloaded{amsmath}{%
+  \def\math@qedhere{%
+    \@ifundefined{\@currenvir @qed}{%
+      \qed@warning\quad\hbox{\qedsymbol}%
+    }{%
+      \@xp\aftergroup\csname\@currenvir @qed\endcsname
+    }%
+  }
+  \def\displaymath@qed{%
+    \relax
+    \ifmmode
+      \ifinner \aftergroup\linebox@qed
+      \else
+        \eqno
+        \let\eqno\relax \let\leqno\relax \let\veqno\relax
+        \hbox{\qedsymbol}%
+      \fi
+    \else
+       \aftergroup\linebox@qed
+    \fi
+  }
+  \@xp\let\csname equation*@qed\endcsname\displaymath@qed
+  \def\equation@qed{%
+    \iftagsleft@
+      \hbox{\phantom{\quad\qedsymbol}}%
+      \gdef\alt@tag{%
+        \rlap{\hbox to\displaywidth{\hfil\qedsymbol}}%
+        \global\let\alt@tag\@empty
+      }%
+    \else
+      \gdef\alt@tag{%
+        \global\let\alt@tag\@empty
+        \vtop{\ialign{\hfil####\cr
+                \tagform@\theequation\cr
+                \qedsymbol\cr}}%
+        \setbox\z@
+      }%
+    \fi
+  }
+  \def\qed@tag{%
+    \global\tag@true \nonumber
+    &\omit\setboxz@h {\strut@ \qedsymbol}\tagsleft@false
+    \place@tag@gather
+    \kern-\tabskip
+    \ifst@rred \else \global\@eqnswtrue \fi \global\advance\row@\@ne \cr
+  }
+  \def\split@qed{%
+    \def\endsplit{\crcr\egroup \egroup \ctagsplit@false \rendsplit@
+      \aftergroup\align@qed
+    }%
+  }
+  \def\align@qed{%
+    \ifmeasuring@ \tag*{\qedsymbol}%
+    \else \let\math@cr@@@\qed@tag
+    \fi
+  }
+  \@xp\let\csname align*@qed\endcsname\align@qed
+  \@xp\let\csname gather*@qed\endcsname\align@qed
+%% Needs some patching up for amsmath 1.2
+}{% end of amsmath branch, start plain LaTeX branch
+  \def\math@qedhere{%
+    \@ifundefined{\@currenvir @qed}{%
+      \qed@warning \aftergroup\displaymath@qed
+    }{%
+      \@xp\aftergroup\csname\@currenvir @qed\endcsname
+    }%
+  }
+  \def\displaymath@qed{%
+    \relax
+    \ifmmode
+      \ifinner \aftergroup\aftergroup\aftergroup\linebox@qed
+      \else
+        \eqno \def\@badmath{$$}%
+        \let\eqno\relax \let\leqno\relax \let\veqno\relax
+        \hbox{\qedsymbol}%
+      \fi
+    \else
+       \aftergroup\linebox@qed
+    \fi
+  }
+  \@ifundefined{ver@leqno.clo}{%
+    \def\equation@qed{\displaymath@qed \quad}%
+  }{%
+    \def\equation@qed{\displaymath@qed}%
+  }
+    \def\@tempa#1$#2#3\@nil#4{%
+        \def#4{#1$#2\def\@currenvir{displaymath}#3}%
+    }%
+    \expandafter\ifx\csname[ \endcsname\relax
+        \expandafter\@tempa\[\@nil\[%
+    \else
+        \expandafter\expandafter\expandafter\@tempa\csname[
+        \expandafter\endcsname\expandafter\@nil
+        \csname[ \endcsname
+    \fi
+}
+\@ifpackageloaded{amstex}{%
+  \def\@tempa{TT}%
+}{%
+  \@ifpackageloaded{amsmath}{%
+    \def\@tempb#1 v#2.#3\@nil{#2}%
+    \ifnum\@xp\@xp\@xp\@tempb\csname ver@amsmath.sty\endcsname v0.0\@nil
+       <\tw@
+      \def\@tempa{TT}%
+    \else
+      \def\@tempa{TF}%
+    \fi
+  }{%
+    \def\@tempa{TF}
+  }%
+}
+\if\@tempa
+  \renewcommand{\math@qedhere}{\quad\hbox{\qedsymbol}}%
+\fi
+\newcommand{\rgddopenbox}{\leavevmode
+  \hbox to.77778em{%
+  \hfil\vrule
+  \vbox to.675em{\hrule width.6em\vfil\hrule}%
+  \vrule\hfil}}
+\DeclareRobustCommand{\textsquare}{%
+  \begingroup \usefont{U}{msa}{m}{n}\thr@@\endgroup
+}
+\providecommand{\qedsymbol}{\rgddopenbox}
+\newenvironment{proof}[1][\proofname]{\par
+  \pushQED{\qed}%
+  \normalfont \topsep6\p@\@plus6\p@\relax
+  \trivlist
+  \item[\hskip\labelsep
+        \itshape
+    #1\@addpunct{.}]\ignorespaces
+}{%
+  \popQED\endtrivlist\@endpefalse
+}
+\providecommand{\proofname}{Proof}
+\endinput
+%%
+%% End of file `amsthm.sty'.
diff --git a/summary/src/abbr.tex b/summary/src/abbr.tex
new file mode 100644
index 0000000..ea8bdcd
--- /dev/null
+++ b/summary/src/abbr.tex
@@ -0,0 +1,19 @@
+\section*{List of Acronyms}
+The introductory summary refrains from using acronyms to make it easily
+digested.  However, a few acronyms are used without definition because their
+full versions are likely less familiar to most readers.  These acronyms are:
+
+\begin{description}
+  \item[DNS] Domain Name System
+  \item[HTML] Hyper Text Markup Language
+  \item[HTTP] Hyper Text Transfer Protocol
+  \item[HTTPS] Hyper Text Transfer Protocol Secure
+  \item[IP] Internet Protocol
+  \item[P4] Programming Protocol-independent Packet Processors
+  \item[RFC] Request For Comments
+  \item[RIPE] R\'{e}seaux IP Europ\'{e}ens
+  \item[RSA] Rivest Shamir Adleman
+  \item[TCP] Transmission Control Protocol
+  \item[TLS] Transport Layer Security
+  \item[XDP] eXpress Data Path
+\end{description}
diff --git a/summary/src/abstract.tex b/summary/src/abstract.tex
new file mode 100644
index 0000000..0a43c0f
--- /dev/null
+++ b/summary/src/abstract.tex
@@ -0,0 +1,36 @@
+Certificate Transparency is an ecosystem of logs, monitors, and auditors that
+hold certificate authorities accountable while issuing certificates.  We show
+how the amount of trust that TLS clients and domain owners need to place in
+Certificate Transparency can be reduced, both in the context of existing gradual
+deployments and the largely unexplored area of Tor.  Our contributions include
+  improved third-party monitoring,
+  a gossip protocol plugging into Certificate Transparency over DNS,
+  an incrementally deployable gossip-audit model tailored for Tor Browser, and
+  using certificates with onion addresses.
+The methods used range from proof sketches to Internet measurements and
+prototype evaluations.  An essential part of our evaluation in Tor is to assess
+how the protocols used during website visits---such as requesting an inclusion
+proof from a Certificate Transparency log---affect unlinkability between senders
+and receivers.  We find that most false positives in website fingerprinting
+attacks can be eliminated for all but the most frequently visited sites.  This
+is because the destination anonymity set can be reduced due to how Internet
+protocols work: communication is observable and often involves third-party
+interactions.  Some of the used protocols can further be subject to side-channel
+analysis.  For example, we show that remote (timeless) timing attacks against
+Tor's DNS cache reliably reveal the timing of past exit traffic.  The severity
+and practicality of our extension to website fingerprinting pose threats to the
+anonymity provided by Tor.  We conclude that access to a so-called website
+oracle should be an assumed attacker capability when evaluating website
+fingerprinting~defenses.
+
+\keywords
+  Auditing,
+  Certificate Transparency,
+  DNS,
+  Gossip,
+  Side-Channels,
+  Timing Attacks,
+  Tor,
+  Tor Browser,
+  Website Fingerprinting,
+  Website Oracles
diff --git a/summary/src/acknowledgements.tex b/summary/src/acknowledgements.tex
new file mode 100644
index 0000000..c585150
--- /dev/null
+++ b/summary/src/acknowledgements.tex
@@ -0,0 +1,40 @@
+I am fortunate to be surrounded by people that helped me reach this milestone in
+one piece.
+First,
+  I want to acknowledge that my brother, Victor, provided me with unlimited
+  tutoring before my PhD studies.  I would not be on my current path without
+  him.
+Second,
+  Sarah and Andreas, thank you for challenging and supporting me.  You have been
+  a determinantal part of my personal growth and well-being.
+Finally,
+  Mom, thank you for being around whenever I need it.
+
+Several doors were opened for me at Karlstad University.  Stefan Alfredsson and
+Stefan Lindskog kick-started my undergraduate studies with programming feedback,
+increased-pace study plans, and the opportunity to be involved in the
+department.  Tobias Pulls introduced me to computer security research.  We have
+worked closely ever since, and \emph{I strongly recommend him as an advisor and
+collaborator}.  Simone Fischer-H\"{u}bner, Stefan Lindskog, Leonardo Martucci,
+and Tobias Pulls all provided sincere advice during my PhD studies.  Many other
+individuals selflessly helped me forward.  Some of them include
+  Ala Sarah Alaqra,
+  Linus Nordberg,
+  Jenni Reuben,
+  Fredrik Str\"{o}mberg, and
+  Paul Syverson.
+
+I am further grateful for my
+collaborators:
+  Matthew Finkel,
+  Toke H{\o}iland-J{\o}rgensen,
+  Andreas Kassler,
+  Linus Nordberg,
+  Tobias Pulls,
+  Tom Ritter,
+  Paul Syverson, and
+  Jonathan Vestin.
+They are all driven individuals that I learned a lot from.
+I also appreciate the generous funding received from
+  the Swedish Knowledge Foundation and
+  the Swedish Foundation for Strategic Research.
diff --git a/summary/src/cat/.gitignore b/summary/src/cat/.gitignore
new file mode 100644
index 0000000..8bb88c8
--- /dev/null
+++ b/summary/src/cat/.gitignore
@@ -0,0 +1,9 @@
+main.pdf
+*.blg
+*.bbl
+*.fls
+*.fdb_latexmk
+*.log
+*.out
+*.aux
+*.swp
diff --git a/summary/src/cat/img/aws.pdf b/summary/src/cat/img/aws.pdf
new file mode 100644
index 0000000..0c3161e
--- /dev/null
+++ b/summary/src/cat/img/aws.pdf
diff --git a/summary/src/cat/img/bt10.pdf b/summary/src/cat/img/bt10.pdf
new file mode 100644
index 0000000..23fbd5c
--- /dev/null
+++ b/summary/src/cat/img/bt10.pdf
diff --git a/summary/src/cat/img/bt100.pdf b/summary/src/cat/img/bt100.pdf
new file mode 100644
index 0000000..b37c523
--- /dev/null
+++ b/summary/src/cat/img/bt100.pdf
diff --git a/summary/src/cat/img/bt1000.pdf b/summary/src/cat/img/bt1000.pdf
new file mode 100644
index 0000000..65e51f8
--- /dev/null
+++ b/summary/src/cat/img/bt1000.pdf
diff --git a/summary/src/cat/img/df_nodef.pdf b/summary/src/cat/img/df_nodef.pdf
new file mode 100644
index 0000000..f72a9d0
--- /dev/null
+++ b/summary/src/cat/img/df_nodef.pdf
diff --git a/summary/src/cat/img/df_wt.pdf b/summary/src/cat/img/df_wt.pdf
new file mode 100644
index 0000000..14a18b0
--- /dev/null
+++ b/summary/src/cat/img/df_wt.pdf
diff --git a/summary/src/cat/img/df_wtfpad.pdf b/summary/src/cat/img/df_wtfpad.pdf
new file mode 100644
index 0000000..e425ae8
--- /dev/null
+++ b/summary/src/cat/img/df_wtfpad.pdf
diff --git a/summary/src/cat/img/dns__classifier-idea.pdf b/summary/src/cat/img/dns__classifier-idea.pdf
new file mode 100644
index 0000000..bf68fff
--- /dev/null
+++ b/summary/src/cat/img/dns__classifier-idea.pdf
diff --git a/summary/src/cat/img/dns__timing-dist.pdf b/summary/src/cat/img/dns__timing-dist.pdf
new file mode 100644
index 0000000..eca8a0a
--- /dev/null
+++ b/summary/src/cat/img/dns__timing-dist.pdf
diff --git a/summary/src/cat/img/dynaflow_config1.pdf b/summary/src/cat/img/dynaflow_config1.pdf
new file mode 100644
index 0000000..de82dc4
--- /dev/null
+++ b/summary/src/cat/img/dynaflow_config1.pdf
diff --git a/summary/src/cat/img/dynaflow_config2.pdf b/summary/src/cat/img/dynaflow_config2.pdf
new file mode 100644
index 0000000..e995173
--- /dev/null
+++ b/summary/src/cat/img/dynaflow_config2.pdf
diff --git a/summary/src/cat/img/dynaflow_nodef.pdf b/summary/src/cat/img/dynaflow_nodef.pdf
new file mode 100644
index 0000000..c481a3d
--- /dev/null
+++ b/summary/src/cat/img/dynaflow_nodef.pdf
diff --git a/summary/src/cat/img/factor-fnp.pdf b/summary/src/cat/img/factor-fnp.pdf
new file mode 100644
index 0000000..933d1ce
--- /dev/null
+++ b/summary/src/cat/img/factor-fnp.pdf
diff --git a/summary/src/cat/img/factor-recall.pdf b/summary/src/cat/img/factor-recall.pdf
new file mode 100644
index 0000000..2e017db
--- /dev/null
+++ b/summary/src/cat/img/factor-recall.pdf
diff --git a/summary/src/cat/img/probfp.pdf b/summary/src/cat/img/probfp.pdf
new file mode 100644
index 0000000..81e8de8
--- /dev/null
+++ b/summary/src/cat/img/probfp.pdf
diff --git a/summary/src/cat/img/setting-oracle.pdf b/summary/src/cat/img/setting-oracle.pdf
new file mode 100644
index 0000000..4620d67
--- /dev/null
+++ b/summary/src/cat/img/setting-oracle.pdf
diff --git a/summary/src/cat/img/setting.pdf b/summary/src/cat/img/setting.pdf
new file mode 100644
index 0000000..1004bf1
--- /dev/null
+++ b/summary/src/cat/img/setting.pdf
diff --git a/summary/src/cat/img/timeuntilvisited.pdf b/summary/src/cat/img/timeuntilvisited.pdf
new file mode 100644
index 0000000..188746b
--- /dev/null
+++ b/summary/src/cat/img/timeuntilvisited.pdf
diff --git a/summary/src/cat/img/wang_csbuflo.pdf b/summary/src/cat/img/wang_csbuflo.pdf
new file mode 100644
index 0000000..0ec042b
--- /dev/null
+++ b/summary/src/cat/img/wang_csbuflo.pdf
diff --git a/summary/src/cat/img/wang_nodef.pdf b/summary/src/cat/img/wang_nodef.pdf
new file mode 100644
index 0000000..7dd0023
--- /dev/null
+++ b/summary/src/cat/img/wang_nodef.pdf
diff --git a/summary/src/cat/img/wang_tamaraw.pdf b/summary/src/cat/img/wang_tamaraw.pdf
new file mode 100644
index 0000000..7f902ff
--- /dev/null
+++ b/summary/src/cat/img/wang_tamaraw.pdf
diff --git a/summary/src/cat/main.tex b/summary/src/cat/main.tex
new file mode 100644
index 0000000..5dd9d84
--- /dev/null
+++ b/summary/src/cat/main.tex
@@ -0,0 +1,70 @@
+\begin{kaupaper}[
+    author={%
+      Tobias Pulls and \textbf{Rasmus Dahlberg}
+    },
+    title={%
+      Website Fingerprinting with Website Oracles
+    },
+    reference={%
+      PETS (2020)
+    },
+    summary={%
+      One of the properties Tor aims to provide against local network attackers
+      is unlinkability between end-users (sender anonymity set) and their
+      destinations on the Internet (receiver anonymity set).  A website
+      fingerprinting attack aims to break anonymity in this model by inferring
+      which website an identifiable end-user is visiting based only on the
+      traffic entering the Tor network.  We extend the attacker model for
+      website fingerprinting attacks by introducing the notion of \emph{website
+      oracles}.  A website oracle answers the following question: was website $w$
+      visited during time frame $t$?  In other words, the attacker can query the
+      receiver anonymity set for websites that were (not) visited.  Our
+      simulations show that augmenting past website fingerprinting attacks to
+      include website oracles significantly reduces false positives for all but
+      the most popular websites, e.g., to the order of $10^{-6}$ for
+      classifications around Alexa top-10k and much less for the long tail of
+      sites.  Further, some earlier website fingerprinting defenses are largely
+      ineffective in the (stronger) attacker model that includes website
+      oracles.  We discuss a dozen real-world website oracles ranging from
+      centralized access logs to widely accessible real-time bidding platforms
+      and DNS caches, arguing that they are inherent parts of the protocols used
+      to perform website visits.  Therefore, access to a website oracle should
+      be an assumed attacker capability when evaluating which website
+      fingerprinting defenses are effective.
+    },
+    participation={\vspace{-.25cm}
+      Tobias is the main author and conducted most of the work.  I mainly
+      contributed by coining the name \emph{website oracle}, evaluating
+      sources of real-world website oracles, and performing our non-simulated
+      network experiments.
+    },
+    label={
+      paper:cat
+    },
+]
+  \maketitle
+  \begin{abstract}
+    \input{src/cat/src/abstract}
+  \end{abstract}
+
+  \input{src/cat/src/intro}
+  \input{src/cat/src/background}
+  \input{src/cat/src/oracles}
+  \input{src/cat/src/sources}
+  \input{src/cat/src/sim}
+  \input{src/cat/src/wf}
+  \input{src/cat/src/discussion}
+  \input{src/cat/src/related}
+  \input{src/cat/src/conclusions}
+  \input{src/cat/src/ack}
+
+  \bibliographystyle{plain}
+  \bibliography{src/cat/src/ref-min}
+  
+  \begin{appendices}
+    \input{src/cat/src/bayes}
+    \input{src/cat/src/lessons}
+    \input{src/cat/src/othersources}
+  \end{appendices}
+
+\end{kaupaper}
diff --git a/summary/src/cat/src/abstract.tex b/summary/src/cat/src/abstract.tex
new file mode 100644
index 0000000..da09599
--- /dev/null
+++ b/summary/src/cat/src/abstract.tex
@@ -0,0 +1,25 @@
+\noindent
+Website Fingerprinting (WF) attacks are a subset of traffic analysis attacks
+where a local passive attacker attempts to infer which websites a target victim
+is visiting over an encrypted tunnel, such as the anonymity network Tor. We
+introduce the security notion of a \emph{Website Oracle} (WO) that gives a WF
+attacker the capability to determine whether a particular monitored website was
+among the websites visited by Tor clients at the time of a victim's trace. Our
+simulations show that combining a WO with a WF attack---which we refer to as a
+WF+WO attack---significantly reduces false positives for about half of all
+website visits and for the vast majority of websites visited over Tor. The
+measured false positive rate is on the order one false positive per million
+classified website trace for websites around Alexa rank 10,000. Less popular
+monitored websites show orders of magnitude lower false positive rates.
+
+{\setlength{\parindent}{6mm} We argue that WOs are inherent to the setting of
+anonymity networks and should be an assumed capability of attackers when
+assessing WF attacks and defenses. Sources of WOs are abundant and available to
+a wide range of realistic attackers, e.g., due to the use of DNS, OCSP, and
+real-time bidding for online advertisement on the Internet, as well as the
+abundance of middleboxes and access logs. Access to a WO indicates that the
+evaluation of WF defenses in the open world should focus on the highest possible
+recall an attacker can achieve. Our simulations show that augmenting the Deep
+Fingerprinting WF attack by Sirinam \emph{et~al.}~\cite{DF} with access to a WO
+significantly improves the attack against five state-of-the-art WF defenses,
+rendering some of them largely ineffective in this new WF+WO setting.}
diff --git a/summary/src/cat/src/ack.tex b/summary/src/cat/src/ack.tex
new file mode 100644
index 0000000..4008faf
--- /dev/null
+++ b/summary/src/cat/src/ack.tex
@@ -0,0 +1,9 @@
+\section*{Acknowledgements}
+We would like to thank Jari Appelgren, Roger Dingledine, Nicholas Hopper, Marc
+Juarez, George Kadianakis, Linus Nordberg, Mike Perry, Erik Wästlund, and the
+PETS reviewers for their valuable feedback. Simulations were performed using the
+Swedish National Infrastructure for Computing (SNIC) at
+High Performance Computing Center North (HPC2N)
+This research was funded by the
+Swedish Internet Foundation and the
+Knowledge Foundation of Sweden.
diff --git a/summary/src/cat/src/background.tex b/summary/src/cat/src/background.tex
new file mode 100644
index 0000000..bb64337
--- /dev/null
+++ b/summary/src/cat/src/background.tex
@@ -0,0 +1,211 @@
+\section{Background} \label{cat:sec:back}
+Here we present background on terminology, the anonymity network Tor,
+and WF attacks and defenses. 
+
+\subsection{Anonymity and Unobservability}
+Anonymity is the state of a subject not being identifiable from an attackers
+perspective within the \emph{anonymity set} of possible subjects that performed
+an action such as sending or receiving a message~\cite{anonterm}. For an
+anonymity network, an attacker may not be able to determine who sent a message
+into the network---providing a sender anonymity set of all possible
+senders---and conversely, not be able to determine the recipient of a message
+from the network out of all possible recipients in the recipient anonymity set.
+Inherent for anonymity is that the subjects in an anonymity set change based on
+what the attacker observes, e.g., when some subjects send or receive
+messages~\cite{KedoganAP02,Raymond00}. In gist, anonymity is concerned with
+hiding the \emph{relationship} between a sender and recipient, not its
+existence. 
+
+Unobservability is a strictly stronger notion than
+anonymity~\cite{KedoganAP02,anonterm,Raymond00}. In addition to anonymity of the
+relationship between a sender and recipient, unobservability also requires that
+an attacker (not acting as either the sender or recipient) cannot sufficiently
+distinguish if there is a sender or recipient or not~\cite{anonterm}. Perfect
+unobservability is therefore the state of an attacker being unable to determine
+if a sender/recipient should be part of the anonymity set or not.
+
+\subsection{Tor}
+Tor is a low-latency anonymity network for anonymising TCP streams with about
+eight million daily users, primarily used for anonymous browsing, censorship
+circumvention, and providing anonymous (onion) services~\cite{tor,torusage}.
+Because Tor is designed to be usable for low-latency tasks such as web browsing,
+its threat model and design does not consider powerful attackers, e.g., global
+passive adversaries that can observe all network traffic on the
+Internet~\cite{trilemma,tor}. However, less powerful attackers such as ISPs and
+ASes that observe a fraction of network traffic on the Internet are in scope. 
+
+Users typically use Tor Browser---a customised version of Mozilla Firefox
+(bundled with a local relay)---as a client that sends traffic through three
+\emph{relays} when browsing a website on the regular Internet: a guard, middle,
+and exit relay. Traffic from the client to the exit is encrypted in multiple
+layers as part of fixed-size cells such that only the guard relay knows the
+IP-address of the client and only the exit relay knows the destination website.
+There are about 7000 public relays at the time of writing, all available in the
+\emph{consensus} generated periodically by the network. The consensus is public
+and therefore anyone can trivially determine if traffic is coming from the Tor
+network by checking if the IP-address is in the consensus. Note that the
+encrypted network traffic in Tor is exposed to network adversaries as well as
+relays as it traverses the Internet. Figure~\ref{cat:fig:setting} depicts the
+setting just described, highlighting the anonymity sets of users of Tor Browser
+and the possible destination websites. 
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=.85\columnwidth]{src/cat/img/setting}
+	\caption{Using Tor to browse to a website, where an attacker observes the encrypted traffic into the Tor network for a target user, attempting to determine the website the user is visiting.}
+	\label{cat:fig:setting}
+\end{figure}
+
+\subsection{Website Fingerprinting}
+\label{cat:sec:back:wf}
+As mentioned in the introduction, attacks that analyse the encrypted network
+traffic (a trace) between a Tor client and a guard relay with the goal to detect
+the website a client is visiting are referred to as \emph{website
+fingerprinting} (WF) attacks. Figure~\ref{cat:fig:setting} shows the typical
+location of the attacker, who can also be the guard itself. WF attacks are
+evaluated in either the \emph{closed} or the \emph{open} world. In the closed
+world, an attacker \emph{monitors} a number of websites and it is the goal of
+the attacker to determine which website out of all the possible monitored
+websites a target is visiting. The open world is like the closed world with one
+significant change: the target user may also visit \emph{unmonitored} websites.
+This means that in the open world the attacker may also classify a trace as
+unmonitored in addition to monitored, posing a significantly greater challenge
+for the attacker in a more realistic setting than the closed world. The ratio
+between monitored and unmonitored traces in a dataset is further a significant
+challenge for WF attacks when assessing their real-world significance for
+Tor~\cite{DBLP:conf/ccs/JuarezAADG14}. Typically, WF attacks are evaluated on
+the frontpages of web\emph{sites}: web\emph{page} fingerprinting is presumably
+much more challenging due to the orders of magnitude of more webpages than
+websites. Unless otherwise stated, we only consider the frontpages of websites
+in this paper. 
+
+\subsubsection{Website Fingerprinting Attacks}
+Prior to WF attacks being considered for use on Tor, they were used against
+HTTPS~\cite{cheng1998traffic}, web
+proxies~\cite{Hintz02,DBLP:conf/sp/SunSWRPQ02}, SSH
+tunnels~\cite{DBLP:conf/ccs/LiberatoreL06}, and VPNs~\cite{HerrmannWF09}. For Tor, WF attacks are typically based on machine learning and can be
+categorized based on if they use deep learning or not. 
+
+Traditional WF attacks in the literature use manually engineered features
+extracted from both the size and timing of packets (and/or cells) sent by Tor.
+State of the art attacks with manually engineered features are
+Wang-kNN~\cite{Wang}, CUMUL~\cite{cumul}, and k-FP~\cite{kfp}. For reference,
+Wang-kNN has 1225 features, CUMUL 104 features, and k-FP 125 features. In terms
+of accuracy, k-FP appears to have a slight edge over the other two, but all
+three report over 90\% accuracy against significantly sized datasets. As
+traditional WF attacks progressed, the features more than the type of machine
+learning method have shown to be vital for the success of attacks, with an
+emerging consensus on what are important features (e.g., coarse features like
+number of incoming and outgoing packets)~\cite{Cherubin17,kfp,cumul}.
+
+Deep learning was first used for WF attacks by Abe and Goto in
+2016~\cite{abe2016fingerprinting}. Relatively quickly, Rimmer \emph{et~al.}
+reached parity with traditional WF attacks, lending credence to the emerging
+consensus that the research community had found the most important features for
+WF~\cite{DBLP:conf/ndss/RimmerPJGJ18}. However, recently Sirinam et
+al.~\cite{DF} with Deep Fingerprinting (DF) significantly improved on other WF
+attacks, also on the WTF-PAD and Walkie-Talkie defenses, and is at the time of
+writing considered state-of-the-art. DF is based on a Convolutional Neural
+Network (CNN) with a customized architecture for WF. Each packet trace as input
+to DF is simply a constant size (5000) list of cells (or packets) and their
+direction (positive for outgoing, negative for incoming), ignoring size and
+timings. Based on the input, the CNN learns features on its own: we do not know
+what they are, other than preliminary work indicating that the CNN gives more
+weight to input early in the trace~\cite{mathews2018understanding}. 
+
+The last layer of the CNN-based architecture of DF is a \emph{softmax} function:
+it assigns (relative) probabilities to each class as the output of
+classification. These probabilities allow a threshold to be defined for the
+final classification in the open world, requiring that the probability of the
+most likely class is above the threshold to classify as a monitored website. 
+
+\subsubsection{Website Fingerprinting Defenses}
+WF defenses for Tor modify the timing and number of (fixed-size) cells sent over
+Tor when a website is visited. The modifications are done by injecting dummy
+traffic and introducing artificial delays. Defenses can typically be classified
+as either based on constant-rate traffic or not, where constant rate defenses
+force all traffic to fit a pre-determined structure, forming \emph{collision
+sets} for websites where their traffic traces appear identical to an attacker.
+Non-constant rate defenses simply more-or-less randomly inject dummy traffic
+and/or artificial delays with the hope of obfuscating the resulting network
+traces. WF defenses are typically compared in terms of their induced
+\emph{bandwidth} (BOH) and \emph{time} (TOH) overheads compared to no defense.
+Further, different WF defenses make more or less realistic and/or practical
+assumptions, making comparing overheads necessary but not nearly sufficient for
+reaching conclusions. 
+
+We briefly describe WF defenses that we later use to evaluate the impact of
+attackers performing enhanced WF attacks with access to WOs:
+\begin{description}
+    \item[Walkie-Talkie] by Wang and Goldberg~\cite{WT} puts Tor Browser into
+    half duplex mode and pads traffic such that different websites result in the
+    same cell sequences. This creates a collision set between a visited website
+    and  a target \emph{decoy website} which results in the same cell sequence
+    with the defense. Their evaluation shows 31\% BOH and 34\% TOH. Collision
+    sets grow beyond size two at the cost of BOH.
+    \item[WTF-PAD] by Juarez \emph{et~al.}~\cite{wtf-pad} is based on the idea
+    of \emph{adaptive padding} \cite{DBLP:conf/esorics/ShmatikovW06} where fake
+    padding is injected only when there is no real traffic to send. The defense
+    is simulated on collected packet traces and its design is the foundation of
+    the circuit padding framework recently implemented in Tor. The simulations
+    report  50-60\% BOH and 0\% TOH.
+    \item[CS-BuFLO] by Cai \emph{et~al.}~\cite{csbuflo} is a \emph{constant rate}
+    defense where traffic is always sent at a constant rate between a sender and
+    receiver, improving on prior work by Dyer~et
+    al.~\cite{DBLP:conf/sp/DyerCRS12}. Their evaluation shows 220-270\% BOH and
+    270-340\% TOH.
+    \item[Tamaraw] by Cai \emph{et~al.}~\cite{Tamaraw} is another constant rate defense
+    that further improves on CS-BuFLO. In the evaluation by Wang and Goldberg,
+    they report  103\% BOH and 140\% TOH for Tamaraw~\cite{WT}.
+    \item[DynaFlow] by Lu \emph{et~al.}~\cite{DynaFlow} is a \emph{dynamic}
+    constant-rate defense that allows for the defense to adjust its parameters
+    (notably the ``inter-packet interval'') based on configuration and on the
+    observed traffic. The evaluation shows an overall improvement over Tamaraw
+    when configured to use similar overheads. 
+\end{description}
+The primary downside of defenses like Walkie-Talkie that depend on creating
+collision sets for websites is that they require up-to-date knowledge of the
+target website(s) to create collisions with (to know how to morph the traffic
+traces): this is a significant practical issue for
+deployment~\cite{DBLP:conf/wpes/NithyanandCJ14,Wang,WT}. Constant rate defenses
+like CS-BuFLO and Tamaraw are easier to deploy but suffer from significant
+overheads~\cite{csbuflo,Tamaraw}. WTF-PAD is hard to implement both efficiently
+and effectively in practice due to only being simulated on packet traces as-is
+and also being vulnerable to attacks like Deep Fingerprinting~\cite{wtf-pad,DF}.
+While DynaFlow shows great promise, but requires changes at the client (Tor
+Browser, local relay, or both) and at exit relays to \emph{combine} packets with
+payloads smaller than Tor's cell size~\cite{DynaFlow}. Without combined packets
+its advantage in terms of overhead compared to Tamaraw likely shrinks. 
+
+\subsection{Challenges for WF Attacks in Practice}
+A number of practical challenges for an attacker performing WF attacks have been
+highlighted over the years, notably comprehensively so by Mike Perry of the Tor
+Project~\cite{perryCrit} and Juarez et
+al.~\cite{DBLP:conf/ccs/JuarezAADG14}. Wang and Goldberg have showed that
+several of the highlighted challenges---such as maintaining a fresh data set and
+determining when websites are visited---are practical to overcome~\cite{DBLP:journals/popets/WangG16}. What remains are two notably
+significant challenges: distinguishing between different goals of the attacker
+and addressing false positives.
+
+
+For attacker goals when performing WF attacks, an attacker may want to detect
+website visits with the goal of censoring access to it, to identify all users
+that visit particular websites, or to identify every single website visited by
+a target~\cite{perryCrit}. Clearly, these goals put different
+constraints on the attacker. For censorship, classification must happen before
+content is actually allowed to be completely transferred to the victim. For
+monitoring only a select number of websites the attacker has the most freedom,
+while detecting all website visits by a victim requires the attacker to have
+knowledge of all possible websites on the web. 
+
+For addressing false positives there are a number of aspects to take into
+account. First, the web has millions of websites that could be visited by a
+victim (not the case for onion services~\cite{JansenJGED18}), and each website
+has a significant number of webpages that are often dynamically generated and
+frequently changed~\cite{DBLP:conf/ccs/JuarezAADG14,perryCrit}. Secondly, how
+often victims potentially visit websites that are monitored by an attacker is
+unknown to the attacker, i.e., the \emph{base rate} of victims are unknown. The
+base rate leads to even a small false positive rate of a WF attack overwhelming
+an attacker with orders of magnitude more false positives than true positives,
+leaving WF attacks impractical for most attacker goals in practice. 
+
diff --git a/summary/src/cat/src/bayes.tex b/summary/src/cat/src/bayes.tex
new file mode 100644
index 0000000..344d712
--- /dev/null
+++ b/summary/src/cat/src/bayes.tex
@@ -0,0 +1,96 @@
+\section{Bayes' Law for Estimating Utility of Website Oracles} \label{cat:app:bayes}
+
+To reason about the advantage to an attacker of having access to a WO, we
+estimate the conditional probability of a target user visiting a monitored
+website. For conditional probability we know that:
+\begin{equation}
+	P(C_0 \cap C_1) = P(C_0|C_1)P(C_1)
+\end{equation}
+
+For a hypothesis $H$ given conditional evidence $E$, Bayes' theorem states
+that:
+\begin{equation}
+	P(H|E) = \frac{P(E|H) P(H)}{P(E)}
+\end{equation}
+
+Assume that E = $E_0 \cap E_1$, then:
+\begin{equation}
+	P(H|E_0 \cap E_1) = \frac{P(E_0 \cap E_1|H) P(H)}{P(E_0 \cap E_1)}
+\end{equation}
+
+Substituting $P(E_0 \cap E_1)$ with (1) we get:
+\begin{equation}
+	P(H|E_0 \cap E_1) = \frac{P(E_0 \cap E_1|H) P(H)}{P(E_0|E_1)P(E_1)}
+\end{equation}
+
+For a timeframe $t$, we define
+\begin{description}
+	\item[$H$] the probability that target user(s) visited website $w$ over Tor in $t$
+	\item[$E_0$] the probability that target user(s) visited a website over Tor in $t$
+	\item[$E_1$] the probability that someone visited website $w$ over Tor in $t$
+\end{description}
+
+We see that $P(E_0 \cap E_1|H) = 1$ by definition and get:
+\begin{equation}
+	P(H|E_0 \cap E_1) = \frac{P(H)}{P(E_0|E_1)P(E_1)}
+\end{equation}
+
+Consider $P(E_0|E_1)$: while the conditional $E_1$ may have some minor affect on
+user behaviour (in particular for overall popular websites), we assume that the
+popularity of using Tor to visit a particular website (by any of the users of
+Tor) has negligible impact on $E_0$ and treat $E_0$ and $E_1$ as independent:
+
+\begin{equation}
+	P(H|E_0 \cap E_1) = \frac{P(H)}{P(E_0)P(E_1)}
+\end{equation}
+
+We can further refine $P(H)$ as being composed of at least:
+
+\begin{equation}
+	P(H) = P(E_0) \cap P(B_w) = P(E_0|B_w)P(B_w)
+\end{equation}
+
+Where $P(B_w)$ is the base rate (prior) of the user(s) visiting website $w$ out
+of all possible websites they visit ($P(E_0)$). We again assume (perhaps
+naively) that $E_0$ is also independent of $B_w$, which gives us:
+
+\begin{equation}
+	P(H|E_0 \cap E_1) = \frac{P(E_0)P(B_w)}{P(E_0)P(E_1)} = \frac{P(B_w)}{P(E_1)}
+\end{equation}
+
+In other words, if an attacker learns that target user(s) visited a website
+($E_0$) over Tor and that website $w$ was also visited over Tor by some user
+($E_1$), then we can estimate the probability that it was target user(s) that
+visited website $w$ ($H$) as the ratio between the base rate (prior) for
+visiting $w$ of target user(s) ($B_w$) and the probability that someone visited
+the website over Tor ($E_1$), all within a timeframe $t$.
+
+Figure~\ref{cat:fig:bt} shows the results for simulating the probability $P(H|E_0
+\cap E_1)$ for different website popularities of $w$, base rates, and
+timeframes. We see that with a realistic timeframe of $100$ ms, for all
+base-rates but $10^{-6}$ there is non-zero conditional probability (and
+therefore utility of WO access) for Alexa top 100k or less popular websites,
+which covers about half of all website visits over Tor (excluding
+\url{torproject.org}).
+
+\begin{figure}[!t]
+	\centering
+	\begin{subfigure}{.495\columnwidth}
+	\includegraphics[width=1\textwidth]{src/cat/img/bt10}
+	\caption{10 ms}
+	\label{cat:fig:bt:10ms}
+	\end{subfigure}
+	\begin{subfigure}[b]{.495\columnwidth}
+	\includegraphics[width=1\textwidth]{src/cat/img/bt100}
+	\caption{100 ms}
+	\label{cat:fig:bt:100ms}
+	\end{subfigure}
+	\begin{subfigure}[b]{.495\columnwidth}
+	\includegraphics[width=1\textwidth]{src/cat/img/bt1000}
+	\caption{1000 ms}
+	\label{cat:fig:bt:1000ms}
+	\end{subfigure}
+	\caption{The conditional probability as a function of user base rate and
+	website popularity (Alexa) for three different timeframes.}
+	\label{cat:fig:bt}
+\end{figure}
diff --git a/summary/src/cat/src/conclusions.tex b/summary/src/cat/src/conclusions.tex
new file mode 100644
index 0000000..8554d23
--- /dev/null
+++ b/summary/src/cat/src/conclusions.tex
@@ -0,0 +1,25 @@
+\section{Conclusions} \label{cat:sec:conc}
+WF+WO attacks use the base rate of all users of the network against victims,
+significantly reducing false positives in the case of all but the most popular
+websites visited over Tor. This is troubling in many ways, in part because
+presumably many sensitive website visits are to unpopular websites used only by
+local communities in regions of the world where the potential consequences of
+identification are the worst. 
+
+The threat model of Tor explicitly states that Tor does not consider attackers
+that can observe both incoming and outgoing traffic~\cite{tor}. Clearly, a WO
+gives the capability to infer what the outgoing traffic of the network encodes
+on the application layer (the website visits). This is in a sense a violation of
+Tor's threat model when combined with a WF attacker that also observes incoming
+traffic. However, we argue that because of the plethora of possible ways for an
+attacker to infer membership in the anonymity sets of Tor, WOs should be
+considered within scope simply because Tor asserts that it is an anonymity
+network. 
+
+While the real-world impact of WF attacks on Tor users remains an open question,
+our simulations show that false positives can be signficantly reduced by many
+attackers with little extra effort for some WO sources. Depending on WO source,
+this comes at a trade-off of less recall. For many attackers and attacker goals,
+however, this is a worthwhile trade. To us, the threat of WF attacks appears
+more real than ever, especially when also considering recent advances by deep
+learning based attacks like DF~\cite{DF} and DeepCorr~\cite{deepcorr}.
diff --git a/summary/src/cat/src/discussion.tex b/summary/src/cat/src/discussion.tex
new file mode 100644
index 0000000..0de8584
--- /dev/null
+++ b/summary/src/cat/src/discussion.tex
@@ -0,0 +1,153 @@
+\section{Discussion} \label{cat:sec:disc}
+For defenses that are based on the idea of creating collision sets between
+packet traces generated by websites, oracle access is equivalent to being able
+to perform set intersection between the set of websites in a collision set and
+monitored websites visited at the time of fingerprinting. As the results show
+from Section~\ref{cat:sec:wf}, some defenses can significantly reduce the recall of
+WF attacks with WOs, but not the precision for the majority of websites and
+website visits in Tor. 
+
+Next, in Section~\ref{cat:sec:disc:unmon} we further cement that our simulations
+show that WOs significantly reduces false positives, highlighting that a WF+WO
+attacker surprisingly infrequently have to query a WO when classifying
+unmonitored traces. Section~\ref{cat:sec:disc:flawed} discusses the impact of
+imperfect WO sources with limited observability and false positives on the joint
+WF+WO attack. Finally, Section~\ref{cat:sec:disc:limits} covers limitations of our
+work, and Section~\ref{cat:sec:disc:miti} discusses possible mitigations.
+
+\subsection{A Large Unmonitored Dataset}
+\label{cat:sec:disc:unmon}
+We look at the number of false positives for a large test dataset consisting of
+only unmonitored websites (representing a target user(s) with base rate 0, i.e.,
+that never visits any monitored website). Using the dataset of Greschbach et
+al.~\cite{DBLP:conf/ndss/GreschbachPRWF17}, we trained DF on 100x100 monitored
+and 10k unmonitored websites (8:2 stratified split for validation), resulting in
+about 80\% validation accuracy after 30 epochs (so DF is clearly successful also
+on this dataset). We then tested the trained classifier on \emph{only} 100k
+\emph{unmonitored} traces, with and without oracle access (100ms resolution) for
+different assumptions of the popularity of the \emph{monitored} websites. With
+ten repetitions of the above experiment, we observed a false positive rate in
+the order of $10^{-6}$ for monitored websites with Alexa popularity 10k.
+Excluding \url{torproject.org}, this indicates that an attacker would have close
+to no false positives for about half of all website visits in Tor, according to
+the distribution of Mani \emph{et~al.}~\cite{torusage} (see
+Section~\ref{cat:sec:sim:dist}). Without access to a WO, DF had a false positive
+rate in the order of $10^{-3}$ to $10^{-4}$, depending on the threshold used by
+the attacker. 
+
+Recall how WOs are used as part of WF+WO attacks in
+Section~\ref{cat:sec:oracles:generic}: the WO is only used if the WF attack
+classifies a trace as monitored.\footnote{For WF attacks like DF that produces a
+list of probabilities (Definition~\ref{cat:def:oracleprob}), just assume that the
+attacker picks the threshold and checks if the probability is above as part of
+the if-statement before using the WO.} This means that, in the example above,
+the WO is used on average every $10^3$ to $10^4$ trace, to (potentially) rule
+out a false positive. Clearly, this means that WO sources that can only be used
+infrequently, e.g., due to caching as in DNS, are still valuable for an
+attacker.
+
+\subsection{Imperfect Website Oracle Sources}
+\label{cat:sec:disc:flawed}
+Our analysis considered an ideal source of a WO that observes all visits to
+targeted \emph{monitored} websites of the attacker and that produces no false
+positives. Next, using the same dataset and setup as for
+Figure~\ref{cat:fig:df:nodef} with an Alexa starting rank of $10^4$, we simulate the
+impact on recall and the False-Negative-to-Positive-rate\footnote{For a
+classifier with multiple monitored classes and an unmonitored class (as for our
+modified DF, see Section~\ref{cat:sec:wf:aug}), FNP captures the case when the
+classifier classifies an unmonitored testing trace as any monitored class. In
+addition to FNP, such a classifier can also confuse one monitored website for
+another. Both these cases are false positives~\cite{Wang2015a}.} (FNP) of the
+\emph{joint} WF+WO attack for five false positive rates \emph{of the WO} and a
+fraction of observed website visits.
+
+Figure~\ref{cat:fig:factor-recall} shows the impact on the joint recall in the above
+setting. We see that recall is directly proportional to the fraction of observed
+visits, as per the results of Greschbach
+\emph{et~al.}~\cite{DBLP:conf/ndss/GreschbachPRWF17}. Further, false positives
+for the WO have a positive impact on the fraction of recall, counteracting
+visits missed due to limited observability. For the same reason, a larger
+timeframe or monitoring more popular websites would also improve recall.
+
+\begin{figure}[!t]
+	\centering
+  \includegraphics[width=.67\columnwidth]{src/cat/img/factor-recall}
+	\caption{How limited WO observability effects the final recall of a WF+WO attack for five different WO false positive rates.}
+	\label{cat:fig:factor-recall}
+\end{figure}
+
+Figure~\ref{cat:fig:factor-fnp} shows the impact on the joint FNP. Note that lower
+FNP is better for an attacker. We see that limited observability has no impact
+on FNP. This makes sense, because a WO cannot confirm anything it does not
+observe. The FNP fraction for the joint FNP is roughly proportional to the FP of
+the WO. We also see that the FNP fraction consistently is above the FP of the
+WO: this is because---beyond the simulated FP---there is a slight probability
+that someone else (in our simulation of the Tor network) visited the website for
+each classified trace. A larger timeframe or monitoring more popular websites
+would also increase FNP. 
+
+\begin{figure}[!t]
+	\centering
+  \includegraphics[width=.67\columnwidth]{src/cat/img/factor-fnp}
+	\caption{How limited WO observability effects the final False-Negative-to-Positive-rate (FNP) of a WF+WO attack for five different WO false positive rates. Lower is better.}
+	\label{cat:fig:factor-fnp}
+\end{figure}
+
+From above results, our simulations indicate that even with a deeply imperfect
+WO source an attacker can get significant advantage in terms of reduced false
+positives at a comparatively small cost of recall. For example, given a WO with
+50\% observability and false positives, the resulting WF+WO attack has about
+75\% of the recall of the WF attack and slightly more than half the false
+positives. 
+
+\subsection{Limitations}
+\label{cat:sec:disc:limits}
+As discussed in Section~\ref{cat:sec:back:wf}, there are a number of practical
+limitations in general for WF attacks. Regarding attacker goals, WOs are likely
+less useful for the purpose of censorship than for other goals. Many sources of
+WOs cannot be accessed in real-time, giving little utility for an attacker that
+needs to make a near real-time censorship decision. An attacker that only wants
+to detect visits to a few selected monitored websites gains significant utility
+from WOs, as long as the detection does not have to be in real-time. It is also
+noteworthy that an attacker that wants to detect all possible website visits by
+a victim can use the WO to in essence ``close the world'' from all possible
+websites to only those visited over Tor while the victim is actively browsing.
+Granted, this requires a source for the WO that is slightly different from our
+definition, but some do offer this: e.g., an attacker that gains comprehensive
+control over the DNS resolvers used by Tor
+exits~\cite{DBLP:conf/ndss/GreschbachPRWF17}. 
+
+When it comes to false positives a significant limitation of our simulations is
+that we consider fingerprinting the frontpages of websites and not specific
+webpages. Several sources or WOs are not able to detect webpage visits. This is
+also true for subsequent webpage visits on the same website after first visiting
+the frontpage of a website (e.g., DNS and OCSP will be cached). An attacker with
+the goal of detecting each such page visit will thus suffer more false positives
+or fail at detecting them for some sources of WOs.
+
+\subsection{Mitigations}
+\label{cat:sec:disc:miti}
+The best defense against WOs is WF defenses that significantly reduce the recall
+of WF attacks. In particular, if an attacker can significantly reduce the
+website anonymity set \emph{after} accounting for information from the WO, then
+attacks are likelier to succeed. This implies that most websites need to (at
+least have the potential to) result in the same network traces, as we see with
+DynaFlow, Tamaraw, and CS-BuFLO. 
+
+For onion websites we note that the DHT source of a WO from
+Section~\ref{cat:sec:sources} is inherent to the design of onion services in Tor.
+Defenses that try to make it harder to distinguish between regular website
+visits and visits to onion websites should also consider this WO source as part
+of their analysis, in particular for v2 onion services.
+
+Finally, some sources of WOs could be minimized. If you run a potentially
+sensitive website: do not use RTB ads, staple OCSP, have as few DNS entries as
+possible\footnote{As noted by
+Greschbach~\emph{et~al.}~\cite{DBLP:conf/ndss/GreschbachPRWF17}, websites may
+have several unique domain names. Each of those could be used independently to
+query several sources (e.g., DNS) of WOs.} with a high TTL, do not use CDNs, do
+not retain any access logs, and consider if your website, web server, or
+operating system have any information leaks that can be used as an oracle. If
+you run a Tor exit, consider not using Google or Cloudflare for your DNS but
+instead use your ISP's resolver if
+possible~\cite{DBLP:conf/ndss/GreschbachPRWF17}.
diff --git a/summary/src/cat/src/intro.tex b/summary/src/cat/src/intro.tex
new file mode 100644
index 0000000..b65baa9
--- /dev/null
+++ b/summary/src/cat/src/intro.tex
@@ -0,0 +1,122 @@
+\section{Introduction} \label{cat:sec:intro}
+A Website Fingerprinting (WF) attack is a type of traffic analysis attack where
+an attacker attempts to learn which websites are visited through encrypted
+network tunnels---such as the low-latency anonymity network Tor~\cite{tor} or
+Virtual Private Networks (VPNs)---by analysing the encrypted network
+traffic~\cite{cheng1998traffic,HerrmannWF09,Hintz02,DBLP:conf/ccs/LiberatoreL06,PanchenkoNZE11,DBLP:conf/sp/SunSWRPQ02}.
+The analysis considers only the size and timing of encrypted packets sent over
+the network to and from a target client. This makes it possible for attackers
+that only have the limited \emph{capability} of observing the encrypted network
+traffic (sometimes referred to as a \emph{local eavesdropper}) to perform WF
+attacks. Sources of such capabilities include ISPs, routers, network interface
+cards, WiFi hotspots, and guard relays in the Tor network, among others. Access
+to encrypted network traffic is typically not well-protected over the Internet
+because it is already in a form that is considered safe to expose to attackers
+due to the use of encryption. 
+
+The last decade has seen significant work on improved WF attacks (e.g.,
+\cite{CaiZJJ12,kfp,DF,Wang}) and defenses (e.g,
+\cite{csbuflo,Tamaraw,wtf-pad,DynaFlow}) accompanied by an ongoing debate on the
+real-world impact of these attacks justifying the deployment of defenses or not,
+in particular surrounding Tor (e.g.,
+\cite{DBLP:conf/ccs/JuarezAADG14,perryCrit,DBLP:journals/popets/WangG16}).
+There are significant real-world challenges for an attacker to successfully
+perform WF attacks, such as the sheer size of the web (about 200 million active
+websites~\cite{netcraft-survey}),
+detecting the beginning of website loads in encrypted network traces, background
+traffic, maintaining a realistic and fresh training data set, and dealing with
+false positives. 
+
+Compared to most VPN implementations, Tor has some basic but rather ineffective
+defenses in place against WF attacks, such as padding packets to a constant size
+and randomized HTTP request pipelining~\cite{CaiZJJ12,tor,Wang}. Furthermore,
+Tor recently started implementing a framework for circuit padding machines to
+make it easier to implement traffic analysis defenses~\cite{tor-0401}
+based on adaptive padding~\cite{wtf-pad,DBLP:conf/esorics/ShmatikovW06}.
+However, the unclear real-world impact of WF attacks makes deployment of
+proposed effective (and often prohibitively costly in terms of bandwidth and/or
+latency overheads) WF defenses a complicated topic for researchers to reach
+consensus on and the Tor Project to decide upon.
+
+\subsection{Introducing Website Oracles}
+In this paper, we introduce the security notion of a \emph{Website Oracle} (WO)
+that can be used by attackers to augment any WF attack. A WO answers ``yes'' or
+``no'' to the question ``was a particular website visited over Tor at this point
+in time?''. We show through simulation that such a \emph{capability}---access to
+a WO---greatly reduces the false positive rate for an attacker attempting to
+fingerprint the majority of websites and website visits through the Tor network.
+The reduction is to such a great extent that our simulations suggest that false
+positives are no longer a significant reason for why WF attacks lack real-world
+impact. This is in particular the case for onion services where the estimated
+number of websites is a fraction compared to the ``regular''
+web~\cite{JansenJGED18}.
+
+Our simulations are based on the privacy-preserving network measurement results
+of the live Tor network in early 2018 by Mani \emph{et~al.}~\cite{torusage}.
+Besides simulating WOs we also identify a significant number of potential
+sources of WOs that are available to a wide range of attackers, such as nation
+state actors, advertisement networks (including their customers), and operators
+of Tor relays. Some particularly practical sources---due to DNS
+and how onion services are accessed---can be used by anyone with modest
+computing resources. 
+
+We argue that sources of WOs are inherent in Tor due to its design goal of
+providing \emph{anonymous} and not \emph{unobservable} communication: observable
+anonymity sets are inherent for anonymity~\cite{KedoganAP02,anonterm,Raymond00},
+and a WO can be viewed as simply being able to query for membership in the
+destination/recipient anonymity set (the potential websites visited by a Tor
+client). The solution to the effectiveness of WF+WO attacks is therefore not to
+eliminate all sources---that would be impossible without unobservable
+communication~\cite{KedoganAP02,anonterm,Raymond00}---but to assume that an
+attacker has WO access when evaluating the effectiveness of WF attacks and
+defenses, even for weak attackers like local (passive) eavesdroppers. 
+
+The introduction of a WO in the setting of WF attacks is similar to how
+encryption schemes are constructed to be secure in the presence of an attacker
+with access to \emph{encryption} and \emph{decryption} oracles (chosen plaintext
+and ciphertext attacks, respectively) \cite{GoldwasserM84,NaorY90,RackoffS91}.
+This is motivated by the real-world prevalence of such oracles, and the high
+impact on security when paired with other weaknesses of the encryption schemes:
+e.g., Bleichenbacher~\cite{Bleichenbacher98} padding oracle attacks remain an
+issue in modern cryptosystems today despite being discovered about twenty years
+ago~\cite{Merget19,RonenGGSWY18}. 
+
+\subsection{Contributions and Structure}
+Further background on anonymity, Tor, and WF are presented in
+Section~\ref{cat:sec:back}. Section~\ref{cat:sec:oracles} defines a WO and describes two
+generic constructions for combining a WO with \emph{any} WF attack. Our generic
+constructions are a type of Classify-Verify method by Stolerman
+\emph{et~al.}~\cite{stolerman2013classify}, first used in the context of WF
+attacks by Juarez \emph{et~al.}~\cite{DBLP:conf/ccs/JuarezAADG14} and later by
+Greschbach \emph{et~al.} \cite{DBLP:conf/ndss/GreschbachPRWF17}.
+Section~\ref{cat:sec:sources} presents a number of sources of WOs that can be used
+by a wide range of attackers. We focus on practical sources based on DNS and
+onion service directories in Tor, offering \emph{probabilistic} WOs that anyone
+can use with modest resources. We describe how we simulate access to a WO
+throughout the rest of the paper in Section~\ref{cat:sec:sim}, based on Tor network
+measurement data from Mani \emph{et~al.}~\cite{torusage}.
+
+Section~\ref{cat:sec:wf} experimentally evaluates the performance of augmenting the
+state-of-the-art WF attack Deep Fingerprinting (DF) by Sirinam
+\emph{et~al.}~\cite{DF} with WO access using one of our generic constructions.
+We show significantly improved classification performance against unprotected
+Tor as well as against traces defended with the WF defenses WTF-PAD by Juarez
+\emph{et~al.}~\cite{wtf-pad} and Walkie-Talkie by Wang and Goldberg~\cite{WT},
+concluding that the defenses are ineffective in this new setting where an
+attacker has access to a WO. Further, we also evaluate DF with WO access against
+Wang \emph{et~al.}'s dataset~\cite{Wang} with simulated traces for the
+constant-rate WF defenses CS-BuFLO and Tamaraw by Cai et
+al.~\cite{csbuflo,Tamaraw}. Our results show that constant-rate defenses are
+overall effective defenses but not efficient due to the significant induced
+overheads. We then evaluate two configurations of the WF defense DynaFlow by Lu
+\emph{et~al.}~\cite{DynaFlow}, observing similar effectiveness as CS-BuFLO but
+at lower overheads approaching that of WTF-PAD and Walkie-Talkie.
+
+In Section~\ref{cat:sec:disc} we discuss our results, focusing on the impact on
+false positives with WO access, how imperfect sources for WOs impact WF+WO
+attacks, limitations of our work, and possible mitigations. Our simulations
+indicate that WF defenses should be evaluated against WF attacks based on how
+they minimise \emph{recall}. We present related work in
+Section~\ref{cat:sec:related}, including how WF+WO attacks relate to traffic
+correlation and confirmation attacks. Section~\ref{cat:sec:conc} briefly concludes
+this paper. 
diff --git a/summary/src/cat/src/lessons.tex b/summary/src/cat/src/lessons.tex
new file mode 100644
index 0000000..70f49f3
--- /dev/null
+++ b/summary/src/cat/src/lessons.tex
@@ -0,0 +1,47 @@
+\section{Lessons from Simulation} \label{cat:app:lessons}
+With the ability to simulate access to WOs we can now simulate the entire
+website anonymity set for Tor. To get a better understanding of why WOs are so
+useful for an attacker performing WF attacks, we look at two results from the
+simulation below. 
+
+\subsection{Time Until Website Visited over Tor}
+\label{cat:sec:sim:timeuntil}
+
+Figure~\ref{cat:fig:timeuntil} shows the time until there is a 50\% probability that
+a website has been visited over Tor depending on website popularity (Alexa, as
+discussed in Section~\ref{cat:sec:sim:dist}). Within ten seconds, we expect that
+most of Alexa top 1k has been visited. Recall that this represents about one
+third of all website visits over Tor. The less popular websites on Alexa top
+one-million represent another third of all visits, quickly approaching hundreds
+of seconds between visits. For the remaining third of all website visits we
+expect them to be even less frequent.
+
+\begin{figure}[!t]
+	\centering
+  \includegraphics[width=.67\columnwidth]{src/cat/img/timeuntilvisited}
+	\caption{The simulated time until there is a 50\% probability that a website for different Alexa ranks has been visited over Tor.}
+	\label{cat:fig:timeuntil}
+\end{figure}
+
+\subsection{Visits Until First False Positive}
+\label{cat:sec:sim:fp}
+Assume that target user(s) have a base rate of $0$, i.e., they never visit the
+attacker's monitored websites. With WO access, we can determine how many
+(naively assumed independent) website visits it \emph{at least} takes until
+there is a 50\% chance that the attacker's classifier gets a false positive.
+This is because if the attacker's website classifier without oracle access
+always returns a false positive, then the false positive rate by the WF+WO
+attack will be determined by when the WO says that the---incorrectly classified
+as monitored---website has been visited. Figure~\ref{cat:fig:probfp} shows the
+expected number of visits \emph{by the victim(s)} for different timeframes based
+on the popularity of the monitored websites. Note that the attacker per
+definition chooses which websites are monitored and can therefore take the
+probability of false positives into account. 
+
+\begin{figure}[t]
+	\centering
+  \includegraphics[width=.67\columnwidth]{src/cat/img/probfp}
+	\caption{The number of website visits until there is a 50\% probability
+	that a website oracle would contribute to a false positive.}
+	\label{cat:fig:probfp}
+\end{figure}
diff --git a/summary/src/cat/src/main.tex b/summary/src/cat/src/main.tex
new file mode 100644
index 0000000..f12287b
--- /dev/null
+++ b/summary/src/cat/src/main.tex
@@ -0,0 +1,121 @@
+\documentclass[USenglish,oneside,twocolumn]{article}
+
+\usepackage[utf8]{inputenc}%(only for the pdftex engine)
+%\RequirePackage[no-math]{fontspec}%(only for the luatex or the xetex engine)
+\usepackage[big]{dgruyter_NEW}
+\usepackage{subcaption}
+\usepackage[dvipsnames]{xcolor}
+\usepackage{mathtools}
+\usepackage{amsthm, amssymb}
+\usepackage[]{cryptocode}
+\usepackage{footmisc}
+\hypersetup{
+  colorlinks,
+  citecolor=RedViolet,
+  linkcolor=RedViolet,
+  urlcolor=MidnightBlue}
+
+\theoremstyle{definition}
+\newtheorem{definition}{Definition}
+
+\DOI{foobar}
+
+\newcommand{\TODO}[1]{\textcolor{red}{TODO:} #1}
+
+\cclogo{\includegraphics{by-nc-nd.pdf}}
+
+\begin{document}
+
+  \author*[1]{Tobias Pulls}
+  \author[2]{Rasmus Dahlberg}
+  \affil[1]{Karlstad University, E-mail: tobias.pulls@kau.se}
+  \affil[2]{Karlstad University, E-mail: rasmus.dahlberg@kau.se}
+
+  \title{\huge Website Fingerprinting with Website Oracles}
+
+  \runningtitle{Website Fingerprinting with Website Oracles}
+
+  \begin{abstract}
+    {\input{src/abstract}}
+  \end{abstract}
+  \keywords{website fingerprinting, website oracles, traffic analysis, security model, design}
+% \classification[PACS]{}
+% \communicated{...}
+% \dedication{...}
+
+\journalname{Proceedings on Privacy Enhancing Technologies}
+\DOI{Editor to enter DOI}
+\startpage{1}
+\received{..}
+\revised{..}
+\accepted{..}
+
+\journalyear{..}
+\journalvolume{..}
+\journalissue{..}
+
+\maketitle
+\eject
+\section{Introduction}
+\label{cat:sec:intro}
+\input{src/intro}
+
+\section{Background}
+\label{cat:sec:back}
+\input{src/background}
+
+\section{Website Oracles}
+\label{cat:sec:oracles}
+\input{src/oracles}
+
+\section{Sources of Website Oracles}
+\label{cat:sec:sources}
+\input{src/sources}
+
+\section{Simulating Website Oracles}
+\label{cat:sec:sim}
+\input{src/sim}
+
+\section{Deep Fingerprinting with Website Oracles}
+\label{cat:sec:wf}
+\input{src/wf}
+
+\section{Discussion}
+\label{cat:sec:disc}
+\input{src/discussion}
+
+\section{Related Work}
+\label{cat:sec:related}
+\input{src/related}
+
+\section{Conclusions}
+\label{cat:sec:conc}
+\input{src/conclusions}
+
+\section*{Acknowledgements}
+We would like to thank Jari Appelgren, Roger Dingledine, Nicholas Hopper, Marc
+Juarez, George Kadianakis, Linus Nordberg, Mike Perry, Erik Wästlund, and the
+PETS reviewers for their valuable feedback. Simulations were performed using the
+\href{http://snic.se/}{Swedish National Infrastructure for Computing} (SNIC) at
+\href{https://www.hpc2n.umu.se/}{High Performance Computing Center North}
+(HPC2N). This research was funded by the
+\href{https://internetstiftelsen.se/en/}{Swedish Internet Foundation} and the
+\href{www.kks.se}{Knowledge Foundation of Sweden}. 
+
+\bibliographystyle{abbrv}
+\bibliography{ref-min}
+
+\appendix
+\section{Bayes' Law for Estimating Utility of Website Oracles}
+\label{cat:app:bayes}
+\input{src/bayes}
+
+\section{Lessons from Simulation}
+\label{cat:app:lessons}
+\input{src/lessons}
+
+\section{Sources of Website Oracles}
+\label{cat:app:sources}
+\input{src/othersources}
+
+\end{document}
diff --git a/summary/src/cat/src/oracles.tex b/summary/src/cat/src/oracles.tex
new file mode 100644
index 0000000..01f1d99
--- /dev/null
+++ b/summary/src/cat/src/oracles.tex
@@ -0,0 +1,126 @@
+\section{Website Oracles} \label{cat:sec:oracles}
+We first define a WO and then present two generic constructions for use with WF
+attacks based on the kind of output the WF attack supports. 
+
+\subsection{Defining Website Oracles}
+\begin{definition}
+	\label{cat:def:oracle}
+	A website oracle answers true or false to the question ``was a particular
+	monitored website $w$ visited over the Tor network at time $t$?''. 
+\end{definition}
+
+A WO considers only web\emph{sites} and not web\emph{pages} for $w$, but note
+that even for webpage fingerprinting being able to narrow down the possible
+websites that webpages belong to through WO access is a significant advantage to
+an attacker. The time $t$ refers to a \emph{period of time} or \emph{timeframe}
+during which a visit should have taken place. Notably, different sources of WOs
+may provide different \emph{resolutions} for time, forcing an attacker to
+consider a timeframe in which a visit could have taken place. For example,
+timestamps in Apache or nginx access logs use regular Unix timestamps as default
+(i.e., seconds), while CDNs like Cloudflare maintain logs with Unix nanosecond
+precision. Further, there are inherent limitations in approximating $t$ for the
+query when the attacker in addition to WO access can only directly observe
+traffic from the victim into Tor. We explore this later in
+Section~\ref{cat:sec:sim:timeframe}.
+
+One important limitation we place on the use of a WO with WF is that the
+attacker can only query the WO for \emph{monitored} websites. The open world
+setting is intended to capture a more realistic setting for evaluating attacks,
+and inherent in this is that the attacker cannot train (or even enumerate) all
+possible websites on the web. Given the ability to enumerate and query all
+possible websites gives the adversary a capability in line with a global passive
+adversary performing correlation attacks, which is clearly outside of the threat
+model of Tor~\cite{tor}. We further relate correlation and confirmation attacks
+to WF+WO attacks in Section~\ref{cat:sec:related}.
+
+Definition~\ref{cat:def:oracle} defines the ideal WO: it never fails to observe a
+\emph{monitored} website visit, it has no false positives, and it can answer for
+an arbitrary $t$. This is similar to how encryption and decryption oracles
+always encrypt and decrypt when modelling security for encryption
+schemes~\cite{GoldwasserM84,NaorY90,RackoffS91}. In practice, sources of all of
+these oracles may be more or less ideal and challenging for an attacker to use.
+Nevertheless, the prevalence of sources of these imperfect oracles motivate the
+assumption of an attacker with access to an ideal oracle. Similarly, for WOs, we
+motivate this assumption in Sections~\ref{cat:sec:sources}~and~\ref{cat:sec:sim}, in
+particular wrt.\ a timeframe on the order of (milli)seconds.
+Section~\ref{cat:sec:disc} further considers non-ideal sources of WOs and the effect
+on WF+WO attacks, both when the WO can produce false positives and when the
+source only observes a fraction of visits to monitored websites.
+
+\subsection{Generic Website Fingerprinting Attacks with Website Oracles}
+\label{cat:sec:oracles:generic}
+As mentioned in Section~\ref{cat:sec:back:wf}, a WF attack is a classifier that is
+given as input a packet trace and provides as output a classification. The
+classification is either a monitored site or a class representing unmonitored
+(in the open world). Figure~\ref{cat:fig:setting-oracle} shows the setting where an
+attacker capable of performing WF attacks also has access to a WO. We define a
+generic construction for WF+WO attacks that works with \emph{any} WF attack in
+the open world in Definition~\ref{cat:def:oraclewf}: 
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=\columnwidth]{src/cat/img/setting-oracle}
+	\caption{WF+WO attacks, where the WO infers membership of a particular website $w$ in the website anonymity set of all possible websites visited over Tor during a particular timeframe $t$.}
+	\label{cat:fig:setting-oracle}
+\end{figure}
+
+\begin{definition}[Binary verifier]
+	\label{cat:def:oraclewf}
+	Given a website oracle $o$ and WF classification $c$ of a trace collected at
+	time $t$, if $c$ is a monitored class, query the oracle $o(c,t)$. Return $c$
+	if the oracle returns true, otherwise return the unmonitored class. 
+\end{definition}
+
+Note that the WO is only queried when the WF \emph{classification} is for a
+monitored website and that Definition~\ref{cat:def:oraclewf} is a generalisation of
+the ``high precision'' DefecTor attack by Greschbach
+\emph{et~al.}~\cite{DBLP:conf/ndss/GreschbachPRWF17}. In terms of
+\emph{precision} and \emph{false positives}, the above generic WF+WO
+construction is strictly superior to a WF attack without a WO. Assume that the
+WF classification incorrectly classified an unmonitored trace as monitored, then
+there is \emph{only a probability} that a WO also returns true, depending on the
+probability that someone else visited the website in the same timeframe over
+Tor. If it does not, then a false positive is prevented. That is, a WF attack
+without WO access is identical to a WF attack with access to a useless WO that
+always returns true; any improvements beyond that will only help the attacker in
+ruling out false positives. We consider the impact on \emph{recall} later.
+
+We can further refine the use of WOs for the subset of WF attacks that support
+providing as output an ordered list of predictions in decreasing likelihood,
+optionally with probabilities, as shown in Definition~\ref{cat:def:oracleprob}:
+
+\begin{definition}[List verifier]
+	Given an ordered list of predictions in the open world and a website oracle:
+
+	{\centering
+	\pseudocode[syntaxhighlight=auto]{%
+	\t\pcfor \text{top prediction $p$ in list} \pcdo \\
+	\t\pcind \pcif p \text{ is unmonitored or oracle says $p$ visited } \t\pcthen\\
+	\t\pcind[2] return \text{list}\\
+	\t\pcind \text{move $p$ to last in list and optionally update probabilities}}
+	}
+	\label{cat:def:oracleprob}
+\end{definition}
+
+First, we observe that if the WF attack thinks that it is most likely an
+unmonitored website, then we accept that because a WO can only teach us
+something new about monitored websites. Secondly, if the most likely prediction
+has been visited according to the WO then we also accept that classification
+result. Finally, all that is left to do is to consider this while repeatedly
+iterating over the top predictions: if the top classification is a monitored
+website that has not been visited according to the WO, then move it from the top
+of the list and optionally update probabilities (if applicable, then also set
+$p=0.0$ before updating) and try again. Per definition, we will either hit the
+case of a monitored website that has been visited according to the WO or an
+unmonitored prediction. As mentioned in Section~\ref{cat:sec:back:wf}, WF output
+that has some sort of probability or threshold associated with classifications
+are useful for attackers with different requirements wrt. false positives and
+negatives.
+
+One could consider a third approach based on repeatedly querying a WO to first
+determine if any monitored websites have been visited and then train an
+optimised classifier (discarding monitored websites that we know have not been
+visited). While this may give a minor improvement, our results later in this
+paper as well as earlier work show that confusing monitored websites is a minor
+issue compared to confusing an unmonitored website as
+monitored~\cite{DBLP:conf/ndss/GreschbachPRWF17,DBLP:conf/ccs/JuarezAADG14,Wang}. 
diff --git a/summary/src/cat/src/othersources.tex b/summary/src/cat/src/othersources.tex
new file mode 100644
index 0000000..35d3c71
--- /dev/null
+++ b/summary/src/cat/src/othersources.tex
@@ -0,0 +1,112 @@
+\section{Sources of Website Oracles} \label{cat:app:sources}
+There are a wide number of possible sources to instantiate WOs. Here we present
+some details on a selection of sources, far from exhaustive.
+
+\subsection{Surveillance Programmes}
+Intelligence agencies operate surveillance programmes that perform bulk
+collection and retention of communications metadata, including
+web-browsing~\cite{lyon2014surveillance}. For example, the Snowden revelations
+included \emph{Marina}:
+\begin{quote}
+	Of the more distinguishing features, Marina has the ability to look back on
+	the last 365 days' worth of DNI (Digital Network Intelligence) metadata seen
+	by the Sigint collection system, \emph{regardless} whether or not it was
+	tasked for collection~\cite{guardian}.
+\end{quote}
+
+Another example is the prevalence of nation states to monitor Internet traffic
+that crosses geographic borders. For example, China operates the Great Firewall
+of China that is also used for censorship purposes. Due to the nature of Tor and
+how exits are selected, visits to websites that are not operated by world-wide
+reaching hosting providers are highly likely to cross multiple nation borders as
+traffic goes from an exit to the website. It is also worth to highlight that any
+sensitive website hosted from within a country where a state actor is interested
+in identifying visitors are likely to capture traffic to that website due to the
+Tor traffic crossing its borders more often than not. 
+
+\subsection{Content Delivery Networks}
+Content Delivery Networks (CDNs), such as Akamai, Google, and Amazon host
+different types of content for a significant fraction of all websites on the
+Internet~\cite{ScheitleHGJZSV18}. Inherently, all requests for these resources
+are easily identified as coming from Tor exits, and depending on content, things
+like unique identifiers and HTTP referrer headers enable the CDN provider to
+infer the website the content is hosted on. 
+
+\subsection{Internet Giants}
+Internet giants like Google, Apple, Facebook, Amazon, Microsoft, and Cloudflare
+make up a large fraction the web as we know it. For example the use of Google
+Analytics is wide-spread, so is hosting in clouds provided by several of these
+giants, and Cloudflare with its ``cloud network platform'' hosts over 13 million
+domains~\cite{cf-size}.
+While some of them may do what is in their power to protect the valuable data
+they process and retain, they are still subject to many legal frameworks across
+the world that might not offer the best of protections for, say, access logs
+pertaining to ``anonymous'' users of Tor when requested by authorities of nation
+states. As another example, Cloudflare offers a nice API for their customers to
+get their access logs with Unix nanosecond precision. The logs are retained for
+up to seven
+days~\cite{cf-retention},
+giving ample time for legal requests. 
+
+\subsection{Access Logs of Web Servers}
+The vast majority of web servers retain access logs by default. Typically, they
+provide unix timestamps with seconds as the resolution (the case for Apache and
+nginx). Further, the access logs may be shipped to centralised security
+information and event management (SIEM) systems for analysis, with varying
+retention times and rigour in storage. For example, it is common to
+``anonymize'' logs by removing parts of the IP-addresses and then retaining them
+indefinitely, as is the case for Google who removes part of IP addresses in logs
+after nine
+months~\cite{google-retention}.
+
+
+\subsection{Middleboxes}
+Network middleboxes that observe, analyse, and potentially retain network
+traffic abound. Especially in more oppressive countries, middleboxes are often
+used for censorship or dragnet surveillance, e.g., as seen with Blue Coat in
+Syria~\cite{bluecoat}. 
+
+\subsection{OCSP Responders}
+Chung \emph{et~al.}~\cite{ocsp-chung} found in a recent study that 95.4\% of all
+certificates support the Online Certificate Status Protocol (OCSP), which allows
+a client to query the responsible CA in real-time for a certificate's revocation
+status via HTTP. As such, the browsed website will be exposed to the CA in
+question. From a privacy-standpoint this could be solved if the server
+\emph{stapled} a recently fetched OCSP response with the served certificate.
+Unfortunately, only 35\% of Alexa's top-one-million uses OCSP
+stapling~\cite{ocsp-chung}.
+
+Unless an OCSP response is stapled while visiting a website in a default
+configuration of the Tor browser, the status of a certificate is checked in
+real-time using OCSP. As such, any CA that issued a certificate for a website
+without OCSP stapling could instantiate a WO with an RTT-based resolution.
+Similarly, any actor that observes most OCSP traffic (which is in plaintext due
+to HTTP) gets the same capability. To better understand who could instantiate a
+WO based on OCSP we performed preliminary traceroute measurements\footnote{%
+	Every RIPE Atlas probe used its configured DNS resolver(s). In total we
+	requested 2048 WW-probes for one-off measurements.
+} on the RIPE Atlas network towards four OCSP
+responders that are hosted by particularly large CAs: Let's Encrypt, Sectigo,
+DigiCert, and GoDaddy. Let's Encrypt and Sectigo are fronted by a variety of
+actors (mainly due to CDN caching), while DigiCert is fronted by a single CDN.
+Requests towards GoDaddy's OCSP responder always end-up in an AS hosted by
+GoDaddy.
+
+\subsection{Tor Exit Relays}
+Anyone can run a Tor exit relay and have it be used by all Tor users. Obviously,
+the operator of the exit relay can observe when its relay is used and the
+destination websites. At the time of writing, the consumed exit bandwidth of the
+entire Tor network is around 50~Gbit/s. This makes the necessary investment for
+an attacker that wishes to get a decent chunk of exit bandwidth more a question
+of stealthily deploying new exit relays than prohibitively large monetary costs.
+
+\subsection{Information Leaks}
+More sophisticated attackers can look for information leaks at the application,
+network, and operating system levels that allow them to infer that websites have
+been visited. Application level information leaks are particularly of concern
+for onion services: any observable state that can be tied to a new visitor is a
+WO for an onion visit (this is not the case for ``regular'' websites). Such
+state can include online status or the number of online users of a service, any
+observable activity with timestamps, a predictable caching structure, and so on.
+Similar information leaks can also occur on the network and operating system
+level~\cite{DBLP:journals/ton/CaoQWDKM18,DBLP:conf/uss/EnsafiPKC10,DBLP:conf/ccs/QianMX12}.
diff --git a/summary/src/cat/src/ref-min.bib b/summary/src/cat/src/ref-min.bib
new file mode 100644
index 0000000..fe12c0e
--- /dev/null
+++ b/summary/src/cat/src/ref-min.bib
@@ -0,0 +1,837 @@
+@misc{google-retention,
+	author = {Google LLC.},
+	title = {How {Google} retains data we collect},
+	howpublished = {\url{https://web.archive.org/web/20190227170903/https://policies.google.com/technologies/retention}},
+}
+
+@misc{cf-retention,
+	author = {Cloudflare Inc.},
+	title = {{FAQs}},
+	howpublished = {\url{https://web.archive.org/web/20190227165850/https://developers.cloudflare.com/logs/faq/}},
+}
+
+@misc{cf-size,
+	author = {Cloudflare Inc.},
+	title = {Helping Build a Better Internet},
+	howpublished = {\url{https://web.archive.org/web/20190227165133/https://www.cloudflare.com/}},
+}
+
+@misc{guardian,
+	author = {The Guardian},
+	title = {{NSA} stores metadata of millions of web users for up to a year, secret files show},
+	howpublished = {\url{https://www.theguardian.com/world/2013/sep/30/nsa-americans-metadata-year-documents}, accessed 2019-02-27},
+}
+
+@misc{wiki,
+	author = {Wikipedia contributors},
+	title = {Softmax function---{Wikipedia}{,} the free encyclopedia.},
+	howpublished = {\url{https://en.wikipedia.org/w/index.php?title=Softmax_function&oldid=883834589}, accessed 2019-02-17},
+}
+
+@misc{alexa,
+	author = {Amazon},
+	title = {The top 500 sites on the web},
+	howpublished = {\url{https://www.alexa.com/topsites}, accessed 2019-02-13}}
+}
+
+@misc{tor-safety-board,
+	author = {Tor Project},
+	title = {Tor Research Safety Board},
+	howpublished = {\url{https://research.torproject.org/safetyboard.html}, accessed 2019-02-13},
+}
+
+@misc{google-bid-anon,
+	author = {Google LLC.},
+	title = {Set your desktop and mobile web inventory to Anonymous, Branded, or Semi-transparent in {AdX}},
+	howpublished = {\url{https://web.archive.org/web/20190228123602/https://support.google.com/admanager/answer/2913411?hl=en&ref_topic=2912022}},
+}
+
+@misc{google-bid,
+	author = {Google LLC.},
+	title = {Real-Time Bidding Protocol Buffer v.161 },
+	howpublished = {\url{https://web.archive.org/web/20190228122615/https://developers.google.com/authorized-buyers/rtb/downloads/realtime-bidding-proto}},
+}
+
+@misc{google-dn,
+	author = {Google LLC.},
+	title = {About targeting for Display Network campaigns},
+	howpublished = {\url{https://web.archive.org/web/20190228122431/https://support.google.com/google-ads/answer/2404191?hl=en&ref\_topic=3121944\%5C}},
+}
+
+@misc{google-purge,
+	author = {Google LLC.},
+	title = {Flush Cache},
+	howpublished = {\url{https://web.archive.org/web/20190228150306/https://developers.google.com/speed/public-dns/cache}},
+}
+
+@misc{cf-purge,
+	author = {Cloudflare Inc.},
+	title = {Purge Cache},
+	howpublished = {\url{https://web.archive.org/web/20190228150344/https://1.1.1.1/purge-cache/}},
+}
+
+@misc{bug-report,
+  author = {Tobias Pulls and Rasmus Dahlberg},
+  title = {{OOM} manger wipes entire {DNS} cache},
+  howpublished = {\url{https://trac.torproject.org/projects/tor/ticket/29617}},
+  year = {2020},
+}
+
+@misc{tor-0401,
+  author = {Nick Mathewson},
+  title = {New Release: {Tor} 0.4.0.1-alpha },
+  howpublished = {\url{https://blog.torproject.org/new-release-tor-0401-alpha}, accessed 2019-02-08},
+}
+
+@misc{netcraft-survey,
+  author = {Netcraft},
+  title = {January 2019 Web Server Survey},
+  howpublished = {\url{https://web.archive.org/web/20190208081915/https://news.netcraft.com/archives/category/web-server-survey/}}
+}
+
+@inproceedings{DBLP:conf/ccs/JuarezAADG14,
+  author    = {Marc Ju{\'{a}}rez and
+               Sadia Afroz and
+               Gunes Acar and
+               Claudia D{\'{\i}}az and
+               Rachel Greenstadt},
+  title     = {A Critical Evaluation of Website Fingerprinting Attacks},
+  booktitle = {{CCS}},
+  year      = {2014}
+}
+
+@article{chow1970optimum,
+  title={On optimum recognition error and reject tradeoff},
+  author={Chow, C},
+  journal={IEEE Trans. Inf. Theory},
+  volume={16},
+  number={1},
+  year={1970},
+}
+
+@inproceedings{stolerman2013classify,
+  title={Classify, but verify: Breaking the closed-world assumption in stylometric authorship attribution},
+  author={Stolerman, Ariel and Overdorf, Rebekah and Afroz, Sadia and Greenstadt, Rachel},
+  booktitle={IFIP Working Group},
+  volume={11},
+  year={2013}
+}
+
+@inproceedings{DBLP:conf/ndss/GreschbachPRWF17,
+  author    = {Benjamin Greschbach and
+               Tobias Pulls and
+               Laura M. Roberts and
+               Phillip Winter and
+               Nick Feamster},
+  title     = {The Effect of {DNS} on {Tor}'s Anonymity},
+  booktitle = {{NDSS}},
+  year      = {2017},
+}
+
+@article{DBLP:journals/popets/WangG16,
+  author    = {Tao Wang and
+               Ian Goldberg},
+  title     = {On Realistically Attacking {Tor} with Website Fingerprinting},
+  journal   = {PETS},
+  volume    = {2016},
+  number    = {4},
+}
+
+@inproceedings{DBLP:conf/uss/KwonALDD15,
+  author    = {Albert Kwon and
+               Mashael AlSabah and
+               David Lazar and
+               Marc Dacier and
+               Srinivas Devadas},
+  title     = {Circuit Fingerprinting Attacks: Passive Deanonymization of {Tor} Hidden
+               Services},
+  booktitle = {{USENIX} Security},
+  year      = {2015},
+}
+
+@inproceedings{DBLP:conf/wpes/PanchenkoMHLWE17,
+  author    = {Andriy Panchenko and
+               Asya Mitseva and
+               Martin Henze and
+               Fabian Lanze and
+               Klaus Wehrle and
+               Thomas Engel},
+  title     = {Analysis of Fingerprinting Techniques for {Tor} Hidden Services},
+  booktitle = {{WPES}},
+  year      = {2017},
+}
+
+@inproceedings{jansenccs18,
+  author    = {Rob Jansen and Matthew Traudt and Nick Hopper},
+  title     = {Privacy-Preserving Dynamic Learning of {Tor} Network Traffic},
+  booktitle = {{CCS}},
+  year      = {2018}
+}
+
+@inproceedings{DBLP:conf/ccs/JansenJ16,
+  author    = {Rob Jansen and
+               Aaron Johnson},
+  title     = {Safely Measuring {Tor}},
+  booktitle = {{CCS}},
+  year      = {2016},
+}
+
+@inproceedings{DBLP:conf/wpes/VinesRK17,
+  author    = {Paul Vines and
+               Franziska Roesner and
+               Tadayoshi Kohno},
+  title     = {Exploring {ADINT:} Using Ad Targeting for Surveillance on a Budget
+               - or - How Alice Can Buy Ads to Track Bob},
+  booktitle = {{WPES}},
+  year      = {2017},
+}
+
+@article{riggingranking,
+  author    = {Victor Le Pochat and
+               Tom van Goethem and
+               Wouter Joosen},
+  title     = {Rigging Research Results by Manipulating Top Websites Rankings},
+  journal   = {CoRR},
+  volume    = {abs/1806.01156},
+  year      = {2018},
+}
+
+@inproceedings{torusage,
+  author    = {Akshaya Mani and
+               T. Wilson{-}Brown and
+               Rob Jansen and
+               Aaron Johnson and
+               Micah Sherr},
+  title     = {Understanding {Tor} Usage with Privacy-Preserving Measurement},
+  booktitle = {{IMC}},
+  year      = {2018}
+}
+
+@article{lyon2014surveillance,
+  title={Surveillance, {Snowden}, and big data: Capacities, consequences, critique},
+  author={Lyon, David},
+  journal={Big Data \& Society},
+  volume={1},
+  number={2},
+  year={2014},
+  publisher={SAGE Publications Sage UK: London, England}
+}
+
+@inproceedings{Wang,
+  author    = {Tao Wang and
+               Xiang Cai and
+               Rishab Nithyanand and
+               Rob Johnson and
+               Ian Goldberg},
+  title     = {Effective Attacks and Provable Defenses for Website Fingerprinting},
+  booktitle = {{USENIX} Security},
+  year      = {2014},
+}
+
+@article{Cherubin17,
+  author    = {Giovanni Cherubin},
+  title     = {Bayes, not Na{\"{\i}}ve: Security Bounds on Website Fingerprinting Defenses},
+  journal   = {PETS},
+  volume    = {2017},
+  number    = {4},
+}
+
+@inproceedings{Tamaraw,
+  author    = {Xiang Cai and
+               Rishab Nithyanand and
+               Tao Wang and
+               Rob Johnson and
+               Ian Goldberg},
+  title     = {A Systematic Approach to Developing and Evaluating Website Fingerprinting
+               Defenses},
+  booktitle = {{CCS}},
+  year      = {2014},
+}
+
+@inproceedings{csbuflo,
+  author    = {Xiang Cai and
+               Rishab Nithyanand and
+               Rob Johnson},
+  title     = {{CS-BuFLO}: {A} Congestion Sensitive Website Fingerprinting Defense},
+  booktitle = {{WPES}},
+  year      = {2014},
+}
+
+@inproceedings{DF,
+  author    = {Payap Sirinam and
+               Mohsen Imani and
+               Marc Ju{\'{a}}rez and
+               Matthew Wright},
+  title     = {Deep Fingerprinting: Undermining Website Fingerprinting Defenses with
+               Deep Learning},
+  booktitle = {{CCS}},
+  year      = {2018}
+}
+
+@inproceedings{wtf-pad,
+  author    = {Marc Ju{\'{a}}rez and
+               Mohsen Imani and
+               Mike Perry and
+               Claudia D{\'{\i}}az and
+               Matthew Wright},
+  title     = {Toward an Efficient Website Fingerprinting Defense},
+  booktitle = {{ESORICS}},
+  year      = {2016}
+}
+
+@inproceedings{WT,
+  author    = {Tao Wang and
+               Ian Goldberg},
+  title     = {Walkie-Talkie: An Efficient Defense Against Passive Website Fingerprinting
+               Attacks},
+  booktitle = {{USENIX} Security},
+  year      = {2017}
+}
+
+@inproceedings{DynaFlow,
+  author    = {David Lu and
+               Sanjit Bhat and
+               Albert Kwon and
+               Srinivas Devadas},
+  title     = {DynaFlow: An Efficient Website Fingerprinting Defense Based on Dynamically-Adjusting
+               Flows},
+  booktitle = {{WPES}},
+  year      = {2018}
+}
+
+@inproceedings{tor,
+  author    = {Roger Dingledine and
+               Nick Mathewson and
+               Paul F. Syverson},
+  title     = {Tor: The Second-Generation Onion Router},
+  booktitle = {{USENIX} Security},
+  year      = {2004}
+}
+
+@inproceedings{trilemma,
+  author    = {Debajyoti Das and
+               Sebastian Meiser and
+               Esfandiar Mohammadi and
+               Aniket Kate},
+  title     = {Anonymity Trilemma: Strong Anonymity, Low Bandwidth Overhead, Low
+               Latency - Choose Two},
+  booktitle = {{IEEE} {S\&P}},
+  year      = {2018},
+}
+
+@inproceedings{SunSWRPQ02,
+  author    = {Qixiang Sun and
+               Daniel R. Simon and
+               Yi{-}Min Wang and
+               Wilf Russell and
+               Venkata N. Padmanabhan and
+               Lili Qiu},
+  title     = {Statistical Identification of Encrypted Web Browsing Traffic},
+  booktitle = {{IEEE S\&P}},
+  year      = {2002}
+}
+
+@article{rtb,
+  author    = {Jun Wang and
+               Weinan Zhang and
+               Shuai Yuan},
+  title     = {Display Advertising with Real-Time Bidding {(RTB)} and Behavioural
+               Targeting},
+  journal   = {Foundations and Trends in Information Retrieval},
+  year      = {2017}
+}
+
+@inproceedings{ocsp-chung,
+  author    = {Taejoong Chung and
+               Jay Lok and
+               Balakrishnan Chandrasekaran and
+               David R. Choffnes and
+               Dave Levin and
+               Bruce M. Maggs and
+               Alan Mislove and
+               John P. Rula and
+               Nick Sullivan and
+               Christo Wilson},
+  title     = {Is the Web Ready for {OCSP} Must-Staple?},
+  booktitle = {{IMC}},
+  year      = {2018}
+}
+
+@inproceedings{bluecoat,
+  author    = {Chaabane Abdelberi and
+               Terence Chen and
+               Mathieu Cunche and
+               Emiliano De Cristofaro and
+               Arik Friedman and
+               Mohamed Ali K{\^{a}}afar},
+  title     = {Censorship in the Wild: Analyzing Internet Filtering in {Syria}},
+  booktitle = {{IMC}},
+  year      = {2014}
+}
+
+@inproceedings{PanchenkoNZE11,
+  author    = {Andriy Panchenko and
+               Lukas Niessen and
+               Andreas Zinnen and
+               Thomas Engel},
+  title     = {Website fingerprinting in onion routing based anonymization networks},
+  booktitle = {{WPES}},
+  year      = {2011}
+}
+
+@inproceedings{Hintz02,
+  author    = {Andrew Hintz},
+  title     = {Fingerprinting Websites Using Traffic Analysis},
+  booktitle = {{PETS}},
+  year      = {2002}
+}
+
+@inproceedings{HerrmannWF09,
+  author    = {Dominik Herrmann and
+               Rolf Wendolsky and
+               Hannes Federrath},
+  title     = {Website fingerprinting: attacking popular privacy enhancing technologies
+               with the multinomial na{\"{\i}}ve-bayes classifier},
+  booktitle = {{CCSW}},
+  year      = {2009},
+}
+
+@inproceedings{kfp,
+  author    = {Jamie Hayes and
+               George Danezis},
+  title     = {k-fingerprinting: {A} Robust Scalable Website Fingerprinting Technique},
+  booktitle = {{USENIX} Security},
+  year      = {2016},
+}
+
+@inproceedings{CaiZJJ12,
+  author    = {Xiang Cai and
+               Xin Cheng Zhang and
+               Brijesh Joshi and
+               Rob Johnson},
+  title     = {Touching from a distance: website fingerprinting attacks and defenses},
+  booktitle = {{CCS}},
+  year      = {2012},
+}
+
+@inproceedings{DBLP:conf/esorics/ShmatikovW06,
+  author    = {Vitaly Shmatikov and
+               Ming{-}Hsiu Wang},
+  title     = {Timing Analysis in Low-Latency Mix Networks: Attacks and Defenses},
+  booktitle = {{ESORICS}},
+  year      = {2006},
+}
+
+@misc{anonterm,
+  title={A terminology for talking about privacy by data minimization: Anonymity, unlinkability, undetectability, unobservability, pseudonymity, and identity management},
+  author={Pfitzmann, Andreas and Hansen, Marit},
+  publisher={Dresden, Germany},
+  year={2010},
+}
+
+@inproceedings{JansenJGED18,
+  author    = {Rob Jansen and
+               Marc Ju{\'{a}}rez and
+               Rafa Galvez and
+               Tariq Elahi and
+               Claudia D{\'{\i}}az},
+  title     = {Inside Job: Applying Traffic Analysis to Measure {Tor} from Within},
+  booktitle = {{NDSS}},
+  year      = {2018}
+}
+
+@article{GoldwasserM84,
+  author    = {Shafi Goldwasser and
+               Silvio Micali},
+  title     = {Probabilistic Encryption},
+  journal   = {JCSS},
+  volume    = {28},
+  number    = {2},
+  year      = {1984},
+}
+
+@inproceedings{NaorY90,
+  author    = {Moni Naor and
+               Moti Yung},
+  title     = {Public-key Cryptosystems Provably Secure against Chosen Ciphertext
+               Attacks},
+  booktitle = {Proc. Annu. ACM Symp. Theory Comput.},
+  year      = {1990}
+}
+
+@inproceedings{RackoffS91,
+  author    = {Charles Rackoff and
+               Daniel R. Simon},
+  title     = {Non-Interactive Zero-Knowledge Proof of Knowledge and Chosen Ciphertext
+               Attack},
+  booktitle = {{CRYPTO}},
+  year      = {1991}
+}
+
+@inproceedings{Bleichenbacher98,
+  author    = {Daniel Bleichenbacher},
+  title     = {Chosen Ciphertext Attacks Against Protocols Based on the {RSA} Encryption
+               Standard {PKCS} {\#}1},
+  booktitle = {{CRYPTO}},
+  year      = {1998}
+}
+
+@article{RonenGGSWY18,
+  author    = {Eyal Ronen and
+               Robert Gillham and
+               Daniel Genkin and
+               Adi Shamir and
+               David Wong and
+               Yuval Yarom},
+  title     = {The 9 Lives of {Bleichenbacher's} {CAT:} New Cache ATtacks on {TLS}
+               Implementations},
+  journal   = {{IACR} Cryptology ePrint Archive},
+  year      = {2018},
+}
+
+@inproceedings{DBLP:conf/sp/DyerCRS12,
+  author    = {Kevin P. Dyer and
+               Scott E. Coull and
+               Thomas Ristenpart and
+               Thomas Shrimpton},
+  title     = {Peek-a-Boo, {I} Still See You: Why Efficient Traffic Analysis Countermeasures
+               Fail},
+  booktitle = {{IEEE} {S\&P}},
+  year      = {2012}
+}
+
+@inproceedings{DBLP:conf/wpes/NithyanandCJ14,
+  author    = {Rishab Nithyanand and
+               Xiang Cai and
+               Rob Johnson},
+  title     = {Glove: {A} Bespoke Website Fingerprinting Defense},
+  booktitle = {{WPES}},
+  year      = {2014}
+}
+
+@inproceedings{mathews2018understanding,
+  title={UNDERSTANDING FEATURE DISCOVERY IN WEBSITE FINGERPRINTING ATTACKS},
+  author={Mathews, Nate and Sirinam, Payap and Wright, Matthew},
+  booktitle={{WNYISPW}},
+  year={2018},
+}
+
+@article{abe2016fingerprinting,
+  title={Fingerprinting attack on {Tor} anonymity using deep learning},
+  author={Abe, Kota and Goto, Shigeki},
+  journal={Proceedings of the Asia-Pacific Advanced Network},
+  volume={42},
+  year={2016}
+}
+
+@inproceedings{DBLP:conf/ndss/RimmerPJGJ18,
+  author    = {Vera Rimmer and
+               Davy Preuveneers and
+               Marc Ju{\'{a}}rez and
+               Tom van Goethem and
+               Wouter Joosen},
+  title     = {Automated Website Fingerprinting through Deep Learning},
+  booktitle = {{NDSS}},
+  year      = {2018}
+}
+
+@inproceedings{cumul,
+  author    = {Andriy Panchenko and
+               Fabian Lanze and
+               Jan Pennekamp and
+               Thomas Engel and
+               Andreas Zinnen and
+               Martin Henze and
+               Klaus Wehrle},
+  title     = {Website Fingerprinting at Internet Scale},
+  booktitle = {{NDSS}},
+  year      = {2016}
+}
+
+@article{cheng1998traffic,
+  title={Traffic analysis of {SSL} encrypted web browsing},
+  author={Cheng, Heyning and Avnur, Ron},
+  journal={Project paper, University of Berkeley},
+  year={1998}
+}
+
+@inproceedings{DBLP:conf/sp/SunSWRPQ02,
+  author    = {Qixiang Sun and
+               Daniel R. Simon and
+               Yi{-}Min Wang and
+               Wilf Russell and
+               Venkata N. Padmanabhan and
+               Lili Qiu},
+  title     = {Statistical Identification of Encrypted Web Browsing Traffic},
+  booktitle = {{IEEE S\&P}},
+  year      = {2002}
+}
+
+@inproceedings{DBLP:conf/ccs/LiberatoreL06,
+  author    = {Marc Liberatore and
+               Brian Neil Levine},
+  title     = {Inferring the source of encrypted {HTTP} connections},
+  booktitle = {{CCS}},
+  year      = {2006}
+}
+
+@inproceedings{KedoganAP02,
+  author    = {Dogan Kesdogan and
+               Dakshi Agrawal and
+               Stefan Penz},
+  title     = {Limits of Anonymity in Open Environments},
+  booktitle = {{IH}},
+  year      = {2002}
+}
+
+@inproceedings{DBLP:conf/pet/Danezis04,
+  author    = {George Danezis},
+  title     = {The Traffic Analysis of Continuous-Time Mixes},
+  booktitle = {{PETS}},
+  year      = {2004}
+}
+
+@inproceedings{DBLP:conf/ih/DanezisS04,
+  author    = {George Danezis and
+               Andrei Serjantov},
+  title     = {Statistical Disclosure or Intersection Attacks on Anonymity Systems},
+  booktitle = {{IH}},
+  year      = {2004}
+}
+
+@inproceedings{DBLP:conf/diau/BertholdPS00,
+  author    = {Oliver Berthold and
+               Andreas Pfitzmann and
+               Ronny Standtke},
+  title     = {The Disadvantages of Free {MIX} Routes and how to Overcome Them},
+  booktitle = {International Workshop on Design Issues in Anonymity and Unobservability},
+  year      = {2000},
+}
+
+@inproceedings{KesdoganP04,
+  author    = {Dogan Kesdogan and
+               Lexi Pimenidis},
+  title     = {The Hitting Set Attack on Anonymity Protocols},
+  booktitle = {{IH}},
+  year      = {2004}
+}
+
+@inproceedings{TroncosoGPV08,
+  author    = {Carmela Troncoso and
+               Benedikt Gierlichs and
+               Bart Preneel and
+               Ingrid Verbauwhede},
+  title     = {Perfect Matching Disclosure Attacks},
+  booktitle = {{PETS}},
+  year      = {2008}
+}
+
+@inproceedings{DiazSCP02,
+  author    = {Claudia D{\'{\i}}az and
+               Stefaan Seys and
+               Joris Claessens and
+               Bart Preneel},
+  title     = {Towards Measuring Anonymity},
+  booktitle = {{PETS}},
+  year      = {2002}
+}
+
+@inproceedings{SerjantovD02,
+  author    = {Andrei Serjantov and
+               George Danezis},
+  title     = {Towards an Information Theoretic Metric for Anonymity},
+  booktitle = {{PETS}},
+  year      = {2002}
+}
+
+@inproceedings{Raymond00,
+  author    = {Jean{-}Fran{\c{c}}ois Raymond},
+  title     = {Traffic Analysis: Protocols, Attacks, Design Issues, and Open Problems},
+  booktitle = {International Workshop on Design Issues in Anonymity and Unobservability},
+  year      = {2000}
+}
+
+@inproceedings{Danezis03,
+  author    = {George Danezis},
+  title     = {Statistical Disclosure Attacks},
+  booktitle = {{IFIP SEC}},
+  year      = {2003}
+}
+
+@inproceedings{MurdochD05,
+  author    = {Steven J. Murdoch and
+               George Danezis},
+  title     = {Low-Cost Traffic Analysis of {Tor}},
+  booktitle = {{IEEE} {S\&P}},
+  year      = {2005}
+}
+
+@inproceedings{ChakravartySK10,
+  author    = {Sambuddho Chakravarty and
+               Angelos Stavrou and
+               Angelos D. Keromytis},
+  title     = {Traffic Analysis against Low-Latency Anonymity Networks Using Available
+               Bandwidth Estimation},
+  booktitle = {{ESORICS}},
+  year      = {2010}
+}
+
+@inproceedings{MittalKJCB11,
+  author    = {Prateek Mittal and
+               Ahmed Khurshid and
+               Joshua Juen and
+               Matthew Caesar and
+               Nikita Borisov},
+  title     = {Stealthy traffic analysis of low-latency anonymous communication using
+               throughput fingerprinting},
+  booktitle = {{CCS}},
+  year      = {2011}
+}
+
+@inproceedings{deepcorr,
+  author    = {Milad Nasr and
+               Alireza Bahramali and
+               Amir Houmansadr},
+  title     = {DeepCorr: Strong Flow Correlation Attacks on {Tor} Using Deep Learning},
+  booktitle = {{CCS}},
+  year      = {2018}
+}
+
+@inproceedings{JohnsonWJSS13,
+  author    = {Aaron Johnson and
+               Chris Wacek and
+               Rob Jansen and
+               Micah Sherr and
+               Paul F. Syverson},
+  title     = {Users get routed: traffic correlation on {Tor} by realistic adversaries},
+  booktitle = {{CCS}},
+  year      = {2013}
+}
+
+@inproceedings{BorisovDMT07,
+  author    = {Nikita Borisov and
+               George Danezis and
+               Prateek Mittal and
+               Parisa Tabriz},
+  title     = {Denial of service or denial of security?},
+  booktitle = {{CCS}},
+  year      = {2007}
+}
+
+@inproceedings{SunEVLRCM15,
+  author    = {Yixin Sun and
+               Anne Edmundson and
+               Laurent Vanbever and
+               Oscar Li and
+               Jennifer Rexford and
+               Mung Chiang and
+               Prateek Mittal},
+  title     = {{RAPTOR:} Routing Attacks on Privacy in {Tor}},
+  booktitle = {{USENIX} Security},
+  year      = {2015}
+}
+
+@inproceedings{ScheitleHGJZSV18,
+  author    = {Quirin Scheitle and
+               Oliver Hohlfeld and
+               Julien Gamba and
+               Jonas Jelten and
+               Torsten Zimmermann and
+               Stephen D. Strowes and
+               Narseo Vallina{-}Rodriguez},
+  title     = {A Long Way to the Top: Significance, Structure, and Stability of Internet
+               Top Lists},
+  booktitle = {{IMC}},
+  year      = {2018}
+}
+
+@article{DBLP:journals/ton/CaoQWDKM18,
+  author    = {Yue Cao and
+               Zhiyun Qian and
+               Zhongjie Wang and
+               Tuan Dao and
+               Srikanth V. Krishnamurthy and
+               Lisa M. Marvel},
+  title     = {Off-Path {TCP} Exploits of the Challenge {ACK} Global Rate Limit},
+  journal   = {{IEEE/ACM} Trans. Netw.},
+  volume    = {26},
+  number    = {2},
+  year      = {2018}
+}
+
+@inproceedings{DBLP:conf/ccs/QianMX12,
+  author    = {Zhiyun Qian and
+               Zhuoqing Morley Mao and
+               Yinglian Xie},
+  title     = {Collaborative {TCP} sequence number inference attack: how to crack
+               sequence number under a second},
+  booktitle = {{CCS}},
+  year      = {2012}
+}
+
+@inproceedings{DBLP:conf/uss/EnsafiPKC10,
+  author    = {Roya Ensafi and
+               Jong Chun Park and
+               Deepak Kapur and
+               Jedidiah R. Crandall},
+  title     = {Idle Port Scanning and Non-interference Analysis of Network Protocol
+               Stacks Using Model Checking},
+  booktitle = {{USENIX} Security},
+  year      = {2010}
+}
+
+@misc{onionv2,
+  author = {{Tor Project}},
+  title = {{Tor} Rendezvous Specification - Version 2},
+  howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/rend-spec-v2.txt}, accessed 2019-02-13},
+}
+
+@misc{onionv3,
+  author = {{Tor Project}},
+  title = {{Tor} Rendezvous Specification - Version 3},
+  howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt}, accessed 2019-02-13},
+}
+
+@inproceedings{Merget19,
+  author    = {Robert Merget and Juraj Somorovsky and Nimrod Aviram and Craig Young and Janis Fliegenschmidt and Jörg Schwenk and Yuval Shavitt},
+  title     = {Scalable Scanning and Automatic Classification of {TLS} Padding Oracle Vulnerabilities},
+  booktitle = {{USENIX} Security},
+  year      = {2019},
+  note      = {to appear}
+}
+
+@inproceedings{DBLP:conf/pet/WinterKMHSLW14,
+  author    = {Philipp Winter and
+               Richard K{\"{o}}wer and
+               Martin Mulazzani and
+               Markus Huber and
+               Sebastian Schrittwieser and
+               Stefan Lindskog and
+               Edgar R. Weippl},
+  title     = {Spoiled Onions: Exposing Malicious {Tor} Exit Relays},
+  booktitle = {{PETS}},
+  year      = {2014}
+}
+
+@phdthesis{Wang2015a,
+  author = {Tao Wang},
+  title = {Website Fingerprinting: Attacks and Defenses},
+  school = {University of Waterloo},
+  year = {2015},
+  howpublished = {\url{https://nymity.ch/tor-dns/pdf/Wang2015a.pdf}},
+}
+
+@misc{perryCrit,
+  author = {Mike Perry},
+  title = {A Critique of Website Traffic Fingerprinting Attacks},
+  howpublished = {\url{https://blog.torproject.org/critique-website-traffic-fingerprinting-attacks}, accessed 2019-02-08},
+}
+
+@article{DBLP:journals/jsac/ReedSG98,
+  author    = {Michael G. Reed and Paul F. Syverson and David M. Goldschlag},
+  title     = {Anonymous connections and onion routing},
+  journal   = {{JSAC}},
+  volume    = {16},
+  number    = {4},
+  year      = {1998},
+}
diff --git a/summary/src/cat/src/related.tex b/summary/src/cat/src/related.tex
new file mode 100644
index 0000000..6c36654
--- /dev/null
+++ b/summary/src/cat/src/related.tex
@@ -0,0 +1,64 @@
+\section{Related Work} \label{cat:sec:related}
+The combination of a WF attack with a WO is a type of Classify-Verify method as
+proposed by Stolerman et al.~\cite{stolerman2013classify}, which in turn is a
+type of rejection function as described by Chow~\cite{chow1970optimum}. Such a
+method was first used in the context of WF by Juarez
+\emph{et~al.}~\cite{DBLP:conf/ccs/JuarezAADG14} and later by Greschbach
+\emph{et~al.} \cite{DBLP:conf/ndss/GreschbachPRWF17} to augment WF attacks with
+inferences from observed DNS traffic. Note that the attack by Greschbach et al.
+can be seen as a probabilistic WO due to the attacker under their threat model
+only observing a fraction of DNS traffic from the Tor network. Our work builds
+upon and generalises their work where DNS traffic is just one of many possible
+sources to infer website visits from. Further, our DNS-based sources are usable
+by anyone instead of relatively strong network attackers (or Google or
+Cloudflare).
+
+All anonymity networks produce anonymity sets (per definition) that change with
+observations by an attacker over time~\cite{Raymond00}. Modelling the behaviour
+of an anonymity system (as a mix), what the attacker observes, and how the
+anonymity sets change over time allows us to reason about how the attacker can
+perform traffic analysis and break the anonymity provided by the
+system~\cite{DiazSCP02,KedoganAP02,SerjantovD02}. Attacks along these lines are
+many with more-or-less consistent terminology, including intersection attacks,
+(statistical) disclosure attacks, and traffic confirmation
+attacks~\cite{DBLP:conf/diau/BertholdPS00,Danezis03,
+DBLP:conf/pet/Danezis04,DBLP:conf/ih/DanezisS04,KesdoganP04,Raymond00,
+DBLP:journals/jsac/ReedSG98,TroncosoGPV08}. 
+
+WOs are nothing more than applying the notion of anonymity sets to the potential
+destination websites visited over an anonymity network like Tor and giving an
+attacker the ability to query this anonymity set for membership for a limited
+number of monitored websites. The way we use WOs in our generic attacks is
+\emph{not to learn long-term statistically unlikely relationships} between
+senders and recipients in a network. Rather, the WO is only used to learn
+\emph{part of the anonymity set at the time of the attack}. That an attacker can
+observe anonymity sets is not novel, what is novel in our work is how we apply
+it to the WF domain and argue for its inclusion as a core attacker capability
+when modelling WF attacks and defenses. 
+
+Murdoch and Danezis showed how to use observed latency in Tor as an oracle to
+perform traffic analysis attacks \cite{MurdochD05}. Chakravarty \emph{et~al.}
+detailed similar attacks but based on bandwidth estimation
+\cite{ChakravartySK10} and Mittal \emph{et~al.} using throughput
+estimation~\cite{MittalKJCB11}. Attackers in these cases do not need to be
+directly in control of significant fractions Tor, but rather use network
+measurements to infer the state of the network and create an oracle that an
+attacker can utilize, similar to WOs. 
+
+Correlation of input and output flows is at the core of many attacks on
+anonymity networks like Tor~\cite{BorisovDMT07,JohnsonWJSS13,SunEVLRCM15}. Flow
+correlation attacks correlate traffic on the network layer, considering packet
+sizes and timing of sent traffic. The RAPTOR attack by Sun et
+al.~\cite{SunEVLRCM15} needs about 100MB of data sent over five minutes to
+correlate flows with high accuracy. The recent state-of-the-art attack DeepCorr
+by Nasr \emph{et~al.} \cite{deepcorr}---based on deep learning like Deep
+Fingerprinting by Sirinam \emph{et~al.}~\cite{DF}---needs only about 900KB of
+data (900 packets) for comparable accuracy to RAPTOR. While flow correlation
+attacks like RAPTOR and DeepCorr operate on the network layer, WF+WO attacks can
+be viewed as \emph{application layer} correlation attacks. WF attacks extract
+the application-layer data (the website) while WOs reconstruct parts of the
+anonymity set of possible monitored websites visited. WF attacks need to observe
+most of the traffic generated when visiting a website that goes into the
+anonymity network. While a WO does not have to directly view any of the output
+flows of the network, it needs to be able to infer if a particular website was
+visited during a period of time, as shown in Section~\ref{cat:sec:sources}.
diff --git a/summary/src/cat/src/sim.tex b/summary/src/cat/src/sim.tex
new file mode 100644
index 0000000..4077b89
--- /dev/null
+++ b/summary/src/cat/src/sim.tex
@@ -0,0 +1,131 @@
+\section{Simulating Website Oracles} \label{cat:sec:sim}
+To be able to \emph{simulate} access to a WO for \emph{arbitrary monitored
+websites} we need to simulate the entire website anonymity set of Tor, because
+the anonymity set is what a WO queries for membership. We opt for simulation for
+ethical reasons. The simulation has three key parts: how those visits are
+distributed, the number of visits to websites over Tor, and the timeframe
+(resolution) of the oracle source. Note that the first two parts are easy for an
+attacker to estimate by simply observing traffic from live Tor exit relays,
+something we cannot trivially do as researchers adhering to Tor's research
+safety
+guidelines~\cite{tor-safety-board}.
+Another option available to an attacker is to repeatedly query a WO to learn
+about the popularity of its monitored websites and based on those figures infer
+the utility of the WO. We opted to not perform such measurements ourselves,
+despite access to several WOs, due to fears of inadvertently harming Tor users.
+Instead we base our simulations on results from the privacy-preserving
+measurements of the Tor network in early 2018 by Mani
+\emph{et~al.}~\cite{torusage}.
+
+\subsection{How Website Visits are Distributed}
+\label{cat:sec:sim:dist}
+Table~\ref{cat:table:visits} shows the average inferred website popularity from Mani
+\emph{et~al.}~\cite{torusage}. The average percentage does not add up to 100\%,
+presumably due to the privacy-preserving measurement technique or rounding
+errors. Their results show that \texttt{torproject.org} is very popular (perhaps
+due to a bug in software using Tor), and beyond that focus on
+Alexa's~\cite{alexa} top one million most
+popular websites as bins. The ``other'' category is for websites identified not
+part of Alexa's top one million websites ranking. For the rest of the analysis
+(not simulation) in this paper we \emph{exclude} \texttt{torproject.org}: for one,
+that Tor users visit that website is unlikely to be an interesting fact for an
+attacker to monitor, and its over-representation (perhaps due to a bug) will
+skew our analysis. Excluding \texttt{torproject.org}, about one third of all
+website visits go to Alexa (0,1k], one third to Alexa (1k,1m], and one third to
+other websites. The third column of Table~\ref{cat:table:visits} contains adjusted
+average percentages.
+
+\begin{table}[!t]
+\caption{Inferred average website popularity for the entire Tor network early 2018, from Mani \emph{et~al.}~\cite[Figure 2]{torusage}.}
+\centering
+\begin{tabular}{lcc}
+Website &  Average & Without\\
+ & primary domain (\%) & torproject.org\\
+\midrule
+torproject.org  & 40.1 & \\
+Alexa (0,10]  & 8.4 & 13.9 \\
+Alexa (10,100]  & 5.1 & 8.4 \\
+Alexa (100,1k]  & 6.2 & 10.3 \\
+Alexa (1k,10k]  & 4.3 & 7.1 \\
+Alexa (10k,100k]  & 7.7 &  12.7\\
+Alexa (100k,1m]  & 7.0 & 11.6 \\
+other  & 21.7 & 35.9 \\
+\end{tabular}
+\label{cat:table:visits}
+\end{table}
+
+In our simulations for website visits we treat the entries in column two of
+Table~\ref{cat:table:visits} as bins of a histogram with the relative size indicated
+by the average website popularity. After randomly selecting a bin (weighted by
+popularity), in the case of an Alexa range we uniformly select a website within
+the range, and for the other category we uniformly select from one million other
+websites. This is a conservative choice given that there are hundreds of
+millions of active websites on the Internet. Uniformly selecting within a bin
+will make the more popular websites in the bin likely underrepresented while
+less popular websites in the bin get overrepresented. However, we typically
+simulate an attacker that monitors $\approx$100 websites and use the website
+popularity as the starting rank of the first monitored website. For the most
+popular websites, monitoring 100 websites covers the entire or significant
+portions of the bins (Alexa $\leq$1k), and for less popular websites (Alexa
+$>$1k), as our results later show, this does not matter. 
+
+\subsection{The Number of Website Visits}
+Mani \emph{et~al.} also inferred with a 95\% confidence interval that
+$(104\pm36)*10^6$ \emph{initial} streams are created during a 24 hour period in
+the entire Tor network \cite{torusage}. Based on this, in our simulation we
+assume 140 million website visits per day that are distributed as described
+above and occur uniformly throughout the day. While assuming uniformity is
+naive, we selected the upper limit of the confidence interval to somewhat negate
+any unreasonable advantage to the attacker. 
+
+\subsection{A Reasonable Timeframe}
+\label{cat:sec:sim:timeframe}
+Wang and Goldberg show that it is realistic to assume that an attacker can
+determine the start of a webpage load even in the presence of background noise
+and multiple concurrent website visits~\cite{DBLP:journals/popets/WangG16}. An
+attacker can further determine if a circuit is used for onion services or
+not~\cite{DBLP:conf/uss/KwonALDD15,DBLP:conf/wpes/PanchenkoMHLWE17}. Now,
+consider an attacker that observes traffic between a Tor client and its guard.
+The initial stream contains the first HTTP GET request for a typical website
+visit. The request will be the first outgoing packet as part of a website visit
+once a connection has been established. When the request arrives at the
+destination is the point in time when an oracle, e.g., instantiated by access
+logs would record this time as the time of visit. Clearly, the exact time is
+between the request and the response packets and the attacker observes the
+timing of those packets. So what is a realistic timeframe for the attacker to
+use when it queries a WO?
+
+Between January 22--30 (2019) we performed Round-Trip Time (RTT) measurements
+using four Amazon EC2 instances that ran \emph{their own} nginx HTTP(S) servers
+to visit \emph{themselves} over Tor (with \texttt{torify curl}) using a fresh
+circuit for each visit. This allowed us easy access to start and stop times for
+the RTT measurement, as well as the time a request appeared in the nginx access
+log (without any clock-drift). In total we collected 21,497 HTTP traces and
+21,492 HTTPS traces, where each trace contains start, log, and stop timestamps.
+Our results are shown in Figure~\ref{cat:fig:aws}. It is clear that that log-to-stop
+times are independent of HTTP(S). More than half of all log-to-stop times
+($54.5$\%) are within a 100~ms window (see 40--140~ms), and nearly all
+log-to-stop times are less than 1000~ms.
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=0.7\textwidth]{src/cat/img/aws}
+	\caption{%
+		Time differences between start, log, and stop events when visiting a website over HTTP(S) using Tor.
+	}
+	\label{cat:fig:aws}
+\end{figure}
+
+Based on our experiment results we consider three timeframes relevant: 10 ms,
+100 ms, and 1000 ms. First, 10 ms is relevant as close to optimal for any
+attacker. On average, there are only 17 website visits during a 10 ms window in
+the entire Tor network. 100 ms is our default for the WF experiments we perform:
+we consider it realistic for many sources of WOs (e.g., Cloudflare logs and
+real-time bidding). We also consider a 1000 ms timeframe relevant due to the
+prevalence of sources of WOs with a resolution in seconds (e.g., due to Unix
+timestamps or TTLs for DNS). Based on our simulations and the different
+timeframes, Appendix~\ref{cat:app:bayes} contains an analysis of the utility of WOs
+using Bayes' law. Appendix~\ref{cat:app:lessons} presents some key lessons from the
+simulation, in particular that while the resolution and resulting timeframe is
+an important metric in our simulation, it is minor in comparison to the overall
+website popularity in Tor of the monitored websites.
diff --git a/summary/src/cat/src/sources.tex b/summary/src/cat/src/sources.tex
new file mode 100644
index 0000000..89616ad
--- /dev/null
+++ b/summary/src/cat/src/sources.tex
@@ -0,0 +1,204 @@
+\section{Sources of Website Oracles} \label{cat:sec:sources}
+There are a wide range of potential sources of WOs. Table~\ref{cat:table:sources}
+summarizes a selection of sources that are more thoroughly detailed in
+Appendix~\ref{cat:app:sources}. The table shows the availability of the source,
+i.e., if the attacker needs to query the source in near real-time as a website
+visit occurs or if it can be accessed retroactively, e.g., through a legal
+request. We also estimate qualitatively the false positive rate of the source,
+its coverage of websites it can monitor (or fraction of Tor network traffic,
+depending on source), as well as the estimated effort to access the source.
+Finally, the table gives an example of an actor with access to the source. 
+
+Next we focus on a number of sources of WOs that we find particularly relevant:
+several due to DNS in Section~\ref{cat:sec:sources:dns}, the DHT of Tor onion
+directory services in Section~\ref{cat:sec:sources:dht}, and real-time bidding
+platforms in Section~\ref{cat:sec:sources:rtb}. 
+
+\begin{sidewaystable}
+	\caption{Comparison of a number of WO sources based on their \emph{estimated} time of availability (when attacker likely has to collect data, i.e., retroactively or real-time), False Positive Rate (FPR), coverage of website/network visits, and primary entities with access.}
+	\centering
+	\label{cat:table:sources}
+	\begin{tabular}{l c c c c r}
+	Source &  Availability & FPR & Coverage & Effort & Access \\ \midrule
+	Dragnet surveillance programmes  & retroactive & negl. & high & high & intelligence agencies \\
+	Content Delivery Networks & retroactive & negl. & high & high & operators\\
+	Real-time bidding & real-time (retroactive) & negl. & high & modest & customers (operator)\\
+	Webserver access logs & retroactive & negl. & high & medium & operators\\
+	Middleboxes & retroactive~\cite{bluecoat} & negl. & medium & medium & operators \\
+	OCSP & retroactive & low & high & medium & few CAs, plaintext\\
+	8.8.8.8 operator & retroactive & low~\cite{DBLP:conf/ndss/GreschbachPRWF17} & 16.8\% of visits & high & Google, plaintext \\
+	1.1.1.1 operator & retroactive & low~\cite{DBLP:conf/ndss/GreschbachPRWF17} & 7.4\% of visits & high & Cloudflare, plaintext \\
+	Exit relays & real-time & negl. & low & low & operators \\
+	Exit relays DNS cache & real-time & medium & high & medium & anyone\\
+	Query DNS resolvers & real-time & high & low & low & anyone \\
+	Onion v2 (v3) & real-time & negl. & high (low) & low (high) & anyone \\
+	% &  &  &  &  & \\
+	\end{tabular}
+\end{sidewaystable}
+
+\subsection{DNS}
+\label{cat:sec:sources:dns}
+Before a website visit the corresponding domain name must be resolved to an IP
+address. For a user that uses Tor browser, the exit relay of the
+current circuit resolves the domain name. If the DNS record of the domain
+name is already cached in the DNS cache of the exit relay, then the exit relay
+uses that record. Otherwise the domain name is resolved and subsequently cached
+using whichever DNS resolution mechanism that the exit relay has configured.
+Based on this process we present three sources of WOs that work for unpopular
+websites.
+
+\subsubsection{Shared Pending DNS Resolutions}
+If an exit relay is asked to resolve a domain name that is uncached it will
+create a list of pending connections waiting for the domain resolution to
+finish. If another connection asks that the same domain name be resolved, it is
+added to the list of pending connections.  When a result is available all
+pending connections are informed.  This is the basis of a WO: if a request to
+resolve a domain name returns a record \emph{more quickly than previously
+measured by the attacker for uncached entries}, the entry was either pending
+resolution at the time of the request or already cached. Notably this works
+regardless of if exit relays have DNS caches or not. However, the timing
+constraints of shared pending connections are significant and thus a practical
+hurdle to overcome.
+
+\subsubsection{Tor's DNS Cache at Exit Relays}
+If an unpopular website is visited by a user, the resolved domain name will
+likely be cached by a \emph{single} relay.  We
+performed 411 \texttt{exitmap}~\cite{DBLP:conf/pet/WinterKMHSLW14}
+measurements between April 1--10 (2019), collecting on average 3544
+(un)cached data points for each exit using a domain under our control
+that is not used by anyone else.
+
+Given a labelled data set of (un)cached times for each exit relay, we can
+construct distinct \emph{per-relay} classifiers that predict whether a measured
+time corresponds to an (un)cached domain name. While there are many different
+approaches that could be used to build such a classifier, we decided to use a
+simple heuristic that should result in little or no false positives: output
+`cached' iff no uncached query has \emph{ever} been this fast before.
+Figure~\ref{cat:fig:dns:classifier-idea} shows the idea of this classifier in
+greater detail, namely create a \emph{threshold} that is the minimum of the
+largest cached time and the smallest uncached time and then say cached iff the
+measured time is smaller than the threshold. Regardless of how well this
+heuristic performs (see below), it should be possible to construct other
+classifiers that exploit the trend of smaller resolve times and less standard
+deviation for cached queries (Figure~\ref{cat:fig:dns:dist}). For example, 69.1\% of
+all exit relays take at least 50~ms more time to resolve an uncached domain on
+average.
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=.7\columnwidth]{src/cat/img/dns__classifier-idea}
+	\caption{The two cases when deciding on a classifier's threshold.}
+	\label{cat:fig:dns:classifier-idea}
+\end{figure}
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=.7\columnwidth]{src/cat/img/dns__timing-dist}
+	\caption{%
+		The difference between (un)cached standard deviation and mean times
+		without any absolute values, i.e., a negative value implies
+		that the uncached time is smaller than the cached time.
+	}
+	\label{cat:fig:dns:dist}
+\end{figure}
+
+
+To estimate an \emph{upper bound} on how effective the composite classifier of
+all per-relay classifiers could be \emph{without any false positives} using
+our heuristic, we applied ten-fold cross-validation to simply exclude every
+exit relay that had false positives during any fold and then weighted the
+observed bandwidth for the remaining classifiers by the individual true positive
+rates.  This gives us an
+estimate of how much bandwidth we could predict true positives for without
+having any false positives. By comparing it to the total exit bandwidth of the
+Tor network, we obtain an estimated upper bound true positive rate for the
+composite classifier of $17.3$\%.
+
+When an attacker measures if a domain is cached or not the domain will, after
+the measurement, be cached for up to an hour (current highest caching duration
+in Tor, independent of TTL) at every exit. However, if a an attacker can cause
+an exit to run low on memory, the entire DNS cache will be removed (instead of
+only parts of it) due to a bug in the out-of-memory manager of Tor. We have
+reported this to the Tor
+Project~\cite{bug-report}.
+We further discuss in Section~\ref{cat:sec:disc} how frequently an attacker on
+average can be expected to query a WO.
+
+\subsubsection{Caching at Recursive DNS Resolvers}
+For a website that is unpopular enough, there is a high chance that nobody on
+the web visited the website within a given timeframe.  This is the basis of
+our next idea for a WO which is \emph{not mutually exclusive} to the Tor
+network: wait a couple of seconds after observing a connection, then probe all
+recursive DNS resolvers of Tor exits that can be accessed to determine whether
+any monitored website was cached approximately at the time of observing the
+connection by inspecting TTLs. %the TTL of returned DNS records.
+
+In 2016 Greschbach~\emph{et~al.}~\cite{DBLP:conf/ndss/GreschbachPRWF17} showed
+that remote DNS resolvers like Google's \texttt{8.8.8.8} receive a large
+portion of all DNS traffic that exit relays generate. To better understand how
+the DNS resolver landscape looks today, we repeated their RIPE Atlas experiment
+setup for 35 hours in February 17--18 (2019), measuring every 30 minutes. Our
+results show that Google (16.8\%) and Cloudflare (7.4\%) are both popular. Many
+exits use a same-AS resolver which is presumably the ISP (42.3\%), while other
+exits resolve themselves (15.2\%) or use a remote DNS resolver that we did not
+identify (18.2\%). Further, we note that there are at least one RIPE Atlas
+network measurement probe in the same AS as 53.3\% of all exits, providing
+access to many of the same DNS resolvers as used by exits from a similar network
+vantage point. 
+
+Instead of using RIPE Atlas nodes we opted for a different approach which is
+\emph{strictly worse}: query Google's and Cloudflare's DNS resolvers from VMs in
+16 Amazon EC2 regions.  With a simple experiment of first visiting a unique
+domain (once again under our control and only used by us) using \texttt{torify
+curl} and then querying the DNS resolvers from each Amazon VM to observe TTLs,
+we got true positive rates of 2.9\% and 0.9\% for Google and Cloudflare with
+1000 repetitions. While this may seem low, the cost for an attacker is at the
+time of writing about 2 USD per day using on-demand pricing. Using an identical
+setup we were also able to find a subset of monitored websites that yield
+alarmingly high true positive rates: 61.4\% (Google) and 8.0\% (Cloudflare).
+Presumably this was due to the cached entries being shared over a wider
+geographical area for some reason (however, not globally). Regardless, coupled
+with the fact that anyone can \emph{globally purge} the DNS caches of
+Google~\cite{google-purge} and Cloudflare~\cite{cf-purge} for arbitrary domain
+names, this is a noteworthy WO source.
+
+\subsection{Onion Service Directories in Tor}
+\label{cat:sec:sources:dht}
+To access an onion service a user first obtains the service's \emph{descriptor}
+from a Distributed Hash Table (DHT) maintained by \emph{onion service
+directories}. From the descriptor the user learns of \emph{introduction points}
+selected by the host of the onion service in the Tor network that are used to
+establish a connection to the onion service in a couple of more
+steps~\cite{onionv2,onionv3} that are irrelevant here. Observing a request for
+the descriptor of a monitored onion service is a source for a WO. To observe
+visits for a target (known) onion service in the DHT, a relay first has to be
+selected as one out of six or eight (depending on version) relays to host the
+descriptor in the DHT, and then the victim has to select that relay to retrieve
+the descriptor. For v2 of onion services, the location in the DHT is
+deterministic~\cite{onionv2} and an attacker can position its relays in such a
+way to always be selected for hosting target descriptors. Version 3 of onion
+services addresses this issue by randomising the process every 24
+hours~\cite{onionv3}, forcing an attacker to host a significant number of relays
+to get a WO for onion services with high coverage. At the time of writing, there
+are about 3,500 relays operating as onion service directories.
+
+\subsection{Real-Time Bidding}
+\label{cat:sec:sources:rtb}
+Real-Time Bidding (RTB) is an approach towards online advertisement that allows
+a publisher to auction ad space to advertisers on a \emph{per-visit} basis in
+real time~\cite{rtb}. Google's Display Network includes more than two million
+websites that reach 90\% of all Internet users~\cite{google-dn}, and an
+advertiser that uses RTB must respond to submitted bid
+requests containing information such as the three first network bytes of an IPv4
+address, the second-level domain name of the visited website, and the user agent
+string within $\approx$100~ms~\cite{google-bid}. While the exact information
+available to the bidder depends on the ad platform and the publisher's
+advertisement settings, anonymous modes provide less
+revenue~\cite{google-bid-anon}.
+Combined with many flavours of pre-targeting such as IP and location
+filtering~\cite{DBLP:conf/wpes/VinesRK17}, it is likely that the bidder knows
+whether a user used Tor while accessing a monitored website. Vines et
+al.~\cite{DBLP:conf/wpes/VinesRK17} further note that ``35\% of the DSPs also
+allow arbitrary IP white-and blacklisting (Admedo, AdWords, Bing, BluAgile,
+Criteo, Centro, Choozle, Go2Mobi, Simpli.fi)''. Finally, observe that an
+attacker need not win a bid to use RTB as a WO.
diff --git a/summary/src/cat/src/wf.tex b/summary/src/cat/src/wf.tex
new file mode 100644
index 0000000..6b2dedb
--- /dev/null
+++ b/summary/src/cat/src/wf.tex
@@ -0,0 +1,181 @@
+\section{Deep Fingerprinting with Website Oracles} \label{cat:sec:wf}
+We first describe how we augment the Deep Fingerprinting (DF) attack by Sirinam
+\emph{et~al.}~\cite{DF} with WO access. Next we evaluate the augmented
+classifier on three different datasets with five different WF defenses. Source
+code and datasets for simulating WF+WO attacks as well as steps to reproduce all
+of the following results using DF are available at
+\href{https://github.com/pylls/wfwo}{https://github.com/pylls/wfwo}.
+
+\subsection{The Augmented Classifier}
+\label{cat:sec:wf:aug}
+As covered in the background (Section~\ref{cat:sec:back:wf}), DF is a CNN where the
+last layer is a softmax. The output is an array of probabilities for each
+possible class. Compared to the implementation of DF used by Sirinam
+\emph{et~al.}, we changed DF to not first use binary classification in the open
+world to determine if it is an unmonitored trace or not, but rather such that
+there is one class for each monitored website and one for unmonitored.
+Conceptually, this slightly lowers the performance of DF in our analysis, but
+our metrics show that mistaking one monitored website for another is
+insignificant for the datasets used in the analysis of this paper. The principal
+source of false positives is mistaking an unmonitored website for a monitored. 
+
+Given the probability of each possible class as output of DF, we used the second
+generic construction (Definition~\ref{cat:def:oracleprob}) from
+Section~\ref{cat:sec:oracles:generic} to combine DF with a WO. To update the
+remaining probabilities after removing a (monitored) prediction with the help of
+the WO, we use a softmax again. However, due to how the softmax function is
+defined, it emphasizes differences in values above one and actually
+de-emphasizes values between zero and
+one~\cite{wiki}.
+This is problematic for us because all values we send through the softmax are
+probabilities that per definition are between zero and one. To account for this,
+we first divide each probability with the maximum probability and multiply with
+a constant before performing the softmax. Through trial-and-error, a constant of
+five gave us a reasonable threshold in probabilities. Note that this does not in
+any way affect the order of likely classes from DF, it simply puts the
+probabilities in a span that makes it easier for us to retain a threshold value
+between zero and one after multiple calls to the softmax function. 
+
+\subsection{WTF-PAD and Walkie-Talkie}
+We use the original dataset of Sirinam \emph{et~al.}~\cite{DF} that consists of
+95 monitored websites with 1,000 instances each as well as 20,000 unmonitored
+websites (95x1k+20k). The dataset is split 8:1:1 for training, validation, and
+testing, respectively. Given the dataset and our changes to DF to not do binary
+classification means that our testing dataset is unbalanced in terms of
+instances per class. Therefore we show precision-recall curves generated by
+alternating the threshold for DF with and without WO access. 
+
+Figure~\ref{cat:fig:df} shows the results of DF and DF+WO with a simulated WO on
+Sirinam \emph{et~al.}'s dataset with no defense (Figure~\ref{cat:fig:df:nodef}),
+Walkie-Talkie (Figure~\ref{cat:fig:df:wt}), and WTF-PAD
+(Figure~\ref{cat:fig:df:wtfpad}). For the WO we use a 100 ms timeframe and plot the
+results for different starting Alexa ranks of the 95 monitored websites.
+Regardless of defense or not, we observe that for Alexa ranks 1k and less
+popular websites the precision is perfect (1.0) regardless of threshold. This
+indicates that---for an attacker monitoring frontpages of websites---a 100 ms WO
+significantly reduces false positives for two-thirds of all website visits made
+over Tor, for the vast majority of potentially monitored frontpages of websites.
+Recall is also slightly improved. 
+
+\begin{figure}[!t]
+	\centering
+		\begin{subfigure}{.495\columnwidth}
+		\includegraphics[width=1\textwidth]{src/cat/img/df_nodef}
+		\caption{No defense.}
+		\label{cat:fig:df:nodef}
+		\end{subfigure}
+		\begin{subfigure}{.495\columnwidth}
+		\includegraphics[width=1\textwidth]{src/cat/img/df_wt}
+		\caption{Walkie-Talkie~\cite{WT}.}
+		\label{cat:fig:df:wt}
+		\end{subfigure}
+		\begin{subfigure}{.495\columnwidth}
+		\includegraphics[width=1\textwidth]{src/cat/img/df_wtfpad}
+		\caption{WTF-PAD~\cite{wtf-pad}.}
+		\label{cat:fig:df:wtfpad}
+		\end{subfigure}
+		\caption{Attack simulation for Deep Fingerprinting (DF) with website oracles (100 ms timeframe) on Sirinam \emph{et~al.}'s dataset~\cite{DF}. The lines in each sub-figure show DF with and without website oracle access for different starting Alexa ranks for monitored websites.}
+		\label{cat:fig:df}
+\end{figure}
+
+For Walkie-Talkie we observe a significant improvement in precision due to WO
+access. Wang and Goldberg note that the use of popular websites as decoy
+(non-sensitive) websites protects less-popular sensitive websites due to the
+base rate: an attacker claiming that the user visited the less-popular website
+is (per definition) likely wrong, given that the attacker is able to detect both
+potential website visits~\cite{WT}. Access to a WO flips this observation on its
+head: if a WO detects the sensitive less-popular website, the base rate works in
+reverse. The probability of an unpopular website being both miss-classified and
+visited in the timeframe is small for all but the most popular websites. The key
+question becomes one of belief in the base rate of the network and that of the
+target user, as analysed in Appendix~\ref{cat:app:bayes}. 
+
+Further, WO access improves both recall and precision for all monitored websites
+against WTF-PAD. WTF-PAD only provides a three percentage points decrease in
+recall compared to no defense for monitored websites with Alexa ranks 1k and
+above. 
+
+\subsection{CS-BuFLO and Tamaraw}
+To evaluate the constant-rate defenses CS-BuFLO and Tamaraw by Cai et
+al.~\cite{csbuflo,Tamaraw} we use Wang \emph{et~al.}'s dataset in the open world
+\cite{Wang}. The dataset consists of 100 monitored websites with 90 instances
+each and 9000 unmonitored sites (100x90+9k), that we randomly split (stratified)
+into 8:1:1 for training, validation, and testing. We had to increase the length
+of the input to DF for this dataset, from 5000 to 25000, to ensure that we
+capture most of the dataset. To get defended traces for CS-BuFLO and Tamaraw we
+use the slightly modified implementations as part of Cherubin's
+framework~\cite{Cherubin17}. 
+
+Figure~\ref{cat:fig:wang} shows the results of our simulations. DF alone is also
+highly effective against the original Wang dataset---as expected---and our
+attack simulation shows that we can further improve it with access to website
+oracles. Most importantly, both CS-BuFLO and Tamaraw offer protection against DF
+with and without oracle access by \emph{significantly lowering recall}. Tamaraw
+offers an order of magnitude better defense in terms of recall. As implemented
+in the framework by Cherubin, CS-BuFLO and Tamaraw reportedly has BOH 67.2\% and
+256.7\%, and TOH 575.6\% and 341.4\%, respectively. This kind of overhead is
+likely prohibitively large for real-world deployment in
+Tor~\cite{csbuflo,Tamaraw,wtf-pad,DF,WT}.
+
+\begin{figure}[!t]
+	\centering
+		\begin{subfigure}{.495\columnwidth}
+		\includegraphics[width=1\textwidth]{src/cat/img/wang_nodef}
+		\caption{No defense.\\\,}
+		\label{cat:fig:wang:nodef}
+		\end{subfigure}
+		\begin{subfigure}{.495\columnwidth}
+		\includegraphics[width=1\textwidth]{src/cat/img/wang_csbuflo}
+		\caption{CS-BuFLO~\cite{csbuflo}, with reported 67.2\% BOW and 575.6\% TOH~\cite{Cherubin17}.}
+		\label{cat:fig:wang:csbuflo}
+		\end{subfigure}
+		\begin{subfigure}{.495\columnwidth}
+		\includegraphics[width=1\textwidth]{src/cat/img/wang_tamaraw}
+		\caption{Tamaraw~\cite{Tamaraw}, with reported 256.7\% BOW and 341.4\% TOH~\cite{Cherubin17}.}
+		\label{cat:fig:wang:tamaraw}
+		\end{subfigure}
+		\caption{Attack simulation for Deep Fingerprinting (DF)~\cite{DF} with website oracles (100 ms timeframe) on Wang \emph{et~al.}'s dataset~\cite{Wang}. The lines in each sub-figure show DF with and without website oracle access for different starting Alexa ranks for monitored websites.}
+		\label{cat:fig:wang}
+\end{figure}
+
+
+\subsection{DynaFlow}
+DynaFlow is a \emph{dynamic} constant-rate defense by Lu
+\emph{et~al.}~\cite{DynaFlow} with two configurations that result in different
+overheads and levels of protection. Lu \emph{et~al.} gathered their own dataset
+of 100 monitored websites with 90 instances each and 9000 unmonitored websites
+(100x90+9k, same as Wang \emph{et~al.}'s \cite{Wang}) to be able to combine
+smaller packets, as discussed briefly in Section~\ref{cat:sec:back:wf}. As for
+CS-BuFLO and Tamaraw, we had to increase the length of the input to DF for this
+dataset to 25000 to ensure that we capture most of the dataset. 
+
+Figure~\ref{cat:fig:dynaflow} shows the results of our simulations for no defense as
+well as the two configurations of DynaFlow. As for Wang \emph{et~al.}'s
+dataset~\cite{Wang}, we see as expected that DF is highly effective and WO
+access further improves the attack. Further, both configurations of DynaFlow are
+effective defenses, comparable to CS-BuFLO with significantly lower overheads at
+first glance. However, note that the comparison is problematic due to DynaFlow
+combining smaller packets. The extra overhead for config 2 over 1 is not wasted:
+recall is significantly reduced, more than halved for regular DF and slightly
+less than half with a WO. 
+
+\begin{figure}[!t]
+	\centering
+		\begin{subfigure}{.495\columnwidth}
+		\includegraphics[width=1\textwidth]{src/cat/img/dynaflow_nodef}
+		\caption{No defense.\\\,}
+		\label{cat:fig:dynaflow:nodef}
+		\end{subfigure}
+		\begin{subfigure}{.495\columnwidth}
+		\includegraphics[width=1\textwidth]{src/cat/img/dynaflow_config1}
+		\caption{DynaFlow~\cite{DynaFlow} config 1, with measured 59\% BOH and 24\% TOH.}
+		\label{cat:fig:dynaflow:config1}
+		\end{subfigure}
+		\begin{subfigure}{.495\columnwidth}
+			\includegraphics[width=1\textwidth]{src/cat/img/dynaflow_config2}
+			\caption{DynaFlow~\cite{DynaFlow} config 2, with measured 109\% BOH and 30\% TOH.}
+			\label{cat:fig:dynaflow:config2}
+		\end{subfigure}
+		\caption{Attack simulation for Deep Fingerprinting (DF)~\cite{DF} with website oracles (100 ms timeframe) on Lu \emph{et~al.}'s dataset~\cite{DynaFlow}. The lines in each sub-figure show DF with and without website oracle access for different starting Alexa ranks for monitored websites.}
+		\label{cat:fig:dynaflow}
+\end{figure}
diff --git a/summary/src/ctga/.gitignore b/summary/src/ctga/.gitignore
new file mode 100644
index 0000000..8bb88c8
--- /dev/null
+++ b/summary/src/ctga/.gitignore
@@ -0,0 +1,9 @@
+main.pdf
+*.blg
+*.bbl
+*.fls
+*.fdb_latexmk
+*.log
+*.out
+*.aux
+*.swp
diff --git a/summary/src/ctga/img/design.pdf b/summary/src/ctga/img/design.pdf
new file mode 100644
index 0000000..3a9aba1
--- /dev/null
+++ b/summary/src/ctga/img/design.pdf
diff --git a/summary/src/ctga/img/parser.tex b/summary/src/ctga/img/parser.tex
new file mode 100644
index 0000000..dba221b
--- /dev/null
+++ b/summary/src/ctga/img/parser.tex
@@ -0,0 +1,66 @@
+\resizebox{\columnwidth}{!}{%
+\begin{tikzpicture}[%
+  -latex,
+  sibling distance=10em,
+  level distance=22pt,
+  parser/.style = {%
+    draw,
+    shape=rectangle,
+    rounded corners,
+    align=center,
+    top color=white,
+    bottom color=mydblue!20,
+  },
+  label/.style = {%
+    draw=none,
+    align=center,
+    text=mydblue,
+    font=\scriptsize,
+  },
+  arrow/.style = {%
+	  draw,
+	  -latex,
+	  rounded corners,
+  },
+]
+	
+	\node[parser](eth){Ethernet};
+	\node[parser,right=of eth](udp){UDP};
+	\coordinate(ip) at ($ (eth) !.5! (udp) $);
+	\node[parser,above=of ip](ipv4){IPv4};
+	\node[parser,below=of ip](ipv6){IPv6};
+
+	\node[parser,right=of udp](dns){DNS};
+	\node[parser](dnsp) at ($ (dns) + (1,1.1) $){preamble};
+	\node[parser](dnsq) at ($ (dns) + (2.25,.45) $){domain name};
+	\node[parser](dnst) at ($ (dns) + (2.25,-.45) $){query type};
+	\node[parser](dnsc) at ($ (dns) + (1,-1.1) $){query class};
+
+	\path[arrow] ($ (eth) + (-1.25,0) $) -- node[left,pos=0]{\texttt{pkt\_in}} (eth);
+
+	\path[arrow] (eth) |- node[label,above left,pos=1]{\texttt{type=0x0800}} (ipv4);
+	\path[arrow] (eth) |- node[label,below left,pos=1]{\texttt{type=0x86DD}} (ipv6);
+	\path[arrow] (ipv4) -| node[label,above right, pos=0]{\texttt{proto=0x17}} (udp);
+	\path[arrow] (ipv6) -| node[label,below right, pos=0]{\texttt{proto=0x17}} (udp);
+	\path[arrow] (udp) -- node[label,above]{\texttt{sport=53}} (dns);
+
+	\path[arrow,dashed] (dns) |- (dnsp);
+	\path[arrow,dashed] (dnsp) -| node[label,above right,pos=0]{\texttt{qd=an=1}} (dnsq);
+	\path[arrow,dashed] (dnsq) -- node[label,right]{\texttt{known log}} (dnst);
+	\path[arrow,dashed] (dnst) |- node[label,below right,pos=1]{\texttt{TXT}} (dnsc);
+	\path[arrow,dashed]
+		(dnsq) edge[out=5, in=355, looseness=8]
+			node[label,right]{
+				\begin{tabular}{c}
+					variable \\
+					length
+				  \end{tabular}
+				}
+		(dnsq);
+	\path[arrow,dashed]
+		(dnsc) --
+			node[label,below right,pos=.8]{\texttt{IN}}
+			node[pos=1.2,rotate=90]{\texttt{clone}}
+		($ (dnsc) + (-1.5,0) $);
+\end{tikzpicture}
+}
diff --git a/summary/src/ctga/img/perf-netfpga.pdf b/summary/src/ctga/img/perf-netfpga.pdf
new file mode 100644
index 0000000..309a689
--- /dev/null
+++ b/summary/src/ctga/img/perf-netfpga.pdf
diff --git a/summary/src/ctga/img/perf-xdp.pdf b/summary/src/ctga/img/perf-xdp.pdf
new file mode 100644
index 0000000..041cbdd
--- /dev/null
+++ b/summary/src/ctga/img/perf-xdp.pdf
diff --git a/summary/src/ctga/img/pl.pdf b/summary/src/ctga/img/pl.pdf
new file mode 100644
index 0000000..0b39f91
--- /dev/null
+++ b/summary/src/ctga/img/pl.pdf
diff --git a/summary/src/ctga/img/ps.pdf b/summary/src/ctga/img/ps.pdf
new file mode 100644
index 0000000..cf3db16
--- /dev/null
+++ b/summary/src/ctga/img/ps.pdf
diff --git a/summary/src/ctga/img/related.tex b/summary/src/ctga/img/related.tex
new file mode 100644
index 0000000..31a86e8
--- /dev/null
+++ b/summary/src/ctga/img/related.tex
@@ -0,0 +1,37 @@
+\resizebox{1\columnwidth}{!}{%
+  \begin{tikzpicture}[%
+    ns/.style = {
+      draw=none,
+    },
+    ps/.style = {
+      draw,
+      -latex,
+    },
+  ]
+    \node[ns](gossip){};
+    \node[ns,right=0pt of gossip](retroactive){\textbf{Retroactive}};
+    \node[ns,left=0pt of gossip](proactive){\textbf{Proactive}};
+
+    % proactive
+    \node[ns,left=12pt of proactive](cross){STH cross-logging~\cite{minimal-gossip,ietf-cross-logging,hof-cross-logging,catena}};
+    \node[ns,above=0pt of cross](push){STH pushing~\cite{google-gossip}};
+    \node[ns,below=0pt of cross](cosi){STH cosigning~\cite{cosi}};
+
+    \path[ps] (proactive) -- (push.east);
+    \path[ps] (proactive) -- (cross);
+    \path[ps] (proactive) -- (cosi.east);
+
+    % retroactive
+    \node[ns,right=12pt of retroactive](implicit){Implicit via multipath~\cite{mpaudit}};
+    \node[ns,above=0pt of implicit](pool){STH pooling~\cite{chuat-gossip,ietf-gossip}};
+    \node[ns,below=0pt of implicit](trust){Trusted auditing~\cite{ietf-gossip}};
+    \node[ns,above=14pt of retroactive.north east](feedback){SCT feedback~\cite{ietf-gossip}};
+    \node[ns,below=14pt of retroactive.south east](bee){CT honey bee~\cite{ct-honey-bee}};
+
+    \path[ps] (retroactive) -- (feedback);
+    \path[ps] (retroactive) -- (pool.west);
+    \path[ps] (retroactive) -- (implicit);
+    \path[ps] (retroactive) -- (trust.west);
+    \path[ps] (retroactive) -- (bee);
+  \end{tikzpicture}
+}
diff --git a/summary/src/ctga/img/wcov-goo.pdf b/summary/src/ctga/img/wcov-goo.pdf
new file mode 100644
index 0000000..976e5bd
--- /dev/null
+++ b/summary/src/ctga/img/wcov-goo.pdf
diff --git a/summary/src/ctga/img/wcov-nor.pdf b/summary/src/ctga/img/wcov-nor.pdf
new file mode 100644
index 0000000..110cf88
--- /dev/null
+++ b/summary/src/ctga/img/wcov-nor.pdf
diff --git a/summary/src/ctga/main.tex b/summary/src/ctga/main.tex
new file mode 100644
index 0000000..bc5ff45
--- /dev/null
+++ b/summary/src/ctga/main.tex
@@ -0,0 +1,70 @@
+\begin{kaupaper}[
+    author={%
+      \textbf{Rasmus Dahlberg},
+      Tobias Pulls,
+      Jonathan Vestin,
+      Toke H{\o}iland-J{\o}rgensen, and
+      Andreas Kassler
+    },
+    title={%
+      Aggregation-Based Certificate Transparency Gossip
+    },
+    reference={%
+      SECURWARE (2019)
+    },
+    summary={%
+      Another often overlooked part of Certificate Transparency is that monitors
+      and end-users who browse websites must observe the same append-only
+      logs.  For example, if the same append-only logs are not observed, an
+      end-user may connect to a website that serves a mis-issued certificate
+      that no monitor will discover.  This would largely defeat the purpose of
+      public logging, which is why RFC~6962 specifies that multiple gossip
+      protocols should be defined separately in the future.  We define one such
+      protocol that plugs into the (at the time current) idea of having
+      end-users interact with the logs through DNS.  Our work is exploratory,
+      using recent advancements in programmable packet processors that allow
+      turning routers, switches, and network interface cards into
+      \emph{aggregators} of tree heads that the logs signed and transmitted in
+      plaintext via DNS.  The aggregated tree heads are then used as a reference
+      while challenging the logs to prove consistency, thus protecting
+      entire vantage points from undetected split views.  A different
+      network path (like Tor) can be used to break out of a local vantage point
+      to increase the likelihood of global consistency.  If the security
+      definition for \emph{aggregation indistinguishability} is satisfied,
+      vantage points without an aggregator may also receive protection due to
+      herd immunity.  Our P4 and XDP prototypes satisfy the notion of
+      aggregation indistinguishability at line-rate with regard to throughput.
+      Prevalent vantage points to roll out aggregation-based gossip include
+      autonomous systems and Internet exchange points that route the traffic of
+      many users.  Our RIPE Atlas measurements show that 32 autonomous systems
+      could protect 30-50\% of the IPv4 space from undetected split views.
+      End-users merely need to use plaintext DNS for opt-in.
+    },
+    participation={\vspace{-.25cm}
+      Andreas and Tobias had the initial idea of exploring the intersection
+      between Certificate Transparency and programmable packet processors.  I did most of the
+      design and writing with feedback from Tobias, our RIPE Atlas measurements,
+      and our performance benchmarks with Jonathan and Toke.
+    },
+    label={
+      paper:ctga
+    },
+]
+  \maketitle
+  \begin{abstract}
+    \input{src/ctga/src/abstract}
+  \end{abstract}
+  
+  \input{src/ctga/src/introduction}
+  \input{src/ctga/src/background}
+  \input{src/ctga/src/design}
+  \input{src/ctga/src/implementation}
+  \input{src/ctga/src/measurements}
+  \input{src/ctga/src/related}
+  \input{src/ctga/src/discussion}
+  \input{src/ctga/src/conclusion} 
+  \input{src/ctga/src/acknowledgments}
+  
+  \bibliographystyle{plain}
+  \bibliography{src/ctga/src/ref}
+\end{kaupaper}
diff --git a/summary/src/ctga/src/abstract.tex b/summary/src/ctga/src/abstract.tex
new file mode 100644
index 0000000..5483f7e
--- /dev/null
+++ b/summary/src/ctga/src/abstract.tex
@@ -0,0 +1,16 @@
+\noindent
+Certificate Transparency (CT) requires that every certificate which is issued by
+a certificate authority must be publicly logged.  While a CT log can be
+untrusted in theory, it relies on the assumption that every client observes and
+cryptographically verifies the same log. As such, some form of gossip mechanism
+is needed in practice. Despite CT being adopted by several major browser
+vendors, no gossip mechanism is widely deployed.
+We suggest an aggregation-based gossip mechanism that passively observes
+cryptographic material that CT logs emit in plaintext, aggregating at packet
+processors (such as routers and switches) to periodically verify log consistency
+off-path. In other words, gossip is provided as-a-service by the network.  Our
+proposal can be implemented for a variety of programmable packet processors at
+line-speed without aggregation distinguishers (throughput), and based on
+20 days of RIPE Atlas measurements that represent clients from 3500 autonomous
+systems we show that significant protection against split-viewing CT logs can be
+achieved with a realistic threat model and an incremental deployment scenario.
diff --git a/summary/src/ctga/src/acknowledgments.tex b/summary/src/ctga/src/acknowledgments.tex
new file mode 100644
index 0000000..a35331b
--- /dev/null
+++ b/summary/src/ctga/src/acknowledgments.tex
@@ -0,0 +1,5 @@
+\section*{Acknowledgements}
+We would like to thank Stefan Alfredsson and Philipp Winter for their RIPE Atlas
+credits, as well as Jonas Karlsson and Ricardo Santos for helping with the
+NetFPGA setup. We also received funding from the HITS research profile which is
+funded by the Swedish Knowledge Foundation.
diff --git a/summary/src/ctga/src/background.tex b/summary/src/ctga/src/background.tex
new file mode 100644
index 0000000..e924d57
--- /dev/null
+++ b/summary/src/ctga/src/background.tex
@@ -0,0 +1,90 @@
+\section{Background} \label{ctga:sec:background}
+First additional prerequisites are provided on CT and the status quo,
+then the techniques which allow us to program custom packet processors are
+introduced.
+
+\subsection{Certificate Transparency} \label{ctga:sec:background:ct}
+The main motivation of CT is that the CA ecosystem is error-prone~\cite{laurie}:
+	a CA can normally issue certificates for \emph{any} domain name, and
+	given that there are hundreds of trusted CAs an attacker only needs to
+	target the weakest link~\cite{ca-ecosystem}. 
+While the requirement of CT logging all certificates cannot prevent mis-issuance
+proactively, it allows anyone to detect it retroactively by monitoring the
+logs~\cite{ct}.  After a log promises to include a certificate by issuing a
+Signed Certificate Timestamp (SCT), a new STH including the appended certificate
+must be issued within a Maximum Merge Delay (MMD). Typically, logs use 24~hour
+MMDs. Should non-included SCTs and/or inconsistent STHs be found,
+binding evidence of misbehaviour exists because these statements are
+digitally signed by the logs.  Other than MMD a log's policy defines parameters
+such as STH frequency:
+	the number of STHs that can be issued during an MMD, making it harder to
+	track clients~\cite{ietf-gossip}.
+
+CT is being deployed across Apple's platform~\cite{apple-ct} and Google's
+Chrome~\cite{google-ct}. The status quo is to trust a CA-signed certificate if
+it is accompanied by two or more SCTs, thereby relying on at least one log to
+append each certificate so that mis-issuance can be detected by monitors that
+inspect the logs. The next step of this incremental deployment is to
+\emph{verify} that these certificates are logged by querying for
+inclusion~\cite{google-gossip}, and that the log's append-only property is
+respected by challenging the log to prove STH consistency. Finally, to fully
+distrust CT logs we need mechanisms that detect split-views.  One such mechanism
+which is based on programmable packet processors (introduced next) is presented
+in Section~\ref{ctga:sec:design}, and it is compared to related work on CT gossip in
+Section~\ref{ctga:sec:related}.
+
+\subsection{Programmable Data Planes} \label{ctga:sec:background:pdp}
+Packet processors such as switches, routers, and network interface cards
+are typically integrated tightly using customized hardware and application-%
+specific integrated circuits. This inflexible design limits the
+potential for innovation and leads to long product upgrade cycles, where it
+takes \emph{years} to introduce new processing capabilities and support for
+different protocols and header fields (mostly following lengthy
+standardization cycles).
+The recent shift towards flexible \emph{match+action} packet-processing
+pipelines---including
+  RMT~\cite{rmt},
+  Intel Flexpipe~\cite{flexpipe},
+  Cavium XPA~\cite{cavium}, and
+  Barefoot Tofino~\cite{barefoot}---%
+now have the potential to change the way in which packet processing hardware is
+implemented:
+  it enables programmability using high-level languages, such as P4,
+  while at the same time maintaining performance comparable to fixed-function
+  chips.
+
+\subsubsection{P4}
+The main goal of P4 is to simplify
+  \barbelow{p}rogramming of
+  \barbelow{p}rotocol-independent
+  \barbelow{p}acket
+  \barbelow{p}rocessors
+by providing an abstract programming model for the network data plane~\cite{p4}.
+In this setting, the functionality of a packet processing device is specified
+without assuming any hardwired protocols and headers. Consequently, a P4 program
+must parse headers and connect the values of those protocol fields to the
+actions that should be executed based on a pipeline of reconfigurable
+match+action tables.
+Based on the specified P4 code, a front-end compiler generates a high-level
+intermediate representation that a back-end compiler uses to create a target-%
+dependent program representation. Compilers are available for several platforms,
+including
+  the software-based simple switch architecture~\cite{p4bm},
+  SDNet for Xilinx NetFPGA boards~\cite{p4netfpga}, and
+  Netronome's smart network interfaces~\cite{p4netronome}.
+It is also possible to compile basic P4 programs into eBPF byte
+code~\cite{p42ebpf}.
+
+\subsubsection{XDP}
+The Berkeley Packet Filter (BPF) is a Linux-based packet filtering
+mechanism~\cite{bpf}. Verified bytecode is injected from user space, and
+executed for each received packet in kernel space by a just-in-time compiler.
+Extended BPF (eBPF)
+enhances the original BPF concept, enabling faster runtime and many new
+features.  For example, an eBPF program can be attached to the Linux traffic
+control tool \texttt{tc}, and additional hooks were defined for a faster eXpress
+Data Path (XDP)~\cite{xdp}. In contrast to the Intel Data Plane Development Kit
+(DPDK), which runs in user space and completely controls a given network
+interface that supports a DPDK driver, XDP cooperates with the Linux stack to
+achieve fast, programmable, and reconfigurable packet processing using C-like
+programs.
diff --git a/summary/src/ctga/src/conclusion.tex b/summary/src/ctga/src/conclusion.tex
new file mode 100644
index 0000000..f001ace
--- /dev/null
+++ b/summary/src/ctga/src/conclusion.tex
@@ -0,0 +1,23 @@
+\section{Conclusion and Future Work} \label{ctga:sec:conclusion}
+Wide spread modifications of TLS clients are inevitable to support CT gossip.
+We propose that these modifications include challenging the logs to
+prove certificate inclusion based on STHs \emph{fetched in plaintext}, thereby
+enabling the traversed packet processors to assist in split view detection
+retroactively by aggregating STHs for periodic off-path verification.  Our
+results show that the aggregation-step can be implemented without throughput-%
+based distinguishers for a distant attacker, and that our approach offers rapid
+incremental deployment with high impact on a significant fraction of Internet
+users.  Beyond being an application neutral approach that is complementary to
+proactive gossip, a compelling aspect is that core packet processors are used
+(rather than clients) as a key building block:
+	should a consistency issue arise, it is already in the hands of an actor
+	that is better equipped to investigate the cause manually.
+Further, considering that far from all TLS clients are backed by big browser
+vendors (not to mention other use-cases of transparency logs in general) it is
+likely a long-term win to avoid pushing complex retroactive gossip logic into
+all the different types of clients when there are orders of magnitudes fewer
+packet processors that could aggregate to their own off-path challengers.
+Future work includes different instantiations of the aggregation step and
+evaluating whether aggregation indistinguishability is provided based on
+throughput and/or latency.  The setting may also change in some scenarios,
+e.g., if DNS caches are aggregated the transport need not be plaintext.
diff --git a/summary/src/ctga/src/design.tex b/summary/src/ctga/src/design.tex
new file mode 100644
index 0000000..a04e36b
--- /dev/null
+++ b/summary/src/ctga/src/design.tex
@@ -0,0 +1,129 @@
+\section{Design} \label{ctga:sec:design}
+An overview of aggregation-based gossip is shown in Figure~\ref{ctga:fig:agg}. The
+setting consists of logs that send plaintext STHs to clients over a network, and
+as part of the network inline \emph{packet processors} passively aggregate
+observed STHs to their own off-path \emph{challengers} which challenge the logs
+to prove consistency. A log cannot present split views to different clients that
+share an aggregating vantage point because it would trivially be detected by
+that vantage point's challenger. A log also cannot present a persistent split
+view to different challengers because they are off-path in the sense that they
+are indistinguishable from one another. This means that every client that is
+covered by an aggregator must be on the same view because at least one
+challenger will otherwise detect an inconsistency and report it. A client that
+is not directly covered by an aggregator may receive indirect protection in the
+form of herd immunity. This is discussed in Section~\ref{ctga:sec:discussion:herd}.
+\begin{figure}[!t]
+  \centering
+  \includegraphics[width=\columnwidth]{src/ctga/img/design.pdf}
+  \caption[ ]{%
+    Packet processor that aggregates plaintext STHs for off-path verification.
+  }
+  \label{ctga:fig:agg}
+\end{figure}
+
+\subsection{Threat Model and Security Notion} \label{ctga:sec:agg:thr}
+The overarching threat is undetectable domain impersonation (ex-post) by an
+attacker that is capable of compromising at least one CA and a sufficient number
+of CT logs to convince a client into accepting a forged certificate.
+We assume that any illegitimately issued certificate
+would be detected by the legitimate domain owner through self or delegated
+third-party monitoring.
+This means that an attacker must either provide a split view towards the victim
+or the monitoring entity.
+We also assume that clients query the logs for certificate inclusion based on
+STHs that they acquire from the logs via plaintext mechanisms that packet
+processors can observe, and that some other entities than challengers process
+STHs using the chosen off-paths (Section~\ref{ctga:sec:discussion:limitations}).
+We do not account for the fact that CA compromises may be detected by other
+means, focusing solely on split-viewing CT logs.
+
+\subsubsection{Limitations}
+Our gossip mechanism is limited to STHs that packet processors can observe.
+As such, a client isolated by an attacker is not protected. We limit ourselves
+to attackers that act over a network some distance
+(in the sense of network path length) from a client in plaintext so that
+aggregation can take place. Our limitations and assumptions are further
+discussed in Section~\ref{ctga:sec:discussion:limitations}.
+
+\subsubsection{Attackers}
+Exceptionally powerful attackers can isolate clients, \emph{but clients are not
+necessarily easy to isolate} for a significant number of relevant attackers.
+Isolation may require physical control over a device~\cite{fbi-apple},
+clients may be using anonymity networks like Tor where path selection is
+inherently unpredictable~\cite{tor}, or sufficiently large parts of the network
+cannot be controlled to ensure that no aggregation takes place.
+This may be the case if we consider
+  a nation state actor attacking another nation state actor,
+  the prevalence of edge security middleboxes, and
+  that home routers or NICs nearby the clients could aggregate.
+Any attacker that cannot account for these considerations is within our
+threat model.
+
+\subsubsection{Security Notion}
+To bypass our approach towards gossip an adaptive attacker may attempt to
+actively probe the network for aggregating packet processors. This leads us to
+the key security notion:
+  \emph{aggregation indistinguishability}.
+An attacker should not be able to determine if a packet processor is aggregating
+STHs. The importance of aggregation indistinguishability motivates the design of
+our gossip mechanism into two distinct components:
+  aggregation that takes place inline at packet processors, and
+  periodic off\mbox{-}path log challenging that checks whether the observed STHs
+    are consistent.
+
+\subsection{Packet Processor Aggregation} \label{ctga:sec:aggregator}
+An aggregating packet-processor determines for each packet if it is STH-related.
+If so, the packet is cloned and sent to a challenging component for off-path
+verification.
+The exact definition of \emph{STH-related} depends on the plaintext source, but it
+is ultimately the process of inspecting multiple packet headers such as
+transport protocol and port number. It should be noted that the original packet
+must not be dropped or modified. For example, an aggregator would have a
+trivial aggregation distinguisher if it dropped any malformed STH.
+
+For each aggregating packet processor we have to take IP fragmentation into
+consideration. Recall that IP fragmentation usually occurs when a packet is
+larger than the MTU, splitting it into multiple smaller IP packets that are
+reassembled at the destination host. Normally, an STH should not be fragmented
+because it is much smaller than the de-facto minimum MTU of (at least) 576~%
+bytes~\cite{min-mtu,ipv6}, but an attacker could use fragmentation to
+\emph{intentionally} spread expected headers across multiple packets.
+Assuming stateless packet processing, an aggregator cannot identify
+such fragmented packets as STH-related because some header would be absent
+  (cf.\ stateless firewalls).
+All tiny fragments should therefore be aggregated to account for intentional IP
+fragmentation, which appears to have little or no impact on normal traffic
+because tiny fragments are anomalies~\cite{frag-study-02}. The threat of 
+multi-path fragmentation is discussed in Section~\ref{ctga:sec:discussion:limitations}.
+
+Large traffic loads must also be taken into account. If an aggregating
+packet processor degrades in performance as the portion of STH-related traffic
+increases, a distant attacker may probe for such behaviour to determine if a
+path contains an aggregator. Each \emph{implementation} must therefore be
+evaluated individually for such behaviour, and if trivial aggregation
+distinguishers exist this needs to be solved. For example, STH-related traffic
+could be aggregated probabilistically to reduce the amount of work.
+Another option is to load-balance the traffic before aggregation, i.e., avoid
+worst-case loads that cannot be handled.
+
+\subsection{Off-Path Log Challenging} \label{ctga:sec:challenger}
+A challenger is setup to listen for aggregated traffic, reassembling IP
+fragments and storing the aggregated STHs for periodic off-path verification.
+Periodic off\mbox{-}path verification means that the challenger challenges the log
+based on its own (off-path fetched) STHs and the observed (aggregated) STHs to
+verify log consistency periodically, e.g., every day.
+The definition of \emph{off-path} is that the challenger must not be linkable to
+its aggregating packet processor(s) or any other challenger (including itself).
+Without an off-path there is no gossip step amongst aggregator-challenger
+instances that are operated by different actors, and our approach towards gossip
+would only assert that clients behind the same vantage point observe the same
+logs. If a log cannot distinguish between different challengers due to the
+use of off-paths, however, it is non-trivial to maintain a targeted split-view
+towards an unknown location. Therefore, we get a form of \emph{implicit
+gossip}~\cite{mpaudit} because at least one challenger would detect an
+inconsistency unless everybody observes the same log. If every challenger
+observes the same log, so does every client that is covered by an aggregating
+packet processor.  Notably the challenger component \emph{does not run inline}
+to avoid timing distinguishers.  Note that there are other important
+considerations when implementing a challenger, as discussed in
+Section~\ref{ctga:sec:discussion:limitations}.
diff --git a/summary/src/ctga/src/discussion.tex b/summary/src/ctga/src/discussion.tex
new file mode 100644
index 0000000..3a542d1
--- /dev/null
+++ b/summary/src/ctga/src/discussion.tex
@@ -0,0 +1,126 @@
+\section{Discussion} \label{ctga:sec:discussion}
+Next we discuss assumptions, limitations and deployment, showing that
+our approach towards retroactive gossip can be deployed to detect
+split-views by many relevant attackers with relatively little effort.  The
+main drawback is reliance on clients fetching STHs in plaintext, e.g., using
+CT-over-DNS~\cite{ct-over-dns}.
+
+\subsection{Assumptions and Limitations} \label{ctga:sec:discussion:limitations}
+Aggregation-based gossip is limited to network traffic that packet processors
+can observe. The strongest type of attacker in this setting---who can completely
+isolate a client---trivially defeats our gossip mechanism and other retroactive
+approaches in the literature (see Section~\ref{ctga:sec:related}).
+A weaker attacker cannot isolate a client, but is located nearby in a network
+path length sense. This limits the opportunity for packet processor aggregation,
+but an attacker cannot rule it out given aggregation indistinguishability.
+Section~\ref{ctga:sec:implementation} showed based on performance that it is non-%
+trivial to distinguish between (non\mbox{-})aggregating packet processors on two
+different targets using P4 and XDP. Off-path challengers must also be
+indistinguishable from one another to achieve \emph{implicit gossip}.
+While we suggested the use of anonymity networks like Tor, a prerequisite is
+that this is in and of itself not an aggregation distinguisher.
+Therefore, we assume that other entities also use off-paths to fetch and verify
+STHs. The fact that a unique STH \emph{is not audited} from an off-path could
+also be an aggregation distinguisher. To avoid this we could rely on a
+verifiable STH history~\cite{ver-sth}
+and wait until the next MMD to audit or simply monitor the full log so that
+consistency proofs are unnecessary.
+
+The existence of multiple network paths are fundamental to the structure and
+functioning of the Internet. A weak attacker may use IP fragmentation such that
+each individual STH fragment is injected from a different location to make
+aggregation harder, approaching the capabilities of a stronger attacker that
+is located closer to the client. This is further exacerbated by the deployment
+of multi-path transport protocols like MPTCP (which can also be fragmented).
+Looking back at our RIPE Atlas measurements in Section~\ref{ctga:sec:measurements}, the
+results towards Google's world-wide infrastructure better represent an active
+attacker that takes \emph{some} measures to circumvent aggregation by
+approaching a client nearby the edge. Given that the likelihood of aggregation
+is high if \emph{any} IXP is present (Figure~\ref{ctga:fig:wcov}), aggregation at
+well-connected IXPs are most likely to be circumvented.
+
+\subsection{Deployment} \label{ctga:sec:disussion:deployment}
+Besides aggregating at strategic locations in the Internet's backbone,
+ISPs and enterprise networks have the opportunity to protect all of their
+clients with relatively little effort. Deployment of special-purpose middleboxes
+are already prevalent in these environments, and then the inconvenience of
+fragmentation tends to go away due to features such as packet reassembly.
+Further, an attacker cannot trivially circumvent the edge of a network topology%
+---especially not if aggregation takes place on an end-system:
+  all fragments are needed to reassemble a packet, which means that multi-path
+  fragmentation is no longer a threat.
+If aggregation-based gossip is deployed on an end-system, STHs could be
+hooked using other approaches than P4/XDP. For example, shim-layers that
+intercept TLS certificates higher up in the networking stack were already
+proposed by Bates~\emph{et~al.}~\cite{h1} and O'Neill~\emph{et~al.}~\cite{h2}.
+In this setting, an end-system is viewed as the aggregating packet processor,
+and it reports back to an off-path challenger that may be a local process
+running on the same system or a remote entity, e.g., a TelCo could host
+challengers that collect aggregated STHs from smartphones.
+
+While we looked at programming physical packet processors like routers,
+STH aggregation could be approached in hypervisors and software
+switches~\cite{pisces} to protect many virtual hosts. If CT-over-DNS is used to
+fetch STHs, it would be promising to output DNS server caches to implement the
+aggregation step. Similar to DNS servers, so called Tor exist relays also
+operate DNS caches. In other words, P4 and XDP are only examples of how to
+\emph{instantiate} the aggregation step. Depending on the used plaintext source,
+packet processor, and network topology other approaches may be more suitable,
+e.g., C for vendor-specific middleboxes.
+
+\subsection{Retroactive Gossip Benefits From Plaintext}
+As opposed to an Internet core that only forwards IP packets, extra
+functionality is often embedded which causes complex processing dependencies and
+protocol ossification~\cite{TCPoss}. Many security and protocol issues were
+found for middleboxes that provides extra
+functionality~\cite{HTTPSintercept,langely-quic}, resulting in the mindset
+that \emph{everything} should be encrypted~\cite{langely-quic}.
+Our work is controversial because it goes against this mindset and advocates
+that STHs should be communicated in plaintext.
+We argue that this makes sense in the context of STHs due to the absence of
+privacy concerns and because the entire point of gossip is to make STHs
+\emph{available} (rather than end-to-end).
+The idea of intentionally exposing information to the network is not new, e.g.,
+MPQUIC is designed to support traffic shaping~\cite{mpquic}.
+
+While we used CT-over-DNS as a plaintext source, there is a push towards
+DNS-over-TLS~\cite{dot} and DNS-over-HTTPS~\cite{doh}.
+Wide use of these approaches could undermine our gossip mechanism, but
+ironically the security of TLS could be jeopardized unless gossip is deployed.
+In other words, long term gossip is an essential component of CT and other
+transparency logs to avoid becoming yet another class of trusted third-parties.
+If proactive approaches such as witness cosigning are rejected in favour of
+retroactive mechanisms, then ensuring that STHs are widely spread and easily
+accessible is vital. An STH needs no secrecy if the appropriate measures are
+taken to make it privacy-insensitive~\cite{ietf-gossip}.
+While secure channels also provide integrity and replay protection, an STH is
+already signed by logs and freshness is covered by MMDs, as well as issue
+frequency to protect privacy.
+A valid argument against exposing any plaintext to the network is protocol
+ossification. We emphasize that our design motivates why packet processors
+should fail open:
+  otherwise there is no aggregation indistinguishability.
+Note that there are other plaintext sources than CT-over-DNS that could be
+aggregated.  However, if these sources require stream-reassembly it is
+generally hard to process in languages such as P4 and XDP~\cite{ctga-thesis}.
+
+\subsection{Indistinguishability and Herd Immunity} \label{ctga:sec:discussion:herd}
+An attacker that gains control over a CT log is bound to be more risk averse
+than an attacker that compromises a CA. There is an order of magnitude fewer
+logs than CAs, and client vendors are likely going to be exceptionally picky
+when it comes to accepted and rejected logs.
+We have already seen examples of this, including Google Chrome disqualifying
+logs that made mistakes:
+  Izenpe used the same key for production and testing~\cite{izenpe}, and
+  Venafi suffered from an unfortunate power outage~\cite{venafi}.
+Risk averse attackers combined with packet processors that are aggregation
+indistinguishable may lead to \emph{herd immunity}: despite a significant
+fraction of clients that lack aggregators, indirect protection may be provided
+because the risk of eventual detection is unacceptable to many attackers. Hof
+and Carle~\cite{hof-cross-logging} and Nordberg \emph{et~al.}~\cite{ietf-gossip}
+discussed herd immunity~briefly~before~us.
+While herd immunity is promising, it should be noted that aggregation
+distinguishable packet processors at \emph{the edge of a network topology} may
+be acceptable for some.  In other words, if an aggregator cannot be circumvented
+but it is detectable split-views would still be deterred against covered
+clients if the challenger is off-path.
diff --git a/summary/src/ctga/src/implementation.tex b/summary/src/ctga/src/implementation.tex
new file mode 100644
index 0000000..9a35cfe
--- /dev/null
+++ b/summary/src/ctga/src/implementation.tex
@@ -0,0 +1,82 @@
+\section{Distinguishability Experiments} \label{ctga:sec:implementation}
+There are many different ways to implement the aggregation step. We decided to
+use P4 and XDP because a large variety of programmable
+packet processors support these languages (Section~\ref{ctga:sec:background:pdp}).
+The aggregated plaintext source is assumed to be CT-over-DNS~\cite{ct-over-dns},
+which means that a client obtains STHs by fetching IN TXT resource records.
+Since languages for programmable packet processors are somewhat restricted,
+we facilitated packet processing by requiring that at most one STH is sent per
+UDP packet.
+This is reasonable because logs should only have one \emph{most recent} STH.
+A DNS STH is roughly 170~bytes without any packet headers and
+should normally not be fragmented, but to ensure that we do not miss any
+intentionally fragmented STHs we aggregate every tiny fragment. We did not
+implement the challenging component because it is relatively easy given
+an existing off-path. Should any scalability issue arise for the challenger
+there is nothing that prevents a distributed front-end that processes the
+aggregated material before storage. Storage is not an issue because there are
+only a limited amount of unique STHs per day and log
+  (one new STH per hour is a common policy, and browsers recognize $\approx 40$
+  logs).
+Further implementation details can be found
+online~\cite{github,full-version}.
+
+\subsection{Setup}
+We used a test-bed consisting of
+  a traffic generator,
+  a traffic receiver, and
+  an aggregating target in between.
+The first target is a P4-enabled NetFPGA SUME board that runs an adapted version
+of our P4 reference implementation.
+The second target is a net-next kernel v4.17.0-rc6 Linux machine that runs XDP
+on one core with
+  a 10~Gb SFP+ X520 82599ES Intel card,
+  a $3.6$~GHz Intel Core i7-4790 CPU, and
+  16~GB of RAM at 1600~MHz (Hynix/Hyundai).
+We would like to determine whether there are any aggregation distinguishers as
+the fraction of STHs (experiment 1) and tiny fragments (experiment 2) in the
+traffic is increased from 0--100\%, i.e., does performance degrade as a
+function of STH-related rate? Non-fragmented STH packets are
+411~bytes
+	(we used excessively large DNS headers to maximize the packet parsing
+	overhead),
+and tiny fragments are 64~bytes. All background traffic have the same packet
+sizes but is not deemed STH-related.
+
+\subsection{Results}
+Figure~\ref{ctga:fig:perf-p4} shows throughput as a function of STH-related rate for
+the P4-enabled NetFPGA. While we were unable to observe any distinguisher between
+normal routing and the edge case of 100\% aggregation for
+non-fragmented STH packets, there is a small constant throughput difference for
+tiny fragments ($7.5$~Kbps). This is a non-negligible \emph{program
+distinguisher} if a packet processor is physically isolated as in our benchmark,
+i.e., something other than a routing program is running but it is not
+necessarily an aggregator because performance does not degrade as a function
+of increased STH-related rate. However, we found such degradation behaviour for the
+single-core XDP case (Figure~\ref{ctga:fig:perf-xdp}). If line-speed is higher than
+2~Gbps, STHs could be aggregated probabilistically or traffic could be load-%
+balanced to \emph{overcome} this issue.
+\begin{figure}[!t]
+  \centering
+  \begin{subfigure}[b]{.8\textwidth}
+	  \includegraphics[width=\textwidth]{src/ctga/img/perf-netfpga}
+    \caption{P4 NetFPGA}
+    \label{ctga:fig:perf-p4}
+  \end{subfigure}
+
+  \begin{subfigure}[b]{.8\textwidth}
+    \includegraphics[width=\textwidth]{src/ctga/img/perf-xdp}
+    \caption{XDP on a single core}
+    \label{ctga:fig:perf-xdp}
+  \end{subfigure}
+  \caption{%
+    Throughput as a function of STH-related traffic that is aggregated.
+  }
+  \label{ctga:fig:perf}
+\end{figure}
+
+\subsection{Lessons Learned}
+P4-NetFPGA provides aggregation indistinguishability regardless of STH load.
+For XDP, it depends on the scenario: what is the line-rate criteria and how many
+cores are available. For example, five cores support 10~Gbps aggregation
+indistinguishability without probabilistic filtering or load balancing.
diff --git a/summary/src/ctga/src/introduction.tex b/summary/src/ctga/src/introduction.tex
new file mode 100644
index 0000000..248785e
--- /dev/null
+++ b/summary/src/ctga/src/introduction.tex
@@ -0,0 +1,93 @@
+\section{Introduction} \label{ctga:sec:introduction}
+The HyperText Transfer Protocol Secure (HTTPS) ecosystem is going through a paradigm shift. As opposed to blindly
+trusting that Certificate Authorities (CAs) only issue certificates to the
+rightful domain owners%
+  ---a model known for its weakest-link security~\cite{ca-ecosystem}---%
+transparency into the set of issued certificates is incrementally being
+required by major browser vendors~\cite{apple-ct,google-ct}.  This transparency
+is forced and takes the form of Certificate Transparency (CT) logs:
+  the idea is to reject any TLS certificate that have yet to be publicly logged,
+  such that domain owners can monitor the logs for client\mbox{-}accepted certificates
+	to \emph{detect} certificate mis-issuance \emph{after the fact}~\cite{ct}.
+While the requirement of certificate logging is a significant improvement to the
+HTTPS ecosystem, the underlying problem of trusting CAs cannot be solved by the
+status quo of trusted CT logs (described further in
+Section~\ref{ctga:sec:background:ct}). Therefore, it is paramount that nobody
+needs to trust these logs once incremental deployments are matured.
+
+CT is formalized and cryptographically verifiable~\cite{ct-formal}, supporting
+inclusion and consistency proofs.
+This means that a client can verify whether a log is
+operated correctly:
+  said certificates are included in the log, and
+  nothing is being removed or modified.
+Despite the ability to cryptographically verify these two properties, there are
+no assurances that everybody observes \emph{the same
+log}~\cite{chuat-gossip,ct}.  For example, certificate mis-issuance would
+not be detected by a domain owner that monitors the logs if fraudulently issued
+certificates are shown to the clients selectively.  A log that serves different
+versions of itself is said to present a \emph{split view}~\cite{ietf-gossip}.
+Unless such log misbehaviour can be detected, we must trust it not to happen.
+
+The solution to the split viewing problem is a gossip mechanism which ensures
+that everybody observes \emph{the same} consistent log~\cite{ct}.  This
+assumption is simple in theory but remarkably hard in practice due to
+	client privacy,
+	varying threat models, and
+	deployment challenges~\cite{ietf-gossip,cosi}.
+While Google started on a package that supports
+	minimal gossip~\cite{minimal-gossip} and
+	the mechanisms of Nordberg \emph{et~al.}~\cite{ietf-gossip},
+there is ``next to no deployment in the wild''~\cite{little-or-no-gossip}.
+To this end, we propose a gossip mechanism that helps detecting split-view
+attacks retroactively based on the idea of packet processors, such as routers
+and middleboxes, that \emph{aggregate} Signed Tree Heads (STHs)---succinct
+representations of the logs' states---that are exposed to the network \emph{in
+plaintext}.
+The aggregated STHs are then used to challenge the logs to prove consistency
+via an off-path, such that the logs cannot distinguish between challenges that
+come from different aggregators.  Given this indistinguishability assumption, it
+is non-trivial to serve a consistent split-view to an unknown
+location~\cite{mpaudit}.  Thus, all aggregators must be on the same view, and
+accordingly all clients that are covered by these aggregators must also be on
+the same view \emph{despite not doing any explicit gossip themselves} because
+gossip is provided as-a-service by the network.  An isolated client (i.e.,
+untrusted network path to the aggregator) is notably beyond reach of any
+retroactive gossip~\cite{cosi}.
+
+The premise of having STHs in plaintext is controversial given current trends to
+encrypt transport protocols, which is otherwise an approach that combats
+inspection of network traffic and protocol
+ossification~\cite{HTTPSintercept,TCPoss}.  We argue that keeping gossip
+related material in plaintext to support aggregation-based gossip comes with few
+downsides though:
+  it is easy to implement,
+  there are no major negative privacy impacts, and
+  it would offer significant protection for a large portion of the Internet
+    with a realistic threat model \emph{despite relatively small deployment
+    efforts}.
+The three main limitations are
+  no protection against isolated clients,
+  reliance on clients that fetch STHs from the logs in plaintext, and
+  possible concerns surrounding protocol ossification~\cite{TCPoss}.
+Our contributions are:
+\begin{itemize}
+  \item Design and security considerations for a network-based gossip mechanism
+    that passively aggregates STHs to verify log consistency off-path
+    (Section~\ref{ctga:sec:design}).
+  \item Generic implementations of the aggregation step using P4~\cite{p4} and
+    XDP~\cite{xdp} for plaintext STHs, supporting line-speed packet
+    processing on systems that range from switches, routers, network interface
+    cards, and Linux (Section~\ref{ctga:sec:implementation}).
+  \item A simulation based on RIPE Atlas measurements that evaluate the impact
+    of deploying aggregation-based gossip at ASes and IXPs. Our evaluation shows
+    that incremental roll-out at well-connected locations would protect a
+    significant portion of all Internet clients from undetected split views
+    (Section~\ref{ctga:sec:measurements}).
+\end{itemize}
+
+Besides the sections referenced above, the paper introduces necessary
+background in Section~\ref{ctga:sec:background} and provides discussion, conclusion,
+and future work in Sections~\ref{ctga:sec:related}--\ref{ctga:sec:conclusion}.
+A full version with additional implementation details is available
+online~\cite{full-version}.
diff --git a/summary/src/ctga/src/measurements.tex b/summary/src/ctga/src/measurements.tex
new file mode 100644
index 0000000..ee0ea89
--- /dev/null
+++ b/summary/src/ctga/src/measurements.tex
@@ -0,0 +1,85 @@
+\section{Estimated Impact of Deployment} \label{ctga:sec:measurements}
+We conducted 20 daily traceroute measurements during spring 2018 on the RIPE
+Atlas platform to evaluate the effectiveness of aggregation-based gossip. The
+basic idea is to look at client coverage as central ASes and IXPs aggregate
+STHs. If any significant client coverage can be achieved, the likelihood of
+pulling off an undetected split-view will be small.
+
+\subsection{Setup}
+We scheduled RIPE Atlas measurements from roughly 3500 unique ASes that
+represent 40\% of the IPv4 space, trace-routing Google's authoritative
+CT-over-DNS server and NORDUnet's CT log to simulate clients that fetch DNS STHs
+in plaintext. Each traceroute result is a list of
+traversed IPs, and it can be translated into the corresponding ASes and IXPs
+using public data sets~\cite{pub-routeviews,pub-caida}.
+In other words, traversed ASes and IXPs can be determined for each probe. Since
+we are interested in client coverage as ASes and IXPs aggregate, each
+probe is weighted by the IPv4 space of its AS. While an IP address is an
+imperfect representation of a client, e.g., an IP may be unused or reused, it
+gives a decent idea of how significant it is to cover a given probe.
+
+\subsection{Results}
+Figure~\ref{ctga:fig:pl} shows AS/IXP path length and stability from the probes to
+the targets.
+If the AS path length is one, a single AS is traversed \emph{before reaching the
+target}. It is evident that an AS path tends to be one hop longer
+towards NORDUnet than Google because there is a rough off-by-one offset on the
+x-axis.
+A similar trend of greater path length towards NORDUnet can be observed for
+IXPs. For example,
+  74.0\% of all paths traversed no IXP towards Google, but
+  58.5\% of all paths traversed a single IXP towards NORDUnet.
+These results can be explained by infrastructural differences of our targets:
+  since Google is a worldwide actor an average path should be shorter than
+  compared to a region-restricted actor like NORDUnet.
+We also observed that AS and IXP paths tend to be quite stable over 20~days
+	(the duration of our measurements).
+I.e., if AS $a$ and $b$ are traversed it is unlikely to suddenly be
+routed via AS~$c$.
+\begin{figure}[!t]
+  \centering
+  \includegraphics[width=0.5\columnwidth]{src/ctga/img/pl}%
+  \includegraphics[width=0.5\columnwidth]{src/ctga/img/ps}
+  \caption{%
+    Path length and stability towards Google and NORDUnet.
+  }
+  \label{ctga:fig:pl}
+\end{figure}
+
+Figure~\ref{ctga:fig:wcov} shows coverage of the RIPE Atlas network as $1...n$ actors
+aggregate STHs. For example, 100\% and 50\% coverage means that at least 40\%
+and 20\% of the full IPv4 space is covered. The aggregating ASes and IXPs were
+selected based on the most commonly traversed vantage points in
+our measurements (Pop), as well as CAIDA's largest AS ranking~\cite{caida}.
+We found that more coverage is achieved when targeting
+NORDUnet than Google. This is expected given that the paths tend to be longer.
+If CAIDA's top-32 enabled aggregation, the coverage would be significant
+towards Google (31.6\%)~and~NORDUnet~(58.1\%).
+
+\begin{figure}[!t]
+  \centering
+  \includegraphics[width=0.5\columnwidth]{src/ctga/img/wcov-goo}%
+  \includegraphics[width=0.5\columnwidth]{src/ctga/img/wcov-nor}
+  \caption{%
+    Coverage as a function of aggregation opt-in.
+  }
+  \label{ctga:fig:wcov}
+\end{figure}
+
+\subsection{Lessons Learned}
+A vast majority of all clients traverse \emph{at least} one AS that could
+aggregate. It is relatively rare to traverse IXPs towards Google but not
+NORDUnet. We also learned that paths tends to be stable, which means that the
+time until split view detection would be at least 20 days \emph{if} it is
+possible to find an unprotected client. This increases the importance of
+aggregation indistinguishability.
+Finally, we identified vantage points that are commonly traversed using Pop, and
+these vantage points are represented well by CAIDA's independent AS ranking.
+Little opt-in from ASes and IXPs provides significant coverage against an
+attacker that is relatively close to a client
+  (cf.\ world-wide infrastructure of Google).
+Although we got better coverage for NORDUnet, any weak attacker would approach
+Google's coverage by renting infrastructure nearby.
+Any weak attacker could also circumvent IXP aggregation by detecting the IXP
+itself~\cite{ixp-detect}.  As such, top-ranked AS aggregation should give
+the best split-view protection.
diff --git a/summary/src/ctga/src/ref.bib b/summary/src/ctga/src/ref.bib
new file mode 100644
index 0000000..5aa2314
--- /dev/null
+++ b/summary/src/ctga/src/ref.bib
@@ -0,0 +1,573 @@
+@inproceedings{ixp-detect,
+  author    = {George Nomikos and Xenofontas A. Dimitropoulos},
+  title     = {{traIXroute}: Detecting {IXPs} in traceroute paths},
+  booktitle = {PAM},
+  year      = {2016},
+}
+
+@mastersthesis{ctga-thesis,
+  author = {Rasmus Dahlberg},
+  title  = {Aggregating {Certificate Transparency} Gossip Using Programmable Packet Processors},
+  school = {Karlstad University},
+  year   = {2018},
+  type   = {Master Thesis},
+}
+
+@article{laurie,
+  author    = {Ben Laurie},
+  title     = {{Certificate Transparency}},
+  journal   = {{ACM} Queue},
+  volume    = {12},
+  number    = {8},
+  year      = {2014},
+}
+
+@misc{minimal-gossip,
+  author = {David Drysdale},
+  title = {Minimal Gossip},
+  howpublished = {\url{https://github.com/google/certificate-transparency-go/blob/master/gossip/minimal}, accessed 2019-09-04},
+}
+
+@misc{google-ct,
+  author = {Devon O'Brien},
+  title = {{Certificate Transparency} Enforcement in {Google Chrome}},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/wHILiYf31DE/iMFmpMEkAQAJ}, accessed 2019-09-04},
+}
+
+@misc{apple-ct,
+  author = {Apple Inc.},
+  title = {Apple's {Certificate Transparency} Policy},
+  howpublished = {\url{https://support.apple.com/en-us/HT205280}, accessed 2019-09-04},
+}
+
+@inproceedings{h2,
+  author    = {Mark O'Neill and
+               Scott Heidbrink and
+               Scott Ruoti and
+               Jordan Whitehead and
+               Dan Bunker and
+               Luke Dickinson and
+               Travis Hendershot and
+               Joshua Reynolds and
+               Kent E. Seamons and
+               Daniel Zappala},
+  title     = {{TrustBase}: An Architecture to Repair and Strengthen Certificate-Based Authentication},
+  booktitle = {USENIX Security},
+  year      = {2017},
+}
+
+@inproceedings{h1,
+  author    = {Adam Bates and
+               Joe Pletcher and
+               Tyler Nichols and
+               Braden Hollembaek and
+               Dave Tian and
+               Kevin R. B. Butler and
+               Abdulrahman Alkhelaifi},
+  title     = {Securing {SSL} Certificate Verification through Dynamic Linking},
+  booktitle = {CCS},
+  year      = {2014},
+}
+
+@inproceedings{catena,
+  author    = {Alin Tomescu and Srinivas Devadas},
+  title     = {Catena: Efficient Non-equivocation via {Bitcoin}},
+  booktitle = {IEEE S\&P},
+  year      = {2017},
+}
+
+@inproceedings{ct-pir,
+  author    = {Wouter Lueks and Ian Goldberg},
+  title     = {Sublinear Scaling for Multi-Client Private Information Retrieval},
+  booktitle = {FC},
+  year      = {2015},
+}
+
+@techreport{ct,
+  author      = {Ben Laurie and Adam Langley and Emilia Kasper},
+  title       = {{Certificate Transparency}},
+  type        = {RFC},
+  institution = {IETF},
+  number      = {6962},
+  year        = {2013},
+}
+
+@misc{vds,
+  author        = {Adam Eijdenberg and Ben Laurie and Al Cutter},
+  title         = {Verifiable Data Structures},
+  howpublished  = {\url{https://github.com/google/trillian/blob/master/docs/VerifiableDataStructures.pdf}, accessed 2019-09-04},
+}
+
+@inproceedings{transparency-overlays,
+  author    = {Melissa Chase and Sarah Meiklejohn},
+  title     = {Transparency Overlays and Applications},
+  booktitle = {CCS},
+  year      = {2016},
+}
+
+@inproceedings{coniks,
+  author    = {Marcela S. Melara and
+    Aaron Blankstein and
+    Joseph Bonneau and
+    Edward W. Felten and
+    Michael J. Freedman},
+  title     = {{CONIKS}: Bringing Key Transparency to End Users},
+  booktitle = {USENIX Security},
+  year      = {2015},
+}
+
+@inproceedings{ca-ecosystem,
+  author    = {Zakir Durumeric and
+    James Kasten and
+    Michael Bailey and
+    J. Alex Halderman},
+  title     = {Analysis of the {HTTPS} Certificate Ecosystem},
+  booktitle = {IMC},
+  year      = {2013},
+}
+
+@inproceedings{little-or-no-gossip,
+  author    = {Oliver Gasser and
+    Benjamin Hof and
+    Max Helm and
+    Maciej Korczynski and
+    Ralph Holz and
+    Georg Carle},
+  title     = {In Log We Trust: Revealing Poor Security Practices with {Certificate Transparency} Logs and Internet Measurements},
+  booktitle = {PAM},
+  year      = {2018},
+}
+
+@techreport{ietf-gossip,
+  author      = {Linus Nordberg and Daniel Kahn Gillmor and Tom Ritter},
+  title       = {Gossiping in {CT}},
+  number      = {draft-ietf-trans-gossip-05},
+  type        = {Internet-draft},
+  institution = {IETF},
+  year        = {2018},
+}
+
+@inproceedings{chuat-gossip,
+  author    = {Laurent Chuat and
+   Pawel Szalachowski and
+   Adrian Perrig and
+   Ben Laurie and
+   Eran Messeri},
+  title     = {Efficient Gossip Protocols for Verifying the Consistency of
+    Certificate Logs},
+  booktitle = {CNS},
+  year      = {2015},
+}
+
+@misc{ct-honey-bee,
+  author    = {Andrew Ayer},
+  title     = {Lightweight Program that Pollinates {STHs} Between {Certificte
+    Transparency} Logs and Auditors},
+  howpublished = {\url{https://github.com/SSLMate/ct-honeybee}, accessed 2019-09-04},
+}
+
+@article{hof-cross-logging,
+  author    = {Benjamin Hof and Georg Carle},
+  title     = {Software Distribution Transparency and Auditability},
+  journal   = {CoRR},
+  volume    = {abs/1711.07278},
+  year      = {2017},
+}
+
+@techreport{ietf-cross-logging,
+  author      = {Benjamin Hof},
+  title       = {{STH} Cross Logging},
+  institution = {IETF},
+  number      = {draft-hof-trans-cross-00},
+  type        = {Internet-draft},
+  year        = {2017},
+}
+
+@misc{google-gossip,
+  author      = {Ryan Sleevi and Eran Messeri},
+  title       = {{Certificate Transparency} in {Chrome}: Monitoring {CT} Logs consistency},
+  howpublished = {\url{https://docs.google.com/document/d/1FP5J5Sfsg0OR9P4YT0q1dM02iavhi8ix1mZlZe_z-ls/edit?pref=2&pli=1}, accessed 2019-09-04},
+}
+
+@inproceedings{cosi,
+  author    = {Ewa Syta and
+               Iulia Tamas and
+               Dylan Visher and
+               David Isaac Wolinsky and
+               Philipp Jovanovic and
+               Linus Gasser and
+               Nicolas Gailly and
+               Ismail Khoffi and
+               Bryan Ford},
+  title     = {Keeping Authorities ``Honest or Bust'' with Decentralized Witness Cosigning},
+  booktitle = {IEEE S\&P},
+  year      = {2016},
+}
+
+@inproceedings{mpaudit,
+  author    = {Lachlan J. Gunn and Andrew Allison and Derek Abbott},
+  title     = {Safety in Numbers: Anonymization Makes Keyservers Trustworthy},
+  booktitle = {HotPETs},
+  year      = {2017},
+}
+
+@inproceedings{doublecheck,
+  author    = {Mansoor Alicherry and Angelos D. Keromytis},
+  title     = {{DoubleCheck}: Multi-path Verification Against Man-in-the-Middle
+    Attacks},
+  booktitle = {ISCC},
+  year      = {2009},
+}
+
+@inproceedings{perspectives,
+  author    = {Dan Wendlandt and David G. Andersen and Adrian Perrig},
+  title     = {Perspectives: Improving {SSH}-Style Host Authentication with
+    Multi-Path Probing},
+  booktitle = {USENIX ATC},
+  year      = {2008},
+}
+
+@misc{ct-over-dns,
+  author      = {Ben Laurie},
+  title       = {{Certificate Transparency} Over {DNS}},
+  howpublished = {\url{https://github.com/google/certificate-transparency-rfcs/blob/master/dns}, accessed 2019-09-04},
+}
+
+%%% Results: Characteristics of fragment traffic (§4c)
+% Figures 12--13 show real-world measurements that __very__ few correct
+% fragmentation series are less than 576 bytes.
+%
+% 93 series less than 256 bytes were observed, and all but two appeared to be
+% errors.
+%
+% ``MTUs lower than 576 bytes are generally evidence of mistaken or misguided
+% configuration''.
+%%%
+@article{frag-study-02,
+  author    = {Colleen Shannon and David Moore and Kimberly C. Claffy},
+  title     = {Beyond Folklore: Observations on Fragmented Traffic},
+  journal   = {IEEE/ACM Trans.\ Netw.},
+  volume    = {10},
+  number    = {6},
+  year      = {2002},
+}
+
+%%% page 60
+% ``Since nearly all networks in the Internet currently support an MTU of 576
+% or greater, we strongly recommend the use of 576 for datagrams sent to
+% non-local networks''
+%%%
+@techreport{min-mtu,
+  author      = {Robert Braden},
+  title       = {Requirements for {Internet} hosts---Communication Layers},
+  institution = {IETF},
+  type        = {RFC},
+  number      = {1122},
+  year        = {1989},
+}
+
+@inproceedings{xdp,
+  author    = {Toke H{\o}iland{-}J{\o}rgensen and
+               Jesper Dangaard Brouer and
+               Daniel Borkmann and
+               John Fastabend and
+               Tom Herbert and
+               David Ahern and
+               David Miller},
+  title     = {The eXpress data path: fast programmable packet processing in the operating system kernel},
+  booktitle = {CoNEXT},
+  year      = {2018},
+}
+
+@inproceedings{TCPoss,
+  author    = {Michio Honda and
+               Yoshifumi Nishida and
+               Costin Raiciu and
+               Adam Greenhalgh and
+               Mark Handley and
+               Hideyuki Tokuda},
+  title     = {Is it Still Possible to Extend {TCP}?},
+  booktitle = {IMC},
+  year      = {2011},
+}
+
+@inproceedings{HTTPSintercept,
+  author    = {Zakir Durumeric and
+               Zane Ma and
+               Drew Springall and
+               Richard Barnes and
+               Nick Sullivan and
+               Elie Bursztein and
+               Michael Bailey and
+               J. Alex Halderman and
+               Vern Paxson},
+  title     = {The Security Impact of {HTTPS} Interception},
+  booktitle = {NDSS},
+  year      = {2017},
+}
+
+@inproceedings{mpquic,
+  author    = {Quentin De Coninck and Olivier Bonaventure},
+  title     = {Multipath {QUIC}: Design and Evaluation},
+  booktitle = {CoNEXT},
+  year      = {2017},
+}
+
+@inproceedings{tor,
+  author    = {Roger Dingledine and Nick Mathewson and Paul F. Syverson},
+  title     = {Tor: The Second-Generation Onion Router},
+  booktitle = {USENIX Security},
+  year      = {2004},
+}
+
+@inproceedings{androidlibs,
+  author    = {Michael Backes and Sven Bugiel and Erik Derr},
+  title     = {Reliable Third-Party Library Detection in {Android} and its Security Applications},
+  booktitle = {{CCS}},
+  year      = {2016},
+}
+
+@inproceedings{androidlibs2,
+  author    = {Erik Derr and
+    Sven Bugiel and
+    Sascha Fahl and
+    Yasemin Acar and
+    Michael Backes},
+  title     = {Keep me Updated: An Empirical Study of Third-Party Library
+    Updatability on {Android}},
+  booktitle = {CCS},
+  year      = {2017},
+}
+
+@inproceedings{langely-quic,
+  author    = {Adam Langley and
+               Alistair Riddoch and
+               Alyssa Wilk and
+               Antonio Vicente and
+               Charles Krasic and
+               Dan Zhang and
+               Fan Yang and
+               Fedor Kouranov and
+               Ian Swett and
+               Janardhan R. Iyengar and
+               Jeff Bailey and
+               Jeremy Dorfman and
+               Jim Roskind and
+               Joanna Kulik and
+               Patrik Westin and
+               Raman Tenneti and
+               Robbie Shade and
+               Ryan Hamilton and
+               Victor Vasiliev and
+               Wan{-}Teh Chang and
+               Zhongyi Shi},
+  title     = {The {QUIC} Transport Protocol: Design and Internet-Scale Deployment},
+  booktitle = {{SIGCOMM}},
+  year      = {2017},
+}
+
+
+@article{sdn,
+  author    = {Nick Feamster and
+    Jennifer Rexford and
+    Ellen W. Zegura},
+  title     = {The road to {SDN:} An intellectual history of programmable networks},
+  journal   = {CCR},
+  volume    = {44},
+  number    = {2},
+  year      = {2014},
+}
+
+@techreport{ipv6,
+  author        = {Steve Deering and Robert Hinden},
+  title         = {Internet Protocol Version 6 ({IPv6}) specification},
+  type          = {RFC},
+  institution   = {IETF},
+  number        = {8200},
+  year          = {2017},
+}
+
+@inproceedings{ct-formal,
+  author    = {Benjamin Dowling and
+    Felix G{\"{u}}nther and
+    Udyani Herath and
+    Douglas Stebila},
+  title     = {Secure Logging Schemes and {Certificate Transparency}},
+  booktitle = {ESORICS},
+  year      = {2016},
+}
+
+@inproceedings{bpf,
+  author    = {Steven McCanne and Van Jacobson},
+  title     = {The {BSD} Packet Filter: A New Architecture for User-level
+    Packet Capture},
+  booktitle = {Usenix Winter Technical Conference},
+  year      = {1993},
+}
+
+@inproceedings{pisces,
+  author    = {Muhammad Shahbaz and
+               Sean Choi and
+               Ben Pfaff and
+               Changhoon Kim and
+               Nick Feamster and
+               Nick McKeown and
+               Jennifer Rexford},
+  title     = {{PISCES:} A Programmable, Protocol-Independent Software Switch},
+  booktitle = {{ACM} {SIGCOMM}},
+  year      = {2016},
+}
+
+@article{p4,
+  author    = {Pat Bosshart and
+               Dan Daly and
+               Glen Gibb and
+               Martin Izzard and
+               Nick McKeown and
+               Jennifer Rexford and
+               Cole Schlesinger and
+               Dan Talayco and
+               Amin Vahdat and
+               George Varghese and
+               David Walker},
+  title     = {{P4}: Programming Protocol-independent Packet Processors},
+  journal   = {CCR},
+  volume    = {44},
+  number    = {3},
+  year      = {2014},
+}
+
+@inproceedings{rmt,
+ author    = {Pat Bosshart and
+               Glen Gibb and
+               Hun{-}Seok Kim and
+               George Varghese and
+               Nick McKeown and
+               Martin Izzard and
+               Fernando A. Mujica and
+               Mark Horowitz},
+ title      = {Forwarding Metamorphosis: Fast Programmable Match-action Processing in
+  Hardware for {SDN}},
+ booktitle  = {ACM SIGCOMM},
+ year       = {2013},
+} 
+      
+@conference{p4netfpga,
+  author       = {Gordon Brebner},
+  title        = {{P4} for an {FPGA} Target},
+  booktitle    = {P4 Workshop},
+  year         = {2015},
+  note         = {\url{https://p4workshop2015.sched.com/event/3ZQA/p4-for-an-fpga-target}, accessed 2019-09-04},
+}
+
+@misc{p4netronome,
+  title        = {Programming {NFP} with {P4} and {C}},
+  howpublished = {\url{https://www.netronome.com/media/redactor_files/WP_Programming_with_P4_and_C.pdf}, accessed 2019-09-04},
+}
+
+@misc{flexpipe,
+  title        = {Intel Ethernet Switch {FM600} Series: 10/40 {GbE} Low Latency Switching Silicon},
+  howpublished = {\url{https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ethernet-switch-fm6000-series-brief.pdf}, accessed 2019-09-04},
+}
+
+@misc{cavium,
+  title = {Cavium and {XPliant} Introduce a Fully Programmable Switch Silicon Family Scaling to 3.2 Terabits per Second},
+  howpublished = {\url{https://cavium.com/newsevents-cavium-and-xpliant-introduce-a-fully-programmable-switch-silicon-family.html}, accessed 2019-09-04},
+}
+
+@misc{barefoot,
+  title = {Tofino: World's fastest {P4}-programmable Ethernet switch {ASICs}},
+  howpublished = {\url{https://barefootnetworks.com/products/brief-tofino/}, accessed 2019-09-04},
+}
+
+@misc{p4bm,
+	title = {BEHAVIORAL MODEL REPOSITORY},
+  howpublished = {\url{https://github.com/p4lang/behavioral-model}, accessed 2019-09-04},
+}
+
+@misc{p42ebpf,
+  author = {Mihai Budiu},
+  title = {Compiling {P4} to {eBPF}},
+  howpublished = {\url{https://github.com/iovisor/bcc/tree/master/src/cc/frontends/p4}, accessed 2019-09-04},
+}
+
+@misc{fbi-apple,
+  author = {EFF},
+  title = {Apple Challenges {FBI}: All Writs Act Order ({CA})},
+  howpublished = {\url{https://www.eff.org/cases/apple-challenges-fbi-all-writs-act-order}, accessed 2019-09-04},
+}
+
+@misc{ver-sth,
+  author = {Linus Nordberg},
+  title = {{Re: [Trans] Providing} the history of {STHs} a log has issued (in 6962-bis)},
+  howpublished = {\url{https://mailarchive.ietf.org/arch/msg/trans/JbFiwO90PjcYzXrEgh-Y7bFG5Fw}, accessed 2019-09-04},
+} 
+
+@techreport{dot,
+  author      = {Sara Dickinson and Dan Gillmor and Tirumaleswar Reddy},
+  title       = {Usage Profiles for {DNS} over {TLS} and {DNS} over {DTLS}},
+  type        = {RFC},
+  institution = {IETF},
+  number      = {8310},
+  year        = {2016},
+}
+
+@techreport{doh,
+  author      = {Paul Hoffman and Patrick McManus},
+  title       = {{DNS} Queries over {HTTPS (DoH)}},
+  type        = {RFC},
+  institution = {IETF},
+  number      = {8484},
+  year        = {2018},
+}
+
+@misc{izenpe,
+  author = {Ryan Sleevi},
+  title = {Upcoming {CT} Log Removal: {Izenpe}},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/qOorKuhL1vA}, accessed 2019-09-04},
+}
+
+@misc{venafi,
+  author = {Ryan Sleevi},
+  title = {Upcoming Log Removal: {Venafi CT} Log Server},
+  note = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/KMAcNT3asTQ}, accessed 2019-09-04},
+}
+
+@misc{caida,
+  author = {CAIDA},
+  title = {{ARank}},
+  note = {\url{http://as-rank.caida.org/}, accessed 2019-09-04},
+}
+
+@article{full-version,
+  author    = {Rasmus Dahlberg and
+               Tobias Pulls and
+               Jonathan Vestin and
+               Toke H{\o}iland{-}J{\o}rgensen and
+               Andreas Kassler},
+  title     = {Aggregation-Based Gossip for Certificate Transparency},
+  journal   = {CoRR},
+  volume    = {abs/1806.08817},
+  year      = {2019},
+}
+
+@misc{pub-caida,
+  author = {CAIDA},
+  title = {The {CAIDA UCSD IXPs} Dataset},
+  howpublished = {\url{https://www.caida.org/data/ixps/}, accessed 2019-09-04},
+  month = {February},
+  year = {2018},
+}
+
+@misc{pub-routeviews,
+  title = {The {Routeviews MRT format RIBs and UPDATEs} Dataset},
+  howpublished = {\url{http://archive.routeviews.org/bgpdata/2018.03/RIBS/}, accessed 2019-09-04},
+  month = {March},
+  year = {2018},
+}
+
+@misc{github,
+  title = {Paper artifact},
+  year = {2018},
+  howpublished = {\url{https://github.com/rgdd/ctga}},
+}
diff --git a/summary/src/ctga/src/related.tex b/summary/src/ctga/src/related.tex
new file mode 100644
index 0000000..15d7fad
--- /dev/null
+++ b/summary/src/ctga/src/related.tex
@@ -0,0 +1,67 @@
+\section{Related Work} \label{ctga:sec:related}
+Earlier approaches towards CT gossip are categorized as \emph{proactive} or
+\emph{retroactive} in Figure~\ref{ctga:fig:related}. We consider an approach proactive
+if gossip takes place \emph{before} SCTs and/or STHs reach the broader audience
+of clients.
+Syta \emph{et~al.} proposed proactive witness cosigning, in which an STH is
+collectively signed by a \emph{large} number of witnesses and at most a fraction
+of those can be faulty to ensure that a benevolent witness observed an
+STH~\cite{cosi}.  STH
+cross-logging~\cite{minimal-gossip,ietf-cross-logging,hof-cross-logging}
+is similar in that an STH must be proactively disclosed in
+another transparency log to be trusted, avoiding any additional cosigning
+infrastructure at the cost of reducing the size and diversity of the witnessing
+group.
+Tomescu and Devadas~\cite{catena} suggested a similar cross-logging scheme,
+but split-view detection is instead reduced to the difficulty of forking the
+Bitcoin blockchain
+  (big-O cost of downloading all block headers as a TLS client).
+The final proactive approach is STH pushing, where a trusted third-party
+pushes the same verified STH history to a base of clients~\cite{google-gossip}.
+\begin{figure}[!t]
+  \centering
+  \input{src/ctga/img/related.tex}
+  \caption{%
+    A categorization of approaches towards CT gossip.
+  }
+  \label{ctga:fig:related}
+\end{figure}
+
+We consider a gossip mechanism retroactive if gossip takes place \emph{after}
+SCTs and/or STHs reach the broader audience of clients.
+Chuat \emph{et~al.} proposed that TLS clients and TLS servers be modified to
+pool exchanged STHs and relevant consistency proofs~\cite{chuat-gossip}.
+Nordberg \emph{et~al.} continued this line of work, suggesting privacy-%
+preserving client-server pollination of fresh STHs~\cite{ietf-gossip}. Nordberg
+\emph{et~al.} also proposed that clients feedback SCTs and certificate chains on
+every server revisit, and that trusted auditor relationships could be engaged if
+privacy need not be protected.
+The latter is somewhat similar to the formalized client-monitor gossip of
+Chase and Meiklejohn~\cite{transparency-overlays}, as well as the CT honey bee
+project where a client process fetches and submits STHs to a pre-%
+compiled list of auditors~\cite{ct-honey-bee}.
+Laurie suggested that a client can resolve privacy-sensitive SCTs to privacy-%
+insensitive STHs via DNS (which are easier to gossip)~\cite{ct-over-dns}.
+Private information retrievals could likely achieve something similar~\cite{ct-pir}.
+Assuming that TLS clients are indistinguishable from one another, split-view
+detection could also be implicit as proposed by Gunn \emph{et~al.} for the
+verifiable key-value store CONIKS~\cite{mpaudit,coniks}.
+
+Given that aggregation-based gossip takes place after an STH is issued, it is a
+retroactive approach. As such, we cannot protect an isolated client from split-%
+views~\cite{cosi}. Similar to STH pooling and STH pollination, we rely on
+client-driven communication and an existing infrastructure of packet processors
+to aggregate.
+Our off-path verification is
+based on the same multi-path probing and indistinguishability assumptions as
+Gunn \emph{et~al.}~\cite{doublecheck,mpaudit,perspectives}. Further, given that
+aggregation is application neutral and deployable on hosts, it could provide
+gossip \emph{for} the CT honey bee project (assuming plaintext STHs) and any
+other transparency application like Trillian~\cite{vds}. Another benefit when
+compared to browsing-centric and vendor-specific approaches is that a plethora
+of HTTPS clients are covered, ranging from niche web browsers to command line
+tools and embedded libraries that are vital to protect but yet lack the
+resources of major browser vendors~\cite{androidlibs,androidlibs2}.
+Our approach coexists well with witness cosigning and cross-logging due to
+different threat models, but not necessarily STH pushing if the secure
+channel is encrypted (no need to fetch what a trusted party provides).
diff --git a/summary/src/ctor/.gitignore b/summary/src/ctor/.gitignore
new file mode 100644
index 0000000..8bb88c8
--- /dev/null
+++ b/summary/src/ctor/.gitignore
@@ -0,0 +1,9 @@
+main.pdf
+*.blg
+*.bbl
+*.fls
+*.fdb_latexmk
+*.log
+*.out
+*.aux
+*.swp
diff --git a/summary/src/ctor/img/design-full.pdf b/summary/src/ctor/img/design-full.pdf
new file mode 100644
index 0000000..5602116
--- /dev/null
+++ b/summary/src/ctor/img/design-full.pdf
diff --git a/summary/src/ctor/img/design-incremental.pdf b/summary/src/ctor/img/design-incremental.pdf
new file mode 100644
index 0000000..7c7160d
--- /dev/null
+++ b/summary/src/ctor/img/design-incremental.pdf
diff --git a/summary/src/ctor/main.tex b/summary/src/ctor/main.tex
new file mode 100644
index 0000000..ac4b505
--- /dev/null
+++ b/summary/src/ctor/main.tex
@@ -0,0 +1,72 @@
+\begin{kaupaper}[
+    author={%
+      \textbf{Rasmus Dahlberg},
+      Tobias Pulls,
+      Tom Ritter, and
+      Paul Syverson
+    },
+    title={%
+      Privacy-Preserving \& Incrementally-Deployable Support for Certificate Transparency in Tor
+    },
+    reference={%
+      PETS (2021)
+    },
+    summary={%
+      One deployment challenge of Certificate Transparency is to ensure that
+      monitors and end-users are engaged in gossip-audit protocols.  This is
+      particularly difficult for end-users because such engagement can harm
+      privacy.  For example, verifying that a certificate is included by
+      fetching an inclusion proof from a log reveals which website was visited.
+      We propose a gradual roll-out of Certificate Transparency in Tor Browser
+      that preserves privacy \emph{due to} and \emph{how we use} the anonymity
+      network Tor.  The complete design holds log operators accountable for
+      certificates they promise to append by having Tor relays fetch inclusion
+      proofs against the same view agreed upon by directory authorities in Tor's
+      consensus.  Found issues (if any) are reported to trusted auditors.  The
+      incremental design side-steps much of the practical deployment effort by
+      replacing the audit-report pattern with cross-logging of certificates in
+      independent logs, thus assuming that at least one log is honest as opposed
+      to no log in the complete design.  All Tor Browser needs to do is verify
+      log signatures and then submit the encountered certificates to randomly
+      selected Tor relays.  Such submissions are probabilistic to balance
+      performance against the risk of eventual detection of log misbehavior.
+      Processing of the submitted certificates is also randomized to reduce
+      leakage of real-time browsing patterns, something Tor Browser cannot do on
+      its own due to criteria like disk avoidance and the threat model for
+      wanting Certificate Transparency in the first place.  We provide a
+      security sketch and estimate performance overhead based on Internet
+      measurements.
+    },
+    participation={\vspace{-.25cm}
+      I had the initial idea and was the main driver to move the work forward,
+      first in discussion with Tobias and then together with Tom and Paul.
+    },
+    label={
+      paper:ctor
+    },
+]
+  \maketitle
+  \begin{abstract}
+    \input{src/ctor/src/abstract}
+  \end{abstract}
+  
+  \input{src/ctor/src/introduction}
+  \input{src/ctor/src/background}
+  \input{src/ctor/src/adversary}
+  \input{src/ctor/src/design}
+  \input{src/ctor/src/analysis}
+  \input{src/ctor/src/cross-logging}
+  \input{src/ctor/src/performance}
+  \input{src/ctor/src/privacy}
+  \input{src/ctor/src/related}
+  \input{src/ctor/src/conclusion}
+
+  \input{src/ctor/src/acknowledgements}
+  
+  \bibliographystyle{plain}
+  \bibliography{src/ctor/src/ref}
+
+  \begin{appendices}
+    \input{src/ctor/src/appendix}
+  \end{appendices}
+\end{kaupaper}
diff --git a/summary/src/ctor/src/abstract.tex b/summary/src/ctor/src/abstract.tex
new file mode 100644
index 0000000..718c939
--- /dev/null
+++ b/summary/src/ctor/src/abstract.tex
@@ -0,0 +1,30 @@
+\noindent
+The security of the web improved greatly throughout the last couple of years.
+A large majority of the web is now served encrypted as part of HTTPS, and
+web browsers accordingly moved from positive to negative security indicators
+that warn the user if a connection is insecure.  A secure connection requires
+that the server presents a valid certificate that binds the domain name in
+question to a public key.  A certificate used to be valid if signed by a trusted
+Certificate Authority (CA), but web browsers like Google Chrome and
+Apple's Safari have additionally started to mandate Certificate Transparency (CT)
+logging to overcome the weakest-link security of the CA ecosystem.  Tor and the
+Firefox-based Tor Browser have yet to enforce CT.
+
+We present privacy-preserving and incrementally-deployable
+designs that add support for CT in Tor. Our designs go beyond the currently
+deployed CT enforcements that are based on blind trust:
+	if a user that uses Tor Browser is man-in-the-middled over HTTPS,
+	we probabilistically detect and disclose cryptographic evidence of CA and/or
+	CT log misbehavior.
+The first design increment allows Tor to play a vital role in the overall goal
+of CT:
+	detect mis-issued certificates and hold CAs accountable.
+We achieve this by randomly cross-logging a subset of certificates into other CT
+logs.  The final increments hold misbehaving CT logs accountable, initially
+assuming that some logs are benign and then without any such assumption.
+Given that the current CT deployment lacks strong mechanisms to verify if log
+operators play by the rules, exposing misbehavior is important for the web in
+general and not just Tor.  The full design turns Tor into a system for
+maintaining a probabilistically-verified view of the CT log ecosystem available
+from Tor's consensus.  Each increment leading up to it preserves privacy due to
+and how we use Tor.
diff --git a/summary/src/ctor/src/acknowledgements.tex b/summary/src/ctor/src/acknowledgements.tex
new file mode 100644
index 0000000..3bd9f48
--- /dev/null
+++ b/summary/src/ctor/src/acknowledgements.tex
@@ -0,0 +1,7 @@
+\section*{Acknowledgements}
+We would like to thank our anonymous reviewers as well as Linus Nordberg and
+Eric Rescorla for their valuable feedback.
+Rasmus Dahlberg was supported by the Knowledge Foundation of Sweden and the
+Swedish Foundation for Strategic Research,
+Tobias Pulls by the Swedish Internet Foundation, and
+Paul Syverson by the U.S.\ Office of Naval Research (ONR).
diff --git a/summary/src/ctor/src/adversary.tex b/summary/src/ctor/src/adversary.tex
new file mode 100644
index 0000000..a17fd31
--- /dev/null
+++ b/summary/src/ctor/src/adversary.tex
@@ -0,0 +1,76 @@
+\section{Threat Model} \label{ctor:sec:adversary}
+We consider a strong attacker who is targeting all or a subset of users visiting
+a particular website over Tor. It is generally difficult to perform a targeted
+attack on a single particular Tor user because one needs to identify the user's
+connection before performing the attack---something that Tor's
+anonymity properties frustrate.
+However, it is not difficult to perform an attack on all or a subset of unknown
+users of a particular service. A network vantage point to perform such an attack
+is easily obtained by operating an exit relay (for a subset of Tor users) or by
+compromising the network path of multiple exit relays or the final destination.
+Once so positioned, the encrypted network traffic can be intercepted using a
+fraudulent certificate and associated SCTs.  The subsequent attack on decrypted
+network traffic
+may be passive (to gather user credentials or other information) or active.
+Typical examples of active attacks are to change cryptocurrency addresses to
+redirect funds to the attacker or to serve an exploit to the user's browser for
+\emph{user deanonymization}. Without the ability to intercept encrypted traffic,
+these attacks become more difficult as the web moves towards deprecating
+plaintext HTTP.
+
+All of the components of such an attack have been seen in-the-wild
+numerous times. Untargeted attacks on visitors of a particular website
+include Syria's interception of Facebook traffic using a self-signed
+512-bit RSA key in ~2011~\cite{syria-facebook-mitm}, Iran's
+interception of Bing and Google traffic using the DigiNotar
+CA~\cite{ct/a,diginotar}, and the 2018 MyEtherWallet
+self-signed certificate that was used as part of a BGP
+hijack~\cite{ethereum-hijack-isoc}.  The latter is also an example of
+redirecting routing as part of an attack (either suspected or
+confirmed). Other examples of this are Iran hijacking prefixes of
+Telegram (an encrypted messaging application) in
+2018~\cite{iran-telegram-bgp}, another attack on cryptocurrency in
+2014 this time targeting unencrypted mining
+traffic~\cite{bgp-hijacking-for-crypto},
+and hijacks that may have been intelligence-gathering (or honest
+mistakes) including hijacks by Russian ISPs in 2017 and China Telecom
+in 2018 and 2019~\cite{wiki-bgp}.  Finally, there are several examples of 
+law enforcement serving exploits to Tor Browser users to de-anonymize and
+subsequently arrest individuals~\cite{forbes-fbi-tor,doj-fbi-tor}.
+
+With
+the attacker's profile in mind, we consider someone that controls
+	a CA,
+	enough CT logs to pass Tor Browser's SCT-centric CT policy, 
+	some Tor clients, and
+	a fraction of Tor relays.
+For example, it is possible to
+	issue certificates and SCTs,
+	dishonor promises of public logging,
+	present split-views at will,
+	intercept and delay traffic from controlled exit relays as well as CT logs,
+		and
+	be partially present in the network.
+This includes a weaker attacker that does not \emph{control} CAs and CT logs,
+but who \emph{gained access} to the relevant signing keys~\cite{turktrust,%
+gdca1-omission}.  A modest fraction of CTor entities can be subject to DoS, but
+not everyone at once and all the time.  In other words, we consider the threat
+model of Tor and Tor Browser as a starting point~\cite{tor,tor-browser}.  Any
+attacker that can reliably disrupt CT and/or Tor well beyond Tor's threat
+model is therefore not within ours.
+
+Given that we are in the business of enforcing CT, the attacker needs to hide
+mis-issued certificates and SCTs from entities that audit the CT log ecosystem.
+As described in Section~\ref{ctor:sec:background:ct}, this can either be achieved by
+omission or split-view attacks.  Our intended attacker is clearly powerful and
+may successfully issue a certificate chain and associated SCTs without detection
+some of the time, but a CA caught in mis-issuance or a CT log that violated an
+MMD promise will no longer be regarded as trusted.  Therefore, we assume a
+\emph{risk-averse} attacker that above a relatively low probability of detection
+would be deterred from engaging in such activities. Note that the goal of
+\emph{detection} is inherited from CT's threat model, which aims to remedy
+certificate mis-issuance \emph{after the fact}; not prevent it~\cite{ct/a}.
+
+We identify and analyze specific attack vectors that follow from our threat
+model and design as part of the security analysis in Section~\ref{ctor:sec:analysis},
+namely, attack vectors related to timing as well as relay flooding and tagging.
diff --git a/summary/src/ctor/src/analysis.tex b/summary/src/ctor/src/analysis.tex
new file mode 100644
index 0000000..4bbc4c3
--- /dev/null
+++ b/summary/src/ctor/src/analysis.tex
@@ -0,0 +1,173 @@
+\section{Security Analysis} \label{ctor:sec:analysis}
+We consider four types of impact for an attacker that conducted
+HTTPS-based man-in-the-middle attacks on Tor Browser.  Other than \emph{none},
+these impact types are:
+\begin{description}
+	\item[Minor] the attack was detected due to some cover-up that involved
+		network-wide actions against CTor.  This is likely hard to attribute to
+		the actual attacker, but nevertheless it draws much unwanted attention.
+	\item[Significant] the attack generated public cryptographic evidence
+		that proves CA misbehavior.
+	\item[Catastrophic] the attack generated public cryptographic evidence
+		that proves CT log misbehavior.
+\end{description}
+
+Our design leads to significant and catastrophic impact events, but does
+unfortunately not preclude minor ones.  It is possible to overcome this
+shortcoming at different trade-offs, e.g., by tuning CTor parameters reactively
+(phase~2 below) or relying on different trust assumptions as in the
+incremental cross-logging designs (Section~\ref{ctor:sec:incremental}).
+
+\textbf{Probability of Detection.}
+Suppose the attacker mis-issued a certificate that Tor Browser trusts, and that
+it is considered valid because it is accompanied by enough SCTs from CT logs
+that the attacker controls.  The resulting SFO is then used to man-in-the-middle
+a single Tor Browser user, i.e., for the purpose of our analysis we consider
+\emph{the most risk-averse scenario possible}.  Clearly, none of the attacker's
+CT logs plan to keep any promise of public logging:
+	that would trivially imply significant impact events.
+The risk of exposure is instead bound by the probability that \emph{any} of the
+four phases in our design fail to propagate the mis-issued SFO to a pinned CT
+auditor that is benign.
+
+\textbf{Phase~1: Submission.}
+The probability of detection cannot exceed the probability of submission
+(\texttt{ct-submit-pr}). We analyze the outcome of submitting the mis-issued
+SFO from Tor Browser to a CTR\@.  There are two cases to consider, namely, the
+mis-issued SFO is either larger than \texttt{ct-large-sfo-size} or it is not.
+
+If the SFO is larger than \texttt{ct-large-sfo-size}, Tor Browser blocks until
+the SFO is submitted and its CT circuit is closed.  As such, it is impossible to
+serve a Tor Browser exploit reactively over the man-in-the-middled connection
+that shuts-down the submission procedure before it occurs.  Assuming that
+forensic traces in tor and Tor Browser are unreliable,\footnote{%
+	``tor'' (aka ``little-t tor'') is the tor process Tor Browser uses to
+	interact with the Tor network.  On marking a circuit as closed in tor, tor
+	immediately schedules the associated data structures to be freed as soon as
+	possible.
+} the sampled CTR identity also cannot be revealed with high certainty
+afterwards by compromising Tor Browser.  The attacker may know that the SFO is
+buffered by \emph{some CTR} based on timing, i.e., blocking-behavior could be 
+measurable and distinct.  The important part is not to reveal \emph{which CTR}
+received a submission:  a single Tor relay may be subject to DoS.
+
+If the SFO is smaller or equal to \texttt{ct-large-sfo-size} there is a
+race between (i) the time it takes for Tor Browser to submit the SFO and close
+its CT circuit against (ii) the time it takes for the attacker to compromise Tor
+Browser and identify the CTR in question.  It is more advantageous to try and
+win this race rather than being in the unfruitful scenario above.  Therefore,
+the attacker would maximize the time it takes to perform (i) by sending an SFO
+that is \texttt{ct-large-sfo-size}.  Our design reduced the threat of an
+attacker that wins this race by using pre-built CT circuits that are closed
+immediately after use.  This makes the attack surface \emph{narrow}, limiting
+the number of reliable exploits (if any).
+
+Note that the attack surface could, in theory, be eliminated by setting
+\texttt{ct-large-sfo-size} to zero.  However, that is likely  too costly in
+terms of latency~\cite{no-hard-fail}.
+
+\textbf{Phase~2: Buffering.}
+The probability of detection cannot exceed $1-(f_{\mathsf{ctr}} +
+f_{\mathsf{dos}})$, where $f_{\mathsf{ctr}}$ is the fraction of
+malicious CTRs and $f_{\mathsf{dos}}$ the fraction of CTRs that suffer from
+DoS.  We analyze the outcome of SFO reception at a genuine CTR\@.
+
+The time that an SFO is buffered depends on if the log's MMD elapsed or not.
+The earliest point in time that a newly issued SCT can be audited (and the log
+is expected to respond) is an MMD later, whereas the normal buffer time is
+otherwise only governed by smaller randomness in the \texttt{audit\_after}
+timestamp (minutes).  A rational attacker would therefore maximize the buffer
+time by using a newly issued SCT, resulting in an attack window that is \emph{at
+least} 24~hours for today's CT logs~\cite{google-log-policy}.
+
+Following from Tor's threat model, the mis-issued SFO must be stored in volatile
+memory and not to disk.  Two risks emerge due to large buffer times:
+	the CTR in question might be restarted by the operator independently of the
+		attacker's mis-issued SFO being buffered,
+	and given enough time the attacker might find a way to cause the evidence to
+		be deleted.
+While a risk-averse attacker cannot rely on the former to avoid detection, we
+emphasize that the CTR criteria must include the \texttt{stable} flag to reduce
+the probability of this occurring.
+
+The latter is more difficult to evaluate.  It depends on the attacker's
+knowledge as well as capabilities.  Phase~1 ensured that the attacker \emph{does
+not know which CTR to target}.  As such, any attempt to intervene needs to
+target all CTRs.  While a network-wide DoS against Tor would be effective, it is
+not within our threat model.  A less intrusive type of DoS would be to
+\emph{flood} CTRs by submitting massive amounts of SFOs: just enough to make
+memory a scarce resource, but without making Tor unavailable. This could
+potentially \emph{flush} a target SFO from the CTR's finite memory, following
+from the delete-at-random strategy in Section~\ref{ctor:sec:base:phase2}. Assuming
+that a CTR has at most 1~GiB of memory available for SFOs (conservative and in
+favour of the attacker), Appendix~\ref{ctor:app:flush} shows that the attacker's
+flood must involve at least $2.3$~GiB per CTR to accomplish a 90\% success
+certainty.  This means that it takes $7.9$--$39.3$~minutes if the relay
+bandwidth is between 8--40~Mbps.  So it is impractical to flush all CTRs within
+a few minutes, and hours are needed not to make everyone unavailable at once.
+
+The CTR criteria set in Section~\ref{ctor:sec:base:consensus} matches over
+4000 Tor relays~\cite{relay-by-flag}.  A network-wide flush that succeeds with
+90\% certainty therefore involves 8.99~TiB.  It might sound daunting at first,
+but distributed throughout an entire day it only requires 0.91~Gbps. Such an
+attack is within our threat model because it does not make Tor unavailable.
+Notably the ballpark of these numbers do not change to any significant degree by
+assuming larger success probabilities, e.g., a 99\% probability only doubles the
+overhead. Further, the needed bandwidth scales linearly with the assumed memory
+of CTRs.  This makes it difficult to rely on the finite volatile memory of CTRs
+to mitigate network-wide flushes.  As described in
+Section~\ref{ctor:sec:base:phase2}, we ensure that flushes are \emph{detected} by
+publishing the number of received and deleted SFO bytes throughout different
+time intervals as extra-info.
+
+Once detected, there are several possible \emph{reactions} that decrease the
+likelihood of a minor impact scenario.  For example, Tor's directory
+authorities could lower MMDs to, say, 30~minutes, so that the SFO is reported to
+an auditor before it is flushed with high probability.  This has the benefit of
+implying significant impact because the mis-issued certificate is detected, but
+also the drawback of allowing the logs to merge the certificate before there is
+any MMD violation to speak of.  The most appropriate response depends on the
+exact attack scenario and which trade-offs one is willing to accept.
+
+\textbf{Phase~3: Auditing.}
+By the time an SFO enters the audit phase, the log in question is expected to
+respond with a valid inclusion proof.  There is no such proof if the log
+violated its MMD, and it is too late to create a split-view that merged the
+certificate in time because the CTR's view is already fixed by an STH in the
+Tor consensus that captured the log's misbehavior.  In fact, creating any
+split-view within Tor is impractical because it requires that the consensus is
+forged or that nobody ever checks whether the trusted STHs are consistent.
+This leaves two options:
+	the attacker either responds to the query with an invalid inclusion proof or
+	not at all.
+The former is immediately detected and starts phase~4, whereas the latter forces
+the CTR to wait for \texttt{ct-watchdog-timeout} to trigger (which is a
+few seconds to avoid premature auditor reports).  A rational attacker prefers
+the second option to gain time.
+
+Clearly, the attacker knows that \emph{some} CTR holds evidence of log
+misbehavior as it is being audited.  The relevant question is whether the
+\emph{exact CTR identity} can be inferred, in which case the attacker could
+knock it offline (DoS).  Motivated by the threat of \emph{tagging}, where the
+attacker sends unique SFOs to all CTRs so that their identities are revealed
+once queried for, we erred on the safe side and built watchdogs into our design:
+it is already too late to DoS the querying CTR because the evidence is already
+replicated somewhere else, ready to be reported unless there is a timely
+acknowledgement. The attacker would have to \emph{break into an arbitrary CTR
+within seconds} to cancel the watchdog, which cannot be identified later on
+(same premise as the sampled CTR in phase~1).  Such an attacker is not in Tor's
+threat model.
+
+\textbf{Phase~4: Reporting.}
+At this stage the process of reporting the mis-issued SFO to a random CT auditor
+is initiated.  Clearly, the probability of detection cannot exceed
+$1-f_{\mathsf{auditor}}$, where $f_{\mathsf{auditor}}$ is the fraction of
+malicious CT auditors.  Fixating the sampled CT auditor is important to avoid
+the threat of an eventually successful report only if it is destined to the
+attacker's auditor because our attacker is partially present in the network.
+Gaining time at this stage is of limited help because the CTR identity is
+unknown as noted above, and it remains the
+case throughout phase~4 due to reporting on independent Tor circuits (and
+independently of if other SFO reports succeeded or not).  Without an
+identifiable watchdog, the attacker needs a network-wide attack that is already
+more likely to succeed in the buffer phase.
diff --git a/summary/src/ctor/src/appendix.tex b/summary/src/ctor/src/appendix.tex
new file mode 100644
index 0000000..23e285f
--- /dev/null
+++ b/summary/src/ctor/src/appendix.tex
@@ -0,0 +1,117 @@
+\section{Detailed Consensus Parameters} \label{ctor:app:consensus-params} 
+
+Below, the value of an item is computed as the median of all votes.
+\begin{description}
+    \item[ct-submit-pr:] A floating-point in $[0,1]$ that determines Tor
+        Browser's submission probability.  For example, $0$ disables submissions
+        while $0.10$ means that every 10$^{\mathsf{th}}$ SFO is sent to a random
+        CTR on average.
+    \item[ct-large-sfo-size:] A natural number that determines how many
+        wire-bytes a normal SFO should not exceed.  As outlined in
+        Section~\ref{ctor:sec:base:phase1}, excessively large SFOs are subject to
+        stricter verification criteria.
+    \item[ct-log-timeout:] A natural number that determines how long a CTR waits
+        before concluding that a CT log is unresponsive, e.g., 5~seconds. As
+        outlined in Section~\ref{ctor:sec:base:phase3}, a timeout causes the watchdog
+        to send an SFO to the auditor.
+    \item[ct-delay-dist:] A distribution that determines how long a CTR should
+        wait at minimum before auditing a submitted SFO.  As outlined in
+        Section~\ref{ctor:sec:base:phase2}, random noise is added, e.g., on the order
+        of minutes to an hour.
+    \item[ct-backoff-dist:]
+        A distribution that determines how long a CTR should wait between two
+        auditing instances, e.g., a few minutes on average.  As outlined in
+        Section~\ref{ctor:sec:base:phase3}, CTRs audit pending SFOs in batches at
+        random time intervals to spread out log overhead.
+    \item[ct-watchdog-timeout:] A natural number that determines how long time
+    at most a watchdog waits before considering an SFO for reporting. Prevents
+    the watchdog from having to wait for a circuit timeout caused by an
+    unresponsive CTR. Should be set with \texttt{ct-backoff-dist} in mind.
+    \item[ct-auditor-timeout] A natural number that determines how long time at
+    most a watchdog waits for an auditor to acknowledge the submission of an SFO.
+\end{description}
+
+\section{Log Operators \& Trust Anchors} \label{ctor:app:ct-trust-anchors}
+The standardized CT protocol suggests that a log's trust anchors should
+``usefully be the union of root certificates trusted by major browser
+vendors''~\cite{ct,ct/bis}.  Apple further claims that a log in their CT program
+``must trust all root CA certificates included in Apple's trust
+store''~\cite{apple-log-policy}.  This bodes well for the incremental CTor
+designs:
+	we assumed that the existence of independent log operators implies the
+	ability to at least add certificate chains and possibly complete SFOs
+	into logs that the attacker does not control.
+Google's CT policy currently qualifies 36 logs that are hosted by
+	Cloudflare,
+	DigiCert,
+	Google,
+	Let's Encrypt,
+	Sectigo, and
+	TrustAsia~\cite{google-log-policy}.
+No log accepts all roots, but the overlap between root certificates that are
+trusted by major browser vendors and CT logs increased over
+time~\cite{ct-root-landscape}.  This trend would likely continue if there are
+user agents that benefit from it, e.g., Tor Browser.  Despite relatively few
+log operators and an incomplete root coverage, the basic and extended
+cross-logging in CTor still provide significant value as is:
+\begin{itemize}
+	\item Even if there are no independent logs available for a certificate
+		issued by some CA, adding it again \emph{to the same logs} would come
+		with practical security gains.  For example, if the attacker gained
+		access to the secret signing keys but not the logs' infrastructures
+		the mis-issued certificate trivially makes it into the public.  If the
+		full SFO is added, the log operators could also notice that they were
+		compromised.
+	\item Most log operators only exclude a small fraction of widely accepted
+		root certificates: 1--5\%~\cite{ct-root-landscape}.  This narrows down
+		the possible CAs that the attacker must control by 1--2 orders of
+		magnitude.  In other words, to be entirely sure that CTor would (re)add
+		a mis-issued SFO to the attacker-controlled CT logs, this smaller group
+		of CAs must issue the underlying certificate.  It is likely harder to
+		take control of Let's Encrypt which some logs and operators exclude due
+		to the sheer volume of issued certificates than, say, a smaller CA that
+		law enforcement may coerce.
+\end{itemize}
+
+Browser-qualified or not, the availability of independent logs that accept the
+commonly accepted root certificates provides significant ecosystem value.
+Log misbehavior is mostly reported through the CT policy mailing list.  Thus, it
+requires manual intervention.  Wide support of certificate chain and SCT
+cross-logging allows anyone to \emph{casually} disclose suspected log
+misbehavior on-the-fly.
+
+\section{Flushing a Single CTR} \label{ctor:app:flush}
+Let $n$ be the number of SFOs that a CTR can store in its buffer.  The
+probability to sample a target SFO is thus $\frac{1}{n}$, and the probability to
+not sample a target SFO is $q = 1 - \frac{1}{n}$.  The probability to not sample
+a target SFO after $k$ submissions is $q^k$.  Thus, the probability to sample
+the relevant buffer index at least once is $p = 1 - q^k$.  Solving for $k$ we
+get: $k = \frac{\log(1 - p)}{\log(q)}$.  Substituting $q$ for $1 - \frac{1}{n}$
+yields Equation~\ref{ctor:eq:flush}, which can be used to compute the number of
+SFO submissions that the attacker needs to flush a buffer of $n>2$
+entries with some probability~$p\in[0,1)$.
+
+\begin{equation} \label{ctor:eq:flush}
+	k = \frac{\log(1-p)}{\log(1 - \frac{1}{n})}
+\end{equation}
+
+It is recommended that a non-exit relay should have at least 512MB of memory.
+If the available bandwidth exceeds 40Mbps, it should have at least
+1GB~\cite{relay-config}.  Given that these recommendations are lower bounds,
+suppose the average memory available to store SFOs is 1GiB.
+Section~\ref{ctor:sec:performance} further showed that the average SFO size is
+roughly 6KiB.  This means that the buffer capacity is $n \gets 174763$ SFOs.
+Plugging it into Equation~\ref{ctor:eq:flush} for $p \gets \frac{9}{10}$, the
+attacker's flood must involve $k \gets 402406$ submissions.  In other words,
+2.3GiB must be transmitted to flush a single CTR with 90\% success probability.
+
+As a corner case and implementation detail it is important that Tor Browser and
+CTRs \emph{reject} SFOs that are bogus in terms of size: it is a trivial DoS
+vector to load data indefinitely.  If such a threshold is added the required
+flushing bandwidth is still 2.3GiB (e.g., use 1MiB SFOs in the above
+computations).  What can be said about bandwidth and potential adversarial
+advantages is that a submitted SFO yields amplification:
+	twofold for cross-logging, and
+	slightly more for proof-fetching as the SFO is pushed up-front to a
+		watchdog.
+Note that such amplification is smaller than a typical website visit.
diff --git a/summary/src/ctor/src/background.tex b/summary/src/ctor/src/background.tex
new file mode 100644
index 0000000..85d972f
--- /dev/null
+++ b/summary/src/ctor/src/background.tex
@@ -0,0 +1,150 @@
+\section{Background} \label{ctor:sec:background}
+The theory and current practise of CT is introduced first, then Tor
+and its privacy-preserving Tor Browser.
+
+\subsection{Certificate Transparency} \label{ctor:sec:background:ct}
+The idea to transparently log TLS certificates emerged at Google in response to
+a lack of proposals that could be deployed without drastic ecosystem changes
+and/or significant downsides~\cite{ct/a}.  By making the set of issued
+certificate chains\footnote{%
+	A domain owner's certificate is signed by an intermediate CA, whose
+	certificate is in turned signed by a root CA that acts as a trust
+	anchor~\cite{ca-ecosystem}.  Such a \emph{certificate chain} is valid if it
+	ends in a trusted anchor that is shipped in the user's system software.
+} transparent, anyone that inspect the logs can detect certificate
+mis-issuance \emph{after the fact}.  It would be somewhat circular to solve
+issues in the CA ecosystem by adding trusted CT logs.  Therefore, the
+cryptographic foundation of CT is engineered to avoid any such reliance.
+Google's \emph{gradual} CT roll-out started in 2015, and evolved from 
+downgrading user-interface indicators in Chrome to the current state of hard
+failures unless a certificate is accompanied by a signed \emph{promise} that it
+will appear in two CT logs~\cite{does-ct-break-the-web}.  Unlike Apple's
+Safari~\cite{apple-log-policy}, these two logs must additionally be operated by
+Google and not-Google to ensure independence~\cite{google-log-policy}.
+
+The lack of mainstream verification, i.e., beyond checking signatures, allows an
+attacker to side-step the current CT enforcement with minimal risk of exposure
+\emph{if the required logs are controlled by the attacker}.  
+CTor integrates into the gradual CT roll-out by starting on the
+premise of pairwise-independently trusted CT logs, which
+avoids the risk of bad user experience~\cite{does-ct-break-the-web}
+and significant system complexity.  For example, web pages are unlikely to
+break, TLS handshake latency stays about the same, and no robust management of
+suspected log misbehavior is needed.  Retaining the latter property as part of
+our incremental designs simplifies deployment.
+
+\subsubsection{Cryptographic Foundation}
+The operator of a CT log maintains a tamper-evident append-only Merkle
+tree~\cite{ct,ct/bis}.  At any time, a Signed Tree Head (STH) can be produced
+which fixes the log's structure and content.  Important attributes of an STH
+include
+	the tree head (a cryptographic hash),
+	the tree size (a number of entries), and
+	the current time.
+Given two tree sizes, a log can produce a \emph{consistency proof} that proves
+the newer tree head entails everything that the older tree head does.  As such,
+anyone can verify that the log is append-only without downloading all entries
+and recomputing the tree head.  Membership of an entry can also be proven
+by producing an \emph{inclusion proof} for an STH.  These proof techniques are
+formally verified~\cite{secure-logging-and-ct}.
+
+Upon a valid request, a log must add an entry and produce a new STH that covers
+it within a time known as the Maximum Merge Delay (MMD), e.g., 24~hours.  This
+policy aspect can be verified because in response, a Signed Certificate
+Timestamp (SCT) is returned.  An SCT is a signed promise that an entry will
+appear in the log within an MMD.  A log that violates its MMD is said to perform
+an \emph{omission attack}.  It can be detected by challenging the log to prove
+inclusion.  A log that forks, presenting one append-only version
+to some entities and another to others, is said to perform a \emph{split-view
+attack}.  Split-views can be detected by STH
+gossip~\cite{chuat,dahlberg,nordberg,syta}.
+
+\subsubsection{Standardization and Verification}
+The standardized CT protocol defines public HTTP(S) endpoints that allow anyone
+to check the log's accepted trust anchors and added certificates, as well as
+to obtain the most recent STH and to fetch proofs~\cite{ct,ct/bis}.  For
+example, the \texttt{add-chain} endpoint returns an SCT if the added certificate
+chain ends in a trust anchor returned by the \texttt{get-roots} endpoint.  We
+use \texttt{add-chain} in Section~\ref{ctor:sec:incremental}, as well as several
+other endpoints in Section~\ref{ctor:sec:base} to fetch proofs and STHs.  It might be
+helpful to know that an inclusion proof is fetched based on two parameters: a
+certificate hash and the tree size of an STH.  The former specifies the log entry
+of interest, and the latter with regards to which view inclusion should be
+proven.  The returned proof is valid if it can be used in combination with the
+certificate to reconstruct the STH's tree head.
+
+The CT landscape provides a limited value unless it is verified that the logs
+play by the rules.  What the rules are changed over time, but they are largely
+influenced by the major browser vendors that define \emph{CT policies}.  For
+example, what is required to become a recognized CT log in terms of uptime and
+trust anchors, and which criteria should pass to consider a certificate CT
+compliant~\cite{apple-log-policy,google-log-policy}.  While there are several ways that
+a log can misbehave with regards to these policy aspects, the most fundamental
+forms of cheating are omission and split-view attacks.  A party that follows-up
+on inclusion and consistency proofs is said to \emph{audit} the logs.
+
+Widespread client-side auditing is a premise for CT logs to be untrusted, but
+none of the web browsers that enforce CT engage in such activities yet.  For
+example, requesting an inclusion proof is privacy-invasive because it leaks
+browsing patterns to the logs, and reporting suspected log misbehavior comes
+with privacy~\cite{ct-with-privacy} as well as operational challenges.
+Found log incidents are mostly reported manually to the CT policy
+list~\cite{ct-policy-mailing-list}.  This is in contrast to automated
+\emph{CT monitors}, which notify domain owners
+of newly issued certificates based on what actually appeared in the public
+logs~\cite{lwm,ct-monitors}.
+
+\subsection{Tor} \label{ctor:sec:background:tor}
+
+Most of the activity of Tor's millions of daily users starts with Tor Browser
+and connects to some ordinary website via a circuit comprised of three
+randomly-selected Tor relays. In this way no identifying information from
+Internet protocols (such as IP address) are automatically provided to the
+destination, and no single entity can observe both the source and destination of
+a connection. Tor Browser is also configured and performs some filtering to resist
+browser fingerprinting, and first party isolation to resist sharing state or
+linking of identifiers across origins. More generally it avoids storing
+identifying configuration and behavioral information to disk.
+
+Tor relays in a circuit are selected at random, but not uniformly. A typical
+circuit is comprised of a \emph{guard}, a \emph{middle}, and an \emph{exit}. A
+guard is selected by a client and used for several months as the entrance to all
+Tor circuits. If the guard is not controlled by an adversary, that adversary
+will not find itself selected to be on a Tor circuit adjacent to (thus
+identifying) the client. And because some relay operators do not wish to act as
+the apparent Internet source for connections to arbitrary destinations, relay
+operators can configure the ports (if any) on which they will permit connections
+besides to other Tor relays. Finally, to facilitate load balancing, relays are
+assigned a weight based on their apparent capacity to carry traffic. In keeping
+with avoiding storing of linkable state, even circuits that share an origin will
+only permit new connections over that circuit for ten minutes. After that, if
+all connections are closed, all state associated with the circuit is cleared.
+
+Tor clients use this information when choosing relays with which to build a
+circuit. They receive the information via an hourly updated \emph{consensus}.
+The consensus assigns weights as well as flags such as \texttt{guard} or
+\texttt{exit}. It also assigns auxiliary flags such as
+\texttt{stable}, which, e.g.,
+is necessary to obtain the \texttt{guard} flag since guards must have good
+availability. Self-reported information by relays in their \emph{extra-info
+document}, such as statistics on their read and written bytes, are also part of
+the consensus and uploaded to \emph{directory authorities}. Directory
+authorities determine the consensus by voting on various components making up
+the shared view of the state of the Tor network. Making sure that all clients
+have a consistent view of the network prevents epistemic attacks wherein clients
+can be separated based on the routes that are consistent with their
+understanding~\cite{danezis:pets2008}. This is only a very rough sketch of Tor's
+design and operation.  More details can be found by following links at Tor's
+documentation site~\cite{tor-documentation}.
+
+Tor does not aim to prevent end-to-end correlation attacks. An adversary
+controlling the guard and exit, or controlling the destination and observing the
+client ISP, etc., is assumed able to confirm who is connected to whom on that
+particular circuit. The Tor threat model assumes an adversary able to control
+and/or observe a small to moderate fraction of Tor relays measured by both
+number of relays and by consensus weight, and it assumes a large
+number of Tor clients
+able to, for example, flood individual relays to detect traffic signatures of
+honest traffic on a given circuit~\cite{long-paths}. Also, the adversary can
+knock any small number of relays offline via either attacks from clients or
+direct Internet DDoS. 
diff --git a/summary/src/ctor/src/conclusion.tex b/summary/src/ctor/src/conclusion.tex
new file mode 100644
index 0000000..c7f5508
--- /dev/null
+++ b/summary/src/ctor/src/conclusion.tex
@@ -0,0 +1,49 @@
+\section{Conclusion} \label{ctor:sec:conclusion} 
+We proposed CTor, a privacy-preserving and incrementally-deployable design that
+brings CT to Tor.  Tor Browser should start by taking the same proactive
+security measures as Google Chrome and Apple's Safari:
+	require that a certificate is only valid if accompanied by at least two
+	SCTs.
+Such CT enforcement narrows down the attack surface from the weakest-link
+security of the CA ecosystem to a relatively small number of trusted log
+operators \emph{without negatively impacting the user experience to an
+unacceptable degree}.  The problem is that a powerful attacker may gain control
+of the required logs, trivially circumventing enforcement without significant
+risk of exposure.  If deployed incrementally, CTor relaxes the currently
+deployed trust assumption by distributing it across all CT logs.  If the full
+design is put into operation, such trust is completely eliminated.
+
+CTor repurposes Tor relays to ensure that today's trust in CT logs is not
+misplaced:
+	Tor Browser probabilistically submits the encountered certificates and SCTs
+	to Tor relays, which
+		cross-log them into independent CT logs (incremental design)
+		or request inclusion proofs with regards to a single fixed view
+			(full design).
+It turns out that delegating verification to a party that can defer it
+is paramount in our setting, both for privacy and security.  Tor and the wider
+web would greatly benefit from each design increment.  The full design turns Tor
+into a
+system for maintaining a probabilistically-verified view of the entire CT log
+ecosystem, provided in Tor's consensus for anyone to use as a basis of trust.
+The idea to cross-log certificates and SCTs further showcase how certificate
+mis-issuance and suspected log misbehavior could be disclosed casually without
+any manual intervention by using the log ecosystem against the attacker.
+
+The attacker's best bet to break CTor involves any of the following:
+	operating significant parts of the CTor infrastructure,
+	spending a reliable Tor Browser zero-day that escalates privileges within a
+		tiny time window, or
+	targeting all Tor relays in an attempt to delete any evidence of certificate
+		mis-issuance and log misbehavior.
+The latter---a so-called network-wide flush---brings us to the border of our
+threat model, but it cannot be ignored due to the powerful attacker that we
+consider.  Therefore, CTor is designed so that Tor can \emph{adapt} in response
+to interference.  For example, in Tor Browser the \texttt{ct-large-sfo-size}
+could be set reactively such that all SFOs must be sent to a CTR before
+accepting any HTTPS application-layer data to counter zero-days, and the submit
+probability \texttt{ct-submit-pr} could be increased if ongoing attacks are
+suspected.  When it comes to the storage phase, the consensus can minimize or
+maximize the storage time by tuning a log's MMD in the \texttt{ct-log-info}
+item.  The distribution that adds random buffering delays could also be updated,
+as well as log operator relationships during the auditing phase.
diff --git a/summary/src/ctor/src/cross-logging.tex b/summary/src/ctor/src/cross-logging.tex
new file mode 100644
index 0000000..ec6807d
--- /dev/null
+++ b/summary/src/ctor/src/cross-logging.tex
@@ -0,0 +1,101 @@
+\section{Incremental Deployment} \label{ctor:sec:incremental} 
+Section~\ref{ctor:sec:base} covered the full design that places zero-trust in the CT
+landscape by challenging the logs to prove certificate inclusion with regards to
+trusted STHs in the Tor consensus.  If no such proof can be provided, the
+suspected evidence of log misbehavior is reported to a trusted CT auditor that
+follows-up on the incident, which involves human intervention if an issue
+persists.  The proposed design modifies the Tor consensus, Tor relays, and Tor
+Browser.  It also requires development and operation of a trusted auditor
+infrastructure.  The current lack of the latter makes it unlikely that we will
+see adoption of CTor in its full potential anytime soon, and begs the question
+of increments that help us get there in the future. Therefore, we additionally
+propose two incremental designs in this section.
+
+\begin{figure}[!t]
+    \centering
+	\includegraphics[width=\columnwidth]{src/ctor/img/design-incremental}
+	\caption{%
+		Incremental design that can be deployed without any
+		trusted CT auditors.  Tor Browser still submits SFOs to CTRs on
+		independent Tor circuits for the sake of privacy and security.  After
+		CTR buffering, the submitted certificates are \emph{cross-logged} by
+		adding them to independent CT logs (selected at random) that the
+		attacker does not control (inferred from accompanied SCTs).
+	}
+	\label{ctor:fig:cross-log}
+\end{figure}
+
+Without the ability to rely on CT auditors, trust needs to be shifted elsewhere
+because we cannot expect relay operators to take on the role.  At the same time,
+an incremental proposal needs to improve upon the status quo of
+pairwise-independently trusted CT logs. These observations lead us towards the
+trust assumption that \emph{at least some} of the CT logs are trustworthy. Such
+an assumption is suboptimal, but it does provide a real-world security
+improvement by significantly raising the bar from weakest-link(s) to quite the
+opposite.
+
+The smallest change of the full design would be for watchdogs to report
+suspected certificate mis-issuance to all CT logs, simply by using the public
+\texttt{add-chain} API to make the SFO's certificate chain transparent.  This
+has the benefit of holding the CA accountable if \emph{some} log operator is
+benign.  Given that our attacker is risk-averse, reporting to a single
+independent log\footnote{The independent log need not be trusted by the browser,
+i.e., it could be specified separately in the Tor consensus.  An operator that
+runs such a log would help distribute trust and facilitate auditing.
+Appendix~\ref{ctor:app:ct-trust-anchors} provides details on today's log ecosystem.}
+that issued none of the accompanied SCTs would likely be sufficient.  There is
+also room for further simplification: there is no point in challenging the logs
+to prove inclusion if the fallback behavior of no response only makes the issued
+certificate public, not the associated SCTs. Thus, CTRs could opt to cross-log
+immediately \emph{without ever distinguishing between certificates that are
+benign and possibly fraudulent}.  This results in the incremental design shown
+in Figure~\ref{ctor:fig:cross-log}, which initially removes several system
+complexities such as extra-info metrics, auditor infrastructure, watchdog
+collaborations, and inclusion proof fetching against trusted STHs in Tor's
+consensus.
+
+The drawback of certificate cross-logging is that the misbehaving CT logs cannot
+be exposed.  There is also a discrepancy between cross-logging and encouraging
+the CT landscape to deploy reliable CT auditors.  We therefore suggest a
+minimal change to the basic cross-logging design that addresses both of these
+concerns.  This change is unfortunately to the API of CT logs and not Tor.  The
+proposed change is to allow cross-logging of a certificate's issued SCTs, e.g.,
+in the form of an \texttt{add-sfo} API that would replace \texttt{add-chain}
+in Figure~\ref{ctor:fig:cross-log}.
+This means that CTRs could expose both the mis-issued certificate and the logs
+that violated their promises of public logging.  At the same time, the
+infrastructural part of a CT auditor is built directly into existing
+CT logs:
+	accepting SFOs that need further investigation.
+Such an API would be an ecosystem improvement in itself, providing a
+well-defined place to report suspected log misbehavior on-the-fly
+\emph{casually}, i.e., without first trying to resolve an SFO for an extended
+time period from many different vantage points and then ultimately reporting it
+manually on the CT policy mailing list.
+
+\textbf{Security Sketch.} 
+There are no changes to phase~1 because cross-logging is instantiated at CTRs.
+Phases~3--4 are now merged, such that the encountered certificates are added to
+independent CT logs that the attacker does/may not control.  Watchdogs are no
+longer needed since either the certificates are added to a log that the attacker
+controls, or they are not (which makes them public).  The other main difference takes place in phase~2,
+during which CTRs buffer SFOs.  The buffer time used to be lengthy due to taking
+early signals and MMDs into account, but it is now irrelevant as no inclusion
+proofs are fetched.  The expected buffer time can therefore be shortened down
+to \emph{minutes} that follow only from the randomness in the
+\texttt{audit\_after} timestamp (for the sake of privacy), making network-wide
+flushes impractical while at the same time reducing the time that a mis-issued
+certificate stays unnoticed:
+	a benign log is likely to add an entry before all MMDs elapsed.
+
+The extended cross-logging also aims to expose log misbehavior.  As such, it is
+paramount that no cross-logged SFO becomes public before the issuing CT logs can
+merge the mis-issued certificate reactively to avoid catastrophic impact. This
+could be assured by buffering newly issued SFOs longer as in the full design,
+which brings back the threat and complexity of minor impact scenarios. Another
+option that is appealing for Tor (but less so for CT) is to operate the
+\texttt{add-sfo} API with the expectation of \emph{delayed merges} that account
+for MMDs before making an SFO public, effectively moving lengthy buffering from
+CTRs to CT logs with persistent storage.  Trillian-based CT logs already support
+delayed merges of (pre)certificates, see
+\texttt{sequencer\_guard\_window}~\cite{delayed-merge}.
diff --git a/summary/src/ctor/src/design.tex b/summary/src/ctor/src/design.tex
new file mode 100644
index 0000000..5b887fe
--- /dev/null
+++ b/summary/src/ctor/src/design.tex
@@ -0,0 +1,377 @@
+\section{Design} \label{ctor:sec:base}
+A complete design---a design that detects misbehavior by both CAs and CT logs
+within our strong threat model---requires a considerable degree of
+complexity. In this section we present such a full design by breaking it up
+into four phases as shown in Figure~\ref{ctor:fig:design}, demonstrating the need for
+the involved complexity in each step.  Section~\ref{ctor:sec:incremental} presents
+two incremental versions of the full design that are less complicated.  The
+first increment comes as the cost of having a weaker threat model and security
+goal.  The second increment does not have a weaker security goal but requires a
+new CT log API.
+
+A design that starts by validating SCT signatures like Apple's Safari is
+promising and assumed~\cite{apple-log-policy,apple-on-independence}, but it does
+not stand up against a malicious CA and two CT logs that work in concert.  If
+the logs cannot be trusted blindly, the presented SCTs need to be audited.
+
+\begin{figure}[!t]
+    \centering
+	\includegraphics[width=\columnwidth]{src/ctor/img/design-full}
+	\caption{%
+		An overview of the four phases of the full CTor design. In phase 1 Tor
+	Browser submits an SFO (SCT Feedback Object) to a Certificate Transparency
+	Relay (CTR), followed by phase 2 where the CTR buffers the SFO. In phase 3
+	the relay attempts to audit the SFO, and in case of failure, it reports the
+	SFO to an auditor with the help of a watchdog CTR in phase 4.}
+	\label{ctor:fig:design}
+\end{figure}
+
+\subsection{Phase~1: Submission} \label{ctor:sec:base:phase1}
+
+The least complicated auditing design would be one where Tor Browser receives a
+TLS certificate and accompanying SCTs (we will refer to this bundle as an SCT
+Feedback Object, or SFO for short) and talks to the corresponding logs, over
+Tor, requesting an inclusion proof for each SCT. In an ordinary browser, this
+would be an unacceptable privacy leak to the log of browsing behavior associated
+with an IP address; performing this request over Tor hides the user's IP address
+but still leaks real-time browsing behavior.
+
+An immediate problem with this design is that a primary requirement of Tor
+Browser is to persist no data about browsing behavior after the application
+exits. If we assume that browsers are not left running for long periods of time,
+the inclusion proof request can be easily circumvented by the attacker by using
+a fresh SCT whose MMD has not completed---thus no inclusion proof needs to be
+provided (yet) by the log as per the CT standard. A second problem is that the
+STH that an inclusion proof refers to exists in a \emph{trust vacuum}:
+	there is no way to know that it is consistent with other STHs and not part
+	of a split view (assuming that there is no proactive STH
+	gossip~\cite{dahlberg,syta}, which is not deployed).
+
+We can evolve the design by adding two components: a list of STHs that Tor
+Browser receives over a trusted channel and the participation of a trusted third
+party with the ability to persist data and perform auditing actions at a later
+point in time.
+
+A single third party used by all users of Tor Browser would receive a
+considerable aggregation of browsing behavior and would need to scale in-line
+with the entire Tor network. A small number of auditors presents privacy and
+single-point-of-failure concerns. A large number would be ideal but presents
+difficulties in curation and independent management and still requires scaling
+independent of the Tor network. These concerns do not entirely preclude the
+design, but they can be easily avoided by reusing relays in the Tor network as
+our trusted third parties: we call the relays so designated Certificate
+Transparency Relays (CTRs).
+
+Now, when the browser is completing the TLS handshake, it simultaneously either
+passes the SFO to a CTR (if the MMD of the SCT has not elapsed) or queries the
+log itself for an inclusion proof to a trusted STH\@.  However, if we presume
+the attacker can serve an exploit to the browser, the latter behavior is
+immediately vulnerable. The log, upon receiving an inclusion proof request for
+an SCT that it knows is malicious, can delay its response. The TLS connection in
+the browser, having succeeded, will progress to the HTTP request and response,
+at which point the exploit will be served, and the SFO (containing the
+cryptographic evidence of CA and log misbehavior) will be deleted by the exploit
+code. While blocking the TLS connection until the CT log responds is an option,
+experience related to OCSP hard-fail indicates that this notion is likely doomed
+to fail~\cite{no-hard-fail}.
+
+The final change of the design has Tor Browser submit the SFO to the CTR
+immediately upon receipt (with some probability) in all cases. A consequence of
+this shift is that the trusted STH list no longer needs to be delivered to the
+browser but rather the CTRs. To mitigate the risk of a browser exploit being
+able to identify the CTR to the attacker (who could then target it), we prepare
+\emph{CTR circuits} ahead of time that are closed and discarded as soon as the
+SFO is sent. This allows the SFO submission to race with the TLS connection
+completion and HTTP request/response. An added detail is to block the TLS
+connection in the case that an SFO is unusually large, as defined by a parameter
+\texttt{ct-large-sfo-size}. A large SFO may indicate an attempt to win the race
+between SFO submission and exploitation. The parameter can be set such that it
+happens extremely rarely on legitimate connections, as shown in
+Section~\ref{ctor:sec:performance}.
+
+We summarize phase~1 with the following algorithm that provides more explicit
+steps and details, including the addition of a parameter \texttt{ct-submit-pr}
+that indicates a probability that an SFO is submitted to a CTR. This provides
+probabilistic security while providing the ability to adjust submission rates to
+account for
+CTR and more general network scaling/health issues. Given an incoming SFO $s$,
+Tor Browser should:
+\begin{enumerate}
+    \item Raise a certificate error and stop if the certificate chain of $s$
+        is not rooted in Tor Browser's trust store.
+    \item Raise a certificate transparency error and stop if the SCTs of $s$
+        fail Tor Browser's CT policy.
+    \item If $\mathsf{len}(s) < \texttt{ct-large-sfo-size}$, accept $s$ and
+        conduct the remaining steps in the background while the TLS connection
+        and subsequent HTTP request/response proceed. If $\mathsf{len}(s) \geq
+        \texttt{ct-large-sfo-size}$ pause the TLS handshake, complete the
+        remaining steps, accept~$s$ as valid and then continue the handshake.
+    \item Flip a biased coin based on \texttt{ct-submit-pr} and stop if the
+        outcome indicates no further auditing.
+    \item Submit $s$ to a random CTR on a pre-built circuit. The circuit used
+        for submission is closed immediately without waiting for any
+        acknowledgment.
+\end{enumerate}
+
+\subsection{Phase 2: Buffering} \label{ctor:sec:base:phase2}
+
+Once received, the most straightforward thing for a CTR to do would be to
+contact the issuing log and request an inclusion proof relative to a trusted
+STH\@. (And if the SCT's MMD has not elapsed, hold the SFO until it has.)
+However, this proposal has two flaws, the first of which leads us to the actual
+design of phase 2.
+
+Immediately contacting the log about an SFO (i) allows the log to predict when
+exactly it will receive a request about an SFO and (ii) discloses real-time
+browsing behavior to the log. The former problem means that an attacker can
+position resources for perpetuating an attack ahead-of-time, as well as letting
+it know with certainty whether a connection was audited (based on
+\texttt{ct-submit-pr}). The latter is some amount of information leakage that
+can help with real-time traffic analysis.
+
+Because a CTR must support buffering SCTs regardless (due to the MMD), we can
+schedule an event in the future for when each SFO should be audited. Adding a
+per-SFO value sampled from \texttt{ct-delay-dist} effectively adds stop-and-go
+mixing~\cite{kesdogan:ih1998} to the privacy protection, but where there is only
+one mix (CTR) between sender (client) and receiver (CT log). So there is no
+point in a client-specified interval-start-time such that the mix drops messages
+arriving before then, and there is no additional risk in having the interval end
+time set by the mix rather than the sender. This means both that some SFOs a
+client sends to a CTR at roughly the same time might be audited at different
+times and that SFOs submitted to that CTR by other honest clients are more
+likely to be mixed with these.
+
+In addition to buffering SFOs for mixing effects, we also add a layer of caching
+to reduce the storage overhead, prevent unnecessary log connections, and limit
+the disclosure to logs. With regards to some CT circuit, an incoming SFO $s$ is
+processed as follows by a CTR:
+\begin{enumerate}
+    \item\label{ctor:enm:storage:close} Close the circuit to enforce one-time use.
+    \item\label{ctor:enm:storage:unrecognized} Discard all SCTs in the SFO for logs
+        the CTR is not aware of; if no SCT remains then discard the SFO.
+	\item\label{ctor:enm:storage:cached} Stop if $s$ is cached or already pending to
+		be audited in the buffer.  See caching details in
+		Section~\ref{ctor:sec:performance:estimates}.
+    \item\label{ctor:enm:storage:fix-log} Sample a CT log $l$ that issued a
+        remaining SCT in~$s$.
+    \item\label{ctor:enm:storage:audit-after} Compute an \texttt{audit\_after}
+		time~$t$, see Figure~\ref{ctor:fig:audit-after}.
+    \item\label{ctor:enm:storage:store} Add $(l,t,s)$ to a buffer of pending SFOs to
+    audit.
+\end{enumerate}
+
+What makes a CT log known to the CTR is part of the Tor consensus, see
+Section~\ref{ctor:sec:base:consensus}.  It implies knowledge of a trusted STH for the
+sampled CT log $l$, which refers to an entity that (i) issued an SCT in the
+submitted SFO, and (ii) will be challenged to prove inclusion in phase~3
+sometime after the \texttt{audit\_after} timestamp $t$ elapsed. We choose one
+SCT (and thus log) at random from the SFO because it is sufficient to suspect
+only one misbehaving log so long as we report the entire SFO, allowing us to
+identify the other malicious CT logs later on (a risk averse-attacker would not
+conduct an attack without controlling enough logs, i.e., one benign log would
+otherwise make the mis-issued certificate public).
+
+\begin{figure}[!t]
+	\centering
+	\pseudocode[linenumbering, syntaxhighlight=auto]{%
+		\textrm{t} \gets \mathsf{now}() +
+			\mathsf{MMD} +
+			\mathsf{random}(\texttt{ct-delay-dist}) \\
+		\pcif \textrm{SCT.timestamp} + \textrm{MMD} <
+				\mathsf{now}():\\
+			\pcind\textrm{t} \gets \mathsf{now}() +
+				\mathsf{random}(\texttt{ct-delay-dist})
+	}
+	\caption{%
+		Algorithm that computes an \texttt{audit\_after} timestamp $t$.
+	}
+	\label{ctor:fig:audit-after}
+\end{figure}
+
+The \texttt{audit\_after} timestamp specifies the earliest point in time that an
+SCT from an SFO will be audited in phase~3, which adds random noise that
+obfuscates real-time browsing patterns in the Tor network and complicates
+predictions of when it is safe to assume no audit will take place. If memory
+becomes a scarce resource, pending triplets should be deleted at
+random~\cite{nordberg}. Figure~\ref{ctor:fig:audit-after} shows that $t$ takes the
+log's MMD into account. This prevents an \emph{early signal} to the issuing CT
+logs that an SFO is being audited.  For example, if an SFO is audited before the
+MMD elapsed, then the issuing CT log could simply merge the underlying
+certificate chain to avoid any MMD violation. However, by taking the MMD into
+account, this results in a relatively large time window during which the
+attacker can attempt to \emph{flood} all CTRs in hope that they delete the
+omitted SFO at random before it is audited. We discuss the threat of flooding
+further in Section~\ref{ctor:sec:analysis}, noting that such an attack can
+be detected if CTRs publish two new metrics in the extra-info document:
+\texttt{ct-receive-bytes} and \texttt{ct-delete-bytes}. These metrics indicate
+how many SFO bytes were received and deleted throughout different time
+intervals, which is similar to other extra-info metrics such as
+\texttt{read-history} and \texttt{write-history}.
+
+\subsection{Phase 3: Auditing} \label{ctor:sec:base:phase3}
+
+As alluded to in phase 2, there is a second problem why the simple behavior of
+``contact the log and request an inclusion proof'' is unacceptable. We include
+the ability to DoS an individual Tor relay in our threat model---if the log
+knows which CTR holds the evidence of its misbehavior, it can take the CTR
+offline, wiping the evidence of the log's misbehavior from its memory. 
+
+We can address this concern in a few ways. The simple proposal of contacting the
+log over a Tor circuit will not suffice:
+	a log can tag each CTR by submitting unique SFOs to them all, and
+	recognize the CTR when they are submitted (see
+	Section~\ref{ctor:sec:analysis}).
+Even using a unique Tor circuit for each SFO might not suffice to prevent
+effective tagging attacks. For example, after tagging all CTRs, a malicious log
+could ignore all but innocuous untagged requests and tagged requests matching
+tags for whichever CTR it decides to respond to first. If some kind of
+back-off is supported (common to delay retransmissions and avoid congestion),
+the rest of the CTRs will likely be in back-off so that there is a high
+probability that the first CTR is the one fetching proofs.  The log can repeat
+this process---alternating tagged CTRs it replies to---until it receives the
+offending SFO from an identifiable CTR with high probability.  CTRs may report
+the log as inaccessible for days, but that is not the same as direct
+cryptographic evidence of misbehavior.
+
+While there are ways to detect this attack after-the-fact, and there may be ways
+to mitigate it, a more robust design would tolerate the disclosure of a CTRs
+identity to the log during the auditing phase without significant security
+implications.  A simple appealing approach is to write the data to disk prior
+to contacting the log; however, Tor relays are explicitly designed not to write
+data about user behavior to disk unless debug-level logging is enabled. Relay
+operators have expressed an explicit desire to never have any user data
+persisted to disk, as it changes the risk profile of their servers with regards
+to search, seizure, and forensic analysis.
+
+The final design is to have the CTR work with a partner CTR---we call it a
+\emph{watchdog}---that they choose at random and contact over a circuit. Prior
+to attempting to fetch a proof from a log, the CTR provides the watchdog with
+the SFO it is about to audit. After an appropriate response from the log, the
+CTR tells the watchdog that the SFO has been adequately addressed.
+
+In more detail, each CTR maintains a single shared circuit that is used to
+interact with all CT logs known to the CTR (we are not using one circuit per
+SFO given the overhead and unclear security benefit noted above). For
+\emph{each} such log $l$, the CTR runs the following steps: %indefinitely:
+\begin{enumerate}
+    \item\label{ctor:enm:auditing:backoff} Sample a delay $d \gets
+        \mathsf{random}(\texttt{ct-backoff-dist})$ and wait until $d$ time units
+        elapsed.
+    \item Connect to a random watchdog CTR\@.
+    \item\label{ctor:enm:auditing:loop} For each pending buffer entry $(l',s,t)$,
+    where $l' = l$ and $t <= \mathsf{now}()$:
+		\begin{enumerate}
+			\item\label{ctor:enm:ext:auditing:watchdog} Share $s$ with the current
+				watchdog.
+			\item\label{ctor:enm:ext:auditing:challenge} Challenge the log to prove
+                                  inclusion to the closest STH in the Tor
+								  consensus where $t$ $\leq$
+								  STH\texttt{.timestamp}. Wait
+								  \texttt{ct-log-timeout} time units for the
+								  complete proof before timing out.
+				\begin{itemize}
+					\item\label{ctor:enm:ext:auditing:challenge:success} On valid
+						proof: send an acknowledgment to the watchdog, cache $s$
+						and then discard it.
+					\item\label{ctor:enm:ext:auditing:challenge:fail} On any other
+						outcome: close circuit to the watchdog CTR, discard $s$,
+						and go to step~1.
+				\end{itemize}
+		\end{enumerate}
+\end{enumerate}
+
+\subsection{Phase 4: Reporting}
+
+At any given time, a CTR may be requesting inclusion proofs from logs and act as
+a watchdog for one or more CTRs. A CTR acting as a watchdog will have at
+most one SFO held temporarily for each other CTR it is interacting with. If an
+acknowledgement from the other CTR is not received within
+\texttt{ct-watchdog-timeout}, it becomes the watchdog's responsibility to report
+the SFO such that it culminates in human review if need be.
+
+Because human review and publication is critical at this end-stage, we envision
+that the watchdog (which is a Tor relay that cannot persist any evidence to disk
+and may not be closely monitored by its operator) provides the SFO to an
+independent CT auditor that is run by someone that closely monitors its
+operation. When arriving at the design of the CTR being a
+role played by a Tor relay, we eschewed separate auditors because of the lack of
+automatic scaling with the Tor network, the considerable aggregation of browsing
+behavior across the Tor network, and the difficulties of curation and validation
+of trustworthy individuals. SFOs submitted to auditors at this stage have been
+filtered through the CTR layer (that additionally backs-off if the logs become
+unavailable to prevent an open pipe of SFOs from being reported), resulting in
+an exponentially smaller load and data exposure for auditors. This should allow
+for a smaller number of them to operate without needing to scale with the
+network.
+
+While we assume that most auditors are trusted to actually investigate the
+reported SFOs further, the watchdog needs to take precautions talking to them
+because the network is not trusted.\footnote{%
+	While our threat model, and Tor's, precludes a global network adversary,
+	both include partial control of the network.
+}  The watchdog can contact the auditor immediately, but must do so over
+an independent Tor circuit.\footnote{%
+	This is also important because CTRs are not necessarily exits, i.e., the
+	exiting traffic must be destined to another Tor relay.
+}  If a successful acknowledgement from the auditor is not received within
+\texttt{ct-auditor-timeout}, the SFO is buffered for a random time using
+\texttt{ct-delay-dist} before being reported to the same auditor again over a
+new independent Tor circuit.
+
+When an auditor receives an SFO, it should persist it to durable storage until
+it can be successfully resolved to a specific STH.\footnote{%
+	The fetched inclusion proof must be against the first known STH that
+	should have incorporated the certificate in question by using the
+	history of STHs in Tor's consensus:
+		the mis-issued certificate might have been merged into the log
+		reactively upon learning that a CTR reported the SFO, such that a valid
+		inclusion proof can be returned with regards to a more recent STH but
+		not earlier ones that actually captured the log's misbehavior.
+}  Once so persisted, the auditor can begin querying the log itself asking for
+an inclusion proof. If no valid inclusion proof can be provided after some
+threshold of time, the auditor software should raise the details to a human
+operator for investigation.
+
+Separately, the auditor should be retrieving the current Tor consensus and
+ensuring that a consistency proof can be provided between STHs from the older
+consensus and the newer. If consistency cannot be established after some
+threshold of time, the auditor software should raise the details to a human
+operator for investigation. An auditor could also monitor a log's uptime and
+report on excessive downtime. Finally, it is paramount that the auditor
+continuously monitors its own availability from fresh Tor-circuits by submitting
+known SFOs to itself to ensure that an attacker is not keeping watchdogs from
+connecting to it.
+
+\subsection{Setup} \label{ctor:sec:base:consensus}
+
+There are a number of additional details missing to setup phases 1--4 for the
+design. Most of these details relate to the Tor consensus. Directory authorities
+influence the way in which Tor Browser and CTRs behave by voting on necessary
+parameters, such as the probability of submission of an SFO
+(\texttt{ct-submit-pr}) and the timeout used by CTRs when auditing CT logs
+(\texttt{ct-log-timeout}), as introduced earlier as part of the design. See
+Appendix~\ref{ctor:app:consensus-params} for details on these parameters and their
+values that were previously used. Next, we briefly introduce a number of
+implicitly used parts from our design that should also be part of the consensus.
+
+In the consensus, the existing \texttt{known-flags} item determines the
+different flags that the consensus might contain for relays.  We add another
+flag named \texttt{CTR}, which indicates that a Tor relay should support
+CT-auditing as described here. A relay qualifies as a CTR if it is flagged as
+\texttt{stable} and not \texttt{exit}, to spare the relatively sparse exit
+bandwidth and only use relays that can be expected to stay online.
+Section~\ref{ctor:sec:privacy} discusses trade-offs in the assignment of the
+\texttt{CTR} flag.
+
+The consensus should also capture a fixed view of the CT log ecosystem by
+publishing STHs from all known logs.  A CT log is known if a majority of
+directory authorities proposed a \texttt{ct-log-info} item, which contains a
+log's ID, public key, base URL, MMD, and most recent STH.  Each directory
+authority proposes its own STH, and agrees to use the most recent STH as
+determined by timestamp and lexicographical order.  Since CTRs verify inclusion
+with regards to SCTs that Tor Browser accepts, the CT logs recognized by Tor
+Browser must be in Tor's consensus.
+
+Tor's directory authorities also majority-vote on \texttt{ct-auditor} items,
+which pin base URLs and public keys of CT auditors that watchdogs contact in
+case that any log misbehavior is suspected. 
diff --git a/summary/src/ctor/src/introduction.tex b/summary/src/ctor/src/introduction.tex
new file mode 100644
index 0000000..2206ec5
--- /dev/null
+++ b/summary/src/ctor/src/introduction.tex
@@ -0,0 +1,183 @@
+\section{Introduction} \label{ctor:sec:introduction}
+Metrics reported by Google and Mozilla reveal that encryption on the web
+skyrocketed the past couple of years: at least 84\% of all web pages load using
+HTTPS~\cite{google-metrics,mozilla-metrics}. An HTTPS connection is initiated by
+a TLS handshake where the client's web browser requires that the web server
+presents a valid certificate to authenticate the identity of the server, e.g.,
+to make sure that the client who wants to visit \texttt{mozilla.org} is really
+connecting to Mozilla, and not, say, Google. A certificate specifies the
+cryptographic key-material for a given domain name, and it is considered valid
+if it is digitally signed by a Certificate Authority (CA) that the web browser
+trusts.
+
+It is a long-known problem that the CA trust model suffers from
+weakest-link security:
+	web browsers allow hundreds of CAs to sign arbitrary domain-name to
+		key-bindings,
+	which means that it suffices to compromise a single CA to acquire any
+		certificate~\cite{https-sok,ca-ecosystem}.
+Motivated by prominent CA compromises, such as the issuance of fraudulent
+certificates for
+	\texttt{*.google.com},
+	\texttt{*.mozilla.org} and
+	\texttt{*.torproject.org}
+by DigiNotar~\cite{diginotar}, multiple browser vendors mandated
+that certificates issued by CAs must be publicly disclosed in Certificate
+Transparency (CT) logs to be valid.  The idea behind CT is that, by making all
+CA-issued certificates transparent, mis-issued ones can be detected
+\emph{after the fact}~\cite{ct/a,ct,ct/bis}.  The appropriate actions can then
+be taken to keep the wider web safe, e.g., by
+	investigating the events that lead up to a particular incident,
+	removing or limiting trust in the offending CA, and
+	revoking affected certificates.
+Google Chrome and Apple's Safari currently enforce CT by augmenting the TLS
+handshake to require cryptographic proofs from the server that the presented
+certificate \emph{will appear} in CT logs that the respective web browsers
+trust~\cite{apple-log-policy,google-log-policy}.
+
+In addition to increased encryption on the web, the ability to access it
+anonymously matured as well.  Tor with its Tor Browser has millions of daily
+users~\cite{tor,mani}, and efforts are ongoing to mature the technology 
+for wider use~\cite{fftor}.  Tor Browser builds on-top of Mozilla's Firefox:
+	it relays traffic between the user and the web server in question by routing
+		everything through the Tor network,
+	which is composed of thousands of volunteer-run relays that are located
+		across the globe~\cite{relay-by-flag}.
+Just like attackers may wish to break security properties of HTTPS, it may also
+be of interest to break the anonymity provided by Tor.  A common technique for
+deanonymization (known to be used in practice) is to compromise Tor
+Browser instead of circumventing the anonymity provided by
+Tor~\cite{lepop1,selfrando,lepop2,zerotor}.  Web browsers like Firefox
+(or forks thereof) are one of the most complex software types that are widely
+used today, leading to security vulnerabilities and clear incentives for
+exploitation.  For example, the exploit acquisition platform Zerodium offers up
+to \$$100,000$ for a Firefox zero-day exploit that provides remote code
+execution and local privilege escalation (i.e., full control of the
+browser)~\cite{zeromain}.
+
+An attacker that wishes to use such an exploit to compromise and then ultimately
+deanonymize a Tor Browser user has to deliver the exploit somehow.  Since the
+web is mostly encrypted, this primarily needs to take place over an HTTPS
+connection where the attacker controls the content returned by the web server.
+While there are numerous possible ways that the attacker can accomplish this,
+e.g., by compromising a web server that a subset of Tor Browser users visit,
+another option is to \emph{impersonate} one or more web servers by acquiring
+fraudulent certificates. Due to the Tor network being run by volunteers, getting
+into a position to perform such an attack is relatively straightforward:
+	the attacker can volunteer to run malicious exit
+		relays~\cite{spoiled-onions}.
+The same is true for an attacker that wishes to man-in-the-middle connections
+made by Tor Browser users.  In some cases a Tor Browser exploit may not even be
+needed for deanonymization, e.g., the attacker can observe if the user logs-on
+to a service linking an identity.
+
+\subsection{Introducing CTor}
+We propose an incrementally deployable and privacy-preserving design that is
+henceforth referred to as CTor.  By bringing CT to Tor, HTTPS-based
+man-in-the-middle attacks against Tor Browser users can be detected \emph{after
+the fact} when conducted by attackers that:
+\begin{enumerate}
+	\item can acquire any certificate from a trusted CA,
+	\item with the necessary cryptographic proofs from enough CT logs so that
+		Tor Browser accepts the certificate as valid without the attacker
+		making it publicly available in any of the controlled logs, and
+	\item with the ability to gain full control of Tor Browser shortly after
+		establishing an HTTPS connection.
+\end{enumerate}
+
+The first and third capabilities are motivated directly by shortcomings in the
+CA ecosystem as well as how the anonymity of Tor Browser is known to be
+attacked.  The second capability assumes the same starting point as Google
+Chrome and Apple's Safari, namely, that the logs are trusted to \emph{promise}
+public logging, which is in contrast to being untrusted and thus forced to
+\emph{prove} it.  This is part of the gradual CT deployment that avoided
+breakage on the web~\cite{does-ct-break-the-web}.  Therefore, we start
+from the assumption that Tor Browser accepts a certificate as valid if 
+accompanied by two independent promises of public logging.  The limitation of
+such CT enforcement is that it is trivially bypassed by an attacker that
+controls two seemingly independent CT logs.  This is not to say that trusting
+the log ecosystem would be an insignificant Tor Browser improvement when
+compared to no CT at all, but CTor takes us several steps further by relaxing
+and ultimately eliminating the trust which is currently (mis)placed in today's
+browser-recognized CT logs.
+We already observed instances of CT logs that happened to
+	violate their promises of public logging~\cite{gdca1-omission},
+	show inconsistent certificate contents to different
+		parties~\cite{izenpe-disqualified,venafi-disqualified}, and
+	get their secret signing keys compromised due to disclosed remote
+		code-execution vulnerabilities~\cite{digicert-log-compromised}. 
+
+The first design increment uses the CT landscape against the attacker to
+ensure a non-zero (tweakable) probability of public disclosure \emph{each time}
+a fraudulent certificate is used against Tor Browser.  This is done by randomly
+adding a subset of presented certificates to CT logs that the attacker may not
+control (inferred from the accompanied promises of public logging).  Such
+\emph{certificate cross-logging} distributes trust across all CT logs, raising
+the bar towards unnoticed certificate mis-issuance.  Motivated by factors like
+privacy, security and deployability, Tor Browser uses Tor relays as
+intermediates to cache and interact with CT logs on its behalf.  Such deferred
+auditing is a fundamental part of our setting unless future distributed auditing
+mechanisms turn out to be non-interactive from the browser's perspective.
+
+The next incremental step is to not only cross-log certificates but also their
+promises of public logging.  While it requires an additional CT log API
+endpoint, it facilitates auditing of these promises if some logs are
+trustworthy.  The full design also holds logs accountable but without any such
+assumption:
+	Tor relays challenge the logs to prove correct operation with regards to a
+		single fixed view in Tor's consensus, and
+	potential issues are reported to auditors that investigate them further.
+
+\subsection{Contribution and Structure}
+Section~\ref{ctor:sec:background} introduces background on the theory and practise of
+CT, as well as the anonymity network Tor.  Section~\ref{ctor:sec:adversary} motivates
+the intended attacker and presents a unified threat model for CT and Tor.
+Section~\ref{ctor:sec:base} describes the full CTor design that \emph{eliminates all
+trust in the browser-recognized CT logs} by challenging them to prove
+certificate inclusion cryptographically, and would result in a \emph{single
+probabilistically-verified view of the CT log ecosystem available from Tor's
+consensus}.  This view could be used by other browsers as the basis of trust,
+\emph{greatly improving the security posture of the entire web}.  The security
+analysis in Section~\ref{ctor:sec:analysis} shows that one of the best bets for the
+attacker would be to take network-wide actions against Tor to avoid public
+disclosure of certificate mis-issuance and log misbehavior.  Such an attack is
+trivially detected, but it is hard to attribute unless reactive defenses are
+enabled at the cost of trade-offs.
+
+The full design involves many different components that add deployment burdens,
+such as the requirement of reliable CT auditors that investigate suspected log
+misbehavior further.  Therefore, we additionally propose two initial increments
+that place \emph{some trust in CT logs} (Section~\ref{ctor:sec:incremental}).  The
+first increment \emph{provides evidence to independent CT logs that fraudulent
+certificates were presented while preserving privacy}.  This greatly impacts
+risk-averse attackers because one part of their malicious behavior becomes
+transparent \emph{if the randomly selected log operator is benign}.  For
+example, the targeted domain name is disclosed as part of the cross-logged
+certificate, and awareness of the event draws unwanted attention.
+
+The next increment is minor from the perspective of Tor, but requires CT logs to
+support an additional API.  Similar changes were proposed in the context of CT
+gossip~\cite{minimal-gossip}.  If supported, Tor relays could expose both the
+mis-issued certificates and the operators that promised to log them publicly
+\emph{without the complexity of ever distinguishing between what is benign and
+fraudulent}.
+This API change happens to also build auditor infrastructure
+directly into CT log software, thereby paving the path towards the missing component of
+the full design.  We argue that CTor can be deployed incrementally:
+	complete Firefox's CT enforcement~\cite{ffct},
+	add our cross-logging increments, and
+	finally put the full design into operation.
+Each part of CTor would \emph{greatly contribute to the open question of how
+to reduce and/or eliminate trust in browser-recognized log operators}, which is
+caused by the lack of an appropriate gossip mechanism as well as privacy issues
+while interacting with the logs~\cite{ct-with-privacy,minimal-gossip,nordberg}.
+
+We show that circuit-, bandwidth- and memory-\emph{overheads are modest} by
+computing such estimates in Section~\ref{ctor:sec:performance}.  Therefore, we do not
+investigate performance further in any experimental setting.
+Section~\ref{ctor:sec:privacy} discusses privacy aspects of our design choices with
+a focus on the essential role of the Tor network's distributed nature to
+preserve user privacy as well as the overall security.  In gist,
+\emph{a similar approach would be privacy-invasive without Tor}, e.g., if
+adopted by Google Chrome.  Section~\ref{ctor:sec:related} outlines related work.
+Section~\ref{ctor:sec:conclusion} concludes the paper.
diff --git a/summary/src/ctor/src/performance.tex b/summary/src/ctor/src/performance.tex
new file mode 100644
index 0000000..e641ba1
--- /dev/null
+++ b/summary/src/ctor/src/performance.tex
@@ -0,0 +1,142 @@
+\section{Performance} \label{ctor:sec:performance}
+The following analysis shows that CTor's overhead is modest based on computing
+performance estimates from concrete parameter properties and two public data
+sets.
+
+\subsection{Setup}
+Mani~\emph{et~al.} derived a distribution of website visits over Tor and an
+estimation of the number of circuits through the network~\cite{mani}.  We use
+their results to reason about overhead as the Tor network is under heavy load,
+assuming 140~million daily website visits (the upper bound of a 95\% confidence
+interval).  Our analysis also requires a distribution that captures typical SFO
+properties per website visit.  Therefore, we collected an SFO data set by
+browsing the most popular webpages submitted to Reddit (r/frontpage, all time)
+on December 4, 2019.  The data set contains SFOs from 8858 webpage visits, and
+it is available online as an open access artifact together with the associated
+scripts~\cite{sfo-dist}.  Notably we hypothesized that browsing actual webpages
+as opposed to front-pages would yield more SFOs.  When compared to Alexa's
+list it turned out to be the case:
+	our data set has roughly two additional SFOs per data point.
+This makes it less likely that our analysis is an underestimate.
+
+We found that an average certificate chain is 5440~bytes, and it is seldom
+accompanied by more than a few SCTs.  As such, a typical SFO is in the order of
+6~KiB.  No certificate chain exceeded 20~KiB, and the average number of SFOs per
+webpage was seven.  The latter includes 1--2 SFOs per data point that followed
+from our client software calling home on start-up (Chromium~77).
+
+We assume no abnormal CTor behavior, which means that there will be little or
+no CTR back-offs due to the high uptime requirements of today's CT logs: 99\%.
+We set \texttt{ct-large-sfo-size} conservatively to avoid blocking in the TLS
+handshake (e.g., 20~KiB), and use a 10\% submission probability as well as a
+10~minute random buffer delay on average.  It is likely unwarranted to use a
+higher submission probability given that the intended attacker is risk-averse.
+Shorter buffer times would leak finer-grained browsing patterns to the logs,
+while longer ones increase the attack surface in phase~2.  Therefore, we
+selected an average for \texttt{ct-delay-dist} that satisfies none of the two
+extremes.  The remaining CTor parameters are timeouts, which have little or no
+performance impact if set conservatively (few seconds).
+
+\subsection{Estimates} \label{ctor:sec:performance:estimates}
+The incremental cross-logging designs are analyzed first without any caching.
+Caching is then considered, followed by overhead that appears only in the full
+design.
+
+\textbf{Circuit Overhead.}
+Equation~\ref{ctor:eq:sub-oh} shows the expected circuit overhead from Tor Browser
+over time, where $p$ is the submit probability and $\bar{d}$ the average number
+of SFOs per website visit.  The involved overhead is linear as either of the two
+parameters are tuned up or down.
+
+\begin{equation} \label{ctor:eq:sub-oh}
+	p\bar{d}
+\end{equation}
+
+Using $p\gets\frac{1}{10}$ and our approximated SFO distribution $\bar{d}\gets7$
+yields an average circuit overhead of $0.70$, i.e., for every three Tor Browser
+circuits CTor adds another two.  Such an increase might sound
+daunting at first,\footnote{%
+	Circuit establishment involves queueing of onionskins~\cite{onionskins} and
+	it is a likely bottleneck, but since the introduction of ntor it is not a
+	scarce resource so such overhead is acceptable if it (i) serves a purpose,
+	and (ii) can be tuned.  Confirmed by Tor developers.
+} but these additional circuits are short-lived and light-weight; transporting
+6~KiB on average.  Each CTR also maintains a long-lived circuit for CT log
+interactions.
+
+\textbf{Bandwidth Overhead.}  Equation~\ref{ctor:eq:bw} shows the expected
+bandwidth overhead for the Tor network over time, where
+	$V$ is the number of website visits per time unit,
+	$p$ the submit probability,
+	$\bar{d}$ the average number of SFOs per website visit, and
+	$\bar{s}$ the average SFO byte-size.
+
+\begin{equation} \label{ctor:eq:bw}
+	6Vp\bar{d}\bar{s}
+\end{equation}
+
+$Vp\bar{d}$ is the average number of SFO submissions per time unit, which can be
+converted to bandwidth by weighting each submission with the size of
+a typical SFO and accounting for it being relayed six times:
+	three hops from Tor Browser to a CTR, then
+	another three hops from the CTR to a CT log
+	(we assumed symmetric Tor relay bandwidth).
+Using
+	$V\gets 140\textrm{~M/day}$,
+	$p \gets \frac{1}{10}$,
+	$\bar{d} \gets 7$,
+	$\bar{s} \gets 6\textrm{~KiB}$
+and converting the result to bps yields 334.5~Mbps in total.  Such order of
+overhead is small when compared to Tor's capacity:
+450~Gbps~\cite{tor-bandwidth}.
+
+\textbf{Memory Overhead.}
+Equation~\ref{ctor:eq:memory} shows the expected buffering overhead, where
+	$V_m$ is the number of website visits per minute,
+	$t$ the average buffer time in minutes,
+	$R$ the number of Tor relays that qualify as CTRs, and
+	$\bar{s}$ the typical SFO size in bytes.
+
+\begin{equation} \label{ctor:eq:memory}
+	\frac{V_mt}{R} \bar{s}
+\end{equation}
+
+$V_mt$ represent incoming SFO submissions during the average buffer time, which
+are randomly distributed across $R$ CTRs.  Combined, this yields the expected
+number of SFOs that await at a single CTR in phase~2, and by taking the
+byte-size of these SFOs into account we get an estimate of the resulting memory
+overhead.  Using
+	$V_m \gets \frac{140\textrm{~M}}{24\cdot60}$,
+	$t \gets 10$~m,
+	$R \gets 4000$ based on the CTR criteria in
+		Section~\ref{ctor:sec:base:consensus}, and
+	$\bar{s} \gets 6\textrm{~KiB}$
+yields 1.42~MiB.  Such order of overhead is small when compared to the
+recommended relay configuration:
+	at least 512~MiB~\cite{relay-config}.
+
+A cache of processed SFOs reduces the CTR's buffering memory and log
+interactions proportionally to the cache hit ratio.  Mani~\emph{et al.} showed
+that if the overrepresented \texttt{torproject.org} is removed, about one third
+of all website visits over Tor can be attributed to Alexa's top-1k and another
+one third to the top-1M~\cite{mani}.
+Assuming 32~byte cryptographic hashes and seven SFOs per website visit, a cache
+hit ratio of $\frac{1}{3}$ could be achieved by a 256~KiB LFU/LRU cache that
+eventually captures Alexa's top-1k.  Given that the cache requires memory as
+well, this is mainly a bandwidth optimization.
+
+\textbf{Full Design.}
+For each CTR and CT log pair, there is an additional watchdog circuit that
+transports the full SFO upfront before fetching an inclusion proof.  The
+expected bandwidth overhead is at most $9Vp\bar{d}\bar{s}$, i.e., now
+also accounting for the three additional hops that an SFO is subject to.  In
+practise the overhead is slightly less, because an inclusion query and its
+returned proof is smaller than an SFO.  We expect little or no
+watchdog-to-auditor overhead if the logs are available, and otherwise one
+light-weight circuit that reports a single SFO for each CTR that goes into
+back-off.  Such overhead is small when compared to all Tor Browser submissions.
+Finally, the required memory increases because newly issued SFOs are buffered
+for at least an MMD.  Only a small portion of SFOs are newly issued, however:
+	the short-lived certificates of Let's Encrypt are valid for
+	90~days~\cite{le}, which is in contrast to 24~hour
+	MMDs~\cite{google-log-policy}.
diff --git a/summary/src/ctor/src/privacy.tex b/summary/src/ctor/src/privacy.tex
new file mode 100644
index 0000000..2738dba
--- /dev/null
+++ b/summary/src/ctor/src/privacy.tex
@@ -0,0 +1,48 @@
+\section{Privacy} \label{ctor:sec:privacy}
+There is an inherent privacy problem in the setting due to how CT is designed
+and deployed. A browser, like Tor Browser, that wishes to validate that SFOs presented to
+it are \emph{consistent} and \emph{included} in CT logs must directly or
+indirectly interact with CT logs wrt. its observed SFOs. Without protections
+like Private Information Retrieval (PIR)~\cite{PIR} that require server-side
+support or introduction of additional parties and trust
+assumptions~\cite{kales,lueks-and-goldberg}, exposing SFOs to any party risks
+leaking (partial) information about the browsing activities of the user.
+
+Given the constraints of the existing CT ecosystem, CTor is made
+privacy-preserving thanks to the distributed nature of Tor with its anonymity
+properties and high-uptime relays that make up the Tor network. First, all
+communication between Tor Browser, CTRs, CT logs, and auditors are made over
+full Tor-circuits. This is a significant privacy-gain, not available, e.g., to
+browsers like Chrome that in their communications would reveal their public
+IP-address (among a number of other potentially identifying metadata). Secondly,
+the use of CTRs as intermediaries probabilistically delays the interaction with
+the CT logs---making correlating Tor Browser user browsing with CT log
+interaction harder for attackers---and safely maintains a dynamic cache of the
+most commonly already verified SFOs. While browsers like Chrome could maintain a
+cache, Tor Browser's security and privacy goals
+(Section~\ref{ctor:sec:background:tor}) prohibit such shared (persisted) dynamic
+state.
+
+In terms of privacy, the main limitation of CTor is that CTor continuously leaks
+to CT logs---and to a \emph{lesser extent} auditors (depending on design)---a
+fraction of certificates of websites visited using Tor Browser to those that
+operate CT logs. This provides to a CT log a partial list of websites visited
+via the Tor network over a period of time (determined by
+\texttt{ct-delay-dist}), together with some indication of distribution based on
+the number of active CTRs. It does not, however, provide even pseudonymously any
+information about which sites individual users visit, much less with which
+patterns or timing. As such it leaks significantly less information than does
+OCSP validation by Tor Browser or DNS resolution at exit-relays~\cite{TorDNS},
+both of which indicate visit activity in real time to a small number of
+entities.
+
+Another significant limitation is that relays with the CTR flag learn real-time
+browser behavior of Tor users. Relays without the \texttt{exit} flag primarily
+only transport encrypted Tor-traffic between clients and other relays, never to
+destinations. If such relays are given the CTR flag---as we stated in the full
+design, see Section~\ref{ctor:sec:base:consensus}---then this might discourage some
+from running Tor relays unless it is possible to opt out. Another option is to
+give the CTR flag only to exit relays, but this \emph{might be} undesirable for
+overall network performance despite the modest overhead of CTor
+(Section~\ref{ctor:sec:performance}). Depending on the health of the network and the
+exact incremental deployment of CTor, there are different trade-offs.
diff --git a/summary/src/ctor/src/ref.bib b/summary/src/ctor/src/ref.bib
new file mode 100644
index 0000000..b39ae33
--- /dev/null
+++ b/summary/src/ctor/src/ref.bib
@@ -0,0 +1,536 @@
+@misc{apple-on-independence,
+	author = {Clint Wilson},
+	title = {{CT} Days 2020},
+	howpublished = {\url{https://groups.google.com/a/chromium.org/g/ct-policy/c/JWVVhZTL5RM}, accessed 2020-12-15}
+}
+
+@misc{onionskins,
+	author = {{Tor Project}},
+	title = {Functions to queue create cells for processing},
+	howpublished = {\url{https://src-ref.docs.torproject.org/tor/onion__queue_8c_source.html}, accessed 2020-12-15},
+}
+
+@misc{delayed-merge,
+	author = {{Google LLC.}},
+	title = {Trillian Log Signer},
+	howpublished = {\url{https://github.com/google/trillian/blob/master/cmd/trillian_log_signer/main.go}, accessed 2020-12-15},
+}
+
+@misc{stark,
+	title = {Opt-in {SCT} Auditing},
+	author = {Emily Stark and Chris Thompson},
+	howpublished = {\url{https://docs.google.com/document/d/1G1Jy8LJgSqJ-B673GnTYIG4b7XRw2ZLtvvSlrqFcl4A/edit}, accessed 2020-12-15},
+}
+
+@article{meiklejohn,
+  author    = {Sarah Meiklejohn and Pavel Kalinnikov and Cindy S. Lin and Martin Hutchinson and Gary Belvin and Mariana Raykova and Al Cutter},
+  title     = {Think Global, Act Local: Gossip and Client Audits in Verifiable Data Structures},
+  journal   = {CoRR},
+  volume    = {abs/2011.04551},
+  year      = {2020},
+}
+
+@misc{sfo-dist,
+	author = {Rasmus Dahlberg and Tobias Pulls and Tom Ritter and Paul Syverson},
+	title = {{SFO} Distribution Artificat},
+	year = {2020},
+	howpublished = {\url{https://github.com/rgdd/ctor/tree/master/artifact}},
+}
+
+@misc{ct-policy-mailing-list,
+	author = {{CT policy mailing list}},
+	title = {{Certificate Transparency} Policy},
+	howpublished = {\url{https://groups.google.com/a/chromium.org/forum/\#!forum/ct-policy}, accessed 2020-12-15},
+}
+
+@misc{no-hard-fail,
+	author = {Adam Langley},
+	title = {No, don't enable revocation checking},
+	howpublished = {\url{https://www.imperialviolet.org/2014/04/19/revchecking.html}, accessed 2020-12-15},
+}
+
+@misc{de-anonymize-exploit,
+	author = {Joseph Cox},
+	title = {The {FBI} Used a 'Non-Public' Vulnerability to Hack Suspects on {Tor}},
+	howpublished = {\url{https://www.vice.com/en_us/article/kb7kza/the-fbi-used-a-non-public-vulnerability-to-hack-suspects-on-tor}, accessed 2020-12-15},
+}
+
+@Misc{forbes-fbi-tor,
+  author = {Kashmir Hill},
+  title = {How Did The {FBI} Break {Tor}?},
+  howpublished = {\url{https://www.forbes.com/sites/kashmirhill/2014/11/07/how-did-law-enforcement-break-tor/#6cf2ed594bf7}, accessed 2020-12-15},
+}
+
+
+@Misc{doj-fbi-tor,
+  author = {{U.S. Dept. of Justice}},
+  title = {More Than 400 .Onion Addresses, Including Dozens of ‘Dark Market’ Sites, Targeted as Part of Global Enforcement Action on {Tor} Network},
+  howpublished = {\url{https://www.fbi.gov/news/pressrel/press-releases/more-than-400-.onion-addresses-including-dozens-of-dark-market-sites-targeted-as-part-of-global-enforcement-action-on-tor-network}, accessed 2020-12-15},
+}
+
+
+@Misc{syria-facebook-mitm,
+  author = {Peter Eckersley},
+  title = {A {Syrian} Man-In-The-Middle Attack against {Facebook}},
+  howpublished = {\url{https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook}, accessed 2020-12-15},
+}
+
+@misc{wiki-bgp,
+	author = {{Wikipedia contributors}},
+	title = {{BGP} hijacking---{Wikipedia}{,} The Free Encyclopedia},
+	howpublished = {\url{https://en.wikipedia.org/w/index.php?title=BGP_hijacking&oldid=964360841}, accessed 2020-12-15},
+}
+
+@misc{bgp-hijacking-for-crypto-2,
+	author = {Ameet Naik},
+	title = {Anatomy of a {BGP} Hijack on {Amazon’s} Route 53 {DNS} Service},
+	howpublished = {\url{https://blog.thousandeyes.com/amazon-route-53-dns-and-bgp-hijack}, accessed 2020-12-15},
+}
+
+@misc{bgp-hijacking-for-crypto,
+	author = {Joe Stewart},
+	title = {{BGP} Hijacking for Cryptocurrency Profit},
+	howpublished = {\url{https://www.secureworks.com/research/bgp-hijacking-for-cryptocurrency-profit}, accessed 2020-12-15},
+}
+
+@misc{myetherwallet,
+	author = {Russell Brandom},
+	title = {Hackers emptied {Ethereum} wallets by breaking the basic infrastructure of the {Internet}},
+	howpublished = {\url{https://www.theverge.com/2018/4/24/17275982/myetherwallet-hack-bgp-dns-hijacking-stolen-ethereum}, accessed 2020-12-15},
+}
+
+@Misc{ethereum-hijack-isoc,
+  author = {Aftab Siddiqui},
+  title = {What Happened? {The Amazon Route 53 BGP} Hijack to Take Over {Ethereum} Cryptocurrency Wallets},
+  howpublished = {\url{https://www.internetsociety.org/blog/2018/04/amazons-route-53-bgp-hijack/}, accessed 2020-12-15}}
+
+@Misc{iran-telegram-bgp,
+  author = {Patrick Howell O'Neill},
+  title = {Telegram traffic from around the world took a detour through {Iran}}, 
+  howpublished = {\url{https://www.cyberscoop.com/telegram-iran-bgp-hijacking/}, accessed 2020-12-15},
+}
+
+@misc{google-log-policy,
+	author = {{Google LLC.}},
+	title = {Chromium {Certificate Transparency} Policy},
+	howpublished = {\url{https://github.com/chromium/ct-policy/blob/master/README.md}, accessed 2020-12-15},
+}
+
+@misc{apple-log-policy,
+	author = {{Apple Inc.}},
+	title = {Apple's {Certificate Transparency} log program},
+	howpublished = {\url{https://support.apple.com/en-om/HT209255}, accessed 2020-12-15},
+}
+
+@misc{tor-bandwidth,
+	author = {{Tor project}},
+	title = {Advertised and consumed bandwidth by relay flag},
+	howpublished = {\url{https://metrics.torproject.org/bandwidth-flags.html}, accessed 2020-05-30},
+}
+
+@misc{relay-by-flag,
+	author = {{Tor project}},
+	title = {Relays by relay flag},
+	howpublished = {\url{https://metrics.torproject.org/relayflags.html}, accessed 2020-05-29},
+}
+
+@misc{relay-config,
+	author = {{Tor project}},
+	title = {Relay requirements},
+	howpublished = {\url{https://community.torproject.org/relay/relays-requirements/}, accessed 2020-05-29},
+}
+
+@misc{turktrust,
+	author = {Adam Langley},
+	title = {Enhancing digital certificate security},
+	howpublished = {\url{https://security.googleblog.com/2013/01/enhancing-digital-certificate-security.html}, accessed 2020-12-15},
+}
+
+@inproceedings{doublecheck,
+  author    = {Mansoor Alicherry and Angelos D. Keromytis},
+  title     = {{DoubleCheck}: Multi-path verification against man-in-the-middle attacks},
+  booktitle = {ISCC},
+  year      = {2009},
+}
+
+@misc{consensus-transparency,
+	author = {Linus Nordberg},
+	title = {{Tor} Consensus Transparency},
+	howpublished = {\url{https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/267-tor-consensus-transparency.txt}, accessed 2020-12-15},
+}
+
+@misc{sth-push,
+  author      = {Ryan Sleevi and Eran Messeri},
+  title       = {Certificate transparency in {Chrome}: Monitoring {CT} Logs consistency},
+  howpublished = {\url{https://docs.google.com/document/d/1FP5J5Sfsg0OR9P4YT0q1dM02iavhi8ix1mZlZe_z-ls/edit?pref=2&pli=1}, accessed 2020-12-15},
+}
+
+@misc{minimal-gossip,
+	author = {{Google LLC.}},
+	title = {Minimal Gossip},
+	howpublished = {\url{https://github.com/google/trillian-examples/blob/master/gossip/minimal/README.md}, accessed 2020-12-15},
+}
+
+@inproceedings{catena,
+  author    = {Alin Tomescu and Srinivas Devadas},
+  title     = {Catena: Efficient Non-equivocation via {Bitcoin}},
+  booktitle = {IEEE S\&P},
+  year      = {2017},
+}
+
+@inproceedings{chase,
+  author    = {Melissa Chase and Sarah Meiklejohn},
+  title     = {Transparency Overlays and Applications},
+  booktitle = {CCS},
+  year      = {2016},
+}
+
+@inproceedings{kales,
+  author    = {Daniel Kales and Olamide Omolola and Sebastian Ramacher},
+  title     = {Revisiting User Privacy for {Certificate Transparency}},
+  booktitle = {IEEE EuroS\&P},
+  year      = {2019},
+}
+
+@inproceedings{lueks-and-goldberg,
+  author    = {Wouter Lueks and Ian Goldberg},
+  title     = {Sublinear Scaling for Multi-Client Private Information Retrieval},
+  booktitle = {FC},
+  year      = {2015},
+}
+
+@misc{ct-over-dns,
+  author = {Ben Laurie},
+  title  = {{Certificate Transparency} over {DNS}},
+  howpublished = {\url{https://github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-over-dns.md}, accessed 2020-12-15},
+}
+
+@inproceedings{lwm,
+  author    = {Rasmus Dahlberg and Tobias Pulls},
+  title     = {Verifiable Light-Weight Monitoring for {Certificate Transparency} Logs},
+  booktitle = {NordSec},
+  year      = {2018},
+}
+
+@article{ct-with-privacy,
+  author    = {Saba Eskandarian and Eran Messeri and Joseph Bonneau and Dan Boneh},
+  title     = {{Certificate Transparency} with Privacy},
+  journal   = {PETS},
+  volume    = {2017},
+  number    = {4},
+}
+
+@inproceedings{ct-monitors,
+  author    = {Bingyu Li and Jingqiang Lin and Fengjun Li and Qiongxiao Wang and Qi Li and Jiwu Jing and Congli Wang},
+  title     = {{Certificate Transparency} in the Wild: Exploring the Reliability of Monitors},
+  booktitle = {CCS},
+  year      = {2019},
+}
+
+@inproceedings{syta,
+  author    = {Ewa Syta and Iulia Tamas and Dylan Visher and David Isaac Wolinsky and Philipp Jovanovic and Linus Gasser and Nicolas Gailly and Ismail Khoffi and Bryan Ford},
+  title     = {Keeping Authorities "Honest or Bust" with Decentralized Witness Cosigning},
+  booktitle = {IEEE S\&P},
+  year      = {2016},
+}
+
+@inproceedings{dahlberg,
+	author = {Rasmus Dahlberg and Tobias Pulls and Jonathan Vestin and Toke H{\o}iland-J{\o}rgensen and Andreas Kassler},
+	title = {Aggregation-Based {Certificate Transparency} Gossip},
+	booktitle = {SECURWARE},
+	year = {2019},
+}
+
+@inproceedings{secure-logging-and-ct,
+  author    = {Benjamin Dowling and Felix G{\"{u}}nther and Udyani Herath and Douglas Stebila},
+  title     = {Secure Logging Schemes and {Certificate Transparency}},
+  booktitle = {ESORICS},
+  year      = {2016},
+}
+
+@misc{tor-browser,
+	author = {Mike Perry and Erinn Clark and Steven Murdoch and Georg Koppen},
+	title = {The Design and Implementation of the {Tor Browser [DRAFT]}},
+	howpublished = {\url{https://2019.www.torproject.org/projects/torbrowser/design/}, accessed 2020-12-15},
+}
+
+@inproceedings{mani,
+  author    = {Akshaya Mani and T. Wilson{-}Brown and Rob Jansen and Aaron Johnson and Micah Sherr},
+  title     = {Understanding {Tor} Usage with Privacy-Preserving Measurement},
+  booktitle = {IMC},
+  year      = {2018},
+}
+
+@inproceedings{ct-root-landscape,
+  author    = {Nikita Korzhitskii and Niklas Carlsson},
+  title     = {Characterizing the Root Landscape of {Certificate Transparency} Logs},
+  booktitle = {IFIP Networking},
+  year      = {2020},
+}
+
+@inproceedings{spoiled-onions,
+  author    = {Philipp Winter and Richard K{\"{o}}wer and Martin Mulazzani and Markus Huber and Sebastian Schrittwieser and Stefan Lindskog and Edgar R. Weippl},
+  title     = {Spoiled Onions: Exposing Malicious {Tor} Exit Relays},
+  booktitle = {PETS},
+  year      = {2014},
+}
+
+@misc{gdca1-omission,
+	title = {Un-incorporated {SCTs} from {GDCA1}},
+	author = {Brendan McMillion},
+	howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/Emh3ZaU0jqI}, accessed 2020-12-15},
+}
+
+@misc{digicert-log-compromised,
+	title = {{CT2} Log Compromised via {Salt} Vulnerability},
+	author = {Jeremy Rowley},
+	howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/aKNbZuJzwfM}, accessed 2020-12-15},
+}
+
+@misc{izenpe-disqualified,
+	title = {Upcoming {CT} Log Removal: {Izenpe}},
+	author = {Ryan Sleevi},
+	howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/qOorKuhL1vA}, accessed 2020-12-15},
+}
+
+@misc{venafi-disqualified,
+	title = {Upcoming Log Removal: {Venafi} {CT} Log Server},
+	author = {Ryan Sleevi},
+	howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/KMAcNT3asTQ}, accessed 2020-12-15},
+}
+
+@inproceedings{does-ct-break-the-web,
+  author    = {Emily Stark and Ryan Sleevi and Rijad Muminovic and Devon O'Brien and Eran Messeri and Adrienne Porter Felt and Brendan McMillion and Parisa Tabriz},
+  title     = {Does {Certificate Transparency} Break the Web? {Measuring} Adoption and Error Rate},
+  booktitle = {IEEE S\&P},
+  year      = {2019},
+}
+
+@inproceedings{https-sok,
+  author    = {Jeremy Clark and Paul C. van Oorschot},
+  title     = {{SoK:} {SSL} and {HTTPS:} Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements},
+  booktitle = {IEEE S\&P},
+  year      = {2013},
+}
+
+@inproceedings{ca-ecosystem,
+  author    = {Zakir Durumeric and James Kasten and Michael Bailey and J. Alex Halderman},
+  title     = {Analysis of the {HTTPS} certificate ecosystem},
+  booktitle = {IMC},
+  year      = {2013},
+}
+
+@article{ct/a,
+  author    = {Ben Laurie},
+  title     = {Certificate transparency},
+  journal   = {CACM},
+  volume    = {57},
+  number    = {10},
+  year      = {2014},
+}
+
+@inproceedings{tor,
+  author    = {Roger Dingledine and Nick Mathewson and Paul F. Syverson},
+  title     = {Tor: The Second-Generation Onion Router},
+  booktitle = {USENIX Security},
+  year      = {2004},
+}
+
+@misc{rapid-tls13,
+	author = {Joseph A.\ Salowey and Sean Turner and Christopher A.\ Wood},
+	title = {{TLS} 1.3: One Year Later},
+	howpublished = {\url{https://www.ietf.org/blog/tls13-adoption}, accessed 2020-12-15},
+}
+
+@misc{chrome-ui,
+	author = {Emily Schechter},
+	title = {Evolving {Chrome's} Security Indicators},
+	howpublished = {\url{https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html}, accessed 2020-12-15},
+}
+
+@misc{firefox-ui,
+	author = {Johann Hofmann},
+	title = {Improved Security and Privacy Indicators in {Firefox} 70},
+	howpublished = {\url{https://blog.mozilla.org/security/2019/10/15/improved-security-and-privacy-indicators-in-firefox-70/}, accessed 2020-12-15}
+}
+
+@inproceedings{le,
+  author    = {Josh Aas and Richard Barnes and Benton Case and Zakir Durumeric and Peter Eckersley and Alan Flores{-}L{\'{o}}pez and J. Alex Halderman and Jacob Hoffman{-}Andrews and James Kasten and Eric Rescorla and Seth D. Schoen and Brad Warren},
+  title     = {{Let's Encrypt}: An Automated Certificate Authority to Encrypt the Entire Web},
+  booktitle = {CCS},
+  year      = {2019},
+}
+
+@misc{google-metrics,
+	author = {{Google LLC}},
+	title = {{HTTPS} encryption on the web},
+	howpublished = {\url{https://transparencyreport.google.com/https/overview?hl=en}, accessed 2020-05-19},
+}
+
+@misc{mozilla-metrics,
+	author = {{Mozilla}},
+	title = {{SSL} Ratios},
+	howpublished = {\url{https://docs.telemetry.mozilla.org/datasets/other/ssl/reference.html}, accessed 2020-05-19},
+}
+
+@techreport{nordberg,
+  author      = {Linus Nordberg and Daniel Kahn Gillmor and Tom Ritter},
+  title       = {Gossiping in {CT}},
+  number      = {draft-ietf-trans-gossip-05},
+  type        = {Internet-draft},
+  institution = {IETF},
+  year        = {2018},
+  url         = {https://tools.ietf.org/html/draft-ietf-trans-gossip-05}
+}
+
+@techreport{ct,
+	author = {Ben Laurie and Adam Langley and Emilia Kasper},
+	title =	 {{Certificate Transparency}},
+	number = {6962},
+	type = {RFC},
+	institution = {IETF},
+	year = {2013},
+	url = {https://tools.ietf.org/html/rfc6962},
+}
+
+@techreport{ct/bis,
+  author      = {Ben Laurie and Adam Langley and Emilia Kasper and Eran Messeri and Rob Stradling},
+  title       = {{Certificate Transparency} Version 2.0},
+  number      = {draft-ietf-trans-rfc6962-bis-34},
+  type        = {Internet-draft},
+  institution = {IETF},
+  year        = {2019},
+  url         = {https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-34},
+}
+
+@techreport{hpkp,
+	author = {Chris Evans and Chris Palmer and Ryan Sleevi},
+	title = {Public Key Pinning Extension for {HTTP}},
+	number = {7469},
+	type = {RFC},
+	institution = {IETF},
+	year = {2015},
+	url = {https://tools.ietf.org/html/rfc7469},
+}
+
+@inproceedings{chuat,
+  author    = {Laurent Chuat and Pawel Szalachowski and Adrian Perrig and Ben Laurie and Eran Messeri},
+  title     = {Efficient Gossip Protocols for Verifying the Consistency of Certificate Logs},
+  booktitle = {CNS},
+  year      = {2015},
+}
+
+@inproceedings{TorDNS,
+  author    = {Benjamin Greschbach and Tobias Pulls and Laura M. Roberts and Philipp Winter and Nick Feamster},
+  title     = {The Effect of {DNS} on {Tor's} Anonymity},
+  booktitle = {NDSS},
+  year      = {2017},
+}
+
+@inproceedings{trickle02,
+  author = {Andrei Serjantov and Roger Dingledine and Paul Syverson},
+  title = {From a Trickle to a Flood: Active Attacks on Several Mix Types},
+  booktitle = {IH},
+  year = {2002},
+}
+
+@inproceedings{kesdogan:ih1998,
+  title = {{Stop-and-Go} {MIX}es: Providing Probabilistic Anonymity in an Open System}, 
+  author = {Dogan Kesdogan and Jan Egner and Roland B\"uschkes}, 
+  booktitle = {IH},
+  year = {1998}, 
+}
+
+@inproceedings{danezis:pets2008,
+  author = {George Danezis and Paul Syverson},
+  title = {Bridging and Fingerprinting: Epistemic Attacks on Route Selection},
+  booktitle = {PETS},
+  year = {2008},
+}
+
+@inproceedings{long-paths,
+  author = 	 {Nathan S. Evans and Roger Dingledine and Christian Grothoff},
+  title = {A Practical Congestion Attack on {Tor} Using Long Paths},
+  booktitle = {USENIX Security},
+  year = {2009},
+}
+
+
+@misc{tor-documentation,
+  author = {{Tor Project}},
+  title = {Getting up to speed on {Tor's} past, present, and future},
+  howpublished = {\url{https://2019.www.torproject.org/docs/documentation.html.en}, accessed 2020-12-15},
+}
+
+@inproceedings{PIR,
+  author    = {Benny Chor and Oded Goldreich and Eyal Kushilevitz and Madhu Sudan},
+  title     = {Private Information Retrieval},
+  booktitle = {FOCS},
+  year      = {1995},
+}
+
+@inproceedings{DBLP:conf/pam/AmannS16,
+  author    = {Johanna Amann and Robin Sommer},
+  title     = {Exploring {Tor's} Activity Through Long-Term Passive {TLS} Traffic Measurement},
+  booktitle = {PAM},
+  year      = {2016},
+}
+
+@inproceedings{1mtrack,
+  author    = {Steven Englehardt and Arvind Narayanan},
+  title     = {Online Tracking: A 1-million-site Measurement and Analysis},
+  booktitle = {CCS},
+  year      = {2016},
+}
+
+@techreport{diginotar,
+  author = {J.R. Prins},
+  title = {{DigiNotar} Certificate Authority breach “Operation Black Tulip”}, 
+  institution = {Fox-IT},
+  year = {2011},
+  type = {Interim Report},
+}
+
+@misc{ffct,
+  author = {{Bugzilla}},
+  title = {Implement {Certificate Transparency} support ({RFC} 6962)},
+  howpublished = {\url{https://bugzilla.mozilla.org/show_bug.cgi?id=1281469}, accessed 2020-12-15},
+}
+
+@misc{fftor,
+  author = {{Mozilla}},
+  title = {Mozilla Research Grants {2019H1}},
+  howpublished = {\url{https://mozilla-research.forms.fm/mozilla-research-grants-2019h1/forms/6510}, accessed 2020-12-15},
+}
+
+@misc{zerotor,
+  author = {{Zerodium}},
+  title = {{Tor Browser} Zero-Day Exploit Bounty (Expired)},
+  howpublished = {\url{https://zerodium.com/tor.html}, accessed 2020-12-15},
+}
+
+@misc{zeromain,
+  author = {{Zerodium}},
+  title = {Our Exploit Acquisition Program},
+  howpublished = {\url{https://zerodium.com/program.html}, accessed 2020-05-21},
+}
+
+@misc{lepop1,
+  author = {{Catalin Cimpanu}},
+  title = {Exploit vendor drops {Tor Browser} zero-day on {Twitter}},
+  howpublished = {\url{https://www.zdnet.com/article/exploit-vendor-drops-tor-browser-zero-day-on-twitter/}, accessed 2020-12-15},
+}
+
+@misc{lepop2,
+  author = {{firstwatch at sigaint.org}},
+  title = {[tor-talk] Javascript exploit},
+  howpublished = {\url{https://lists.torproject.org/pipermail/tor-talk/2016-November/042639.html}, accessed 2020-12-15},
+}
+
+@article{selfrando,
+  author    = {Mauro Conti and Stephen Crane and Tommaso Frassetto and Andrei Homescu and Georg Koppen and Per Larsen and Christopher Liebchen and Mike Perry and Ahmad{-}Reza Sadeghi},
+  title     = {Selfrando: Securing the {Tor Browser} against De-anonymization Exploits},
+  journal   = {PETS},
+  volume    = {2016},
+  number    = {4},
+}
diff --git a/summary/src/ctor/src/related.tex b/summary/src/ctor/src/related.tex
new file mode 100644
index 0000000..cc5ae60
--- /dev/null
+++ b/summary/src/ctor/src/related.tex
@@ -0,0 +1,80 @@
+\section{Related Work} \label{ctor:sec:related}
+The status quo is to consider a certificate CT compliant if it is accompanied by
+two independent SCTs~\cite{google-log-policy,apple-on-independence}.  Therefore we
+proposed that Tor Browser should do the same, but unlike any other CT-enforcing
+web browser CTor also provides concrete next steps that relax the centralized
+trust which is otherwise misplaced in CT logs~\cite{%
+	gdca1-omission,%
+	digicert-log-compromised,%
+	izenpe-disqualified,%
+	venafi-disqualified%
+}.  Several proposals surfaced that aim to do better with regards to omissions
+and split-views.
+
+% Privacy preserving inclusion proofs
+Laurie proposed that inclusion proofs could be fetched over DNS to avoid
+additional privacy leaks, i.e., a user's browsing patterns are already exposed
+to the DNS resolver but not the logs in the CT landscape~\cite{ct-over-dns}.
+CT/bis provides the option of serving stapled inclusion proofs as part of the
+TLS handshake in an extension, an OCSP response, or the certificate
+itself~\cite{ct/bis}. Lueks and Goldberg proposed that a separate database of
+inclusion proofs could be maintained that supports information-theoretic
+PIR~\cite{lueks-and-goldberg}. Kales~\emph{et~al.} improved scalability by
+reducing the size of each entry in the PIR database at the cost of transforming
+logs into multi-tier Merkle trees, and additionally showed how the upper tier
+could be expressed as a two-server computational PIR database to ensure that any
+inclusion proof can be computed privately on-the-fly~\cite{kales}.
+Nordberg~\emph{et~al.} avoid inclusion proof fetching by hanging on to presented
+SFOs, handing them back to the same origin at a later time~\cite{nordberg}. In
+contrast, CTor protects the user's privacy without any persistent browser state
+by submitting SFOs on independent Tor circuits to CTRs, which in turn add random
+noise before there is any log interaction.  The use of CTRs enable caching
+similar to CT-over-DNS, but it does not put the logs in the dark like PIR could.
+
+% The same consistent view
+Inclusion proofs are only meaningful if everyone observes the same consistent
+STHs. One option is to configure client software with a list of entities that
+they should gossip with, e.g., CT monitors~\cite{chase}, or, browser vendors
+could push a verified view~\cite{sth-push}. Such trusted auditor relationships
+may work for some but not others~\cite{nordberg}. Chuat~\emph{et~al.} proposed
+that HTTPS clients and HTTPS servers could pool STHs and consistency proofs,
+which are gossiped on website visits~\cite{chuat}. Nordberg~\emph{et~al.}
+suggested a similar variant, reducing the risk of user tracking by pooling fewer
+and recent STHs~\cite{nordberg}. Dahlberg~\emph{et~al.} noted that such
+privacy-insensitive STHs need not be encrypted, which could enable network
+operators to use programmable data planes to provide gossip
+as-a-service~\cite{dahlberg}. Syta~\emph{et~al.} proposed an alternative to
+reactive gossip mechanisms by showing how an STH can be cosigned efficiently by
+many independent witnesses~\cite{syta}. A smaller-scale version of witness
+cosigning could be instantiated by cross-logging STHs in other CT
+logs~\cite{minimal-gossip}, or in other append-only ledgers~\cite{catena}.
+CTor's full design (Section~\ref{ctor:sec:base}) ensures that anyone connected to the
+Tor network is on the same view by making STHs public in the Tor consensus.  In
+contrast, the first incremental design (Section~\ref{ctor:sec:incremental}) is not
+concerned with catching log misbehavior, while the second incremental design
+(also Section~\ref{ctor:sec:incremental}) exposes misbehaving logs \emph{without}
+first trying to fetch inclusion proofs.
+
+% Other work that is closely related to our approach
+Nordberg proposed that Tor clients could enforce public logging of consensus
+documents and votes~\cite{consensus-transparency}.  Such an initiative is mostly
+orthogonal to CTor, as it strengthens the assumption of a secure Tor consensus
+by enabling detection of compromised signing keys rather than mis-issued TLS
+certificates.  Winter~\emph{et~al.} proposed that Tor Browser could check
+self-signed TLS certificates for exact matches on independent Tor
+circuits~\cite{spoiled-onions}.  Alicherry~\emph{et~al.} proposed that any web
+browser could double-check TLS certificates on first encounter using alternative
+paths and Tor, again, looking for certificate mismatches and generating warnings
+of possible man-in-the-middle attacks~\cite{doublecheck}.  The submission phase
+in CTor is similar to double-checking, except that there are normally no TLS
+handshake blocking, browser warnings, or strict assumptions regarding the
+attacker's location.
+
+% Parallel to our work
+In parallel Stark and Thompson proposed that Chrome could submit a random subset
+of encountered SCTs to a trusted auditor that Google runs~\cite{stark}.  CTor
+also propagates a random subset of SCTs to a trusted auditor, but does so while
+preserving privacy because of and how Tor is used.  Meiklejohn additionally
+proposed witness cosigning on-top of consistent STHs~\cite{meiklejohn}.  CTor
+adds signatures on-top of STHs too, but only as part of the Tor consensus that
+directory authorities sign.
diff --git a/summary/src/introduction/img/contribs.pdf b/summary/src/introduction/img/contribs.pdf
new file mode 100644
index 0000000..a7baa39
--- /dev/null
+++ b/summary/src/introduction/img/contribs.pdf
diff --git a/summary/src/introduction/img/contribs.svg b/summary/src/introduction/img/contribs.svg
new file mode 100644
index 0000000..c05e93d
--- /dev/null
+++ b/summary/src/introduction/img/contribs.svg
@@ -0,0 +1,2213 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   width="143.86166mm"
+   height="76.417732mm"
+   viewBox="0 0 143.86166 76.41773"
+   version="1.1"
+   id="svg5"
+   inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
+   sodipodi:docname="contribs.svg"
+   xml:space="preserve"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:xlink="http://www.w3.org/1999/xlink"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg"><sodipodi:namedview
+     id="namedview7"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageshadow="2"
+     inkscape:pageopacity="0.0"
+     inkscape:pagecheckerboard="0"
+     inkscape:document-units="mm"
+     showgrid="false"
+     inkscape:zoom="1.7180113"
+     inkscape:cx="292.19831"
+     inkscape:cy="127.18193"
+     inkscape:window-width="1870"
+     inkscape:window-height="1000"
+     inkscape:window-x="20"
+     inkscape:window-y="50"
+     inkscape:window-maximized="1"
+     inkscape:current-layer="layer1"
+     inkscape:showpageshadow="2"
+     inkscape:deskcolor="#d1d1d1" /><defs
+     id="defs2"><rect
+       x="327.9743"
+       y="270.12"
+       width="91.584488"
+       height="66.98774"
+       id="rect29495" /><marker
+       style="overflow:visible"
+       id="marker44200"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:isstock="true"
+       viewBox="0 0 12.705841 9.5264135"
+       markerWidth="12.705841"
+       markerHeight="9.5264139"
+       preserveAspectRatio="xMidYMid"><path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:0.625;stroke-linejoin:round"
+         id="path44198" /></marker><marker
+       style="overflow:visible"
+       id="marker44190"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:isstock="true"><path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:0.625;stroke-linejoin:round"
+         id="path44188" /></marker><marker
+       style="overflow:visible"
+       id="marker44180"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:isstock="true"
+       viewBox="0 0 12.705841 9.5264135"
+       markerWidth="12.705841"
+       markerHeight="9.5264139"
+       preserveAspectRatio="xMidYMid"><path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:0.625;stroke-linejoin:round"
+         id="path44178" /></marker><marker
+       style="overflow:visible"
+       id="marker44170"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:isstock="true"
+       viewBox="0 0 12.705841 9.5264135"
+       markerWidth="12.705841"
+       markerHeight="9.5264139"
+       preserveAspectRatio="xMidYMid"><path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:0.625;stroke-linejoin:round"
+         id="path44168" /></marker><marker
+       style="overflow:visible"
+       id="marker44160"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:isstock="true"><path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:0.625;stroke-linejoin:round"
+         id="path44158" /></marker><marker
+       style="overflow:visible"
+       id="marker44144"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:isstock="true"><path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:0.625;stroke-linejoin:round"
+         id="path44142" /></marker><marker
+       style="overflow:visible"
+       id="Arrow2Lend"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:isstock="true"><path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:0.625;stroke-linejoin:round"
+         id="path43893" /></marker><symbol
+       id="Keying"><title
+         id="title1128">Keying</title><desc
+         id="desc1130">Operation using a key-driven device, e.g. typing. (IBM)</desc><path
+         d="m 6.6145833,30.427083 a 17.197917,17.197917 0 0 1 0,-21.1666663 H 33.072917 a 17.197917,17.197917 0 0 1 0,21.1666663 z"
+         style="stroke-width:0.529167"
+         id="path1132" /></symbol><symbol
+       id="AuxillaryOp"><title
+         id="title1079">Auxiliary Operation</title><desc
+         id="desc1081">Offline operation.</desc><rect
+         x="9.260417"
+         y="9.260417"
+         width="21.166666"
+         height="21.166666"
+         style="stroke-width:0.529167"
+         id="rect1083" /></symbol><linearGradient
+       id="linearGradient3109"><stop
+         id="stop3111"
+         style="stop-color:#ffff00"
+         offset="0" /><stop
+         id="stop3113"
+         style="stop-color:#ffff00;stop-opacity:0"
+         offset="1" /></linearGradient><marker
+       inkscape:stockid="TriangleInM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="TriangleInM"
+       style="overflow:visible"
+       inkscape:isstock="true"
+       viewBox="0 0 4.2595265 4.9243081"
+       markerWidth="4.2595263"
+       markerHeight="4.9243078"
+       preserveAspectRatio="xMidYMid"><path
+         id="path8135"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="scale(-0.4)" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker9036"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"
+       viewBox="0 0 4.2595265 4.9243081"
+       markerWidth="4.2595263"
+       markerHeight="4.9243083"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path9034" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8855"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8853" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8597"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8595" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8428"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8426" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8265"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8263" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8025"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8023" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker7874"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path7872" /></marker><marker
+       inkscape:stockid="Arrow2Mend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker7717"
+       style="overflow:visible"
+       inkscape:isstock="true"><path
+         id="path7715"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="scale(-0.6)" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker7417"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path7415" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker7290"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path7288" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker7034"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"><path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path7032" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6925"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"
+       viewBox="0 0 8.886927 5.078244"
+       markerWidth="8.8869267"
+       markerHeight="5.0782437"
+       preserveAspectRatio="xMidYMid"><path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6923" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6915"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"><path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6913" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6703"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"><path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path6701" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6612"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"><path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path6610" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6602"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"><path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path6600" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6428"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend"><path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6426" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6355"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend"><path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6353" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6288"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend"><path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6286" /></marker><marker
+       inkscape:stockid="Arrow1Mend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Mend"
+       style="overflow:visible"
+       inkscape:isstock="true"><path
+         id="path5633"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="matrix(-0.4,0,0,-0.4,-4,0)" /></marker><marker
+       inkscape:stockid="Arrow1Send"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Send"
+       style="overflow:visible"
+       inkscape:isstock="true"><path
+         id="path5639"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="matrix(-0.2,0,0,-0.2,-1.2,0)" /></marker><marker
+       inkscape:stockid="Torso"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Torso"
+       style="overflow:visible"
+       inkscape:isstock="true"><g
+         id="g5850"
+         transform="scale(0.7)"
+         style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-opacity:1"><path
+           id="path5836"
+           d="m -4.7792281,-3.239542 c 2.350374,0.3659393 5.30026732,1.9375477 5.03715532,3.62748546 C -0.00518779,2.0778819 -2.2126741,2.6176539 -4.5630471,2.2517169 -6.9134221,1.8857769 -8.521035,0.75201414 -8.257922,-0.93792336 -7.994809,-2.6278615 -7.1296041,-3.6054813 -4.7792281,-3.239542 Z"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-opacity:1" /><path
+           id="path5838"
+           d="M 4.4598789,0.08866574 C -2.5564571,-4.378332 5.2248769,-3.9061806 -0.84829578,-8.7197331"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" /><path
+           id="path5840"
+           d="M 4.9298719,0.05752074 C -1.3872731,1.7494689 1.8027579,5.4782079 -4.9448731,7.5462725"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" /><rect
+           id="rect5842"
+           transform="matrix(0.527536,-0.849533,0.887668,0.460484,0,0)"
+           y="-1.7408575"
+           x="-10.391706"
+           height="2.7608147"
+           width="2.6366582"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" /><rect
+           id="rect5844"
+           transform="matrix(0.671205,-0.741272,0.790802,0.612072,0,0)"
+           y="-7.9629307"
+           x="4.9587269"
+           height="2.8614161"
+           width="2.7327356"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" /><path
+           id="path5846"
+           transform="matrix(0,-1.109517,1.109517,0,25.96648,19.71619)"
+           d="m 16.779951,-28.685045 a 0.60731727,0.60731727 0 1 0 -1.214634,0 0.60731727,0.60731727 0 1 0 1.214634,0 z"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" /><path
+           id="path5848"
+           transform="matrix(0,-1.109517,1.109517,0,26.8245,16.99126)"
+           d="m 16.779951,-28.685045 a 0.60731727,0.60731727 0 1 0 -1.214634,0 0.60731727,0.60731727 0 1 0 1.214634,0 z"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" /></g></marker><marker
+       inkscape:stockid="Arrow2Send"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Send"
+       style="overflow:visible"
+       inkscape:isstock="true"><path
+         id="path5657"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-0.3,0,0,-0.3,0.69,0)" /></marker><style
+       id="style979">.cls-1{fill:#627a83;}.cls-2{fill:#062b31;}.cls-3{fill:#819096;stroke:#062b31;stroke-miterlimit:10;stroke-width:6.5px;}</style><linearGradient
+       id="linearGradient-1"
+       y2="0"
+       x2="0.5"
+       y1="1"
+       x1="0.5"><stop
+         id="stop1116"
+         offset="0%"
+         stop-color="#420C5D" /><stop
+         id="stop1118"
+         offset="100%"
+         stop-color="#951AD1" /></linearGradient><path
+       id="path-2"
+       d="M 25,29 C 152.57778,29 256,131.97451 256,259 256,386.02549 152.57778,489 25,489 Z" /><filter
+       id="filter-3"
+       filterUnits="objectBoundingBox"
+       height="1.148"
+       width="1.2939999"
+       y="-0.074000001"
+       x="-0.18200001"><feOffset
+         id="feOffset1122"
+         result="shadowOffsetOuter1"
+         in="SourceAlpha"
+         dy="0"
+         dx="-8" /><feGaussianBlur
+         id="feGaussianBlur1124"
+         result="shadowBlurOuter1"
+         in="shadowOffsetOuter1"
+         stdDeviation="10" /><feColorMatrix
+         id="feColorMatrix1126"
+         in="shadowBlurOuter1"
+         type="matrix"
+         values="0 0 0 0 0.250980392   0 0 0 0 0.250980392   0 0 0 0 0.250980392  0 0 0 0.2 0" /></filter><style
+       id="style11378">.cls-1{fill:none;stroke:#000;stroke-linejoin:round;stroke-width:2px;}</style><font
+       horiz-adv-x="576"
+       id="tor-icons"
+       horiz-origin-x="0"
+       horiz-origin-y="0"
+       vert-origin-x="512"
+       vert-origin-y="768"
+       vert-adv-y="1024"><font-face
+         id="font-face14955"
+         descent="0"
+         ascent="512"
+         units-per-em="512"
+         font-family="tor-icons" /><missing-glyph
+         id="missing-glyph14957"
+         horiz-adv-x="0" /><glyph
+         id="glyph14959"
+         d=" M458.622 256.0800000000001L504.607 301.0850000000001C518.315 314.062 511.923 337.124 493.943 341.424L431.2930000000001 357.414L448.9540000000001 419.4290000000001C453.9450000000001 437.2670000000001 437.1250000000001 454.092 419.2930000000001 449.1L357.2990000000001 431.433L341.3150000000001 494.104C337.085 511.803 313.765 518.276 300.99 504.772L256 458.43L211.011 504.771C198.381 518.122 174.964 512.005 170.686 494.103L154.702 431.432L92.707 449.099C74.87 454.093 58.056 437.262 63.046 419.428L80.707 357.413L18.057 341.423C0.069 337.122 -6.31 314.0560000000001 7.392 301.0850000000001L53.377 256.0800000000001L7.392 211.076C-6.316 198.0990000000001 0.076 175.037 18.056 170.737L80.706 154.747L63.045 92.732C58.054 74.894 74.874 58.069 92.706 63.061L154.7 80.7280000000001L170.684 18.0570000000001C175.123 -0.5179999999999 198.38 -5.9609999999999 211.009 7.3890000000001L256 53.39L300.989 7.389C313.489 -6.0989999999999 336.976 -0.097 341.314 18.057L357.298 80.728L419.2919999999999 63.061C437.128 58.067 453.9429999999999 74.898 448.9529999999999 92.732L431.2919999999999 154.747L493.9419999999999 170.737C511.9289999999999 175.0390000000001 518.3079999999999 198.1040000000001 504.6059999999999 211.076L458.6219999999999 256.0800000000001z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="authority" /><glyph
+         id="glyph14961"
+         d=" M256 504C119.034 504 8 392.967 8 256S119.034 8 256 8S504 119.034 504 256S392.967 504 256 504zM386.108 386.108C451.556 320.6600000000001 456.108 220.627 406.7850000000001 150.471L150.47 406.784C220.674 456.14 320.6960000000001 451.519 386.108 386.108zM125.892 125.892C60.444 191.34 55.892 291.373 105.215 361.529L361.53 105.216C291.327 55.86 191.304 60.48 125.892 125.892z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="badexit" /><glyph
+         id="glyph14963"
+         d=" M16 368L16 115.3684208L86.2866667199996 115.3684208C111 188.9473680000001 177.6333328000001 241.6842105599999 256 241.6842105599999C334.3666672 241.6842105599999 401 188.9473680000001 425.7133328 115.3684208L496 115.3684208L496 368L16 368z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="bridge" /><glyph
+         id="glyph14965"
+         d=" M172.268 10.33C26.97 220.969 0 242.587 0 320C0 426.039 85.961 512 192 512S384 426.039 384 320C384 242.587 357.03 220.969 211.732 10.33C202.197 -3.444 181.802 -3.443 172.268 10.33z"
+         horiz-adv-x="384"
+         unicode=""
+         glyph-name="country" /><glyph
+         id="glyph14967"
+         d=" M452.9230767999998 352C459.0403071999999 352 464 356.8357 464 362.8L464 398.8C464 404.7643000000001 459.0403071999999 409.6 452.9230767999998 409.6L434.4615392000001 409.6L434.4615392000001 452.8C434.4615392000001 476.659 414.6246160000001 496 390.1538464 496L124.3076923200001 496C99.8369230399999 496 80 476.659 80 452.8L80 78.4C80 54.5409999999999 99.8369230399999 35.2 124.3076923200001 35.2L390.1538464 35.2C414.6246160000001 35.2 434.4615392000001 54.5409999999999 434.4615392000001 78.4L434.4615392000001 121.6L452.9230767999998 121.6C459.0403071999999 121.6 464 126.4356992000001 464 132.4L464 168.4C464 174.3643008 459.0403071999999 179.2000000000001 452.9230767999998 179.2000000000001L434.4615392000001 179.2000000000001L434.4615392000001 236.8L452.9230767999998 236.8C459.0403071999999 236.8 464 241.6356992 464 247.6L464 283.6C464 289.5643008 459.0403071999999 294.4 452.9230767999998 294.4L434.4615392000001 294.4L434.4615392000001 352L452.9230767999998 352z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="directory" /><glyph
+         id="glyph14969"
+         d=" M296.5909877987965 115.1547656932976L249.7182730611699 115.1547656932976L249.7182730611699 191.4505156032526L155.9728736919687 191.4505156032526L155.9728736919687 115.1547656932976L109.1001683624834 115.1547656932976L202.8455771398258 13.427099146691z M385.5550693190428 315.6303325759527C385.5550693190428 275.9530447882323 352.5320764727 243.7877778650137 311.7967082319215 243.7877778650137H99.7414234591009C53.9138567562077 243.7877778650137 16.7632675713548 279.9734118919249 16.7632675713548 324.6106644872678C16.7632675713548 359.8432583489403 39.9112912172481 389.8049741187648 72.199590439413 400.8687282818329C72.121641262355 402.3891395527968 72.0824152248678 403.9112204448434 72.0820799595901 405.4335360225843C72.0820380514303 455.0307215753485 113.3602141873657 495.2367361165633 164.2799894103319 495.2367361165633C198.4439369337201 495.2367361165633 228.2665209659647 477.1369020008461 244.194873728423 450.2458943198008C252.9830651091063 455.973655168792 263.5489503348364 459.3154570847676 274.917527688361 459.3154570847676C305.4690622505769 459.3154570847676 330.2362985037019 435.1915110831694 330.2362985037019 405.4335360225844C330.2362985037019 398.5950228690864 328.9254112680172 392.0551053535121 326.5397473684459 386.0360459153656C360.2104392047168 379.3827517408421 385.5550693190429 350.3897883434942 385.5550693190429 315.6303325759525z"
+         horiz-adv-x="402.31833320247944"
+         unicode=""
+         glyph-name="exit" /><glyph
+         id="glyph14971"
+         d=" M444.8 198.08A39.36 39.36 0 0 1 444.8 203.52V206.08A181.43999999999997 181.43999999999997 0 0 1 368 313.6A37.44 37.44 0 0 0 350.08 344V416A32 32 0 0 1 318.08 448H193.92A32 32 0 0 1 161.92 416V344A37.44 37.44 0 0 0 144 312A181.12 181.12 0 0 1 68.8 205.44V201.6A16.96 16.96 0 0 1 68.8 198.0800000000001A171.2 171.2 0 0 1 65.28 166.0800000000001A180.80000000000004 180.80000000000004 0 0 1 168.96 3.2A32 32 0 0 1 183.04 1e-13H329.2800000000001A32 32 0 0 1 343.36 3.2A180.80000000000004 180.80000000000004 0 0 1 448 165.44A169.6 169.6 0 0 1 444.8 198.08zM180.16 262.08A101.76 101.76 0 0 1 225.92 345.28V384H286.0800000000001V344A101.76 101.76 0 0 1 331.8400000000001 260.8A117.76 117.76 0 0 0 381.12 189.12V182.08A90.24 90.24 0 0 0 263.36 200.96A111.36000000000001 111.36000000000001 0 0 1 145.92 224A120.32000000000001 120.32000000000001 0 0 0 180.16 260.8z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="experimental" /><glyph
+         id="glyph14973"
+         d=" M452.9230767999998 352C459.0403071999999 352 464 356.8357 464 362.8L464 398.8C464 404.7643000000001 459.0403071999999 409.6 452.9230767999998 409.6L434.4615391999996 409.6L434.4615391999996 452.8C434.4615391999996 476.659 414.6246160000001 496 390.1538464000005 496L124.3076923199997 496C99.8369230400003 496 80 476.659 80 452.8L80 78.4C80 54.5409999999999 99.8369230400003 35.2 124.3076923199997 35.2L390.1538464000005 35.2C414.6246160000001 35.2 434.4615391999996 54.5409999999999 434.4615391999996 78.4L434.4615391999996 121.6L452.9230767999998 121.6C459.0403071999999 121.6 464 126.4356992000001 464 132.4L464 168.4C464 174.3643008 459.0403071999999 179.2000000000001 452.9230767999998 179.2000000000001L434.4615391999996 179.2000000000001L434.4615391999996 236.8L452.9230767999998 236.8C459.0403071999999 236.8 464 241.6356992 464 247.6L464 283.6C464 289.5643008 459.0403071999999 294.4 452.9230767999998 294.4L434.4615391999996 294.4L434.4615391999996 352L452.9230767999998 352z M332.0210623999996 442.51428112L349.7886320000001 442.51428112C353.0297599999998 442.51428112 355.6571360000002 439.88519712 355.6571360000002 436.64285264L355.6571360000002 361.5179776C355.6571360000002 358.27563296 353.0297599999998 355.64654896 349.7886320000001 355.64654896L274.7125860800001 355.64654896C271.4714576 355.64654896 268.8440824000003 358.27563296 268.8440824000003 361.5179776L268.8440824000003 379.29710256C268.8440824000003 382.64996128 271.6456374399999 385.32222944 274.9933779200004 385.1617073600001L311.8386863999998 381.20214032C299.9163696 398.92995472 280.0015614400003 409.771424 258.2233105600002 409.771424C228.1761463999996 409.771424 202.3303078399999 389.1221204799999 195.4223151999999 360.2953712C194.78704048 357.6444696 192.4320032 355.771424 189.7129939199998 355.771424L171.3184575999998 355.771424C167.64736528 355.771424 164.8671779199998 359.1065444800001 165.5459400000004 362.7124883199999C173.8761135999998 406.97738048 212.6795275199997 439.51428112 258.2233105600002 439.51428112C286.2351251200002 439.51428112 312.2489695999997 427.21675568 327.6452848000003 405.32475408L326.1590016000004 436.362004C325.9986303999998 439.71092448 328.6694496000004 442.51428112 332.0210623999996 442.51428112z M258.2233105600002 280.5142816C288.2704745599998 280.5142816 314.1163135999999 301.163584 321.0243056000003 329.99033392C321.6595807999996 332.64123552 324.0146176000002 334.51428112 326.7336271999997 334.51428112L345.1281632000004 334.51428112C348.7992559999997 334.51428112 351.5794431999997 331.1791608 350.9006815999996 327.5732168C342.5705072000004 283.3083248000001 303.7670928000001 250.771424 258.2233105600002 250.771424C230.2408636800005 250.771424 204.2513508799997 263.043288 188.8544127999998 284.9015488L190.4017785600003 253.9359792C190.5694864000001 250.582576 187.89707408 247.771424 184.5406079999997 247.771424L166.7827825600001 247.771424C163.5416540800001 247.771424 160.9142788800004 250.4005088 160.9142788800004 253.6428528L160.9142788800004 328.76735264C160.9142788800004 332.00969712 163.5416540800001 334.63878112 166.7827825600001 334.63878112L241.8584540799997 334.63878112C245.0995825599998 334.63878112 247.7269577600004 332.00969712 247.7269577600004 328.76735264L247.7269577600004 310.9878526400001C247.7269577600004 307.6353696 244.9258255999998 304.9632128 241.5781737600004 305.1232416000001L204.60607664 309.0850424C216.5283587199996 291.3565216 236.44428336 280.5142816 258.2233105600002 280.5142816z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="fallbackdir" /><glyph
+         id="glyph14975"
+         d=" M295.973 352H180.572L215.19 481.816C219.25 497.044 207.756 512 192 512H56C43.971 512 33.8 503.095 32.211 491.172L0.215 251.1720000000001C-1.704 236.783 9.504 224 24.004 224H142.705L96.646 29.534C93.05 14.351 104.659 0 119.992 0C128.342 0 136.368 4.374 140.77 11.978L316.7430000000001 315.975C325.9870000000001 331.942 314.4550000000001 352 295.9730000000001 352z"
+         horiz-adv-x="320"
+         unicode=""
+         glyph-name="fast" /><glyph
+         id="glyph14977"
+         d=" M198.8473759999997 69.8115520000001C175.7948960000003 92.8640479999999 165.1261439999999 106.6301600000002 149.9472159999996 134.0429439999998C133.0839040000001 164.1036479999998 124.2357920000004 200.7511199999999 124.2357920000004 240.159952C124.2357920000004 313.703536 187.0392000000002 373.5199360000002 264.0757919999997 373.5199360000002C341.1123680000001 373.5199360000002 403.9158079999998 313.7035040000001 403.9158079999998 240.159952C403.9158079999998 231.2308159999998 396.8449600000004 224.159952 387.9158079999998 224.159952C378.9866560000001 224.159952 371.9158079999998 231.2308159999998 371.9158079999998 240.159952C371.9158079999998 295.9849119999999 323.5885120000003 341.5199520000001 264.0758079999996 341.5199520000001C204.5631039999999 341.5199520000001 156.2358080000004 295.984896 156.2358080000004 240.159952C156.2358080000004 206.2166240000002 163.7722240000003 174.9857280000001 178.0510080000004 149.7051040000001C191.6408320000001 125.2859199999998 200.3410240000003 114.230208 221.8558400000002 92.4349440000001C227.8824800000002 86.0910560000002 227.8824800000002 76.2287999999999 221.6465280000002 69.6802240000002C218.329264 66.6644959999999 214.2679360000002 65.039984 210.0758239999996 65.039984C205.7350079999997 65.039984 201.5739519999997 66.7737440000001 198.8473759999997 69.8115520000001zM305.5114240000003 131.4889600000001C268.6525279999996 156.4738560000001 246.6357920000001 197.0735199999999 246.6357920000001 240.159952C246.6357920000001 249.0890880000002 253.7066720000003 256.159952 262.6357920000001 256.159952C271.5649279999998 256.159952 278.6357920000001 249.0890880000002 278.6357920000001 240.159952C278.6357920000001 207.5885920000001 295.3078240000005 176.939648 323.4360800000004 158.0337439999999C339.7374879999998 147.0130880000002 358.8572160000004 141.6799999999998 382.1557599999997 141.6799999999998C388.4921279999999 141.6799999999998 397.9151359999996 142.5306879999998 406.3874400000004 144.013136C415.0970719999996 145.6260000000002 423.3919679999999 139.7998400000001 424.9689120000003 130.9683519999999C426.581776 122.2587199999998 420.7556160000004 113.9638239999999 411.9537440000004 112.39248C400.8680800000002 110.2531199999999 390.1723039999997 109.4399840000001 382.1557599999997 109.4399840000001C352.7702079999999 109.4399840000001 326.7927040000004 116.8889600000002 305.5114240000003 131.4889600000001zM329.7289760000004 60.6248959999998C291.02056 71.3366719999999 265.4320479999997 85.7974079999999 238.6975199999997 112.0414719999999C204.3265920000004 146.1668960000002 185.4357920000002 191.5947679999999 185.4357920000002 240.1599999999999C185.4357920000002 281.3138399999998 220.4103359999999 314.7200160000002 263.3557920000003 314.7200160000002C306.3012639999997 314.7200160000002 341.2757920000004 281.3138560000002 341.2757920000004 240.1599999999999C341.2757920000004 216.7314240000001 361.7688799999997 197.5999999999999 387.1957920000005 197.5999999999999C412.6227040000004 197.5999999999999 433.1157919999996 216.7314080000001 433.1157919999996 240.1599999999999C433.1157919999996 328.3612960000001 356.9735680000004 400.08 263.1157919999996 400.08C196.4003039999998 400.08 135.4604639999998 362.9602880000002 108.0797920000005 305.6247199999998C98.993888 286.753968 94.3157760000004 264.5478079999998 94.3157760000004 240.1599839999999C94.3157760000004 212.6229600000002 98.3163359999999 186.4572159999998 110.1291680000004 154.9559039999999C113.3395520000004 146.6088639999998 109.1273920000003 137.2819359999999 100.8717120000001 134.4266240000002C92.6151520000003 131.2510080000002 83.2601439999999 135.5764640000002 80.3292959999999 143.718672C68.3969280000001 175.6194719999999 62.5557920000001 207.2941599999999 62.5557920000001 240.1600319999998C62.5557920000001 269.4816160000001 68.178672 296.2367039999999 79.2650560000002 319.6412639999999C111.8755520000004 388.0497599999999 184.1168960000005 432.3200160000001 263.1157919999996 432.3200160000001C374.4936960000005 432.3200160000001 465.1157919999996 346.3238240000001 465.1157919999996 240.4000160000001C465.1157919999996 199.2461600000002 430.1412799999998 165.8400000000002 387.1957920000005 165.8400000000002C344.2503040000002 165.8400000000002 309.2757920000004 199.2461600000002 309.2757920000004 240.4000160000001C309.2757920000004 263.8285919999999 288.7827040000002 282.960016 263.3557920000003 282.960016C237.9288800000004 282.960016 217.4357920000002 263.8286079999998 217.4357920000002 240.4000160000001C217.4357920000002 200.3504320000002 232.9033600000003 162.9959680000002 261.1292160000003 135.0033600000002C283.5484479999996 112.8200959999999 304.8367040000003 100.7499680000001 337.7996160000003 91.6319840000001C346.3564800000004 89.413552 351.3377600000004 80.5468799999999 349.104496 72.2702559999998C347.5418239999999 65.0820159999998 341.0214720000004 60 333.9157759999998 60C332.6766559999997 60 331.3167999999996 60.2266559999998 329.7289760000004 60.6248959999998z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="fingerprint" /><glyph
+         id="glyph14979"
+         d=" M496 384C496 162.718 360.0660000000001 39.355 274.461 3.692A48 48 0 0 0 237.538 3.692C130.495 48.287 16 185.513 16 384A48 48 0 0 0 45.539 428.308L237.539 508.308A48 48 0 0 0 274.462 508.308L466.462 428.308A48 48 0 0 0 496 384zM256 65.687L256.066 65.653C349.801 112.342 428.563 221.961 431.883 373.382L256 446.6670000000001V65.687z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="guard" /><glyph
+         id="glyph14981"
+         d=" M189.0312960000001 381.0658400000002L189.0312960000001 343.85032L120.4904800000004 211.5879359999999L189.0312960000001 211.5879359999999L189.0312960000001 170.6240800000001L65.8720000000003 170.6240800000001L65.8720000000003 209.9815039999999L137.0902079999996 340.1019839999999L65.8720000000003 340.1019839999999L65.8720000000003 381.0658400000002L189.0312960000001 381.0658400000002zM344.8545919999997 320.8248800000001L344.8545919999997 289.4995840000002L275.242816 208.107344L344.8545919999997 208.107344L344.8545919999997 170.6240800000001L221.6952959999999 170.6240800000001L221.6952959999999 205.1622240000002L287.8264799999997 283.073872L221.6952959999999 283.073872L221.6952959999999 320.8248800000001L344.8545919999997 320.8248800000001zM465.8720000000003 283.274688L465.8720000000003 259.7807039999998L413.6631680000001 198.7365279999999L465.8720000000003 198.7365279999999L465.8720000000003 170.6240800000001L373.502528 170.6240800000001L373.502528 196.5276960000001L423.1009119999999 254.9614240000001L373.502528 254.9614240000001L373.502528 283.274688L465.8720000000003 283.274688z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="hibernating" /><glyph
+         id="glyph14983"
+         d=" M452.9230767999998 352C459.0403071999999 352 464 356.8357 464 362.8L464 398.8C464 404.7643000000001 459.0403071999999 409.6 452.9230767999998 409.6L434.4615391999996 409.6L434.4615391999996 452.8C434.4615391999996 476.659 414.6246160000001 496 390.1538464000005 496L124.3076923199997 496C99.8369230400003 496 80 476.659 80 452.8L80 78.4C80 54.5409999999999 99.8369230400003 35.2 124.3076923199997 35.2L390.1538464000005 35.2C414.6246160000001 35.2 434.4615391999996 54.5409999999999 434.4615391999996 78.4L434.4615391999996 121.6L452.9230767999998 121.6C459.0403071999999 121.6 464 126.4356992000001 464 132.4L464 168.4C464 174.3643008 459.0403071999999 179.2000000000001 452.9230767999998 179.2000000000001L434.4615391999996 179.2000000000001L434.4615391999996 236.8L452.9230767999998 236.8C459.0403071999999 236.8 464 241.6356992 464 247.6L464 283.6C464 289.5643008 459.0403071999999 294.4 452.9230767999998 294.4L434.4615391999996 294.4L434.4615391999996 352L452.9230767999998 352z M178.1093038400004 437.4980121600001L178.1093038400004 364.11513232L207.9970329600001 364.11513232L207.9970329600001 437.4980121600001L251.2491935999997 437.4980121600001L251.2491935999997 246.5081328L207.9970329600001 246.5081328L207.9970329600001 328.3956512L178.1093038400004 328.3956512L178.1093038400004 246.5081328L134.8571428799996 246.5081328L134.8571428799996 437.4980121600001L178.1093038400004 437.4980121600001zM351.8469168000002 400.3205928C348.6070384000004 401.77853824 345.5292 402.7909849600001 342.6133087999997 403.35796368C339.6974191999998 403.9249424 336.6195808000002 404.20842752 333.3797023999996 404.20842752C326.7379504000001 404.20842752 321.7567120000004 402.75050416 318.4358368000003 399.8346136C315.1149616000003 396.91872288 313.4545488000004 393.11192288 313.4545488000004 388.4140992C313.4545488000004 384.68823888 314.2645071999996 381.56990272 315.8844464000004 379.0589969600001C317.5043856000002 376.5480910400001 319.7317679999997 374.44220176 322.5666608000002 372.7412656C325.4015552000001 371.0403292800001 328.6818831999999 369.6229038400001 332.4077423999998 368.4889464000001C336.1336031999999 367.35498896 340.1428928000005 366.1805505600001 344.4357312000002 364.96559616C348.7285712000003 363.75064176 353.1428384000001 362.37371408 357.6786688000002 360.8347718400001C362.2144992000003 359.2958296 366.6692640000001 357.39242944 371.0431007999996 355.12451456C380.2767536000001 350.2646969600001 386.8779071999998 343.9470288 390.8467584 336.17132048C394.8156096000003 328.3956128 396.8000048000004 318.9191104 396.8000048000004 307.7415296000001C396.8000048000004 285.8723504 391.0493072 269.5922048 379.5477392000003 258.9006064C368.0461696000002 248.2090064 351.6850287999996 242.863288 330.4638255999999 242.863288C318.8002640000004 242.863288 309.1617696000003 244.3617088 301.5480559999997 247.3585968C293.9343408000005 250.3554848 287.8596592000004 254.4862672 283.3238303999997 259.7510704C278.7880000000005 265.015872 275.6291664000001 271.0905536 273.8472336000005 277.9752944C272.0652991999996 284.8600368 271.1743471999999 292.190152 271.1743471999999 299.9658592000001L271.1743471999999 302.8817360000001L311.2676416000004 302.8817360000001L311.2676416000004 299.9658592000001C311.2676416000004 297.6979456000001 311.5511263999997 295.430064 312.1181055999996 293.1621488000001C312.6850848000004 290.8942336 313.7785264000004 288.8288432 315.3984656000003 286.965912C317.0184048000001 285.1029824 319.1242943999996 283.5640640000001 321.7161984000004 282.3491088000001C324.3081007999999 281.1341552 327.7099215999997 280.5266864 331.9217632 280.5266864C336.2956000000004 280.5266864 339.9404080000004 281.2556480000001 342.8562991999998 282.7135936C345.7721887999997 284.1715392 348.0805680000003 286.0749392 349.7815039999996 288.4238512C351.4824399999998 290.7727632 352.6568784000001 293.4861200000001 353.3048544000003 296.5640048C353.9528303999996 299.6418896 354.2768127999998 302.8817184 354.2768127999998 306.283592C354.2768127999998 309.685464 353.6288480000003 312.7633024 352.3328959999999 315.5171984C351.0369440000004 318.271096 348.0401024000003 320.700968 343.3422784000004 322.806888C339.7784112 324.5888224000001 335.5261360000004 326.1682384000001 330.5853200000002 327.5451872C325.6445056000003 328.922136 320.5417743999997 330.501552 315.2769712 332.2834864C310.0121695999997 334.0654192 304.7474448000003 336.21180624 299.4826432 338.722712C294.2178400000003 341.23361776 289.5200880000002 344.5139454400001 285.3892415999999 348.5637936000001C281.2583967999999 352.6136416 277.9375712000001 357.59488 275.4266656 363.5076580800001C272.9157599999999 369.42043632 271.6603263999996 376.66955552 271.6603263999996 385.25523344C271.6603263999996 395.94683232 273.3612368000004 404.85636432 276.7631087999999 411.98409696C280.1649808000002 419.1118296 284.8627343999997 424.8220296 290.8565104 429.11486864C296.8502847999999 433.4077075200001 303.7754207999997 436.4855459200001 311.6321263999999 438.348476C319.488832 440.21140608 327.9528879999998 441.1428571200001 337.0245471999997 441.1428571200001C341.8843648000002 441.1428571200001 346.7846063999996 440.89986992 351.7254223999999 440.41388816C356.6662367999998 439.9279064 361.5259808000001 439.03695312 366.3048016000003 437.74100176C371.0836224000004 436.4450504 375.5788863999997 434.70364192 379.790728 432.51672384C384.0025711999997 430.32980592 387.8093712 427.6164484800001 391.2112432000004 424.37657008L391.2112432000004 387.92811984L351.8469168000002 387.92811984L351.8469168000002 400.3205928z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="hsdir" /><glyph
+         id="glyph14985"
+         d=" M244.6880000000001 453.7919999999999L244.6880000000001 417.8880000000001L209.0560000000001 417.8880000000001L209.0560000000001 275.904L244.6880000000001 275.904L244.6880000000001 240L124.7360000000001 240L124.7360000000001 275.904L160.368 275.904L160.368 417.8880000000001L124.7360000000001 417.8880000000001L124.7360000000001 453.7919999999999L244.6880000000001 453.7919999999999zM338.528 453.7919999999999C353.3974080000001 453.7919999999999 365.7279504000001 452.6133451200001 375.52 450.2560000000001C385.3120496 447.8986548800001 393.0639712 443.86402856 398.7760000000001 438.1520000000001C404.4880288 432.4399714399999 408.4773216 424.7787147200001 410.7440000000001 415.168C413.0106784 405.55728528 414.144 393.58940496 414.144 379.264C414.144 364.7572608000001 413.0106784 352.78938048 410.7440000000001 343.36C408.4773216 333.93061952 404.4880288 326.36002864 398.7760000000001 320.648C393.0639712 314.93597152 385.3120496 310.94667808 375.52 308.6800000000001C365.7279504000001 306.4133219200001 353.3974080000001 305.28 338.528 305.28L326.288 305.28L326.288 240L277.8720000000001 240L277.8720000000001 453.7919999999999L338.528 453.7919999999999zM326.288 345.264L342.88 345.264C347.5946896000001 345.264 351.4933184 345.6266630400001 354.576 346.352C357.6586816 347.0773369600001 360.0613248 348.5733220800001 361.784 350.8400000000001C363.5066752 353.1066779200001 364.7306624000001 356.41597824 365.456 360.7680000000001C366.1813376 365.12002176 366.544 371.01329616 366.544 378.448C366.544 385.7013696 366.1813376 391.54931104 365.456 395.992C364.7306624000001 400.43468896 363.5066752 403.87998784 361.784 406.328C360.0613248 408.77601232 357.6586816 410.3626630400001 354.576 411.088C351.4933184 411.81333696 347.5946896000001 412.1760000000001 342.88 412.1760000000001L326.288 412.1760000000001L326.288 345.264zM159.0080000000001 200.592L184.3040000000001 108.656L213.136 200.592L258.288 200.592L205.2480000000001 48L161.7280000000001 48L111.136 200.592L159.0080000000001 200.592zM396.192 261.7920000000001L396.192 132.048L415.232 132.048L415.232 95.056L396.192 95.056L396.192 48L352.6720000000001 48L352.6720000000001 95.056L271.072 95.056L271.072 132.864L357.2960000000001 261.7920000000001L396.192 261.7920000000001zM352.6720000000001 132.048L352.6720000000001 194.608L310.784 132.048L352.6720000000001 132.048z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="ipv4" /><glyph
+         id="glyph14987"
+         d=" M226.900593162086 212.6296858410254L117.2411193576932 212.6296858410254L117.2411193576932 130.3850908505497L62.4114011085707 130.3850908505497L172.0708562598897 20.7256170461573L281.7303300642825 130.3850908505497L226.900593162086 130.3850908505497z M69.3618079848193 424.9523213584622L95.0615988218449 331.5487735583611L124.3538266307687 424.9523213584622H170.2265853827663L116.3399271760999 269.9245508254372H72.1252194458459L20.7256377717949 424.9523213584622zM280.4869783287148 449.546745538513C278.6446763871798 451.0205746563583 276.2036936729691 452.0798744382578 273.1639058322554 452.7246759726667C270.1241387171794 453.3694712893852 267.0383399606124 453.6918793105633 263.906468111279 453.6918793105633C259.1165037889262 453.6918793105633 254.9714176858428 452.5404665041512 251.4710854482022 450.2376056577429C247.9707324849238 447.9347448113346 245.0691639225102 444.7107889533808 242.7663175840483 440.5656406733841C240.4634505199487 436.4204923933874 238.7132947639473 431.4924455819438 237.5158088647685 425.781353087025C236.3182815143142 420.0702605921064 235.443245087589 413.7144619007118 234.8905752307663 406.7137663369739C240.2332094099418 408.7402777470244 245.6218130536951 410.0759228201537 251.0565726927662 410.7207222819996C256.4913116061996 411.3655175987176 261.6957057814369 411.6879131845138 266.6698795723056 411.6879131845138C277.7236083189635 411.6879131845138 287.0270155045178 410.1219876226659 294.5804120135351 406.9901012653857C302.1337877969147 403.8582128355418 308.2592914916442 399.2986181221501 312.9571303541013 393.3111803360012C317.6549692165585 387.3237446224161 321.0631552686658 380.0468156858919 323.181792138612 371.4801759072319C325.3004082829204 362.9135444188271 326.3597163550746 353.1956037521991 326.3597163550746 342.3261051996947C326.3597163550746 326.6666630504752 324.4714034976863 313.862944352918 320.6947156059966 303.914596771181C316.9180277143068 293.9662491894439 311.8057382733271 286.1826944729709 305.3577436548685 280.5637046397462C298.9097283107721 274.9447355321594 291.494633982606 271.0759843574874 283.1122119627169 268.9573474875412C274.7298106684655 266.8387313432321 265.9330209726051 265.7794232710782 256.721573441844 265.7794232710782C245.2993843068791 265.7794232710782 235.3972341717354 267.2992342888839 227.0148328774841 270.339063580873C218.632410857595 273.3788306959488 211.6318292848648 278.9056121667267 206.0128394516402 286.9195737983088C200.3938703440534 294.9335354298909 196.202731873841 305.8489205444222 193.4392996871765 319.6660814777446C190.675867500512 333.483242411067 189.2941721328176 351.1689472626838 189.2941721328176 372.7237141735392C189.2941721328176 393.1731123548564 190.629732230832 410.8588130613457 193.301121860152 425.7813468693339C195.9724285869209 440.7038806773221 200.2556925170288 453.0009694498029 206.1510172786648 462.6729821031286C212.0463420403007 472.3449947564543 219.783823664007 479.5298106684655 229.3637315830749 484.2276453857951C238.943618776505 488.9254801031248 250.5498723005212 491.2743622282053 264.1828030396901 491.2743622282053C276.7103526139382 491.2743622282053 288.2244806780588 489.524206472204 298.725539567894 486.023868016872C309.2265777320915 482.5235191987211 317.1482895499514 478.0099809975858 322.4909237291269 472.4831166242569V430.7554999345641H280.4869783287148zM257.5505989527159 377.6978672387695C254.4187063777445 377.6978672387695 250.8262901314837 377.3294068504625 246.7732673113827 376.5925067994863C242.7202237656438 375.8555860228724 238.5751376625604 374.7502255835892 234.3378846483058 373.2764047559991C234.5223428244748 359.2750136285232 235.1208992433242 347.8069379315316 236.1341756739872 338.8718460548198C237.1474521046503 329.9367334524703 238.6211693040515 322.8440471454823 240.5555759798442 317.5935177005646C242.4898997530858 312.342988255647 244.9309653698478 308.7045403678951 247.8786277506658 306.6780082322067C250.8262901314837 304.6514553708807 254.4187063777445 303.6382618427687 258.6559593919991 303.6382618427687C266.2093559010163 303.6382618427687 272.0585246673345 306.7240398736979 276.2036729473312 312.8956995637452C280.3488212273279 319.0673799794303 282.4213642788697 328.5089649920091 282.4213642788697 341.2207447604107C282.4213642788697 346.5633789395862 282.0068515234338 351.4914381864125 281.1778260125619 356.0050261290784C280.3488005016902 360.518634797382 278.9671051339957 364.3873859720541 277.032698458203 367.6113894989748C275.0983746849614 370.8353950984592 272.5191312411748 373.3224467603092 269.2951339319456 375.0726190968209C266.0711158970784 376.8227935058965 262.1563123552775 377.6978672387695 257.5505989527159 377.6978672387695z"
+         horiz-adv-x="347.08537485250696"
+         unicode=""
+         glyph-name="ipv6exit" /><glyph
+         id="glyph14989"
+         d=" M244.6880000000001 453.7919999999999L244.6880000000001 417.8880000000001L209.0560000000001 417.8880000000001L209.0560000000001 275.904L244.6880000000001 275.904L244.6880000000001 240L124.7359999999999 240L124.7359999999999 275.904L160.368 275.904L160.368 417.8880000000001L124.7359999999999 417.8880000000001L124.7359999999999 453.7919999999999L244.6880000000001 453.7919999999999zM338.5280000000003 453.7919999999999C353.3974079999998 453.7919999999999 365.7279503999999 452.6133451200001 375.52 450.2560000000001C385.3120496000002 447.8986548800001 393.0639712000002 443.86402856 398.7759999999999 438.1520000000001C404.4880288 432.4399714399999 408.4773215999999 424.7787147200001 410.7440000000002 415.168C413.0106784 405.55728528 414.1440000000003 393.58940496 414.1440000000003 379.264C414.1440000000003 364.7572608000001 413.0106784 352.78938048 410.7440000000002 343.36C408.4773215999999 333.93061952 404.4880288 326.36002864 398.7759999999999 320.648C393.0639712000002 314.93597152 385.3120496000002 310.94667808 375.52 308.6800000000001C365.7279503999999 306.41332208 353.3974079999998 305.28 338.5280000000003 305.28L326.288 305.28L326.288 240L277.8719999999999 240L277.8719999999999 453.7919999999999L338.5280000000003 453.7919999999999zM326.288 345.264L342.8800000000001 345.264C347.5946896000001 345.264 351.4933184000002 345.6266630400001 354.576 346.352C357.6586815999999 347.0773369600001 360.0613248 348.5733220800001 361.7840000000001 350.8400000000001C363.5066752000003 353.1066779200001 364.7306624000003 356.41597824 365.4560000000002 360.7680000000001C366.1813376 365.12002176 366.5439999999999 371.01329616 366.5439999999999 378.448C366.5439999999999 385.7013696 366.1813376 391.54931104 365.4560000000002 395.992C364.7306624000003 400.43468896 363.5066752000003 403.87998784 361.7840000000001 406.328C360.0613248 408.77601232 357.6586815999999 410.3626630400001 354.576 411.088C351.4933184000002 411.81333696 347.5946896000001 412.1760000000001 342.8800000000001 412.1760000000001L326.288 412.1760000000001L326.288 345.264zM159.0079999999998 200.592L184.3040000000001 108.656L213.136 200.592L258.288 200.592L205.2480000000001 48L161.7280000000001 48L111.136 200.592L159.0079999999998 200.592zM366.8159999999998 224.8C365.0026576 226.2506736000001 362.6000144 227.2933296 359.6080000000002 227.928C356.6159856 228.5626704 353.5786816 228.88 350.4960000000001 228.88C345.7813104000002 228.88 341.7013504000002 227.7466784000001 338.2559999999999 225.48C334.8106496000001 223.2133216 331.9546783999999 220.0400208 329.6880000000001 215.96C327.4213215999999 211.8799792 325.698672 207.0293616 324.52 201.408C323.341328 195.7866384 322.4800031999999 189.5307008 321.9360000000002 182.64C327.1946927999998 184.6346768 332.4986399999998 185.9493296000001 337.848 186.5840000000001C343.1973600000001 187.2186704000001 348.3199759999998 187.5360000000001 353.2159999999999 187.5360000000001C364.0960544 187.5360000000001 373.2532959999999 185.9946816 380.6880000000001 182.912C388.1227039999999 179.8293184 394.1519776 175.3413631999999 398.7759999999999 169.448C403.4000224000002 163.5546368 406.7546560000001 156.3920416000001 408.8400000000002 147.96C410.9253440000002 139.5279584 411.9679999999999 129.96272 411.9679999999999 119.264C411.9679999999999 103.8505904 410.109352 91.2480496000001 406.3919999999999 81.456C402.6746480000002 71.6639504 397.6426976000003 64.0026944 391.2959999999998 58.472C384.9493023999999 52.9413056000001 377.6507072 49.1333440000001 369.4000000000001 47.048C361.1492927999998 44.9626559999999 352.4907119999998 43.9200000000001 343.424 43.9200000000001C332.1812768 43.9200000000001 322.4347072000001 45.4159856 314.1840000000002 48.408C305.9332927999999 51.4000143999999 299.0426944000001 56.83996 293.5120000000002 64.7280000000001C287.9813055999998 72.61604 283.8560143999998 83.3599328 281.136 96.96C278.4159872 110.5600688 277.0560000000001 127.9678944 277.0560000000001 149.184C277.0560000000001 169.3121008000001 278.3706527999998 186.7199264 281 201.408C283.6293472000002 216.0960736 287.845304 228.199952 293.6480000000002 237.7200000000001C299.4506959999999 247.240048 307.0666191999999 254.3119776 316.4960000000001 258.9360000000001C325.9253807999999 263.5600224 337.3492655999999 265.8720000000001 350.7680000000001 265.8720000000001C363.098728 265.8720000000001 374.4319488000001 264.1493504 384.7680000000001 260.704C395.1040512 257.2586496 402.9013071999998 252.8160272 408.1599999999999 247.376L408.1599999999999 206.304L366.8159999999998 206.304L366.8159999999998 224.8zM344.2399999999998 154.0799999999999C341.1573183999999 154.0799999999999 337.6213536 153.7173376000001 333.6320000000001 152.992C329.6426464000001 152.2666624 325.562688 151.1786736 321.3919999999999 149.7280000000001C321.5733344 135.9465984000001 322.1626624000001 124.6587104 323.1599999999999 115.864C324.1573376000001 107.0692896000001 325.6079903999999 100.0880256 327.5120000000002 94.9200000000001C329.4160096000001 89.7519744 331.8186528000001 86.1706768 334.7200000000003 84.1759999999999C337.6213472 82.1813232 341.1573119999998 81.184 345.328 81.184C352.7627039999998 81.184 358.5199791999999 84.2213024 362.5999999999999 90.2960000000001C366.6800208 96.3706976000001 368.7200000000003 105.6639376000001 368.7200000000003 118.1759999999999C368.7200000000003 123.4346928 368.3120048000001 128.2853104000001 367.4960000000001 132.7280000000001C366.6799952000001 137.1706896000001 365.3200096000001 140.9786512000001 363.4160000000002 144.1520000000001C361.5119903999999 147.3253488 358.9733488000002 149.7733248 355.8000000000002 151.496C352.6266512000002 153.2186752 348.7733567999999 154.0799999999999 344.2399999999998 154.0799999999999z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="ipv6" /><glyph
+         id="glyph14991"
+         d=" M202.021 512C122.202 512 70.503 479.297 29.914 420.974C22.551 410.394 24.821 395.8880000000001 35.092 388.1L78.23 355.391C88.603 347.526 103.362 349.365 111.483 359.539C136.532 390.92 155.113 408.988 194.24 408.988C225.004 408.988 263.0560000000001 389.189 263.0560000000001 359.357C263.0560000000001 336.805 244.4390000000001 325.223 214.0630000000001 308.193C178.6400000000001 288.333 131.7640000000001 263.617 131.7640000000001 201.788V192C131.7640000000001 178.745 142.5090000000001 168 155.7640000000001 168H228.2350000000001C241.4900000000001 168 252.2350000000001 178.745 252.2350000000001 192V197.773C252.2350000000001 240.6330000000001 377.5030000000001 242.418 377.5030000000001 358.4000000000001C377.504 445.7440000000001 286.902 512 202.021 512zM192 138.541C153.804 138.541 122.729 107.466 122.729 69.27C122.729 31.075 153.804 0 192 0S261.271 31.075 261.271 69.271S230.1960000000001 138.541 192 138.541z"
+         horiz-adv-x="384"
+         unicode=""
+         glyph-name="noedconsensus" /><glyph
+         id="glyph14993"
+         d=" M569.517 71.987C587.975 39.993 564.806 0 527.94 0H48.054C11.117 0 -11.945 40.055 6.477 71.987L246.423 488.015C264.89 520.024 311.1430000000001 519.966 329.577 488.015L569.517 71.987zM288 158C262.5950000000001 158 242 137.405 242 112S262.5950000000001 66 288 66S334 86.595 334 112S313.405 158 288 158zM244.327 323.346L251.745 187.346C252.092 180.982 257.354 176 263.727 176H312.273C318.646 176 323.908 180.982 324.255 187.346L331.673 323.346C332.048 330.2200000000001 326.575 336 319.6910000000001 336H256.3080000000001C249.4240000000001 336 243.9520000000001 330.2200000000001 244.3270000000001 323.346z"
+         horiz-adv-x="576"
+         unicode=""
+         glyph-name="notrecommended" /><glyph
+         id="glyph14995"
+         d=" M285.8229263746506 251.9440820130475C269.5992544268407 266.7362534948742 249.0810810810811 278.6654240447344 228.0857409133272 290.5945945945946C218.542404473439 295.8434296365331 189.4352283317801 318.7474370922647 199.4557315936627 351.1947809878845L181.3233923578752 358.829450139795C209.9534016775396 403.2059645852749 247.1724137931035 447.1053122087605 292.9804287045667 488.1416589002796C256.2385834109972 475.7353215284249 223.7912395153775 456.6486486486486 199.4557315936627 422.7698042870457C213.7707362534949 452.8313140726934 237.1519105312209 482.4156570363467 262.9189189189189 512.4771668219944C227.6085740913327 487.1873252562908 197.0698974836906 458.5573159366263 177.9832246039143 420.3839701770736L191.3438956197577 473.8266542404473C172.2572227399814 439.47064305685 158.896551724138 404.6374650512581 153.6477166821995 369.8042870456664L125.4948741845294 381.2562907735321L120.7232059645853 377.4389561975769C145.5358807082946 333.0624417520969 132.6523765144455 309.6812674743709 120.2460391425909 301.569431500466C95.4333643988817 284.8685927306617 59.645852749301 263.3960857409133 41.5135135135135 244.7865796831314C7.1575023299161 209.4762348555452 -2.8630009319665 176.0745573159366 0.4771668219944 131.6980428704566C3.8173345759553 74.915191053122 45.3308480894688 27.6756756756756 100.2050326188257 9.0661696178937C124.5405405405406 0.9543336439887 146.9673811742777 -1e-13 171.780055917987 -1e-13C211.8620689655173 -1e-13 252.8984156570364 10.4976700838769 282.9599254426841 35.7875116495805C314.9301025163095 62.031686859273 333.5396085740914 102.1136999068033 333.5396085740914 143.1500465983224C333.5396085740914 184.663560111836 316.3616029822927 224.2684063373719 285.8229263746506 251.9440820130475zM88.7530288909599 26.2441752096924C44.37651444548 47.7166821994408 14.7921714818267 94.0018639328984 12.883504193849 131.6980428704566C9.0661696178938 208.5219012115563 45.8080149114632 230.9487418452936 80.1640260950606 259.1015843429637C99.2506989748369 274.8480894687791 125.9720410065238 282.4827586206897 141.2413793103449 310.6356011183597C144.1043802423113 316.8387698042871 146.0130475302889 330.1994408201305 142.1957129543337 344.5144454799627C140.7642124883505 349.2861136999068 133.6067101584343 366.4641192917055 130.7437092264679 370.2814538676608L173.2115563839702 351.6719478098788L173.2115563839702 351.6719478098788L173.2115563839702 351.6719478098788C172.2572227399814 331.6309412861137 171.780055917987 315.4072693383038 175.5973904939423 300.6150978564772C179.8918918918919 284.3914259086673 200.8872320596459 261.0102516309413 209.4762348555453 233.81174277726C226.1770736253496 182.2777260018639 221.8825722273999 114.9972041006524 209.9534016775397 62.5088536812675C208.0447343895621 53.9198508853681 201.8415657036347 43.4221808014912 194.2068965517242 33.878844361603C197.0698974836907 39.1276794035414 199.4557315936627 44.37651444548 200.8872320596459 50.1025163094129C212.8164026095061 92.5703634669152 218.0652376514446 112.134203168686 212.3392357875117 158.896551724138C211.3849021435229 163.6682199440821 209.4762348555453 178.9375582479031 202.3187325256291 195.6383970177074C192.2982292637465 220.928238583411 177.0288909599255 244.7865796831314 175.1202236719479 250.0354147250699C171.780055917987 258.1472506989749 167.0083876980429 292.5032618825722 166.5312208760485 315.8844361602983C167.0083876980429 295.8434296365331 168.4398881640261 259.1015843429637 173.6887232059646 244.7865796831314C175.1202236719478 240.0149114631873 188.9580615097857 218.5424044734389 198.9785647716682 192.2982292637465C205.65890027959 174.165890027959 207.0904007455732 157.4650512581547 208.5219012115564 152.6933830382106C213.2935694315005 131.2208760484622 207.5675675675676 94.9561975768872 199.9328984156571 60.6001863932899C197.547064305685 48.1938490214353 190.8667287977633 33.878844361603 182.2777260018639 22.9040074557315C187.049394221808 29.5843429636533 190.8667287977633 38.1733457595526 193.7297297297297 48.1938490214351C199.4557315936627 68.2348555452003 201.8415657036347 94.0018639328984 201.3643988816403 110.2255358807083C200.8872320596459 119.7688723205964 196.5927306616962 140.2870456663559 189.4352283317801 158.8965517241379C185.1407269338304 168.9170549860205 178.9375582479031 179.4147250698974 174.6430568499534 186.5722273998136C169.8713886300093 193.7297297297297 169.8713886300093 209.4762348555452 167.9627213420317 227.6085740913327C168.4398881640261 208.044734389562 166.5312208760485 198.0242311276794 171.3028890959926 184.1863932898415C174.165890027959 176.0745573159366 184.663560111836 164.6225535880708 187.5265610438024 153.6477166821994C191.8210624417521 138.8555452003727 196.1155638397018 122.6318732525628 195.6383970177074 112.6113699906803C195.6383970177074 101.1593662628145 195.161230195713 80.1640260950605 189.9123951537745 57.260018639329C186.5722273998136 40.0820130475303 178.9375582479031 25.2898415657036 166.5312208760485 15.7465051258154C171.780055917987 22.4268406337372 174.6430568499535 29.1071761416588 176.0745573159366 35.7875116495806C177.9832246039143 45.8080149114631 178.4603914259087 55.3513513513513 179.4147250698975 67.2805219012115C180.3690587138864 77.301025163094 179.8918918918919 90.1845293569431 177.0288909599255 104.0223671947809C173.2115563839702 121.2003727865796 167.0083876980429 138.3783783783783 164.1453867660764 150.3075489282385C164.6225535880709 136.9468779123952 169.8713886300093 120.2460391425909 172.2572227399814 102.5908667287977C174.165890027959 89.7073625349487 173.2115563839702 76.8238583410997 172.7343895619758 65.3718546132339C172.2572227399814 52.0111835973905 167.9627213420317 28.6300093196645 162.2367194780988 17.1780055917987C156.5107176141659 19.5638397017707 154.6020503261883 22.9040074557316 150.784715750233 27.6756756756757C146.0130475302889 33.878844361603 143.1500465983225 40.5591798695247 140.2870456663561 48.1938490214353C137.901211556384 53.9198508853681 135.515377446412 60.6001863932899 134.0838769804287 67.757688723206C132.6523765144455 79.2096924510718 133.1295433364399 96.8648648648648 146.0130475302889 114.9972041006524C156.0335507921715 129.3122087604846 157.9422180801491 130.2665424044735 161.28238583411 146.9673811742778C156.510717614166 132.1752096924511 153.1705498602051 130.7437092264679 142.6728797763281 118.3373718546133C130.7437092264679 104.4995340167754 128.8350419384903 84.4585274930103 128.8350419384903 68.2348555452004C128.8350419384903 61.5545200372787 131.6980428704567 53.9198508853681 134.0838769804288 46.762348555452C136.9468779123952 39.1276794035415 139.8098788443617 31.493010251631 143.6272134203169 25.767008387698C146.4902143522834 20.995340167754 150.3075489282387 17.6551724137931 153.6477166821995 15.269338303821C141.2413793103449 18.6095060577819 128.3578751164959 23.381174277726 120.2460391425909 30.0615097856477C100.2050326188258 47.2395153774463 82.5498602050327 76.3466915191053 80.1640260950606 102.1136999068033C78.255358807083 123.1090400745573 97.3420316868593 153.6477166821994 124.5405405405406 168.9170549860205C147.4445479962722 182.2777260018639 152.6933830382107 197.0698974836906 157.4650512581548 221.4054054054054C150.7847157502331 200.4100652376514 144.1043802423114 182.2777260018639 122.1547064305686 171.3028890959925C90.6616961789376 154.1248835041938 74.4380242311277 126.4492078285181 75.8695246971109 99.7278657968312C78.2553588070829 65.8490214352283 91.6160298229264 42.4678471575023 118.8145386766077 23.8583410997203C125.017707362535 19.5638397017706 133.6067101584343 15.269338303821 142.6728797763281 11.9291705498601C108.7940354147251 20.0410065237651 104.4995340167754 24.8126747437091 93.0475302889096 38.1733457595525C93.0475302889096 39.1276794035414 90.1845293569432 41.036346691519 90.1845293569432 41.5135135135134C74.9151910531221 58.6915191053121 55.8285181733458 88.2758620689654 49.148182665424 115.4743709226467C46.762348555452 125.0177073625349 44.37651444548 135.0382106244174 47.2395153774464 144.5815470643056C59.645852749301 189.43522833178 86.8443616029823 206.6132339235787 114.0428704566636 225.2227399813606C120.7232059645853 229.9944082013046 127.403541472507 234.2889095992544 133.6067101584343 239.0605778191984C148.8760484622554 250.9897483690586 152.6933830382107 282.0055917986952 156.0335507921715 299.6607642124883C149.8303821062442 278.1882572227399 143.1500465983225 251.4669151910531 131.2208760484623 242.8779123951537C125.017707362535 238.1062441752096 117.3830382106245 234.2889095992544 111.1798695246971 229.9944082013046C83.0270270270271 210.9077353215283 54.874184529357 192.7753960857408 41.9906803355079 146.4902143522832C39.1276794035415 134.561043802423 41.0363466915191 125.9720410065236 43.8993476234856 114.5200372786578C51.0568499534017 86.3671947809877 70.143522833178 55.8285181733456 86.3671947809879 37.696178937558C86.3671947809879 37.696178937558 89.2301957129544 34.8331780055916 89.2301957129544 34.8331780055916C96.3876980428705 26.7213420316867 105.4538676607643 20.5181733457594 116.4287045666357 16.2236719478096C106.4082013047531 18.6095060577819 97.3420316868593 21.9496738117427 88.7530288909599 26.2441752096924z"
+         horiz-adv-x="333.5396085740914"
+         unicode=""
+         glyph-name="onion-alt" /><glyph
+         id="glyph14997"
+         d=" M198.5300319999997 313.1915680000002C180.5147040000002 365.9338560000001 152.4059360000001 395.8352639999998 152 396.2267040000002L204.2640160000001 430.1897760000002C205.3681919999999 429.1029440000002 216.5102559999996 417.039264 229.8272159999997 396.6342559999998L229.8272159999997 512L296.7465759999996 512C296.7465759999996 512 297.0142400000005 410.7357280000001 296.7465759999996 403.3181920000002C314.6809599999997 420.48992 339.1399840000004 447.1441279999999 366.3427039999997 457.2243680000001L408 383.076208C374.2029439999997 370.5677759999999 352.6237600000004 338.001792 339.5471200000002 305.928144C339.7065279999997 305.8620639999999 339.8537280000001 305.7971520000001 339.9884160000002 305.733424C366.3900640000002 293.3918079999999 391.8492640000004 280.6537600000002 412.1234240000004 265.1290880000002C450.3139359999996 235.6712640000001 472 194.2682559999999 472 150.4779680000002C472 107.087008 448.4256480000004 65.2875680000002 408.8232159999998 37.42128C371.5785599999999 11.1465119999998 320.1906559999998 0 270.2146720000001 0C239.0975040000003 0 211.2805120000003 1.192192 181.1092159999998 9.5549919999999C112.2779039999996 29.0613920000001 60.8865599999999 78.8213759999999 56.6439360000004 138.5385919999999C52.8707999999997 185.1155199999998 65.1291840000004 220.545936 108.0352800000001 257.5678720000001C128.5335679999998 275.6151840000003 168.4076160000004 296.0478400000002 198.5300319999997 313.1915680000002z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="onion" /><glyph
+         id="glyph14999"
+         d=" M426.6666666666667 341.3333333333334H366.7200000000001C357.12 357.9733333333334 343.8933333333333 372.2666666666667 327.8933333333333 383.1466666666667L362.6666666666667 417.92L332.5866666666667 448L286.2933333333333 401.7066666666667C276.48 404.0533333333334 266.4533333333333 405.3333333333334 256 405.3333333333334C245.5466666666667 405.3333333333334 235.52 404.0533333333334 225.92 401.7066666666667L179.4133333333333 448L149.3333333333333 417.92L183.8933333333334 383.1466666666667C168.1066666666667 372.2666666666667 154.88 357.9733333333334 145.28 341.3333333333334H85.3333333333333V298.6666666666667H129.92C128.8533333333333 291.6266666666667 128 284.5866666666667 128 277.3333333333334V256H85.3333333333333V213.3333333333334H128V192C128 184.7466666666667 128.8533333333333 177.7066666666667 129.92 170.6666666666667H85.3333333333333V128H145.28C167.4666666666667 89.8133333333334 208.64 64 256 64S344.5333333333333 89.8133333333334 366.7200000000001 128H426.6666666666667V170.6666666666667H382.08C383.1466666666667 177.7066666666667 384 184.7466666666667 384 192V213.3333333333334H426.6666666666667V256H384V277.3333333333334C384 284.5866666666667 383.1466666666667 291.6266666666667 382.08 298.6666666666667H426.6666666666667V341.3333333333334zM298.6666666666667 170.6666666666667H213.3333333333333V213.3333333333334H298.6666666666667V170.6666666666667zM298.6666666666667 256H213.3333333333333V298.6666666666667H298.6666666666667V256z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="outdated" /><glyph
+         id="glyph15001"
+         d=" M154.2776470399999 176.0752944000001L178.7858824 87.0023535999999L206.72 176.0752944000001L250.4658824000001 176.0752944000001L199.0776470400001 28.2352943999999L156.9129411199999 28.2352943999999L107.896470592 176.0752944000001L154.2776470399999 176.0752944000001zM384.0752944000001 235.3694112000001L384.0752944000001 109.6658815999999L402.5223536 109.6658815999999L402.5223536 73.8258816L384.0752944000001 73.8258816L384.0752944000001 28.2352943999999L341.9105887999999 28.2352943999999L341.9105887999999 73.8258816L262.8517648 73.8258816L262.8517648 110.4564704L346.3905888 235.3694112000001L384.0752944000001 235.3694112000001zM341.9105887999999 109.6658815999999L341.9105887999999 170.2776463999999L301.3270591999999 109.6658815999999L341.9105887999999 109.6658815999999z M114.823536 422.0172921599999L114.823536 430.2987665600001C114.823536 437.1594504 120.7490874720001 442.7209780799999 128.058830112 442.7209780799999L326.5882416000001 442.7209780799999L326.5882416000001 467.565401088C326.5882416000001 478.6247924720001 340.8707791999999 484.1500886399999 349.1825439999999 476.349457392L393.3001903999999 434.9420857600001C398.4685728000001 430.09069456 398.4685728000001 422.22536432 393.3001903999999 417.3744907200001L349.1825439999999 375.9671188800001C340.9022128000001 368.1970256 326.5882416000001 373.64520064 326.5882416000001 384.7506576000001L326.5882416000001 409.5950806400001L128.058830112 409.5950806400001C120.7490874720001 409.5950806400001 114.823536 415.1566083200001 114.823536 422.0172921599999zM383.9411824 343.34328592L185.41177136 343.34328592L185.41177136 368.18770896C185.41177136 379.219668 171.14963888 384.7920649600001 162.8174697599999 376.97176528L118.699822768 335.5643935999999C113.5314404112 330.7130024000001 113.5314404112 322.84767216 118.699822768 317.9967984L162.8174697599999 276.5894272000001C171.10496976 268.8115696 185.41177136 274.2773424 185.41177136 285.3729648000001L185.41177136 310.2173888L383.9411824 310.2173888C391.2509263999999 310.2173888 397.1764768 315.7789168 397.1764768 322.6396001600001L397.1764768 330.9210744C397.1764768 337.7817584 391.2509263999999 343.34328592 383.9411824 343.34328592z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="reachableipv4" /><glyph
+         id="glyph15003"
+         d=" M147.9200000000001 189.0799999999999L173.96 94.4400000000001L203.6399999999999 189.0799999999999L250.1199999999999 189.0799999999999L195.52 32L150.7199999999998 32L98.6399999999999 189.0799999999999L147.9200000000001 189.0799999999999zM361.8400000000002 214C359.9733248000003 215.4933408 357.500016 216.566664 354.4200000000001 217.22C351.3399840000002 217.8733360000001 348.2133488 218.2000000000001 345.04 218.2000000000001C340.1866432000002 218.2000000000001 335.9866848000002 217.0333456000001 332.4400000000001 214.7000000000001C328.8933152 212.3666544 325.9533455999999 209.1000208000001 323.6199999999999 204.9000000000001C321.2866543999999 200.6999791999999 319.5133391999998 195.706696 318.3000000000002 189.9200000000001C317.0866608000001 184.133304 316.2000032000001 177.6933696000001 315.6399999999999 170.5999999999999C321.0533599999999 172.6533440000001 326.5133056 174.006664 332.02 174.6600000000001C337.5266944 175.3133359999999 342.7999743999999 175.6399999999999 347.8400000000002 175.6399999999999C359.0400559999998 175.6399999999999 368.4666287999999 174.0533488000001 376.1199999999999 170.8800000000001C383.7733712 167.7066512000001 389.9799760000001 163.0866976 394.7399999999998 157.02C399.500024 150.9533024 402.9533231999999 143.5800432000001 405.0999999999999 134.9000000000001C407.2466768 126.2199568000001 408.3200000000002 116.3733887999999 408.3200000000002 105.3600000000001C408.3200000000002 89.4932544000001 406.4066864000002 76.5200512000001 402.58 66.4400000000001C398.7533136000002 56.3599503999999 393.5733664 48.4733615999999 387.04 42.78C380.5066336 37.0866384000001 372.9933759999999 33.1666768 364.5 31.02C356.0066240000001 28.8733232 347.0933808 27.8 337.7600000000002 27.8C326.1866095999999 27.8 316.1533760000002 29.339984 307.6599999999999 32.4200000000001C299.166624 35.500016 292.0733615999998 41.09996 286.3800000000001 49.22C280.6866384 57.3400400000001 276.4400144000001 68.3999296 273.6399999999999 82.4000000000001C270.8399856000001 96.4000704 269.4400000000001 114.3198912 269.4400000000001 136.1600000000001C269.4400000000001 156.8801040000001 270.7933199999998 174.7999248000001 273.5 189.9200000000001C276.2066800000003 205.0400752000001 280.5466367999998 217.4999504 286.52 227.3C292.4933632000002 237.1000495999999 300.3332848 244.379976 310.04 249.1399999999999C319.7467152 253.9000240000001 331.5065983999998 256.28 345.3200000000002 256.28C358.0133968 256.28 369.6799472000003 254.5066847999999 380.3200000000002 250.9600000000001C390.9600528000001 247.4133152 398.9866400000001 242.8400288000001 404.4000000000001 237.24L404.4000000000001 194.96L361.8400000000002 194.96L361.8400000000002 214zM338.5999999999999 141.2000000000001C335.4266511999999 141.2000000000001 331.7866880000002 140.8266704 327.6799999999999 140.0799999999999C323.5733135999999 139.3333296000001 319.3733551999999 138.2133408 315.08 136.72C315.2666672000001 122.5332624 315.8733280000002 110.9133792 316.9000000000001 101.8600000000001C317.9266720000001 92.8066208 319.4199904000002 85.6200272000001 321.3800000000001 80.3C323.3400096000001 74.9799728 325.8133183999999 71.2933439999999 328.8000000000002 69.24C331.7866816000001 67.1866560000001 335.4266447999999 66.1600000000001 339.7199999999998 66.1600000000001C347.3733711999999 66.1600000000001 353.2999792000001 69.2866352000001 357.5 75.54C361.7000208 81.7933648000001 363.8000000000002 91.3599360000001 363.8000000000002 104.24C363.8000000000002 109.65336 363.3800047999998 114.6466432 362.54 119.22C361.6999952000001 123.7933568000001 360.3000096000001 127.7133168 358.3400000000002 130.98C356.3799903999998 134.2466832 353.7666832 136.7666575999999 350.5 138.54C347.2333168 140.3133424 343.2666896000001 141.2000000000001 338.5999999999999 141.2000000000001z M116 433.96255744L116 442.8231558400001C116 450.16360784 122.1990384639999 456.1140534399999 129.8461538400002 456.1140534399999L337.5384608 456.1140534399999L337.5384608 482.6958487039999C337.5384608 494.5286241136 352.480192 500.440304624 361.1755776 492.0941747039999L407.3294224000001 447.7911825599999C412.7363455999998 442.6005332800001 412.7363455999998 434.18518 407.3294224000001 428.9950844800001L361.1755776 384.6920923200001C352.5130767999999 376.37863584 337.5384608 382.20780208 337.5384608 394.08986448L337.5384608 420.67165968L129.8461538400002 420.67165968C122.1990384639999 420.67165968 116 426.6221054400001 116 433.96255744zM397.5384608 349.78687232L189.8461539199998 349.78687232L189.8461539199998 376.3686676800001C189.8461539199998 388.1720923200001 174.9257692800002 394.1341675200001 166.2090383999998 385.7669936L120.0551923039998 341.4640016000001C114.6482692303998 336.2733521600001 114.6482692303998 327.8579984000001 120.0551923039998 322.6679039999999L166.2090383999998 278.364912C174.8790383999999 270.0431472 189.8461539199998 275.8911424000001 189.8461539199998 287.7626832000001L189.8461539199998 314.3444784000001L397.5384608 314.3444784000001C405.1855776000002 314.3444784000001 411.3846159999998 320.2949248 411.3846159999998 327.635376L411.3846159999998 336.4959747200001C411.3846159999998 343.83642672 405.1855776000002 349.78687232 397.5384608 349.78687232z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="reachableipv6" /><glyph
+         id="glyph15005"
+         d=" M238.4790720000001 415.5708528L313.2039519999999 365.7542672C321.5206559999997 369.4821792 330.7404319999996 371.5555552000001 340.4444480000002 371.5555552000001C377.2632000000003 371.5555552000001 407.1111039999996 341.7076384 407.1111039999996 304.8888896000001C407.1111039999996 268.0701392000001 377.2632000000003 238.2222224 340.4444480000002 238.2222224C324.7444480000004 238.2222224 310.3145759999998 243.6520832000001 298.9236160000001 252.7333328L227.7527840000003 208.2513888000001C229.8604160000005 198.7176416 229.8604160000005 188.838608 227.7527840000003 179.3048607999999L298.9236160000001 134.8229168C310.3145759999998 143.903472 324.7444480000004 149.3333328000001 340.4444480000002 149.3333328000001C377.2632000000003 149.3333328000001 407.1111039999996 119.485416 407.1111039999996 82.6666671999999C407.1111039999996 45.8479167999999 377.2632000000003 16 340.4444480000002 16C303.6256960000001 16 273.7777759999999 45.8479167999999 273.7777759999999 82.6666671999999C273.7763679999998 87.5341152000001 274.3063519999996 92.3871727999999 275.3583360000003 97.139584L204.1875040000005 141.6215279999999C192.7965279999999 132.5409728 178.3666720000001 127.1111103999999 162.6666720000003 127.1111103999999C125.8479200000002 127.1111103999999 96 156.9590272 96 193.7777776C96 230.5965280000001 125.8479200000002 260.4444448 162.6666720000003 260.4444448C178.3666720000001 260.4444448 192.7965279999999 255.014584 204.1875040000005 245.9340272L275.3583360000003 290.4159728C274.326384 295.0763887999999 273.7777759999999 299.918056 273.7777759999999 304.8888896000001C273.7777759999999 316.4405088000001 276.7158399999999 327.3059584 281.885456 336.77872L213.7660800000003 382.1916448C203.8325759999998 375.4767664000001 191.8556959999996 371.5555552000001 178.9629599999999 371.5555552000001C144.5985760000003 371.5555552000001 116.7407359999998 399.4133936000001 116.7407359999998 433.7777776000001C116.7407359999998 468.1421616 144.5985760000003 496 178.9629599999999 496C213.3273440000003 496 241.185184 468.1421616 241.185184 433.7777776000001C241.185184 427.4431279999999 240.2385599999998 421.3295711999999 238.4790720000001 415.5708528z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="relay" /><glyph
+         id="glyph15007"
+         d=" M0 344V360C0 373.255 10.745 384 24 384H384V432C384 453.367 409.899 464.042 424.971 448.971L504.971 368.971C514.343 359.598 514.343 344.4020000000001 504.971 335.03L424.971 255.03C409.956 240.018 384 250.544 384 272V320H24C10.745 320 0 330.745 0 344zM488 192H128V240C128 261.314 102.138 272.08 87.029 256.971L7.029 176.971C-2.343 167.598 -2.343 152.402 7.029 143.03L87.029 63.03C102.057 48.003 128 58.563 128 80V128H488C501.255 128 512 138.745 512 152V168C512 181.255 501.255 192 488 192z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="running" /><glyph
+         id="glyph15009"
+         d=" M256 504C119.033 504 8 392.967 8 256S119.033 8 256 8S504 119.033 504 256S392.967 504 256 504zM336 256C336 211.888 300.112 176 256 176S176 211.888 176 256S211.888 336 256 336S336 300.112 336 256z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="stable" /><glyph
+         id="glyph15011"
+         d=" M496 306.793232C481.3473759999997 291.6353439999998 419.7052640000002 256.2669120000001 419.7052640000002 256.2669120000001L393.431584 288.0984960000001C386.8631519999999 253.7406080000001 390.905264 92.5616479999999 393.431584 18.793232C293.3894719999999 3.1300799999999 183.2421119999999 14.245856 127.6631520000001 18.793232C133.7263199999998 108.2248159999999 123.1157919999996 288.0984960000001 123.1157919999996 288.0984960000001C123.1157919999996 288.0984960000001 108.4631520000003 274.4563840000001 96.3368479999999 256.772176C61.9789440000004 256.2669120000001 16 300.2248159999999 16 300.2248159999999C16 300.2248159999999 64.5052640000004 389.15112 81.6842079999997 417.4458559999998C95.3263200000001 439.67744 157.9789440000004 465.4458559999998 163.0315840000003 468.4774400000001C165.0526239999999 469.4879679999999 174.6526240000003 474.0353439999999 185.2631520000005 479.0879679999998C187.284208 480.0984960000001 189.3052639999996 479.0879679999998 190.3157920000003 477.5721760000001C201.9368480000003 458.3721759999999 227.1999999999998 444.7300799999998 256.5052640000004 444.7300799999998C285.810528 444.7300799999998 311.5789439999999 458.3721759999999 323.1999999999998 478.07744C324.2105279999996 479.5932320000002 326.2315840000001 480.60376 328.2526239999998 479.5932320000002C353.0105279999998 467.4669119999999 390.3999999999997 448.2669120000001 405.5578880000003 435.6353439999998C428.8000000000002 415.9300800000001 478.8210559999998 334.07744 496 306.793232z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="tshirt" /><glyph
+         id="glyph15013"
+         d=" M256 504C119 504 8 393 8 256S119 8 256 8S504 119 504 256S393 504 256 504zM352 176C352 167.2 344.8 160 336 160H176C167.2 160 160 167.2 160 176V336C160 344.8 167.2 352 176 352H336C344.8 352 352 344.8 352 336V176z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="unmeasured" /><glyph
+         id="glyph15015"
+         d=" M384.3907536000001 299.3691904000002C392.3892192 285.071872 382.3493216000001 267.1999999999998 366.3740592000001 267.1999999999998L158.4235182399999 267.1999999999998C142.41748952 267.1999999999998 132.423959024 285.0995776 140.406823424 299.3691904000002L244.38339392 485.2817010240001C252.38575824 499.5857227679999 272.4287192000001 499.5598040159998 280.4167836800001 485.2817010240001L384.3907536000001 299.3691904000002zM262.4000888 337.80624928C251.39125856 337.80624928 242.4667611200001 328.6028592000003 242.4667611200001 317.25C242.4667611200001 305.8971407999998 251.39125856 296.6937503999998 262.4000888 296.6937503999998C273.4089190400001 296.6937503999998 282.33341648 305.8971407999998 282.33341648 317.25C282.33341648 328.6028592000003 273.4089190400001 337.80624928 262.4000888 337.80624928zM243.47512752 411.6952424000001L246.6895932799999 350.92024288C246.83995984 348.0763304000002 249.1201592000001 345.8499992000002 251.8817918400001 345.8499992000002L272.91838576 345.8499992000002C275.6800184 345.8499992000002 277.9602177600001 348.0763304000002 278.11058432 350.92024288L281.3250500800001 411.6952424000001C281.48755008 414.7670611200001 279.1159174400001 417.3499985600002 276.1328515199999 417.3499985600002L248.6668926400001 417.3499985600002C245.6838268800001 417.3499985600002 243.3126275200001 414.7670611200001 243.47512752 411.6952424000001z M149.0432000000001 166.7968000000001L174.0416 75.9423999999999L202.5344 166.7968000000001L247.1551999999999 166.7968000000001L194.7392 16L151.7312 16L101.7344000000001 166.7968000000001L149.0432000000001 166.7968000000001zM383.4368 227.2768000000001L383.4368 99.0592000000002L402.2528 99.0592000000002L402.2528 62.5023999999999L383.4368 62.5023999999999L383.4368 16L340.4288 16L340.4288 62.5023999999999L259.7888000000001 62.5023999999999L259.7888000000001 99.8656000000001L344.9984 227.2768000000001L383.4368 227.2768000000001zM340.4288 99.0592000000002L340.4288 160.8832000000002L299.0336 99.0592000000002L340.4288 99.0592000000002z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="unreachableipv4" /><glyph
+         id="glyph15017"
+         d=" M381.1907535999998 299.3691904000002C389.1892191999999 285.071872 379.1493215999998 267.1999999999998 363.1740592 267.1999999999998L155.2235182399999 267.1999999999998C139.21748952 267.1999999999998 129.2239590240001 285.0995776 137.206823424 299.3691904000002L241.18339392 485.2817010240001C249.1857582400002 499.5857227679999 269.2287191999998 499.5598040159998 277.2167836799998 485.2817010240001L381.1907535999998 299.3691904000002zM259.2000888000001 337.80624928C248.1912585600002 337.80624928 239.2667611199999 328.6028592000003 239.2667611199999 317.25C239.2667611199999 305.8971407999998 248.1912585600002 296.6937503999998 259.2000888000001 296.6937503999998C270.2089190400001 296.6937503999998 279.13341648 305.8971407999998 279.13341648 317.25C279.13341648 328.6028592000003 270.2089190400001 337.80624928 259.2000888000001 337.80624928zM240.2751275200002 411.6952424000001L243.4895932799999 350.92024288C243.6399598400002 348.0763304000002 245.9201591999999 345.8499992000002 248.6817918400001 345.8499992000002L269.7183857600002 345.8499992000002C272.4800184 345.8499992000002 274.7602177600001 348.0763304000002 274.9105843199999 350.92024288L278.1250500800001 411.6952424000001C278.28755008 414.7670611200001 275.9159174400001 417.3499985600002 272.9328515199999 417.3499985600002L245.4668926399999 417.3499985600002C242.4838268799999 417.3499985600002 240.1126275199999 414.7670611200001 240.2751275200002 411.6952424000001z M155.4432000000002 166.7968000000001L180.4416000000001 75.9423999999999L208.9344000000001 166.7968000000001L253.5551999999998 166.7968000000001L201.1392000000001 16L158.1311999999998 16L108.1343999999999 166.7968000000001L155.4432000000002 166.7968000000001zM360.8064 190.7200000000003C359.0143904000002 192.1536064000002 356.6400144 193.1839967999999 353.6832 193.8112000000001C350.7263856 194.4384031999998 347.7248159999999 194.752 344.6783999999998 194.752C340.0191759999998 194.752 335.9872175999999 193.6320111999999 332.5824000000003 191.3919999999998C329.1775824000001 189.1519888000003 326.3552112000002 186.0160207999998 324.1152000000002 181.9839999999999C321.8751888000002 177.9519792000001 320.1728063999999 173.1584272 319.0079999999998 167.6032C317.8431936000002 162.0479728 316.9920032 155.8656335999999 316.4544000000001 149.0560000000001C321.6512256000001 151.0272095999999 326.8927727999999 152.3263968000001 332.1792000000001 152.9535999999998C337.4656272000002 153.5808032 342.5279759999999 153.8944000000001 347.3663999999999 153.8944000000001C358.1184543999998 153.8944000000001 367.1679632000001 152.371216 374.5151999999998 149.3247999999999C381.8624368000001 146.2783840000002 387.8207776 141.8432287999999 392.3904000000003 136.0192000000002C396.9600224000001 130.1951712 400.2751904000002 123.1168416000001 402.3360000000003 114.7840000000001C404.3968095999999 106.4511584000002 405.4272000000001 96.9984528 405.4272000000001 86.4256C405.4272000000001 71.1935232000001 403.5904175999999 58.7392479999999 399.9168 49.0623999999998C396.2431824 39.3855520000002 391.2704320000003 31.8144272 384.9984 26.3487999999998C378.7263680000001 20.8831728 371.5136400000001 17.1200096000002 363.3600000000002 15.0592000000001C355.2063600000002 12.9983904000001 346.6496447999998 11.9679999999998 337.6896000000002 11.9679999999998C326.5791439999998 11.9679999999998 316.94724 13.4463856000002 308.7936 16.4032000000002C300.63996 19.3600144000002 293.8304272000001 24.7359615999999 288.3647999999999 32.5311999999999C282.8991728000001 40.3264383999999 278.8224128000002 50.9439327999999 276.1343999999999 64.384C273.4463872000001 77.8240672000002 272.1023999999998 95.0270943999999 272.1023999999998 115.9935999999998C272.1023999999998 135.8848991999998 273.4015872 153.0879279999999 276 167.6032C278.5984128 182.1184720000001 282.7647711999998 194.0799536 288.4992000000002 203.4879999999998C294.2336288000002 212.8960464000002 301.7599535999998 219.8847776000002 311.0783999999999 224.4544000000001C320.3968464 229.0240223999999 331.6863343999999 231.3087999999998 344.9472000000001 231.3087999999998C357.1328607999999 231.3087999999998 368.3327488 229.6064176 378.5472 226.2015999999999C388.7616512 222.7967823999998 396.4671743999998 218.4064272000001 401.6639999999998 213.0304000000001L401.6639999999998 172.4416000000001L360.8064 172.4416000000001L360.8064 190.7200000000003zM338.4960000000001 120.8319999999999C335.449584 120.8319999999999 331.9552192000001 120.4736032000001 328.0128 119.7568000000001C324.0703807999999 119.0399968000002 320.0384208000001 117.9648063999998 315.9168 116.5311999999999C316.0960015999999 102.9119312000003 316.6783952000001 91.7568431999998 317.6639999999998 83.0655999999999C318.6496047999999 74.3743568 320.0831904000002 67.4752256000002 321.9648000000002 62.3679999999999C323.8464095999998 57.2607744000002 326.2207856 53.7216096000002 329.0880000000002 51.7503999999999C331.9552144 49.7791904000001 335.4495791999998 48.7936 339.5711999999999 48.7936C346.9184368000001 48.7936 352.6079792000001 51.7951696 356.6399999999999 57.7984000000001C360.6720208000002 63.8016304000003 362.6880000000001 72.9855376 362.6880000000001 85.3503999999998C362.6880000000001 90.5472255999998 362.2848048000001 95.3407775999999 361.4784 99.7312000000002C360.6719951999999 104.1216224 359.3280095999999 107.8847839999999 357.4463999999998 111.0208000000002C355.5647903999998 114.1568160000002 353.056016 116.5759920000001 349.9200000000001 118.2784000000002C346.7839840000002 119.9808080000003 342.9760224000002 120.8319999999999 338.4960000000001 120.8319999999999z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="unreachableipv6" /><glyph
+         id="glyph15019"
+         d=" M452.9230767999998 352C459.0403071999999 352 464 356.8357 464 362.8L464 398.8C464 404.7643000000001 459.0403071999999 409.6 452.9230767999998 409.6L434.4615391999996 409.6L434.4615391999996 452.8C434.4615391999996 476.659 414.6246160000001 496 390.1538464000005 496L124.3076923199997 496C99.8369230400003 496 80 476.659 80 452.8L80 78.4C80 54.5409999999999 99.8369230400003 35.2 124.3076923199997 35.2L390.1538464000005 35.2C414.6246160000001 35.2 434.4615391999996 54.5409999999999 434.4615391999996 78.4L434.4615391999996 121.6L452.9230767999998 121.6C459.0403071999999 121.6 464 126.4356992000001 464 132.4L464 168.4C464 174.3643008 459.0403071999999 179.2000000000001 452.9230767999998 179.2000000000001L434.4615391999996 179.2000000000001L434.4615391999996 236.8L452.9230767999998 236.8C459.0403071999999 236.8 464 241.6356992 464 247.6L464 283.6C464 289.5643008 459.0403071999999 294.4 452.9230767999998 294.4L434.4615391999996 294.4L434.4615391999996 352L452.9230767999998 352z M167.4975744000003 437.9845376L188.5962399999999 318.0165440000001L213.3749055999997 437.9845376H255.3269120000005L208.9589056000004 245.1525440000001H166.7615744000004L122.6015744000004 437.9845376000001z M273.4892319999999 424.7365376Q278.3959039999999 429.8885376 285.0199039999999 433.077872Q291.8892319999999 436.2672048 299.2492319999999 438.229872Q306.8545599999999 440.1925376000001 314.4599039999999 440.9285376000001Q322.3105599999999 441.6645376 329.4252319999999 441.6645376Q342.9185599999999 441.6645376 354.2039039999999 438.7205376Q365.7345599999999 436.0218720000001 373.8305599999999 429.1525376Q382.1718879999999 422.5285392 386.5878879999999 410.7525392Q391.2492319999999 399.221872 391.2492319999999 381.557872Q391.2492319999999 371.7445392 388.0598879999999 361.1952064Q384.8705599999999 350.8912064 377.0198879999998 338.3792064000001Q369.4145599999998 326.112544 356.1665599999999 311.3925440000001Q343.1639039999999 296.672544 323.0465599999999 278.517872H393.9478879999998V245.1525440000001H274.4705599999998V277.291216Q297.5319039999998 297.1632 312.2519039999998 312.373872Q326.9719039999998 327.829872 335.3132319999998 340.3418736Q343.8999039999998 352.8538736000001 347.0892319999998 363.1578736Q350.2785599999998 373.7072064 350.2785599999998 383.765872Q350.2785599999998 397.749872 344.8812319999998 402.9018720000001Q339.4839039999997 408.2992048 329.6705599999998 408.2992048Q324.0279039999998 408.2992048 319.3665599999998 406.8272048Q314.9505599999998 405.6005328 310.7799039999998 403.1472048V387.9365392H273.4892319999998z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="v2dir" /><glyph
+         id="glyph15021"
+         d=" M504 256C504 119.033 392.967 8 256 8S8 119.033 8 256S119.033 504 256 504S504 392.967 504 256zM227.314 124.686L411.314 308.686C417.562 314.934 417.562 325.065 411.314 331.313L388.687 353.94C382.439 360.189 372.308 360.189 366.059 353.94L216 203.882L145.941 273.9410000000001C139.693 280.189 129.562 280.189 123.313 273.9410000000001L100.686 251.314C94.438 245.0660000000001 94.438 234.935 100.686 228.687L204.686 124.687C210.935 118.438 221.065 118.438 227.314 124.686z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="valid" /></font><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-9"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-3" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-9-4"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-3-5" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-0"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-6" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-5"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-5" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-5-9"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-5-3" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-4"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-52" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-47"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-4" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker9036-6"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path9034-8" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8855-5"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8853-8" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-7"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"><path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-0" /></marker><filter
+       id="filter-3-0"
+       filterUnits="objectBoundingBox"
+       height="1.1043478"
+       width="1.2424242"
+       y="-0.052173913"
+       x="-0.13852814"><feOffset
+         id="feOffset1122-4"
+         result="shadowOffsetOuter1"
+         in="SourceAlpha"
+         dy="0"
+         dx="-8" /><feGaussianBlur
+         id="feGaussianBlur1124-2"
+         result="shadowBlurOuter1"
+         in="shadowOffsetOuter1"
+         stdDeviation="10" /><feColorMatrix
+         id="feColorMatrix1126-9"
+         in="shadowBlurOuter1"
+         type="matrix"
+         values="0 0 0 0 0.250980392   0 0 0 0 0.250980392   0 0 0 0 0.250980392  0 0 0 0.2 0" /></filter><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6925-3"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"
+       viewBox="0 0 8.886927 5.078244"
+       markerWidth="8.8869267"
+       markerHeight="5.0782437"
+       preserveAspectRatio="xMidYMid"><path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6923-6" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6500"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"
+       viewBox="0 0 8.886927 5.078244"
+       markerWidth="8.8869267"
+       markerHeight="5.0782437"
+       preserveAspectRatio="xMidYMid"><path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6498" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6925-3-3"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"
+       viewBox="0 0 8.886927 5.078244"
+       markerWidth="8.8869267"
+       markerHeight="5.0782437"
+       preserveAspectRatio="xMidYMid"><path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6923-6-5" /></marker><filter
+       id="filter-3-0-1"
+       filterUnits="objectBoundingBox"
+       height="1.1043478"
+       width="1.2424242"
+       y="-0.052173913"
+       x="-0.13852814"><feOffset
+         id="feOffset1122-4-9"
+         result="shadowOffsetOuter1"
+         in="SourceAlpha"
+         dy="0"
+         dx="-8" /><feGaussianBlur
+         id="feGaussianBlur1124-2-4"
+         result="shadowBlurOuter1"
+         in="shadowOffsetOuter1"
+         stdDeviation="10" /><feColorMatrix
+         id="feColorMatrix1126-9-7"
+         in="shadowBlurOuter1"
+         type="matrix"
+         values="0 0 0 0 0.250980392   0 0 0 0 0.250980392   0 0 0 0 0.250980392  0 0 0 0.2 0" /></filter><linearGradient
+       inkscape:collect="always"
+       xlink:href="#linearGradient-1"
+       id="linearGradient1169-8"
+       x1="198.26646"
+       y1="346.52609"
+       x2="198.26646"
+       y2="20.550627"
+       gradientTransform="scale(0.7086423,1.4111492)"
+       gradientUnits="userSpaceOnUse" /><linearGradient
+       inkscape:collect="always"
+       xlink:href="#linearGradient-1"
+       id="linearGradient13221"
+       gradientUnits="userSpaceOnUse"
+       x1="256"
+       y1="512"
+       x2="256"
+       y2="0" /><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6925-3-3-9"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"
+       viewBox="0 0 8.886927 5.078244"
+       markerWidth="8.8869267"
+       markerHeight="5.0782437"
+       preserveAspectRatio="xMidYMid"><path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6923-6-5-3" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-5"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-0" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-5-8"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-0-7" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-5-7"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-0-2" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-5-8-2"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-0-7-2" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-5-7-1"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-0-2-0" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-5-7-1-1"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-0-2-0-5" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-5-7-1-1-4"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-0-2-0-5-9" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-5-8-2-9"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-0-7-2-1" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-7"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-1" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-59"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-7" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-6"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-73" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-56"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-3" /></marker><marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188-7-9"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend"
+       viewBox="0 0 6.9304588 5.1962256"
+       markerWidth="6.9304581"
+       markerHeight="5.1962252"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186-1-3" /></marker><style
+       id="style1945">.cls-1,.cls-10,.cls-11,.cls-2,.cls-3,.cls-7{fill:none;}.cls-2,.cls-7{stroke:#6fc8b7;}.cls-10,.cls-11,.cls-2,.cls-3,.cls-7{stroke-linecap:round;stroke-linejoin:round;}.cls-2{stroke-width:3px;}.cls-3{stroke:#240a3b;}.cls-10,.cls-11,.cls-3,.cls-7{stroke-width:1.6px;}.cls-4,.cls-6{fill:#895ba5;}.cls-5{fill:#240a3b;}.cls-11,.cls-6{stroke:#895ba5;}.cls-6{stroke-miterlimit:10;stroke-width:0.75px;}.cls-8{fill:#cf63a6;}.cls-9{fill:#fed916;}.cls-10{stroke:#cf63a6;}</style></defs><g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(1.5636956e-6,-128.29397)"><g
+       id="layer1-7"
+       inkscape:label="Calque 1"
+       transform="matrix(0.12507748,0,0,0.12507748,-54.599467,110.05953)"><path
+         id="path1212"
+         d="m 643.39,655.28 124.68,0.46875 0.1225,29.272 -0.0925,1.5138 -0.55675,2.08 -1.045,2.3975 -1.6405,2.1092 -2.7344,2.6367 -3.5449,2.5293 -4.458,2.3828 -5.4199,2.2802 -7.1924,2.3828 -6.8896,1.7188 -12.183,1.919 -9.5508,0.86925 -5.9766,0.1525 -12.056,-0.40525 -12.539,-1.4258 -8.5107,-1.9238 -4.9414,-1.2598 -4.7607,-1.4698 -4.9121,-2.08 -4.0039,-1.9728 -4.6582,-2.9394 -2.8858,-2.583 -1.5235,-1.8212 -1.6162,-2.6367 -0.8155,-1.87 -0.49325,-2.583 z"
+         style="fill:#bdbdbd;fill-rule:evenodd;stroke:#7d7d7d;stroke-width:3.75;stroke-miterlimit:10"
+         inkscape:connector-curvature="0" /><path
+         id="path1214"
+         d="m 768.23,654.01 c 0,13.809 -27.983,25 -62.5,25 -34.517,0 -62.5,-11.191 -62.5,-25 0,-13.804 27.983,-25 62.5,-25 34.517,0 62.5,11.196 62.5,25"
+         style="fill:#bdbdbd;fill-rule:evenodd;stroke:#7d7d7d;stroke-width:3.75;stroke-miterlimit:10"
+         inkscape:connector-curvature="0" /><path
+         id="path1216"
+         d="m 664.04,639.99 8.6182,-3.2031 22.207,8.9502 9.3896,-3.3154 -4.1992,8.2862 -24.194,-0.1125 6.7383,-2.539 z"
+         style="fill:#ffffff;fill-rule:evenodd;stroke:#7d7d7d;stroke-width:1.25;stroke-miterlimit:10"
+         inkscape:connector-curvature="0" /><path
+         id="path1218"
+         d="m 716.96,660.42 -10.718,3.0908 4.1992,-9.0576 26.626,0.332 -10.054,3.0908 19.443,8.3984 -8.2861,3.3154 z"
+         style="fill:#ffffff;fill-rule:evenodd;stroke:#7d7d7d;stroke-width:1.25;stroke-miterlimit:10"
+         inkscape:connector-curvature="0" /><path
+         id="path1220"
+         d="m 707.02,648.6 19.551,-8.3984 -10.273,-2.9834 26.738,-0.22 4.9707,8.5058 -9.0625,-2.7588 -22.754,9.2773 z"
+         style="fill:#ffffff;fill-rule:evenodd;stroke:#7d7d7d;stroke-width:1.25;stroke-miterlimit:10"
+         inkscape:connector-curvature="0" /><path
+         id="path1222"
+         d="m 683.93,666.06 7.3975,2.7588 -24.414,-0.22 -5.5224,-9.0576 10.161,3.5352 22.432,-9.502 9.0576,3.6475 z"
+         style="fill:#ffffff;fill-rule:evenodd;stroke:#7d7d7d;stroke-width:1.25;stroke-miterlimit:10"
+         inkscape:connector-curvature="0" /></g><image
+       preserveAspectRatio="none"
+       inkscape:svg-dpi="96"
+       width="11.086322"
+       height="15.798007"
+       xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjwh LS0gQ3JlYXRlZCB3aXRoIElua3NjYXBlIChodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy8pIC0tPgo8 c3ZnCiAgICB4bWxuczppbmtzY2FwZT0iaHR0cDovL3d3dy5pbmtzY2FwZS5vcmcvbmFtZXNwYWNl cy9pbmtzY2FwZSIKICAgIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1y ZGYtc3ludGF4LW5zIyIKICAgIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIKICAg IHhtbG5zOnNvZGlwb2RpPSJodHRwOi8vc29kaXBvZGkuc291cmNlZm9yZ2UubmV0L0RURC9zb2Rp cG9kaS0wLmR0ZCIKICAgIHhtbG5zOm5zMT0iaHR0cDovL3NvemkuYmFpZXJvdWdlLmZyIgogICAg eG1sbnM6Y2M9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1vbnMub3JnL25zIyIKICAgIHhtbG5zOnhsaW5r PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIgogICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJs Lm9yZy9kYy9lbGVtZW50cy8xLjEvIgogICAgaWQ9InN2ZzMwMjEiCiAgICBzb2RpcG9kaTpkb2Nu YW1lPSJmaXJlLnN2ZyIKICAgIHZpZXdCb3g9IjAgMCA0MDAgNTcwIgogICAgdmVyc2lvbj0iMS4x IgogICAgaW5rc2NhcGU6dmVyc2lvbj0iMC40OC40IHI5OTM5IgogID4KICA8ZGVmcwogICAgICBp ZD0iZGVmczMwMjMiCiAgICA+CiAgICA8bGluZWFyR3JhZGllbnQKICAgICAgICBpZD0ibGluZWFy R3JhZGllbnQzMTA5IgogICAgICA+CiAgICAgIDxzdG9wCiAgICAgICAgICBpZD0ic3RvcDMxMTEi CiAgICAgICAgICBzdHlsZT0ic3RvcC1jb2xvcjojZmZmZjAwIgogICAgICAgICAgb2Zmc2V0PSIw IgogICAgICAvPgogICAgICA8c3RvcAogICAgICAgICAgaWQ9InN0b3AzMTEzIgogICAgICAgICAg c3R5bGU9InN0b3AtY29sb3I6I2ZmZmYwMDtzdG9wLW9wYWNpdHk6MCIKICAgICAgICAgIG9mZnNl dD0iMSIKICAgICAgLz4KICAgIDwvbGluZWFyR3JhZGllbnQKICAgID4KICAgIDxsaW5lYXJHcmFk aWVudAogICAgICAgIGlkPSJsaW5lYXJHcmFkaWVudDMxMTUiCiAgICAgICAgeTI9IjIzNi42NSIK ICAgICAgICB4bGluazpocmVmPSIjbGluZWFyR3JhZGllbnQzMTA5IgogICAgICAgIGdyYWRpZW50 VW5pdHM9InVzZXJTcGFjZU9uVXNlIgogICAgICAgIHgyPSIyNDEuNDMiCiAgICAgICAgeTE9IjY5 Ni42NSIKICAgICAgICB4MT0iMzE1LjcxIgogICAgICAgIGlua3NjYXBlOmNvbGxlY3Q9ImFsd2F5 cyIKICAgIC8+CiAgPC9kZWZzCiAgPgogIDxzb2RpcG9kaTpuYW1lZHZpZXcKICAgICAgaWQ9ImJh c2UiCiAgICAgIGJvcmRlcmNvbG9yPSIjNjY2NjY2IgogICAgICBpbmtzY2FwZTpwYWdlc2hhZG93 PSIyIgogICAgICBpbmtzY2FwZTp3aW5kb3cteT0iLTgiCiAgICAgIHBhZ2Vjb2xvcj0iI2ZmZmZm ZiIKICAgICAgaW5rc2NhcGU6d2luZG93LWhlaWdodD0iODM3IgogICAgICBpbmtzY2FwZTp3aW5k b3ctbWF4aW1pemVkPSIxIgogICAgICBpbmtzY2FwZTp6b29tPSIwLjciCiAgICAgIGlua3NjYXBl OndpbmRvdy14PSItOCIKICAgICAgc2hvd2dyaWQ9ImZhbHNlIgogICAgICBib3JkZXJvcGFjaXR5 PSIxLjAiCiAgICAgIGlua3NjYXBlOmN1cnJlbnQtbGF5ZXI9ImxheWVyMSIKICAgICAgaW5rc2Nh cGU6Y3g9IjUxNS45MTIxOCIKICAgICAgaW5rc2NhcGU6Y3k9IjEzNC41NjU2MSIKICAgICAgaW5r c2NhcGU6d2luZG93LXdpZHRoPSIxNjAwIgogICAgICBpbmtzY2FwZTpwYWdlb3BhY2l0eT0iMC4w IgogICAgICBpbmtzY2FwZTpkb2N1bWVudC11bml0cz0icHgiCiAgLz4KICA8ZwogICAgICBpZD0i bGF5ZXIxIgogICAgICBpbmtzY2FwZTpsYWJlbD0iQ2FscXVlIDEiCiAgICAgIGlua3NjYXBlOmdy b3VwbW9kZT0ibGF5ZXIiCiAgICAgIHRyYW5zZm9ybT0idHJhbnNsYXRlKDAgLTQ4Mi4zNikiCiAg ICA+CiAgICA8ZwogICAgICAgIGlkPSJnMzAxNSIKICAgICAgPgogICAgICA8ZwogICAgICAgICAg aWQ9ImczMDg3IgogICAgICAgICAgdHJhbnNmb3JtPSJtYXRyaXgoLjkzMjUyIDAgMCAuOTMyNTIg LTgxLjA5MyAzNzQuNjYpIgogICAgICAgID4KICAgICAgICA8ZwogICAgICAgICAgICBpZD0iZzMw MzkiCiAgICAgICAgICAgIHN0eWxlPSJmaWxsOiNmZjAwMDAiCiAgICAgICAgICA+CiAgICAgICAg ICA8cGF0aAogICAgICAgICAgICAgIGlkPSJwYXRoMzAyOSIKICAgICAgICAgICAgICBkPSJtMTI4 LjU3IDM3OC4wOGMtMTEuNTEgMTMwLjcgNTEuNzYgMzUzLjg1IDE4Mi44NiAzNDguNTcgMTExLjcx LTQuNSAxOTcuNDQtMjE4LjM1IDEzMS40My0zMDguNTctODMuNDMtMTE0LjAyLTE2Ny4yOS0xNzgu OS0xNjUuNzItMjY0LjI5IDEuMDEtNTQuNDExLTU2LjA0IDY1Ljc3LTQyLjg1IDExOC41NyA3My42 NiAyOTUuMDYtMTAyLjQ0IDY4LjUyLTEwNS43MiAxMDUuNzJ6IgogICAgICAgICAgICAgIHNvZGlw b2RpOm5vZGV0eXBlcz0ic3Nzc3NzIgogICAgICAgICAgICAgIHN0eWxlPSJmaWxsOiNmZjAwMDAi CiAgICAgICAgICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMCIKICAgICAgICAg IC8+CiAgICAgICAgICA8cGF0aAogICAgICAgICAgICAgIGlkPSJwYXRoMzAzMSIKICAgICAgICAg ICAgICBzb2RpcG9kaTpub2RldHlwZXM9InNzc3NzcyIKICAgICAgICAgICAgICBzdHlsZT0iZmls bDojZmYwMDAwIgogICAgICAgICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci1jdXJ2YXR1cmU9IjAi CiAgICAgICAgICAgICAgZD0ibTEyMCAzMDkuNTFjLTEwNC4zNyAxNzcuODQgNjAuMzMgNDIyLjQy IDE5MS40MyA0MTcuMTQgMTExLjcxLTQuNSAxOTcuNDQtMjE4LjM1IDEzMS40My0zMDguNTctODMu NDMtMTE0LjAyLTI3MC4xNS0xMTcuNDctMjY4LjU3LTIwMi44NiAxLjAwNTMtNTQuNDEyLTQyLjA4 MSAxMi42NTEtMzAgNjUuNzE0IDY2LjUyIDI5Mi4yLTUuMzktMy42My0yNC4yOSAyOC41OHoiCiAg ICAgICAgICAvPgogICAgICAgIDwvZwogICAgICAgID4KICAgICAgICA8ZwogICAgICAgICAgICBp ZD0iZzMwNDMiCiAgICAgICAgICAgIHN0eWxlPSJmaWxsOiNmZjAwMDAiCiAgICAgICAgICAgIHRy YW5zZm9ybT0ibWF0cml4KC0xIDAgMCAxIDYwMi44NyAtMjQuMjg2KSIKICAgICAgICAgID4KICAg ICAgICAgIDxwYXRoCiAgICAgICAgICAgICAgaWQ9InBhdGgzMDQ1IgogICAgICAgICAgICAgIHNv ZGlwb2RpOm5vZGV0eXBlcz0ic3Nzc3NzIgogICAgICAgICAgICAgIHN0eWxlPSJmaWxsOiNmZjAw MDAiCiAgICAgICAgICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMCIKICAgICAg ICAgICAgICBkPSJtMTI4LjU3IDM3OC4wOGMtMTEuNTEgMTMwLjcgNTEuNzYgMzUzLjg1IDE4Mi44 NiAzNDguNTcgMTExLjcxLTQuNSAxOTcuNDQtMjE4LjM1IDEzMS40My0zMDguNTctODMuNDMtMTE0 LjAyLTE2Ny4yOS0xNzguOS0xNjUuNzItMjY0LjI5IDEuMDEtNTQuNDExLTU2LjA0IDY1Ljc3LTQy Ljg1IDExOC41NyA3My42NiAyOTUuMDYtMTAyLjQ0IDY4LjUyLTEwNS43MiAxMDUuNzJ6IgogICAg ICAgICAgLz4KICAgICAgICAgIDxwYXRoCiAgICAgICAgICAgICAgaWQ9InBhdGgzMDQ3IgogICAg ICAgICAgICAgIGQ9Im0xMjAgMzA5LjUxYy0xMDQuMzcgMTc3Ljg0IDYwLjMzIDQyMi40MiAxOTEu NDMgNDE3LjE0IDExMS43MS00LjUgMTk3LjQ0LTIxOC4zNSAxMzEuNDMtMzA4LjU3LTgzLjQzLTEx NC4wMi0yNzAuMTUtMTE3LjQ3LTI2OC41Ny0yMDIuODYgMS4wMDUzLTU0LjQxMi00Mi4wODEgMTIu NjUxLTMwIDY1LjcxNCA2Ni41MiAyOTIuMi01LjM5LTMuNjMtMjQuMjkgMjguNTh6IgogICAgICAg ICAgICAgIHNvZGlwb2RpOm5vZGV0eXBlcz0ic3Nzc3NzIgogICAgICAgICAgICAgIHN0eWxlPSJm aWxsOiNmZjAwMDAiCiAgICAgICAgICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0i MCIKICAgICAgICAgIC8+CiAgICAgICAgPC9nCiAgICAgICAgPgogICAgICA8L2cKICAgICAgPgog ICAgICA8ZwogICAgICAgICAgaWQ9ImczMDk1IgogICAgICAgICAgc3R5bGU9ImZpbGw6dXJsKCNs aW5lYXJHcmFkaWVudDMxMTUpIgogICAgICAgICAgdHJhbnNmb3JtPSJtYXRyaXgoLjkzMjUyIDAg MCAuOTMyNTIgLTgxLjA5MyAzNzQuNjYpIgogICAgICAgID4KICAgICAgICA8ZwogICAgICAgICAg ICBpZD0iZzMwOTciCiAgICAgICAgICAgIHN0eWxlPSJmaWxsOnVybCgjbGluZWFyR3JhZGllbnQz MTE1KSIKICAgICAgICAgID4KICAgICAgICAgIDxwYXRoCiAgICAgICAgICAgICAgaWQ9InBhdGgz MDk5IgogICAgICAgICAgICAgIHNvZGlwb2RpOm5vZGV0eXBlcz0ic3Nzc3NzIgogICAgICAgICAg ICAgIHN0eWxlPSJmaWxsOnVybCgjbGluZWFyR3JhZGllbnQzMTE1KSIKICAgICAgICAgICAgICBp bmtzY2FwZTpjb25uZWN0b3ItY3VydmF0dXJlPSIwIgogICAgICAgICAgICAgIGQ9Im0xMjguNTcg Mzc4LjA4Yy0xMS41MSAxMzAuNyA1MS43NiAzNTMuODUgMTgyLjg2IDM0OC41NyAxMTEuNzEtNC41 IDE5Ny40NC0yMTguMzUgMTMxLjQzLTMwOC41Ny04My40My0xMTQuMDItMTY3LjI5LTE3OC45LTE2 NS43Mi0yNjQuMjkgMS4wMS01NC40MTEtNTYuMDQgNjUuNzctNDIuODUgMTE4LjU3IDczLjY2IDI5 NS4wNi0xMDIuNDQgNjguNTItMTA1LjcyIDEwNS43MnoiCiAgICAgICAgICAvPgogICAgICAgICAg PHBhdGgKICAgICAgICAgICAgICBpZD0icGF0aDMxMDEiCiAgICAgICAgICAgICAgZD0ibTEyMCAz MDkuNTFjLTEwNC4zNyAxNzcuODQgNjAuMzMgNDIyLjQyIDE5MS40MyA0MTcuMTQgMTExLjcxLTQu NSAxOTcuNDQtMjE4LjM1IDEzMS40My0zMDguNTctODMuNDMtMTE0LjAyLTI3MC4xNS0xMTcuNDct MjY4LjU3LTIwMi44NiAxLjAwNTMtNTQuNDEyLTQyLjA4MSAxMi42NTEtMzAgNjUuNzE0IDY2LjUy IDI5Mi4yLTUuMzktMy42My0yNC4yOSAyOC41OHoiCiAgICAgICAgICAgICAgc29kaXBvZGk6bm9k ZXR5cGVzPSJzc3Nzc3MiCiAgICAgICAgICAgICAgc3R5bGU9ImZpbGw6dXJsKCNsaW5lYXJHcmFk aWVudDMxMTUpIgogICAgICAgICAgICAgIGlua3NjYXBlOmNvbm5lY3Rvci1jdXJ2YXR1cmU9IjAi CiAgICAgICAgICAvPgogICAgICAgIDwvZwogICAgICAgID4KICAgICAgICA8ZwogICAgICAgICAg ICBpZD0iZzMxMDMiCiAgICAgICAgICAgIHN0eWxlPSJmaWxsOnVybCgjbGluZWFyR3JhZGllbnQz MTE1KSIKICAgICAgICAgICAgdHJhbnNmb3JtPSJtYXRyaXgoLTEgMCAwIDEgNjAyLjg3IC0yNC4y ODYpIgogICAgICAgICAgPgogICAgICAgICAgPHBhdGgKICAgICAgICAgICAgICBpZD0icGF0aDMx MDUiCiAgICAgICAgICAgICAgZD0ibTEyOC41NyAzNzguMDhjLTExLjUxIDEzMC43IDUxLjc2IDM1 My44NSAxODIuODYgMzQ4LjU3IDExMS43MS00LjUgMTk3LjQ0LTIxOC4zNSAxMzEuNDMtMzA4LjU3 LTgzLjQzLTExNC4wMi0xNjcuMjktMTc4LjktMTY1LjcyLTI2NC4yOSAxLjAxLTU0LjQxMS01Ni4w NCA2NS43Ny00Mi44NSAxMTguNTcgNzMuNjYgMjk1LjA2LTEwMi40NCA2OC41Mi0xMDUuNzIgMTA1 LjcyeiIKICAgICAgICAgICAgICBzb2RpcG9kaTpub2RldHlwZXM9InNzc3NzcyIKICAgICAgICAg ICAgICBzdHlsZT0iZmlsbDp1cmwoI2xpbmVhckdyYWRpZW50MzExNSkiCiAgICAgICAgICAgICAg aW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0iMCIKICAgICAgICAgIC8+CiAgICAgICAgICA8 cGF0aAogICAgICAgICAgICAgIGlkPSJwYXRoMzEwNyIKICAgICAgICAgICAgICBzb2RpcG9kaTpu b2RldHlwZXM9InNzc3NzcyIKICAgICAgICAgICAgICBzdHlsZT0iZmlsbDp1cmwoI2xpbmVhckdy YWRpZW50MzExNSkiCiAgICAgICAgICAgICAgaW5rc2NhcGU6Y29ubmVjdG9yLWN1cnZhdHVyZT0i MCIKICAgICAgICAgICAgICBkPSJtMTIwIDMwOS41MWMtMTA0LjM3IDE3Ny44NCA2MC4zMyA0MjIu NDIgMTkxLjQzIDQxNy4xNCAxMTEuNzEtNC41IDE5Ny40NC0yMTguMzUgMTMxLjQzLTMwOC41Ny04 My40My0xMTQuMDItMjcwLjE1LTExNy40Ny0yNjguNTctMjAyLjg2IDEuMDA1My01NC40MTItNDIu MDgxIDEyLjY1MS0zMCA2NS43MTQgNjYuNTIgMjkyLjItNS4zOS0zLjYzLTI0LjI5IDI4LjU4eiIK ICAgICAgICAgIC8+CiAgICAgICAgPC9nCiAgICAgICAgPgogICAgICA8L2cKICAgICAgPgogICAg PC9nCiAgICA+CiAgPC9nCiAgPgogIDxtZXRhZGF0YQogICAgPgogICAgPHJkZjpSREYKICAgICAg PgogICAgICA8Y2M6V29yawogICAgICAgID4KICAgICAgICA8ZGM6Zm9ybWF0CiAgICAgICAgICA+ aW1hZ2Uvc3ZnK3htbDwvZGM6Zm9ybWF0CiAgICAgICAgPgogICAgICAgIDxkYzp0eXBlCiAgICAg ICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0cDovL3B1cmwub3JnL2RjL2RjbWl0eXBlL1N0aWxsSW1h Z2UiCiAgICAgICAgLz4KICAgICAgICA8Y2M6bGljZW5zZQogICAgICAgICAgICByZGY6cmVzb3Vy Y2U9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1vbnMub3JnL2xpY2Vuc2VzL3B1YmxpY2RvbWFpbi8iCiAg ICAgICAgLz4KICAgICAgICA8ZGM6cHVibGlzaGVyCiAgICAgICAgICA+CiAgICAgICAgICA8Y2M6 QWdlbnQKICAgICAgICAgICAgICByZGY6YWJvdXQ9Imh0dHA6Ly9vcGVuY2xpcGFydC5vcmcvIgog ICAgICAgICAgICA+CiAgICAgICAgICAgIDxkYzp0aXRsZQogICAgICAgICAgICAgID5PcGVuY2xp cGFydDwvZGM6dGl0bGUKICAgICAgICAgICAgPgogICAgICAgICAgPC9jYzpBZ2VudAogICAgICAg ICAgPgogICAgICAgIDwvZGM6cHVibGlzaGVyCiAgICAgICAgPgogICAgICA8L2NjOldvcmsKICAg ICAgPgogICAgICA8Y2M6TGljZW5zZQogICAgICAgICAgcmRmOmFib3V0PSJodHRwOi8vY3JlYXRp dmVjb21tb25zLm9yZy9saWNlbnNlcy9wdWJsaWNkb21haW4vIgogICAgICAgID4KICAgICAgICA8 Y2M6cGVybWl0cwogICAgICAgICAgICByZGY6cmVzb3VyY2U9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1v bnMub3JnL25zI1JlcHJvZHVjdGlvbiIKICAgICAgICAvPgogICAgICAgIDxjYzpwZXJtaXRzCiAg ICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjRGlz dHJpYnV0aW9uIgogICAgICAgIC8+CiAgICAgICAgPGNjOnBlcm1pdHMKICAgICAgICAgICAgcmRm OnJlc291cmNlPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9ucyNEZXJpdmF0aXZlV29ya3Mi CiAgICAgICAgLz4KICAgICAgPC9jYzpMaWNlbnNlCiAgICAgID4KICAgIDwvcmRmOlJERgogICAg PgogIDwvbWV0YWRhdGEKICA+Cjwvc3ZnCj4K "
+       id="image8332"
+       x="128.76601"
+       y="183.01529" /><g
+       inkscape:label="Layer 1"
+       id="layer1-3"
+       transform="translate(-330.10256,-27.538486)"><g
+         id="g1550"
+         transform="translate(98.954167,-47.360417)" /><g
+         id="g14832"
+         transform="translate(13.751947)" /><g
+         id="g3552"
+         transform="matrix(0.88230337,0,0,0.88230337,-80.177739,-12.344664)"><g
+           style="stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           transform="matrix(0.33870877,0,0,0.33870877,463.33891,250.8126)"
+           id="usability_audit"><g
+             style="stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+             id="g1023"><path
+               style="fill:#37474f;stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+               inkscape:connector-curvature="0"
+               d="m 17.07,21 h 1.055 l 0.251,1.758 c 0.068,0.546 0.569,0.931 1.114,1.009 l 1.52,0.154 c 0.216,0.031 0.484,0.015 0.764,0.015 0.428,0 0.881,-0.051 1.207,-0.116 l 0.539,-0.115 c 0.539,-0.108 1.09,-0.387 1.223,-0.92 L 25.25,21 c 0,0 0.094,-0.5 0.75,-0.5 0.656,0 0.75,0.5 0.75,0.5 l 0.508,1.78 c 0.133,0.533 0.684,0.933 1.223,1.041 l 0.539,0.045 c 0.326,0.065 0.779,0.069 1.207,0.069 0.279,0 0.549,-0.03 0.764,-0.062 l 1.52,-0.225 c 0.545,-0.078 1.046,-0.342 1.114,-0.888 L 33.875,21 h 1.115 c 0.007,0.475 0.01,0.967 0.01,1.5 0,0 1,-3.188 1,-8 0,-2.916 -0.5,-7 -4,-7 -1.458,-1.708 -3.946,-2 -7,-2 -7.5,0 -9,4.5 -9,9 0,4.971 1,8 1,8 0,-0.557 0.029,-1.041 0.07,-1.5 z m 7.702,-0.651 -0.515,2.061 c -0.087,0.347 -0.486,0.727 -0.836,0.797 l -0.54,0.107 c -0.282,0.057 -0.696,0.091 -1.108,0.091 -0.264,0 -0.51,-0.015 -0.692,-0.041 L 19.56,23.147 c -0.32,-0.046 -0.648,-0.38 -0.688,-0.701 L 18.62,20.43 c -0.034,-0.273 0.167,-0.537 0.44,-0.576 l 1.521,-0.217 c 0.262,-0.038 0.631,-0.06 1.013,-0.06 0.319,0 0.617,0.016 0.836,0.043 l 2.016,0.252 c 0.121,0.015 0.22,0.071 0.279,0.159 0.06,0.087 0.077,0.2 0.047,0.318 z m 8.356,2.096 c -0.04,0.321 -0.369,0.655 -0.688,0.701 l -1.521,0.217 c -0.183,0.026 -0.429,0.041 -0.692,0.041 -0.412,0 -0.826,-0.034 -1.109,-0.091 L 28.58,23.206 c -0.352,-0.07 -0.75,-0.45 -0.836,-0.797 l -0.516,-2.061 c -0.029,-0.117 -0.013,-0.23 0.048,-0.317 0.06,-0.088 0.159,-0.145 0.279,-0.159 l 2.016,-0.252 c 0.22,-0.027 0.517,-0.043 0.836,-0.043 0.382,0 0.751,0.021 1.014,0.06 l 1.519,0.217 c 0.273,0.039 0.476,0.303 0.441,0.576 z M 33.798,20 C 33.667,19.672 33.381,19.411 33.01,19.358 l -1.52,-0.217 c -0.296,-0.042 -0.694,-0.064 -1.084,-0.064 -0.328,0 -0.649,0.016 -0.898,0.047 l -2.016,0.252 C 27.117,19.423 26.853,19.677 26.761,20 H 25.24 c -0.093,-0.323 -0.356,-0.577 -0.731,-0.624 l -2.016,-0.252 c -0.25,-0.031 -0.57,-0.047 -0.898,-0.047 -0.39,0 -0.787,0.022 -1.084,0.064 l -1.52,0.217 C 18.62,19.411 18.334,19.671 18.202,20 H 17.19 c 0.222,-1.455 0.588,-2.648 0.811,-4.5 0.115,-0.951 0.209,-1.269 0.486,-1.269 0.555,0 1.848,1.269 5.514,1.269 4.36,0 6.676,-2.635 8.072,-2.635 0.365,0 0.668,0.181 0.928,0.635 1.475,2.58 1.859,4.35 1.961,6.5 z M 25,6.5 c 2.9,0 5.071,0.28 6.239,1.649 l 0.3,0.351 H 32 c 0.742,0 3,0 3,6 0,0.264 -0.003,0.523 -0.009,0.777 -0.286,-0.703 -0.652,-1.45 -1.123,-2.273 -0.538,-0.941 -1.273,-1.139 -1.796,-1.139 -0.762,0 -1.489,0.4 -2.41,0.908 -1.396,0.77 -3.135,1.727 -5.662,1.727 -2.418,0 -3.668,-0.584 -4.414,-0.932 -0.404,-0.188 -0.723,-0.337 -1.1,-0.337 v 0 c -1.207,0 -1.373,1.267 -1.477,2.123 C 17.004,15.076 17,14.792 17,14.5 c 0,-5.533 2.467,-8 8,-8 z"
+               id="path1011" /><path
+               style="fill:#37474f;stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+               inkscape:connector-curvature="0"
+               d="m 34.53,26.873 c 0.237,-0.796 0.397,-1.597 0.442,-2.379 0.01,0.001 0.018,0.006 0.028,0.006 0.55,0 1,-0.45 1,-1 v -1 c 0,0.55 -0.45,1.5 -1,1.5 -10e-4,0 -0.329,0 -0.885,0 -0.077,0.134 -0.132,0.279 -0.141,0.437 -0.059,1.009 -0.306,2.028 -0.681,3.009 0.399,-0.216 0.813,-0.403 1.237,-0.573 z"
+               id="path1013" /><path
+               style="fill:#37474f;stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+               inkscape:connector-curvature="0"
+               d="M 46.493,40.959 C 46.221,39.325 44.682,37.736 43.058,37.412 L 38.5,36.5 V 36 L 32,34 v -1.645 c -0.384,0.476 -0.718,0.992 -1,1.54 v 2.823 c -0.154,0.226 -0.474,0.623 -0.987,1.024 C 30.011,37.829 30,37.913 30,38 c 0,0.313 0.017,0.624 0.048,0.93 0.237,-0.146 0.456,-0.298 0.646,-0.45 l -0.453,1.554 c 0.134,0.575 0.321,1.128 0.559,1.655 l 1.877,-6.435 4.824,1.484 v 1.585 l -1.871,0.748 -1.408,0.563 1.072,1.072 1.362,1.362 -2.729,3.358 c 0.277,0.189 0.565,0.363 0.864,0.521 L 38,42 36,40 38.5,39 v -1.48 l 4.363,0.873 c 1.205,0.241 2.441,1.517 2.644,2.73 l 0.253,1.521 c 0.05,0.297 0.084,0.713 0.104,1.164 0.333,-0.393 0.629,-0.816 0.892,-1.263 -0.004,-0.021 -0.006,-0.047 -0.009,-0.066 -0.141,-0.839 -0.254,-1.52 -0.254,-1.52 z"
+               id="path1015" /><path
+               style="fill:#37474f;stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+               inkscape:connector-curvature="0"
+               d="m 39,50 c -0.147,0 -0.291,-0.017 -0.438,-0.022 L 26,57.821 25.433,57.467 32.879,48.303 c -0.289,-0.172 -0.57,-0.354 -0.843,-0.549 l -4.689,5.772 2.329,-7.987 C 29.41,45.211 29.165,44.866 28.935,44.511 L 25.988,54.616 21.3,38.472 c 0.94,0.759 2.448,1.528 4.701,1.528 0.417,0 0.8,-0.033 1.167,-0.081 C 27.115,39.593 27.072,39.264 27.047,38.93 26.721,38.973 26.375,39 26.001,39 22.819,39 21.388,37.288 21,36.72 v -4.07 c 1.488,1.42 3.24,2.35 5,2.35 0.485,0 0.97,-0.077 1.449,-0.209 0.113,-0.408 0.245,-0.808 0.399,-1.197 C 27.232,33.85 26.609,34 26,34 22.393,34 18.293,29.084 18.025,24.437 18.016,24.28 17.962,24.134 17.884,24 c -0.555,0 -0.883,0 -0.885,0 -0.55,0 -1,-0.95 -1,-1.5 v 1 c 0,0.55 0.45,1 1,1 0.01,0 0.018,-0.005 0.027,-0.006 0.141,2.44 1.302,5.074 2.973,7.094 V 34 l -6.5,2 v 0.501 L 8.94,37.412 C 7.315,37.736 5.778,39.325 5.505,40.959 L 5.252,42.48 c -0.141,0.84 -0.18,2.413 -0.088,3.514 L 26,59 40.609,49.879 C 40.081,49.95 39.547,50 39,50 Z m -24.5,-13.262 4.823,-1.483 5.251,18.081 -9.227,-11.269 1.359,-1.36 1.072,-1.072 -1.408,-0.563 -1.87,-0.749 z m -8.367,8.679 c -0.042,-0.959 0,-2.132 0.107,-2.773 L 6.493,41.123 C 6.699,39.888 7.91,38.638 9.138,38.393 L 13.5,37.52 V 39 l 2.5,1 -2,2 11.552,14.108 -0.354,1.212 z"
+               id="path1017" /><g
+               style="stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+               id="g1021"><path
+                 style="fill:#37474f;stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+                 inkscape:connector-curvature="0"
+                 d="M 58.293,54.293 49.707,45.707 C 49.513,45.513 49.256,45.416 49,45.416 c -0.159,0 -0.313,0.051 -0.458,0.126 L 47.706,44.706 C 49.139,42.849 50,40.527 50,38 50,31.925 45.075,27 39,27 c -6.075,0 -11,4.925 -11,11 0,6.075 4.925,11 11,11 2.527,0 4.849,-0.861 6.706,-2.294 l 0.836,0.836 c -0.196,0.377 -0.15,0.85 0.165,1.165 l 8.586,8.586 c 0.194,0.194 0.451,0.291 0.707,0.291 0.256,0 0.513,-0.097 0.707,-0.291 l 1.586,-1.586 c 0.389,-0.389 0.389,-1.025 0,-1.414 z M 29,38 c 0,-5.522 4.478,-10 10,-10 5.522,0 10,4.478 10,10 0,5.522 -4.478,10 -10,10 -5.522,0 -10,-4.478 -10,-10 z m 18.058,7.472 0.735,0.735 -0.586,0.586 -0.735,-0.735 c 0.202,-0.189 0.397,-0.384 0.586,-0.586 z M 56,56.586 47.414,48 48.997,46.416 c 0,0 10e-4,0 0.003,0 V 46.414 L 57.586,55 Z"
+                 id="path1019" /></g></g></g><g
+           style="stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           transform="matrix(0.33870877,0,0,0.33870877,670.95174,237.77416)"
+           id="g13558" /></g><g
+         id="g11162"
+         transform="matrix(0.94340175,0,0,0.94340175,-37.863885,-75.865437)"><g
+           style="fill:none;fill-rule:evenodd;stroke:none;stroke-width:1"
+           transform="matrix(0.0287436,0,0,0.0287436,445.38126,305.634)"
+           id="tor-browser-icon-4"><g
+             id="icon_512x512-5"><g
+               id="Group-0"><g
+                 id="tb_icon/Stable-3"><g
+                   id="Stable-6"><circle
+                     style="fill:#f2e4ff;fill-rule:nonzero"
+                     id="background-1"
+                     cx="256"
+                     cy="256"
+                     r="246" /><path
+                     style="fill:url(#linearGradient13221)"
+                     inkscape:connector-curvature="0"
+                     d="m 256.52514,465.43971 v -31.0331 C 354.82619,434.12275 434.4208,354.36492 434.4208,255.9929 434.4208,157.62799 354.82619,77.870156 256.52514,77.586295 V 46.553196 C 371.9643,46.844154 465.4468,140.48988 465.4468,255.9929 c 0,115.51012 -93.4825,209.16295 -208.92166,209.44681 z m 0,-108.6194 c 55.44514,-0.29095 100.32356,-45.3042 100.32356,-100.82741 0,-55.5161 -44.87842,-100.52935 -100.32356,-100.82031 v -31.026 c 72.59034,0.28386 131.35666,59.1921 131.35666,131.84631 0,72.66131 -58.76632,131.56955 -131.35666,131.85342 z m 0,-155.10162 c 29.74153,0.28386 53.77746,24.46172 53.77746,54.27421 0,29.8196 -24.03593,53.99745 -53.77746,54.28131 z M 0,255.9929 C 0,397.38404 114.60886,512 256,512 397.38404,512 512,397.38404 512,255.9929 512,114.60886 397.38404,0 256,0 114.60886,0 0,114.60886 0,255.9929 Z"
+                     id="center-0" /><g
+                     id="half-6"
+                     transform="matrix(-1,0,0,1,281,0)"><use
+                       height="100%"
+                       width="100%"
+                       y="0"
+                       x="0"
+                       style="fill:#000000;fill-opacity:1;filter:url(#filter-3-0-1)"
+                       xlink:href="#path-2"
+                       id="use1133-3" /><use
+                       height="100%"
+                       width="100%"
+                       y="0"
+                       x="0"
+                       style="fill:url(#linearGradient1169-8);fill-rule:evenodd"
+                       xlink:href="#path-2"
+                       id="use1135-2" /></g></g></g></g></g></g></g><text
+         xml:space="preserve"
+         style="font-size:8.46667px;line-height:1;font-family:sans-serif;stroke-width:0.264583"
+         x="259.63907"
+         y="189.25381"
+         id="text12625"
+         transform="rotate(-15.894008)"><tspan
+           sodipodi:role="line"
+           style="font-size:8.46667px;text-align:center;text-anchor:middle;stroke-width:0.264583"
+           x="259.63907"
+           y="189.25381"
+           id="tspan15099" /></text><g
+         id="g16793"
+         transform="matrix(0.24306403,0,0,0.24306403,478.10713,223.36638)">
+	<g
+   id="g16787"
+   transform="translate(4.1745506,2.6979589)">
+		<g
+   id="layer3_22_"
+   transform="matrix(0.82741166,0,0,0.82741166,-408.55399,-118.47453)">
+			<g
+   id="layer5_22_">
+				<g
+   id="path2554_38_">
+					<path
+   fill="#68b044"
+   d="m 176.9,70.8 -2.4,9.6 c 3.4,-6.8 8.9,-11.9 15.2,-16.4 -4.6,5.3 -8.8,10.6 -11.3,16 4.3,-6.1 10.1,-9.4 16.6,-11.7 -8.7,7.7 -15.6,16.1 -20.8,24.4 L 170,90.9 c 0.7,-6.7 3.2,-13.5 6.9,-20.1 z"
+   id="path16754" />
+				</g>
+				<g
+   id="path2534_13_">
+					<path
+   fill="#f5f8de"
+   d="m 165.8,89.1 7.9,3.3 c 0,2 -0.2,8.2 1.1,10 13.2,17 11,51.2 -2.7,52 -20.8,0 -28.8,-14.1 -28.8,-27.1 0,-11.9 14.2,-19.7 22.7,-26.7 2.3,-1.9 1.9,-6.1 -0.2,-11.5 z"
+   id="path16757" />
+				</g>
+				<g
+   id="path2536_23_">
+					<path
+   fill="#7e4798"
+   d="m 173.7,92.3 2.9,1.5 c -0.3,1.9 0.1,6.1 2,7.1 8.4,5.2 16.2,10.8 19.3,16.5 11,19.9 -7.7,38.4 -24,36.6 8.8,-6.5 11.4,-19.9 8.1,-34.6 -1.3,-5.7 -3.4,-10.9 -7.1,-16.8 -1.6,-2.7 -1,-6.3 -1.2,-10.3 z"
+   id="path16760" />
+				</g>
+			</g>
+			<g
+   id="layer4_22_">
+				<g
+   id="path2540_23_">
+					<path
+   fill="#010101"
+   d="m 170.5,101.8 c -0.6,3.1 -1.3,8.7 -4,10.8 -1.1,0.8 -2.3,1.6 -3.5,2.4 -4.9,3.3 -9.7,6.4 -11.9,14.3 -0.5,1.7 -0.1,3.5 0.3,5.2 1.2,4.9 4.6,10.1 7.3,13.2 0,0.1 0.5,0.5 0.5,0.6 2.2,2.6 2.9,3.4 11.3,5.3 l -0.2,0.9 c -5.1,-1.3 -9.2,-2.6 -11.9,-5.6 0,-0.1 -0.5,-0.5 -0.5,-0.5 -2.8,-3.2 -6.3,-8.6 -7.5,-13.7 -0.5,-2 -0.9,-3.6 -0.3,-5.7 2.3,-8.2 7.3,-11.5 12.3,-14.9 1.1,-0.7 2.5,-1.4 3.6,-2.3 2.3,-1.5 3.4,-6.2 4.5,-10 z"
+   id="path16764" />
+				</g>
+				<g
+   id="path2542_23_">
+					<path
+   fill="#010101"
+   d="m 172.7,114.8 c 0.1,3.5 -0.3,5.3 0.6,7.8 0.5,1.5 2.4,3.5 2.9,5.5 0.7,2.6 1.5,5.5 1.5,7.3 0,2 -0.1,5.8 -1,9.8 -0.7,3.3 -2.2,6.2 -4.8,7.8 -2.7,-0.5 -5.8,-1.5 -7.6,-3.1 -3.6,-3.1 -6.7,-8.3 -7.1,-12.8 -0.3,-3.7 3.1,-9.2 7.9,-11.9 4,-2.4 5,-5 5.9,-9.4 -1.2,3.8 -2.4,6.9 -6.3,9 -5.7,3 -8.6,7.9 -8.3,12.7 0.4,6.1 2.8,10.2 7.6,13.5 2,1.4 5.8,2.9 8.2,3.3 V 154 c 1.8,-0.3 4.1,-3.3 5.3,-7.2 1,-3.6 1.4,-8.1 1.3,-11 -0.1,-1.7 -0.8,-5.3 -2.2,-8.6 -0.7,-1.8 -1.9,-3.6 -2.6,-4.9 -0.9,-1.5 -0.9,-4.3 -1.3,-7.5 z"
+   id="path16767" />
+				</g>
+				<g
+   id="path2544_23_">
+					<path
+   fill="#010101"
+   d="m 172.1,128.5 c 0.1,2.4 1,5.4 1.4,8.5 0.3,2.3 0.2,4.6 0.1,6.6 -0.1,2.3 -0.8,6.5 -1.9,8.6 -1,-0.5 -1.4,-1 -2.1,-1.8 -0.8,-1.1 -1.4,-2.3 -1.9,-3.6 -0.4,-1 -0.9,-2.2 -1.1,-3.5 -0.3,-2 -0.2,-5.2 2.1,-8.4 1.8,-2.6 2.2,-2.8 2.8,-5.7 -0.8,2.6 -1.4,2.9 -3.3,5.1 -2.1,2.4 -2.4,6 -2.4,8.9 0,1.2 0.5,2.6 1,3.8 0.5,1.3 1,2.7 1.7,3.7 1.1,1.6 2.5,2.6 3.2,2.7 0,0 0,0 0,0 0,0 0,0 0,0 v -0.1 c 1.3,-1.5 2.1,-2.9 2.4,-4.4 0.3,-1.8 0.4,-3.5 0.6,-5.6 0.2,-1.8 0.1,-4.1 -0.4,-6.5 -0.6,-3 -1.7,-6.1 -2.2,-8.3 z"
+   id="path16770" />
+				</g>
+				<g
+   id="path2550_23_">
+					<path
+   fill="#010101"
+   d="m 172.5,99 c 0.1,3.5 0.3,10 1.3,12.6 0.3,0.9 2.8,4.7 4.5,9.4 1.2,3.2 1.5,6.2 1.7,7.1 0.8,3.8 -0.2,10.3 -1.5,16.4 -0.7,3.3 -3,7.4 -5.6,9 l -0.5,0.9 c 1.5,-0.1 5.1,-3.6 6.4,-8.1 2.2,-7.5 3,-11 2,-19.4 -0.1,-0.8 -0.5,-3.6 -1.8,-6.5 -1.9,-4.5 -4.6,-8.8 -4.9,-9.7 -0.7,-1.4 -1.5,-7.6 -1.6,-11.7 z"
+   id="path16773" />
+				</g>
+				<g
+   id="path2552_23_">
+					<path
+   fill="#010101"
+   d="m 173.7,92.6 c -0.2,3.6 -0.2,6.4 0.4,9.1 0.7,2.9 4.5,7.1 6.1,11.9 3,9.2 2.2,21.2 0.1,30.5 -0.8,3.3 -4.6,8.1 -8.5,9.6 l 2.8,0.7 c 1.5,-0.1 5.5,-3.8 7.1,-8 2.5,-6.7 3,-14.6 2,-23 -0.1,-0.8 -1.4,-8 -2.7,-11 -1.8,-4.5 -4.7,-7.7 -5.7,-10.5 -0.8,-2.1 -1.1,-7.7 -0.6,-8.8 z"
+   id="path16776" />
+				</g>
+			</g>
+		</g>
+		
+		
+	</g>
+	<g
+   id="g16791"
+   transform="matrix(0.82741166,0,0,0.82741166,-328.25756,-62.822408)">
+		<path
+   fill="#010101"
+   d="m 101.7,46.3 c -2.9,-2.6 -6.5,-4.8 -10.3,-6.9 -1.7,-0.9 -6.9,-5 -5.1,-10.8 l -13.1,-5.4 -0.9,0.7 c 4.4,7.9 2.1,12.1 -0.1,13.5 -4.4,3 -10.8,6.8 -13.9,10.1 -6.1,6.3 -7.9,12.3 -7.3,20.1 0.6,10.1 7.9,18.5 17.8,21.8 4.3,1.4 8.3,1.6 12.7,1.6 7.1,0 14.5,-1.9 19.8,-6.3 5.7,-4.7 9,-11.8 9,-19.1 0,-7.3 -3.1,-14.3 -8.6,-19.3 z M 99.8,83.2 C 94.9,87.2 86.1,90 81.4,89.8 76.2,89.5 71.1,88.7 66.6,86.5 58.7,82.7 53.5,74.4 53.1,67.7 52.4,54 59,50.1 65.1,45.1 c 3.4,-2.8 8.2,-4.2 10.9,-9.2 0.5,-1.1 0.8,-3.5 0.2,-6 -0.3,-0.9 -1.5,-3.9 -2,-4.6 l 9.8,4.3 c -1.2,4.5 2.5,9.2 5.5,10.9 3,1.7 7.7,4.9 10.6,7.5 5.1,4.5 7.7,10.9 7.7,17.6 0,6.7 -2.8,13.3 -8,17.6 z"
+   id="path16789" />
+	</g>
+</g></g><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="-0.47907329"
+       y="203.52637"
+       id="text18809"><tspan
+         sodipodi:role="line"
+         id="tspan18807"
+         style="stroke-width:0.264583"
+         x="-0.47907329"
+         y="203.52637">Paper I</tspan></text><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="24.520927"
+       y="203.52637"
+       id="text18813"><tspan
+         sodipodi:role="line"
+         id="tspan18811"
+         style="stroke-width:0.264583"
+         x="24.520927"
+         y="203.52637">Paper II</tspan></text><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="49.520927"
+       y="203.52637"
+       id="text18813-0"><tspan
+         sodipodi:role="line"
+         id="tspan18811-6"
+         style="stroke-width:0.264583"
+         x="49.520927"
+         y="203.52637">Paper III</tspan></text><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="74.520927"
+       y="203.52637"
+       id="text18813-1"><tspan
+         sodipodi:role="line"
+         id="tspan18811-5"
+         style="stroke-width:0.264583"
+         x="74.520927"
+         y="203.52637">Paper IV</tspan></text><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="99.520927"
+       y="203.52637"
+       id="text18813-1-5"><tspan
+         sodipodi:role="line"
+         id="tspan18811-5-4"
+         style="stroke-width:0.264583"
+         x="99.520927"
+         y="203.52637">Paper V</tspan></text><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="124.52093"
+       y="203.52637"
+       id="text18813-1-7"><tspan
+         sodipodi:role="line"
+         id="tspan18811-5-6"
+         style="stroke-width:0.264583"
+         x="124.52093"
+         y="203.52637">Paper VI</tspan></text><rect
+       style="opacity:0.709338;fill:#f2f2f2;stroke:#cecece;stroke-width:0.304508;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
+       id="rect29238"
+       width="14.317735"
+       height="14.317735"
+       x="1.5134155"
+       y="155.84253"
+       ry="4.9276371" /><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="5.9120836"
+       y="164.71849"
+       id="text29242"><tspan
+         sodipodi:role="line"
+         id="tspan29240"
+         style="stroke-width:0.264583"
+         x="5.9120836"
+         y="164.71849">C1</tspan></text><rect
+       style="opacity:0.709338;fill:#f2f2f2;stroke:#cecece;stroke-width:0.304508;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
+       id="rect29238-0"
+       width="14.317735"
+       height="14.317735"
+       x="26.578011"
+       y="155.84253"
+       ry="4.9276371" /><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="30.976679"
+       y="164.71849"
+       id="text29242-7"><tspan
+         sodipodi:role="line"
+         id="tspan29240-8"
+         style="stroke-width:0.264583"
+         x="30.976679"
+         y="164.71849">C2</tspan></text><rect
+       style="opacity:0.709338;fill:#f2f2f2;stroke:#cecece;stroke-width:0.304508;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
+       id="rect29238-0-6"
+       width="14.317735"
+       height="14.317735"
+       x="52.120319"
+       y="155.84253"
+       ry="4.9276371" /><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="56.518986"
+       y="164.71849"
+       id="text29242-7-8"><tspan
+         sodipodi:role="line"
+         id="tspan29240-8-8"
+         style="stroke-width:0.264583"
+         x="56.518986"
+         y="164.71849">C3</tspan></text><rect
+       style="opacity:0.709338;fill:#f2f2f2;stroke:#cecece;stroke-width:0.304508;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
+       id="rect29238-0-6-4"
+       width="14.317735"
+       height="14.317735"
+       x="77.497009"
+       y="155.84253"
+       ry="4.9276371" /><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="81.895668"
+       y="164.71849"
+       id="text29242-7-8-3"><tspan
+         sodipodi:role="line"
+         id="tspan29240-8-8-1"
+         style="stroke-width:0.264583"
+         x="81.895668"
+         y="164.71849">C4</tspan></text><rect
+       style="opacity:0.709338;fill:#f2f2f2;stroke:#cecece;stroke-width:0.304508;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
+       id="rect29238-0-6-4-4"
+       width="14.317735"
+       height="14.317735"
+       x="101.58947"
+       y="155.84253"
+       ry="4.9276371" /><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="105.98813"
+       y="164.71849"
+       id="text29242-7-8-3-9"><tspan
+         sodipodi:role="line"
+         id="tspan29240-8-8-1-2"
+         style="stroke-width:0.264583"
+         x="105.98813"
+         y="164.71849">C5</tspan></text><rect
+       style="opacity:0.709338;fill:#f2f2f2;stroke:#cecece;stroke-width:0.304508;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
+       id="rect29238-0-6-4-4-0"
+       width="14.317735"
+       height="14.317735"
+       x="127.04912"
+       y="155.84253"
+       ry="4.9276371" /><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="131.44778"
+       y="164.71849"
+       id="text29242-7-8-3-9-6"><tspan
+         sodipodi:role="line"
+         style="stroke-width:0.264583"
+         x="131.44778"
+         y="164.71849"
+         id="tspan29489">C6</tspan></text><rect
+       style="opacity:0.709338;fill:#f2f2f2;stroke:#cecece;stroke-width:0.304508;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
+       id="rect29238-4"
+       width="14.317735"
+       height="14.317735"
+       x="26.577738"
+       y="128.55922"
+       ry="4.9276371" /><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="29.241245"
+       y="137.50711"
+       id="text29242-4"><tspan
+         sodipodi:role="line"
+         id="tspan29240-3"
+         style="stroke-width:0.264583"
+         x="29.241245"
+         y="137.50711">RQ1</tspan></text><rect
+       style="opacity:0.709338;fill:#f2f2f2;stroke:#cecece;stroke-width:0.304508;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
+       id="rect29238-4-9"
+       width="14.317735"
+       height="14.317735"
+       x="64.808739"
+       y="128.55905"
+       ry="4.9276371" /><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="67.472244"
+       y="137.50694"
+       id="text29242-4-2"><tspan
+         sodipodi:role="line"
+         id="tspan29240-3-6"
+         style="stroke-width:0.264583"
+         x="67.472244"
+         y="137.50694">RQ2</tspan></text><rect
+       style="opacity:0.709338;fill:#f2f2f2;stroke:#cecece;stroke-width:0.304508;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:5;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
+       id="rect29238-4-6"
+       width="14.317735"
+       height="14.317735"
+       x="101.58961"
+       y="128.44623"
+       ry="4.9276371" /><text
+       xml:space="preserve"
+       style="font-size:4.9389px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="104.25314"
+       y="137.39412"
+       id="text29242-4-4"><tspan
+         sodipodi:role="line"
+         id="tspan29240-3-9"
+         style="stroke-width:0.264583"
+         x="104.25314"
+         y="137.39412">RQ3</tspan></text><text
+       xml:space="preserve"
+       transform="matrix(0.26458333,0,0,0.26458333,-0.50051694,58.312521)"
+       id="text29493"
+       style="font-size:18.6667px;line-height:1.25;font-family:sans-serif;white-space:pre;shape-inside:url(#rect29495);display:inline" /><path
+       style="fill:none;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188)"
+       d="m 16.23903,154.02447 9.863992,-8.80754"
+       id="path39140" /><path
+       style="fill:none;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-7)"
+       d="m 91.224756,153.90972 9.863994,-8.80754"
+       id="path39140-1" /><path
+       style="fill:none;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-7-9)"
+       d="m 127.22954,154.64554 -9.66188,-9.0288"
+       id="path39140-1-9" /><path
+       style="fill:none;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188)"
+       d="m 33.811786,154.02686 v -8.16631"
+       id="path39142" /><path
+       style="fill:none;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-59)"
+       d="m 108.68712,154.02686 v -8.16631"
+       id="path39142-7" /><path
+       style="fill:none;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188)"
+       d="m 50.924817,154.15837 -9.587346,-8.69055"
+       id="path39144" /><path
+       style="fill:none;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188)"
+       d="m 42.802096,154.98884 4.889661,-2.61969 c 0.03188,-1.30845 0.945017,-1.20933 1.37853,-0.73542 l 11.957634,-6.43979"
+       id="path41117"
+       sodipodi:nodetypes="cccc" /><path
+       style="fill:none;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188)"
+       d="m 63.679932,154.09837 3.699658,-8.59051"
+       id="path41119" /><path
+       style="fill:none;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188)"
+       d="m 80.339003,154.05076 -3.908806,-8.55073"
+       id="path41121"
+       sodipodi:nodetypes="cc" /><path
+       style="fill:#010101;fill-opacity:1;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188)"
+       d="m 8.0155716,180.52462 v -7.62507"
+       id="path47583" /><path
+       style="fill:#999999;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-5)"
+       d="m 33.760743,180.52462 v -7.62507"
+       id="path47583-4" /><path
+       style="fill:#999999;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-5-7)"
+       d="m 59.166846,180.52462 v -7.62507"
+       id="path47583-4-7" /><path
+       style="fill:#999999;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-5-7-1)"
+       d="m 84.612049,180.52462 v -7.62507"
+       id="path47583-4-7-6" /><path
+       style="fill:#999999;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-5-7-1-1)"
+       d="m 108.84721,180.52462 v -7.62507"
+       id="path47583-4-7-6-9" /><path
+       style="fill:#999999;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-5-7-1-1-4)"
+       d="m 134.48224,180.52462 v -7.62507"
+       id="path47583-4-7-6-9-0" /><path
+       style="fill:#999999;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-5-8)"
+       d="m 51.066238,181.27382 -7.34132,-7.69218"
+       id="path47583-4-1"
+       sodipodi:nodetypes="cc" /><path
+       style="fill:#999999;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-5-8-2)"
+       d="m 76.799214,181.27356 -7.341319,-7.69218"
+       id="path47583-4-1-6"
+       sodipodi:nodetypes="cc" /><path
+       style="fill:#999999;stroke:#000000;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8188-5-8-2-9)"
+       d="m 125.6987,181.27356 -7.34132,-7.69218"
+       id="path47583-4-1-6-7"
+       sodipodi:nodetypes="cc" /><g
+       id="Layer_1-2"
+       data-name="Layer 1"
+       transform="matrix(0.1124465,0,0,0.1124465,95.565758,180.21499)"><path
+         class="cls-4"
+         d="m 118.14,34 c 6.66,1.63 10,4.56 11.85,6.87 0.74,1 0.95,1.43 3.29,5.58 4.13,7.29 5.22,8.85 5.8,10 1.51,3 2.64,9.66 -6.29,24.12 6.23,0.32 9.35,2.41 11.05,4.25 4.19,4.56 1.43,9.53 6.07,21.41 a 44.59,44.59 0 0 0 4.53,8.78 72,72 0 0 0 4.67,5.84 c 5.34,7.47 10.37,14.58 11.53,24.27 0.55,4.56 1.14,9.73 -0.78,15.6 a 21.2,21.2 0 0 1 -7.49,1.44 c -5.63,0 -3.66,-2.36 -7.29,-1.58 -4.15,0.89 -12.57,5.45 -13.43,5.31 -0.58,-0.1 -0.64,-0.33 -0.64,-0.33 a 0.2,0.2 0 0 1 0,-0.11 c 0.78,-4.44 1.59,-19.48 -23.22,-18.24 v 0.05 h -0.5 -0.49 v -0.05 C 92,146 92.78,161.07 93.56,165.52 c 0,0.24 -0.36,0.29 -0.65,0.44 -3.65,1.82 -10,-5 -16.26,-5.28 -3.77,-0.15 -1.68,2.27 -6.32,1.87 a 14.2,14.2 0 0 1 -5.62,-1.76 43.6,43.6 0 0 1 -0.81,-5 50.24,50.24 0 0 1 0.07,-10 c 0.74,-7.94 4.47,-14.35 11.81,-26.84 6.26,-10.64 7.39,-10.6 9.09,-15.85 2.27,-7 1.49,-10.91 4.8,-15.34 3.31,-4.43 8.45,-6.29 12.11,-7.13 -8.51,-13.8 -8.28,-20.52 -6.3,-24.12 0.61,-1.1 1.58,-2.28 3.8,-6 3.44,-5.81 3.8,-7.54 5.3,-9.58 1.94,-2.67 5.68,-5.66 13.56,-6.93 z"
+         id="path1965" /><path
+         class="cls-4"
+         d="m 118.22,34.53 c 0.21,-0.1 0.06,-0.22 -0.55,-0.08 l -0.4,0.32 z"
+         id="path1967" /><path
+         class="cls-4"
+         d="m 114,35 c -0.69,0.33 -1.42,0.81 -0.9,0.87 0.62,-0.44 0.82,-0.42 1.51,-0.89 0.6,-0.19 1.08,-0.2 1,-0.08 a 8.21,8.21 0 0 0 1.27,-0.37 6.62,6.62 0 0 0 -2.88,0.65 c -0.27,0 -0.07,-0.13 0,-0.18 z"
+         id="path1969" /><path
+         class="cls-4"
+         d="m 95.13,82.71 0.37,-0.17 a 1.91,1.91 0 0 0 -0.37,0.17 z"
+         id="path1971" /><path
+         class="cls-4"
+         d="m 77.11,115.8 c 0.15,-0.25 0.19,-0.37 0.18,-0.4 -0.13,0.25 -0.23,0.45 -0.18,0.4 z"
+         id="path1973" /><path
+         class="cls-4"
+         d="m 73.51,121.33 0.21,-0.32 a 1.44,1.44 0 0 0 -0.21,0.32 z"
+         id="path1975" /><path
+         class="cls-4"
+         d="m 95.13,82.71 c -0.32,0.14 -0.64,0.29 -0.95,0.45 -0.02,0.11 0.49,-0.23 0.95,-0.45 z"
+         id="path1977" /><path
+         class="cls-4"
+         d="m 106.84,39.36 a 4,4 0 0 0 0.36,-0.39 l -0.36,0.34 z"
+         id="path1979" /><path
+         class="cls-4"
+         d="m 96.52,72 c 0,-0.1 -0.09,-0.19 -0.13,-0.29 A 1.29,1.29 0 0 0 96.2,71.5 c 0.1,0.16 0.21,0.33 0.32,0.5 z"
+         id="path1981" /><path
+         class="cls-4"
+         d="m 94,59 c -0.06,0.31 0.13,0.45 0.2,0.58 a 1.66,1.66 0 0 1 0,-0.68 c 0,0 -0.14,0.04 -0.2,0.1 z"
+         id="path1983" /><path
+         class="cls-4"
+         d="m 104.29,40.94 c 0.06,-0.11 0.13,-0.21 0.2,-0.32 z"
+         id="path1985" /><path
+         class="cls-4"
+         d="m 100.67,79.94 c 0,0 -0.06,0 -0.07,0 a 0.07,0.07 0 0 0 0.07,0 z"
+         id="path1987" /><path
+         class="cls-4"
+         d="m 129.82,42.39 c 0,0 0,0 0,0 0,0 -0.05,-0.08 0,0 z"
+         id="path1989" /><path
+         class="cls-4"
+         d="m 118.15,34 h 0.21 a 0.3,0.3 0 0 0 0.07,-0.1 z"
+         id="path1991" /><path
+         class="cls-4"
+         d="m 67.39,131.78 v -0.05 c 0.15,-0.29 0.07,-0.13 0,0.05 z"
+         id="path1993" /><path
+         class="cls-4"
+         d="m 131.3,149.68 c -0.55,-0.27 -0.06,-0.18 0.37,-0.11 0.43,0.07 0.75,0.16 -0.07,-0.27 0.12,0.13 -1.7,-0.18 -0.3,0.38 z"
+         id="path1995" /><path
+         class="cls-4"
+         d="m 106.59,39.57 -0.37,0.35 c 0.17,-0.16 0.29,-0.26 0.37,-0.35 z"
+         id="path1997" /><path
+         class="cls-4"
+         d="m 131.6,149.3 v 0 l -0.18,-0.08 z"
+         id="path1999" /><path
+         class="cls-4"
+         d="m 63.5,159.35 a 1.82,1.82 0 0 0 0,-0.3 c 0,0 0,0.08 0,0.3 z"
+         id="path2001" /><path
+         class="cls-4"
+         d="m 64.94,138.54 -0.19,0.49 c 0.08,-0.19 0.14,-0.35 0.19,-0.49 z"
+         id="path2003" /><path
+         class="cls-4"
+         d="m 73.75,162.57 a 2.81,2.81 0 0 0 0.65,-0.56 0.21,0.21 0 0 0 -0.1,0.06 1.85,1.85 0 0 1 -0.55,0.5 z"
+         id="path2005" /><path
+         class="cls-4"
+         d="m 83.42,163.54 -0.16,-0.13 -0.32,-0.14 z"
+         id="path2007" /><path
+         class="cls-4"
+         d="m 136.17,72.56 a 2.37,2.37 0 0 1 0.38,-0.39 c -0.2,0.1 0.45,-1.4 -0.38,0.39 z"
+         id="path2009" /><path
+         class="cls-4"
+         d="m 106.76,39.28 a 0.56,0.56 0 0 1 -0.17,0.29 l 0.25,-0.26 c 0,0 -0.01,-0.07 -0.08,-0.03 z"
+         id="path2011" /><path
+         class="cls-4"
+         d="m 73,161 a 7.46,7.46 0 0 1 0.76,-0.68 3.27,3.27 0 0 1 1.16,-0.53 3.5,3.5 0 0 0 -1.1,0.47 A 6.67,6.67 0 0 0 73,161 Z"
+         id="path2013" /><path
+         class="cls-4"
+         d="m 168,137.91 -0.16,-0.37 a 1.28,1.28 0 0 0 0.16,0.37 z"
+         id="path2015" /><path
+         class="cls-4"
+         d="m 80.71,160.5 a 8.29,8.29 0 0 0 0.93,0.52 0.88,0.88 0 0 0 0.21,0 c -0.37,-0.16 -0.76,-0.33 -1.14,-0.52 z"
+         id="path2017" /><path
+         class="cls-4"
+         d="M 136.55,72.17 Z"
+         id="path2019" /><path
+         class="cls-4"
+         d="m 138.9,61.23 c 0,1.56 0.25,0.75 0.4,1.09 -0.1,1.94 -0.3,0.87 -0.51,1.5 a 16.87,16.87 0 0 1 -0.35,3 c -0.06,0 -0.13,0.22 -0.13,0 -0.14,1.31 -1.2,3.67 -1.61,5.16 a 0.66,0.66 0 0 1 -0.15,0.15 c 0.23,-0.17 0.38,-0.15 0.45,-0.06 -0.3,0.69 -0.41,1.35 -0.71,1.53 a 1.55,1.55 0 0 0 0.2,-0.7 c -0.08,0.25 -0.19,0.49 -0.28,0.74 -0.54,0.53 0.4,-1 0.21,-1.09 a 27.73,27.73 0 0 1 -1.84,4.12 c -0.34,0.09 1.24,-2.46 0.29,-1.19 0.32,-0.51 0.61,-1 0.91,-1.58 -1,1.07 0.52,-1 -0.44,0 -0.55,1 -0.84,1.65 -1.14,2.25 a 15.89,15.89 0 0 1 -1.2,2.23 c -0.25,0.71 0.35,-0.17 0.06,0.6 -0.3,0.57 -0.56,1 -0.8,1.42 -0.12,0.2 -0.23,0.39 -0.34,0.56 l -0.08,0.13 v 0.06 c 0,0 0,0 0.05,0 h 0.24 a 11.63,11.63 0 0 1 1.44,0.31 l 1.27,0.31 a 7.21,7.21 0 0 0 1.33,0.15 3.56,3.56 0 0 1 2.58,0.36 c -0.21,0 -0.43,0 -0.64,0.09 a 8.9,8.9 0 0 0 1.7,0.46 3.53,3.53 0 0 1 1.63,0.83 c -0.4,-0.15 -1.56,-0.76 -1.28,-0.58 a 3.13,3.13 0 0 0 1.07,0.6 2,2 0 0 1 0.89,0.42 v 0.34 a 10,10 0 0 1 2.4,2.61 10.67,10.67 0 0 1 1.29,3.63 c -0.1,-0.13 -0.27,-0.56 -0.23,0.06 0.34,1.66 0.51,3.53 0.76,5.38 a 52.53,52.53 0 0 0 0.94,5.37 c 0.19,0.4 0.36,0.81 0.57,1.2 0.21,0.39 0.07,0.57 -0.07,0.27 0.32,1.29 0.15,0 0.43,0.6 0.28,0.6 0.18,1 0,0.56 0.47,1.08 1.12,2.62 1.83,4.14 0.71,1.52 1.47,3 2,4.19 l -0.29,-0.39 c 0.86,1.73 1.46,1.66 2.25,3.26 l -0.22,-0.26 a 36.05,36.05 0 0 0 3.89,5 14.48,14.48 0 0 1 0.93,1.12 l 0.8,1.17 c 0.52,0.78 1,1.52 1.36,2.21 0.62,0.3 2.15,3.42 2.65,3.4 1,2.1 0.67,1.55 2.12,4.47 0.38,0.77 0.85,1 1.34,2 l -0.19,0.12 c 0.27,0.41 0.56,0.81 0.81,1.23 v 0.82 c 0.15,0.3 0.29,0.6 0.42,0.91 -0.12,-0.38 -0.21,-0.83 -0.12,-0.8 a 10.16,10.16 0 0 1 0.95,3.74 32.78,32.78 0 0 1 1,3.56 6.57,6.57 0 0 1 -0.39,-1.14 c 0.59,1.89 -0.17,0.39 0.32,2.13 0,-0.25 0.16,0.11 0.21,0.15 0,0.93 0.22,3 0.38,4.51 l -0.18,-0.28 a 30.6,30.6 0 0 1 -0.46,8.73 c 0.3,-1 0.52,-0.76 0.36,0.13 l -0.32,0.29 c 0,0.6 0.32,-0.89 0.21,0.31 -0.32,1.11 -0.46,0.67 -0.38,0 0,0.22 -0.08,0.45 -0.13,0.67 l -0.08,0.34 c 0,0.1 0,0.09 0,0.14 0,0.05 -0.09,-0.1 -0.16,-0.18 0,0.08 0,0.09 0,0.13 0,0.04 0,0 -0.09,0 h -0.08 l -0.22,0.06 a 6.49,6.49 0 0 0 -1.58,0.52 l -0.09,-0.05 a 22,22 0 0 1 -3.54,0.58 13.5,13.5 0 0 1 -3.1,-0.06 c -0.1,0.21 -0.93,0 -1.54,-0.18 a 12.51,12.51 0 0 0 -1.25,-0.9 3.76,3.76 0 0 0 -1.92,-0.26 13.77,13.77 0 0 0 -3.34,0.85 c -1.49,0.67 -0.39,0.33 -1,0.71 -0.19,-0.15 -2.3,0.75 -1.26,0.17 -2.52,1.1 -3.2,1.45 -6.27,3 0.37,-0.08 0.77,-0.22 0.6,-0.07 -0.56,0.29 -1.33,0.49 -1.28,0.37 l 0.14,-0.08 -0.66,0.32 a 1.77,1.77 0 0 1 -0.38,0.15 c -0.17,0 -0.48,-0.08 -0.35,-0.32 a 5.67,5.67 0 0 0 0.15,-0.88 18.65,18.65 0 0 0 0.18,-2.88 10.6,10.6 0 0 0 -0.1,-1.4 6.38,6.38 0 0 0 -0.23,-1.33 c -0.1,-0.42 -0.21,-0.82 -0.34,-1.2 -0.13,-0.38 -0.33,-0.71 -0.5,-1 l 0.09,0.16 -0.37,-0.77 -0.46,-0.71 a 8.08,8.08 0 0 0 -1,-1.37 c -0.94,-1.24 0.7,0.65 0.08,-0.33 l -0.9,-1 -0.91,-0.78 c -0.29,-0.24 -0.54,-0.51 -0.83,-0.72 l -0.85,-0.59 a 13.07,13.07 0 0 0 -3.66,-1.83 10.79,10.79 0 0 0 -2.1,-0.91 6.92,6.92 0 0 0 -1.41,-0.34 l -1.54,-0.27 a 26.13,26.13 0 0 0 -3.11,-0.3 l -2.68,-0.26 0.17,0.14 a 4.47,4.47 0 0 1 -1.52,-0.1 c 0.08,0.11 0.85,0.12 0.36,0.19 l -2.57,0.07 h -0.82 v 0.89 l 0.9,-0.85 a 6.37,6.37 0 0 0 -1.07,0 l 0.89,0.85 v -0.89 h -0.81 l -4.14,-0.09 c -1.4,0 -2.81,0.14 -4.22,0.21 l -2.11,0.32 a 11.79,11.79 0 0 0 -2.11,0.43 l -2.08,0.59 -2,0.88 a 3.46,3.46 0 0 0 -1.15,0.76 5.87,5.87 0 0 0 -0.51,0.58 3.36,3.36 0 0 1 -0.63,0.6 13.12,13.12 0 0 1 -1.34,1.12 l 0.52,-0.81 a 14.83,14.83 0 0 0 -4.18,6.72 13.11,13.11 0 0 0 -0.43,1.91 l -0.14,1 v 1 a 17.36,17.36 0 0 0 0,1.91 c 0,0.31 0.07,0.62 0.11,0.93 0,0.13 0,0.36 0,0.41 l 0.06,0.24 v 0.08 a 0.75,0.75 0 0 0 -0.09,-0.09 0.54,0.54 0 0 1 -0.1,-0.25 1.64,1.64 0 0 0 0,0.23 c 0,0 0,0.09 -0.07,0.1 h -0.11 a 2,2 0 0 1 -0.31,0.13 c -0.45,0.11 -0.9,0.11 -0.91,0.16 -0.62,-0.09 -0.12,-0.14 -0.49,-0.3 a 10,10 0 0 1 -2.68,-1 c -0.07,-0.07 0.28,0.07 0.44,0.14 -0.61,-0.19 -2.68,-1.42 -2.23,-0.94 -1.54,-0.94 -3.11,-1.56 -4.43,-2.25 a 19,19 0 0 1 -1.94,-0.62 2.61,2.61 0 0 0 -1.53,-0.23 c 0.11,-0.17 -0.72,-0.38 -1.78,-0.43 a 4.57,4.57 0 0 0 -1.76,0.29 2.91,2.91 0 0 0 -1.22,0.93 c 0.11,-0.18 -0.11,0 -0.28,0.13 -0.17,0.13 -0.29,0.17 -0.23,0 -0.46,0.48 -1.68,0.46 -1.44,0.65 -1.08,-0.19 -2.2,-0.27 -3.19,-0.47 a 4.21,4.21 0 0 1 -2.31,-1 2.5,2.5 0 0 0 -0.4,-0.15 v -0.06 a 0.42,0.42 0 0 1 0,-0.13 l -0.16,-0.63 c -0.09,-0.42 -0.18,-0.83 -0.26,-1.24 -0.17,-0.82 -0.31,-1.64 -0.41,-2.45 a 39.14,39.14 0 0 1 -0.35,-4.78 c 0.17,0.06 0.16,1 0.21,1.92 0.05,0.92 0.12,1.78 0.29,1.69 a 32.77,32.77 0 0 1 -0.2,-8.34 c 0.13,-0.83 0.1,0.49 0.14,0.78 a 32.18,32.18 0 0 1 1.74,-8.92 2.62,2.62 0 0 1 -0.13,0.6 c 0.19,-0.53 0.5,-1.22 0.34,-1.21 l -0.16,0.53 c -0.25,0.39 -0.18,-0.18 0,-0.87 a 14.56,14.56 0 0 0 0.37,-1.55 c 0,1.06 1.29,-2.58 1.16,-0.94 0.13,-0.35 0.27,-0.81 0.14,-0.77 0.27,-0.5 0.4,-0.63 0.26,-0.07 a 27.17,27.17 0 0 1 1.22,-2.95 c 0.07,0 -0.09,0.38 -0.1,0.6 a 14.55,14.55 0 0 1 1.46,-3.17 c 0,0.11 0.13,0 -0.1,0.39 1.3,-2.39 2,-4.23 3.58,-6.74 -0.17,0.92 0.6,-0.82 0.92,-0.82 l 0.75,-1.43 -0.45,0.49 c 0.72,-1.21 1.18,-2.38 1.88,-3.37 l -0.44,1 1.32,-2.27 -0.86,1.21 c 0.61,-1.29 -0.39,-0.05 0.66,-1.61 -0.18,0.34 0.75,-1.19 1.28,-1.72 v 0 a 10.57,10.57 0 0 1 1.24,-2.12 c 0.22,-0.18 0.14,0.35 0.29,0.23 0.17,-0.7 1.77,-2.79 2,-3.69 -0.1,0.28 0,0.37 0.1,0.3 l 0.13,-0.6 c 0.38,-0.54 0.43,-0.63 0.49,-0.48 0.91,-1.79 -0.56,0.44 0.55,-1.66 a 3.4,3.4 0 0 1 -0.12,0.48 39.7,39.7 0 0 0 2,-6.44 c 0.43,-0.56 -0.37,1.86 0,1.2 0.76,-3 0.77,-6.45 1.85,-9.19 l -0.21,0.51 c -0.25,-0.54 0.92,-2 1.62,-3.27 -0.19,0.31 -0.07,0.52 -0.06,0.41 a 18.3,18.3 0 0 1 4.9,-5.08 c -0.09,0.1 -0.18,0.19 -0.26,0.29 a 25,25 0 0 1 4,-1.89 c 0.31,-0.23 1,-0.46 0.55,-0.45 l 1.64,-0.35 2.25,-0.54 c -0.23,-0.4 -0.51,-0.83 -0.76,-1.23 l -0.67,-1 c -0.38,-0.55 -0.73,-1.11 -1.06,-1.67 a 17.23,17.23 0 0 1 -1.7,-3.48 c 0.19,0.38 0.54,0.86 0.39,0.56 -0.51,-0.88 -0.92,-1.79 -1.38,-2.69 -0.06,0.29 0.07,0.4 0.21,1 a 7.59,7.59 0 0 1 -1,-1.76 c 0.62,1.22 0.25,-0.12 0.12,-0.7 0,0.12 -0.15,0 -0.18,0 -0.28,-1.59 -0.43,-0.13 -1,-2.24 l 0.12,0.08 a 14.45,14.45 0 0 1 -0.78,-2.3 c 0.12,-0.4 0.28,0.82 0.47,0.82 C 95.22,65.8 95,65.23 94.81,64.67 a 4.57,4.57 0 0 1 -0.26,-1.7 c 0.08,0.52 0.24,1.25 0.37,1.75 A 19.42,19.42 0 0 0 94.83,62.5 v 0.08 a 6.81,6.81 0 0 1 0,-1 8.42,8.42 0 0 1 0.08,-1 4.54,4.54 0 0 0 -0.09,0.51 4.09,4.09 0 0 1 -0.16,-1.15 6.31,6.31 0 0 1 0.17,-1.2 18.87,18.87 0 0 1 0.93,-2.6 c -0.66,1.91 0,0.37 0.11,0.62 0.3,-0.4 0.8,-1 0.73,-0.8 0.38,-0.91 1,-1.28 1.56,-2.61 0.1,0 0.57,-0.89 0.6,-0.6 0.63,-1.13 -0.26,0.19 -0.28,0.05 0.82,-1.81 2.67,-3.83 3.69,-6.52 1,-2.24 0.88,-2.79 2,-4.79 0.51,-0.57 -0.12,0.66 -0.1,0.67 0.71,-1 1.26,-1.7 2,-2.57 -0.11,0.21 0.09,0.07 0.4,-0.1 0.66,-0.62 0.26,-0.63 1.29,-1.28 a 6.26,6.26 0 0 1 -0.54,0.79 15.4,15.4 0 0 1 2.54,-2 c 0.32,0 -0.5,0.48 -0.78,0.77 1,-0.73 2.82,-1.55 3.12,-1.87 l -0.78,0.24 c 0.42,-0.19 0.28,0.07 0,0.23 a 2.65,2.65 0 0 1 -1.52,0.57 5.9,5.9 0 0 1 0.69,-0.4 3.73,3.73 0 0 0 -1.93,0.9 c -0.73,0.54 -1.45,1.24 -2,1.77 0.09,-0.23 0.2,-0.44 0.31,-0.67 a 11.82,11.82 0 0 0 -1,1.32 c -0.3,0.2 -0.6,0.27 -0.08,-0.36 -0.91,0.77 -0.61,0.84 -1.36,1.55 -0.09,0.07 -0.07,0 0,-0.07 -0.2,0.33 -0.38,0.68 -0.55,1 0.06,-0.22 -0.29,0 0.12,-0.53 -1.24,1.71 -1.34,3 -1.92,3.62 l 0.06,-0.16 c -1.21,2.57 0.08,0.35 -0.68,2.37 l -1.19,1 0.07,0.35 c -0.16,0.25 -0.46,0.75 -0.48,0.61 -0.42,1 0.18,-0.11 0,0.51 -0.88,1.12 -1.93,3.39 -2.42,3.46 -0.12,0.52 0.84,-1.07 0.13,0.27 -0.55,0.15 -0.9,1.48 -1.76,2.47 0,-0.45 0.82,-1.41 0,-0.42 a 6.82,6.82 0 0 1 -0.76,1.57 6.33,6.33 0 0 0 -0.7,1.87 c 0.15,0 0,0.65 0,1.48 a 12.69,12.69 0 0 0 0.11,2.8 7.22,7.22 0 0 0 0.19,1.91 c 0.19,1.09 0.52,2.38 0.75,3.21 h -0.06 c 0.36,0.23 0.91,1.91 1.47,3.06 -0.17,0 -0.32,-0.17 -0.65,-0.79 l 0.46,1.13 A 6,6 0 0 1 97.15,73 L 96.83,72.81 A 23.49,23.49 0 0 0 98,74.94 c 0.42,0.76 0.89,1.56 1.33,2.5 0.22,0 -0.32,-1.69 0.84,0.14 -0.05,0.12 -0.16,0.28 -0.48,-0.19 a 5.3,5.3 0 0 1 0.55,0.88 L 99.66,77.6 c 0.39,0.86 0.36,0.36 0.73,1 -0.14,0.07 0.19,0.53 0,0.5 a 6.28,6.28 0 0 0 -0.48,-0.81 c 0.21,0.37 0.42,0.79 0.6,1.15 a 1.09,1.09 0 0 1 0.12,0.49 c 0.08,0 0.23,0 0.48,0.39 0,0 0.06,0.07 0,0.07 -0.48,0.12 -0.59,0.1 -0.66,0.06 a 0.55,0.55 0 0 0 -0.36,-0.06 3,3 0 0 1 -0.69,0.27 c -0.3,0.11 -0.54,0.22 -0.52,0.33 a 1.85,1.85 0 0 1 -0.76,0.09 c -0.38,0.17 -1.29,0.56 -2,0.89 -0.71,0.33 -1.13,0.64 -0.65,0.53 l 0.2,-0.08 -0.12,0.07 v 0 c -2.33,1.39 -4.91,3 -6.44,5.36 v 0 a 17.23,17.23 0 0 0 -1.25,2.28 8.72,8.72 0 0 0 -0.65,2.12 c -0.15,0.46 -0.43,1.06 -0.47,0.84 a 30.83,30.83 0 0 1 -0.63,3.09 c 0.1,-1.23 -0.2,0.4 0.14,-1.26 a 18.37,18.37 0 0 0 -0.68,3.6 c -0.07,-0.61 -0.48,1.11 -0.62,1.84 l 0.39,-1 a 20.43,20.43 0 0 1 -0.58,2.25 l -0.13,-0.45 c -0.58,1.5 -0.9,2.9 -1.33,4.16 a 8.41,8.41 0 0 1 -1.89,3.26 c -0.3,0.82 1,-1.41 0.81,-0.66 -0.81,1.24 -2,2.34 -2.25,2.74 -1.24,1.65 -0.75,1.8 -2,3.58 0.22,-0.19 0.56,-0.28 -0.22,1.13 -0.81,1.26 -1.28,1.38 -0.85,0.53 0.18,-0.31 0.29,-0.44 0.31,-0.42 0.23,-0.43 0.54,-1 0.14,-0.53 v 0.21 c -0.47,0.59 -1.53,2.37 -1.41,1.88 -0.5,1 -0.12,0.49 0.35,-0.21 -1.1,1.59 -1.54,2.59 -2.62,4.26 0.21,-0.25 0.44,-0.45 0.28,-0.18 -1.56,2.46 -0.5,1.19 -1.45,2.92 -0.68,0.9 -0.08,-0.51 -1,1.26 -0.68,1 -0.33,0.11 -0.15,-0.35 a 32.62,32.62 0 0 1 -2.3,3.79 l 0.4,-0.87 c -0.24,0.52 -0.47,0.93 -0.7,1.35 l 0.42,-0.4 c -0.3,0.48 -0.52,0.9 -0.58,0.86 -0.17,0.57 0.47,-0.25 0.07,0.84 -0.43,0.62 -1,2.07 -1.29,2.2 1.14,-2.08 -0.33,0.12 0.55,-1.68 a 10.5,10.5 0 0 1 -0.66,1.26 c -0.06,0.07 0,-0.09 0.06,-0.23 -1.19,1.95 -0.25,1 -1.22,3.18 0,-0.33 -0.46,0.4 -0.57,0.77 0.36,-0.88 0.37,-0.33 0.14,0.51 a 11.9,11.9 0 0 0 -0.8,2.3 c 0.11,-0.28 0.23,-0.55 0.35,-0.83 a 12.63,12.63 0 0 1 -0.53,2 c -0.12,0.06 0.23,-0.93 0.07,-0.59 -0.14,1.17 -1,2.49 -1.12,4.14 -0.21,0.74 -0.26,0 -0.43,0.68 -0.07,1.87 -0.43,2 -0.43,3.9 0.22,-0.54 0.17,-0.64 0.27,0.72 0,-1.05 0.05,-2.09 0.12,-3.14 0,0.68 0,1.35 0.08,2 0.07,-0.95 0.06,-2 0.17,-2.57 0,1 0,0.87 0.2,0.43 -0.41,1.27 -0.09,2.57 -0.33,4 l -0.44,-0.07 c -0.27,2.28 0.15,4 0.35,7 v -0.95 c 0.2,0.38 0.21,1.81 0.43,2.74 -0.16,-0.07 -0.12,0.53 -0.14,1 0,0 0.1,0.27 0.18,0.66 q 0.08,0.3 0.15,0.63 c 0.07,0.3 0.16,0.64 0.24,0.89 a 1.89,1.89 0 0 0 0.73,0.22 c 0.45,0.31 0.77,0.52 1.18,0.77 a 6.7,6.7 0 0 0 2.54,0.61 l 2.52,0.11 c -0.71,0.11 0.35,0.31 -1.24,0.29 a 3.49,3.49 0 0 0 1.53,0 3.44,3.44 0 0 0 1.44,-0.22 4,4 0 0 0 0.89,-0.47 c 0.25,-0.2 0.45,-0.38 0.6,-0.48 0.15,-0.1 0.11,-0.24 0.19,-0.38 a 0.92,0.92 0 0 1 0.54,-0.42 c 0.08,0 0,0.07 0,0.07 0,0 0.23,-0.16 0.44,-0.23 0.21,-0.07 0.34,-0.13 0,-0.17 a 17.66,17.66 0 0 1 4.13,0.73 12.62,12.62 0 0 1 3.66,1.74 c 1.47,0.7 3.21,1.64 4.6,2.26 -0.11,0 0,0.07 -0.29,-0.06 a 3.29,3.29 0 0 0 1.65,0.54 c 0.19,0 0.38,0 0.68,0.08 0.3,0.08 0.67,0.16 1.28,0.25 0.31,0.1 0.39,0.1 0.34,0.14 a 1,1 0 0 1 -0.44,0 c -0.39,0 -0.85,-0.1 -0.45,0 0.11,0.2 0.66,0.38 1.45,0.24 a 5.15,5.15 0 0 0 1.32,-0.45 1.5,1.5 0 0 0 0.65,-0.43 0.52,0.52 0 0 0 0.08,-0.37 v -0.38 c 0,-0.2 -0.05,-0.41 -0.07,-0.6 a 3.14,3.14 0 0 1 0,-0.45 l 0.07,0.38 A 23.67,23.67 0 0 1 94,159.85 c 0,0 0,0.1 0.07,0 a 5.45,5.45 0 0 1 0.07,-1.17 8.7,8.7 0 0 1 0.3,-1.41 c 0.17,-0.47 0.31,-1 0.53,-1.45 l 0.68,-1.31 c -0.12,0.6 -0.33,0.77 0,0.57 0.19,-0.36 0.1,-0.35 0.05,-0.43 -0.05,-0.08 -0.06,-0.26 0.45,-0.92 0.2,-0.19 0.51,-0.49 0.8,-0.75 a 1.8,1.8 0 0 1 0.75,-0.37 l -0.56,0.52 -0.47,0.6 a 2,2 0 0 0 0.49,-0.44 l 0.52,-0.5 a 11.51,11.51 0 0 1 1,-1 c 0,0.05 0,0.11 0,0.16 1,-0.66 1.4,-1.07 1.89,-1.45 a 13.7,13.7 0 0 1 2.27,-1.18 h -0.28 c 1.25,-0.72 1.18,-0.2 2.46,-0.83 l 0.48,0.16 a 28.45,28.45 0 0 1 4.85,-1 c -0.47,0.15 -1.2,0.25 -1.94,0.44 l -2.08,0.58 c 0.46,-0.09 1.22,-0.23 1.93,-0.38 0.71,-0.15 1.39,-0.2 1.62,-0.31 a 7,7 0 0 1 -1.2,0.14 19,19 0 0 1 1.94,-0.41 13.72,13.72 0 0 1 2.52,-0.21 c -0.2,0.36 1.77,0.35 3.59,0.4 l -0.57,-0.59 V 148 h 0.64 a 4.77,4.77 0 0 1 0.93,0 l 0.62,0.08 v -0.71 -0.05 l -0.6,0.63 a 5.83,5.83 0 0 1 1.49,0.18 c 0.82,-0.06 1.63,-0.09 2.45,-0.11 0.82,-0.02 1.64,0.13 2.47,0.2 a 17.48,17.48 0 0 1 2.54,0.37 c 0.85,0.2 1.75,0.3 2.64,0.56 -1.15,-0.83 1,0.31 1,-0.2 a 6.46,6.46 0 0 1 1.23,0.39 c 0.8,0.4 1.54,0.9 2.3,1.33 0.49,0.38 -0.79,-0.26 -0.77,-0.13 0.86,0.39 1,0.57 1,0.68 0,0.11 0.06,0.2 0.52,0.58 -0.06,-0.14 0.11,-0.1 0.39,0.05 a 5.38,5.38 0 0 1 0.51,0.31 c 0.17,0.14 0.34,0.32 0.53,0.51 -0.16,-0.19 -0.31,-0.39 -0.48,-0.58 l -0.56,-0.49 a 6.65,6.65 0 0 1 0.74,0.43 c 0.18,0.16 0.33,0.31 0.46,0.44 a 8.14,8.14 0 0 1 0.61,0.71 c 0.18,0.21 0.31,0.46 0.52,0.76 0.21,0.3 0.53,0.63 0.91,1.14 a 4.55,4.55 0 0 0 -0.59,-0.57 c 0.11,0.13 0.25,0.27 0.38,0.45 l 0.38,0.63 0.43,0.72 c 0.13,0.26 0.23,0.54 0.35,0.82 0.12,0.28 0.26,0.54 0.35,0.82 0.09,0.28 0.19,0.56 0.27,0.81 0.2,0.51 0.31,1 0.46,1.28 0,0.25 -0.1,0.57 -0.22,0 0,0.25 0.07,0.51 0.11,0.76 0.04,0.25 0,0.53 0.05,0.79 0.07,0.54 0.05,1.08 0.07,1.63 0,0.28 0,0.55 0,0.83 0,0.28 0,0.21 0,0.52 0,0.31 0,0.43 0,0.65 v 0.62 a 0.55,0.55 0 0 0 0.21,0.51 1.78,1.78 0 0 0 1.08,0.4 c 0.24,0 0.47,-0.06 0.69,-0.11 l 0.68,-0.25 c 0.4,-0.16 0.6,-0.26 0.89,-0.38 0.54,-0.23 1,-0.43 1.5,-0.59 l -0.19,0.2 a 7.83,7.83 0 0 1 1.69,-0.87 c 0,0.06 -0.18,0.21 0.09,0.09 a 15,15 0 0 1 2.24,-1.14 l -0.6,0.4 c 1.53,-0.6 2.66,-1.16 3.72,-1.67 a 14.12,14.12 0 0 1 3.37,-1.29 c 0,0.17 0.69,0.16 1.08,0.36 a 8.22,8.22 0 0 1 0.81,0.63 4.85,4.85 0 0 0 1.23,0.7 h -0.07 a 8.37,8.37 0 0 0 3,0.47 16.68,16.68 0 0 0 2.59,-0.2 23.89,23.89 0 0 0 5,-1.36 c 0.11,0 0.36,-0.09 0.59,-0.15 l 0.39,-0.12 0.2,-0.06 0.08,-0.21 0.29,-0.83 c 0.07,-0.19 0.15,-0.39 0.21,-0.61 a 22,22 0 0 0 0.68,-2.89 41.51,41.51 0 0 0 0.43,-6.21 c 0,0.56 -0.25,-0.08 -0.33,-0.72 0,-0.86 -0.41,-2.32 -0.1,-2.21 v 0.3 a 11.82,11.82 0 0 0 -0.21,-3.74 l -0.43,-0.16 a 18.06,18.06 0 0 0 -1.3,-6.15 c -0.74,-2 -1.64,-3.73 -1.82,-4.73 -0.47,-0.73 -1,-1.68 -1.47,-2.37 l 0.21,-0.07 a 47.12,47.12 0 0 0 -3.4,-5.54 l 0.46,0.41 c -0.91,-1.38 -1.68,-1.38 -2.56,-2.61 v -0.56 l -1.22,-1.8 a 16.73,16.73 0 0 0 -1.37,-1.78 c -0.92,-1.09 -1.81,-2.14 -2.74,-3.17 0.06,0 0.18,0 0.46,0.38 -0.83,-1 -2.6,-4.34 -2.72,-3.72 0.21,-0.16 -1.39,-2.53 -2.1,-3.89 l 0.29,0.13 a 9.64,9.64 0 0 1 -1.59,-2.72 c -0.12,-0.41 0,-0.41 0.17,0.14 -0.37,-1.37 -0.59,-1 -1,-2.64 l 0.32,0.57 a 6.52,6.52 0 0 0 -0.85,-2 11.74,11.74 0 0 1 -0.44,-1.71 3.29,3.29 0 0 1 -0.06,-1.25 3.91,3.91 0 0 1 -0.58,-1.78 c 0,-0.12 0.15,0.18 0.2,0.33 -0.3,-2.42 -0.79,-3.56 -0.82,-5.28 0.07,0 0.09,-0.16 0.09,-0.3 0.24,2 0.44,3.5 0.41,3.36 0.19,0 0,-1.59 0.44,-0.39 a 43.17,43.17 0 0 1 -1.11,-4.9 0.75,0.75 0 0 1 0,-0.22 l 0.05,0.15 a 4.22,4.22 0 0 0 -0.24,-1 7.33,7.33 0 0 0 -0.35,-1.32 c 0.14,-0.26 -0.72,-1.87 -1.25,-2.56 -0.13,0.17 -0.8,-0.7 -0.29,0.21 -0.06,-0.12 0.12,0.1 0.43,0.58 l 0.21,0.29 h -0.05 a 10.42,10.42 0 0 1 0.87,1.9 c -0.32,-0.59 -0.64,-1.18 -1,-2 a 9.79,9.79 0 0 0 -0.94,-0.75 6.67,6.67 0 0 0 -1.19,-1.76 c -0.5,-0.55 -1,-1 -1.06,-1.13 a 15.12,15.12 0 0 0 -3.83,-1.6 10.15,10.15 0 0 0 -3.35,-0.36 1,1 0 0 1 -0.55,-0.11 c -0.08,0 -0.1,-0.11 -0.14,-0.14 h 0.76 -0.81 -0.56 l 0.07,-0.15 a 2.75,2.75 0 0 0 0.36,-1 c 1,-1.43 -0.26,1 0.89,-1.11 l -0.08,0.32 a 22.35,22.35 0 0 0 2.73,-5.63 c 0.67,-1.87 1.28,-3.8 2.22,-6.28 a 1.88,1.88 0 0 1 -0.26,0.58 15.26,15.26 0 0 0 0.34,-9.13 22.93,22.93 0 0 0 -2.15,-4.09 c -0.75,-1.3 -1.46,-2.6 -2.1,-3.91 a 10.72,10.72 0 0 0 -1.61,-2.36 v -0.42 l -1.08,-1.38 a 18.42,18.42 0 0 1 -1.55,-3.07 7.85,7.85 0 0 0 -2.39,-3.24 l 0.17,0.41 a 12,12 0 0 0 -1.62,-1.49 c -0.57,-0.46 -1,-0.79 -0.9,-0.81 a 1.58,1.58 0 0 1 -0.72,-0.4 V 37 a 22.23,22.23 0 0 0 -2.53,-1.17 c -1.94,-0.93 0.53,-0.36 -2.43,-1.52 -1.13,-0.36 -3.3,-0.6 -2.89,-0.41 0.41,0.19 1.14,0.38 1.14,0.5 l -1,-0.21 c -0.28,0.3 -1.1,0.42 1.25,1.34 0.58,0.09 1.15,0.22 1.73,0.35 l 0.46,0.37 c -0.45,-0.19 -0.91,-0.34 -1.38,-0.5 a 5.87,5.87 0 0 0 1.86,0.62 1.73,1.73 0 0 0 0.59,0.46 c 0.56,0.14 1.12,0.3 1.67,0.48 0.11,0.22 -0.8,-0.13 0.15,0.49 0.76,0.28 -0.5,-0.67 0.69,-0.06 0.61,0.59 0.34,0.54 1.2,1 0.06,0.16 -0.14,0.08 -0.47,-0.12 0.78,0.4 1.78,1.39 2.22,1.58 0.23,0.38 0.73,0.9 1.1,1.38 0.37,0.48 0.58,0.89 0.42,0.94 a 11.67,11.67 0 0 1 1.42,1.92 c -1.09,-1.12 1.5,2.72 0.93,2.58 0.86,0.8 2.14,3.44 3.31,5.05 a 1.5,1.5 0 0 1 -0.31,-0.4 c 0.54,1 0.61,1.32 0.92,2 0.32,0 1.27,1.44 1.9,2.15 0.43,1.3 -0.71,-0.54 -0.73,0 0.08,-0.09 0.44,0.38 0.74,0.81 0.3,0.43 0.51,0.81 0.52,0.58 0.22,1 0.24,0.8 0.15,1.34 0.4,0.06 0.3,0.83 0.6,1.6 0,0.72 -0.1,0.81 -0.15,0.92 -0.05,0.11 -0.05,0.23 0,1 -0.11,0.54 -0.18,-0.85 -0.21,-0.84 z m 6.94,29.49 v 0 c -0.06,-0.33 -0.12,-0.6 -0.16,-0.78 0.03,0.17 0.07,0.39 0.16,0.78 z m 0.45,3.27 c 0,-0.4 -0.11,-0.9 -0.18,-1.43 0.06,-0.12 0.15,0 0.19,0.32 -0.07,-0.17 -0.01,0.61 -0.01,1.12 z m -0.14,-7.29 c 0.29,0.5 0.3,0.7 0.29,0.79 a 6.89,6.89 0 0 0 -0.43,-0.9 h -0.06 a 0.63,0.63 0 0 1 0.2,0.11 z"
+         id="path2021" /><path
+         class="cls-4"
+         d="m 145.41,85.94 -0.14,-0.19 0.14,0.31 0.16,0.13 z"
+         id="path2023" /><path
+         class="cls-4"
+         d="M 95.57,82.51 H 95.5 a 0.56,0.56 0 0 1 0.15,0 z"
+         id="path2025" /><polygon
+         class="cls-4"
+         points="166.55,134.61 166.6,134.58 166.44,134.34 "
+         id="polygon2027" /><path
+         class="cls-4"
+         d="m 96.73,70 a 1.3,1.3 0 0 0 0,-0.23 0.77,0.77 0 0 0 0,0.23 z"
+         id="path2029" /><path
+         class="cls-4"
+         d="m 94.85,62.48 a 9.84,9.84 0 0 1 0,-1.09 6.2,6.2 0 0 0 0,1.09 z"
+         id="path2031" /><path
+         class="cls-4"
+         d="m 95.93,56.87 a 0.22,0.22 0 0 0 0,-0.14 v 0 z"
+         id="path2033" /><path
+         class="cls-4"
+         d="m 66.41,138.61 -0.07,0.22 c -0.12,0.53 -0.04,0.17 0.07,-0.22 z"
+         id="path2035" /><path
+         class="cls-4"
+         d="m 79.62,113.3 c -0.13,0.27 -0.26,0.55 -0.41,0.83 0.29,-0.43 0.5,-0.76 0.41,-0.83 z"
+         id="path2037" /><polygon
+         class="cls-4"
+         points="73.01,161.02 72.9,161.12 "
+         id="polygon2039" /><path
+         class="cls-4"
+         d="m 78.5,115.26 a 8.5,8.5 0 0 0 0.71,-1.13 10.77,10.77 0 0 0 -0.71,1.13 z"
+         id="path2041" /><path
+         class="cls-4"
+         d="m 111.24,36.63 0.27,-0.1 c 0,0 0,0 0,-0.05 z"
+         id="path2043" /><path
+         class="cls-4"
+         d="m 111.53,36.48 0.28,-0.14 a 0.87,0.87 0 0 0 -0.28,0.14 z"
+         id="path2045" /><path
+         class="cls-4"
+         d="m 112.41,36.05 c -0.2,0.09 -0.4,0.18 -0.6,0.29 a 3.06,3.06 0 0 0 0.6,-0.29 z"
+         id="path2047" /><path
+         class="cls-4"
+         d="m 105.09,41.16 v 0.12 a 0.1,0.1 0 0 0 0,-0.12 z"
+         id="path2049" /><path
+         class="cls-4"
+         d="m 103.88,43.17 c 0.28,-0.5 0.82,-1.16 1.23,-1.8 v -0.09 c -0.11,0.33 -1.11,1.33 -1.23,1.89 z"
+         id="path2051" /><path
+         class="cls-4"
+         d="m 98.16,51.66 1.1,-1.72 c -0.25,0.26 -0.59,0.61 -0.13,-0.2 -1.52,2.09 0.43,-0.36 -0.97,1.92 z"
+         id="path2053" /><path
+         class="cls-4"
+         d="m 94.69,57.05 c 0.47,-1.06 -0.12,0 -0.13,-0.11 -0.21,0.73 -0.24,0.9 0.13,0.11 z"
+         id="path2055" /><path
+         class="cls-4"
+         d="m 86.6,93.49 -0.15,-0.16 c -0.17,0.85 0.06,0.03 0.15,0.16 z"
+         id="path2057" /><path
+         class="cls-4"
+         d="m 85.65,102.3 c 0.13,-0.25 0.24,-0.51 0.35,-0.77 l -0.07,-0.43 c -0.09,0.4 -0.17,0.8 -0.28,1.2 z"
+         id="path2059" /><path
+         class="cls-4"
+         d="m 82.52,106.56 0.14,-0.33 c -0.18,0.42 -0.39,0.82 -0.61,1.22 0.17,-0.29 0.31,-0.59 0.47,-0.89 z"
+         id="path2061" /><path
+         class="cls-4"
+         d="m 81.58,162.86 -0.13,-0.32 c -0.53,-0.19 -0.73,0.01 0.13,0.32 z"
+         id="path2063" /><path
+         class="cls-4"
+         d="m 102.64,149.55 a 5.42,5.42 0 0 0 1.77,-0.48 14.16,14.16 0 0 0 -1.77,0.48 z"
+         id="path2065" /><polygon
+         class="cls-4"
+         points="171.12,142.36 171.34,143.02 171.02,141.76 "
+         id="polygon2067" /><path
+         class="cls-5"
+         d="m 118.76,147.33 c 11.09,-0.71 20.84,12.67 20.84,12.67 2.39,-16.64 -0.31,-28.09 -3.24,-35.49 -0.85,-2.13 -1.55,-3.51 -8.82,-18.54 -3.83,-7.9 -6.94,-14.35 -9,-18.53 h -1.42 c -2.34,5.21 -6,13.06 -11.19,22.37 -5.28,9.54 -5.27,8.32 -6.93,12 0,0 -3.83,8.58 -4.65,38.48 v 0 c 0,0 11.5,-13.72 22.6,-13 z"
+         id="path2069" /><path
+         class="cls-5"
+         d="m 118.76,148 c 0.11,-0.09 0,-0.28 -0.26,-0.24 l -0.22,0.33 z"
+         id="path2071" /><path
+         class="cls-5"
+         d="m 116.7,147.39 c -0.36,0.17 -0.75,0.45 -0.52,0.75 0.34,-0.32 0.42,-0.19 0.8,-0.57 0.31,0 0.53,0.11 0.48,0.23 0.11,-0.09 0.48,0.07 0.64,-0.14 a 1.5,1.5 0 0 0 -1.42,0 c -0.11,-0.12 0,-0.21 0.02,-0.27 z"
+         id="path2073" /><path
+         class="cls-5"
+         d="m 95,156.65 v 0.19 a 1.62,1.62 0 0 0 0,-0.19 z"
+         id="path2075" /><path
+         class="cls-5"
+         d="m 96.42,138.75 c 0,0.15 0,0.21 0,0.22 0,0.01 0.03,-0.24 0,-0.22 z"
+         id="path2077" /><path
+         class="cls-5"
+         d="m 97.16,135.68 v 0.18 a 0.25,0.25 0 0 0 0,-0.18 z"
+         id="path2079" /><path
+         class="cls-5"
+         d="m 95,156.65 0.12,-0.46 C 95,156.24 95,156.44 95,156.65 Z"
+         id="path2081" /><path
+         class="cls-5"
+         d="m 112.82,148.58 a 2.3,2.3 0 0 0 0.23,-0.15 2.18,2.18 0 0 0 -0.23,0.09 z"
+         id="path2083" /><path
+         class="cls-5"
+         d="m 97.29,156.28 0.11,-0.11 a 0.54,0.54 0 0 0 0,-0.18 z"
+         id="path2085" /><path
+         class="cls-5"
+         d="m 102.11,152.16 c -0.12,0.07 0,0.33 0,0.46 a 0.45,0.45 0 0 1 0.13,-0.34 0.29,0.29 0 0 0 -0.13,-0.12 z"
+         id="path2087" /><path
+         class="cls-5"
+         d="m 111.19,147.86 0.16,-0.09 z"
+         id="path2089" /><path
+         class="cls-5"
+         d="m 95.4,158.11 0.08,-0.22 a 2.11,2.11 0 0 0 -0.08,0.22 z"
+         id="path2091" /><path
+         class="cls-5"
+         d="m 125.32,149.88 c 0,0 -0.04,-0.02 0,0 z"
+         id="path2093" /><path
+         class="cls-5"
+         d="m 118.75,147.26 h 0.1 a 0.88,0.88 0 0 0 0,-0.16 z"
+         id="path2095" /><path
+         class="cls-5"
+         d="m 98.38,130.09 v 0 c 0,0.17 0.01,0.09 0,0 z"
+         id="path2097" /><path
+         class="cls-5"
+         d="m 119.46,92 c 0,-0.65 0.72,0.74 0.58,-0.2 -0.04,0.07 -0.76,-0.6 -0.58,0.2 z"
+         id="path2099" /><path
+         class="cls-5"
+         d="m 112.66,148.58 -0.23,0.07 a 0.7,0.7 0 0 0 0.23,-0.07 z"
+         id="path2101" /><path
+         class="cls-5"
+         d="m 120,91.75 v 0 -0.1 z"
+         id="path2103" /><path
+         class="cls-5"
+         d="m 102.53,118.09 a 0.41,0.41 0 0 0 -0.18,0 c 0,0 0.07,0.06 0.18,0 z"
+         id="path2105" /><path
+         class="cls-5"
+         d="m 98.49,126.7 0.09,-0.23 a 1,1 0 0 0 -0.09,0.23 z"
+         id="path2107" /><path
+         class="cls-5"
+         d="m 104.86,113.44 a 0.71,0.71 0 0 0 0.19,-0.31 v 0 a 0.39,0.39 0 0 1 -0.19,0.31 z"
+         id="path2109" /><path
+         class="cls-5"
+         d="m 107.47,108.74 -0.09,0.06 -0.07,0.16 z"
+         id="path2111" /><path
+         class="cls-5"
+         d="m 138.55,160.6 a 3.82,3.82 0 0 1 -0.27,-0.74 c 0.09,0.44 -0.82,-0.61 0.27,0.74 z"
+         id="path2113" /><path
+         class="cls-5"
+         d="m 112.78,148.42 a 0.19,0.19 0 0 1 -0.12,0.16 l 0.16,-0.06 a 0.08,0.08 0 0 0 -0.04,-0.1 z"
+         id="path2115" /><path
+         class="cls-5"
+         d="m 103,112.15 0.45,-0.72 a 7.06,7.06 0 0 0 -0.45,0.72 z"
+         id="path2117" /><path
+         class="cls-5"
+         d="m 137.19,123.52 0.1,0.17 a 0.31,0.31 0 0 0 -0.1,-0.17 z"
+         id="path2119" /><path
+         class="cls-5"
+         d="m 104.68,109.22 a 1.44,1.44 0 0 0 0.4,-0.33 0.49,0.49 0 0 0 0,-0.12 z"
+         id="path2121" /><path
+         class="cls-5"
+         d="M 138.28,159.85 Z"
+         id="path2123" /><path
+         class="cls-5"
+         d="m 133.38,155.57 c 0.57,0.53 0.51,0 0.78,0 0.75,0.58 0.13,0.5 0.22,0.85 0.49,0.34 1.05,0.42 1.34,0.75 0,0.07 0,0.15 -0.1,0.13 a 1.8,1.8 0 0 1 0.49,0.31 l 0.24,0.23 0.33,0.35 a 9.28,9.28 0 0 0 1.51,1.45 1.34,1.34 0 0 1 0.09,0.26 1.93,1.93 0 0 1 -0.06,-0.89 c 0.31,0.38 0.51,0.24 0.67,0.84 -0.19,-0.24 -0.19,-0.08 -0.28,-0.07 l 0.32,0.23 c 0.4,1.09 -0.44,-0.37 -0.43,0.07 0.54,0.56 1,0.93 1.42,1.34 l 0.06,-0.05 c 0,0 0,-0.12 0,-0.16 a 1.13,1.13 0 0 1 0.06,-0.3 1.47,1.47 0 0 1 0.09,0.59 c 0,0.11 0,0.23 0,0.35 a 0.41,0.41 0 0 1 -0.06,0.17 c -0.21,-0.24 -0.37,-0.41 0.11,0.48 l -1,-1.51 c 0.94,2.13 -0.63,-0.88 0.28,1.27 0.46,0.66 0.78,1.08 1,1.38 a 6.34,6.34 0 0 0 0.06,-0.69 c 0,-0.23 0,-0.46 0.05,-0.71 a 15.84,15.84 0 0 1 0.21,-1.65 c -0.1,-0.72 -0.24,-0.28 -0.35,-1 0,-1.42 0.25,-1.62 0.5,-2 a 1.89,1.89 0 0 0 0.32,-0.62 3.11,3.11 0 0 0 0.06,-0.5 1.31,1.31 0 0 0 -0.06,-0.43 c -0.19,-0.33 -0.61,-0.5 -0.3,-1.34 l 0.35,0.33 c 0.15,-1.13 -0.48,-0.69 -0.15,-1.86 0.14,0.23 0.08,0.9 0.13,0.74 0.35,-0.75 -0.18,-0.56 -0.15,-1.15 l 0.35,-0.1 c 0,-1.22 -0.18,-2.56 -0.21,-3.9 0.1,0.08 0.2,0.31 0.31,0 a 35.55,35.55 0 0 1 0.14,-5.27 l -0.33,-0.6 c 0,-0.15 0.11,-0.28 0.18,-0.13 0.06,-0.64 -0.19,0 -0.33,-0.31 -0.14,-0.31 0.13,-0.49 0.24,-0.27 a 14.09,14.09 0 0 1 -0.69,-4.35 l 0.12,0.22 c 0,-0.93 -0.73,-0.94 -0.6,-1.82 l 0.08,0.15 c -0.2,-2 -0.94,-4.09 -0.9,-5.68 -0.48,-0.17 -0.35,-2 -1,-1.93 a 8.31,8.31 0 0 0 -0.19,-2.49 c -0.12,-0.42 -0.55,-0.49 -0.8,-1 l 0.29,-0.12 -0.56,-0.56 0.2,-0.49 -0.26,-0.44 c 0.06,0.19 0,0.45 -0.06,0.45 a 3.11,3.11 0 0 1 -0.42,-1.93 l -1,-1.56 c 0.13,0 0.3,0.25 0.48,0.43 -0.7,-0.75 0.22,-0.3 -0.43,-1 0,0.14 -0.19,0 -0.26,0 a 5.52,5.52 0 0 0 -0.85,-2 h 0.26 c -0.54,-1.24 -1.33,-2.51 -2,-3.87 0.14,0.53 -0.24,0.58 -0.47,0.19 l 0.22,-0.3 c -0.31,-0.17 0.09,0.47 -0.39,0 -0.21,-0.52 0.17,-0.5 0.41,-0.26 l -0.4,-0.56 c 0.07,-0.08 0.18,0 0.31,0 -0.3,-0.16 -0.22,-1.2 -0.71,-1.42 l 0.07,-0.07 c -0.66,-1.36 -1.06,-1.93 -1.61,-3 -0.26,0.1 -0.42,-0.36 -0.78,-0.59 a 22.14,22.14 0 0 0 -1,-2.82 c -0.46,-0.63 -0.31,-0.1 -0.61,-0.34 0.21,-0.16 -0.29,-1.13 0.12,-0.7 a 25.09,25.09 0 0 0 -1.68,-2.88 c 0,0.21 0,0.41 -0.09,0.36 -0.17,-0.26 -0.2,-0.67 -0.07,-0.68 l 0.06,0.06 c -1.16,-1.5 -1.19,-4.18 -2.32,-5.28 l 0.06,0.06 -0.91,-1.25 c -0.27,-0.66 0.35,0.29 0.27,-0.25 -1.11,-1.3 -1.08,-2.37 -1.93,-3.48 a 3.54,3.54 0 0 0 -0.6,-2 L 120.31,88 119.88,87.12 c -0.16,-0.33 -0.31,-0.66 -0.44,-1 h -1 -0.18 0.19 0.09 c 0.06,0 -0.05,0 -0.07,0 h -0.23 a 2.31,2.31 0 0 1 0.23,0.18 4.12,4.12 0 0 1 -0.71,0.06 h -0.27 -0.12 c 0,0 -0.1,0 0,0 0.5,-0.05 -0.06,-0.13 -0.47,-0.15 a 2.11,2.11 0 0 0 0.62,0.14 c 0,0 0.12,0 0.11,0 v 0 c 0,0 0,0 0,0 0,0 -0.07,0 -0.13,0 h -1 q -0.37,0.85 -0.75,1.74 l -0.49,1 c -0.34,0.69 -0.7,1.37 -1.08,2 l -2.3,4 c -0.56,1 0.54,1 -0.5,2.13 l -0.11,-0.52 c -0.68,2.28 -2.16,4.28 -2.93,6.47 0,-0.16 -0.09,-0.21 0,-0.41 -0.44,0.32 -0.85,1.58 -0.68,1.68 -0.19,0.31 -0.19,0 -0.39,0.14 -0.35,0.36 -0.3,1.22 -0.63,1.34 -0.06,0 0,-0.16 0,-0.25 0,0.34 -0.73,1.29 -0.34,1.15 -0.52,0.7 -0.68,1.51 -1.16,2 0.06,0.55 -0.84,1.22 -0.53,1.56 -0.36,-0.27 -1.06,1.14 -1.14,1.72 0,-0.23 -0.36,0.34 -0.42,0.06 -0.3,0.54 -0.51,1.07 -0.26,1.09 -1,0.71 -0.79,2.2 -1.72,2.39 -0.37,0.84 -0.76,1.63 -1.17,2.43 -0.41,0.8 -0.79,1.62 -1.11,2.41 -0.41,-0.26 0.85,-1.73 0.42,-1.89 a 26.35,26.35 0 0 0 -0.93,2.83 l -0.08,0.36 a 0.26,0.26 0 0 1 0,-0.15 0.25,0.25 0 0 1 0,-0.07 v 0 0.15 l -0.1,0.31 c -0.06,0.21 -0.15,0.43 -0.23,0.65 -0.18,0.38 -0.12,-0.28 -0.14,-0.45 a 29.73,29.73 0 0 0 -1,4.48 c 0,0 0,-0.17 -0.06,-0.32 0,0.28 -0.2,0.63 0,0.64 v -0.28 c 0.39,-0.37 0.37,1.21 0.52,1.29 -0.48,-0.58 -0.41,1.35 -1,0.47 0,0.19 0,0.43 0.19,0.42 -0.09,0.26 -0.18,0.33 -0.28,0 -0.08,1 0.2,0.69 0,1.58 -0.09,0 -0.1,-0.2 -0.2,-0.32 a 3.08,3.08 0 0 1 0,1.72 c 0,-0.06 -0.14,0 -0.1,-0.2 -0.17,1.3 0.17,2.28 -0.21,3.68 -0.37,-0.47 -0.2,0.47 -0.58,0.5 v 0.78 l 0.22,-0.28 a 12.2,12.2 0 0 1 -0.08,1.86 l -0.1,-0.52 -0.05,1.4 0.22,-0.69 c 0.12,0.7 0.48,0 0.28,0.86 0,-0.19 -0.08,0.67 -0.33,1 v 0 a 2.1,2.1 0 0 1 0,1.18 c -0.14,0.12 -0.4,-0.14 -0.49,-0.06 0.27,0.35 0,1.58 0.24,2 a 0.24,0.24 0 0 0 -0.3,-0.13 l 0.23,0.3 c -0.11,0.31 -0.15,0.35 -0.31,0.28 -0.12,0.94 0.5,-0.25 0.2,0.84 0,-0.09 -0.05,0 -0.07,-0.23 -0.21,1.11 0,2.17 -0.21,3.19 -0.39,0.28 0,-0.9 -0.37,-0.58 0,1.5 0.24,3.11 0.09,4.54 v -0.26 c 0.52,0.23 -0.32,1.05 -0.1,1.8 0,-0.18 -0.29,-0.25 -0.23,-0.2 a 7.32,7.32 0 0 0 0,1.56 c 0,0.67 0.09,1.41 0.15,2.28 l -0.13,-0.14 c -0.15,0.84 -0.14,2.05 -0.24,3 0.14,0 0.1,0.5 0.32,-0.14 a 12.08,12.08 0 0 0 -0.28,1.56 c 0,0.23 0,0.45 -0.07,0.65 V 162 c 0,0.06 0,0.05 0.07,0.07 0.66,-0.8 1.37,-1.79 1.92,-2.48 a 8.39,8.39 0 0 1 0.82,-0.91 4.08,4.08 0 0 1 0.88,-0.62 c -0.19,0.19 -0.42,0.6 -0.26,0.44 l 1.19,-1.35 c -0.25,-0.08 -0.24,0 -0.59,0.11 a 1.92,1.92 0 0 1 0.53,-0.83 c -0.37,0.56 0.26,0.27 0.55,0.17 -0.08,0 -0.06,-0.14 -0.13,-0.18 0.84,-0.21 -0.22,-0.43 0.75,-0.91 v 0.12 a 4.32,4.32 0 0 1 0.76,-0.9 c 0.31,0.09 -0.24,0.35 -0.11,0.54 0.43,-0.39 0.57,-1.12 1.15,-1.26 -0.15,0.22 -0.42,0.45 -0.57,0.66 a 1.8,1.8 0 0 0 1,-0.46 v 0 c 0.28,-0.18 0.58,-0.33 0.87,-0.49 l -0.25,0.08 c 0.17,-1 1.09,-1 1.66,-1.93 -0.55,0.9 0,0.3 0.12,0.59 0.26,-0.07 0.63,-0.2 0.58,-0.07 0.26,-0.45 0.73,-0.29 1.1,-0.91 0.08,0.07 0.43,-0.24 0.47,0 0.47,-0.37 -0.21,-0.07 -0.23,-0.2 a 3.14,3.14 0 0 1 1.39,-0.79 3.79,3.79 0 0 0 1.67,-0.91 c 1,-0.58 1,-1 2,-1.51 0.4,0 -0.17,0.42 -0.17,0.42 a 3.19,3.19 0 0 0 1.51,-0.42 c -0.09,0.11 0,0.15 0.23,0.21 0.41,-0.14 0.2,-0.44 0.8,-0.38 a 1.62,1.62 0 0 1 -0.35,0.45 c 0.47,-0.17 0.94,-0.42 1.45,-0.6 0.16,0.15 -0.28,0.31 -0.44,0.45 l 1,-0.29 a 1.11,1.11 0 0 0 0.69,-0.29 l -0.39,-0.09 c 0.22,0 0.13,0.23 0,0.28 -0.49,0.2 -0.73,0 -0.78,-0.12 l 0.37,-0.12 c -0.45,-0.49 -1.52,0.3 -2.25,0.45 0.07,-0.17 0.14,-0.34 0.22,-0.49 -0.24,0.17 -0.46,0.36 -0.69,0.54 -0.19,-0.05 -0.36,-0.25 0,-0.41 -0.59,-0.05 -0.43,0.28 -1,0.19 -0.06,0 0,-0.05 0,-0.07 l -0.49,0.27 c 0.07,-0.12 -0.19,-0.26 0.16,-0.3 -1,0.11 -1.38,0.88 -1.85,0.71 h 0.06 c -1.21,0.67 0,0.32 -0.78,1.08 l -1,-0.36 v 0.33 c -0.14,0.05 -0.4,0.16 -0.41,0 -0.37,0.42 0.14,0.07 0,0.38 -0.73,0.09 -1.54,1.06 -1.93,0.72 -0.09,0.32 0.66,-0.18 0.12,0.33 -0.47,-0.35 -0.65,0.53 -1.3,0.68 0,-0.33 0.58,-0.55 -0.08,-0.4 0,0.59 -1.07,0.6 -1.44,1 0.21,0.31 -0.84,0.78 -1.44,1.45 a 13.82,13.82 0 0 0 -2.11,1.35 v -0.06 c 0.12,0.38 -0.56,0.89 -0.95,1.37 -0.13,-0.18 -0.11,-0.32 0.07,-0.62 l -0.43,0.4 a 1.24,1.24 0 0 1 -0.35,0.64 l -0.08,-0.3 a 1.12,1.12 0 0 0 -0.26,0.33 c -0.08,0.11 -0.15,0.23 -0.23,0.35 a 1.72,1.72 0 0 1 -0.58,0.59 2,2 0 0 0 0,0.64 c 0,0.22 0,0.49 -0.47,1.1 a 2.32,2.32 0 0 1 0.29,-0.94 c 0,0.08 -0.24,0.42 -0.33,0.43 l 0.34,-0.69 c -0.19,0.06 -0.2,0.5 -0.41,0.69 0.11,-0.4 -0.06,-0.13 0.07,-0.5 0,-0.08 0.1,0 0.21,-0.22 -0.18,0.15 -0.31,0.13 -0.22,-0.18 a 4,4 0 0 1 -0.37,0.82 v 0 l -0.06,0.07 c 0,0 0,-0.05 0,-0.07 a 0.85,0.85 0 0 1 0,-0.17 1.32,1.32 0 0 1 0.1,-0.3 4.58,4.58 0 0 0 0.24,-0.66 c -0.15,0.2 0,-0.4 -0.3,0.17 a 2.9,2.9 0 0 1 0.24,-0.65 c -0.13,0 0,-1.14 -0.33,-0.48 v 0.11 0 a 4,4 0 0 1 0,-1.61 l 0.13,-0.93 a 5.4,5.4 0 0 0 0,-1 h 0.1 a 13.62,13.62 0 0 0 -0.16,-2.26 c 0,-0.23 0.2,-0.53 0.32,-0.43 a 2.87,2.87 0 0 1 0.07,-1.49 c 0.13,0.59 0.16,-0.2 0.08,0.61 a 2.89,2.89 0 0 0 0.09,-1.75 c 0.24,0.29 0.36,-0.55 0.31,-0.92 l -0.22,0.52 a 6.6,6.6 0 0 1 0.09,-1.12 l 0.31,0.22 c 0.5,-1.52 -0.45,-2.86 0.31,-4 -0.19,-0.43 -0.23,0.83 -0.47,0.44 a 9.36,9.36 0 0 1 0.67,-1.64 c 0.28,-1 -0.39,-1 -0.16,-2 -0.13,0.12 -0.46,0.21 -0.49,-0.57 -0.03,-0.78 0.59,-0.82 0.63,-0.36 0,0.17 0,0.25 -0.09,0.24 0,0.23 0,0.54 0.2,0.27 l -0.11,-0.1 c 0.15,-0.34 0.25,-1.32 0.42,-1.07 0,-0.55 -0.17,-0.25 -0.28,0.14 0.29,-0.89 0.18,-1.42 0.42,-2.35 -0.09,0.14 -0.24,0.26 -0.22,0.11 0.31,-1.35 -0.15,-0.63 -0.07,-1.57 0.25,-0.5 0.4,0.25 0.38,-0.71 0.21,-0.55 0.33,-0.07 0.4,0.17 a 4.48,4.48 0 0 1 0.5,-2 v 0.46 a 3.11,3.11 0 0 1 0.07,-0.71 l -0.28,0.22 c 0.08,-0.26 0.12,-0.48 0.22,-0.46 -0.11,-0.29 -0.43,0.14 -0.55,-0.43 0.18,-0.33 0.06,-1.09 0.39,-1.15 -0.3,1.08 0.33,-0.06 0.22,0.87 a 1.92,1.92 0 0 1 0.12,-0.65 c 0,0 0.06,0 0.06,0.12 0.48,-1 -0.26,-0.54 0,-1.62 0.15,0.17 0.38,-0.19 0.37,-0.37 -0.08,0.43 -0.33,0.15 -0.38,-0.28 0.29,-0.66 0.07,-0.77 0.16,-1.12 L 98.25,127 c -0.14,-0.17 0,-0.52 0,-1 0.14,0 0,0.46 0.09,0.3 -0.17,-0.6 0.59,-1.12 0.59,-1.9 0.21,-0.3 0.33,0.06 0.49,-0.21 0,-0.87 0.49,-0.81 0.58,-1.65 -0.15,0.07 -0.22,0.13 -0.25,0.08 a 0.49,0.49 0 0 1 0,-0.15 v -0.24 a 2,2 0 0 0 0.07,-0.39 l -0.23,1 -0.14,0.71 c 0,-0.33 0,-0.66 0,-1 -0.15,0.4 -0.14,0.92 -0.26,1.15 0,-0.48 0,-0.42 -0.26,-0.27 a 1.13,1.13 0 0 0 0.32,-0.69 c 0,-0.13 0,-0.26 0,-0.39 v -0.19 -0.11 a 1.05,1.05 0 0 0 0.06,-0.24 v 0.17 a 1,1 0 0 1 0.2,-0.3 l 0.53,0.27 c 0.67,-0.84 0.49,-1.77 1.36,-2.85 l -0.32,0.31 c -0.11,-0.28 0.42,-0.73 0.59,-1.16 0.14,0.14 0.35,-0.06 0.56,-0.16 -0.14,-0.06 0.56,-0.86 0.29,-1.18 l 0.55,-0.4 c 0.68,-0.91 0.18,-1.39 0.79,-2.29 0,0.39 0.39,0 0.15,0.74 0.19,-0.31 0.38,-0.58 0.27,-0.65 0.21,-0.12 0.27,-1 0.6,-1.2 0,-0.17 -0.16,-0.32 0.06,-0.66 0,0 0.08,0 0.08,0 0,0 0.2,-0.62 -0.17,-0.42 1.09,-0.66 1.48,-2.73 2.41,-3.33 0.32,-0.72 0.71,-1.59 1,-2.22 0,0.07 0.08,0 0,0.16 0.63,-0.79 -0.21,-0.81 0.49,-1.7 0.56,-0.36 -0.12,0.61 0.15,0.35 0.65,0.16 0.55,-1.24 1.24,-1.74 v 0.18 c 0.46,-0.41 0.43,-1.36 0.91,-2.18 0,0 0,0.07 0.08,0 A 9.69,9.69 0 0 1 112,99 c 0.1,0.36 -0.07,0.42 0.24,0.39 0.15,-0.38 -0.42,-0.08 -0.12,-0.84 0.24,-0.18 0.61,-0.65 0.89,-0.59 l -0.33,0.69 c 0.5,-0.19 0.43,-0.89 0.67,-1.23 l 0.11,0.12 c 0.48,-1.08 0.13,-1.27 0.71,-2.39 L 114,95.22 c 0,-0.79 0.45,-0.43 0.49,-1.18 H 115 c 0.12,-0.45 0.34,-1.61 0.62,-2.38 a 9.24,9.24 0 0 1 -0.3,2.08 4.78,4.78 0 0 0 0.56,-1.69 c 0,0.18 -0.06,0.43 -0.19,0.56 a 4.5,4.5 0 0 1 0.51,-2.16 c 0.31,0.23 0.6,-0.28 0.91,-0.9 l 0.24,-0.47 0.12,-0.23 0.09,-0.12 c 0.1,-0.13 0.22,-0.2 0.34,-0.11 v -0.07 c -1,-0.07 1,-0.09 0.09,-0.07 a 1.76,1.76 0 0 1 0.1,0.3 v 0.08 l 0.08,0.19 0.15,0.4 c 0.21,0.53 0.44,1.08 0.72,1.63 0.25,-0.85 0.25,0.48 0.75,0.11 0.22,0.37 0.29,0.53 0.27,0.58 l 0.24,1.33 c 0,0.36 -0.3,-0.31 -0.41,-0.21 0.37,0.87 -0.06,0.47 0.06,1.1 0.15,-0.21 0.43,0.16 0.59,0.68 l -0.08,-0.81 c 0.87,1 0,1.25 0.9,2.31 l -0.35,-0.3 c 0.4,0.57 1.09,2.27 1.82,2.66 0,0.14 -0.09,0.35 -0.26,0.1 0.64,1.5 2,3 2.33,4.31 h -0.19 c 0.17,0.26 0.48,0.36 0.51,0.77 -0.06,0 -0.19,0 -0.13,0.08 a 3,3 0 0 1 0.68,1 l -0.3,-0.23 c 0.51,1.51 1.43,2 2.1,3.17 -0.4,0.19 0,1.37 0.23,2 h -0.07 a 33.85,33.85 0 0 0 2.6,4.14 c 0,1.17 1.39,3.33 1.89,5 0,-0.27 0.33,-0.11 0.5,0.15 0.17,0.26 0.76,0.86 0.37,1 l -0.06,-0.13 c -0.23,0.44 0.22,1.14 0.49,1.72 l 0.52,-0.13 a 6.48,6.48 0 0 0 1,2.74 3.72,3.72 0 0 1 0.68,2.23 c 0.26,0.32 0.42,0.79 0.67,1.12 l -0.27,0.07 c 0.27,1.07 0.42,1.6 0.85,2.89 l -0.27,-0.21 c 0.19,0.74 1.06,0.71 1.24,1.4 l -0.36,0.32 c 0.34,1.3 0.26,2.7 0.86,3.93 a 0.27,0.27 0 0 1 -0.25,-0.23 c 0.12,0.62 0.12,2.44 0.65,2.14 -0.37,0.07 0.17,1.37 0.4,2.08 l -0.29,-0.08 a 2.62,2.62 0 0 1 0.71,1.43 c 0,0.21 -0.21,0.2 -0.16,-0.08 -0.09,0.7 0.3,0.51 0.22,1.35 l -0.2,-0.3 a 1.27,1.27 0 0 0 0.36,1 c 0.15,0.44 0,1.34 -0.26,1.45 a 1,1 0 0 1 0.32,0.88 c -0.09,0.06 -0.15,-0.09 -0.19,-0.16 -0.14,1.17 0.35,1.74 0.09,2.55 a 0.19,0.19 0 0 0 -0.16,0.13 c 0,-0.93 0,-1.68 0,-1.61 -0.26,0 -0.3,0.76 -0.66,0.17 a 5.53,5.53 0 0 1 0.5,2.35 0.47,0.47 0 0 1 -0.1,0.1 v -0.08 a 1,1 0 0 0 0,0.46 3.37,3.37 0 0 0 -0.1,0.61 c -0.21,0.08 -0.13,0.85 -0.16,1.22 0.28,0 0.21,0.47 0.47,0 0,0.06 0,-0.07 0,-0.32 a 0.41,0.41 0 0 0 0,-0.16 v 0 c 0,-0.25 0,-0.57 0,-0.93 a 1.15,1.15 0 0 1 0.08,1 5.5,5.5 0 0 1 0.43,0.54 c -0.42,0.5 -0.7,1.48 -0.94,1.6 0.05,0.57 0,1.24 0,1.87 a 4.91,4.91 0 0 0 0.07,0.88 1.93,1.93 0 0 0 0.09,0.38 1.28,1.28 0 0 0 0.15,0.25 c 0.05,0.25 -0.17,0.19 -0.25,0.2 -0.08,0.01 0,-0.24 -0.1,-0.31 a 6.22,6.22 0 0 0 0.24,1.63 c -0.11,0.16 -0.17,-0.09 -0.21,-0.22 -0.04,-0.13 -0.06,-0.21 -0.07,0.15 l -0.08,-0.29 c -0.05,0 -0.09,0 -0.11,0 -0.02,0 0,0.11 -0.08,0 -0.08,-0.11 -0.32,0 -0.72,-0.26 a 2.36,2.36 0 0 1 -0.68,-0.54 5.38,5.38 0 0 1 -0.83,-1.2 c 0.08,0.16 0.13,0.24 0.11,0.31 -1.77,-2.33 -4.49,-3.81 -6.58,-5.78 -0.64,-0.53 -0.84,-0.37 -1.34,-0.48 v -0.35 l -0.91,-0.09 c -1.14,-0.33 -1.58,-1.59 -3.21,-1.67 l 0.13,0.25 c -0.52,-0.19 -1.7,-0.36 -1.56,-0.56 a 0.35,0.35 0 0 1 -0.4,0 v -0.16 l -1.39,0.06 c -0.5,-0.14 -0.45,-0.29 -0.46,-0.44 -0.01,-0.15 -0.06,-0.32 -0.86,-0.33 -0.61,0 -1.66,0.44 -1.43,0.55 0.23,0.11 0.59,0.1 0.61,0.26 l -0.51,0.08 c -0.08,0.46 -0.37,0.93 0.77,1.27 l 0.81,-0.27 0.24,0.23 H 120 c 0.37,0.23 0.61,0 0.9,-0.07 a 0.55,0.55 0 0 0 0.3,0.3 l 0.84,-0.31 c 0.06,0.19 -0.41,0.3 0.09,0.48 0.41,-0.15 -0.27,-0.46 0.37,-0.5 0.34,0.27 0.18,0.44 0.66,0.38 0,0.14 -0.08,0.18 -0.26,0.19 0.42,0 1,0.23 1.32,0.05 0.31,0.34 1.31,0.45 1.11,0.83 a 2.46,2.46 0 0 1 1.16,0.1 c -0.84,0.15 1.25,0.69 0.82,1.1 a 1.69,1.69 0 0 1 1.21,0.34 11.84,11.84 0 0 0 1.38,0.69 c -0.06,0 -0.19,0 -0.24,-0.06 a 3.41,3.41 0 0 1 0.65,0.81 c 0.28,-0.28 1,0.1 1.49,0.2 0.26,0.7 -0.59,0.12 -0.66,0.53 0.17,-0.27 1.05,0.45 1.05,0.11 0.23,0.48 0.26,0.35 0.24,0.75 0.39,-0.32 0.4,0.24 0.9,0.28 0.36,0.65 -0.18,0.46 0.5,0.87 0.17,0.34 -0.45,0 -0.45,0 z m 7.88,-6.82 v 0 c 0,0.16 0,0.31 0,0.39 0.01,-0.08 0,-0.14 0,-0.39 z m 0,-1.61 c 0,0.2 0,0.44 0,0.7 -0.1,0.06 -0.2,0 -0.2,-0.17 0.06,0.09 0.11,-0.29 0.19,-0.53 z m -2,3.33 c 0,-0.25 0,-0.33 0.08,-0.36 0.08,-0.03 0,0.25 0,0.43 v 0 a 0.24,0.24 0 0 1 -0.08,-0.07 z"
+         id="path2125" /><path
+         class="cls-5"
+         d="m 139.61,150.93 a 0.36,0.36 0 0 1 0,0.11 1,1 0 0 0 0.07,-0.15 l -0.09,-0.09 z"
+         id="path2127" /><path
+         class="cls-5"
+         d="m 94.93,156.87 v 0 0.1 z"
+         id="path2129" /><polygon
+         class="cls-5"
+         points="137.97,125.16 137.91,125.18 138.02,125.3 "
+         id="polygon2131" /><path
+         class="cls-5"
+         d="m 98.78,156.63 a 0.27,0.27 0 0 0 0.14,0 0.28,0.28 0 0 0 -0.14,0 z"
+         id="path2133" /><path
+         class="cls-5"
+         d="m 101.67,154.24 c 0.16,-0.08 0.31,-0.17 0.48,-0.24 a 3,3 0 0 0 -0.48,0.24 z"
+         id="path2135" /><path
+         class="cls-5"
+         d="m 104.06,152.65 a 0.35,0.35 0 0 0 0,-0.13 v 0 z"
+         id="path2137" /><path
+         class="cls-5"
+         d="m 96.61,126.48 a 0.49,0.49 0 0 0 0,-0.12 c 0.02,-0.27 0,-0.09 0,0.12 z"
+         id="path2139" /><path
+         class="cls-5"
+         d="m 95.19,140.29 a 3.73,3.73 0 0 1 -0.09,-0.46 c -0.04,0.24 -0.1,0.43 0.09,0.46 z"
+         id="path2141" /><polygon
+         class="cls-5"
+         points="102.99,112.22 102.99,112.23 103.04,112.14 "
+         id="polygon2143" /><path
+         class="cls-5"
+         d="m 95.17,139.19 a 1.48,1.48 0 0 0 -0.07,0.64 2,2 0 0 0 0.07,-0.64 z"
+         id="path2145" /><path
+         class="cls-5"
+         d="m 115.25,148.23 h 0.13 z"
+         id="path2147" /><path
+         class="cls-5"
+         d="m 115.4,148.2 h 0.14 c -0.06,-0.04 -0.12,-0.03 -0.14,0 z"
+         id="path2149" /><path
+         class="cls-5"
+         d="m 115.85,148.09 -0.31,0.07 c 0.11,0 0.25,0.01 0.31,-0.07 z"
+         id="path2151" /><path
+         class="cls-5"
+         d="m 111.63,148.81 v 0.1 a 0.11,0.11 0 0 0 0,-0.1 z"
+         id="path2153" /><path
+         class="cls-5"
+         d="m 110.57,149.19 a 8.32,8.32 0 0 0 1,-0.19 v -0.09 c -0.07,0.19 -0.82,0 -1,0.28 z"
+         id="path2155" /><path
+         class="cls-5"
+         d="m 105.66,150.16 0.9,-0.43 c -0.2,0 -0.47,0 -0.09,-0.27 -1.25,0.36 0.34,0.08 -0.81,0.7 z"
+         id="path2157" /><path
+         class="cls-5"
+         d="m 103,151.7 c 0.41,-0.34 -0.1,-0.13 -0.11,-0.19 -0.24,0.27 -0.3,0.34 0.11,0.19 z"
+         id="path2159" /><path
+         class="cls-5"
+         d="m 95.45,150.52 0.25,0.07 c -0.02,-0.41 -0.1,-0.01 -0.25,-0.07 z"
+         id="path2161" /><polygon
+         class="cls-5"
+         points="94.41,146.24 94.22,146.62 94.44,146.83 "
+         id="polygon2163" /><polygon
+         class="cls-5"
+         points="96.42,143.91 96.44,144.09 96.41,143.41 "
+         id="polygon2165" /><path
+         class="cls-5"
+         d="m 107.23,109.7 h -0.33 c -0.09,0.22 0.19,0.45 0.33,0 z"
+         id="path2167" /><path
+         class="cls-5"
+         d="m 114.28,95.35 a 0.91,0.91 0 0 0 0.49,-0.77 6,6 0 0 0 -0.49,0.77 z"
+         id="path2169" /><polygon
+         class="cls-5"
+         points="134,122.24 133.77,121.99 134.1,122.5 "
+         id="polygon2171" /><path
+         class="cls-5"
+         d="m 117.61,87.57 c -0.2,-2.78 3.87,-12.2 6.06,-13.82 2.19,-1.62 4.7,-3.21 5.6,-5.84 0.47,-1.34 0.44,-6 0.34,-7.4 a 14.15,14.15 0 0 0 -1.28,-5.5 5.74,5.74 0 0 0 -4.25,-3.25 c -1.23,-0.13 -2.51,0.28 -3.68,-0.11 -1.17,-0.39 -2.05,-2.42 -2,-3.7 h -1.5 c 0,1.28 -0.86,3.31 -2,3.7 -1.14,0.39 -2.45,0 -3.68,0.11 a 5.77,5.77 0 0 0 -4.33,3.24 14.15,14.15 0 0 0 -1.28,5.5 c -0.1,1.43 -0.13,6.06 0.34,7.4 0.9,2.63 3.41,4.21 5.6,5.84 2.19,1.63 6.26,11.05 6.06,13.83 z"
+         id="path2173" /><path
+         class="cls-5"
+         d="m 117,87.52 c 0.08,0.06 0.28,0 0.24,-0.1 l -0.34,-0.09 z"
+         id="path2175" /><path
+         class="cls-5"
+         d="m 117.49,86.58 a 0.69,0.69 0 0 0 -0.77,-0.13 c 0.33,0.1 0.21,0.16 0.61,0.29 a 0.18,0.18 0 0 1 -0.2,0.24 c 0.1,0 -0.06,0.21 0.15,0.27 0.26,-0.18 0.24,-0.44 0,-0.65 0.06,-0.06 0.15,-0.03 0.21,-0.02 z"
+         id="path2177" /><path
+         class="cls-5"
+         d="m 111.68,73.27 v 0.09 a 0.19,0.19 0 0 0 0,-0.09 z"
+         id="path2179" /><path
+         class="cls-5"
+         d="m 106.4,66.91 a 0.08,0.08 0 0 0 0.08,0.08 c -0.03,-0.06 -0.06,-0.1 -0.08,-0.08 z"
+         id="path2181" /><path
+         class="cls-5"
+         d="m 106.63,65.41 v 0.09 c 0,0 0.02,-0.07 0,-0.09 z"
+         id="path2183" /><path
+         class="cls-5"
+         d="m 111.68,73.27 -0.14,-0.23 c -0.07,0.08 0.06,0.14 0.14,0.23 z"
+         id="path2185" /><path
+         class="cls-5"
+         d="m 116.28,84.86 a 0.4,0.4 0 0 0 0.12,0.1 l -0.07,-0.11 z"
+         id="path2187" /><path
+         class="cls-5"
+         d="m 114.41,76.42 v 0.06 h 0.15 z"
+         id="path2189" /><path
+         class="cls-5"
+         d="m 115.85,79.16 c 0,-0.07 -0.28,0 -0.4,0.06 a 0.25,0.25 0 0 1 0.24,0.06 0.74,0.74 0 0 0 0.16,-0.12 z"
+         id="path2191" /><path
+         class="cls-5"
+         d="m 117.17,83.89 0.07,0.07 z"
+         id="path2193" /><path
+         class="cls-5"
+         d="m 113.26,74.47 a 0.33,0.33 0 0 0 0.06,-0.08 0.16,0.16 0 0 0 -0.06,0.08 z"
+         id="path2195" /><path
+         class="cls-5"
+         d="m 119.54,84.51 h -0.05 c 0,0 0.04,0.03 0.05,0 z"
+         id="path2197" /><path
+         class="cls-5"
+         d="m 117.54,87.57 v 0 h -0.15 z"
+         id="path2199" /><path
+         class="cls-5"
+         d="m 106.92,62.67 v 0 c 0.08,0.08 0.02,0.04 0,0 z"
+         id="path2201" /><path
+         class="cls-5"
+         d="m 118.17,51.14 c 0,-0.43 0.57,0.3 0.53,-0.29 -0.06,0.15 -0.63,-0.18 -0.53,0.29 z"
+         id="path2203" /><path
+         class="cls-5"
+         d="m 116.3,84.78 v -0.12 a 0.28,0.28 0 0 0 0,0.12 z"
+         id="path2205" /><path
+         class="cls-5"
+         d="M 118.7,50.85 Z"
+         id="path2207" /><path
+         class="cls-5"
+         d="m 107.49,56.66 h -0.13 z"
+         id="path2209" /><path
+         class="cls-5"
+         d="m 106.39,61.05 v -0.11 a 0.19,0.19 0 0 0 0,0.11 z"
+         id="path2211" /><path
+         class="cls-5"
+         d="m 108.13,54.53 c 0.06,0 0.1,0 0.12,-0.11 v 0 c 0,0 -0.04,0.09 -0.12,0.11 z"
+         id="path2213" /><path
+         class="cls-5"
+         d="m 109.8,53 c 0,0 0,0 -0.07,0 v 0 z"
+         id="path2215" /><path
+         class="cls-5"
+         d="m 122.43,77.44 a 0.88,0.88 0 0 1 -0.28,0 c 0.2,0.04 0.08,0.4 0.28,0 z"
+         id="path2217" /><path
+         class="cls-5"
+         d="m 116.43,84.82 c -0.07,0 -0.11,0 -0.13,0 v 0.07 a 0.13,0.13 0 0 0 0.13,-0.07 z"
+         id="path2219" /><path
+         class="cls-5"
+         d="m 106.43,53.11 0.34,-0.36 a 2,2 0 0 0 -0.34,0.36 z"
+         id="path2221" /><path
+         class="cls-5"
+         d="m 130.79,61.33 v 0.1 a 0.13,0.13 0 0 0 0,-0.1 z"
+         id="path2223" /><path
+         class="cls-5"
+         d="m 107.82,51.69 a 0.79,0.79 0 0 0 0.35,0 0.27,0.27 0 0 0 0,-0.09 z"
+         id="path2225" /><path
+         class="cls-5"
+         d="M 122.15,77.42 Z"
+         id="path2227" /><path
+         class="cls-5"
+         d="m 121.57,80.07 c 0.16,-0.34 -0.26,-0.31 -0.42,-0.48 0.11,-0.45 0.34,-0.07 0.58,-0.13 0,-0.3 -0.17,-0.64 -0.07,-0.83 0.06,0 0.1,0 0.15,0.06 -0.12,-0.4 0.39,-0.79 0.24,-1.28 h 0.1 a 1.28,1.28 0 0 1 -0.47,-0.2 c 0.08,-0.15 0,-0.39 0.2,-0.33 -0.06,0.09 0,0.14 0.06,0.22 v -0.2 c 0.38,0 0,0.28 0.21,0.4 0.07,-0.35 0,-0.87 0.25,-1 0.32,0.13 -0.22,0.6 0.22,0.44 l -0.32,0.3 c 0.62,0 -0.15,0.2 0.49,0.23 0.34,-0.42 0.15,-0.6 0.51,-1 -0.09,-0.21 -0.25,-0.12 -0.35,-0.33 0.16,-0.8 1,0 1,-0.64 -0.09,-0.22 -0.37,-0.61 0,-0.67 a 3.79,3.79 0 0 0 0.2,0.34 c 0.3,-0.2 -0.27,-0.54 0.35,-0.67 0,0.18 -0.27,0.35 -0.17,0.34 0.47,0 0.08,-0.33 0.3,-0.49 l 0.25,0.24 c 0.43,-0.39 0.82,-1 1.3,-1.42 0,0.11 0,0.26 0.2,0.25 a 10.69,10.69 0 0 1 2.19,-1.61 v -0.45 c 0.06,0 0.2,0 0.19,0.08 0.31,-0.18 -0.13,-0.13 -0.11,-0.33 0.02,-0.2 0.29,-0.09 0.28,0.06 a 5.9,5.9 0 0 1 1.1,-2.16 v 0.15 c 0.32,-0.45 -0.33,-0.71 0.06,-1.13 v 0.11 c 0.38,-1.1 0.13,-2.15 0.62,-2.89 -0.42,-0.16 0.22,-1 -0.37,-1 0.3,-0.55 0.4,-0.39 0.6,-1.17 0,-0.22 -0.37,-0.32 -0.43,-0.57 h 0.31 l -0.33,-0.35 0.36,-0.2 -0.08,-0.24 c 0,0.1 -0.13,0.21 -0.22,0.2 a 0.93,0.93 0 0 1 0.33,-1 c -0.1,-0.32 -0.21,-0.6 -0.33,-0.9 0.13,0 0.18,0.15 0.27,0.27 -0.35,-0.46 0.32,-0.12 0,-0.54 -0.06,0.07 -0.19,0 -0.25,0 a 1.44,1.44 0 0 0 0,-1.13 h 0.22 a 10.85,10.85 0 0 0 -0.6,-2.24 0.26,0.26 0 0 1 -0.48,0.13 l 0.28,-0.18 c -0.24,-0.09 0,0.27 -0.37,0 -0.06,-0.29 0.28,-0.31 0.44,-0.18 l -0.23,-0.31 c 0.08,-0.06 0.16,0 0.29,0 -0.24,-0.07 0.06,-0.75 -0.36,-0.82 l 0.08,-0.06 a 7.26,7.26 0 0 0 -1.12,-1.63 c -0.23,0.16 -0.35,-0.1 -0.66,-0.1 A 3.69,3.69 0 0 0 127,51.67 c -0.45,-0.14 -0.24,0.12 -0.5,0.15 0.13,-0.24 -0.45,-0.53 -0.07,-0.53 a 3.57,3.57 0 0 0 -2,-0.43 c 0.09,0.11 0.19,0.19 0.12,0.26 -0.07,0.07 -0.37,-0.17 -0.34,-0.29 h 0.06 c -1.13,0.24 -2.38,-0.65 -2.88,-0.17 v 0 a 3.71,3.71 0 0 1 -0.58,0.21 c -0.22,-0.09 0.18,-0.16 0,-0.35 -0.51,0.32 -0.4,-0.25 -0.88,-0.47 0.21,-0.36 0,-0.63 -0.12,-1 l -0.12,-0.25 a 2.27,2.27 0 0 1 -0.12,-0.6 4.65,4.65 0 0 1 0.1,-1.37 l -0.17,0.25 c -0.11,-0.11 -0.07,-0.25 0,-0.42 0.07,-0.17 0,-0.13 -0.14,-0.15 0,0.13 0.18,0.2 -0.06,0.27 -0.58,0 -1.26,0 -1.88,0 h -1.69 -0.16 c 0,0.42 -0.09,0.91 -0.16,1.37 a 2.5,2.5 0 0 1 -0.17,0.63 c 0,0.08 -0.1,0.17 -0.15,0.25 a 3.8,3.8 0 0 1 -0.67,0.81 c -0.12,0.11 0,0.28 0.12,0.45 0.12,0.17 0.09,0.36 -0.14,0.24 a 1.66,1.66 0 0 0 -0.12,-0.31 0.52,0.52 0 0 1 0,0.14 c 0,0 -0.13,0.08 -0.2,0.11 a 1.75,1.75 0 0 1 -0.62,0.06 6.22,6.22 0 0 0 -1.7,0.05 c 0.08,-0.07 0.08,-0.17 0.21,-0.16 -0.25,-0.27 -1.07,0 -1,0.2 -0.22,0 -0.07,-0.17 -0.22,-0.25 -0.36,-0.1 -0.7,0.46 -0.91,0.28 0,0 0.06,-0.1 0.11,-0.14 -0.17,0.16 -0.9,0.3 -0.62,0.48 -0.54,0.1 -0.81,0.56 -1.23,0.66 0,0.39 -0.78,0.43 -0.53,0.82 -0.29,-0.37 -0.89,0.37 -0.89,0.75 0,-0.17 -0.28,0.13 -0.36,-0.08 -0.21,0.29 -0.32,0.62 -0.09,0.69 a 0.83,0.83 0 0 0 -0.52,0.78 c 0,0.3 -0.07,0.54 -0.46,0.58 A 26.2,26.2 0 0 0 104.99,58 c -0.45,-0.11 0.14,-0.94 -0.32,-1 0,0.87 0.31,1.39 0.1,2.16 -0.08,0.2 -0.18,-0.14 -0.25,-0.22 a 13.09,13.09 0 0 0 0,2.27 c 0,0 -0.09,-0.08 -0.12,-0.15 0,0.14 -0.07,0.32 0.13,0.31 v -0.13 c 0.3,-0.21 0.61,0.56 0.76,0.58 -0.58,-0.24 -0.15,0.68 -0.89,0.31 a 0.27,0.27 0 0 0 0.27,0.18 c 0,0.14 -0.12,0.18 -0.28,0 0.11,0.49 0.33,0.32 0.33,0.76 -0.1,0 -0.14,-0.09 -0.26,-0.13 a 0.89,0.89 0 0 1 0.31,0.82 c -0.06,0 -0.13,0 -0.14,-0.09 0,0.65 0.54,1.08 0.4,1.8 -0.45,-0.19 -0.13,0.25 -0.5,0.31 l 0.14,0.38 0.17,-0.17 c 0,0.34 0.32,0.61 0.23,0.92 l -0.18,-0.24 0.15,0.64 0.09,-0.39 c 0.24,0.32 0.46,-0.1 0.43,0.36 0,-0.08 0,0.32 -0.1,0.57 v 0 c 0.16,0.16 0.35,0.25 0.36,0.53 -0.09,0.11 -0.4,0.11 -0.46,0.18 0.34,0 0.44,0.73 0.85,0.74 a 0.44,0.44 0 0 0 -0.3,0.12 h 0.29 c 0,0.18 0,0.22 -0.14,0.29 0.24,0.43 0.3,-0.39 0.46,0.2 0,0 -0.06,0 -0.15,0 0.26,0.54 0.81,0.77 1.09,1.22 -0.16,0.38 -0.39,-0.27 -0.49,0.08 0.59,0.53 1.45,0.76 1.95,1.26 l -0.08,-0.11 c 0.4,-0.36 0.25,0.53 0.7,0.55 -0.1,0 -0.27,0.17 -0.22,0.13 a 4.7,4.7 0 0 0 1.56,0.78 l -0.15,0.06 a 1.5,1.5 0 0 0 0.35,0.37 2.16,2.16 0 0 1 0.3,0.32 c 0.15,-0.06 0.24,0.1 0.32,-0.12 0,1.11 1.37,1.15 1.25,2.2 0,-0.09 -0.22,-0.14 -0.18,-0.07 l 0.45,0.54 c 0.18,-0.16 0.08,-0.15 0.16,-0.37 a 0.6,0.6 0 0 1 0.45,0.29 c -0.3,-0.21 -0.33,0.18 -0.37,0.36 0,-0.06 0.14,-0.05 0.19,-0.1 -0.19,0.52 0.44,-0.16 0.43,0.41 h -0.12 c 0.14,0.13 0.37,0.22 0.43,0.41 -0.2,0.2 -0.2,-0.12 -0.4,0 0.14,0.24 0.7,0.28 0.57,0.63 -0.12,-0.08 -0.19,-0.24 -0.31,-0.31 -0.16,0.39 -0.08,0.38 0,0.59 v 0 l 0.07,0.49 v -0.15 c 0.78,0 0.41,0.61 1,0.86 -0.59,-0.25 -0.26,0 -0.55,0.12 0,0.14 0,0.35 -0.14,0.34 0.31,0.11 0,0.42 0.42,0.57 -0.09,0 0.08,0.23 -0.16,0.27 0.18,0.24 0.13,-0.12 0.25,-0.15 0.48,0.3 0,1.13 0.66,1.57 0.37,0.47 0.72,0.46 1,0.91 -0.09,0.22 -0.38,0 -0.38,0 a 0.8,0.8 0 0 0 0.23,0.73 c -0.1,0 -0.15,0 -0.23,0.16 0.08,0.19 0.38,0 0.31,0.35 A 1.41,1.41 0 0 1 116.3,85 c 0.15,0.21 0.4,0.4 0.54,0.63 -0.15,0.11 -0.28,-0.09 -0.42,-0.15 0.15,0.26 0.31,0.68 0.6,0.72 V 86 c 0,0.1 -0.21,0.1 -0.27,0 -0.26,-0.19 0,-0.36 0.1,-0.4 l 0.1,0.17 c 0.53,-0.33 -0.27,-0.71 -0.34,-1.07 h 0.45 l -0.44,-0.27 c 0.08,-0.11 0.28,-0.23 0.4,-0.07 0.11,-0.32 -0.22,-0.19 -0.07,-0.48 0,0 0.05,0 0.07,0 l -0.2,-0.22 c 0.1,0 0.27,-0.14 0.26,0 0.09,-0.54 -0.54,-0.63 -0.31,-0.91 v 0 c -0.35,-0.58 -0.31,0 -0.81,-0.3 l 0.58,-0.58 h -0.31 c 0,-0.07 0,-0.21 0.09,-0.23 -0.29,-0.16 -0.11,0.09 -0.35,0 0.14,-0.41 -0.46,-0.79 0,-1 -0.26,0 0,0.36 -0.33,0.09 0.45,-0.29 -0.24,-0.34 -0.13,-0.71 0.28,0 0.26,0.3 0.36,-0.07 -0.49,0 -0.15,-0.58 -0.33,-0.78 -0.34,0.13 -0.37,-0.45 -0.67,-0.78 0.12,0 -0.17,-0.82 -0.25,-1.23 h 0.06 c -0.37,0.1 -0.49,-0.3 -0.71,-0.52 a 0.42,0.42 0 0 1 0.47,0 l -0.14,-0.25 a 0.43,0.43 0 0 1 -0.36,-0.18 l 0.27,-0.08 c -0.2,-0.33 -0.67,-0.5 -0.77,-1 -0.23,0.12 -0.4,0.71 -0.81,0.38 0.1,-0.1 0.29,-0.24 0.41,-0.16 0,0 -0.17,-0.07 -0.18,-0.17 h 0.31 c 0,-0.25 -0.23,0 -0.31,-0.15 0.17,-0.11 0,-0.19 0.18,-0.26 0.18,-0.07 0,0.18 0.13,0.19 a 0.82,0.82 0 0 1 -0.06,-0.61 c -0.08,0.08 -0.22,0.16 -0.32,0 -0.25,-0.31 0.1,-0.25 0,-0.5 -0.17,0 -0.23,-0.28 -0.45,-0.09 -0.08,-0.09 0,-0.2 0,-0.29 -0.26,-0.09 -0.83,-0.68 -0.82,-0.27 v 0 0 c -0.68,-0.14 -1,-0.91 -1.53,-1.18 l 0.06,-0.08 c -0.37,-0.13 -0.69,-0.44 -1,-0.44 a 0.25,0.25 0 0 1 0,-0.36 c -0.27,-0.12 -0.37,-0.06 -0.56,-0.45 0.33,0.06 0,-0.17 0.3,0.1 -0.21,-0.3 -0.16,-0.47 -0.62,-0.54 0.27,-0.09 0,-0.4 -0.12,-0.47 v 0.3 a 1.35,1.35 0 0 1 -0.34,-0.38 l 0.3,-0.16 c -0.07,-0.38 -0.38,-0.5 -0.66,-0.65 -0.28,-0.15 -0.51,-0.34 -0.34,-0.72 -0.29,0 0,0.4 -0.27,0.4 -0.14,-0.31 0.17,-0.8 0.14,-0.88 0,-0.44 -0.6,-0.15 -0.57,-0.61 a 0.37,0.37 0 0 1 -0.58,-0.14 c 0,-0.35 0.44,-0.47 0.56,-0.28 0.12,0.19 0,0.12 0,0.12 0,0 0.13,0.22 0.23,0.08 h -0.12 c 0.09,-0.17 0,-0.61 0.24,-0.53 -0.14,-0.23 -0.21,-0.08 -0.25,0.11 0.13,-0.44 -0.06,-0.67 0,-1.12 -0.06,0.07 -0.2,0.15 -0.2,0.08 0.11,-0.67 -0.24,-0.28 -0.31,-0.73 0.17,-0.26 0.43,0.08 0.26,-0.37 0.12,-0.28 0.32,-0.07 0.42,0 -0.25,-0.41 0.13,-0.77 0.17,-1 l 0.09,0.22 a 0.88,0.88 0 0 1 -0.05,-0.34 l -0.24,0.12 c 0,-0.13 0,-0.23 0.14,-0.23 -0.16,-0.13 -0.39,0.1 -0.61,-0.16 0.12,-0.17 -0.13,-0.52 0.19,-0.58 -0.11,0.54 0.31,-0.06 0.36,0.4 a 0.51,0.51 0 0 1 0,-0.32 c 0,0 0.06,0 0.08,0.05 0.29,-0.51 -0.35,-0.24 -0.34,-0.77 0.18,0.07 0.34,-0.11 0.3,-0.2 0,0.21 -0.29,0.1 -0.43,-0.1 0.15,-0.34 -0.09,-0.38 -0.06,-0.55 l -0.08,0.2 c -0.17,-0.08 -0.14,-0.25 -0.19,-0.48 0.14,0 0.09,0.21 0.15,0.13 -0.3,-0.27 0.36,-0.56 0.18,-0.94 0.14,-0.15 0.34,0 0.43,-0.12 -0.19,-0.42 0.29,-0.4 0.15,-0.84 -0.25,0.09 -0.2,0.12 -0.38,-0.2 l 0.07,0.7 -0.29,-0.48 c 0,0.21 0.1,0.46 0,0.58 -0.18,-0.23 -0.12,-0.21 -0.33,-0.13 0.39,-0.24 -0.14,-0.6 0.16,-0.9 l 0.58,0.1 c 0.33,-0.43 -0.16,-0.91 0.15,-1.49 l -0.15,0.17 c -0.21,-0.14 0.07,-0.39 0,-0.61 0.18,0.08 0.29,0 0.43,-0.06 -0.14,0 0.16,-0.41 -0.18,-0.61 l 0.34,-0.15 c 0.29,-0.39 -0.27,-0.76 0,-1.16 0.11,0.24 0.34,0.13 0.32,0.47 0.07,-0.13 0.18,-0.22 0.06,-0.3 0.15,0 0,-0.51 0.27,-0.51 0,-0.1 -0.19,-0.25 0,-0.38 a 0.14,0.14 0 0 1 0.07,0.06 c -0.07,-0.06 0.08,-0.3 -0.18,-0.32 a 1.21,1.21 0 0 0 0.87,-0.47 c 0.24,-0.23 0.5,-0.45 0.81,-0.31 a 2.57,2.57 0 0 1 0.89,-0.53 c 0,0.06 0,0.09 0,0.09 0.43,0.08 0.13,-0.63 0.66,-0.49 0.28,0.29 -0.24,0.2 -0.07,0.3 0.11,0.63 0.55,-0.13 0.91,0.28 h -0.08 c 0.23,0.23 0.66,-0.2 1.14,-0.13 a 0.13,0.13 0 0 0 0,0.1 6.15,6.15 0 0 1 1.45,-0.62 c -0.1,0.28 -0.2,0.18 -0.06,0.42 0.22,-0.09 -0.13,-0.39 0.26,-0.57 0.17,0.11 0.55,0.07 0.74,0.27 a 2.35,2.35 0 0 1 -0.48,0.23 c 0.4,0.25 0.66,-0.31 0.86,-0.42 l 0.07,0.14 c 0.56,-0.57 0.22,-0.83 0.63,-1.38 h -0.14 c -0.16,-0.5 0.35,-0.16 0.25,-0.61 l 0.41,0.06 c 0,-0.27 0,-1 -0.07,-1.26 a 1.66,1.66 0 0 1 0.24,0.48 c 0,0.22 0,0.45 0.06,0.63 a 2.24,2.24 0 0 0 0.14,-0.52 c 0,-0.13 0,-0.16 0,-0.2 a 0.51,0.51 0 0 0 -0.09,-0.13 c 0,0.07 0.1,0.16 0,0.18 a 1.12,1.12 0 0 1 -0.3,-1 0.89,0.89 0 0 0 0.21,0.2 l 0.1,0.05 0.08,0.06 0.08,0.05 c 0,0 0.08,0.06 -0.11,0.32 0,0 0,-0.08 0,0 a 0.67,0.67 0 0 1 0,0.38 3.17,3.17 0 0 0 0.35,1.22 c 0.37,-0.6 0.16,0.28 0.67,-0.07 0.15,0.18 0.2,0.26 0.17,0.3 a 3.71,3.71 0 0 0 0.17,0.83 c 0,0.26 -0.27,-0.11 -0.36,0 0.37,0.51 0,0.37 0.2,0.82 0.08,-0.23 0.36,-0.06 0.72,0.24 a 2.05,2.05 0 0 1 -0.32,-0.57 1.49,1.49 0 0 1 0.77,0.58 0.75,0.75 0 0 0 0.82,0.31 l -0.32,0.14 c 0.52,0 1.64,0.14 1.93,-0.39 0.06,0.07 0.15,0.23 0,0.28 0.84,0 1.64,-0.63 2,-0.2 l -0.08,0.14 c 0.11,0 0.26,-0.23 0.35,0 0.09,0.23 -0.09,0.13 0,0.15 0.09,0.02 0.37,-0.14 0.47,0 l -0.18,0.09 c 0.41,0.41 1,0.09 1.52,0.41 -0.29,0.33 0,0.77 0,1 v 0 c 0.39,0.58 1,0.8 1.45,1.45 -0.26,0.59 0.3,1.56 0.16,2.38 0.05,-0.13 0.34,0 0.4,0.09 0.06,0.09 0.38,0.47 0,0.49 V 59 c -0.37,0.19 -0.22,0.55 -0.2,0.85 h 0.53 a 1.53,1.53 0 0 0 -0.14,1.39 c 0.09,0.47 0.19,0.91 -0.15,1.13 0.13,0.19 0.13,0.43 0.26,0.62 h -0.28 a 5.24,5.24 0 0 0 -0.07,1.46 l -0.2,-0.14 c 0,0.36 0.81,0.49 0.81,0.84 l -0.43,0.08 c 0,0.65 -0.45,1.25 -0.16,1.86 -0.06,0 -0.18,0 -0.18,-0.15 a 4.44,4.44 0 0 1 -0.17,0.48 0.28,0.28 0 0 0 0.24,0.41 c -0.35,-0.14 -0.25,0.5 -0.28,0.86 l -0.22,-0.19 c 0.18,0.41 0.24,0.47 0.11,0.85 -0.09,0 -0.23,-0.07 -0.1,-0.12 -0.3,0.15 0.07,0.35 -0.29,0.55 v -0.22 c -0.22,0.23 -0.13,0.27 -0.09,0.54 a 0.52,0.52 0 0 1 -0.7,0.25 c 0.08,0.14 0.09,0.41 -0.1,0.49 -0.19,0.08 -0.07,-0.14 -0.07,-0.19 -0.53,0.22 -0.41,0.79 -0.88,0.82 a 0.21,0.21 0 0 0 -0.16,-0.09 4.55,4.55 0 0 1 0.62,-0.45 c -0.17,-0.2 -0.46,0 -0.48,-0.46 -0.08,0.32 -0.2,1 -0.55,1.08 a 0.2,0.2 0 0 1 -0.09,0 v 0 a 0.26,0.26 0 0 0 -0.15,0.17 0.86,0.86 0 0 0 -0.28,0.11 c -0.16,-0.15 -0.4,0.15 -0.56,0.25 0.18,0.22 0,0.32 0.28,0.38 0,0 0,0 0.1,-0.13 a 0.13,0.13 0 0 0 0,-0.07 v 0 l 0.35,-0.29 c 0,0.2 -0.08,0.39 -0.33,0.38 0,0.21 0.05,0.42 0.06,0.52 -0.44,-0.17 -1,0 -1.15,-0.2 -0.1,0.12 -0.19,0.2 -0.33,0.36 -0.14,0.16 -0.28,0.32 -0.4,0.48 a 1.21,1.21 0 0 0 -0.2,0.94 c 0,0.17 -0.23,0.06 -0.33,0.06 -0.1,0 0.09,-0.2 0.06,-0.29 -0.09,0.36 -0.55,0.86 -0.27,1.13 -0.36,0.26 -0.16,-0.39 -0.42,0.13 l -0.05,-0.12 c -1.12,0.68 -0.1,2 -1.32,2.76 0.08,-0.06 0.12,-0.09 0.18,-0.07 -0.93,1.11 -0.92,2.72 -1.9,3.8 -0.25,0.33 0,0.46 0,0.74 h -0.31 l 0.19,0.5 c 0.05,0.62 -1,0.73 -0.78,1.59 h 0.22 c -0.1,0.25 -0.11,0.84 -0.32,0.74 0,0 0.19,0.14 0.06,0.21 h -0.15 l 0.12,0.7 c -0.18,0.5 -0.6,-0.2 -0.74,0.6 0,0.34 0.43,0.92 0.53,0.78 0.1,-0.14 0.11,-0.31 0.27,-0.31 l 0.07,0.25 c 0.47,0 0.94,0.09 1.28,-0.32 a 2,2 0 0 1 -0.26,-0.36 l 0.25,-0.09 v 0.3 c 0.23,-0.15 0.06,-0.27 -0.05,-0.41 a 0.48,0.48 0 0 0 0.27,-0.11 5.63,5.63 0 0 1 -0.36,-0.46 c 0.18,0 0.31,0.24 0.47,0 -0.17,-0.22 -0.44,0.08 -0.51,-0.24 0.25,-0.14 0.4,0 0.28,-0.3 a 0.2,0.2 0 0 1 0.21,0.16 c -0.09,-0.23 0.08,-0.52 -0.13,-0.69 0.3,-0.12 0.13,-0.67 0.55,-0.52 a 1,1 0 0 1 -0.18,-0.63 c 0.38,0.49 0.25,-0.65 0.76,-0.38 -0.37,-0.39 0.11,-0.92 0,-1.43 0,0 0.08,0.11 0,0.14 0.13,-0.22 0.29,-0.24 0.43,-0.36 -0.35,-0.17 -0.28,-0.57 -0.42,-0.86 0.47,-0.14 0.35,0.35 0.73,0.4 -0.3,-0.11 -0.09,-0.62 -0.37,-0.63 0.31,-0.12 0.19,-0.14 0.53,-0.12 -0.43,-0.24 0,-0.24 -0.18,-0.54 0.37,-0.21 0.46,0.11 0.48,-0.29 0.6,-0.21 0.62,0.16 0.62,0.16 z m 4.56,-7.2 v 0 L 126,73 Z m 0.62,-0.5 -0.28,0.21 c -0.08,-0.06 -0.12,-0.16 0,-0.2 0.12,-0.04 0.13,0 0.28,-0.01 z m -2.48,-0.55 c 0.07,-0.1 0.13,-0.08 0.18,0 a 2.09,2.09 0 0 0 -0.15,0.15 v 0 a 0.42,0.42 0 0 1 -0.03,-0.15 z"
+         id="path2229" /><path
+         class="cls-5"
+         d="m 124.31,72.25 h 0.1 v -0.09 z"
+         id="path2231" /><path
+         class="cls-5"
+         d="m 111.74,73.37 v 0 c 0,0 0,0 0,0 0,0 0,0.01 0,0 z"
+         id="path2233" /><polygon
+         class="cls-5"
+         points="130.95,62.21 130.88,62.22 130.94,62.28 "
+         id="polygon2235" /><path
+         class="cls-5"
+         d="m 113.5,77.4 a 0.1,0.1 0 0 0 0,0.08 0.56,0.56 0 0 0 0,-0.08 z"
+         id="path2237" /><path
+         class="cls-5"
+         d="m 114.26,79 v 0.27 a 1.76,1.76 0 0 0 0,-0.27 z"
+         id="path2239" /><path
+         class="cls-5"
+         d="m 114.72,80.36 h 0.12 v 0 z"
+         id="path2241" /><path
+         class="cls-5"
+         d="m 104.5,61.07 a 0.13,0.13 0 0 0 0,-0.06 c -0.06,-0.13 -0.04,-0.01 0,0.06 z"
+         id="path2243" /><path
+         class="cls-5"
+         d="m 105.5,67.9 a 1.8,1.8 0 0 1 -0.19,-0.2 c 0.01,0.13 0.04,0.3 0.19,0.2 z"
+         id="path2245" /><polygon
+         class="cls-5"
+         points="106.43,53.11 106.39,53.16 "
+         id="polygon2247" /><path
+         class="cls-5"
+         d="m 105.25,67.36 a 0.47,0.47 0 0 0 0.06,0.34 0.58,0.58 0 0 0 -0.06,-0.34 z"
+         id="path2249" /><path
+         class="cls-5"
+         d="m 116.55,86 v 0.07 0 z"
+         id="path2251" /><path
+         class="cls-5"
+         d="m 116.6,86.09 0.05,0.07 c 0,0 -0.02,-0.06 -0.05,-0.07 z"
+         id="path2253" /><path
+         class="cls-5"
+         d="m 116.75,86.29 -0.1,-0.13 c 0,0 0.01,0.11 0.1,0.13 z"
+         id="path2255" /><path
+         class="cls-5"
+         d="m 116.21,84.26 h -0.11 a 0.26,0.26 0 0 0 0.11,0 z"
+         id="path2257" /><path
+         class="cls-5"
+         d="m 116,83.75 c 0,0.13 -0.11,0.38 0,0.53 h 0.08 c -0.15,-0.04 0.13,-0.47 -0.08,-0.53 z"
+         id="path2259" /><path
+         class="cls-5"
+         d="m 116.36,81.09 0.1,0.48 c 0.07,-0.12 0.17,-0.28 0.27,-0.08 0.08,-0.69 -0.18,0.2 -0.37,-0.4 z"
+         id="path2261" /><path
+         class="cls-5"
+         d="m 115.92,79.65 c 0.15,0.22 0.14,-0.07 0.2,-0.08 -0.12,-0.11 -0.19,-0.13 -0.2,0.08 z"
+         id="path2263" /><path
+         class="cls-5"
+         d="m 109.24,71.2 0.18,-0.18 c -0.17,-0.09 -0.06,0.08 -0.18,0.18 z"
+         id="path2265" /><polygon
+         class="cls-5"
+         points="106.84,70.73 106.86,70.99 107.1,70.9 "
+         id="polygon2267" /><path
+         class="cls-5"
+         d="m 107.59,68.7 h 0.08 a 1.41,1.41 0 0 1 -0.23,-0.18 z"
+         id="path2269" /><path
+         class="cls-5"
+         d="m 109.6,53.44 -0.22,-0.24 c -0.06,0.12 0.13,0.41 0.22,0.24 z"
+         id="path2271" /><path
+         class="cls-5"
+         d="m 116.71,50.88 a 0.33,0.33 0 0 0 0.33,-0.4 c -0.11,0.18 -0.31,0.29 -0.33,0.4 z"
+         id="path2273" /><polygon
+         class="cls-5"
+         points="128.34,60.28 128.22,60.14 128.34,60.41 "
+         id="polygon2275" /><path
+         class="cls-6"
+         d="m 111.18,52.27 a 5.84,5.84 0 0 1 2.9,2.63 3.2,3.2 0 0 0 0.71,0.92 2.48,2.48 0 0 0 1,0.37 5.57,5.57 0 0 0 4.2,-0.79 3.76,3.76 0 0 0 1.6,-3.75 8.74,8.74 0 0 0 -1.67,-3.42 c -0.85,-0.89 -1.8,-6 -3,-6.45 a 7.61,7.61 0 0 0 -5.05,0.42 c -1.6,0.6 -3.15,6.5 -4.26,7.76 -0.66,0.74 -2.12,2.63 -0.65,2.91 1.47,0.28 2.58,-1.17 4.22,-0.6 z"
+         id="path2277" /><path
+         class="cls-6"
+         d="m 123.25,52.27 a 5.82,5.82 0 0 0 -2.89,2.63 3.23,3.23 0 0 1 -0.72,0.92 2.42,2.42 0 0 1 -1,0.37 5.57,5.57 0 0 1 -4.2,-0.79 3.78,3.78 0 0 1 -1.59,-3.75 8.59,8.59 0 0 1 1.66,-3.42 c 0.86,-0.89 1.81,-6 3,-6.45 a 7.61,7.61 0 0 1 5,0.42 c 1.59,0.6 3.14,6.5 4.26,7.76 0.66,0.74 2.11,2.63 0.65,2.91 -1.46,0.28 -2.53,-1.17 -4.17,-0.6 z"
+         id="path2279" /><polyline
+         class="cls-7"
+         points="117.18 100.95 116.88 101.66 116.63 102.39 116.5 103.16 116.09 103.84 116.01 104.62 115.72 105.35 115.63 106.12 115.29 106.84 115.34 107.63 115.31 108.41 114.99 109.14 114.96 109.92 114.85 110.69 114.98 111.47 114.86 112.24 114.67 113 114.81 113.78 114.86 114.55 114.81 115.32 114.67 116.09 114.84 116.87 114.59 117.64 114.52 118.42 114.56 119.19 114.64 119.96 114.87 120.73 114.78 121.5 114.59 122.28 114.66 123.05 114.82 123.83 114.64 124.6 114.73 125.38 114.74 126.15 114.72 126.93 114.75 127.7 114.93 128.48 114.84 129.25 114.97 130.03 114.78 130.8 114.69 131.57 114.85 132.34 114.85 133.12 114.81 133.9 114.98 134.67 114.9 135.44 114.82 136.22 115 137 114.99 137.77 114.91 138.55 114.9 139.33 114.96 140.11 114.8 140.89 115.09 141.67 114.82 142.46 115.13 143.24 115.08 144.02 115.03 144.8 115.12 145.58 115.08 146.36 115.1 147.15 114.9 147.93 114.89 148.71 115.11 149.49 115.12 150.27 115.07 151.05 115.21 151.82 114.98 152.6 115.18 153.37 115.14 154.16 114.93 154.94 114.95 155.71 115.13 156.48 115.25 157.25 115.17 158.02"
+         id="polyline2281" /><polyline
+         class="cls-7"
+         points="118.55 101.23 118.79 101.97 118.98 102.71 119.21 103.44 119.46 104.17 119.55 104.94 119.67 105.7 119.84 106.45 119.9 107.21 120.05 107.97 120.14 108.73 120.06 109.51 120.15 110.27 120.26 111.03 120.18 111.81 120.32 112.57 120.32 113.34 120.22 114.11 120.32 114.88 120.31 115.65 120.35 116.43 120.37 117.2 120.26 117.98 120.4 118.75 120.28 119.53 120.43 120.3 120.44 121.08 120.33 121.85 120.42 122.63 120.46 123.4 120.46 124.18 120.42 124.95 120.36 125.73 120.36 126.5 120.47 127.28 120.52 128.05"
+         id="polyline2283" /><polygon
+         class="cls-8"
+         points=""
+         id="polygon2447" /><polygon
+         class="cls-9"
+         points=""
+         id="polygon2541" /><polyline
+         class="cls-3"
+         points="99.81 79.38 100.36 79.91 100.98 80.35 101.64 80.73 102.09 81.38 102.82 81.67 103.48 82.06 103.99 82.64 104.64 83.04 105.1 83.71 105.82 84.02 106.3 84.64 106.97 85.01 107.54 85.52 108.05 86.1 108.77 86.41 109.25 87.02 109.95 87.36 110.59 87.78"
+         id="polyline2671" /><polyline
+         class="cls-3"
+         points="133.47 79.42 132.84 79.77 132.36 80.33 131.96 80.97 131.44 81.5 130.74 81.86 130.31 82.49 129.69 82.92 129.05 83.31 128.39 83.8 127.8 84.38 127.27 85.02 126.53 85.45 126.08 86.16 125.54 86.79 124.84 87.26 124.22 87.81"
+         id="polyline2673" /><polyline
+         class="cls-10"
+         points="110 64.79 110.8 65.13 110.82 66.04 111.49 66.46 112.17 66.85 112.51 67.54 112.95 68.18 113.8 68.27 114.37 68.72 115.03 69.27 115.94 69.1 116.72 69.28 117.52 69.63 118.35 69.57 119.17 69.41 119.85 69.48 120.48 69.25 121.18 69.31 122.02 68.88 122.66 68.18 123.4 67.95 123.95 67.47 124.35 66.81 125.06 66.54 125.68 66.16 126.12 65.55"
+         id="polyline2679" /><ellipse
+         class="cls-8"
+         cx="117.56"
+         cy="95.370003"
+         rx="10.73"
+         ry="11.11"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2681" /><ellipse
+         class="cls-8"
+         cx="117.56"
+         cy="95.370003"
+         rx="10.73"
+         ry="11.11"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2683" /><ellipse
+         class="cls-8"
+         cx="117.56"
+         cy="95.370003"
+         rx="6.8099999"
+         ry="7.0500002"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2685" /><ellipse
+         class="cls-8"
+         cx="117.56"
+         cy="95.370003"
+         rx="6.8099999"
+         ry="7.0500002"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2687" /><ellipse
+         class="cls-8"
+         cx="117.56"
+         cy="95.370003"
+         rx="3.6700001"
+         ry="3.8"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2689" /><ellipse
+         class="cls-8"
+         cx="117.56"
+         cy="95.370003"
+         rx="3.6700001"
+         ry="3.8"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2691" /><ellipse
+         class="cls-8"
+         cx="117.56"
+         cy="95.370003"
+         rx="10.73"
+         ry="11.11"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2693" /><ellipse
+         class="cls-3"
+         cx="117.56"
+         cy="95.370003"
+         rx="10.73"
+         ry="11.11"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2695" /><ellipse
+         class="cls-8"
+         cx="117.56"
+         cy="95.370003"
+         rx="6.8099999"
+         ry="7.0500002"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2697" /><ellipse
+         class="cls-3"
+         cx="117.56"
+         cy="95.370003"
+         rx="6.8099999"
+         ry="7.0500002"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2699" /><ellipse
+         class="cls-8"
+         cx="117.56"
+         cy="95.370003"
+         rx="3.6700001"
+         ry="3.8"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2701" /><ellipse
+         class="cls-3"
+         cx="117.56"
+         cy="95.370003"
+         rx="3.6700001"
+         ry="3.8"
+         transform="rotate(-64.5,117.56016,95.369607)"
+         id="ellipse2703" /><polyline
+         class="cls-11"
+         points="65.21 141.73 66.22 141.55 65.61 140.08 65.61 139.19 67.05 139.2 66.89 138.24 68.01 137.95 67.75 136.97 68.07 136.28 69.06 135.87 68.6 134.85 68.94 134.16 69 133.36 70.42 133.15 70.81 132.51 70.39 131.48 70.59 130.73 70.83 129.98 71 129.18 71.51 128.58 71.95 127.9 72.67 127.45 73.26 126.91 74.55 127.09 74.17 125.57 75.01 125.31 75.81 125.02 75.96 123.98 77.22 124.25 77.6 123.47 77.67 122.3 78.05 121.52 79.63 122.19 79.34 120.6 80.47 120.72 80.76 119.84 81.36 119.34 81.61 118.47 82.48 118.24 83.79 118.39 84.6 118.01 85.04 117.28 84.99 116.24 85.27 115.47 84.94 114.42 85.37 113.81 85.85 113.2 87.28 112.86 86.67 111.85 87.59 111.27 86.18 110.17 87.68 109.66 87.29 108.8 86.56 107.94 87.53 107.27 87.66 106.49 86.87 105.66 86.81 104.89 88.06 104.17 88.71 103.42 87.97 102.61 87.35 101.8 86.87 101 88.28 100.28 86.88 99.42 88.7 98.75 87.3 97.86 87.79 97.11 88.57 96.41 88.11 95.56 88.8 94.88 87.89 93.92 89.28 93.41 89.13 92.58 88.83 91.69 90.14 91.3 90.54 90.66 90.26 89.73 90.93 89.22 89.66 87.67 91.14 87.6"
+         id="polyline2705" /><polyline
+         class="cls-11"
+         points="155.83 116.11 156.74 116.57 156.66 117.47 156.84 118.25 157.14 118.98 157.15 119.82 157.61 120.49 158.23 121.12 158 122.03 158.94 122.57 158.36 123.56 158.51 124.33 159.37 124.94 159.38 125.74 159.29 126.56 159.63 127.31 160.1 128.04 159.64 128.9 159.56 129.69 160.32 130.41 160.04 131.23 159.6 132.04 159.87 132.81 160.64 133.58 160.16 134.38 159.72 135.17 160.39 135.96 160.35 136.75 160.25 137.54 160.15 138.32 160.02 139.11 159.58 139.88 159.72 140.68 159.65 141.47 159.66 142.27"
+         id="polyline2707" /><polygon
+         class="cls-9"
+         points=""
+         id="polygon2779" /></g></g><style
+     id="style11499"
+     type="text/css">
+	.st0{fill:#084272;}
+	.st1{fill:#FFFFFF;}
+	.st2{fill:#2B66A1;}
+	.st3{fill:#3DA7E3;}
+	.st4{fill:#24323D;}
+</style><style
+     id="style15137"
+     type="text/css">
+	.st0{fill:#FFDEF9;}
+	.st1{fill:#955E88;}
+	.st2{fill:#6B3763;}
+	.st3{fill:#FFFFFF;}
+</style></svg>
diff --git a/summary/src/introduction/img/ct.pdf b/summary/src/introduction/img/ct.pdf
new file mode 100644
index 0000000..bb14266
--- /dev/null
+++ b/summary/src/introduction/img/ct.pdf
diff --git a/summary/src/introduction/img/ct.svg b/summary/src/introduction/img/ct.svg
new file mode 100644
index 0000000..bd4641f
--- /dev/null
+++ b/summary/src/introduction/img/ct.svg
@@ -0,0 +1,1346 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   width="1003.7013"
+   height="354.44708"
+   viewBox="0 0 265.56264 93.780796"
+   version="1.1"
+   id="svg8"
+   inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
+   sodipodi:docname="ct.svg"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:xlink="http://www.w3.org/1999/xlink"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:dc="http://purl.org/dc/elements/1.1/">
+  <defs
+     id="defs2">
+    <marker
+       inkscape:stockid="TriangleInM"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="TriangleInM"
+       style="overflow:visible"
+       inkscape:isstock="true"
+       viewBox="0 0 4.2595265 4.9243081"
+       markerWidth="4.2595263"
+       markerHeight="4.9243078"
+       preserveAspectRatio="xMidYMid">
+      <path
+         id="path8135"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="scale(-0.4)" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker9036"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM"
+       viewBox="0 0 4.2595265 4.9243081"
+       markerWidth="4.2595263"
+       markerHeight="4.9243083"
+       preserveAspectRatio="xMidYMid">
+      <path
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path9034" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8855"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8853" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8597"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend">
+      <path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8595" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8428"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend">
+      <path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8426" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8265"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend">
+      <path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8263" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8188"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend">
+      <path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8186" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8025"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend">
+      <path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path8023" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker7874"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend">
+      <path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path7872" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Mend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker7717"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path7715"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="scale(-0.6)" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker7417"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend">
+      <path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path7415" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker7290"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Mend">
+      <path
+         transform="scale(-0.6)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path7288" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker7034"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend">
+      <path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path7032" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6925"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"
+       viewBox="0 0 8.886927 5.078244"
+       markerWidth="8.8869267"
+       markerHeight="5.0782437"
+       preserveAspectRatio="xMidYMid">
+      <path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6923" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6915"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend">
+      <path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6913" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6703"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend">
+      <path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path6701" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6612"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend">
+      <path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path6610" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6602"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend">
+      <path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path6600" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6428"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6426" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6355"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6353" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6288"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6286" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Mend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Mend"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5633"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="matrix(-0.4,0,0,-0.4,-4,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Send"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Send"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5639"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="matrix(-0.2,0,0,-0.2,-1.2,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Torso"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Torso"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <g
+         id="g5850"
+         transform="scale(0.7)"
+         style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-opacity:1">
+        <path
+           id="path5836"
+           d="m -4.7792281,-3.239542 c 2.350374,0.3659393 5.30026732,1.9375477 5.03715532,3.62748546 C -0.00518779,2.0778819 -2.2126741,2.6176539 -4.5630471,2.2517169 -6.9134221,1.8857769 -8.521035,0.75201414 -8.257922,-0.93792336 -7.994809,-2.6278615 -7.1296041,-3.6054813 -4.7792281,-3.239542 Z"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-opacity:1" />
+        <path
+           id="path5838"
+           d="M 4.4598789,0.08866574 C -2.5564571,-4.378332 5.2248769,-3.9061806 -0.84829578,-8.7197331"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" />
+        <path
+           id="path5840"
+           d="M 4.9298719,0.05752074 C -1.3872731,1.7494689 1.8027579,5.4782079 -4.9448731,7.5462725"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" />
+        <rect
+           id="rect5842"
+           transform="matrix(0.527536,-0.849533,0.887668,0.460484,0,0)"
+           y="-1.7408575"
+           x="-10.391706"
+           height="2.7608147"
+           width="2.6366582"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" />
+        <rect
+           id="rect5844"
+           transform="matrix(0.671205,-0.741272,0.790802,0.612072,0,0)"
+           y="-7.9629307"
+           x="4.9587269"
+           height="2.8614161"
+           width="2.7327356"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" />
+        <path
+           id="path5846"
+           transform="matrix(0,-1.109517,1.109517,0,25.96648,19.71619)"
+           d="m 16.779951,-28.685045 a 0.60731727,0.60731727 0 1 0 -1.214634,0 0.60731727,0.60731727 0 1 0 1.214634,0 z"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" />
+        <path
+           id="path5848"
+           transform="matrix(0,-1.109517,1.109517,0,26.8245,16.99126)"
+           d="m 16.779951,-28.685045 a 0.60731727,0.60731727 0 1 0 -1.214634,0 0.60731727,0.60731727 0 1 0 1.214634,0 z"
+           style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" />
+      </g>
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Send"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Send"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5657"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-0.3,0,0,-0.3,0.69,0)" />
+    </marker>
+    <style
+       id="style979">.cls-1{fill:#627a83;}.cls-2{fill:#062b31;}.cls-3{fill:#819096;stroke:#062b31;stroke-miterlimit:10;stroke-width:6.5px;}</style>
+    <linearGradient
+       id="linearGradient-1"
+       y2="0"
+       x2="0.5"
+       y1="1"
+       x1="0.5">
+      <stop
+         id="stop1116"
+         offset="0%"
+         stop-color="#420C5D" />
+      <stop
+         id="stop1118"
+         offset="100%"
+         stop-color="#951AD1" />
+    </linearGradient>
+    <path
+       id="path-2"
+       d="M 25,29 C 152.57778,29 256,131.97451 256,259 256,386.02549 152.57778,489 25,489 Z" />
+    <filter
+       id="filter-3"
+       filterUnits="objectBoundingBox"
+       height="1.148"
+       width="1.2939999"
+       y="-0.074000001"
+       x="-0.18200001">
+      <feOffset
+         id="feOffset1122"
+         result="shadowOffsetOuter1"
+         in="SourceAlpha"
+         dy="0"
+         dx="-8" />
+      <feGaussianBlur
+         id="feGaussianBlur1124"
+         result="shadowBlurOuter1"
+         in="shadowOffsetOuter1"
+         stdDeviation="10" />
+      <feColorMatrix
+         id="feColorMatrix1126"
+         in="shadowBlurOuter1"
+         type="matrix"
+         values="0 0 0 0 0.250980392   0 0 0 0 0.250980392   0 0 0 0 0.250980392  0 0 0 0.2 0" />
+    </filter>
+    <style
+       id="style11378">.cls-1{fill:none;stroke:#000;stroke-linejoin:round;stroke-width:2px;}</style>
+    <font
+       horiz-adv-x="576"
+       id="tor-icons"
+       horiz-origin-x="0"
+       horiz-origin-y="0"
+       vert-origin-x="512"
+       vert-origin-y="768"
+       vert-adv-y="1024">
+      <font-face
+         id="font-face14955"
+         descent="0"
+         ascent="512"
+         units-per-em="512"
+         font-family="tor-icons" />
+      <missing-glyph
+         id="missing-glyph14957"
+         horiz-adv-x="0" />
+      <glyph
+         id="glyph14959"
+         d=" M458.622 256.0800000000001L504.607 301.0850000000001C518.315 314.062 511.923 337.124 493.943 341.424L431.2930000000001 357.414L448.9540000000001 419.4290000000001C453.9450000000001 437.2670000000001 437.1250000000001 454.092 419.2930000000001 449.1L357.2990000000001 431.433L341.3150000000001 494.104C337.085 511.803 313.765 518.276 300.99 504.772L256 458.43L211.011 504.771C198.381 518.122 174.964 512.005 170.686 494.103L154.702 431.432L92.707 449.099C74.87 454.093 58.056 437.262 63.046 419.428L80.707 357.413L18.057 341.423C0.069 337.122 -6.31 314.0560000000001 7.392 301.0850000000001L53.377 256.0800000000001L7.392 211.076C-6.316 198.0990000000001 0.076 175.037 18.056 170.737L80.706 154.747L63.045 92.732C58.054 74.894 74.874 58.069 92.706 63.061L154.7 80.7280000000001L170.684 18.0570000000001C175.123 -0.5179999999999 198.38 -5.9609999999999 211.009 7.3890000000001L256 53.39L300.989 7.389C313.489 -6.0989999999999 336.976 -0.097 341.314 18.057L357.298 80.728L419.2919999999999 63.061C437.128 58.067 453.9429999999999 74.898 448.9529999999999 92.732L431.2919999999999 154.747L493.9419999999999 170.737C511.9289999999999 175.0390000000001 518.3079999999999 198.1040000000001 504.6059999999999 211.076L458.6219999999999 256.0800000000001z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="authority" />
+      <glyph
+         id="glyph14961"
+         d=" M256 504C119.034 504 8 392.967 8 256S119.034 8 256 8S504 119.034 504 256S392.967 504 256 504zM386.108 386.108C451.556 320.6600000000001 456.108 220.627 406.7850000000001 150.471L150.47 406.784C220.674 456.14 320.6960000000001 451.519 386.108 386.108zM125.892 125.892C60.444 191.34 55.892 291.373 105.215 361.529L361.53 105.216C291.327 55.86 191.304 60.48 125.892 125.892z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="badexit" />
+      <glyph
+         id="glyph14963"
+         d=" M16 368L16 115.3684208L86.2866667199996 115.3684208C111 188.9473680000001 177.6333328000001 241.6842105599999 256 241.6842105599999C334.3666672 241.6842105599999 401 188.9473680000001 425.7133328 115.3684208L496 115.3684208L496 368L16 368z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="bridge" />
+      <glyph
+         id="glyph14965"
+         d=" M172.268 10.33C26.97 220.969 0 242.587 0 320C0 426.039 85.961 512 192 512S384 426.039 384 320C384 242.587 357.03 220.969 211.732 10.33C202.197 -3.444 181.802 -3.443 172.268 10.33z"
+         horiz-adv-x="384"
+         unicode=""
+         glyph-name="country" />
+      <glyph
+         id="glyph14967"
+         d=" M452.9230767999998 352C459.0403071999999 352 464 356.8357 464 362.8L464 398.8C464 404.7643000000001 459.0403071999999 409.6 452.9230767999998 409.6L434.4615392000001 409.6L434.4615392000001 452.8C434.4615392000001 476.659 414.6246160000001 496 390.1538464 496L124.3076923200001 496C99.8369230399999 496 80 476.659 80 452.8L80 78.4C80 54.5409999999999 99.8369230399999 35.2 124.3076923200001 35.2L390.1538464 35.2C414.6246160000001 35.2 434.4615392000001 54.5409999999999 434.4615392000001 78.4L434.4615392000001 121.6L452.9230767999998 121.6C459.0403071999999 121.6 464 126.4356992000001 464 132.4L464 168.4C464 174.3643008 459.0403071999999 179.2000000000001 452.9230767999998 179.2000000000001L434.4615392000001 179.2000000000001L434.4615392000001 236.8L452.9230767999998 236.8C459.0403071999999 236.8 464 241.6356992 464 247.6L464 283.6C464 289.5643008 459.0403071999999 294.4 452.9230767999998 294.4L434.4615392000001 294.4L434.4615392000001 352L452.9230767999998 352z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="directory" />
+      <glyph
+         id="glyph14969"
+         d=" M296.5909877987965 115.1547656932976L249.7182730611699 115.1547656932976L249.7182730611699 191.4505156032526L155.9728736919687 191.4505156032526L155.9728736919687 115.1547656932976L109.1001683624834 115.1547656932976L202.8455771398258 13.427099146691z M385.5550693190428 315.6303325759527C385.5550693190428 275.9530447882323 352.5320764727 243.7877778650137 311.7967082319215 243.7877778650137H99.7414234591009C53.9138567562077 243.7877778650137 16.7632675713548 279.9734118919249 16.7632675713548 324.6106644872678C16.7632675713548 359.8432583489403 39.9112912172481 389.8049741187648 72.199590439413 400.8687282818329C72.121641262355 402.3891395527968 72.0824152248678 403.9112204448434 72.0820799595901 405.4335360225843C72.0820380514303 455.0307215753485 113.3602141873657 495.2367361165633 164.2799894103319 495.2367361165633C198.4439369337201 495.2367361165633 228.2665209659647 477.1369020008461 244.194873728423 450.2458943198008C252.9830651091063 455.973655168792 263.5489503348364 459.3154570847676 274.917527688361 459.3154570847676C305.4690622505769 459.3154570847676 330.2362985037019 435.1915110831694 330.2362985037019 405.4335360225844C330.2362985037019 398.5950228690864 328.9254112680172 392.0551053535121 326.5397473684459 386.0360459153656C360.2104392047168 379.3827517408421 385.5550693190429 350.3897883434942 385.5550693190429 315.6303325759525z"
+         horiz-adv-x="402.31833320247944"
+         unicode=""
+         glyph-name="exit" />
+      <glyph
+         id="glyph14971"
+         d=" M444.8 198.08A39.36 39.36 0 0 1 444.8 203.52V206.08A181.43999999999997 181.43999999999997 0 0 1 368 313.6A37.44 37.44 0 0 0 350.08 344V416A32 32 0 0 1 318.08 448H193.92A32 32 0 0 1 161.92 416V344A37.44 37.44 0 0 0 144 312A181.12 181.12 0 0 1 68.8 205.44V201.6A16.96 16.96 0 0 1 68.8 198.0800000000001A171.2 171.2 0 0 1 65.28 166.0800000000001A180.80000000000004 180.80000000000004 0 0 1 168.96 3.2A32 32 0 0 1 183.04 1e-13H329.2800000000001A32 32 0 0 1 343.36 3.2A180.80000000000004 180.80000000000004 0 0 1 448 165.44A169.6 169.6 0 0 1 444.8 198.08zM180.16 262.08A101.76 101.76 0 0 1 225.92 345.28V384H286.0800000000001V344A101.76 101.76 0 0 1 331.8400000000001 260.8A117.76 117.76 0 0 0 381.12 189.12V182.08A90.24 90.24 0 0 0 263.36 200.96A111.36000000000001 111.36000000000001 0 0 1 145.92 224A120.32000000000001 120.32000000000001 0 0 0 180.16 260.8z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="experimental" />
+      <glyph
+         id="glyph14973"
+         d=" M452.9230767999998 352C459.0403071999999 352 464 356.8357 464 362.8L464 398.8C464 404.7643000000001 459.0403071999999 409.6 452.9230767999998 409.6L434.4615391999996 409.6L434.4615391999996 452.8C434.4615391999996 476.659 414.6246160000001 496 390.1538464000005 496L124.3076923199997 496C99.8369230400003 496 80 476.659 80 452.8L80 78.4C80 54.5409999999999 99.8369230400003 35.2 124.3076923199997 35.2L390.1538464000005 35.2C414.6246160000001 35.2 434.4615391999996 54.5409999999999 434.4615391999996 78.4L434.4615391999996 121.6L452.9230767999998 121.6C459.0403071999999 121.6 464 126.4356992000001 464 132.4L464 168.4C464 174.3643008 459.0403071999999 179.2000000000001 452.9230767999998 179.2000000000001L434.4615391999996 179.2000000000001L434.4615391999996 236.8L452.9230767999998 236.8C459.0403071999999 236.8 464 241.6356992 464 247.6L464 283.6C464 289.5643008 459.0403071999999 294.4 452.9230767999998 294.4L434.4615391999996 294.4L434.4615391999996 352L452.9230767999998 352z M332.0210623999996 442.51428112L349.7886320000001 442.51428112C353.0297599999998 442.51428112 355.6571360000002 439.88519712 355.6571360000002 436.64285264L355.6571360000002 361.5179776C355.6571360000002 358.27563296 353.0297599999998 355.64654896 349.7886320000001 355.64654896L274.7125860800001 355.64654896C271.4714576 355.64654896 268.8440824000003 358.27563296 268.8440824000003 361.5179776L268.8440824000003 379.29710256C268.8440824000003 382.64996128 271.6456374399999 385.32222944 274.9933779200004 385.1617073600001L311.8386863999998 381.20214032C299.9163696 398.92995472 280.0015614400003 409.771424 258.2233105600002 409.771424C228.1761463999996 409.771424 202.3303078399999 389.1221204799999 195.4223151999999 360.2953712C194.78704048 357.6444696 192.4320032 355.771424 189.7129939199998 355.771424L171.3184575999998 355.771424C167.64736528 355.771424 164.8671779199998 359.1065444800001 165.5459400000004 362.7124883199999C173.8761135999998 406.97738048 212.6795275199997 439.51428112 258.2233105600002 439.51428112C286.2351251200002 439.51428112 312.2489695999997 427.21675568 327.6452848000003 405.32475408L326.1590016000004 436.362004C325.9986303999998 439.71092448 328.6694496000004 442.51428112 332.0210623999996 442.51428112z M258.2233105600002 280.5142816C288.2704745599998 280.5142816 314.1163135999999 301.163584 321.0243056000003 329.99033392C321.6595807999996 332.64123552 324.0146176000002 334.51428112 326.7336271999997 334.51428112L345.1281632000004 334.51428112C348.7992559999997 334.51428112 351.5794431999997 331.1791608 350.9006815999996 327.5732168C342.5705072000004 283.3083248000001 303.7670928000001 250.771424 258.2233105600002 250.771424C230.2408636800005 250.771424 204.2513508799997 263.043288 188.8544127999998 284.9015488L190.4017785600003 253.9359792C190.5694864000001 250.582576 187.89707408 247.771424 184.5406079999997 247.771424L166.7827825600001 247.771424C163.5416540800001 247.771424 160.9142788800004 250.4005088 160.9142788800004 253.6428528L160.9142788800004 328.76735264C160.9142788800004 332.00969712 163.5416540800001 334.63878112 166.7827825600001 334.63878112L241.8584540799997 334.63878112C245.0995825599998 334.63878112 247.7269577600004 332.00969712 247.7269577600004 328.76735264L247.7269577600004 310.9878526400001C247.7269577600004 307.6353696 244.9258255999998 304.9632128 241.5781737600004 305.1232416000001L204.60607664 309.0850424C216.5283587199996 291.3565216 236.44428336 280.5142816 258.2233105600002 280.5142816z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="fallbackdir" />
+      <glyph
+         id="glyph14975"
+         d=" M295.973 352H180.572L215.19 481.816C219.25 497.044 207.756 512 192 512H56C43.971 512 33.8 503.095 32.211 491.172L0.215 251.1720000000001C-1.704 236.783 9.504 224 24.004 224H142.705L96.646 29.534C93.05 14.351 104.659 0 119.992 0C128.342 0 136.368 4.374 140.77 11.978L316.7430000000001 315.975C325.9870000000001 331.942 314.4550000000001 352 295.9730000000001 352z"
+         horiz-adv-x="320"
+         unicode=""
+         glyph-name="fast" />
+      <glyph
+         id="glyph14977"
+         d=" M198.8473759999997 69.8115520000001C175.7948960000003 92.8640479999999 165.1261439999999 106.6301600000002 149.9472159999996 134.0429439999998C133.0839040000001 164.1036479999998 124.2357920000004 200.7511199999999 124.2357920000004 240.159952C124.2357920000004 313.703536 187.0392000000002 373.5199360000002 264.0757919999997 373.5199360000002C341.1123680000001 373.5199360000002 403.9158079999998 313.7035040000001 403.9158079999998 240.159952C403.9158079999998 231.2308159999998 396.8449600000004 224.159952 387.9158079999998 224.159952C378.9866560000001 224.159952 371.9158079999998 231.2308159999998 371.9158079999998 240.159952C371.9158079999998 295.9849119999999 323.5885120000003 341.5199520000001 264.0758079999996 341.5199520000001C204.5631039999999 341.5199520000001 156.2358080000004 295.984896 156.2358080000004 240.159952C156.2358080000004 206.2166240000002 163.7722240000003 174.9857280000001 178.0510080000004 149.7051040000001C191.6408320000001 125.2859199999998 200.3410240000003 114.230208 221.8558400000002 92.4349440000001C227.8824800000002 86.0910560000002 227.8824800000002 76.2287999999999 221.6465280000002 69.6802240000002C218.329264 66.6644959999999 214.2679360000002 65.039984 210.0758239999996 65.039984C205.7350079999997 65.039984 201.5739519999997 66.7737440000001 198.8473759999997 69.8115520000001zM305.5114240000003 131.4889600000001C268.6525279999996 156.4738560000001 246.6357920000001 197.0735199999999 246.6357920000001 240.159952C246.6357920000001 249.0890880000002 253.7066720000003 256.159952 262.6357920000001 256.159952C271.5649279999998 256.159952 278.6357920000001 249.0890880000002 278.6357920000001 240.159952C278.6357920000001 207.5885920000001 295.3078240000005 176.939648 323.4360800000004 158.0337439999999C339.7374879999998 147.0130880000002 358.8572160000004 141.6799999999998 382.1557599999997 141.6799999999998C388.4921279999999 141.6799999999998 397.9151359999996 142.5306879999998 406.3874400000004 144.013136C415.0970719999996 145.6260000000002 423.3919679999999 139.7998400000001 424.9689120000003 130.9683519999999C426.581776 122.2587199999998 420.7556160000004 113.9638239999999 411.9537440000004 112.39248C400.8680800000002 110.2531199999999 390.1723039999997 109.4399840000001 382.1557599999997 109.4399840000001C352.7702079999999 109.4399840000001 326.7927040000004 116.8889600000002 305.5114240000003 131.4889600000001zM329.7289760000004 60.6248959999998C291.02056 71.3366719999999 265.4320479999997 85.7974079999999 238.6975199999997 112.0414719999999C204.3265920000004 146.1668960000002 185.4357920000002 191.5947679999999 185.4357920000002 240.1599999999999C185.4357920000002 281.3138399999998 220.4103359999999 314.7200160000002 263.3557920000003 314.7200160000002C306.3012639999997 314.7200160000002 341.2757920000004 281.3138560000002 341.2757920000004 240.1599999999999C341.2757920000004 216.7314240000001 361.7688799999997 197.5999999999999 387.1957920000005 197.5999999999999C412.6227040000004 197.5999999999999 433.1157919999996 216.7314080000001 433.1157919999996 240.1599999999999C433.1157919999996 328.3612960000001 356.9735680000004 400.08 263.1157919999996 400.08C196.4003039999998 400.08 135.4604639999998 362.9602880000002 108.0797920000005 305.6247199999998C98.993888 286.753968 94.3157760000004 264.5478079999998 94.3157760000004 240.1599839999999C94.3157760000004 212.6229600000002 98.3163359999999 186.4572159999998 110.1291680000004 154.9559039999999C113.3395520000004 146.6088639999998 109.1273920000003 137.2819359999999 100.8717120000001 134.4266240000002C92.6151520000003 131.2510080000002 83.2601439999999 135.5764640000002 80.3292959999999 143.718672C68.3969280000001 175.6194719999999 62.5557920000001 207.2941599999999 62.5557920000001 240.1600319999998C62.5557920000001 269.4816160000001 68.178672 296.2367039999999 79.2650560000002 319.6412639999999C111.8755520000004 388.0497599999999 184.1168960000005 432.3200160000001 263.1157919999996 432.3200160000001C374.4936960000005 432.3200160000001 465.1157919999996 346.3238240000001 465.1157919999996 240.4000160000001C465.1157919999996 199.2461600000002 430.1412799999998 165.8400000000002 387.1957920000005 165.8400000000002C344.2503040000002 165.8400000000002 309.2757920000004 199.2461600000002 309.2757920000004 240.4000160000001C309.2757920000004 263.8285919999999 288.7827040000002 282.960016 263.3557920000003 282.960016C237.9288800000004 282.960016 217.4357920000002 263.8286079999998 217.4357920000002 240.4000160000001C217.4357920000002 200.3504320000002 232.9033600000003 162.9959680000002 261.1292160000003 135.0033600000002C283.5484479999996 112.8200959999999 304.8367040000003 100.7499680000001 337.7996160000003 91.6319840000001C346.3564800000004 89.413552 351.3377600000004 80.5468799999999 349.104496 72.2702559999998C347.5418239999999 65.0820159999998 341.0214720000004 60 333.9157759999998 60C332.6766559999997 60 331.3167999999996 60.2266559999998 329.7289760000004 60.6248959999998z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="fingerprint" />
+      <glyph
+         id="glyph14979"
+         d=" M496 384C496 162.718 360.0660000000001 39.355 274.461 3.692A48 48 0 0 0 237.538 3.692C130.495 48.287 16 185.513 16 384A48 48 0 0 0 45.539 428.308L237.539 508.308A48 48 0 0 0 274.462 508.308L466.462 428.308A48 48 0 0 0 496 384zM256 65.687L256.066 65.653C349.801 112.342 428.563 221.961 431.883 373.382L256 446.6670000000001V65.687z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="guard" />
+      <glyph
+         id="glyph14981"
+         d=" M189.0312960000001 381.0658400000002L189.0312960000001 343.85032L120.4904800000004 211.5879359999999L189.0312960000001 211.5879359999999L189.0312960000001 170.6240800000001L65.8720000000003 170.6240800000001L65.8720000000003 209.9815039999999L137.0902079999996 340.1019839999999L65.8720000000003 340.1019839999999L65.8720000000003 381.0658400000002L189.0312960000001 381.0658400000002zM344.8545919999997 320.8248800000001L344.8545919999997 289.4995840000002L275.242816 208.107344L344.8545919999997 208.107344L344.8545919999997 170.6240800000001L221.6952959999999 170.6240800000001L221.6952959999999 205.1622240000002L287.8264799999997 283.073872L221.6952959999999 283.073872L221.6952959999999 320.8248800000001L344.8545919999997 320.8248800000001zM465.8720000000003 283.274688L465.8720000000003 259.7807039999998L413.6631680000001 198.7365279999999L465.8720000000003 198.7365279999999L465.8720000000003 170.6240800000001L373.502528 170.6240800000001L373.502528 196.5276960000001L423.1009119999999 254.9614240000001L373.502528 254.9614240000001L373.502528 283.274688L465.8720000000003 283.274688z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="hibernating" />
+      <glyph
+         id="glyph14983"
+         d=" M452.9230767999998 352C459.0403071999999 352 464 356.8357 464 362.8L464 398.8C464 404.7643000000001 459.0403071999999 409.6 452.9230767999998 409.6L434.4615391999996 409.6L434.4615391999996 452.8C434.4615391999996 476.659 414.6246160000001 496 390.1538464000005 496L124.3076923199997 496C99.8369230400003 496 80 476.659 80 452.8L80 78.4C80 54.5409999999999 99.8369230400003 35.2 124.3076923199997 35.2L390.1538464000005 35.2C414.6246160000001 35.2 434.4615391999996 54.5409999999999 434.4615391999996 78.4L434.4615391999996 121.6L452.9230767999998 121.6C459.0403071999999 121.6 464 126.4356992000001 464 132.4L464 168.4C464 174.3643008 459.0403071999999 179.2000000000001 452.9230767999998 179.2000000000001L434.4615391999996 179.2000000000001L434.4615391999996 236.8L452.9230767999998 236.8C459.0403071999999 236.8 464 241.6356992 464 247.6L464 283.6C464 289.5643008 459.0403071999999 294.4 452.9230767999998 294.4L434.4615391999996 294.4L434.4615391999996 352L452.9230767999998 352z M178.1093038400004 437.4980121600001L178.1093038400004 364.11513232L207.9970329600001 364.11513232L207.9970329600001 437.4980121600001L251.2491935999997 437.4980121600001L251.2491935999997 246.5081328L207.9970329600001 246.5081328L207.9970329600001 328.3956512L178.1093038400004 328.3956512L178.1093038400004 246.5081328L134.8571428799996 246.5081328L134.8571428799996 437.4980121600001L178.1093038400004 437.4980121600001zM351.8469168000002 400.3205928C348.6070384000004 401.77853824 345.5292 402.7909849600001 342.6133087999997 403.35796368C339.6974191999998 403.9249424 336.6195808000002 404.20842752 333.3797023999996 404.20842752C326.7379504000001 404.20842752 321.7567120000004 402.75050416 318.4358368000003 399.8346136C315.1149616000003 396.91872288 313.4545488000004 393.11192288 313.4545488000004 388.4140992C313.4545488000004 384.68823888 314.2645071999996 381.56990272 315.8844464000004 379.0589969600001C317.5043856000002 376.5480910400001 319.7317679999997 374.44220176 322.5666608000002 372.7412656C325.4015552000001 371.0403292800001 328.6818831999999 369.6229038400001 332.4077423999998 368.4889464000001C336.1336031999999 367.35498896 340.1428928000005 366.1805505600001 344.4357312000002 364.96559616C348.7285712000003 363.75064176 353.1428384000001 362.37371408 357.6786688000002 360.8347718400001C362.2144992000003 359.2958296 366.6692640000001 357.39242944 371.0431007999996 355.12451456C380.2767536000001 350.2646969600001 386.8779071999998 343.9470288 390.8467584 336.17132048C394.8156096000003 328.3956128 396.8000048000004 318.9191104 396.8000048000004 307.7415296000001C396.8000048000004 285.8723504 391.0493072 269.5922048 379.5477392000003 258.9006064C368.0461696000002 248.2090064 351.6850287999996 242.863288 330.4638255999999 242.863288C318.8002640000004 242.863288 309.1617696000003 244.3617088 301.5480559999997 247.3585968C293.9343408000005 250.3554848 287.8596592000004 254.4862672 283.3238303999997 259.7510704C278.7880000000005 265.015872 275.6291664000001 271.0905536 273.8472336000005 277.9752944C272.0652991999996 284.8600368 271.1743471999999 292.190152 271.1743471999999 299.9658592000001L271.1743471999999 302.8817360000001L311.2676416000004 302.8817360000001L311.2676416000004 299.9658592000001C311.2676416000004 297.6979456000001 311.5511263999997 295.430064 312.1181055999996 293.1621488000001C312.6850848000004 290.8942336 313.7785264000004 288.8288432 315.3984656000003 286.965912C317.0184048000001 285.1029824 319.1242943999996 283.5640640000001 321.7161984000004 282.3491088000001C324.3081007999999 281.1341552 327.7099215999997 280.5266864 331.9217632 280.5266864C336.2956000000004 280.5266864 339.9404080000004 281.2556480000001 342.8562991999998 282.7135936C345.7721887999997 284.1715392 348.0805680000003 286.0749392 349.7815039999996 288.4238512C351.4824399999998 290.7727632 352.6568784000001 293.4861200000001 353.3048544000003 296.5640048C353.9528303999996 299.6418896 354.2768127999998 302.8817184 354.2768127999998 306.283592C354.2768127999998 309.685464 353.6288480000003 312.7633024 352.3328959999999 315.5171984C351.0369440000004 318.271096 348.0401024000003 320.700968 343.3422784000004 322.806888C339.7784112 324.5888224000001 335.5261360000004 326.1682384000001 330.5853200000002 327.5451872C325.6445056000003 328.922136 320.5417743999997 330.501552 315.2769712 332.2834864C310.0121695999997 334.0654192 304.7474448000003 336.21180624 299.4826432 338.722712C294.2178400000003 341.23361776 289.5200880000002 344.5139454400001 285.3892415999999 348.5637936000001C281.2583967999999 352.6136416 277.9375712000001 357.59488 275.4266656 363.5076580800001C272.9157599999999 369.42043632 271.6603263999996 376.66955552 271.6603263999996 385.25523344C271.6603263999996 395.94683232 273.3612368000004 404.85636432 276.7631087999999 411.98409696C280.1649808000002 419.1118296 284.8627343999997 424.8220296 290.8565104 429.11486864C296.8502847999999 433.4077075200001 303.7754207999997 436.4855459200001 311.6321263999999 438.348476C319.488832 440.21140608 327.9528879999998 441.1428571200001 337.0245471999997 441.1428571200001C341.8843648000002 441.1428571200001 346.7846063999996 440.89986992 351.7254223999999 440.41388816C356.6662367999998 439.9279064 361.5259808000001 439.03695312 366.3048016000003 437.74100176C371.0836224000004 436.4450504 375.5788863999997 434.70364192 379.790728 432.51672384C384.0025711999997 430.32980592 387.8093712 427.6164484800001 391.2112432000004 424.37657008L391.2112432000004 387.92811984L351.8469168000002 387.92811984L351.8469168000002 400.3205928z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="hsdir" />
+      <glyph
+         id="glyph14985"
+         d=" M244.6880000000001 453.7919999999999L244.6880000000001 417.8880000000001L209.0560000000001 417.8880000000001L209.0560000000001 275.904L244.6880000000001 275.904L244.6880000000001 240L124.7360000000001 240L124.7360000000001 275.904L160.368 275.904L160.368 417.8880000000001L124.7360000000001 417.8880000000001L124.7360000000001 453.7919999999999L244.6880000000001 453.7919999999999zM338.528 453.7919999999999C353.3974080000001 453.7919999999999 365.7279504000001 452.6133451200001 375.52 450.2560000000001C385.3120496 447.8986548800001 393.0639712 443.86402856 398.7760000000001 438.1520000000001C404.4880288 432.4399714399999 408.4773216 424.7787147200001 410.7440000000001 415.168C413.0106784 405.55728528 414.144 393.58940496 414.144 379.264C414.144 364.7572608000001 413.0106784 352.78938048 410.7440000000001 343.36C408.4773216 333.93061952 404.4880288 326.36002864 398.7760000000001 320.648C393.0639712 314.93597152 385.3120496 310.94667808 375.52 308.6800000000001C365.7279504000001 306.4133219200001 353.3974080000001 305.28 338.528 305.28L326.288 305.28L326.288 240L277.8720000000001 240L277.8720000000001 453.7919999999999L338.528 453.7919999999999zM326.288 345.264L342.88 345.264C347.5946896000001 345.264 351.4933184 345.6266630400001 354.576 346.352C357.6586816 347.0773369600001 360.0613248 348.5733220800001 361.784 350.8400000000001C363.5066752 353.1066779200001 364.7306624000001 356.41597824 365.456 360.7680000000001C366.1813376 365.12002176 366.544 371.01329616 366.544 378.448C366.544 385.7013696 366.1813376 391.54931104 365.456 395.992C364.7306624000001 400.43468896 363.5066752 403.87998784 361.784 406.328C360.0613248 408.77601232 357.6586816 410.3626630400001 354.576 411.088C351.4933184 411.81333696 347.5946896000001 412.1760000000001 342.88 412.1760000000001L326.288 412.1760000000001L326.288 345.264zM159.0080000000001 200.592L184.3040000000001 108.656L213.136 200.592L258.288 200.592L205.2480000000001 48L161.7280000000001 48L111.136 200.592L159.0080000000001 200.592zM396.192 261.7920000000001L396.192 132.048L415.232 132.048L415.232 95.056L396.192 95.056L396.192 48L352.6720000000001 48L352.6720000000001 95.056L271.072 95.056L271.072 132.864L357.2960000000001 261.7920000000001L396.192 261.7920000000001zM352.6720000000001 132.048L352.6720000000001 194.608L310.784 132.048L352.6720000000001 132.048z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="ipv4" />
+      <glyph
+         id="glyph14987"
+         d=" M226.900593162086 212.6296858410254L117.2411193576932 212.6296858410254L117.2411193576932 130.3850908505497L62.4114011085707 130.3850908505497L172.0708562598897 20.7256170461573L281.7303300642825 130.3850908505497L226.900593162086 130.3850908505497z M69.3618079848193 424.9523213584622L95.0615988218449 331.5487735583611L124.3538266307687 424.9523213584622H170.2265853827663L116.3399271760999 269.9245508254372H72.1252194458459L20.7256377717949 424.9523213584622zM280.4869783287148 449.546745538513C278.6446763871798 451.0205746563583 276.2036936729691 452.0798744382578 273.1639058322554 452.7246759726667C270.1241387171794 453.3694712893852 267.0383399606124 453.6918793105633 263.906468111279 453.6918793105633C259.1165037889262 453.6918793105633 254.9714176858428 452.5404665041512 251.4710854482022 450.2376056577429C247.9707324849238 447.9347448113346 245.0691639225102 444.7107889533808 242.7663175840483 440.5656406733841C240.4634505199487 436.4204923933874 238.7132947639473 431.4924455819438 237.5158088647685 425.781353087025C236.3182815143142 420.0702605921064 235.443245087589 413.7144619007118 234.8905752307663 406.7137663369739C240.2332094099418 408.7402777470244 245.6218130536951 410.0759228201537 251.0565726927662 410.7207222819996C256.4913116061996 411.3655175987176 261.6957057814369 411.6879131845138 266.6698795723056 411.6879131845138C277.7236083189635 411.6879131845138 287.0270155045178 410.1219876226659 294.5804120135351 406.9901012653857C302.1337877969147 403.8582128355418 308.2592914916442 399.2986181221501 312.9571303541013 393.3111803360012C317.6549692165585 387.3237446224161 321.0631552686658 380.0468156858919 323.181792138612 371.4801759072319C325.3004082829204 362.9135444188271 326.3597163550746 353.1956037521991 326.3597163550746 342.3261051996947C326.3597163550746 326.6666630504752 324.4714034976863 313.862944352918 320.6947156059966 303.914596771181C316.9180277143068 293.9662491894439 311.8057382733271 286.1826944729709 305.3577436548685 280.5637046397462C298.9097283107721 274.9447355321594 291.494633982606 271.0759843574874 283.1122119627169 268.9573474875412C274.7298106684655 266.8387313432321 265.9330209726051 265.7794232710782 256.721573441844 265.7794232710782C245.2993843068791 265.7794232710782 235.3972341717354 267.2992342888839 227.0148328774841 270.339063580873C218.632410857595 273.3788306959488 211.6318292848648 278.9056121667267 206.0128394516402 286.9195737983088C200.3938703440534 294.9335354298909 196.202731873841 305.8489205444222 193.4392996871765 319.6660814777446C190.675867500512 333.483242411067 189.2941721328176 351.1689472626838 189.2941721328176 372.7237141735392C189.2941721328176 393.1731123548564 190.629732230832 410.8588130613457 193.301121860152 425.7813468693339C195.9724285869209 440.7038806773221 200.2556925170288 453.0009694498029 206.1510172786648 462.6729821031286C212.0463420403007 472.3449947564543 219.783823664007 479.5298106684655 229.3637315830749 484.2276453857951C238.943618776505 488.9254801031248 250.5498723005212 491.2743622282053 264.1828030396901 491.2743622282053C276.7103526139382 491.2743622282053 288.2244806780588 489.524206472204 298.725539567894 486.023868016872C309.2265777320915 482.5235191987211 317.1482895499514 478.0099809975858 322.4909237291269 472.4831166242569V430.7554999345641H280.4869783287148zM257.5505989527159 377.6978672387695C254.4187063777445 377.6978672387695 250.8262901314837 377.3294068504625 246.7732673113827 376.5925067994863C242.7202237656438 375.8555860228724 238.5751376625604 374.7502255835892 234.3378846483058 373.2764047559991C234.5223428244748 359.2750136285232 235.1208992433242 347.8069379315316 236.1341756739872 338.8718460548198C237.1474521046503 329.9367334524703 238.6211693040515 322.8440471454823 240.5555759798442 317.5935177005646C242.4898997530858 312.342988255647 244.9309653698478 308.7045403678951 247.8786277506658 306.6780082322067C250.8262901314837 304.6514553708807 254.4187063777445 303.6382618427687 258.6559593919991 303.6382618427687C266.2093559010163 303.6382618427687 272.0585246673345 306.7240398736979 276.2036729473312 312.8956995637452C280.3488212273279 319.0673799794303 282.4213642788697 328.5089649920091 282.4213642788697 341.2207447604107C282.4213642788697 346.5633789395862 282.0068515234338 351.4914381864125 281.1778260125619 356.0050261290784C280.3488005016902 360.518634797382 278.9671051339957 364.3873859720541 277.032698458203 367.6113894989748C275.0983746849614 370.8353950984592 272.5191312411748 373.3224467603092 269.2951339319456 375.0726190968209C266.0711158970784 376.8227935058965 262.1563123552775 377.6978672387695 257.5505989527159 377.6978672387695z"
+         horiz-adv-x="347.08537485250696"
+         unicode=""
+         glyph-name="ipv6exit" />
+      <glyph
+         id="glyph14989"
+         d=" M244.6880000000001 453.7919999999999L244.6880000000001 417.8880000000001L209.0560000000001 417.8880000000001L209.0560000000001 275.904L244.6880000000001 275.904L244.6880000000001 240L124.7359999999999 240L124.7359999999999 275.904L160.368 275.904L160.368 417.8880000000001L124.7359999999999 417.8880000000001L124.7359999999999 453.7919999999999L244.6880000000001 453.7919999999999zM338.5280000000003 453.7919999999999C353.3974079999998 453.7919999999999 365.7279503999999 452.6133451200001 375.52 450.2560000000001C385.3120496000002 447.8986548800001 393.0639712000002 443.86402856 398.7759999999999 438.1520000000001C404.4880288 432.4399714399999 408.4773215999999 424.7787147200001 410.7440000000002 415.168C413.0106784 405.55728528 414.1440000000003 393.58940496 414.1440000000003 379.264C414.1440000000003 364.7572608000001 413.0106784 352.78938048 410.7440000000002 343.36C408.4773215999999 333.93061952 404.4880288 326.36002864 398.7759999999999 320.648C393.0639712000002 314.93597152 385.3120496000002 310.94667808 375.52 308.6800000000001C365.7279503999999 306.41332208 353.3974079999998 305.28 338.5280000000003 305.28L326.288 305.28L326.288 240L277.8719999999999 240L277.8719999999999 453.7919999999999L338.5280000000003 453.7919999999999zM326.288 345.264L342.8800000000001 345.264C347.5946896000001 345.264 351.4933184000002 345.6266630400001 354.576 346.352C357.6586815999999 347.0773369600001 360.0613248 348.5733220800001 361.7840000000001 350.8400000000001C363.5066752000003 353.1066779200001 364.7306624000003 356.41597824 365.4560000000002 360.7680000000001C366.1813376 365.12002176 366.5439999999999 371.01329616 366.5439999999999 378.448C366.5439999999999 385.7013696 366.1813376 391.54931104 365.4560000000002 395.992C364.7306624000003 400.43468896 363.5066752000003 403.87998784 361.7840000000001 406.328C360.0613248 408.77601232 357.6586815999999 410.3626630400001 354.576 411.088C351.4933184000002 411.81333696 347.5946896000001 412.1760000000001 342.8800000000001 412.1760000000001L326.288 412.1760000000001L326.288 345.264zM159.0079999999998 200.592L184.3040000000001 108.656L213.136 200.592L258.288 200.592L205.2480000000001 48L161.7280000000001 48L111.136 200.592L159.0079999999998 200.592zM366.8159999999998 224.8C365.0026576 226.2506736000001 362.6000144 227.2933296 359.6080000000002 227.928C356.6159856 228.5626704 353.5786816 228.88 350.4960000000001 228.88C345.7813104000002 228.88 341.7013504000002 227.7466784000001 338.2559999999999 225.48C334.8106496000001 223.2133216 331.9546783999999 220.0400208 329.6880000000001 215.96C327.4213215999999 211.8799792 325.698672 207.0293616 324.52 201.408C323.341328 195.7866384 322.4800031999999 189.5307008 321.9360000000002 182.64C327.1946927999998 184.6346768 332.4986399999998 185.9493296000001 337.848 186.5840000000001C343.1973600000001 187.2186704000001 348.3199759999998 187.5360000000001 353.2159999999999 187.5360000000001C364.0960544 187.5360000000001 373.2532959999999 185.9946816 380.6880000000001 182.912C388.1227039999999 179.8293184 394.1519776 175.3413631999999 398.7759999999999 169.448C403.4000224000002 163.5546368 406.7546560000001 156.3920416000001 408.8400000000002 147.96C410.9253440000002 139.5279584 411.9679999999999 129.96272 411.9679999999999 119.264C411.9679999999999 103.8505904 410.109352 91.2480496000001 406.3919999999999 81.456C402.6746480000002 71.6639504 397.6426976000003 64.0026944 391.2959999999998 58.472C384.9493023999999 52.9413056000001 377.6507072 49.1333440000001 369.4000000000001 47.048C361.1492927999998 44.9626559999999 352.4907119999998 43.9200000000001 343.424 43.9200000000001C332.1812768 43.9200000000001 322.4347072000001 45.4159856 314.1840000000002 48.408C305.9332927999999 51.4000143999999 299.0426944000001 56.83996 293.5120000000002 64.7280000000001C287.9813055999998 72.61604 283.8560143999998 83.3599328 281.136 96.96C278.4159872 110.5600688 277.0560000000001 127.9678944 277.0560000000001 149.184C277.0560000000001 169.3121008000001 278.3706527999998 186.7199264 281 201.408C283.6293472000002 216.0960736 287.845304 228.199952 293.6480000000002 237.7200000000001C299.4506959999999 247.240048 307.0666191999999 254.3119776 316.4960000000001 258.9360000000001C325.9253807999999 263.5600224 337.3492655999999 265.8720000000001 350.7680000000001 265.8720000000001C363.098728 265.8720000000001 374.4319488000001 264.1493504 384.7680000000001 260.704C395.1040512 257.2586496 402.9013071999998 252.8160272 408.1599999999999 247.376L408.1599999999999 206.304L366.8159999999998 206.304L366.8159999999998 224.8zM344.2399999999998 154.0799999999999C341.1573183999999 154.0799999999999 337.6213536 153.7173376000001 333.6320000000001 152.992C329.6426464000001 152.2666624 325.562688 151.1786736 321.3919999999999 149.7280000000001C321.5733344 135.9465984000001 322.1626624000001 124.6587104 323.1599999999999 115.864C324.1573376000001 107.0692896000001 325.6079903999999 100.0880256 327.5120000000002 94.9200000000001C329.4160096000001 89.7519744 331.8186528000001 86.1706768 334.7200000000003 84.1759999999999C337.6213472 82.1813232 341.1573119999998 81.184 345.328 81.184C352.7627039999998 81.184 358.5199791999999 84.2213024 362.5999999999999 90.2960000000001C366.6800208 96.3706976000001 368.7200000000003 105.6639376000001 368.7200000000003 118.1759999999999C368.7200000000003 123.4346928 368.3120048000001 128.2853104000001 367.4960000000001 132.7280000000001C366.6799952000001 137.1706896000001 365.3200096000001 140.9786512000001 363.4160000000002 144.1520000000001C361.5119903999999 147.3253488 358.9733488000002 149.7733248 355.8000000000002 151.496C352.6266512000002 153.2186752 348.7733567999999 154.0799999999999 344.2399999999998 154.0799999999999z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="ipv6" />
+      <glyph
+         id="glyph14991"
+         d=" M202.021 512C122.202 512 70.503 479.297 29.914 420.974C22.551 410.394 24.821 395.8880000000001 35.092 388.1L78.23 355.391C88.603 347.526 103.362 349.365 111.483 359.539C136.532 390.92 155.113 408.988 194.24 408.988C225.004 408.988 263.0560000000001 389.189 263.0560000000001 359.357C263.0560000000001 336.805 244.4390000000001 325.223 214.0630000000001 308.193C178.6400000000001 288.333 131.7640000000001 263.617 131.7640000000001 201.788V192C131.7640000000001 178.745 142.5090000000001 168 155.7640000000001 168H228.2350000000001C241.4900000000001 168 252.2350000000001 178.745 252.2350000000001 192V197.773C252.2350000000001 240.6330000000001 377.5030000000001 242.418 377.5030000000001 358.4000000000001C377.504 445.7440000000001 286.902 512 202.021 512zM192 138.541C153.804 138.541 122.729 107.466 122.729 69.27C122.729 31.075 153.804 0 192 0S261.271 31.075 261.271 69.271S230.1960000000001 138.541 192 138.541z"
+         horiz-adv-x="384"
+         unicode=""
+         glyph-name="noedconsensus" />
+      <glyph
+         id="glyph14993"
+         d=" M569.517 71.987C587.975 39.993 564.806 0 527.94 0H48.054C11.117 0 -11.945 40.055 6.477 71.987L246.423 488.015C264.89 520.024 311.1430000000001 519.966 329.577 488.015L569.517 71.987zM288 158C262.5950000000001 158 242 137.405 242 112S262.5950000000001 66 288 66S334 86.595 334 112S313.405 158 288 158zM244.327 323.346L251.745 187.346C252.092 180.982 257.354 176 263.727 176H312.273C318.646 176 323.908 180.982 324.255 187.346L331.673 323.346C332.048 330.2200000000001 326.575 336 319.6910000000001 336H256.3080000000001C249.4240000000001 336 243.9520000000001 330.2200000000001 244.3270000000001 323.346z"
+         horiz-adv-x="576"
+         unicode=""
+         glyph-name="notrecommended" />
+      <glyph
+         id="glyph14995"
+         d=" M285.8229263746506 251.9440820130475C269.5992544268407 266.7362534948742 249.0810810810811 278.6654240447344 228.0857409133272 290.5945945945946C218.542404473439 295.8434296365331 189.4352283317801 318.7474370922647 199.4557315936627 351.1947809878845L181.3233923578752 358.829450139795C209.9534016775396 403.2059645852749 247.1724137931035 447.1053122087605 292.9804287045667 488.1416589002796C256.2385834109972 475.7353215284249 223.7912395153775 456.6486486486486 199.4557315936627 422.7698042870457C213.7707362534949 452.8313140726934 237.1519105312209 482.4156570363467 262.9189189189189 512.4771668219944C227.6085740913327 487.1873252562908 197.0698974836906 458.5573159366263 177.9832246039143 420.3839701770736L191.3438956197577 473.8266542404473C172.2572227399814 439.47064305685 158.896551724138 404.6374650512581 153.6477166821995 369.8042870456664L125.4948741845294 381.2562907735321L120.7232059645853 377.4389561975769C145.5358807082946 333.0624417520969 132.6523765144455 309.6812674743709 120.2460391425909 301.569431500466C95.4333643988817 284.8685927306617 59.645852749301 263.3960857409133 41.5135135135135 244.7865796831314C7.1575023299161 209.4762348555452 -2.8630009319665 176.0745573159366 0.4771668219944 131.6980428704566C3.8173345759553 74.915191053122 45.3308480894688 27.6756756756756 100.2050326188257 9.0661696178937C124.5405405405406 0.9543336439887 146.9673811742777 -1e-13 171.780055917987 -1e-13C211.8620689655173 -1e-13 252.8984156570364 10.4976700838769 282.9599254426841 35.7875116495805C314.9301025163095 62.031686859273 333.5396085740914 102.1136999068033 333.5396085740914 143.1500465983224C333.5396085740914 184.663560111836 316.3616029822927 224.2684063373719 285.8229263746506 251.9440820130475zM88.7530288909599 26.2441752096924C44.37651444548 47.7166821994408 14.7921714818267 94.0018639328984 12.883504193849 131.6980428704566C9.0661696178938 208.5219012115563 45.8080149114632 230.9487418452936 80.1640260950606 259.1015843429637C99.2506989748369 274.8480894687791 125.9720410065238 282.4827586206897 141.2413793103449 310.6356011183597C144.1043802423113 316.8387698042871 146.0130475302889 330.1994408201305 142.1957129543337 344.5144454799627C140.7642124883505 349.2861136999068 133.6067101584343 366.4641192917055 130.7437092264679 370.2814538676608L173.2115563839702 351.6719478098788L173.2115563839702 351.6719478098788L173.2115563839702 351.6719478098788C172.2572227399814 331.6309412861137 171.780055917987 315.4072693383038 175.5973904939423 300.6150978564772C179.8918918918919 284.3914259086673 200.8872320596459 261.0102516309413 209.4762348555453 233.81174277726C226.1770736253496 182.2777260018639 221.8825722273999 114.9972041006524 209.9534016775397 62.5088536812675C208.0447343895621 53.9198508853681 201.8415657036347 43.4221808014912 194.2068965517242 33.878844361603C197.0698974836907 39.1276794035414 199.4557315936627 44.37651444548 200.8872320596459 50.1025163094129C212.8164026095061 92.5703634669152 218.0652376514446 112.134203168686 212.3392357875117 158.896551724138C211.3849021435229 163.6682199440821 209.4762348555453 178.9375582479031 202.3187325256291 195.6383970177074C192.2982292637465 220.928238583411 177.0288909599255 244.7865796831314 175.1202236719479 250.0354147250699C171.780055917987 258.1472506989749 167.0083876980429 292.5032618825722 166.5312208760485 315.8844361602983C167.0083876980429 295.8434296365331 168.4398881640261 259.1015843429637 173.6887232059646 244.7865796831314C175.1202236719478 240.0149114631873 188.9580615097857 218.5424044734389 198.9785647716682 192.2982292637465C205.65890027959 174.165890027959 207.0904007455732 157.4650512581547 208.5219012115564 152.6933830382106C213.2935694315005 131.2208760484622 207.5675675675676 94.9561975768872 199.9328984156571 60.6001863932899C197.547064305685 48.1938490214353 190.8667287977633 33.878844361603 182.2777260018639 22.9040074557315C187.049394221808 29.5843429636533 190.8667287977633 38.1733457595526 193.7297297297297 48.1938490214351C199.4557315936627 68.2348555452003 201.8415657036347 94.0018639328984 201.3643988816403 110.2255358807083C200.8872320596459 119.7688723205964 196.5927306616962 140.2870456663559 189.4352283317801 158.8965517241379C185.1407269338304 168.9170549860205 178.9375582479031 179.4147250698974 174.6430568499534 186.5722273998136C169.8713886300093 193.7297297297297 169.8713886300093 209.4762348555452 167.9627213420317 227.6085740913327C168.4398881640261 208.044734389562 166.5312208760485 198.0242311276794 171.3028890959926 184.1863932898415C174.165890027959 176.0745573159366 184.663560111836 164.6225535880708 187.5265610438024 153.6477166821994C191.8210624417521 138.8555452003727 196.1155638397018 122.6318732525628 195.6383970177074 112.6113699906803C195.6383970177074 101.1593662628145 195.161230195713 80.1640260950605 189.9123951537745 57.260018639329C186.5722273998136 40.0820130475303 178.9375582479031 25.2898415657036 166.5312208760485 15.7465051258154C171.780055917987 22.4268406337372 174.6430568499535 29.1071761416588 176.0745573159366 35.7875116495806C177.9832246039143 45.8080149114631 178.4603914259087 55.3513513513513 179.4147250698975 67.2805219012115C180.3690587138864 77.301025163094 179.8918918918919 90.1845293569431 177.0288909599255 104.0223671947809C173.2115563839702 121.2003727865796 167.0083876980429 138.3783783783783 164.1453867660764 150.3075489282385C164.6225535880709 136.9468779123952 169.8713886300093 120.2460391425909 172.2572227399814 102.5908667287977C174.165890027959 89.7073625349487 173.2115563839702 76.8238583410997 172.7343895619758 65.3718546132339C172.2572227399814 52.0111835973905 167.9627213420317 28.6300093196645 162.2367194780988 17.1780055917987C156.5107176141659 19.5638397017707 154.6020503261883 22.9040074557316 150.784715750233 27.6756756756757C146.0130475302889 33.878844361603 143.1500465983225 40.5591798695247 140.2870456663561 48.1938490214353C137.901211556384 53.9198508853681 135.515377446412 60.6001863932899 134.0838769804287 67.757688723206C132.6523765144455 79.2096924510718 133.1295433364399 96.8648648648648 146.0130475302889 114.9972041006524C156.0335507921715 129.3122087604846 157.9422180801491 130.2665424044735 161.28238583411 146.9673811742778C156.510717614166 132.1752096924511 153.1705498602051 130.7437092264679 142.6728797763281 118.3373718546133C130.7437092264679 104.4995340167754 128.8350419384903 84.4585274930103 128.8350419384903 68.2348555452004C128.8350419384903 61.5545200372787 131.6980428704567 53.9198508853681 134.0838769804288 46.762348555452C136.9468779123952 39.1276794035415 139.8098788443617 31.493010251631 143.6272134203169 25.767008387698C146.4902143522834 20.995340167754 150.3075489282387 17.6551724137931 153.6477166821995 15.269338303821C141.2413793103449 18.6095060577819 128.3578751164959 23.381174277726 120.2460391425909 30.0615097856477C100.2050326188258 47.2395153774463 82.5498602050327 76.3466915191053 80.1640260950606 102.1136999068033C78.255358807083 123.1090400745573 97.3420316868593 153.6477166821994 124.5405405405406 168.9170549860205C147.4445479962722 182.2777260018639 152.6933830382107 197.0698974836906 157.4650512581548 221.4054054054054C150.7847157502331 200.4100652376514 144.1043802423114 182.2777260018639 122.1547064305686 171.3028890959925C90.6616961789376 154.1248835041938 74.4380242311277 126.4492078285181 75.8695246971109 99.7278657968312C78.2553588070829 65.8490214352283 91.6160298229264 42.4678471575023 118.8145386766077 23.8583410997203C125.017707362535 19.5638397017706 133.6067101584343 15.269338303821 142.6728797763281 11.9291705498601C108.7940354147251 20.0410065237651 104.4995340167754 24.8126747437091 93.0475302889096 38.1733457595525C93.0475302889096 39.1276794035414 90.1845293569432 41.036346691519 90.1845293569432 41.5135135135134C74.9151910531221 58.6915191053121 55.8285181733458 88.2758620689654 49.148182665424 115.4743709226467C46.762348555452 125.0177073625349 44.37651444548 135.0382106244174 47.2395153774464 144.5815470643056C59.645852749301 189.43522833178 86.8443616029823 206.6132339235787 114.0428704566636 225.2227399813606C120.7232059645853 229.9944082013046 127.403541472507 234.2889095992544 133.6067101584343 239.0605778191984C148.8760484622554 250.9897483690586 152.6933830382107 282.0055917986952 156.0335507921715 299.6607642124883C149.8303821062442 278.1882572227399 143.1500465983225 251.4669151910531 131.2208760484623 242.8779123951537C125.017707362535 238.1062441752096 117.3830382106245 234.2889095992544 111.1798695246971 229.9944082013046C83.0270270270271 210.9077353215283 54.874184529357 192.7753960857408 41.9906803355079 146.4902143522832C39.1276794035415 134.561043802423 41.0363466915191 125.9720410065236 43.8993476234856 114.5200372786578C51.0568499534017 86.3671947809877 70.143522833178 55.8285181733456 86.3671947809879 37.696178937558C86.3671947809879 37.696178937558 89.2301957129544 34.8331780055916 89.2301957129544 34.8331780055916C96.3876980428705 26.7213420316867 105.4538676607643 20.5181733457594 116.4287045666357 16.2236719478096C106.4082013047531 18.6095060577819 97.3420316868593 21.9496738117427 88.7530288909599 26.2441752096924z"
+         horiz-adv-x="333.5396085740914"
+         unicode=""
+         glyph-name="onion-alt" />
+      <glyph
+         id="glyph14997"
+         d=" M198.5300319999997 313.1915680000002C180.5147040000002 365.9338560000001 152.4059360000001 395.8352639999998 152 396.2267040000002L204.2640160000001 430.1897760000002C205.3681919999999 429.1029440000002 216.5102559999996 417.039264 229.8272159999997 396.6342559999998L229.8272159999997 512L296.7465759999996 512C296.7465759999996 512 297.0142400000005 410.7357280000001 296.7465759999996 403.3181920000002C314.6809599999997 420.48992 339.1399840000004 447.1441279999999 366.3427039999997 457.2243680000001L408 383.076208C374.2029439999997 370.5677759999999 352.6237600000004 338.001792 339.5471200000002 305.928144C339.7065279999997 305.8620639999999 339.8537280000001 305.7971520000001 339.9884160000002 305.733424C366.3900640000002 293.3918079999999 391.8492640000004 280.6537600000002 412.1234240000004 265.1290880000002C450.3139359999996 235.6712640000001 472 194.2682559999999 472 150.4779680000002C472 107.087008 448.4256480000004 65.2875680000002 408.8232159999998 37.42128C371.5785599999999 11.1465119999998 320.1906559999998 0 270.2146720000001 0C239.0975040000003 0 211.2805120000003 1.192192 181.1092159999998 9.5549919999999C112.2779039999996 29.0613920000001 60.8865599999999 78.8213759999999 56.6439360000004 138.5385919999999C52.8707999999997 185.1155199999998 65.1291840000004 220.545936 108.0352800000001 257.5678720000001C128.5335679999998 275.6151840000003 168.4076160000004 296.0478400000002 198.5300319999997 313.1915680000002z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="onion" />
+      <glyph
+         id="glyph14999"
+         d=" M426.6666666666667 341.3333333333334H366.7200000000001C357.12 357.9733333333334 343.8933333333333 372.2666666666667 327.8933333333333 383.1466666666667L362.6666666666667 417.92L332.5866666666667 448L286.2933333333333 401.7066666666667C276.48 404.0533333333334 266.4533333333333 405.3333333333334 256 405.3333333333334C245.5466666666667 405.3333333333334 235.52 404.0533333333334 225.92 401.7066666666667L179.4133333333333 448L149.3333333333333 417.92L183.8933333333334 383.1466666666667C168.1066666666667 372.2666666666667 154.88 357.9733333333334 145.28 341.3333333333334H85.3333333333333V298.6666666666667H129.92C128.8533333333333 291.6266666666667 128 284.5866666666667 128 277.3333333333334V256H85.3333333333333V213.3333333333334H128V192C128 184.7466666666667 128.8533333333333 177.7066666666667 129.92 170.6666666666667H85.3333333333333V128H145.28C167.4666666666667 89.8133333333334 208.64 64 256 64S344.5333333333333 89.8133333333334 366.7200000000001 128H426.6666666666667V170.6666666666667H382.08C383.1466666666667 177.7066666666667 384 184.7466666666667 384 192V213.3333333333334H426.6666666666667V256H384V277.3333333333334C384 284.5866666666667 383.1466666666667 291.6266666666667 382.08 298.6666666666667H426.6666666666667V341.3333333333334zM298.6666666666667 170.6666666666667H213.3333333333333V213.3333333333334H298.6666666666667V170.6666666666667zM298.6666666666667 256H213.3333333333333V298.6666666666667H298.6666666666667V256z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="outdated" />
+      <glyph
+         id="glyph15001"
+         d=" M154.2776470399999 176.0752944000001L178.7858824 87.0023535999999L206.72 176.0752944000001L250.4658824000001 176.0752944000001L199.0776470400001 28.2352943999999L156.9129411199999 28.2352943999999L107.896470592 176.0752944000001L154.2776470399999 176.0752944000001zM384.0752944000001 235.3694112000001L384.0752944000001 109.6658815999999L402.5223536 109.6658815999999L402.5223536 73.8258816L384.0752944000001 73.8258816L384.0752944000001 28.2352943999999L341.9105887999999 28.2352943999999L341.9105887999999 73.8258816L262.8517648 73.8258816L262.8517648 110.4564704L346.3905888 235.3694112000001L384.0752944000001 235.3694112000001zM341.9105887999999 109.6658815999999L341.9105887999999 170.2776463999999L301.3270591999999 109.6658815999999L341.9105887999999 109.6658815999999z M114.823536 422.0172921599999L114.823536 430.2987665600001C114.823536 437.1594504 120.7490874720001 442.7209780799999 128.058830112 442.7209780799999L326.5882416000001 442.7209780799999L326.5882416000001 467.565401088C326.5882416000001 478.6247924720001 340.8707791999999 484.1500886399999 349.1825439999999 476.349457392L393.3001903999999 434.9420857600001C398.4685728000001 430.09069456 398.4685728000001 422.22536432 393.3001903999999 417.3744907200001L349.1825439999999 375.9671188800001C340.9022128000001 368.1970256 326.5882416000001 373.64520064 326.5882416000001 384.7506576000001L326.5882416000001 409.5950806400001L128.058830112 409.5950806400001C120.7490874720001 409.5950806400001 114.823536 415.1566083200001 114.823536 422.0172921599999zM383.9411824 343.34328592L185.41177136 343.34328592L185.41177136 368.18770896C185.41177136 379.219668 171.14963888 384.7920649600001 162.8174697599999 376.97176528L118.699822768 335.5643935999999C113.5314404112 330.7130024000001 113.5314404112 322.84767216 118.699822768 317.9967984L162.8174697599999 276.5894272000001C171.10496976 268.8115696 185.41177136 274.2773424 185.41177136 285.3729648000001L185.41177136 310.2173888L383.9411824 310.2173888C391.2509263999999 310.2173888 397.1764768 315.7789168 397.1764768 322.6396001600001L397.1764768 330.9210744C397.1764768 337.7817584 391.2509263999999 343.34328592 383.9411824 343.34328592z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="reachableipv4" />
+      <glyph
+         id="glyph15003"
+         d=" M147.9200000000001 189.0799999999999L173.96 94.4400000000001L203.6399999999999 189.0799999999999L250.1199999999999 189.0799999999999L195.52 32L150.7199999999998 32L98.6399999999999 189.0799999999999L147.9200000000001 189.0799999999999zM361.8400000000002 214C359.9733248000003 215.4933408 357.500016 216.566664 354.4200000000001 217.22C351.3399840000002 217.8733360000001 348.2133488 218.2000000000001 345.04 218.2000000000001C340.1866432000002 218.2000000000001 335.9866848000002 217.0333456000001 332.4400000000001 214.7000000000001C328.8933152 212.3666544 325.9533455999999 209.1000208000001 323.6199999999999 204.9000000000001C321.2866543999999 200.6999791999999 319.5133391999998 195.706696 318.3000000000002 189.9200000000001C317.0866608000001 184.133304 316.2000032000001 177.6933696000001 315.6399999999999 170.5999999999999C321.0533599999999 172.6533440000001 326.5133056 174.006664 332.02 174.6600000000001C337.5266944 175.3133359999999 342.7999743999999 175.6399999999999 347.8400000000002 175.6399999999999C359.0400559999998 175.6399999999999 368.4666287999999 174.0533488000001 376.1199999999999 170.8800000000001C383.7733712 167.7066512000001 389.9799760000001 163.0866976 394.7399999999998 157.02C399.500024 150.9533024 402.9533231999999 143.5800432000001 405.0999999999999 134.9000000000001C407.2466768 126.2199568000001 408.3200000000002 116.3733887999999 408.3200000000002 105.3600000000001C408.3200000000002 89.4932544000001 406.4066864000002 76.5200512000001 402.58 66.4400000000001C398.7533136000002 56.3599503999999 393.5733664 48.4733615999999 387.04 42.78C380.5066336 37.0866384000001 372.9933759999999 33.1666768 364.5 31.02C356.0066240000001 28.8733232 347.0933808 27.8 337.7600000000002 27.8C326.1866095999999 27.8 316.1533760000002 29.339984 307.6599999999999 32.4200000000001C299.166624 35.500016 292.0733615999998 41.09996 286.3800000000001 49.22C280.6866384 57.3400400000001 276.4400144000001 68.3999296 273.6399999999999 82.4000000000001C270.8399856000001 96.4000704 269.4400000000001 114.3198912 269.4400000000001 136.1600000000001C269.4400000000001 156.8801040000001 270.7933199999998 174.7999248000001 273.5 189.9200000000001C276.2066800000003 205.0400752000001 280.5466367999998 217.4999504 286.52 227.3C292.4933632000002 237.1000495999999 300.3332848 244.379976 310.04 249.1399999999999C319.7467152 253.9000240000001 331.5065983999998 256.28 345.3200000000002 256.28C358.0133968 256.28 369.6799472000003 254.5066847999999 380.3200000000002 250.9600000000001C390.9600528000001 247.4133152 398.9866400000001 242.8400288000001 404.4000000000001 237.24L404.4000000000001 194.96L361.8400000000002 194.96L361.8400000000002 214zM338.5999999999999 141.2000000000001C335.4266511999999 141.2000000000001 331.7866880000002 140.8266704 327.6799999999999 140.0799999999999C323.5733135999999 139.3333296000001 319.3733551999999 138.2133408 315.08 136.72C315.2666672000001 122.5332624 315.8733280000002 110.9133792 316.9000000000001 101.8600000000001C317.9266720000001 92.8066208 319.4199904000002 85.6200272000001 321.3800000000001 80.3C323.3400096000001 74.9799728 325.8133183999999 71.2933439999999 328.8000000000002 69.24C331.7866816000001 67.1866560000001 335.4266447999999 66.1600000000001 339.7199999999998 66.1600000000001C347.3733711999999 66.1600000000001 353.2999792000001 69.2866352000001 357.5 75.54C361.7000208 81.7933648000001 363.8000000000002 91.3599360000001 363.8000000000002 104.24C363.8000000000002 109.65336 363.3800047999998 114.6466432 362.54 119.22C361.6999952000001 123.7933568000001 360.3000096000001 127.7133168 358.3400000000002 130.98C356.3799903999998 134.2466832 353.7666832 136.7666575999999 350.5 138.54C347.2333168 140.3133424 343.2666896000001 141.2000000000001 338.5999999999999 141.2000000000001z M116 433.96255744L116 442.8231558400001C116 450.16360784 122.1990384639999 456.1140534399999 129.8461538400002 456.1140534399999L337.5384608 456.1140534399999L337.5384608 482.6958487039999C337.5384608 494.5286241136 352.480192 500.440304624 361.1755776 492.0941747039999L407.3294224000001 447.7911825599999C412.7363455999998 442.6005332800001 412.7363455999998 434.18518 407.3294224000001 428.9950844800001L361.1755776 384.6920923200001C352.5130767999999 376.37863584 337.5384608 382.20780208 337.5384608 394.08986448L337.5384608 420.67165968L129.8461538400002 420.67165968C122.1990384639999 420.67165968 116 426.6221054400001 116 433.96255744zM397.5384608 349.78687232L189.8461539199998 349.78687232L189.8461539199998 376.3686676800001C189.8461539199998 388.1720923200001 174.9257692800002 394.1341675200001 166.2090383999998 385.7669936L120.0551923039998 341.4640016000001C114.6482692303998 336.2733521600001 114.6482692303998 327.8579984000001 120.0551923039998 322.6679039999999L166.2090383999998 278.364912C174.8790383999999 270.0431472 189.8461539199998 275.8911424000001 189.8461539199998 287.7626832000001L189.8461539199998 314.3444784000001L397.5384608 314.3444784000001C405.1855776000002 314.3444784000001 411.3846159999998 320.2949248 411.3846159999998 327.635376L411.3846159999998 336.4959747200001C411.3846159999998 343.83642672 405.1855776000002 349.78687232 397.5384608 349.78687232z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="reachableipv6" />
+      <glyph
+         id="glyph15005"
+         d=" M238.4790720000001 415.5708528L313.2039519999999 365.7542672C321.5206559999997 369.4821792 330.7404319999996 371.5555552000001 340.4444480000002 371.5555552000001C377.2632000000003 371.5555552000001 407.1111039999996 341.7076384 407.1111039999996 304.8888896000001C407.1111039999996 268.0701392000001 377.2632000000003 238.2222224 340.4444480000002 238.2222224C324.7444480000004 238.2222224 310.3145759999998 243.6520832000001 298.9236160000001 252.7333328L227.7527840000003 208.2513888000001C229.8604160000005 198.7176416 229.8604160000005 188.838608 227.7527840000003 179.3048607999999L298.9236160000001 134.8229168C310.3145759999998 143.903472 324.7444480000004 149.3333328000001 340.4444480000002 149.3333328000001C377.2632000000003 149.3333328000001 407.1111039999996 119.485416 407.1111039999996 82.6666671999999C407.1111039999996 45.8479167999999 377.2632000000003 16 340.4444480000002 16C303.6256960000001 16 273.7777759999999 45.8479167999999 273.7777759999999 82.6666671999999C273.7763679999998 87.5341152000001 274.3063519999996 92.3871727999999 275.3583360000003 97.139584L204.1875040000005 141.6215279999999C192.7965279999999 132.5409728 178.3666720000001 127.1111103999999 162.6666720000003 127.1111103999999C125.8479200000002 127.1111103999999 96 156.9590272 96 193.7777776C96 230.5965280000001 125.8479200000002 260.4444448 162.6666720000003 260.4444448C178.3666720000001 260.4444448 192.7965279999999 255.014584 204.1875040000005 245.9340272L275.3583360000003 290.4159728C274.326384 295.0763887999999 273.7777759999999 299.918056 273.7777759999999 304.8888896000001C273.7777759999999 316.4405088000001 276.7158399999999 327.3059584 281.885456 336.77872L213.7660800000003 382.1916448C203.8325759999998 375.4767664000001 191.8556959999996 371.5555552000001 178.9629599999999 371.5555552000001C144.5985760000003 371.5555552000001 116.7407359999998 399.4133936000001 116.7407359999998 433.7777776000001C116.7407359999998 468.1421616 144.5985760000003 496 178.9629599999999 496C213.3273440000003 496 241.185184 468.1421616 241.185184 433.7777776000001C241.185184 427.4431279999999 240.2385599999998 421.3295711999999 238.4790720000001 415.5708528z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="relay" />
+      <glyph
+         id="glyph15007"
+         d=" M0 344V360C0 373.255 10.745 384 24 384H384V432C384 453.367 409.899 464.042 424.971 448.971L504.971 368.971C514.343 359.598 514.343 344.4020000000001 504.971 335.03L424.971 255.03C409.956 240.018 384 250.544 384 272V320H24C10.745 320 0 330.745 0 344zM488 192H128V240C128 261.314 102.138 272.08 87.029 256.971L7.029 176.971C-2.343 167.598 -2.343 152.402 7.029 143.03L87.029 63.03C102.057 48.003 128 58.563 128 80V128H488C501.255 128 512 138.745 512 152V168C512 181.255 501.255 192 488 192z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="running" />
+      <glyph
+         id="glyph15009"
+         d=" M256 504C119.033 504 8 392.967 8 256S119.033 8 256 8S504 119.033 504 256S392.967 504 256 504zM336 256C336 211.888 300.112 176 256 176S176 211.888 176 256S211.888 336 256 336S336 300.112 336 256z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="stable" />
+      <glyph
+         id="glyph15011"
+         d=" M496 306.793232C481.3473759999997 291.6353439999998 419.7052640000002 256.2669120000001 419.7052640000002 256.2669120000001L393.431584 288.0984960000001C386.8631519999999 253.7406080000001 390.905264 92.5616479999999 393.431584 18.793232C293.3894719999999 3.1300799999999 183.2421119999999 14.245856 127.6631520000001 18.793232C133.7263199999998 108.2248159999999 123.1157919999996 288.0984960000001 123.1157919999996 288.0984960000001C123.1157919999996 288.0984960000001 108.4631520000003 274.4563840000001 96.3368479999999 256.772176C61.9789440000004 256.2669120000001 16 300.2248159999999 16 300.2248159999999C16 300.2248159999999 64.5052640000004 389.15112 81.6842079999997 417.4458559999998C95.3263200000001 439.67744 157.9789440000004 465.4458559999998 163.0315840000003 468.4774400000001C165.0526239999999 469.4879679999999 174.6526240000003 474.0353439999999 185.2631520000005 479.0879679999998C187.284208 480.0984960000001 189.3052639999996 479.0879679999998 190.3157920000003 477.5721760000001C201.9368480000003 458.3721759999999 227.1999999999998 444.7300799999998 256.5052640000004 444.7300799999998C285.810528 444.7300799999998 311.5789439999999 458.3721759999999 323.1999999999998 478.07744C324.2105279999996 479.5932320000002 326.2315840000001 480.60376 328.2526239999998 479.5932320000002C353.0105279999998 467.4669119999999 390.3999999999997 448.2669120000001 405.5578880000003 435.6353439999998C428.8000000000002 415.9300800000001 478.8210559999998 334.07744 496 306.793232z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="tshirt" />
+      <glyph
+         id="glyph15013"
+         d=" M256 504C119 504 8 393 8 256S119 8 256 8S504 119 504 256S393 504 256 504zM352 176C352 167.2 344.8 160 336 160H176C167.2 160 160 167.2 160 176V336C160 344.8 167.2 352 176 352H336C344.8 352 352 344.8 352 336V176z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="unmeasured" />
+      <glyph
+         id="glyph15015"
+         d=" M384.3907536000001 299.3691904000002C392.3892192 285.071872 382.3493216000001 267.1999999999998 366.3740592000001 267.1999999999998L158.4235182399999 267.1999999999998C142.41748952 267.1999999999998 132.423959024 285.0995776 140.406823424 299.3691904000002L244.38339392 485.2817010240001C252.38575824 499.5857227679999 272.4287192000001 499.5598040159998 280.4167836800001 485.2817010240001L384.3907536000001 299.3691904000002zM262.4000888 337.80624928C251.39125856 337.80624928 242.4667611200001 328.6028592000003 242.4667611200001 317.25C242.4667611200001 305.8971407999998 251.39125856 296.6937503999998 262.4000888 296.6937503999998C273.4089190400001 296.6937503999998 282.33341648 305.8971407999998 282.33341648 317.25C282.33341648 328.6028592000003 273.4089190400001 337.80624928 262.4000888 337.80624928zM243.47512752 411.6952424000001L246.6895932799999 350.92024288C246.83995984 348.0763304000002 249.1201592000001 345.8499992000002 251.8817918400001 345.8499992000002L272.91838576 345.8499992000002C275.6800184 345.8499992000002 277.9602177600001 348.0763304000002 278.11058432 350.92024288L281.3250500800001 411.6952424000001C281.48755008 414.7670611200001 279.1159174400001 417.3499985600002 276.1328515199999 417.3499985600002L248.6668926400001 417.3499985600002C245.6838268800001 417.3499985600002 243.3126275200001 414.7670611200001 243.47512752 411.6952424000001z M149.0432000000001 166.7968000000001L174.0416 75.9423999999999L202.5344 166.7968000000001L247.1551999999999 166.7968000000001L194.7392 16L151.7312 16L101.7344000000001 166.7968000000001L149.0432000000001 166.7968000000001zM383.4368 227.2768000000001L383.4368 99.0592000000002L402.2528 99.0592000000002L402.2528 62.5023999999999L383.4368 62.5023999999999L383.4368 16L340.4288 16L340.4288 62.5023999999999L259.7888000000001 62.5023999999999L259.7888000000001 99.8656000000001L344.9984 227.2768000000001L383.4368 227.2768000000001zM340.4288 99.0592000000002L340.4288 160.8832000000002L299.0336 99.0592000000002L340.4288 99.0592000000002z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="unreachableipv4" />
+      <glyph
+         id="glyph15017"
+         d=" M381.1907535999998 299.3691904000002C389.1892191999999 285.071872 379.1493215999998 267.1999999999998 363.1740592 267.1999999999998L155.2235182399999 267.1999999999998C139.21748952 267.1999999999998 129.2239590240001 285.0995776 137.206823424 299.3691904000002L241.18339392 485.2817010240001C249.1857582400002 499.5857227679999 269.2287191999998 499.5598040159998 277.2167836799998 485.2817010240001L381.1907535999998 299.3691904000002zM259.2000888000001 337.80624928C248.1912585600002 337.80624928 239.2667611199999 328.6028592000003 239.2667611199999 317.25C239.2667611199999 305.8971407999998 248.1912585600002 296.6937503999998 259.2000888000001 296.6937503999998C270.2089190400001 296.6937503999998 279.13341648 305.8971407999998 279.13341648 317.25C279.13341648 328.6028592000003 270.2089190400001 337.80624928 259.2000888000001 337.80624928zM240.2751275200002 411.6952424000001L243.4895932799999 350.92024288C243.6399598400002 348.0763304000002 245.9201591999999 345.8499992000002 248.6817918400001 345.8499992000002L269.7183857600002 345.8499992000002C272.4800184 345.8499992000002 274.7602177600001 348.0763304000002 274.9105843199999 350.92024288L278.1250500800001 411.6952424000001C278.28755008 414.7670611200001 275.9159174400001 417.3499985600002 272.9328515199999 417.3499985600002L245.4668926399999 417.3499985600002C242.4838268799999 417.3499985600002 240.1126275199999 414.7670611200001 240.2751275200002 411.6952424000001z M155.4432000000002 166.7968000000001L180.4416000000001 75.9423999999999L208.9344000000001 166.7968000000001L253.5551999999998 166.7968000000001L201.1392000000001 16L158.1311999999998 16L108.1343999999999 166.7968000000001L155.4432000000002 166.7968000000001zM360.8064 190.7200000000003C359.0143904000002 192.1536064000002 356.6400144 193.1839967999999 353.6832 193.8112000000001C350.7263856 194.4384031999998 347.7248159999999 194.752 344.6783999999998 194.752C340.0191759999998 194.752 335.9872175999999 193.6320111999999 332.5824000000003 191.3919999999998C329.1775824000001 189.1519888000003 326.3552112000002 186.0160207999998 324.1152000000002 181.9839999999999C321.8751888000002 177.9519792000001 320.1728063999999 173.1584272 319.0079999999998 167.6032C317.8431936000002 162.0479728 316.9920032 155.8656335999999 316.4544000000001 149.0560000000001C321.6512256000001 151.0272095999999 326.8927727999999 152.3263968000001 332.1792000000001 152.9535999999998C337.4656272000002 153.5808032 342.5279759999999 153.8944000000001 347.3663999999999 153.8944000000001C358.1184543999998 153.8944000000001 367.1679632000001 152.371216 374.5151999999998 149.3247999999999C381.8624368000001 146.2783840000002 387.8207776 141.8432287999999 392.3904000000003 136.0192000000002C396.9600224000001 130.1951712 400.2751904000002 123.1168416000001 402.3360000000003 114.7840000000001C404.3968095999999 106.4511584000002 405.4272000000001 96.9984528 405.4272000000001 86.4256C405.4272000000001 71.1935232000001 403.5904175999999 58.7392479999999 399.9168 49.0623999999998C396.2431824 39.3855520000002 391.2704320000003 31.8144272 384.9984 26.3487999999998C378.7263680000001 20.8831728 371.5136400000001 17.1200096000002 363.3600000000002 15.0592000000001C355.2063600000002 12.9983904000001 346.6496447999998 11.9679999999998 337.6896000000002 11.9679999999998C326.5791439999998 11.9679999999998 316.94724 13.4463856000002 308.7936 16.4032000000002C300.63996 19.3600144000002 293.8304272000001 24.7359615999999 288.3647999999999 32.5311999999999C282.8991728000001 40.3264383999999 278.8224128000002 50.9439327999999 276.1343999999999 64.384C273.4463872000001 77.8240672000002 272.1023999999998 95.0270943999999 272.1023999999998 115.9935999999998C272.1023999999998 135.8848991999998 273.4015872 153.0879279999999 276 167.6032C278.5984128 182.1184720000001 282.7647711999998 194.0799536 288.4992000000002 203.4879999999998C294.2336288000002 212.8960464000002 301.7599535999998 219.8847776000002 311.0783999999999 224.4544000000001C320.3968464 229.0240223999999 331.6863343999999 231.3087999999998 344.9472000000001 231.3087999999998C357.1328607999999 231.3087999999998 368.3327488 229.6064176 378.5472 226.2015999999999C388.7616512 222.7967823999998 396.4671743999998 218.4064272000001 401.6639999999998 213.0304000000001L401.6639999999998 172.4416000000001L360.8064 172.4416000000001L360.8064 190.7200000000003zM338.4960000000001 120.8319999999999C335.449584 120.8319999999999 331.9552192000001 120.4736032000001 328.0128 119.7568000000001C324.0703807999999 119.0399968000002 320.0384208000001 117.9648063999998 315.9168 116.5311999999999C316.0960015999999 102.9119312000003 316.6783952000001 91.7568431999998 317.6639999999998 83.0655999999999C318.6496047999999 74.3743568 320.0831904000002 67.4752256000002 321.9648000000002 62.3679999999999C323.8464095999998 57.2607744000002 326.2207856 53.7216096000002 329.0880000000002 51.7503999999999C331.9552144 49.7791904000001 335.4495791999998 48.7936 339.5711999999999 48.7936C346.9184368000001 48.7936 352.6079792000001 51.7951696 356.6399999999999 57.7984000000001C360.6720208000002 63.8016304000003 362.6880000000001 72.9855376 362.6880000000001 85.3503999999998C362.6880000000001 90.5472255999998 362.2848048000001 95.3407775999999 361.4784 99.7312000000002C360.6719951999999 104.1216224 359.3280095999999 107.8847839999999 357.4463999999998 111.0208000000002C355.5647903999998 114.1568160000002 353.056016 116.5759920000001 349.9200000000001 118.2784000000002C346.7839840000002 119.9808080000003 342.9760224000002 120.8319999999999 338.4960000000001 120.8319999999999z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="unreachableipv6" />
+      <glyph
+         id="glyph15019"
+         d=" M452.9230767999998 352C459.0403071999999 352 464 356.8357 464 362.8L464 398.8C464 404.7643000000001 459.0403071999999 409.6 452.9230767999998 409.6L434.4615391999996 409.6L434.4615391999996 452.8C434.4615391999996 476.659 414.6246160000001 496 390.1538464000005 496L124.3076923199997 496C99.8369230400003 496 80 476.659 80 452.8L80 78.4C80 54.5409999999999 99.8369230400003 35.2 124.3076923199997 35.2L390.1538464000005 35.2C414.6246160000001 35.2 434.4615391999996 54.5409999999999 434.4615391999996 78.4L434.4615391999996 121.6L452.9230767999998 121.6C459.0403071999999 121.6 464 126.4356992000001 464 132.4L464 168.4C464 174.3643008 459.0403071999999 179.2000000000001 452.9230767999998 179.2000000000001L434.4615391999996 179.2000000000001L434.4615391999996 236.8L452.9230767999998 236.8C459.0403071999999 236.8 464 241.6356992 464 247.6L464 283.6C464 289.5643008 459.0403071999999 294.4 452.9230767999998 294.4L434.4615391999996 294.4L434.4615391999996 352L452.9230767999998 352z M167.4975744000003 437.9845376L188.5962399999999 318.0165440000001L213.3749055999997 437.9845376H255.3269120000005L208.9589056000004 245.1525440000001H166.7615744000004L122.6015744000004 437.9845376000001z M273.4892319999999 424.7365376Q278.3959039999999 429.8885376 285.0199039999999 433.077872Q291.8892319999999 436.2672048 299.2492319999999 438.229872Q306.8545599999999 440.1925376000001 314.4599039999999 440.9285376000001Q322.3105599999999 441.6645376 329.4252319999999 441.6645376Q342.9185599999999 441.6645376 354.2039039999999 438.7205376Q365.7345599999999 436.0218720000001 373.8305599999999 429.1525376Q382.1718879999999 422.5285392 386.5878879999999 410.7525392Q391.2492319999999 399.221872 391.2492319999999 381.557872Q391.2492319999999 371.7445392 388.0598879999999 361.1952064Q384.8705599999999 350.8912064 377.0198879999998 338.3792064000001Q369.4145599999998 326.112544 356.1665599999999 311.3925440000001Q343.1639039999999 296.672544 323.0465599999999 278.517872H393.9478879999998V245.1525440000001H274.4705599999998V277.291216Q297.5319039999998 297.1632 312.2519039999998 312.373872Q326.9719039999998 327.829872 335.3132319999998 340.3418736Q343.8999039999998 352.8538736000001 347.0892319999998 363.1578736Q350.2785599999998 373.7072064 350.2785599999998 383.765872Q350.2785599999998 397.749872 344.8812319999998 402.9018720000001Q339.4839039999997 408.2992048 329.6705599999998 408.2992048Q324.0279039999998 408.2992048 319.3665599999998 406.8272048Q314.9505599999998 405.6005328 310.7799039999998 403.1472048V387.9365392H273.4892319999998z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="v2dir" />
+      <glyph
+         id="glyph15021"
+         d=" M504 256C504 119.033 392.967 8 256 8S8 119.033 8 256S119.033 504 256 504S504 392.967 504 256zM227.314 124.686L411.314 308.686C417.562 314.934 417.562 325.065 411.314 331.313L388.687 353.94C382.439 360.189 372.308 360.189 366.059 353.94L216 203.882L145.941 273.9410000000001C139.693 280.189 129.562 280.189 123.313 273.9410000000001L100.686 251.314C94.438 245.0660000000001 94.438 234.935 100.686 228.687L204.686 124.687C210.935 118.438 221.065 118.438 227.314 124.686z"
+         horiz-adv-x="512"
+         unicode=""
+         glyph-name="valid" />
+    </font>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-9"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-3" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-9-4"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-3-5" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-0"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-6" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-5"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-5" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-5-9"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-5-3" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-4"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-52" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-47"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-4" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker9036-6"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path9034-8" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8855-5"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8853-8" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker8845-7"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="TriangleOutM">
+      <path
+         inkscape:connector-curvature="0"
+         transform="scale(0.4)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path8843-0" />
+    </marker>
+    <linearGradient
+       inkscape:collect="always"
+       xlink:href="#linearGradient-1"
+       id="linearGradient1167"
+       x1="256"
+       y1="512"
+       x2="256"
+       y2="0"
+       gradientUnits="userSpaceOnUse" />
+    <filter
+       id="filter-3-0"
+       filterUnits="objectBoundingBox"
+       height="1.1043478"
+       width="1.2424242"
+       y="-0.052173913"
+       x="-0.13852814">
+      <feOffset
+         id="feOffset1122-4"
+         result="shadowOffsetOuter1"
+         in="SourceAlpha"
+         dy="0"
+         dx="-8" />
+      <feGaussianBlur
+         id="feGaussianBlur1124-2"
+         result="shadowBlurOuter1"
+         in="shadowOffsetOuter1"
+         stdDeviation="10" />
+      <feColorMatrix
+         id="feColorMatrix1126-9"
+         in="shadowBlurOuter1"
+         type="matrix"
+         values="0 0 0 0 0.250980392   0 0 0 0 0.250980392   0 0 0 0 0.250980392  0 0 0 0.2 0" />
+    </filter>
+    <linearGradient
+       inkscape:collect="always"
+       xlink:href="#linearGradient-1"
+       id="linearGradient1169"
+       x1="198.26646"
+       y1="346.52609"
+       x2="198.26646"
+       y2="20.550627"
+       gradientTransform="scale(0.7086423,1.4111492)"
+       gradientUnits="userSpaceOnUse" />
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6925-3"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"
+       viewBox="0 0 8.886927 5.078244"
+       markerWidth="8.8869267"
+       markerHeight="5.0782437"
+       preserveAspectRatio="xMidYMid">
+      <path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6923-6" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6500"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"
+       viewBox="0 0 8.886927 5.078244"
+       markerWidth="8.8869267"
+       markerHeight="5.0782437"
+       preserveAspectRatio="xMidYMid">
+      <path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6498" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker6925-3-3"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Mend"
+       viewBox="0 0 8.886927 5.078244"
+       markerWidth="8.8869267"
+       markerHeight="5.0782437"
+       preserveAspectRatio="xMidYMid">
+      <path
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path6923-6-5" />
+    </marker>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.92007598"
+     inkscape:cx="503.21931"
+     inkscape:cy="80.971573"
+     inkscape:document-units="mm"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     units="px"
+     inkscape:window-width="1870"
+     inkscape:window-height="1000"
+     inkscape:window-x="20"
+     inkscape:window-y="50"
+     inkscape:window-maximized="1"
+     inkscape:showpageshadow="2"
+     inkscape:pagecheckerboard="0"
+     inkscape:deskcolor="#d1d1d1" />
+  <metadata
+     id="metadata5">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-125,-5.8683279)">
+    <g
+       id="g1550"
+       transform="translate(98.954167,-47.360417)" />
+    <g
+       id="g14832"
+       transform="translate(13.751947)" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:10.5833px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
+       x="367.51221"
+       y="80.15081"
+       id="text5410"><tspan
+         sodipodi:role="line"
+         id="tspan5408"
+         x="367.51221"
+         y="80.15081"
+         style="stroke-width:0.264583">Logs</tspan></text>
+    <g
+       id="g5490"
+       transform="matrix(1.3558592,0,0,1.3558592,-167.39878,-49.653722)">
+      <image
+         y="80.505188"
+         x="371.24182"
+         id="image1285-2"
+         xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGAAAABgCAYAAADimHc4AAAABHNCSVQICAgIfAhkiAAAGplJREFU eJztnXl4VOW9xz/nZLKHyTYzSUgmJCGEJUFI2WWxslgQlABXqBQUqVCBKtzLvbbWXqoi1bba6oW0 ipeqtNVSFsENUbDVikoggFEQSAIJIdtk38g2M+f+8c6QSTJJJmcmIfc+9/s882Ry5rzLedff8v29 BwYm7g5JCTlvTBtSFTEj4jKwUmU+8/39/T+MjY095+vr+ydgsAfr6BFIN7sCTjDVuDj2o9v3zfJH AkuzhYxNJyzZOy+uxcofe5HPvZMmTXp9yZIl3oGBgZw7d4733nsvPz8/fyxQ3VeV7y28bnYFOkI7 QvvqjL98N8kn2AcAWSMT/b1oOXd3zpDW6taXXc1nyJAhh1avXq0LCAgAwGAwEBQUFJKZmXkd+LRP Kq8C8s2uQCcohAVEB7S7JHvLBI8I9u9NNjqdTuvn59fuWlJSEkFBQZPcr6TnMOA6oC6n7kjFqfJ2 16qyKqn9tvbL3uRTVlaW3/FaQUEBFovlazer6FEMuCUIhY8rT1cs8o/0jwiMCaDoo2KynjxTXnmm ci1Q5mo2dXV1Snl5+ZykpCSNt7c3dXV17NmzJ8tkMv1LH9Z+wEAD3AXcB4SoSG/QaDWP+ep9vwAO AvEq6zE+Ojq6IC4u7oqfn9/bQJTKfP5XYezw1Dklc5b9TFmyIV0ZOvq2WmCVyrx+COxyoy6zgb+7 kX60n5/f2wkJCZdiYmIygQVu5OUUHhdDI4eMvrD2yXeG+weFAmC1Wvjbi2sbvzq+Lwxo6mV2qcAf bX/V4HFgEPBTFWljExISMtesWaPTarU0NDSwd+/e1rNnzz7Q2tr6F5X16QRPb8JJyRPnJ9kbH0CW vYgdMdEfGKMiv2+AYYCvyvpMBnq1edsxaNCgH6Wlpem0Wi0AgYGBrFq1yjsiIuInKuviFJ7uAKmu qqTTxUEhEQC3qMivFbgAjFZZn0nACTUJJUkaaTQaO13X6XQe1aY93QEXi/O+vlxenHvjgrm1meOH X64H3laZ52lgnIp08Yglr1hNobW1tVcuXbrU7lpjYyPl5eWdR5gb8LgYWltZ/FbO2WOTrzdUx1w4 /ZFy/N0/VF3+5pNtwIcqsxwMfAd4t5fp5iHW/70qy71oMpnuDQ8PD9Lr9dTW1nLw4MH68+fPrwMu 9Zh6AOB7QBwwA8gHtCrzmQCcUpHuBWCzyjIBNgCHAgICdsTGxp6yibGd16T/JdgB7FSZ1heoB7x7 me4LYJrKMhOAUmCoyvQDDkHAZYRcrgZn6Z0o6gPUAb2yH9kgAf8Afqwi7YDGLOAKojOcYnjq7MHD p949yPZvELAEeA24ilDKXMVExLK3C1gIOFr3fHpI+zBCeRuIpnq38TLwe2c/3PPIzo1P7C5o3fDs J9e8vf2OSZLUAiheXl4mxEaa6Hj/bfMejLlnffqqaXc9fJuT7AYDr0iSVA4okiQ1+en8js77Yn7x kqtLC6fuvq2rpSkRKEG96aPX0PRXQTb8O/A18F3ENLdDh8W8zjdAq4keekt0THySf+v1yt9fu3bt zxaLJRNQAL0tXTIQZUy+bVXy5Luja6tKzNcuZR7Ju/j5p4gZdtn2d42iKD8CpoSGhv4g5NbQFfrJ hkEAtdnVLwBzAUezq4zQup+wpR8wWBweHn56xIgRRXq9/gvgVjfz+x6QAwQilpktsizX66OHWZY+ /PumibNXKcDPgWBgBXAAMCE6QQEUL4238p9/vKw8s69GeWZfjZJ62zLF8Xfb5xzwS4QyJgXFBq2d +OIkZcbemWb/yACLLMv1tnICbfXaBHzk5rPZEQHoPJHR3ClTpjRv375dSU9PV55++mklNTW1HNE4 7mAXcESSpDLAotfrDwJDEKYDBWgEWmjfoMXAMWA78Oj8+56+9su91crG336h6COG/RZ4FvgbQmSt 7pC2CCi0fV8NJOh0uncAqyRJpQibUQkQ6+ZzhQ8ePPibcePGmWfNmmXW6XSngOHdJeh2ozEajSc3 btw43t+/TZioqKjgqaee+pPZbL7PjYoGA7myLH9ltVofBs47/PYVkIIwQ3yAaNQPgMoOedwfojO+ VlddisXcEgZUOfwmI0b+QttnhO16FRCN6GCAMbIsP6soSqqiKD8H/tuNZyI0NPSjDRs2zI6KElZv k8nEG2+8UZidnT0EsDhL0+0eoNFoIhwbHyA8PJyYmJi4vLw8d+paA4y0Wq3OHCzLEErbtwhRsivI 1eUF9u8dH86K0AO+QFhCpwGPIDq60eG+r6xW6zxgLELUdQdTp0yZMsve+CD80EOHDo3Ozs5OA/Y7 S9RtB5hMprympiajo281Ozub6upqVRbGDujKu3XBxfSOZhSno8sBn9k+XcHdxgfIUxRFocOqotPp oJslu1tjXENDw2MvvfRSbUFBAVarlStXrnDo0KHS6urqSvpfguqI3nRAf6CwuLi4xvGCoiicOXPm OnDYnYxHGwyGPxgMhiOSJO1EWCbfA04iRMKbhfW0bbK9NVN4GgnAUeBPKSkpjZs3b1ZWrlyp3Hrr rS3Axr4qdBXCXvIYN8e5/zBtHXCz2B1ewL8h9IlHbf8nIsTbJYChrysQDbwPZND/s2ETbR1wMzAa 8dx/p4OWfjPwAGI2/JT+mw2bEY1v7qfy7PABnkIoh2sYQDajGNpmw6h+KO9RRAc090NZdkxBiLJv MQCJvna8LklSHWJ58hT8EBbO1cDvEBteHaIDrnuwnK4gA+mIUb+kH8pTDa0kSZWyLH/gofxkRKMX 09nWY/90p6x5Ep8htPFBPd14M/EkQiZXy2KQdbpYuyp5O3CGrhteQZgrulOwPIlbEBr2z/upvF5D L0lSg06nO6QirXTniq1vrHnycOGm335xffSURbl0buwrCH/Cw4jO6XMRryO0Wu37sizX4L4x0qOQ 169f/4u5c+dment7m1HhzJhx18Obt75pumFe/uXeasWYNMHe8FUIiacnT1Z/IBmwBgQEvDBt2rTQ Hu92AXZzQgCwVpKkkYqinEaMNJfwwAMP3J+cnPxEcnIydXV1tcePHw+llw6NqLjRqRrvNvKbJEno Bw9TCi6d3IFY1ip6k18f4tyMGTMKFy1atLG+vn6Boigzjh8/XuROhhrAEBMT89mUKVOGxcXFUVhY qBw7dmxpaWnpYoTVsls0NDQUNDc3t3p7e3sXFRVpgUzgE4SYmOFKJUyFOdcc/7dazFSZ8iWEL3gg NH4oIk5tTWBgYIyPjw+hoaFD9Xp9CsLX4Co26fX6JUBFWVnZ48A5ycfH5+VVq1atHTOmjbpZUFDA c889t9tsNt/vSq6RkZH/9PPzuyUvL+93wM8QtpnFCHm5J3hpfPwPj/vuvXPm3beVatNVvjyyiy+P 3DDNP0QvZmQfYSdC6SI0NLRo/vz5hrKysqIjR44McTF9SGxs7D+WLVs2JjY2lurqag4cOFCXlZV1 t5SQkHBp8+bNwzqm2Lp168WSkpIRznLrgABJkir1ev2rJpPpScSIaETEBbS6kP4ZbOzlgEFhSmN9 7W5FMd9Hm4ZpRcQZODKShyJs/PZ7LAh3okdpgw5YhHCNlgCDY2NjXyooKFilKEoI7f0LTuHn5/ez FStWbEtNbc+s2bZtW5amvLy8rKWlZZiPT9se19raiizL3gjH+UmHj7O1/XuKoviaTKY/IfjzEvAO rjV+FMKmA8D1uspHgecQy9h/2S7LCGqK/UF/BMyhswmgFcGe2I5KRnQ3eAuxHMYCt1y9evXPwFqE NPZ+D2m9AgICJo8e3VkyDwsLi5Vra2t3HD582Cp8CQL79u1rKSoqWglsRazBSxGdUYawbT+FiICJ BBbKslyOeOi7bVm84+KD/QSh5YIYwc/Zvm+nvbytQTTufuAOnNtfvIHlCC/Yri7ucQd28XoR8Lks y3XAnR3u0SJm5o+BVxCDtrqystInJyen3Y2tra3U19ffCJfdkJKSYpoxY0Z9cnJyjo+Pz2NdVMIA zEdQN94DSm1mh/0IFtp1hHEszIUHCrDdbxc3nXF1fkX3ilh3n514thPm2PL9FECW5UOIJWkLYnnK RQgt/0RQMR9E8Fr9gZSRI0fWbNmyRUlPT1d27NihTJ8+3YLY325ARp1dPRZBwZhoq6BLkg9ittgb qyttVkY8ZLvGlSRZGTFurjJ1/jpl6vx1SmzSxK464XkVz9MV9LY87VLZjxGM7ycRAkcC3Xf4NJ1O tz8lJeWqXq/PlmX5P+ghQW/xfeBN4A3gBy7c/wpilIBwavzOyT0L6LCcJY2dxaIfvUiIvj1R+Vru Gf724hrKirIdL5sRDO1CF+rjCkyIjohEmN/dhic9SXYNOM/F+x2Juu91cU87guzw1Dnc99O/dmp8 gJihqTz4xDuER7ZTxDWIzdJTsNNnRnoqQ491gGaQZqx/pD+4pgV7IfwHIKSXHCf3DEdsuABIksxd P/wNXpquLRLasCjmrniq4+U1eI5AYJ9ersr/PcIjFZv0+1sfiFsedw9m+GLd57+8ujfP/tCOH2+H 7z4OZVttn45IxWGJTBo7q+PodoqRE+YRqNXRUHuD9hmF8E10ipxH2JhkhzooDt87XZs1a9a85ORk iouL11++fPlgZmZmj5aCnuCRDggfH36vb7CvBDAkbYj+6t48fS+S96jIAIToYnq+CfDy8kYbFunY AdD1XvcMLjIqdDodaWlpyLLM8OHDJ1qt1tmZmZlOyVa9gUc6oCa7+mTY2LA5srdMxemyEuBzxNLS itgIu/te7jzXPkcQvaCz1NfX09jYSGBgIE1NTRaz2ewRG5VHOuD4D/75eM6unJmt1S2Tq89X/Svw Vw9k2+L4T95F16JNr9dVUl6U2/GyM+KWo083C8F3kjp8ZPv3pqYmaefOnW8mJibOr6ys3JeRkfEP lyrUAzzGbiv9uPgSgt3sKRwFGrDRx0uvnufyuc9ISO4+7Cvj6Ou0trRb1bKAAie3OnZAMS6wK3Jy cmpsGq3bS48dnhRD7Q/pqcC2WoRecQN/276WKpOzvVQgJ+sffLz3Vx0vb+/idsfAcWcd5Axxtr+X Xby/R3iyA+zn8KR4MM8/OP5TU17Iy1vmcfLo67Q2t43yhroKPj34Aq8/s6zj6K+gvRXVEY4Hb3zs Yn3sYpjHOsCORYGBgZ8kJiaeDgoKep6e3YoSQvVeggiMmIvgAimIKe9JPIMTM4Ov/yDFEDNCiYxN VjTevl2ZIroK7g5B8InsxC5X3ItBCHHUHofgMT7qkunTp7c8//zzSnp6urJp0yYlLi6uiDZFyQfB n38AeBFhjKpGjIL9kiRVSpJ0CLGfNNs+fp1KcQ/Pod4o97iT/LY4/H7MxTosst1vZzq/jTC+HUI4 oWbTHQ1dlpdGREQcGzlyZF5ERMSXCFM2UkJCwqVHHnlkmLd3W4eePn2aXbt2fYCweQxDaKpnEDx6 +8euhLzk5eW11GKx6BA8yRkIQ5urJmlX8RQiyK+n2N8G2z2Oy+tG2vwLWoS5xD7q5yEicHrCboRb ch2wU5blUqvV+jFC4puIiMgZh7A7nUAYJU8gVoSEKVOmnF2+fLm/LMtUV1ezd+/ehrNnz86Sg4OD dY6NDzBq1CgCAwMlBCkqjPYz4BPa+4rftVgsoQgJ6IDtWl+wx7YgZuWjOLc3ZSJiifW2ejuSdl9A 1N8LYSy0N/6XuNb4GsSeoSBG/mSr1aqz5fUWgiE+05bvUoR1NxV4FaiMioras3jxYn9ZFmMiJCSE RYsWBWo0ms1yRUWFqWNp2dnZWCyWzxGjvqXj7x1wTJKkZqPRuII2H/BS+oazXwn8BsFGjnL4RALj EWGmjcDriJAkOyRJI73iF+l/CuHPALGeO1uenCEN0bgngSKDwbBSkqQmOh9AYkWccbQLYQQcA0QE BgZ624/PtEOn02EwGBLl4uLip3bv3t1y/bqgWJpMJt59993spqYmV48Ka0xOTr6QkpKyWqvV7rZd 87dVuq9gQfgJ7B9npuEdiLWZ5H9PYeE3i7zSvl08dtiDScjeMghXqKvSzxO2vw0Ip9Q9iqIcwTUz SmNZWVlOU1P7w8IuXrxIdXX1BbuNZF5MTMxWYFBJSclxs9m8Fhdp3/PmzRs1a9asr/z9/TVHjx7l rbfeqkVMvd/h3ADWrxiyLP6z29787lRHa9Dfl3z8acGBfGcR9s4gAUcQHjHmzJljXbBggXzixIkv 33jjjSku5jFm1KhRh9PS0qKioqLIz89n7969xfn5+VPsmvDha9euqYpjKiwsLG9tba3z9/cPNZvN VQgPWb2avPoAqYHR/kM7muKGLI7NKTjg8thQEGbx8cDmUaNGfV+j0ZCYmBiP6BxXAkS+On/+fFxp aeluWZbjy8vLMxRFeRYodNsUkZWVZYqNjZ106dKl3+bm5s5DbII3uwOigW3AfeUnKyQcYhfNDWZr RVbVSRV5ngL+48MPP1za0tJSZrFY7KKsq2ipqKj4vopyXYbBDXKuJxCDEBNfQ6zVQs6XUKIXGs13 Zd3dcscn8/LH/Wr8K2oLiIiIeEuW5euIowgGJLYiNsj+ihc7i5DSzDhXwiwI+T3W3+g/GPdML8kI Kedpdyrc1wiWJKlKlmVXtUt3UUXXGvCHCP3FI5Bl+T1JkqoYYNT0jvAHPpQkqZr+iaFqpM2eU4DQ Qx5BfYBIV7hTkqRa2sTRAYmpwEXElPcId74HeNE22h/t47L8gF8jdI57+7isXiMAIfNfpU3L7A8E 09YB6/upzPEIs/tBPHQQuLv+gBmI42W0iGnfFb+nL+B49lx/BeqdQhjcshDPvao/CpUQ/oGltJ39 GYjwNF3BgbvTzxhB2wxYdBPKH4uwlX2A+wc9dYmFKSkpVXfeead16dKlSmxsbCUiSC4H4a26mSGb E2jrALXHYboLDYLFXYYg2o7y9vbeZzQaT0ZFRR1AnHHXLbrjhvrHxcVd27RpU5jdXN3c3MyuXbuq zp07twT3zuX3BG6nzZg2GZWHdHsIycBzcXFx41avXq0PDw+ntraWAwcONJ08eXIF3Tjxu9sDFk6a NCnM0Vfg6+tLTExMMK7zP/sSjrPvZps+zoWEhGSlpaXpw8PDAdBqtdx///1+BoNhS3cJu+uARruJ 2hFBQUEynjkLwhl7wojwJL1Gm0u0K/RmE05CHDXwsy5+d5ucoNFoxiQkJLS7JkkSOp2uW2mpu4Lf zcvLMzl2QkNDAxkZGd/Qc1hOT1giSdJZWZbfpz2LYhVibb8fIdZmILxNzk4e7G4GeCE26c22PC4i RNUttA/wTpYk6TjtzzBVhfLy8jO5ue0JYY2NjdTW1nYbt9ZTfMB4o9F4YMKECcb6+nry8vJMly5d moXw+qiFHiHC7ZEkaZWiKMERERGHSktLNyIaIh5hRphAe4WuEEEEyAPyUlNT7545c+aYpqYmjhw5 8kpOTs41BFNjNGKGOhIDyhE8owREQMVfwsLCnq+srJwvSVKtoii1iEDBdjykXkIzbNiwvLS0tOi4 uDiamprYs2dPc0ZGxhLcFM8lhLw/C8+cBbQXYSoGoUw9I0lS03e+8x3rpk2blOnTp9v9zRqEn3U7 Yja0s/Vs2LBBSU9PV9LT05U77rijox3IjDh1cRfioFgNMPWOO+5QHnroIavRaLTaDm590laHcQh2 nLuHrSYHBwe/m5iYmB0UFHTMVna3cMUfcCMuygNYhlhO7BE0NcBjiqLsmDlz5rfx8fGDAgICtN9+ +22RJEl7ysrK/owQex9G2JbiEey0+Lq6uvXYtNGWlpbPEHSRQoSmeh7x9gwZGJ+QkPCCj4/P9xcu XAggNTc357z66quTaQs3ykT4kf8LEeinFudqamoW1NS4zlrvz5MPDQh2wnw6O/oL6+vrXygtLX3o /PnzWeXl5QoiOmaTl5dXkY0gsBIRg3wc4MKFC6/5+vr+pKWlpcxkMj3bIc/ZGo1mraIosy0WS+iV K1fMsiwfv3DhQoxOpwu3Wq3b6ByB/wRiabwLz1NqBgQOIKZ8d3Dck4IRcWf7EdGUvYlnO4pgUOxE kAPsEpNM94NuGmK5G9AmZzVYjnCeqKGqqHkZ26MI+ooauPO2jwGJSIQZV817xEBIJ7/uZZo5qD8J PQhh47pdZfqbDm8vL68XIiMjPw4JCfk1gknWrTbYA/YhDIG9gR4RUqoW9iP2DQhGXZ+9ANTT4fxj R44ceeSee+4xREREcPnyZQ4ePFiRm5t7K+pf/ZSPGI29pYQXIez3as/zeXz06NE/jY+PD/Lz8+PE iRPf5ufn34N4L4HH4NEOCAsL+3jdunW3Dx7c5o00mUxs27btz2azWc174fUIeV6NfP4+Yj1Xo7Vr hg8fnr1+/fo4jUbs2c3Nzbz88ssVFy9eHEzPdE2X4dEjf/V6/VDHxgdxhLvBYFD7TpYJCBldDc6i 3im/YPz48TcaH4Qh0mg0htN2IIlH4NEOKCkpudbS0n5wlJWVoShKr44wc8B41L3EDdzrgFM1NTWd YpcDAwPBg6MfPNwBNTU1z7755ps3iL5ms5n9+/dfLy4uTleZ5XgEI1kNzqJe8rqWk5NT6UiovX79 OhkZGXn0r9tVFRZFR0d/nZSUVBoWFpZJ5zN1eoNiejZLdwUZYYAL7OnGLnB7dHR00eLFi5XZs2cr SUlJRYggjP/zCPDy8vpNdHT0J4MHD76AehpIJPB3rVb7fnBw8LOoew+kBiGSdnVIlNsYMCd/2xEd HX1s5cqVM41GI83Nzezfv9+amZn5i6ampt5QAqOHDBny5dy5c2NGjBjB1atXefvttwtyc3OH0b+H ffeIm/XiA6eQZXnVtGnTbre/SNnX15fly5fL8fHxq3qTz6BBg9YuWLAg5pZbbsHHx4fExEQeeugh o1ar9UQEv0cxoDpAUZQJw4YN6zQrw8LCIumF5TYsLGzOqFHtvaYBAQGEh4erfTd9n2GgdcBXHd9i bbVaqaysbKYXy2VJSUl1VVVVu2stLS1YLJbqLpLcNNyMd790h6/r6uqWhoSE6AwGA2azmXfeeUc5 ceLEVnrhFLJYLGU1NTXLhg8f7mVndezfv781KytrPcI//P/oBmE+Pj6vJCUlXQ4LCzuFOCdUDRbG xMScGzNmTFVMTEy2r6/vgz0n6X/8D0yz1WBg2QSfAAAAAElFTkSuQmCC "
+         preserveAspectRatio="none"
+         height="22.692762"
+         width="22.692762" />
+      <image
+         y="73.462555"
+         x="394.38736"
+         id="image1285-2-0"
+         xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGAAAABgCAYAAADimHc4AAAABHNCSVQICAgIfAhkiAAAGplJREFU eJztnXl4VOW9xz/nZLKHyTYzSUgmJCGEJUFI2WWxslgQlABXqBQUqVCBKtzLvbbWXqoi1bba6oW0 ipeqtNVSFsENUbDVikoggFEQSAIJIdtk38g2M+f+8c6QSTJJJmcmIfc+9/s882Ry5rzLedff8v29 BwYm7g5JCTlvTBtSFTEj4jKwUmU+8/39/T+MjY095+vr+ydgsAfr6BFIN7sCTjDVuDj2o9v3zfJH AkuzhYxNJyzZOy+uxcofe5HPvZMmTXp9yZIl3oGBgZw7d4733nsvPz8/fyxQ3VeV7y28bnYFOkI7 QvvqjL98N8kn2AcAWSMT/b1oOXd3zpDW6taXXc1nyJAhh1avXq0LCAgAwGAwEBQUFJKZmXkd+LRP Kq8C8s2uQCcohAVEB7S7JHvLBI8I9u9NNjqdTuvn59fuWlJSEkFBQZPcr6TnMOA6oC6n7kjFqfJ2 16qyKqn9tvbL3uRTVlaW3/FaQUEBFovlazer6FEMuCUIhY8rT1cs8o/0jwiMCaDoo2KynjxTXnmm ci1Q5mo2dXV1Snl5+ZykpCSNt7c3dXV17NmzJ8tkMv1LH9Z+wEAD3AXcB4SoSG/QaDWP+ep9vwAO AvEq6zE+Ojq6IC4u7oqfn9/bQJTKfP5XYezw1Dklc5b9TFmyIV0ZOvq2WmCVyrx+COxyoy6zgb+7 kX60n5/f2wkJCZdiYmIygQVu5OUUHhdDI4eMvrD2yXeG+weFAmC1Wvjbi2sbvzq+Lwxo6mV2qcAf bX/V4HFgEPBTFWljExISMtesWaPTarU0NDSwd+/e1rNnzz7Q2tr6F5X16QRPb8JJyRPnJ9kbH0CW vYgdMdEfGKMiv2+AYYCvyvpMBnq1edsxaNCgH6Wlpem0Wi0AgYGBrFq1yjsiIuInKuviFJ7uAKmu qqTTxUEhEQC3qMivFbgAjFZZn0nACTUJJUkaaTQaO13X6XQe1aY93QEXi/O+vlxenHvjgrm1meOH X64H3laZ52lgnIp08Yglr1hNobW1tVcuXbrU7lpjYyPl5eWdR5gb8LgYWltZ/FbO2WOTrzdUx1w4 /ZFy/N0/VF3+5pNtwIcqsxwMfAd4t5fp5iHW/70qy71oMpnuDQ8PD9Lr9dTW1nLw4MH68+fPrwMu 9Zh6AOB7QBwwA8gHtCrzmQCcUpHuBWCzyjIBNgCHAgICdsTGxp6yibGd16T/JdgB7FSZ1heoB7x7 me4LYJrKMhOAUmCoyvQDDkHAZYRcrgZn6Z0o6gPUAb2yH9kgAf8Afqwi7YDGLOAKojOcYnjq7MHD p949yPZvELAEeA24ilDKXMVExLK3C1gIOFr3fHpI+zBCeRuIpnq38TLwe2c/3PPIzo1P7C5o3fDs J9e8vf2OSZLUAiheXl4mxEaa6Hj/bfMejLlnffqqaXc9fJuT7AYDr0iSVA4okiQ1+en8js77Yn7x kqtLC6fuvq2rpSkRKEG96aPX0PRXQTb8O/A18F3ENLdDh8W8zjdAq4keekt0THySf+v1yt9fu3bt zxaLJRNQAL0tXTIQZUy+bVXy5Luja6tKzNcuZR7Ju/j5p4gZdtn2d42iKD8CpoSGhv4g5NbQFfrJ hkEAtdnVLwBzAUezq4zQup+wpR8wWBweHn56xIgRRXq9/gvgVjfz+x6QAwQilpktsizX66OHWZY+ /PumibNXKcDPgWBgBXAAMCE6QQEUL4238p9/vKw8s69GeWZfjZJ62zLF8Xfb5xzwS4QyJgXFBq2d +OIkZcbemWb/yACLLMv1tnICbfXaBHzk5rPZEQHoPJHR3ClTpjRv375dSU9PV55++mklNTW1HNE4 7mAXcESSpDLAotfrDwJDEKYDBWgEWmjfoMXAMWA78Oj8+56+9su91crG336h6COG/RZ4FvgbQmSt 7pC2CCi0fV8NJOh0uncAqyRJpQibUQkQ6+ZzhQ8ePPibcePGmWfNmmXW6XSngOHdJeh2ozEajSc3 btw43t+/TZioqKjgqaee+pPZbL7PjYoGA7myLH9ltVofBs47/PYVkIIwQ3yAaNQPgMoOedwfojO+ VlddisXcEgZUOfwmI0b+QttnhO16FRCN6GCAMbIsP6soSqqiKD8H/tuNZyI0NPSjDRs2zI6KElZv k8nEG2+8UZidnT0EsDhL0+0eoNFoIhwbHyA8PJyYmJi4vLw8d+paA4y0Wq3OHCzLEErbtwhRsivI 1eUF9u8dH86K0AO+QFhCpwGPIDq60eG+r6xW6zxgLELUdQdTp0yZMsve+CD80EOHDo3Ozs5OA/Y7 S9RtB5hMprympiajo281Ozub6upqVRbGDujKu3XBxfSOZhSno8sBn9k+XcHdxgfIUxRFocOqotPp oJslu1tjXENDw2MvvfRSbUFBAVarlStXrnDo0KHS6urqSvpfguqI3nRAf6CwuLi4xvGCoiicOXPm OnDYnYxHGwyGPxgMhiOSJO1EWCbfA04iRMKbhfW0bbK9NVN4GgnAUeBPKSkpjZs3b1ZWrlyp3Hrr rS3Axr4qdBXCXvIYN8e5/zBtHXCz2B1ewL8h9IlHbf8nIsTbJYChrysQDbwPZND/s2ETbR1wMzAa 8dx/p4OWfjPwAGI2/JT+mw2bEY1v7qfy7PABnkIoh2sYQDajGNpmw6h+KO9RRAc090NZdkxBiLJv MQCJvna8LklSHWJ58hT8EBbO1cDvEBteHaIDrnuwnK4gA+mIUb+kH8pTDa0kSZWyLH/gofxkRKMX 09nWY/90p6x5Ep8htPFBPd14M/EkQiZXy2KQdbpYuyp5O3CGrhteQZgrulOwPIlbEBr2z/upvF5D L0lSg06nO6QirXTniq1vrHnycOGm335xffSURbl0buwrCH/Cw4jO6XMRryO0Wu37sizX4L4x0qOQ 169f/4u5c+dment7m1HhzJhx18Obt75pumFe/uXeasWYNMHe8FUIiacnT1Z/IBmwBgQEvDBt2rTQ Hu92AXZzQgCwVpKkkYqinEaMNJfwwAMP3J+cnPxEcnIydXV1tcePHw+llw6NqLjRqRrvNvKbJEno Bw9TCi6d3IFY1ip6k18f4tyMGTMKFy1atLG+vn6Boigzjh8/XuROhhrAEBMT89mUKVOGxcXFUVhY qBw7dmxpaWnpYoTVsls0NDQUNDc3t3p7e3sXFRVpgUzgE4SYmOFKJUyFOdcc/7dazFSZ8iWEL3gg NH4oIk5tTWBgYIyPjw+hoaFD9Xp9CsLX4Co26fX6JUBFWVnZ48A5ycfH5+VVq1atHTOmjbpZUFDA c889t9tsNt/vSq6RkZH/9PPzuyUvL+93wM8QtpnFCHm5J3hpfPwPj/vuvXPm3beVatNVvjyyiy+P 3DDNP0QvZmQfYSdC6SI0NLRo/vz5hrKysqIjR44McTF9SGxs7D+WLVs2JjY2lurqag4cOFCXlZV1 t5SQkHBp8+bNwzqm2Lp168WSkpIRznLrgABJkir1ev2rJpPpScSIaETEBbS6kP4ZbOzlgEFhSmN9 7W5FMd9Hm4ZpRcQZODKShyJs/PZ7LAh3okdpgw5YhHCNlgCDY2NjXyooKFilKEoI7f0LTuHn5/ez FStWbEtNbc+s2bZtW5amvLy8rKWlZZiPT9se19raiizL3gjH+UmHj7O1/XuKoviaTKY/IfjzEvAO rjV+FMKmA8D1uspHgecQy9h/2S7LCGqK/UF/BMyhswmgFcGe2I5KRnQ3eAuxHMYCt1y9evXPwFqE NPZ+D2m9AgICJo8e3VkyDwsLi5Vra2t3HD582Cp8CQL79u1rKSoqWglsRazBSxGdUYawbT+FiICJ BBbKslyOeOi7bVm84+KD/QSh5YIYwc/Zvm+nvbytQTTufuAOnNtfvIHlCC/Yri7ucQd28XoR8Lks y3XAnR3u0SJm5o+BVxCDtrqystInJyen3Y2tra3U19ffCJfdkJKSYpoxY0Z9cnJyjo+Pz2NdVMIA zEdQN94DSm1mh/0IFtp1hHEszIUHCrDdbxc3nXF1fkX3ilh3n514thPm2PL9FECW5UOIJWkLYnnK RQgt/0RQMR9E8Fr9gZSRI0fWbNmyRUlPT1d27NihTJ8+3YLY325ARp1dPRZBwZhoq6BLkg9ittgb qyttVkY8ZLvGlSRZGTFurjJ1/jpl6vx1SmzSxK464XkVz9MV9LY87VLZjxGM7ycRAkcC3Xf4NJ1O tz8lJeWqXq/PlmX5P+ghQW/xfeBN4A3gBy7c/wpilIBwavzOyT0L6LCcJY2dxaIfvUiIvj1R+Vru Gf724hrKirIdL5sRDO1CF+rjCkyIjohEmN/dhic9SXYNOM/F+x2Juu91cU87guzw1Dnc99O/dmp8 gJihqTz4xDuER7ZTxDWIzdJTsNNnRnoqQ491gGaQZqx/pD+4pgV7IfwHIKSXHCf3DEdsuABIksxd P/wNXpquLRLasCjmrniq4+U1eI5AYJ9ersr/PcIjFZv0+1sfiFsedw9m+GLd57+8ujfP/tCOH2+H 7z4OZVttn45IxWGJTBo7q+PodoqRE+YRqNXRUHuD9hmF8E10ipxH2JhkhzooDt87XZs1a9a85ORk iouL11++fPlgZmZmj5aCnuCRDggfH36vb7CvBDAkbYj+6t48fS+S96jIAIToYnq+CfDy8kYbFunY AdD1XvcMLjIqdDodaWlpyLLM8OHDJ1qt1tmZmZlOyVa9gUc6oCa7+mTY2LA5srdMxemyEuBzxNLS itgIu/te7jzXPkcQvaCz1NfX09jYSGBgIE1NTRaz2ewRG5VHOuD4D/75eM6unJmt1S2Tq89X/Svw Vw9k2+L4T95F16JNr9dVUl6U2/GyM+KWo083C8F3kjp8ZPv3pqYmaefOnW8mJibOr6ys3JeRkfEP lyrUAzzGbiv9uPgSgt3sKRwFGrDRx0uvnufyuc9ISO4+7Cvj6Ou0trRb1bKAAie3OnZAMS6wK3Jy cmpsGq3bS48dnhRD7Q/pqcC2WoRecQN/276WKpOzvVQgJ+sffLz3Vx0vb+/idsfAcWcd5Axxtr+X Xby/R3iyA+zn8KR4MM8/OP5TU17Iy1vmcfLo67Q2t43yhroKPj34Aq8/s6zj6K+gvRXVEY4Hb3zs Yn3sYpjHOsCORYGBgZ8kJiaeDgoKep6e3YoSQvVeggiMmIvgAimIKe9JPIMTM4Ov/yDFEDNCiYxN VjTevl2ZIroK7g5B8InsxC5X3ItBCHHUHofgMT7qkunTp7c8//zzSnp6urJp0yYlLi6uiDZFyQfB n38AeBFhjKpGjIL9kiRVSpJ0CLGfNNs+fp1KcQ/Pod4o97iT/LY4/H7MxTosst1vZzq/jTC+HUI4 oWbTHQ1dlpdGREQcGzlyZF5ERMSXCFM2UkJCwqVHHnlkmLd3W4eePn2aXbt2fYCweQxDaKpnEDx6 +8euhLzk5eW11GKx6BA8yRkIQ5urJmlX8RQiyK+n2N8G2z2Oy+tG2vwLWoS5xD7q5yEicHrCboRb ch2wU5blUqvV+jFC4puIiMgZh7A7nUAYJU8gVoSEKVOmnF2+fLm/LMtUV1ezd+/ehrNnz86Sg4OD dY6NDzBq1CgCAwMlBCkqjPYz4BPa+4rftVgsoQgJ6IDtWl+wx7YgZuWjOLc3ZSJiifW2ejuSdl9A 1N8LYSy0N/6XuNb4GsSeoSBG/mSr1aqz5fUWgiE+05bvUoR1NxV4FaiMioras3jxYn9ZFmMiJCSE RYsWBWo0ms1yRUWFqWNp2dnZWCyWzxGjvqXj7x1wTJKkZqPRuII2H/BS+oazXwn8BsFGjnL4RALj EWGmjcDriJAkOyRJI73iF+l/CuHPALGeO1uenCEN0bgngSKDwbBSkqQmOh9AYkWccbQLYQQcA0QE BgZ624/PtEOn02EwGBLl4uLip3bv3t1y/bqgWJpMJt59993spqYmV48Ka0xOTr6QkpKyWqvV7rZd 87dVuq9gQfgJ7B9npuEdiLWZ5H9PYeE3i7zSvl08dtiDScjeMghXqKvSzxO2vw0Ip9Q9iqIcwTUz SmNZWVlOU1P7w8IuXrxIdXX1BbuNZF5MTMxWYFBJSclxs9m8Fhdp3/PmzRs1a9asr/z9/TVHjx7l rbfeqkVMvd/h3ADWrxiyLP6z29787lRHa9Dfl3z8acGBfGcR9s4gAUcQHjHmzJljXbBggXzixIkv 33jjjSku5jFm1KhRh9PS0qKioqLIz89n7969xfn5+VPsmvDha9euqYpjKiwsLG9tba3z9/cPNZvN VQgPWb2avPoAqYHR/kM7muKGLI7NKTjg8thQEGbx8cDmUaNGfV+j0ZCYmBiP6BxXAkS+On/+fFxp aeluWZbjy8vLMxRFeRYodNsUkZWVZYqNjZ106dKl3+bm5s5DbII3uwOigW3AfeUnKyQcYhfNDWZr RVbVSRV5ngL+48MPP1za0tJSZrFY7KKsq2ipqKj4vopyXYbBDXKuJxCDEBNfQ6zVQs6XUKIXGs13 Zd3dcscn8/LH/Wr8K2oLiIiIeEuW5euIowgGJLYiNsj+ihc7i5DSzDhXwiwI+T3W3+g/GPdML8kI Kedpdyrc1wiWJKlKlmVXtUt3UUXXGvCHCP3FI5Bl+T1JkqoYYNT0jvAHPpQkqZr+iaFqpM2eU4DQ Qx5BfYBIV7hTkqRa2sTRAYmpwEXElPcId74HeNE22h/t47L8gF8jdI57+7isXiMAIfNfpU3L7A8E 09YB6/upzPEIs/tBPHQQuLv+gBmI42W0iGnfFb+nL+B49lx/BeqdQhjcshDPvao/CpUQ/oGltJ39 GYjwNF3BgbvTzxhB2wxYdBPKH4uwlX2A+wc9dYmFKSkpVXfeead16dKlSmxsbCUiSC4H4a26mSGb E2jrALXHYboLDYLFXYYg2o7y9vbeZzQaT0ZFRR1AnHHXLbrjhvrHxcVd27RpU5jdXN3c3MyuXbuq zp07twT3zuX3BG6nzZg2GZWHdHsIycBzcXFx41avXq0PDw+ntraWAwcONJ08eXIF3Tjxu9sDFk6a NCnM0Vfg6+tLTExMMK7zP/sSjrPvZps+zoWEhGSlpaXpw8PDAdBqtdx///1+BoNhS3cJu+uARruJ 2hFBQUEynjkLwhl7wojwJL1Gm0u0K/RmE05CHDXwsy5+d5ucoNFoxiQkJLS7JkkSOp2uW2mpu4Lf zcvLMzl2QkNDAxkZGd/Qc1hOT1giSdJZWZbfpz2LYhVibb8fIdZmILxNzk4e7G4GeCE26c22PC4i RNUttA/wTpYk6TjtzzBVhfLy8jO5ue0JYY2NjdTW1nYbt9ZTfMB4o9F4YMKECcb6+nry8vJMly5d moXw+qiFHiHC7ZEkaZWiKMERERGHSktLNyIaIh5hRphAe4WuEEEEyAPyUlNT7545c+aYpqYmjhw5 8kpOTs41BFNjNGKGOhIDyhE8owREQMVfwsLCnq+srJwvSVKtoii1iEDBdjykXkIzbNiwvLS0tOi4 uDiamprYs2dPc0ZGxhLcFM8lhLw/C8+cBbQXYSoGoUw9I0lS03e+8x3rpk2blOnTp9v9zRqEn3U7 Yja0s/Vs2LBBSU9PV9LT05U77rijox3IjDh1cRfioFgNMPWOO+5QHnroIavRaLTaDm590laHcQh2 nLuHrSYHBwe/m5iYmB0UFHTMVna3cMUfcCMuygNYhlhO7BE0NcBjiqLsmDlz5rfx8fGDAgICtN9+ +22RJEl7ysrK/owQex9G2JbiEey0+Lq6uvXYtNGWlpbPEHSRQoSmeh7x9gwZGJ+QkPCCj4/P9xcu XAggNTc357z66quTaQs3ykT4kf8LEeinFudqamoW1NS4zlrvz5MPDQh2wnw6O/oL6+vrXygtLX3o /PnzWeXl5QoiOmaTl5dXkY0gsBIRg3wc4MKFC6/5+vr+pKWlpcxkMj3bIc/ZGo1mraIosy0WS+iV K1fMsiwfv3DhQoxOpwu3Wq3b6ByB/wRiabwLz1NqBgQOIKZ8d3Dck4IRcWf7EdGUvYlnO4pgUOxE kAPsEpNM94NuGmK5G9AmZzVYjnCeqKGqqHkZ26MI+ooauPO2jwGJSIQZV817xEBIJ7/uZZo5qD8J PQhh47pdZfqbDm8vL68XIiMjPw4JCfk1gknWrTbYA/YhDIG9gR4RUqoW9iP2DQhGXZ+9ANTT4fxj R44ceeSee+4xREREcPnyZQ4ePFiRm5t7K+pf/ZSPGI29pYQXIez3as/zeXz06NE/jY+PD/Lz8+PE iRPf5ufn34N4L4HH4NEOCAsL+3jdunW3Dx7c5o00mUxs27btz2azWc174fUIeV6NfP4+Yj1Xo7Vr hg8fnr1+/fo4jUbs2c3Nzbz88ssVFy9eHEzPdE2X4dEjf/V6/VDHxgdxhLvBYFD7TpYJCBldDc6i 3im/YPz48TcaH4Qh0mg0htN2IIlH4NEOKCkpudbS0n5wlJWVoShKr44wc8B41L3EDdzrgFM1NTWd YpcDAwPBg6MfPNwBNTU1z7755ps3iL5ms5n9+/dfLy4uTleZ5XgEI1kNzqJe8rqWk5NT6UiovX79 OhkZGXn0r9tVFRZFR0d/nZSUVBoWFpZJ5zN1eoNiejZLdwUZYYAL7OnGLnB7dHR00eLFi5XZs2cr SUlJRYggjP/zCPDy8vpNdHT0J4MHD76AehpIJPB3rVb7fnBw8LOoew+kBiGSdnVIlNsYMCd/2xEd HX1s5cqVM41GI83Nzezfv9+amZn5i6ampt5QAqOHDBny5dy5c2NGjBjB1atXefvttwtyc3OH0b+H ffeIm/XiA6eQZXnVtGnTbre/SNnX15fly5fL8fHxq3qTz6BBg9YuWLAg5pZbbsHHx4fExEQeeugh o1ar9UQEv0cxoDpAUZQJw4YN6zQrw8LCIumF5TYsLGzOqFHtvaYBAQGEh4erfTd9n2GgdcBXHd9i bbVaqaysbKYXy2VJSUl1VVVVu2stLS1YLJbqLpLcNNyMd790h6/r6uqWhoSE6AwGA2azmXfeeUc5 ceLEVnrhFLJYLGU1NTXLhg8f7mVndezfv781KytrPcI//P/oBmE+Pj6vJCUlXQ4LCzuFOCdUDRbG xMScGzNmTFVMTEy2r6/vgz0n6X/8D0yz1WBg2QSfAAAAAElFTkSuQmCC "
+         preserveAspectRatio="none"
+         height="15.407085"
+         width="15.407085" />
+      <image
+         y="71.473213"
+         x="385.00128"
+         id="image1285-2-0-6"
+         xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGAAAABgCAYAAADimHc4AAAABHNCSVQICAgIfAhkiAAAGplJREFU eJztnXl4VOW9xz/nZLKHyTYzSUgmJCGEJUFI2WWxslgQlABXqBQUqVCBKtzLvbbWXqoi1bba6oW0 ipeqtNVSFsENUbDVikoggFEQSAIJIdtk38g2M+f+8c6QSTJJJmcmIfc+9/s882Ry5rzLedff8v29 BwYm7g5JCTlvTBtSFTEj4jKwUmU+8/39/T+MjY095+vr+ydgsAfr6BFIN7sCTjDVuDj2o9v3zfJH AkuzhYxNJyzZOy+uxcofe5HPvZMmTXp9yZIl3oGBgZw7d4733nsvPz8/fyxQ3VeV7y28bnYFOkI7 QvvqjL98N8kn2AcAWSMT/b1oOXd3zpDW6taXXc1nyJAhh1avXq0LCAgAwGAwEBQUFJKZmXkd+LRP Kq8C8s2uQCcohAVEB7S7JHvLBI8I9u9NNjqdTuvn59fuWlJSEkFBQZPcr6TnMOA6oC6n7kjFqfJ2 16qyKqn9tvbL3uRTVlaW3/FaQUEBFovlazer6FEMuCUIhY8rT1cs8o/0jwiMCaDoo2KynjxTXnmm ci1Q5mo2dXV1Snl5+ZykpCSNt7c3dXV17NmzJ8tkMv1LH9Z+wEAD3AXcB4SoSG/QaDWP+ep9vwAO AvEq6zE+Ojq6IC4u7oqfn9/bQJTKfP5XYezw1Dklc5b9TFmyIV0ZOvq2WmCVyrx+COxyoy6zgb+7 kX60n5/f2wkJCZdiYmIygQVu5OUUHhdDI4eMvrD2yXeG+weFAmC1Wvjbi2sbvzq+Lwxo6mV2qcAf bX/V4HFgEPBTFWljExISMtesWaPTarU0NDSwd+/e1rNnzz7Q2tr6F5X16QRPb8JJyRPnJ9kbH0CW vYgdMdEfGKMiv2+AYYCvyvpMBnq1edsxaNCgH6Wlpem0Wi0AgYGBrFq1yjsiIuInKuviFJ7uAKmu qqTTxUEhEQC3qMivFbgAjFZZn0nACTUJJUkaaTQaO13X6XQe1aY93QEXi/O+vlxenHvjgrm1meOH X64H3laZ52lgnIp08Yglr1hNobW1tVcuXbrU7lpjYyPl5eWdR5gb8LgYWltZ/FbO2WOTrzdUx1w4 /ZFy/N0/VF3+5pNtwIcqsxwMfAd4t5fp5iHW/70qy71oMpnuDQ8PD9Lr9dTW1nLw4MH68+fPrwMu 9Zh6AOB7QBwwA8gHtCrzmQCcUpHuBWCzyjIBNgCHAgICdsTGxp6yibGd16T/JdgB7FSZ1heoB7x7 me4LYJrKMhOAUmCoyvQDDkHAZYRcrgZn6Z0o6gPUAb2yH9kgAf8Afqwi7YDGLOAKojOcYnjq7MHD p949yPZvELAEeA24ilDKXMVExLK3C1gIOFr3fHpI+zBCeRuIpnq38TLwe2c/3PPIzo1P7C5o3fDs J9e8vf2OSZLUAiheXl4mxEaa6Hj/bfMejLlnffqqaXc9fJuT7AYDr0iSVA4okiQ1+en8js77Yn7x kqtLC6fuvq2rpSkRKEG96aPX0PRXQTb8O/A18F3ENLdDh8W8zjdAq4keekt0THySf+v1yt9fu3bt zxaLJRNQAL0tXTIQZUy+bVXy5Luja6tKzNcuZR7Ju/j5p4gZdtn2d42iKD8CpoSGhv4g5NbQFfrJ hkEAtdnVLwBzAUezq4zQup+wpR8wWBweHn56xIgRRXq9/gvgVjfz+x6QAwQilpktsizX66OHWZY+ /PumibNXKcDPgWBgBXAAMCE6QQEUL4238p9/vKw8s69GeWZfjZJ62zLF8Xfb5xzwS4QyJgXFBq2d +OIkZcbemWb/yACLLMv1tnICbfXaBHzk5rPZEQHoPJHR3ClTpjRv375dSU9PV55++mklNTW1HNE4 7mAXcESSpDLAotfrDwJDEKYDBWgEWmjfoMXAMWA78Oj8+56+9su91crG336h6COG/RZ4FvgbQmSt 7pC2CCi0fV8NJOh0uncAqyRJpQibUQkQ6+ZzhQ8ePPibcePGmWfNmmXW6XSngOHdJeh2ozEajSc3 btw43t+/TZioqKjgqaee+pPZbL7PjYoGA7myLH9ltVofBs47/PYVkIIwQ3yAaNQPgMoOedwfojO+ VlddisXcEgZUOfwmI0b+QttnhO16FRCN6GCAMbIsP6soSqqiKD8H/tuNZyI0NPSjDRs2zI6KElZv k8nEG2+8UZidnT0EsDhL0+0eoNFoIhwbHyA8PJyYmJi4vLw8d+paA4y0Wq3OHCzLEErbtwhRsivI 1eUF9u8dH86K0AO+QFhCpwGPIDq60eG+r6xW6zxgLELUdQdTp0yZMsve+CD80EOHDo3Ozs5OA/Y7 S9RtB5hMprympiajo281Ozub6upqVRbGDujKu3XBxfSOZhSno8sBn9k+XcHdxgfIUxRFocOqotPp oJslu1tjXENDw2MvvfRSbUFBAVarlStXrnDo0KHS6urqSvpfguqI3nRAf6CwuLi4xvGCoiicOXPm OnDYnYxHGwyGPxgMhiOSJO1EWCbfA04iRMKbhfW0bbK9NVN4GgnAUeBPKSkpjZs3b1ZWrlyp3Hrr rS3Axr4qdBXCXvIYN8e5/zBtHXCz2B1ewL8h9IlHbf8nIsTbJYChrysQDbwPZND/s2ETbR1wMzAa 8dx/p4OWfjPwAGI2/JT+mw2bEY1v7qfy7PABnkIoh2sYQDajGNpmw6h+KO9RRAc090NZdkxBiLJv MQCJvna8LklSHWJ58hT8EBbO1cDvEBteHaIDrnuwnK4gA+mIUb+kH8pTDa0kSZWyLH/gofxkRKMX 09nWY/90p6x5Ep8htPFBPd14M/EkQiZXy2KQdbpYuyp5O3CGrhteQZgrulOwPIlbEBr2z/upvF5D L0lSg06nO6QirXTniq1vrHnycOGm335xffSURbl0buwrCH/Cw4jO6XMRryO0Wu37sizX4L4x0qOQ 169f/4u5c+dment7m1HhzJhx18Obt75pumFe/uXeasWYNMHe8FUIiacnT1Z/IBmwBgQEvDBt2rTQ Hu92AXZzQgCwVpKkkYqinEaMNJfwwAMP3J+cnPxEcnIydXV1tcePHw+llw6NqLjRqRrvNvKbJEno Bw9TCi6d3IFY1ip6k18f4tyMGTMKFy1atLG+vn6Boigzjh8/XuROhhrAEBMT89mUKVOGxcXFUVhY qBw7dmxpaWnpYoTVsls0NDQUNDc3t3p7e3sXFRVpgUzgE4SYmOFKJUyFOdcc/7dazFSZ8iWEL3gg NH4oIk5tTWBgYIyPjw+hoaFD9Xp9CsLX4Co26fX6JUBFWVnZ48A5ycfH5+VVq1atHTOmjbpZUFDA c889t9tsNt/vSq6RkZH/9PPzuyUvL+93wM8QtpnFCHm5J3hpfPwPj/vuvXPm3beVatNVvjyyiy+P 3DDNP0QvZmQfYSdC6SI0NLRo/vz5hrKysqIjR44McTF9SGxs7D+WLVs2JjY2lurqag4cOFCXlZV1 t5SQkHBp8+bNwzqm2Lp168WSkpIRznLrgABJkir1ev2rJpPpScSIaETEBbS6kP4ZbOzlgEFhSmN9 7W5FMd9Hm4ZpRcQZODKShyJs/PZ7LAh3okdpgw5YhHCNlgCDY2NjXyooKFilKEoI7f0LTuHn5/ez FStWbEtNbc+s2bZtW5amvLy8rKWlZZiPT9se19raiizL3gjH+UmHj7O1/XuKoviaTKY/IfjzEvAO rjV+FMKmA8D1uspHgecQy9h/2S7LCGqK/UF/BMyhswmgFcGe2I5KRnQ3eAuxHMYCt1y9evXPwFqE NPZ+D2m9AgICJo8e3VkyDwsLi5Vra2t3HD582Cp8CQL79u1rKSoqWglsRazBSxGdUYawbT+FiICJ BBbKslyOeOi7bVm84+KD/QSh5YIYwc/Zvm+nvbytQTTufuAOnNtfvIHlCC/Yri7ucQd28XoR8Lks y3XAnR3u0SJm5o+BVxCDtrqystInJyen3Y2tra3U19ffCJfdkJKSYpoxY0Z9cnJyjo+Pz2NdVMIA zEdQN94DSm1mh/0IFtp1hHEszIUHCrDdbxc3nXF1fkX3ilh3n514thPm2PL9FECW5UOIJWkLYnnK RQgt/0RQMR9E8Fr9gZSRI0fWbNmyRUlPT1d27NihTJ8+3YLY325ARp1dPRZBwZhoq6BLkg9ittgb qyttVkY8ZLvGlSRZGTFurjJ1/jpl6vx1SmzSxK464XkVz9MV9LY87VLZjxGM7ycRAkcC3Xf4NJ1O tz8lJeWqXq/PlmX5P+ghQW/xfeBN4A3gBy7c/wpilIBwavzOyT0L6LCcJY2dxaIfvUiIvj1R+Vru Gf724hrKirIdL5sRDO1CF+rjCkyIjohEmN/dhic9SXYNOM/F+x2Juu91cU87guzw1Dnc99O/dmp8 gJihqTz4xDuER7ZTxDWIzdJTsNNnRnoqQ491gGaQZqx/pD+4pgV7IfwHIKSXHCf3DEdsuABIksxd P/wNXpquLRLasCjmrniq4+U1eI5AYJ9ersr/PcIjFZv0+1sfiFsedw9m+GLd57+8ujfP/tCOH2+H 7z4OZVttn45IxWGJTBo7q+PodoqRE+YRqNXRUHuD9hmF8E10ipxH2JhkhzooDt87XZs1a9a85ORk iouL11++fPlgZmZmj5aCnuCRDggfH36vb7CvBDAkbYj+6t48fS+S96jIAIToYnq+CfDy8kYbFunY AdD1XvcMLjIqdDodaWlpyLLM8OHDJ1qt1tmZmZlOyVa9gUc6oCa7+mTY2LA5srdMxemyEuBzxNLS itgIu/te7jzXPkcQvaCz1NfX09jYSGBgIE1NTRaz2ewRG5VHOuD4D/75eM6unJmt1S2Tq89X/Svw Vw9k2+L4T95F16JNr9dVUl6U2/GyM+KWo083C8F3kjp8ZPv3pqYmaefOnW8mJibOr6ys3JeRkfEP lyrUAzzGbiv9uPgSgt3sKRwFGrDRx0uvnufyuc9ISO4+7Cvj6Ou0trRb1bKAAie3OnZAMS6wK3Jy cmpsGq3bS48dnhRD7Q/pqcC2WoRecQN/276WKpOzvVQgJ+sffLz3Vx0vb+/idsfAcWcd5Axxtr+X Xby/R3iyA+zn8KR4MM8/OP5TU17Iy1vmcfLo67Q2t43yhroKPj34Aq8/s6zj6K+gvRXVEY4Hb3zs Yn3sYpjHOsCORYGBgZ8kJiaeDgoKep6e3YoSQvVeggiMmIvgAimIKe9JPIMTM4Ov/yDFEDNCiYxN VjTevl2ZIroK7g5B8InsxC5X3ItBCHHUHofgMT7qkunTp7c8//zzSnp6urJp0yYlLi6uiDZFyQfB n38AeBFhjKpGjIL9kiRVSpJ0CLGfNNs+fp1KcQ/Pod4o97iT/LY4/H7MxTosst1vZzq/jTC+HUI4 oWbTHQ1dlpdGREQcGzlyZF5ERMSXCFM2UkJCwqVHHnlkmLd3W4eePn2aXbt2fYCweQxDaKpnEDx6 +8euhLzk5eW11GKx6BA8yRkIQ5urJmlX8RQiyK+n2N8G2z2Oy+tG2vwLWoS5xD7q5yEicHrCboRb ch2wU5blUqvV+jFC4puIiMgZh7A7nUAYJU8gVoSEKVOmnF2+fLm/LMtUV1ezd+/ehrNnz86Sg4OD dY6NDzBq1CgCAwMlBCkqjPYz4BPa+4rftVgsoQgJ6IDtWl+wx7YgZuWjOLc3ZSJiifW2ejuSdl9A 1N8LYSy0N/6XuNb4GsSeoSBG/mSr1aqz5fUWgiE+05bvUoR1NxV4FaiMioras3jxYn9ZFmMiJCSE RYsWBWo0ms1yRUWFqWNp2dnZWCyWzxGjvqXj7x1wTJKkZqPRuII2H/BS+oazXwn8BsFGjnL4RALj EWGmjcDriJAkOyRJI73iF+l/CuHPALGeO1uenCEN0bgngSKDwbBSkqQmOh9AYkWccbQLYQQcA0QE BgZ624/PtEOn02EwGBLl4uLip3bv3t1y/bqgWJpMJt59993spqYmV48Ka0xOTr6QkpKyWqvV7rZd 87dVuq9gQfgJ7B9npuEdiLWZ5H9PYeE3i7zSvl08dtiDScjeMghXqKvSzxO2vw0Ip9Q9iqIcwTUz SmNZWVlOU1P7w8IuXrxIdXX1BbuNZF5MTMxWYFBJSclxs9m8Fhdp3/PmzRs1a9asr/z9/TVHjx7l rbfeqkVMvd/h3ADWrxiyLP6z29787lRHa9Dfl3z8acGBfGcR9s4gAUcQHjHmzJljXbBggXzixIkv 33jjjSku5jFm1KhRh9PS0qKioqLIz89n7969xfn5+VPsmvDha9euqYpjKiwsLG9tba3z9/cPNZvN VQgPWb2avPoAqYHR/kM7muKGLI7NKTjg8thQEGbx8cDmUaNGfV+j0ZCYmBiP6BxXAkS+On/+fFxp aeluWZbjy8vLMxRFeRYodNsUkZWVZYqNjZ106dKl3+bm5s5DbII3uwOigW3AfeUnKyQcYhfNDWZr RVbVSRV5ngL+48MPP1za0tJSZrFY7KKsq2ipqKj4vopyXYbBDXKuJxCDEBNfQ6zVQs6XUKIXGs13 Zd3dcscn8/LH/Wr8K2oLiIiIeEuW5euIowgGJLYiNsj+ihc7i5DSzDhXwiwI+T3W3+g/GPdML8kI Kedpdyrc1wiWJKlKlmVXtUt3UUXXGvCHCP3FI5Bl+T1JkqoYYNT0jvAHPpQkqZr+iaFqpM2eU4DQ Qx5BfYBIV7hTkqRa2sTRAYmpwEXElPcId74HeNE22h/t47L8gF8jdI57+7isXiMAIfNfpU3L7A8E 09YB6/upzPEIs/tBPHQQuLv+gBmI42W0iGnfFb+nL+B49lx/BeqdQhjcshDPvao/CpUQ/oGltJ39 GYjwNF3BgbvTzxhB2wxYdBPKH4uwlX2A+wc9dYmFKSkpVXfeead16dKlSmxsbCUiSC4H4a26mSGb E2jrALXHYboLDYLFXYYg2o7y9vbeZzQaT0ZFRR1AnHHXLbrjhvrHxcVd27RpU5jdXN3c3MyuXbuq zp07twT3zuX3BG6nzZg2GZWHdHsIycBzcXFx41avXq0PDw+ntraWAwcONJ08eXIF3Tjxu9sDFk6a NCnM0Vfg6+tLTExMMK7zP/sSjrPvZps+zoWEhGSlpaXpw8PDAdBqtdx///1+BoNhS3cJu+uARruJ 2hFBQUEynjkLwhl7wojwJL1Gm0u0K/RmE05CHDXwsy5+d5ucoNFoxiQkJLS7JkkSOp2uW2mpu4Lf zcvLMzl2QkNDAxkZGd/Qc1hOT1giSdJZWZbfpz2LYhVibb8fIdZmILxNzk4e7G4GeCE26c22PC4i RNUttA/wTpYk6TjtzzBVhfLy8jO5ue0JYY2NjdTW1nYbt9ZTfMB4o9F4YMKECcb6+nry8vJMly5d moXw+qiFHiHC7ZEkaZWiKMERERGHSktLNyIaIh5hRphAe4WuEEEEyAPyUlNT7545c+aYpqYmjhw5 8kpOTs41BFNjNGKGOhIDyhE8owREQMVfwsLCnq+srJwvSVKtoii1iEDBdjykXkIzbNiwvLS0tOi4 uDiamprYs2dPc0ZGxhLcFM8lhLw/C8+cBbQXYSoGoUw9I0lS03e+8x3rpk2blOnTp9v9zRqEn3U7 Yja0s/Vs2LBBSU9PV9LT05U77rijox3IjDh1cRfioFgNMPWOO+5QHnroIavRaLTaDm590laHcQh2 nLuHrSYHBwe/m5iYmB0UFHTMVna3cMUfcCMuygNYhlhO7BE0NcBjiqLsmDlz5rfx8fGDAgICtN9+ +22RJEl7ysrK/owQex9G2JbiEey0+Lq6uvXYtNGWlpbPEHSRQoSmeh7x9gwZGJ+QkPCCj4/P9xcu XAggNTc357z66quTaQs3ykT4kf8LEeinFudqamoW1NS4zlrvz5MPDQh2wnw6O/oL6+vrXygtLX3o /PnzWeXl5QoiOmaTl5dXkY0gsBIRg3wc4MKFC6/5+vr+pKWlpcxkMj3bIc/ZGo1mraIosy0WS+iV K1fMsiwfv3DhQoxOpwu3Wq3b6ByB/wRiabwLz1NqBgQOIKZ8d3Dck4IRcWf7EdGUvYlnO4pgUOxE kAPsEpNM94NuGmK5G9AmZzVYjnCeqKGqqHkZ26MI+ooauPO2jwGJSIQZV817xEBIJ7/uZZo5qD8J PQhh47pdZfqbDm8vL68XIiMjPw4JCfk1gknWrTbYA/YhDIG9gR4RUqoW9iP2DQhGXZ+9ANTT4fxj R44ceeSee+4xREREcPnyZQ4ePFiRm5t7K+pf/ZSPGI29pYQXIez3as/zeXz06NE/jY+PD/Lz8+PE iRPf5ufn34N4L4HH4NEOCAsL+3jdunW3Dx7c5o00mUxs27btz2azWc174fUIeV6NfP4+Yj1Xo7Vr hg8fnr1+/fo4jUbs2c3Nzbz88ssVFy9eHEzPdE2X4dEjf/V6/VDHxgdxhLvBYFD7TpYJCBldDc6i 3im/YPz48TcaH4Qh0mg0htN2IIlH4NEOKCkpudbS0n5wlJWVoShKr44wc8B41L3EDdzrgFM1NTWd YpcDAwPBg6MfPNwBNTU1z7755ps3iL5ms5n9+/dfLy4uTleZ5XgEI1kNzqJe8rqWk5NT6UiovX79 OhkZGXn0r9tVFRZFR0d/nZSUVBoWFpZJ5zN1eoNiejZLdwUZYYAL7OnGLnB7dHR00eLFi5XZs2cr SUlJRYggjP/zCPDy8vpNdHT0J4MHD76AehpIJPB3rVb7fnBw8LOoew+kBiGSdnVIlNsYMCd/2xEd HX1s5cqVM41GI83Nzezfv9+amZn5i6ampt5QAqOHDBny5dy5c2NGjBjB1atXefvttwtyc3OH0b+H ffeIm/XiA6eQZXnVtGnTbre/SNnX15fly5fL8fHxq3qTz6BBg9YuWLAg5pZbbsHHx4fExEQeeugh o1ar9UQEv0cxoDpAUZQJw4YN6zQrw8LCIumF5TYsLGzOqFHtvaYBAQGEh4erfTd9n2GgdcBXHd9i bbVaqaysbKYXy2VJSUl1VVVVu2stLS1YLJbqLpLcNNyMd790h6/r6uqWhoSE6AwGA2azmXfeeUc5 ceLEVnrhFLJYLGU1NTXLhg8f7mVndezfv781KytrPcI//P/oBmE+Pj6vJCUlXQ4LCzuFOCdUDRbG xMScGzNmTFVMTEy2r6/vgz0n6X/8D0yz1WBg2QSfAAAAAElFTkSuQmCC "
+         preserveAspectRatio="none"
+         height="8.1490698"
+         width="8.1490698" />
+    </g>
+    <g
+       id="g3552"
+       transform="translate(-138.91367,-48.992534)">
+      <g
+         style="stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         transform="matrix(0.55359707,0,0,0.55359707,373.1235,105.54645)"
+         id="usability_audit">
+        <g
+           style="stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           id="g1023">
+          <path
+             style="fill:#37474f;stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+             inkscape:connector-curvature="0"
+             d="m 17.07,21 h 1.055 l 0.251,1.758 c 0.068,0.546 0.569,0.931 1.114,1.009 l 1.52,0.154 c 0.216,0.031 0.484,0.015 0.764,0.015 0.428,0 0.881,-0.051 1.207,-0.116 l 0.539,-0.115 c 0.539,-0.108 1.09,-0.387 1.223,-0.92 L 25.25,21 c 0,0 0.094,-0.5 0.75,-0.5 0.656,0 0.75,0.5 0.75,0.5 l 0.508,1.78 c 0.133,0.533 0.684,0.933 1.223,1.041 l 0.539,0.045 c 0.326,0.065 0.779,0.069 1.207,0.069 0.279,0 0.549,-0.03 0.764,-0.062 l 1.52,-0.225 c 0.545,-0.078 1.046,-0.342 1.114,-0.888 L 33.875,21 h 1.115 c 0.007,0.475 0.01,0.967 0.01,1.5 0,0 1,-3.188 1,-8 0,-2.916 -0.5,-7 -4,-7 -1.458,-1.708 -3.946,-2 -7,-2 -7.5,0 -9,4.5 -9,9 0,4.971 1,8 1,8 0,-0.557 0.029,-1.041 0.07,-1.5 z m 7.702,-0.651 -0.515,2.061 c -0.087,0.347 -0.486,0.727 -0.836,0.797 l -0.54,0.107 c -0.282,0.057 -0.696,0.091 -1.108,0.091 -0.264,0 -0.51,-0.015 -0.692,-0.041 L 19.56,23.147 c -0.32,-0.046 -0.648,-0.38 -0.688,-0.701 L 18.62,20.43 c -0.034,-0.273 0.167,-0.537 0.44,-0.576 l 1.521,-0.217 c 0.262,-0.038 0.631,-0.06 1.013,-0.06 0.319,0 0.617,0.016 0.836,0.043 l 2.016,0.252 c 0.121,0.015 0.22,0.071 0.279,0.159 0.06,0.087 0.077,0.2 0.047,0.318 z m 8.356,2.096 c -0.04,0.321 -0.369,0.655 -0.688,0.701 l -1.521,0.217 c -0.183,0.026 -0.429,0.041 -0.692,0.041 -0.412,0 -0.826,-0.034 -1.109,-0.091 L 28.58,23.206 c -0.352,-0.07 -0.75,-0.45 -0.836,-0.797 l -0.516,-2.061 c -0.029,-0.117 -0.013,-0.23 0.048,-0.317 0.06,-0.088 0.159,-0.145 0.279,-0.159 l 2.016,-0.252 c 0.22,-0.027 0.517,-0.043 0.836,-0.043 0.382,0 0.751,0.021 1.014,0.06 l 1.519,0.217 c 0.273,0.039 0.476,0.303 0.441,0.576 z M 33.798,20 C 33.667,19.672 33.381,19.411 33.01,19.358 l -1.52,-0.217 c -0.296,-0.042 -0.694,-0.064 -1.084,-0.064 -0.328,0 -0.649,0.016 -0.898,0.047 l -2.016,0.252 C 27.117,19.423 26.853,19.677 26.761,20 H 25.24 c -0.093,-0.323 -0.356,-0.577 -0.731,-0.624 l -2.016,-0.252 c -0.25,-0.031 -0.57,-0.047 -0.898,-0.047 -0.39,0 -0.787,0.022 -1.084,0.064 l -1.52,0.217 C 18.62,19.411 18.334,19.671 18.202,20 H 17.19 c 0.222,-1.455 0.588,-2.648 0.811,-4.5 0.115,-0.951 0.209,-1.269 0.486,-1.269 0.555,0 1.848,1.269 5.514,1.269 4.36,0 6.676,-2.635 8.072,-2.635 0.365,0 0.668,0.181 0.928,0.635 1.475,2.58 1.859,4.35 1.961,6.5 z M 25,6.5 c 2.9,0 5.071,0.28 6.239,1.649 l 0.3,0.351 H 32 c 0.742,0 3,0 3,6 0,0.264 -0.003,0.523 -0.009,0.777 -0.286,-0.703 -0.652,-1.45 -1.123,-2.273 -0.538,-0.941 -1.273,-1.139 -1.796,-1.139 -0.762,0 -1.489,0.4 -2.41,0.908 -1.396,0.77 -3.135,1.727 -5.662,1.727 -2.418,0 -3.668,-0.584 -4.414,-0.932 -0.404,-0.188 -0.723,-0.337 -1.1,-0.337 v 0 c -1.207,0 -1.373,1.267 -1.477,2.123 C 17.004,15.076 17,14.792 17,14.5 c 0,-5.533 2.467,-8 8,-8 z"
+             id="path1011" />
+          <path
+             style="fill:#37474f;stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+             inkscape:connector-curvature="0"
+             d="m 34.53,26.873 c 0.237,-0.796 0.397,-1.597 0.442,-2.379 0.01,0.001 0.018,0.006 0.028,0.006 0.55,0 1,-0.45 1,-1 v -1 c 0,0.55 -0.45,1.5 -1,1.5 -10e-4,0 -0.329,0 -0.885,0 -0.077,0.134 -0.132,0.279 -0.141,0.437 -0.059,1.009 -0.306,2.028 -0.681,3.009 0.399,-0.216 0.813,-0.403 1.237,-0.573 z"
+             id="path1013" />
+          <path
+             style="fill:#37474f;stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+             inkscape:connector-curvature="0"
+             d="M 46.493,40.959 C 46.221,39.325 44.682,37.736 43.058,37.412 L 38.5,36.5 V 36 L 32,34 v -1.645 c -0.384,0.476 -0.718,0.992 -1,1.54 v 2.823 c -0.154,0.226 -0.474,0.623 -0.987,1.024 C 30.011,37.829 30,37.913 30,38 c 0,0.313 0.017,0.624 0.048,0.93 0.237,-0.146 0.456,-0.298 0.646,-0.45 l -0.453,1.554 c 0.134,0.575 0.321,1.128 0.559,1.655 l 1.877,-6.435 4.824,1.484 v 1.585 l -1.871,0.748 -1.408,0.563 1.072,1.072 1.362,1.362 -2.729,3.358 c 0.277,0.189 0.565,0.363 0.864,0.521 L 38,42 36,40 38.5,39 v -1.48 l 4.363,0.873 c 1.205,0.241 2.441,1.517 2.644,2.73 l 0.253,1.521 c 0.05,0.297 0.084,0.713 0.104,1.164 0.333,-0.393 0.629,-0.816 0.892,-1.263 -0.004,-0.021 -0.006,-0.047 -0.009,-0.066 -0.141,-0.839 -0.254,-1.52 -0.254,-1.52 z"
+             id="path1015" />
+          <path
+             style="fill:#37474f;stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+             inkscape:connector-curvature="0"
+             d="m 39,50 c -0.147,0 -0.291,-0.017 -0.438,-0.022 L 26,57.821 25.433,57.467 32.879,48.303 c -0.289,-0.172 -0.57,-0.354 -0.843,-0.549 l -4.689,5.772 2.329,-7.987 C 29.41,45.211 29.165,44.866 28.935,44.511 L 25.988,54.616 21.3,38.472 c 0.94,0.759 2.448,1.528 4.701,1.528 0.417,0 0.8,-0.033 1.167,-0.081 C 27.115,39.593 27.072,39.264 27.047,38.93 26.721,38.973 26.375,39 26.001,39 22.819,39 21.388,37.288 21,36.72 v -4.07 c 1.488,1.42 3.24,2.35 5,2.35 0.485,0 0.97,-0.077 1.449,-0.209 0.113,-0.408 0.245,-0.808 0.399,-1.197 C 27.232,33.85 26.609,34 26,34 22.393,34 18.293,29.084 18.025,24.437 18.016,24.28 17.962,24.134 17.884,24 c -0.555,0 -0.883,0 -0.885,0 -0.55,0 -1,-0.95 -1,-1.5 v 1 c 0,0.55 0.45,1 1,1 0.01,0 0.018,-0.005 0.027,-0.006 0.141,2.44 1.302,5.074 2.973,7.094 V 34 l -6.5,2 v 0.501 L 8.94,37.412 C 7.315,37.736 5.778,39.325 5.505,40.959 L 5.252,42.48 c -0.141,0.84 -0.18,2.413 -0.088,3.514 L 26,59 40.609,49.879 C 40.081,49.95 39.547,50 39,50 Z m -24.5,-13.262 4.823,-1.483 5.251,18.081 -9.227,-11.269 1.359,-1.36 1.072,-1.072 -1.408,-0.563 -1.87,-0.749 z m -8.367,8.679 c -0.042,-0.959 0,-2.132 0.107,-2.773 L 6.493,41.123 C 6.699,39.888 7.91,38.638 9.138,38.393 L 13.5,37.52 V 39 l 2.5,1 -2,2 11.552,14.108 -0.354,1.212 z"
+             id="path1017" />
+          <g
+             style="stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+             id="g1021">
+            <path
+               style="fill:#37474f;stroke:#000000;stroke-width:0.356667;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+               inkscape:connector-curvature="0"
+               d="M 58.293,54.293 49.707,45.707 C 49.513,45.513 49.256,45.416 49,45.416 c -0.159,0 -0.313,0.051 -0.458,0.126 L 47.706,44.706 C 49.139,42.849 50,40.527 50,38 50,31.925 45.075,27 39,27 c -6.075,0 -11,4.925 -11,11 0,6.075 4.925,11 11,11 2.527,0 4.849,-0.861 6.706,-2.294 l 0.836,0.836 c -0.196,0.377 -0.15,0.85 0.165,1.165 l 8.586,8.586 c 0.194,0.194 0.451,0.291 0.707,0.291 0.256,0 0.513,-0.097 0.707,-0.291 l 1.586,-1.586 c 0.389,-0.389 0.389,-1.025 0,-1.414 z M 29,38 c 0,-5.522 4.478,-10 10,-10 5.522,0 10,4.478 10,10 0,5.522 -4.478,10 -10,10 -5.522,0 -10,-4.478 -10,-10 z m 18.058,7.472 0.735,0.735 -0.586,0.586 -0.735,-0.735 c 0.202,-0.189 0.397,-0.384 0.586,-0.586 z M 56,56.586 47.414,48 48.997,46.416 c 0,0 10e-4,0 0.003,0 V 46.414 L 57.586,55 Z"
+               id="path1019" />
+          </g>
+        </g>
+      </g>
+      <text
+         id="text5330-1-7"
+         y="148.2924"
+         x="368.82056"
+         style="font-style:normal;font-weight:normal;font-size:10.5833px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
+         xml:space="preserve"><tspan
+           style="stroke-width:0.264583"
+           y="148.2924"
+           x="368.82056"
+           id="tspan5328-8-9"
+           sodipodi:role="line">Monitor</tspan></text>
+    </g>
+    <g
+       id="globe_sphere-9"
+       transform="matrix(1.0344828,0,0,1.0344828,128.00803,57.386526)">
+      <g
+         id="g3503">
+        <g
+           id="international_finance_x2C__globe_x2C__money_flow_x2C__money_turnover_7_-3">
+          <g
+             id="global_5_-6">
+            <g
+               id="g3477">
+              <circle
+                 id="circle3471"
+                 r="14.042"
+                 cy="16.542999"
+                 cx="16.499001"
+                 style="fill:#80d8ff" />
+              <path
+                 id="path3473"
+                 d="m 3.999,17.543 c 0,-7.455 6.044,-13.5 13.5,-13.5 5.397,0 10.042,3.176 12.202,7.754 C 27.754,6.381 22.586,2.5 16.499,2.5 8.744,2.5 2.457,8.787 2.457,16.543 c 0,6.088 3.88,11.255 9.297,13.203 C 7.176,27.586 3.999,22.941 3.999,17.543 Z"
+                 inkscape:connector-curvature="0"
+                 style="fill:#ffffff" />
+              <path
+                 id="path3475"
+                 d="m 26.176,6.383 c 0.65,1.705 1.022,3.547 1.022,5.479 0,8.493 -6.888,15.38 -15.38,15.38 -1.934,0 -3.775,-0.372 -5.479,-1.023 2.557,2.685 6.158,4.367 10.159,4.367 7.755,0 14.042,-6.287 14.042,-14.043 0.001,-4 -1.681,-7.603 -4.364,-10.16 z"
+                 inkscape:connector-curvature="0"
+                 style="fill:#54a0c3;fill-opacity:1" />
+            </g>
+          </g>
+        </g>
+        <path
+           id="path3481"
+           d="M 16.499,9.162 C 13.764,9.162 11.03,8.847 8.376,8.225 8.107,8.162 7.94,7.894 8.003,7.624 8.066,7.356 8.328,7.189 8.605,7.251 c 5.793,1.358 11.95,1.187 17.678,-0.498 0.27,-0.076 0.544,0.073 0.621,0.338 0.078,0.266 -0.073,0.543 -0.338,0.621 -3.271,0.962 -6.658,1.45 -10.067,1.45 z"
+           inkscape:connector-curvature="0"
+           style="fill:#455a64" />
+        <path
+           id="path3483"
+           d="m 26.424,26.362 c -0.047,0 -0.094,-0.007 -0.142,-0.021 -6.359,-1.871 -13.207,-1.871 -19.566,0 -0.269,0.075 -0.544,-0.073 -0.621,-0.338 -0.078,-0.266 0.073,-0.543 0.338,-0.621 6.545,-1.926 13.588,-1.926 20.133,0 0.265,0.078 0.416,0.355 0.338,0.621 -0.064,0.219 -0.264,0.359 -0.48,0.359 z"
+           inkscape:connector-curvature="0"
+           style="fill:#455a64" />
+        <path
+           id="path3485"
+           d="m 15.888,30.639 c -0.098,0 -0.195,-0.028 -0.282,-0.087 -4.667,-3.185 -7.453,-8.422 -7.453,-14.009 0,-4.527 1.781,-8.788 5.017,-11.998 0.197,-0.197 0.514,-0.193 0.707,0.002 0.195,0.196 0.193,0.513 -0.002,0.707 -3.045,3.021 -4.722,7.03 -4.722,11.289 0,5.256 2.623,10.185 7.018,13.183 0.228,0.155 0.286,0.467 0.131,0.695 -0.098,0.142 -0.255,0.218 -0.414,0.218 z"
+           inkscape:connector-curvature="0"
+           style="fill:#455a64" />
+        <path
+           id="path3487"
+           d="m 17.153,30.639 c -0.159,0 -0.316,-0.076 -0.413,-0.218 -0.155,-0.229 -0.097,-0.54 0.131,-0.695 4.395,-2.998 7.018,-7.927 7.018,-13.183 0,-5.256 -2.623,-10.185 -7.018,-13.183 -0.228,-0.155 -0.286,-0.467 -0.131,-0.695 0.156,-0.228 0.468,-0.284 0.695,-0.131 4.667,3.185 7.453,8.422 7.453,14.009 0,5.587 -2.786,10.824 -7.453,14.009 -0.086,0.058 -0.184,0.087 -0.282,0.087 z"
+           inkscape:connector-curvature="0"
+           style="fill:#455a64" />
+        <g
+           id="g3493">
+          <path
+             id="path3489"
+             d="M 16.499,3.096 V 29.99 Z"
+             inkscape:connector-curvature="0"
+             style="fill:#eceff1" />
+          <path
+             id="path3491"
+             d="m 16.499,30.49 c -0.276,0 -0.5,-0.224 -0.5,-0.5 V 3.096 c 0,-0.276 0.224,-0.5 0.5,-0.5 0.276,0 0.5,0.224 0.5,0.5 V 29.99 c 0,0.277 -0.224,0.5 -0.5,0.5 z"
+             inkscape:connector-curvature="0"
+             style="fill:#455a64" />
+        </g>
+        <g
+           id="g3499">
+          <path
+             id="path3495"
+             d="M 4.552,16.543 H 30.447 Z"
+             inkscape:connector-curvature="0"
+             style="fill:#eceff1" />
+          <path
+             id="path3497"
+             d="M 30.446,17.043 H 4.552 c -0.276,0 -0.5,-0.224 -0.5,-0.5 0,-0.276 0.224,-0.5 0.5,-0.5 h 25.895 c 0.276,0 0.5,0.224 0.5,0.5 0,0.276 -0.224,0.5 -0.501,0.5 z"
+             inkscape:connector-curvature="0"
+             style="fill:#455a64" />
+        </g>
+        <path
+           id="path3501"
+           d="m 16.499,31.043 c -7.995,0 -14.5,-6.505 -14.5,-14.5 0,-3.521 1.278,-6.919 3.6,-9.565 C 5.781,6.77 6.096,6.75 6.305,6.932 6.512,7.114 6.532,7.43 6.351,7.638 4.19,10.101 2.999,13.264 2.999,16.543 c 0,7.444 6.056,13.5 13.5,13.5 7.444,0 13.5,-6.056 13.5,-13.5 0,-7.444 -6.056,-13.5 -13.5,-13.5 -3.078,0 -5.976,1.008 -8.379,2.915 C 7.904,6.13 7.59,6.095 7.418,5.877 7.246,5.661 7.282,5.347 7.499,5.175 c 2.581,-2.049 5.693,-3.132 9,-3.132 7.995,0 14.5,6.505 14.5,14.5 0,7.995 -6.505,14.5 -14.5,14.5 z"
+           inkscape:connector-curvature="0"
+           style="fill:#455a64" />
+      </g>
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:10.5833px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
+       x="124.873"
+       y="99.543282"
+       id="text5330"><tspan
+         sodipodi:role="line"
+         id="tspan5328"
+         x="124.873"
+         y="99.543282"
+         style="stroke-width:0.264583">Website</tspan></text>
+    <g
+       id="g11162"
+       transform="translate(88.89148,-83.056321)">
+      <g
+         style="fill:none;fill-rule:evenodd;stroke:none;stroke-width:1"
+         transform="matrix(0.05680957,0,0,0.05680957,145.34816,97.556295)"
+         id="tor-browser-icon">
+        <g
+           id="icon_512x512">
+          <g
+             id="Group">
+            <g
+               id="tb_icon/Stable">
+              <g
+                 id="Stable">
+                <circle
+                   style="fill:#f2e4ff;fill-rule:nonzero"
+                   id="background"
+                   cx="256"
+                   cy="256"
+                   r="246" />
+                <path
+                   style="fill:url(#linearGradient1167)"
+                   inkscape:connector-curvature="0"
+                   d="m 256.52514,465.43971 v -31.0331 C 354.82619,434.12275 434.4208,354.36492 434.4208,255.9929 434.4208,157.62799 354.82619,77.870156 256.52514,77.586295 V 46.553196 C 371.9643,46.844154 465.4468,140.48988 465.4468,255.9929 c 0,115.51012 -93.4825,209.16295 -208.92166,209.44681 z m 0,-108.6194 c 55.44514,-0.29095 100.32356,-45.3042 100.32356,-100.82741 0,-55.5161 -44.87842,-100.52935 -100.32356,-100.82031 v -31.026 c 72.59034,0.28386 131.35666,59.1921 131.35666,131.84631 0,72.66131 -58.76632,131.56955 -131.35666,131.85342 z m 0,-155.10162 c 29.74153,0.28386 53.77746,24.46172 53.77746,54.27421 0,29.8196 -24.03593,53.99745 -53.77746,54.28131 z M 0,255.9929 C 0,397.38404 114.60886,512 256,512 397.38404,512 512,397.38404 512,255.9929 512,114.60886 397.38404,0 256,0 114.60886,0 0,114.60886 0,255.9929 Z"
+                   id="center" />
+                <g
+                   id="half"
+                   transform="matrix(-1,0,0,1,281,0)">
+                  <use
+                     height="100%"
+                     width="100%"
+                     y="0"
+                     x="0"
+                     style="fill:#000000;fill-opacity:1;filter:url(#filter-3-0)"
+                     xlink:href="#path-2"
+                     id="use1133" />
+                  <use
+                     height="100%"
+                     width="100%"
+                     y="0"
+                     x="0"
+                     style="fill:url(#linearGradient1169);fill-rule:evenodd"
+                     xlink:href="#path-2"
+                     id="use1135" />
+                </g>
+              </g>
+            </g>
+          </g>
+        </g>
+      </g>
+      <text
+         id="text5330-1"
+         y="96.481125"
+         x="140.45294"
+         style="font-style:normal;font-weight:normal;font-size:10.5833px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
+         xml:space="preserve"><tspan
+           style="stroke-width:0.264583"
+           y="96.481125"
+           x="140.45294"
+           id="tspan5328-8"
+           sodipodi:role="line">Browser</tspan></text>
+    </g>
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.6;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker6925);paint-order:markers fill stroke"
+       d="M 225.63552,27.98956 H 145.52279 V 52.237043"
+       id="path1315" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker6925)"
+       d="M 164.18832,63.100784 225.61686,41.500852"
+       id="path5412" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.5;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:1, 3;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker6925-3);paint-order:markers fill stroke"
+       d="m 269.97142,28.651437 h 80.11273 v 24.942182"
+       id="path1315-7"
+       sodipodi:nodetypes="ccc" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.5;stroke-linecap:round;stroke-linejoin:miter;stroke-dasharray:1,3;stroke-opacity:1;marker-end:url(#marker6925-3);stroke-dashoffset:0"
+       d="M 331.41862,63.762668 269.99008,42.162728"
+       id="path5412-5" />
+    <text
+       xml:space="preserve"
+       style="font-size:8.46667px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="146.10869"
+       y="25.934643"
+       id="text6798"><tspan
+         sodipodi:role="line"
+         id="tspan6796"
+         style="font-size:8.46667px;stroke-width:0.264583"
+         x="146.10869"
+         y="25.934643">initiate website visit</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:8.46667px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="151.54257"
+       y="110.28304"
+       id="text6802"
+       transform="rotate(-18.717017)"><tspan
+         sodipodi:role="line"
+         id="tspan6800"
+         style="font-size:8.46667px;stroke-width:0.264583"
+         x="151.54257"
+         y="110.28304">certificate</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:8.46667px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="270.7204"
+       y="25.976976"
+       id="text6806"><tspan
+         sodipodi:role="line"
+         id="tspan6804"
+         style="font-size:8.46667px;stroke-width:0.264583"
+         x="270.7204"
+         y="25.976976">certificate included?</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:8.46667px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="295.04141"
+       y="-52.231258"
+       id="text6810"
+       transform="rotate(19.35318)"><tspan
+         sodipodi:role="line"
+         id="tspan6808"
+         style="font-size:8.46667px;stroke-width:0.264583"
+         x="295.04141"
+         y="-52.231258">proof</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:8.46667px;line-height:1;font-family:sans-serif;stroke-width:0.264583"
+       x="259.63907"
+       y="189.25381"
+       id="text12625"
+       transform="rotate(-15.894008)"><tspan
+         sodipodi:role="line"
+         style="font-size:8.46667px;text-align:center;text-anchor:middle;stroke-width:0.264583"
+         x="259.63907"
+         y="189.25381"
+         id="tspan15099" /></text>
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.5;stroke-linecap:round;stroke-linejoin:miter;stroke-dasharray:1,3;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker6925-3-3)"
+       d="M 330.72966,75.502296 H 269.93793"
+       id="path3014" />
+    <text
+       xml:space="preserve"
+       style="font-size:8.46667px;line-height:1;font-family:sans-serif;stroke-width:0.264583"
+       x="303.34055"
+       y="83.84243"
+       id="text3544"><tspan
+         sodipodi:role="line"
+         id="tspan3542"
+         style="font-size:8.46667px;text-align:center;text-anchor:middle;stroke-width:0.264583"
+         x="303.34055"
+         y="83.84243">continuous</tspan><tspan
+         sodipodi:role="line"
+         style="font-size:8.46667px;text-align:center;text-anchor:middle;stroke-width:0.264583"
+         x="304.44122"
+         y="92.309097"
+         id="tspan3546">download </tspan></text>
+  </g>
+  <style
+     id="style11499"
+     type="text/css">
+	.st0{fill:#084272;}
+	.st1{fill:#FFFFFF;}
+	.st2{fill:#2B66A1;}
+	.st3{fill:#3DA7E3;}
+	.st4{fill:#24323D;}
+</style>
+  <style
+     id="style15137"
+     type="text/css">
+	.st0{fill:#FFDEF9;}
+	.st1{fill:#955E88;}
+	.st2{fill:#6B3763;}
+	.st3{fill:#FFFFFF;}
+</style>
+</svg>
diff --git a/summary/src/introduction/main.tex b/summary/src/introduction/main.tex
new file mode 100644
index 0000000..da013ab
--- /dev/null
+++ b/summary/src/introduction/main.tex
@@ -0,0 +1,826 @@
+\section{Introduction}
+
+The security posture of the Internet increased significantly throughout the
+last decade.  For example,
+  the cleaned-up and formally verified TLS 1.3 protocol that underpins HTTPS
+    has been rolled-out gradually~\cite{tls-timeline},
+  the certificates that specify which public keys to use when bootstrapping a
+    secure connection can be obtained for free and automatically~\cite{le}, and
+  web browsers have shifted from positive to negative security indicators in
+    favor of security-by-default~\cite{browser-ui}.
+The use of end-to-end encryption has further become the norm with services such
+as
+  DNS-over-HTTPS~\cite{rfc8484},
+  virtual private networks~\cite{wireguard},
+  Tor~\cite{tor}, and
+  secure messaging~\cite{mls}
+gaining traction.  In other words, the era of attackers that can passively snoop
+and actively tamper with unencrypted~network~traffic~is~over.
+
+What will remain the same is the incentive for attackers to snoop and tamper
+with network traffic.  Therefore, the focus is (and will likely continue to be)
+on circumventing protocols that add security and privacy as they are deployed
+in the real world.  For example, there is a long history of certificate
+mis-issuance that allows attackers to impersonate websites and thus insert
+themselves as machines-in-the-middle (``MitM'') without actually breaking
+TLS~\cite{sok-https,sslmate-history}.  Or, in the case of encrypted channels
+that are hard to intercept, instead analyzing traffic patterns to infer user
+activity like which website is being
+visited~\cite{cheng98,herrmann09,hintz02,liberatore06,panchenko11,sun02}.  The
+bad news is that attackers only need to find one vulnerability in a deployed
+protocol or its software.  Sometimes, such vulnerabilities can be purchased by
+zero-day brokers like Zerodium~\cite{zerodium}.
+
+To address an attack vector, it is common to add countermeasures that frustrate
+attackers and/or increase the risk involved while trying to exploit a system.
+A good example is how the certificate authority ecosystem evolved.  For
+background, certificate authorities are trusted parties that validate domain
+names before issuing certificates that list their public keys.  Web browsers
+are shipped with hundreds of trusted certificate authorities, which means that
+the resulting TLS connections cannot be more secure than the difficulty of
+hijacking the weakest-link certificate authority~\cite{sok-https}.  A proposal
+eventually deployed to mitigate this issue is Certificate Transparency: an
+ecosystem of public append-only logs that publishes all certificates so that
+any mis-issuance can be \emph{detected} by monitors~\cite {ct,rfc6962}.
+These logs have a cryptographic foundation that holds them and the issuing
+certificate authorities \emph{accountable}, at least in theory.  In practice,
+the logs are essentially trusted parties that must act honestly due to how web
+browsers shape their policies to respect user
+privacy~\cite{apple-log-policy,google-log-policy,sok-sct-auditing,ct-history}.
+
+The first objective of this thesis is to better understand the current limits
+of Certificate Transparency by proposing and evaluating improvements which
+\emph{reduce} the amount of trust that needs to be placed in third-party
+monitors and logs.  We make a dent in the problem of Certificate Transparency
+verification both generally and concretely in the context of Tor Browser, which
+unlike Google Chrome and Apple's Safari does not support Certificate
+Transparency yet.  For context, Tor Browser is a fork of
+Mozilla's Firefox that (among other things) routes user traffic through the
+low-latency anonymity network Tor~\cite{tor,tb}.  As part of our pursuit to
+improve the status quo for Certificate Transparency verification in Tor
+Browser, the second objective of this thesis is to evaluate how the protocols
+used during website visits affect unlinkability between senders (web browsers)
+and receivers (websites).  Our evaluation applies to our addition of
+Certificate Transparency and other protocols already in use, e.g.,
+  DNS,
+  real-time bidding~\cite{rtb}, and
+  certificate revocation checking~\cite{ocsp}.
+
+The remainder of the introductory summary is structured as follows.
+Section~\ref{sec:background} introduces background that will help the reader
+  understand the context and preliminaries of the appended papers.
+Section~\ref{sec:rqs} defines our research questions and overall objective.
+Section~\ref{sec:methods} provides an overview of our research methods.
+Section~\ref{sec:contribs} describes our contributions succinctly.
+Section~\ref{sec:appended} summarizes the appended papers that are published in
+  NordSec (Paper~\ref{paper:lwm}),
+  SECURWARE (Paper~\ref{paper:ctga}),
+  PETS (Paper~\ref{paper:ctor} and~\ref{paper:cat}),
+  WPES (Paper~\ref{paper:sauteed}), and
+  USENIX Security (Paper~\ref{paper:tlwo}).
+Section~\ref{sec:related} positions our contributions with regard to related
+work.  Section~\ref{sec:concl} concludes and briefly discusses future work.
+
+\section{Background} \label{sec:background}
+
+This section introduces background on Certificate Transparency and Tor.
+
+\subsection{Certificate Transparency}
+
+The web's public-key infrastructure depends on certificate authorities to issue
+certificates that map domain names to public keys.  For example, the
+certificate of \texttt{www.example.com} is issued by DigiCert and lists a
+2048-bit RSA key~\cite{crt:www.example.com}.  The fact that DigiCert signed
+this certificate means that they claim to have verified that the requesting
+party is really \texttt{www.example.com}, typically by first ensuring that a
+specified DNS record can be uploaded on request~\cite{ca/b}.  If all
+certificate authorities performed these checks correctly and the checks
+themselves were fool-proof, a user's browser could be sure that any
+certificate signed by a certificate authority would list a verified public key
+that can be used for authentication when connecting to a website via TLS.
+Unfortunately, there are hundreds of trusted certificate authorities and a long
+history of issues surrounding their operations in
+practice~\cite{bambo-cas,sok-https,sslmate-history}.  One of the most famous
+incidents took place in 2011: an attacker managed to mis-issue certificates from
+DigiNotar to intercept traffic towards Google and others in
+Iran~\cite{black-tulip}.  The astonishing part is that this incident was first
+detected \emph{seven weeks later}.
+
+Certificate Transparency aims to facilitate \emph{detection} of issued
+certificates, thus holding certificate authorities \emph{accountable} for any
+certificates that they mis-issue~\cite{ct,rfc6962}.  The basic idea is shown in
+Figure~\ref{fig:ct-idea}.  In addition to regular validation rules, browsers
+ensure certificates are included in a public append-only Certificate
+Transparency \emph{log}.
+This allows anyone to get a concise view of all certificates that users
+may encounter, including domain owners like Google who can then see for
+themselves whether any of the published certificates are mis-issued.  The
+parties inspecting the logs are called \emph{monitors}.  Some monitors mirror
+all log entries~\cite{crt.sh}, while others discard most of them in pursuit of
+finding matches for pre-defined criteria like
+\texttt{*.example.com}~\cite{certspotter}.  Another option is subscribing to
+certificate notifications from a trusted third-party~\cite{ct-monitors}.
+
+\begin{figure}[!t]
+  \centering\includegraphics[width=0.8\textwidth]{src/introduction/img/ct}
+  \caption{%
+    The idea of Certificate Transparency.  Certificates encountered by users
+    must be included in a public log so that monitors can detect mis-issuance.
+  }
+  \label{fig:ct-idea}
+\end{figure}
+
+What makes Certificate Transparency a significant improvement compared to the
+certificate authority ecosystem is that the logs stand on a cryptographic
+foundation that can be verified.  A log can be viewed as an append-only
+tamper-evident list of certificates.  It is efficient\footnote{%
+  Efficient refers to space-time complexity $\mathcal{O}(\mathsf{log}(n))$,
+  where $n$ is the number of log entries.
+} to prove cryptographically that a certificate is in the list, and that a
+current version of the list is append-only with regard to a previous version
+(i.e., no tampering or reordering).\footnote{%
+  Interested readers can refer to our Merkle tree and proof technique
+  introduction online~\cite{merkle-intro}.
+} These properties follow from using a Merkle tree structure that supports
+\emph{inclusion} and \emph{consistency}
+proofs~\cite{history-trees,ct-formal,rfc6962,merkle}.
+The reader
+only needs to know that these proofs are used to reconstruct a log's Merkle tree
+head, often referred to as a \emph{root hash}.  It is a cryptographic hash
+identifying a list of certificates uniquely in a tree data structure.  The logs
+sign root hashes with the number of entries and a timestamp to form \emph{signed
+tree heads}.  So, if an inconsistency is discovered, it cannot be denied.  Log
+operators are therefore held accountable for maintaining the append-only
+property.  A party that verifies the efficient transparency log proofs without
+downloading all the logs is called an \emph{auditor}.
+
+A log that signs two inconsistent tree heads is said to perform a
+\emph{split-view}.  To ensure that everyone observes the same append-only logs,
+all participants of the Certificate Transparency ecosystem must engage in a
+\emph{gossip protocol}~\cite{chuat,nordberg}.  In other words, just because
+Alice observes an append-only log, it is not necessarily the \emph{same
+append-only log} that Bob observes.  Therefore, Alice and Bob must exchange
+signed tree heads and verify consistency to assert that the log operators play
+by the rules and only append certificates.  Without a secure gossip protocol,
+log operators would have to be trusted blindly (much like certificate
+authorities before Certificate Transparency).  RFC~6962 defers the specification
+of gossip~\cite{rfc6962}, with little or no meaningful gossip deployed yet.
+
+Rolling out Certificate Transparency without breakage on the web is a
+challenge~\cite{does-ct-break-the-web}.  Certificates must be logged, associated
+proofs delivered to end-user software, and more.  One solution RFC~6962
+ultimately put forth was the introduction of \emph{signed certificate
+timestamps}.  A signed certificate timestamp is a log's \emph{promise} that a
+certificate will be appended to the log within a \emph{maximum merge delay}
+(typically 24 hours).  Verifying if a log holds its promise is
+usually called \emph{auditing}.
+Certificate authorities can obtain signed certificate
+timestamps and embed them in their final certificates by logging a
+\emph{pre-certificate}.  As such, there is no added latency from building the
+underlying Merkle tree and no need for server software to be updated (as the
+final certificate contains the information needed).  The current policy for
+Google Chrome and Apple's Safari is to reject certificates with fewer than two
+signed certificate timestamps~\cite{apple-log-policy,google-log-policy}.  How to
+request an inclusion proof for a promise without leaking the user's browsing
+history to the log is an open problem~\cite{sok-sct-auditing}.  In other words,
+asking for an inclusion proof trivially reveals the certificate of interest to
+the log.
+
+Other than embedding signed certificate timestamps in certificates, they can be
+delivered dynamically to end-users in TLS extensions and stapled certificate
+status responses.  For example, Cloudflare uses the TLS extension delivery
+method to recover from log incidents without their customers needing to acquire
+new certificates~\cite{cloudflare-scts}.  Several log incidents have already
+happened in the past, ranging from
+split-views~\cite{trustasia-err,izenpe-err,venafi-err} to broken promises of
+timely logging~\cite{wosign-err,google-err,digicert-err,starcom-err} and
+potential key compromise~\cite{digicert-kc}.  These are all good \emph{scares}
+motivating continued completion of Certificate Transparency in practice.
+
+In summary, the status quo is for web browsers to require at least two signed
+certificate timestamps before accepting a certificate as valid.  Merkle tree
+proofs are not verified.  Gossip is not deployed.  The lack of a reliable
+\emph{gossip-audit model} means that the logs are largely trusted
+parties.\footnote{%
+  Historical remark: the lack of verification led Google to require that all
+  certificates be disclosed in at least one of their logs to
+  validate~\cite{ct-history}.  The so-called \emph{one-Google log requirement}
+  was recently replaced.  Google Chrome instead interacts with Google's trusted
+  auditor.  See Section~\ref{sec:related}.
+} We defer discussion of related work in the area of gossip-audit models until
+Section~\ref{sec:related}.
+
+\subsection{Tor}
+
+The Tor Project is a 501(c)(3) US nonprofit that advances human rights and
+defends privacy online through free software and open networks~\cite{tpo}.  Some
+of the maintained and developed components include Tor Browser and Tor's relay
+software.  Thousands of volunteers operate relays as part of the Tor network,
+which routes the traffic of millions of daily users with low
+latency~\cite{mani}.  This frustrates attackers like Internet service providers
+that may try linking \emph{who is communicating with whom} from their local
+(non-global) vantage points~\cite{tor}.
+
+Usage of Tor involves tunneling the TCP traffic of different destinations (such
+as all flows associated with a website visit to \texttt{example.com}) in
+fixed-size \emph{cells} on independent \emph{circuits}.  A circuit is built
+through a guard, a middle, and an exit relay.  At each hop of the circuit, one
+layer of symmetric encryption is peeled off.  The used keys are ephemeral and
+discarded together with all other circuit state after at most 10 minutes (the
+maximum circuit lifetime).  This setup allows guard relays to observe users' IP
+addresses but none of the destination traffic.  In contrast, exit relays can
+observe destination traffic but no user IP addresses.  The relays used in a
+circuit are determined by Tor's end-user software.  Such path selection
+is randomized and bandwidth-weighted but starts with a largely static guard set
+to protect users from \emph{eventually} entering the network from a relay an
+attacker volunteered to run.
+
+Tor's \emph{consensus} lists the relays that make up the network.  As the name
+suggests, it is a document agreed upon by a majority of trusted \emph{directory
+authorities}.  Five votes are currently needed to reach a consensus.  Examples
+of information added to the Tor consensus include tunable network parameters and
+uploaded relay descriptors with relevant metadata, e.g., public key, available
+bandwidth, and exit policy.  Each relay in the consensus is also assigned
+different flags based on their configuration and observed performance, e.g.,
+\texttt{Guard}, \texttt{MiddleOnly}, \texttt{Fast}, \texttt{Stable}, and
+\texttt{HSDir}.  The latter means that the relay is a \emph{hidden service
+directory}, which refers to being part of a distributed hash table that helps
+users lookup \emph{onion service introduction points}.
+
+An onion service is a self-authenticated server identified by its public key.
+Onion services are only reachable through the Tor network.  Users that are aware
+of a server's \emph{onion address} can consult the distributed hash table to
+find its introduction points.  To establish a connection, a user builds a
+circuit to a \emph{rendezvous point}.  A request is then sent to one of the
+current introduction points, which informs the onion service that it may build
+its own circuit to meet the user at their rendezvous point.  In total, six
+relays are traversed while interacting with an onion service.  This setup allows
+not only the sender but also the receiver to be anonymous.  The receiver also
+benefits from a large degree of censorship resistance as the server location may
+be hidden.  The main drawback of onion services is that their non-mnemonic names
+are hard to discover and remember.  Some sites try to overcome this by setting
+their onion addresses in \emph{onion location} HTTP headers or HTML
+attributes~\cite{onion-location}.
+
+Many users use Tor Browser to connect to the Tor network.  In addition to
+routing traffic as described above, Tor Browser ships with privacy-preserving
+features like first-party isolation to not share any state across
+different origins, settings that frustrate browser fingerprinting, and
+\emph{disk-avoidance} to not store browsing-related history as well as other
+identifying information to disk~\cite{tb}.  Tor Browser is a fork of Mozilla's
+Firefox.  Unfortunately, neither Firefox nor Tor Browser supports any form of
+Certificate Transparency.  Conducting undetected machine-in-the-middle attacks
+against Tor users is thus relatively straightforward: compromise or coerce the
+weakest-link certificate authority, then volunteer to operate an exit relay and
+intercept network traffic.  Such interception has previously been found with
+self-signed certificates~\cite{spoiled-onions}.
+
+While global attackers are not within Tor's threat model, it is in scope to
+guard against various local attacks~\cite{tor}.  For example, the intended
+attacker may passively observe a small fraction of the network and actively
+inject their own packets.  Figure~\ref{fig:wf} shows the typical attacker
+setting of \emph{website fingerprinting}, where the attacker observes a user's
+entry traffic with the goal of inferring which website was visited solely based
+on analyzing encrypted
+traffic~\cite{cheng98,herrmann09,hintz02,liberatore06,panchenko11,sun02}.
+Website fingerprinting attacks are evaluated in the \emph{open-world} or
+\emph{closed-world} settings.  In the closed-world setting, the attacker
+monitors (not to be confused with Certificate Transparency monitoring) a fixed
+list of websites.  A user visits one of the monitored sites, and the attacker
+needs to determine which one.  The open-world setting is the same as the
+closed-world setting, except that the user may also visit unmonitored sites.
+The practicality of website fingerprinting attacks is up for debate, e.g.,
+ranging from challenges handling false positives to machine-learning dataset
+drift~\cite{onlinewf,juarez14,perryCrit,realistic}.
+
+\begin{figure}[!t]
+  \centering\includegraphics[width=0.85\textwidth]{src/cat/img/setting}
+  \caption{
+    The setting of a website fingerprinting attack.  A local passive attacker
+    analyzes a user's encrypted network traffic as it enters the network.  The
+    goal is to infer which website is visited.  (Figure reprinted from
+    Paper~\ref{paper:cat}.)
+  }
+  \label{fig:wf}
+\end{figure}
+
+In summary, Tor is a low-latency anonymity network often accessed with Tor
+Browser.  Among the threats that Tor aims to protect against are local attackers
+that see traffic as it enters or leaves the network (but not both at the same
+time all the time).  A website fingerprinting attack is an example of a passive
+attack that operates on entry traffic.  A machine-in-the-middle attack is an
+example of an active attack that typically operates on exit traffic.  Discussion
+of related work in the area of website fingerprinting is deferred until
+Section~\ref{sec:related}.
+
+\section{Research Questions} \label{sec:rqs}
+
+The overall research objective spans two different areas: transparency logs and
+low-latency anonymity networks.  We aim to reduce trust assumptions in
+transparency log solutions and to apply such solutions in anonymous settings for
+improved security and privacy.  We defined the following research questions to
+make this concrete in Certificate Transparency and Tor, the two ecosystems with
+the most history and dominant positions in their respective areas.
+
+\begin{researchquestions}
+  \item[Can trust requirements in Certificate Transparency be reduced in
+    practice?]
+
+  Transparency logs have a cryptographic foundation that supports efficient
+  verification of inclusion and consistency proofs.  Such proofs are useful to
+  reduce the amount of trust that is placed in the logs.  The roll-out of
+  Certificate Transparency has yet to start using these proofs, and to employ a
+  gossip protocol that ensures the same append-only logs are observed.  Part of
+  the challenge relates to privacy concerns as parties interact with each other,
+  as well as deploying gradually without breakage.
+
+  We seek practical solutions that reduce the trust requirements currently
+  placed in the logs and third-party monitors while preserving user privacy.
+
+  \item[How can authentication of websites be improved in the context of Tor?]
+
+  Tor Browser has yet to support Certificate Transparency to facilitate
+  detection of hijacked websites.  This includes HTTPS sites but also onion
+  services that may be easier to discover reliably with more transparency.
+
+  We seek incremental uses of Certificate Transparency in Tor that preserve user
+  privacy while engaging in new verification protocols to reduce trust.
+
+  \item[How do the protocols used during website visits affect
+    unlinkability between Tor users and their destination websites?]
+
+  Several third-parties become aware of a user's browsing activities while a
+  website is visited.  For example, DNS resolvers and certificate status
+  responders may be consulted for domain name resolution and verification of if
+  a certificate has been revoked.  Fetching an inclusion proof from a
+  Certificate Transparency log would reveal the same type of information.
+
+  We seek to explore how unlinkability between Tor users and their exit
+  destinations is affected by the multitude of protocols used during website
+  visits.  The considered setting is the same as in website fingerprinting,
+  except that the attacker may take additional passive and active measures.
+  For example, the attacker may volunteer to run a Certificate Transparency log
+  (passive) or inject carefully-crafted packets into Tor~(active).
+\end{researchquestions}
+
+\section{Research Methods} \label{sec:methods}
+
+We tackle privacy and security problems in the field of computer
+science~\cite{icss,smics}.  Our work is applied, following the scientific method
+for security and experimental networking research.  \emph{Exactly} what it means
+to use the scientific method in these areas is up for debate~\cite{rfenr,sse}.
+However, at a glance, it is about forming precise and consistent theories with
+falsifiable predictions \emph{as in other sciences} except that the objects of
+study are \emph{information systems in the real world}.
+
+A prerequisite to formulating precise, consistent, and falsifiable theories is
+that there are few implicit assumptions.  Therefore, scientific security
+research should be accompanied by definitions of security goals and attacker
+capabilities: what does it mean that the system is secure, and what is the
+attacker (not) allowed to do while attacking it~\cite{secdefs}?  Being explicit about the
+overall \emph{setting} and \emph{threat model} is prevalent in formal security
+work like cryptography, where an abstract (mathematical) model is used to show
+that security can be \emph{proved} by reducing to a computationally hard problem
+(like integer factorization) or a property of some primitive (like the collision
+resistance of a hash function)~\cite{provsec}.  It is nevertheless just as crucial in less
+formal work that deals with security of systems in the real (natural)
+world---the exclusive setting of the scientific method---which usually lends
+itself towards break-and-fix cycles in light of new observations.  Where to draw
+the line between \emph{security work} and \emph{security research} is not
+trivial.  However, a few common \emph{failures} of past ``security research''
+include not bringing observations in contact with theory, not making claims and
+assumptions explicit, or simply relying on unfalsifiable claims~\cite{sse}.
+
+While deductive approaches (like formal reduction proofs) are instrumental in
+managing complexity and gaining confidence in different models, more than these
+approaches are required as a model's \emph{instantiation} must also be secure~\cite{secdefs}.
+It is common to complement abstract modeling with \emph{real-world measurements}
+as well as \emph{systems prototyping and evaluations}~\cite{rfenr}.  Real-world
+measurements measure properties of deployed systems like the Internet, the web,
+and the Tor network.  For example, a hypothesis in a real-world measurement
+could be that (non-)Tor users browse according to the same website popularity
+distribution.  Sometimes these measurements involve the use of research
+prototypes, or the research prototypes themselves become the objects of study to
+investigate properties of selected system parts (say, whether a packet processor
+with new features is indistinguishable from some baseline as active network
+attackers adaptively inject packets of their choosing).  If it is infeasible,
+expensive, or unsafe (see below) to study a real-world system, a simulation may
+be studied instead.  The downside of simulation is that the model used may not
+be a good approximation of the natural world, similar to formal
+cryptographic~modeling.
+
+The appended papers use all of the above approaches to make claims about
+security, privacy, and performance in different systems, sometimes with regard
+to an abstract model that can be used as a foundation in the natural world to
+manage complexity.  Paper~\ref{paper:lwm} contains a reduction proof sketch to
+show reliance on standard cryptographic assumptions.  Paper~\ref{paper:cat}
+extends past simulation setups to show the impact of an added attacker
+capability.  Meanwhile, Paper~\ref{paper:ctor} models part of the Tor network
+with mathematical formulas to estimate performance overhead.  All but
+Paper~\ref{paper:sauteed} contain real-world measurements relating to Internet
+infrastructure, websites, certificates, Tor, or practical deployability of our
+proposals.  All but Paper~\ref{paper:ctor} contain research prototypes with
+associated evaluations, e.g., performance profiling, as well as corroborating or
+refuting our security definitions in experimental settings.  All papers include
+discussions of security and privacy properties as well as their limitations and
+strengths in the chosen settings (where assumptions are explicit and threat
+models motivated).
+
+Throughout our experiments, we strived to follow best practices like documenting
+the used setups, making datasets and associated tooling available, reducing
+potential biases by performing repeated measurements from multiple different
+vantage points, and discussing potential biases (or lack thereof)~\cite{rfenr}.
+We also interacted with Tor's research safety board~\cite{trsb} to discuss the
+ethics and safety of our measurements in Paper~\ref{paper:tlwo}, and refrained
+from measuring real (i.e., non-synthetic) usage of Tor whenever possible
+(Papers~\ref{paper:ctor} and~\ref{paper:cat}).  Finally, the uncovered bugs and
+vulnerabilities in Papers~\ref{paper:cat}--\ref{paper:tlwo} were responsibly
+disclosed to the Tor project.  This included suggestions on how to move forward.
+
+\section{Contributions} \label{sec:contribs}
+
+The main contributions of this thesis are listed below.  An overview of how they
+relate to our research questions and appended papers is shown in
+Figure~\ref{fig:contrib}.
+
+\begin{figure}[!t]
+  \centering
+  \includegraphics[width=0.83\textwidth]{src/introduction/img/contribs}
+  \caption{%
+    Overview of appended papers, contributions, and research questions.
+  }
+  \label{fig:contrib}
+\end{figure}
+
+\vspace{1cm}
+\begin{contributions}
+  \item[Reduced trust in third-party monitoring with a signed tree head
+    extension that shifts trust from non-cryptographic certificate notifications
+    to a log's gossip-audit model (or if such a model does not exist yet, the
+    logs themselves).]
+
+    Paper~\ref{paper:lwm} applies existing cryptographic techniques for
+    constructing static and lexicographically ordered Merkle trees so that
+    certificates can be wild-card filtered on subject alternative names with
+    (non-)membership proofs.  This building block is evaluated in the context of
+    Certificate Transparency, including a security sketch and performance
+    benchmarks.
+
+  \item[Increased probability of split-view detection by proposing gossip
+    protocols that disseminate signed tree heads without bidirectional
+    communication.]
+
+    Paper~\ref{paper:ctga} explores aggregation of signed tree heads at line
+    speed in programmable packet processors, facilitating consistency proof
+    verification on the level of an entire autonomous system.  Such verification
+    can be indistinguishable from an autonomous system without any split-view
+    detection to achieve herd immunity, i.e., protection without aggregation.
+    Aggregation at 32 autonomous systems can protect 30-50\% of the IPv4 space.
+    Paper~\ref{paper:ctor} explores signed tree heads in Tor's consensus.  To
+    reliably perform an undetected split-view against log clients that have Tor
+    in their trust root, a log must collude with a majority of directory
+    authorities.
+
+  \item[Improved detectability of website hijacks targeting Tor Browser by
+    proposing privacy-preserving and gradual roll-outs of Certificate
+    Transparency in Tor.]
+
+    Paper~\ref{paper:ctor} explores adoption of Certificate Transparency in Tor
+    Browser with signed certificate timestamps as a starting point, then
+    leveraging the decentralized network of relays to cross-log certificates
+    before ultimately verifying inclusion proofs against a single view in Tor's
+    consensus.  The design is probabilistically secure with tunable parameters
+    that result in modest overheads.  Paper~\ref{paper:sauteed} shows that
+    Certificate Transparency logging of domain names with associated onion
+    addresses helps provide forward censorship-resistance and detection of
+    unwanted onion associations.
+
+  \item[An extension of the attacker model for website fingerprinting that
+    provides attackers with the capability of querying a website oracle.]
+
+    A website oracle reveals whether a monitored website was (not) visited by
+    any network user during a specific time frame.  Paper~\ref{paper:cat}
+    defines and simulates website fingerprinting attacks with website oracles,
+    showing that most false positives can be eliminated for all but the most
+    frequently visited websites.  A dozen sources of real-world website oracles
+    follow from the protocols used during website visits.  We enumerate and
+    classify those sources based on ease of accessibility, reliability, and
+    coverage.  The overall analysis includes several Internet measurements.
+
+  \item[Remotely-exploitable probing-attacks on Tor's DNS cache that instantiate
+    a real-world website oracle without any special attacker capabilities or reach.]
+
+    Paper~\ref{paper:cat} shows that timing differences in end-to-end response
+    times can be measured to determine whether a domain name is (not) cached by
+    a Tor relay.  An estimated true positive rate of 17.3\% can be achieved
+    while trying to minimize false positives.  Paper~\ref{paper:tlwo} improves
+    the attack by exploiting timeless timing differences that depend on
+    concurrent processing.  The improved attack has no false positives or false
+    negatives.  Our proposed bug fixes and mitigations have been merged in Tor.
+
+  \item[A complete redesign of Tor's DNS cache that defends against all (timeless)
+    timing attacks while retaining or improving performance compared~to~today.]
+
+    Paper~\ref{paper:tlwo} suggests that Tor's DNS cache should only share the
+    same preloaded domain names across different circuits to remove the
+    remotely-probable state that reveals information about past exit traffic.  A
+    network measurement with real-world Tor relays shows which popularity lists
+    are good approximations of Tor usage and, thus, appropriate to preload.
+    Cache-hit ratios can be retained or improved compared to today's Tor.
+\end{contributions}
+
+\section{Summary of Appended Papers} \label{sec:appended}
+
+The appended papers and their contexts are summarized below.  Notably, all
+papers are in publication-date order except that Paper~\ref{paper:cat} predates
+Papers~\ref{paper:ctor}--\ref{paper:sauteed}.
+
+{
+  \hypersetup{linkcolor=black}
+  \listofsummaries
+}
+
+\section{Related Work} \label{sec:related}
+
+This section positions the appended papers with regard to related work.  For
+Certificate Transparency, this includes approaches towards signed certificate
+timestamp verification, gossip, and the problem of monitoring the logs.  The
+related work with regard to Tor is focused on the practicality of website
+fingerprinting attacks and prior use of side-channels (such as timing attacks).
+
+\subsection{Certificate Transparency Verification}
+
+Approaches that fetch inclusion proofs have in common that they should preserve
+privacy by not revealing the link between users and visited websites.
+Eskandarian~\emph{et~al.}\ mention that Tor could be used to overcome privacy
+concerns; however, it comes at the cost of added infrastructure
+requirements~\cite{eskandarian}.  Lueks and Goldberg~\cite{lueks} and
+Kales~\emph{et~al.}~\cite{kales} suggest that logs could provide inclusion
+proofs using multi-server private information retrieval.  This requires a
+non-collusion assumption while also adding significant overhead.
+Laurie suggests that users can fetch inclusion proofs via DNS as their resolvers
+already learned the destination sites~\cite{ct-over-dns}.  While surveying
+signed certificate timestamp auditing,
+Meiklejohn~\emph{et~al.}\ point out that Certificate Transparency over DNS may
+have privacy limitations~\cite{sok-sct-auditing}.  For example, the time of
+domain lookups and inclusion proof queries are detached.
+Paper~\ref{paper:ctga} uses Laurie's approach as a premise while
+proposing a gossip protocol.
+Paper~\ref{paper:ctor} applies Certificate Transparency in a context
+where Tor is not additional infrastructure~(Tor~Browser).
+
+Several proposals try to avoid inclusion proof fetching altogether.
+Dirksen~\emph{et~al.}\ suggest that all logs could be involved in the issuance of
+a signed certificate timestamp~\cite{dirksen}.  This makes it harder to violate
+maximum merge delays without detection but involves relatively large changes to
+log deployments.  Nordberg~\emph{et~al.}\ suggest that signed certificate
+timestamps can be handed back to the origin web servers on subsequent
+revisits~\cite{nordberg}, which has the downside of assuming that
+machine-in-the-middle attacks eventually cease for detection.
+Nordberg~\emph{et~al.}~\cite{nordberg} as well as Chase and
+Meiklejohn~\cite{chase} suggest that some clients/users could collaborate with a
+trusted auditor.  Stark and Thompson describe how users can opt-in to use Google
+as a trusted auditor~\cite{opt-in-sct-auditing}.  This approach was recently
+replaced by opt-out auditing that cross-checks a fraction of signed
+certificate timestamps with Google using
+k-anonymity~\cite{opt-out-sct-auditing}.  Henzinger~\emph{et al.} show how such
+k-anonymity can be replaced with a single-server private information retrieval
+setup that approaches the performance of prior multi-server
+solutions~\cite{henzinger}.  None of the latter two proposals provide a solution
+for privately reporting that a log may have violated its maximum merge delay
+because the trusted auditor is assumed to know about all signed certificate
+timestamps.  Eskandarian~\emph{et~al.}\ show how to prove that a log omitted a
+certificate privately~\cite{eskandarian}.  However, they use an invalid
+assumption about today's logs being in strict timestamp
+order~\cite{sok-sct-auditing}.  Paper~\ref{paper:ctor} suggests that Tor Browser
+could submit a fraction of signed certificate timestamps to randomly selected
+Tor relays.  These relays perform further auditing on Tor Browser's behalf: much
+like a trusted auditor, except that no single entity is running it.
+
+Merkle trees fix log content---not promises of logging.  Therefore,
+inclusion proof fetching by users or their trusted parties must be accompanied
+by consistency verification and gossip to get a complete gossip-audit
+model~\cite{rfc6962}.  Chuat~\emph{et~al.}\ suggest that users and web servers
+can pool signed tree heads, gossiping about them as they interact~\cite{chuat}.
+Nordberg~\emph{et~al.}\ similarly suggest that users can pollinate signed tree
+heads as they visit different web servers~\cite{nordberg}.  Hof and Carle
+suggest that signed tree heads could be cross-logged to make all logs
+intertwined~\cite{hof}.  Gunn~\emph{et~al.}\ suggest multi-path fetching of
+signed tree heads~\cite{gunn}, which may make persistent split-views hard
+depending on the used multi-paths.  Syta~\emph{et~al.}\ suggest that independent
+witnesses could cosign the logs using threshold signatures~\cite{syta}.
+Smaller-scale versions of witness cosigning received attention in
+industry~\cite{sigsum-witness,trustfabric-arxiv}, and generally in other types
+of transparency logs as well~\cite{parakeet}.  Larger browser vendors could
+decide to push the same signed tree heads to their users, as proposed by Sleevi
+and Messeri~\cite{sth-push}.  Paper~\ref{paper:ctga} uses the operators of
+network vantage points for aggregating and verifying signed tree heads to
+provide their users with gossip-as-a-service, however assuming plaintext
+DNS traffic and a sound signed tree head frequency as defined by
+Nordberg~\emph{et~al.}~\cite{nordberg}.  We used the multi-path assumptions of
+Gunn~\emph{et~al.}\ to break out of local vantage points.  In contrast,
+Paper~\ref{paper:ctor} ensures that the same logs are observed in the Tor
+network by incorporating signed tree heads into Tor's consensus (thus making
+directory authorities into witnesses).
+
+Li~\emph{et~al.}\ argue that it would be too costly for most domains to run a
+monitor~\cite{li}.\footnote{%
+  Whether the third-party monitors in this study misbehaved or not can be
+  questioned~\cite{ayer-on-li}.
+} Similar arguments have been raised before, and lead to alternative data
+structures that could make monitoring more efficient than today's
+overhead~\cite{vds,coniks,tomescu}.  Paper~\ref{paper:lwm} falls into this
+category, as the root of an additional static lexicographically-ordered Merkle
+tree is added to a log's signed tree heads to encode batches of included
+certificates.  The downside is that a non-deployed signed tree head extension is
+assumed~\cite{rfc9162}, as well as a tree head frequency similar to those
+described by Nordberg
+\emph{et~al.}~\cite{nordberg}~to~get~efficiency~in~practise.
+
+Paper~\ref{paper:sauteed} uses a Mozilla Firefox web extension to verify
+embedded signed certificate timestamps in Tor Browser.  Such verification is
+similar to the gradual deployments of Certificate Transparency in other
+browsers~\cite{ct-history,does-ct-break-the-web}, and the starting point to
+improve upon in Papers~\ref{paper:ctga}--\ref{paper:ctor}.  Moreover, the use of
+Certificate Transparency to associate human-meaningful domain names with
+non-mnemonic onion addresses (as in Paper~\ref{paper:sauteed}) is one of many
+proposals for alternative naming systems and onion search
+solutions~\cite{kadianakis,muffet-onions,nurmi,onion-location,h-e-securedrop,onio-ns}.
+
+\subsection{Website Fingerprinting and Side-Channels}
+
+Several researchers outline how past website fingerprinting attacks have been
+evaluated in unrealistic conditions~\cite{juarez14,perryCrit,realistic}.
+This includes not accounting for the size of the open-world setting, failing to
+keep false positive rates low enough to be useful, assuming that homepages are
+browsed one at a time, how to avoid dataset drift, and training classifiers on
+synthetic network traces.  While some of these challenges were
+addressed~\cite{onlinewf,realistic}, the question of how to deal with false
+positives remains open.  Papers~\ref{paper:cat}--\ref{paper:tlwo} make a
+significant dent in this problem by providing evidence that the website
+fingerprinting attacker model could be made \emph{stronger} to capture
+\emph{realistic real-world capabilities} that eliminate most false positives
+around Alexa top-10k and the long tail~of~unpopular~sites.
+
+Others have evaluated traffic analysis attacks against Tor beyond the website
+fingerprinting setting.  On one side of the spectrum are end-to-end
+correlation/confirmation attacks that typically consider a global passive
+attacker that observes all network
+traffic~\cite{johnson13,nasr18,oh22,rimmer22}.  Such strong attackers are not
+within the scope of Tor~\cite{tor}.  On the other side of the spectrum are local
+attackers that see a small fraction of the network, typically in a position to
+observe a user's encrypted entry traffic (Figure~\ref{fig:wf}).  Many have
+studied those \emph{weak attacks} in lab settings where, e.g., advances in deep
+learning improved the accuracy significantly~\cite{wfdef,tiktok,df}.  Others
+have focused on improved attacks that are \emph{active} in the Tor network from
+their own local vantage points~\cite{chakravarty10,mittal11,murdoch05}, which is
+similar to the techniques in Papers~\ref{paper:cat}--\ref{paper:tlwo}.
+Greschbach~\emph{et~al.}\ show that an attacker who gains access to (or traffic
+to~\cite{siby20}) commonly used DNS resolvers like Google's \texttt{8.8.8.8} get
+valuable information to improve both end-to-end correlation and website
+fingerprinting attacks~\cite{greschbach}.  Paper~\ref{paper:cat} generalizes the
+attacker capability they uncovered by allowing the attacker to query Tor's
+receiver anonymity set with a website oracle of time-frame~$t$.  It is further
+shown that it is possible to instantiate such an abstraction in the real-world
+while \emph{staying within Tor's threat model}.  In other words, the attacker is
+still local but may employ passive and active measures to narrow down the
+receiver anonymity set.  Paper~\ref{paper:ctor} proposes Certificate
+Transparency verification that gives log operators website oracle access.
+Tor's directory authorities tune $t$.
+
+Website oracles exist because Tor is designed for anonymity---not unobservable
+communication~\cite{anonterm}.  The instantiation of a real-world website oracle
+is either a direct result of observing network flows from the protocols
+used during website visits, or due to state of these network flows being stored
+and inferable.  Inferring secret system state is widely studied in applied
+cryptography and hardware
+architecture~\cite{lucky13,ge18,kocher96,mart21,tsunoo03,heist}, where the goal
+is usually to determine a key, decrypt a ciphertext, forge a message, or similar
+using side-channels.  A side-channel can be local or remote and ranges from
+analysis of power consumption to cache states and timing differences.  There is
+a long history of remote timing attacks that are
+practical~\cite{bbrumley11,dbrumley03,crosby09,wang22}.  A recent improvement in
+this area that is relevant for Tor is timeless timing attacks, which exploit
+concurrency and message reordering to eliminate network jitter~\cite{timeless}.
+Paper~\ref{paper:cat} demonstrates a remote timing attack against Tor's DNS
+cache that achieves up to 17.3\% true positive rates while minimizing false
+positives.  Paper~\ref{paper:tlwo} instead uses a remote timeless timing attack
+with no false positives, no false negatives, and a small time-frame $t$.  This
+approaches an ideal website oracle without special attacker capabilities or
+reach into third-parties.
+
+\section{Conclusions and Future Work} \label{sec:concl}
+
+Throughout the thesis, we contributed to the understanding of how trust
+requirements in Certificate Transparency can be reduced.  Efficient and reliable
+monitoring of the logs is easily overlooked.  If the broader ecosystem achieves
+monitoring through third-parties, they should be subject to the same scrutiny as
+logs.  We proposed a solution that makes it hard for third-party monitors to
+provide subscribers with selective certificate notifications.  We also proposed
+a gossip-audit model that plugs into interacting with the logs over DNS by
+having programmable packet processors verify that the same append-only logs are
+observed.  Avoiding the addition of complicated verification logic into end-user
+software is likely a long-term win because it reduces the number of moving
+parts.  In other words, simple gossip-audit models will be much easier to deploy
+in the wide variety of end-user software that embeds TLS clients.
+
+We also contributed to the understanding of how Certificate Transparency can be
+applied in the context of Tor Browser.  Compared to a regular browser, this
+results in a different setting with its own challenges and opportunities.  On
+the one hand, Tor Browser benefits from the ability to preserve privacy due to
+using the anonymity network Tor.  On the other hand, data relating to
+website visits cannot be persisted to disk (such as signed certificate
+timestamps blocked by maximum merge delays).  Our incrementally-deployable
+proposal keeps the logic in Tor Browser simple by offloading all Certificate
+Transparency verification to randomly selected Tor relays.  The design is
+complete because mis-issued certificates can eventually reach a trusted auditor
+who acts on incidents.  In addition to proposing Certificate Transparency in Tor
+Browser, we also explored how certificates with onion addresses may improve the
+association of domain names with onion addresses.  Such certificates ensure
+domain owners know which onion addresses can be discovered for their sites, much
+like Certificate Transparency does the same thing for public TLS keys.  This
+also adds censorship resistance to the discovery as logs are append-only.
+
+As part of exploring Certificate Transparency in Tor Browser, we further
+contributed to the understanding of how the protocols used during website visits
+affect unlinkability between Tor users and their destination websites.  For
+example, fetching an inclusion proof from a Certificate Transparency log is one
+such protocol.  We extended the attacker model of website fingerprinting attacks
+with website oracles that reveal whether any network user visited a website
+during a specific time frame.  Our results show that website oracles eliminate
+most false positives for all but the most frequently visited websites.  In
+addition to the theoretical evaluation of the extended attacker model, we could
+exploit (timeless) timing attacks in Tor's DNS cache to instantiate real-world
+website oracles without any special capabilities or reach into third-parties.
+This led us to contribute to the understanding of how Tor's DNS cache performs
+today, including a proposal for a performant alternative that preloads the same
+popular domains on all Tor relays to withstand all (timeless) timing attacks.
+
+As an outlook, our angle on Certificate Transparency verification has mostly
+been \emph{reactive} for end-users.  In other words, some or all certificate
+verification occurs asynchronously after a website visit.  An alternative to
+this would be upfront delivery of inclusion proofs that reconstruct tree heads
+which witnesses cosigned; a form of \emph{proactive} gossip as proposed by
+Syta~\emph{et al.}~\cite{syta}.  The significant upside is that the browser's
+verification could become non-interactive, eliminating privacy concerns and
+ensuring end-users only see certificates merged into the append-only logs.
+Investigating what the blockers for such a proposal are in
+practice---today---would be valuable as log verification quickly becomes
+complicated with signed certificate timestamps and reactive gossip-audit models.
+Are these blockers significant?  Are they significant over time as other
+\emph{eventual} changes will be needed, like post-quantum secure certificates?
+New transparency log applications are unlikely to need the complexity of
+Certificate Transparency, and should likely not copy something that was designed
+to fit into an existing system with a large amount of legacy (such as
+certificate authorities, their established processes for certificate issuance,
+and the many client-server implementations already deployed on the Internet).
+
+Orthogonal to the verification performed by end-users, contributing to the
+understanding of how domains (fail to) use Certificate Transparency for
+detecting mis-issued certificates is largely unexplored.  For example,
+subscribing to email notifications of newly issued certificates becomes less
+useful in an era where certificates are renewed frequently and automatically.
+Instead, domain owners need easy-to-use solutions that raise alarms only if
+there is a problem.
+
+Finally, the mitigation deployed to counter our (timeless) timing attacks in
+Tor's DNS cache is just that: a mitigation, not a defense, that applies to
+modestly popular websites but not the long tail where the base rate is low.
+This is because the attacker's needed website oracle time frame is so large that
+a fuzzy time-to-live value does nothing.  Practical aspects of a preloaded DNS
+cache need to be explored further before deployment, such as the assumption of a
+third-party that visits popular domains to assemble an allowlist.  We may also
+have \emph{underestimated} the utility of the existing Umbrella list, which in
+and of itself does not require any new third-party.  Does the use of Umbrella
+impact page-load latency?  Latency is the most crucial parameter to keep
+minimized.  The question is whether frequently looked-up domains are missed or
+not by skipping the website-visit step, as for the non-extended Alexa and Tranco
+lists.
+
+More broadly, the question of how to strike a balance between \emph{efficiency}
+and \emph{effectiveness} of website fingerprinting defenses is open.  How much
+overhead in terms of added latency and/or bandwidth is needed?  How much of that
+overhead is sustainable, both from a user perspective (where, e.g., latency is
+crucial for web browsing and other interactive activities) and a network health
+perspective (such as the amount of volunteered relay bandwidth that is wasted)?  It is
+paramount to neither overestimate nor underestimate attacker capabilities, which
+goes back to the still-debated threat model of website fingerprinting attacks.
+Regardless of if Tor's DNS cache becomes preloaded or not, it will be difficult
+to circumvent DNS lookups from happening.  Someone---be it a weak attacker like
+ourselves or a recursive DNS resolver at an Internet service provider---is in a
+position to narrow down the destination anonymity set.  This is especially true
+when also considering other protocols that reveal information about the
+destination anonymity set during website visits.  Accepting that sources of
+real-world website oracles are prevalent implies that \emph{the world can be
+closed}.  Therefore, a closed world is more realistic than an open world.
+
+\subsection*{Acknowledgments}
+I received valuable feedback while writing the introductory summary from
+  Simone Fischer-H\"{u}bner
+  Johan Garcia,
+  Stefan Lindskog, and
+  Tobias Pulls.
+The final draft was further improved with helpful nudges from Grammarly.
+
+\bibliographystyle{plain}
+\bibliography{src/introduction/refs}
diff --git a/summary/src/introduction/refs.bib b/summary/src/introduction/refs.bib
new file mode 100644
index 0000000..fc31dd8
--- /dev/null
+++ b/summary/src/introduction/refs.bib
@@ -0,0 +1,954 @@
+%%%
+% Certificate transparency
+%%%
+@techreport{rfc6962,
+  author      = {Ben Laurie and Adam Langley and Emilia Kasper},
+  title       = {{Certificate Transparency}},
+  number      = {6962},
+  type        = {RFC},
+  institution = {IETF},
+  year        = {2013},
+  url         = {https://tools.ietf.org/html/rfc6962},
+}
+
+@techreport{rfc9162,
+  author      = {Ben Laurie and Eran Messeri and Rob Stradling},
+  title       = {{Certificate Transparency} Version 2.0},
+  number      = {9162},
+  type        = {RFC},
+  institution = {IETF},
+  year        = {2021},
+  url         = {https://tools.ietf.org/html/rfc9162},
+}
+
+@misc{google-log-policy,
+  author       = {{Google LLC.}},
+  title        = {{Certificate Transparency} in {Chrome}},
+  howpublished = {\url{https://googlechrome.github.io/CertificateTransparency/ct_policy.html}, accessed 2023-04-30},
+}
+
+@misc{apple-log-policy,
+  author       = {{Apple Inc.}},
+  title        = {Apple's {Certificate Transparency} Policy},
+  howpublished = {\url{https://support.apple.com/en-us/HT205280}, accessed 2023-04-30},
+}
+
+@misc{ct-monitors,
+  author = {{Google LLC.}},
+  title = {The list of existing monitors},
+  howpublished = {\url{https://certificate.transparency.dev/monitors/}, accessed 2023-04-30},
+}
+
+@misc{sslmate-history, 
+  author       = {{SSLMate Inc.}},
+  title        = {Timeline of Certificate Authority Failures},
+  howpublished = {\url{https://sslmate.com/resources/certificate_authority_failures}, accessed 2023-04-30},
+}
+
+@misc{merkle-intro,
+  author = {Rasmus Dahlberg},
+  title = {Transparency log preliminaries},
+  howpublished = {\url{https://gitlab.torproject.org/rgdd/ct/-/blob/main/doc/tlog-preliminaries.md}, accessed 2023-04-30},
+}
+
+@article{ct,
+  author    = {Ben Laurie},
+  title     = {{Certificate Transparency}},
+  journal   = {CACM},
+  volume    = {57},
+  number    = {10},
+  year      = {2014},
+}
+
+@article{ct-history,
+  author    = {Emily Stark and
+               Joe DeBlasio and
+               Devon O'Brien and
+               Davide Balzarotti and
+               William Enck and
+               Samuel King and
+               Angelos Stavrou},
+  title     = {{Certificate Transparency} in {Google Chrome}: Past, Present, and Future},
+  journal   = {{IEEE} {S\&P}},
+  volume    = {19},
+  number    = {6},
+  year      = {2021},
+}
+
+@article{sok-sct-auditing,
+  author    = {Sarah Meiklejohn and
+               Joe DeBlasio and
+               Devon O'Brien and
+               Chris Thompson and
+               Kevin Yeo and
+               Emily Stark},
+  title     = {{SoK}: {SCT} Auditing in {Certificate Transparency}},
+  journal   = {PETS},
+  volume    = {2022},
+  number    = {3},
+}
+
+@inproceedings{does-ct-break-the-web,
+  author    = {Emily Stark and Ryan Sleevi and Rijad Muminovic and Devon O'Brien and Eran Messeri and Adrienne Porter Felt and Brendan McMillion and Parisa Tabriz},
+  title     = {Does {Certificate Transparency} Break the Web? {Measuring} Adoption and Error Rate},
+  booktitle = {IEEE S\&P},
+  year      = {2019},
+}
+
+@inproceedings{ct-formal,
+  author    = {Benjamin Dowling and
+    Felix G{\"{u}}nther and
+    Udyani Herath and
+    Douglas Stebila},
+  title     = {Secure Logging Schemes and {Certificate Transparency}},
+  booktitle = {ESORICS},
+  year      = {2016},
+}
+
+@techreport{nordberg,
+  author      = {Linus Nordberg and Daniel Kahn Gillmor and Tom Ritter},
+  title       = {Gossiping in {CT}},
+  number      = {draft-ietf-trans-gossip-05},
+  type        = {Internet-draft},
+  institution = {IETF},
+  year        = {2018},
+  url         = {https://tools.ietf.org/html/draft-ietf-trans-gossip-05}
+}
+
+@inproceedings{chuat,
+  author    = {Laurent Chuat and Pawel Szalachowski and Adrian Perrig and Ben Laurie and Eran Messeri},
+  title     = {Efficient Gossip Protocols for Verifying the Consistency of Certificate Logs},
+  booktitle = {CNS},
+  year      = {2015},
+}
+
+@inproceedings{gunn,
+  author    = {Lachlan J. Gunn and Andrew Allison and Derek Abbott},
+  title     = {Safety in Numbers: Anonymization Makes Keyservers Trustworthy},
+  booktitle = {HotPETs},
+  year      = {2017},
+}
+
+@article{hof,
+  author    = {Benjamin Hof and Georg Carle},
+  title     = {Software Distribution Transparency and Auditability},
+  journal   = {CoRR},
+  volume    = {abs/1711.07278},
+  year      = {2017},
+}
+
+@inproceedings{syta,
+  author    = {Ewa Syta and Iulia Tamas and Dylan Visher and David Isaac Wolinsky and Philipp Jovanovic and Linus Gasser and Nicolas Gailly and Ismail Khoffi and Bryan Ford},
+  title     = {Keeping Authorities "Honest or Bust" with Decentralized Witness Cosigning},
+  booktitle = {IEEE S\&P},
+  year      = {2016},
+}
+
+@article{trustfabric-arxiv,
+  author       = {Sarah Meiklejohn and
+                  Pavel Kalinnikov and
+                  Cindy S. Lin and
+                  Martin Hutchinson and
+                  Gary Belvin and
+                  Mariana Raykova and
+                  Al Cutter},
+  title        = {Think Global, Act Local: Gossip and Client Audits in Verifiable Data Structures},
+  journal      = {CoRR},
+  volume       = {abs/2011.04551},
+  year         = {2020},
+}
+
+@misc{sigsum-witness,
+  author       = {Sigsum Project Contributors},
+  title        = {Witness {API} v0},
+  howpublished = {\url{https://git.glasklar.is/sigsum/project/documentation/-/blob/main/witness.md}, accessed 2023-04-30},
+}
+
+@inproceedings{parakeet,
+  author       = {Harjasleen Malvai and
+                  Lefteris Kokoris{-}Kogias and
+                  Alberto Sonnino and
+                  Esha Ghosh and
+                  Ercan Ozt{\"{u}}rk and
+                  Kevin Lewi and
+                  Sean F. Lawlor},
+  title        = {Parakeet: Practical Key Transparency for End-to-End Encrypted Messaging},
+  booktitle    = {{NDSS}},
+  year         = {2023},
+}
+
+@article{dirksen,
+  author       = {Alexandra Dirksen and
+                  David Klein and
+                  Robert Michael and
+                  Tilman Stehr and
+                  Konrad Rieck and
+                  Martin Johns},
+  title        = {{LogPicker}: Strengthening {Certificate Transparency} Against Covert Adversaries},
+  journal      = {PETS},
+  volume       = {2021},
+  number       = {4},
+}
+
+@misc{ct-over-dns,
+  author = {Ben Laurie},
+  title  = {{Certificate Transparency} over {DNS}},
+  howpublished = {\url{https://github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-over-dns.md}, accessed 2023-04-30},
+}
+
+@inproceedings{lueks,
+  author    = {Wouter Lueks and Ian Goldberg},
+  title     = {Sublinear Scaling for Multi-Client Private Information Retrieval},
+  booktitle = {FC},
+  year      = {2015},
+}
+
+@inproceedings{kales,
+  author    = {Daniel Kales and Olamide Omolola and Sebastian Ramacher},
+  title     = {Revisiting User Privacy for {Certificate Transparency}},
+  booktitle = {IEEE EuroS\&P},
+  year      = {2019},
+}
+
+@inproceedings{henzinger,
+  author    = {Alexandra Henzinger and Matthew M. Hong and Henry Corrigan-Gibbs and Sarah Meiklejohn and Vinod Vaikuntanathan},
+  title     = {One Server for the Price of Two: Simple and Fast Single-Server Private Information Retrieval},
+  booktitle = {{USENIX Security}},
+  year      = {2023},
+}
+
+@inproceedings{chase,
+  author    = {Melissa Chase and Sarah Meiklejohn},
+  title     = {Transparency Overlays and Applications},
+  booktitle = {CCS},
+  year      = {2016},
+}
+
+@article{eskandarian,
+  author       = {Saba Eskandarian and
+                  Eran Messeri and
+                  Joseph Bonneau and
+                  Dan Boneh},
+  title        = {{Certificate Transparency} with Privacy},
+  journal      = {PETS},
+  volume       = {2017},
+  number       = {4},
+}
+
+@misc{opt-in-sct-auditing,
+  title = {Opt-in {SCT} Auditing},
+  author = {Emily Stark and Chris Thompson},
+  howpublished = {\url{https://docs.google.com/document/d/1G1Jy8LJgSqJ-B673GnTYIG4b7XRw2ZLtvvSlrqFcl4A/edit}, accessed 2023-04-30},
+}
+
+@misc{opt-out-sct-auditing,
+  title = {Opt-out {SCT} Auditing in {Chrome}},
+  author = {Joe DeBlasio},
+  howpublished = {\url{https://docs.google.com/document/d/16G-Q7iN3kB46GSW5b-sfH5MO3nKSYyEb77YsM7TMZGE/edit}, accessed 2023-04-30},
+}
+
+@misc{sth-push,
+  author       = {Ryan Sleevi and Eran Messeri},
+  title        = {{Certificate Transparency} in {Chrome}: Monitoring {CT} Logs consistency},
+  howpublished = {\url{https://docs.google.com/document/d/1FP5J5Sfsg0OR9P4YT0q1dM02iavhi8ix1mZlZe_z-ls/edit?pref=2&pli=1}, accessed 2023-04-30},
+}
+
+@misc{crt.sh,
+  author       = {{Sectigo Limited}},
+  title        = {{crt.sh}: certificate search},
+  howpublished = {\url{https://github.com/crtsh}, accessed 2023-04-30},
+}
+
+@misc{certspotter,
+  author       = {{SSLMate Inc.}},
+  title        = {Cert Spotter---{Certificate Transparency} Monitor},
+  howpublished = {\url{https://github.com/SSLMate/certspotter}, accessed 2023-04-30},
+}
+
+@misc{vds,
+  author        = {Adam Eijdenberg and Ben Laurie and Al Cutter},
+  title         = {Verifiable Data Structures},
+  howpublished  = {\url{https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf}, accessed 2023-04-30},
+}
+
+@inproceedings{coniks,
+  author       = {Marcela S. Melara and
+                  Aaron Blankstein and
+                  Joseph Bonneau and
+                  Edward W. Felten and
+                  Michael J. Freedman},
+  title        = {{CONIKS:} Bringing Key Transparency to End Users},
+  booktitle    = {{USENIX} Security},
+  year         = {2015},
+}
+
+@inproceedings{tomescu,
+  author       = {Alin Tomescu and
+                  Vivek Bhupatiraju and
+                  Dimitrios Papadopoulos and
+                  Charalampos Papamanthou and
+                  Nikos Triandopoulos and
+                  Srinivas Devadas},
+  title        = {Transparency Logs via Append-Only Authenticated Dictionaries},
+  booktitle    = {{CCS}},
+  year         = {2019},
+}
+
+@inproceedings{li,
+  author       = {Bingyu Li and
+                  Jingqiang Lin and
+                  Fengjun Li and
+                  Qiongxiao Wang and
+                  Qi Li and
+                  Jiwu Jing and
+                  Congli Wang},
+  title        = {{Certificate Transparency} in the Wild: Exploring the Reliability of Monitors},
+  booktitle    = {{CCS}},
+  year         = {2019},
+}
+
+@misc{ayer-on-li,
+  author = {Andrew Ayer},
+  title  = {Reliability of Monitors | Mitigations},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/g/ct-policy/c/zCtQrn_7QK8}, accessed 2023-04-30},
+}
+
+@misc{cloudflare-scts,
+  author       = {Nick Sullivan},
+  title        = {Understanding use-cases for {SCTs} delivered via {OCSP} stapling for {TLS} extension},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/g/ct-policy/c/WX6iZt7uJBs}, accessed 2023-04-30},
+}
+
+@misc{izenpe-err,
+  author       = {Ryan Sleevi},
+  title        = {Upcoming {CT} Log Removal: {Izenpe}},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/qOorKuhL1vA}, accessed 2023-04-30},
+}
+
+@misc{venafi-err,
+  author       = {Ryan Sleevi},
+  title        = {Upcoming Log Removal: {Venafi CT} Log Server},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/KMAcNT3asTQ}, accessed 2023-04-30},
+}
+
+@misc{trustasia-err,
+  author       = {Andrew Ayer},
+  title        = {{Trust Asia} 2021 has produced inconsistent {STHs}},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/g/ct-policy/c/VJaSg717m9g}, accessed 2023-04-30},
+}
+
+@misc{google-err,
+  author       = {Paul Hadfield},
+  title        = {Google {Aviator} incident under investigation},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/g/ct-policy/c/ZZf3iryLgCo/m/mi-4ViMiCAAJ}, accessed 2023-04-30},
+}
+
+@misc{starcom-err,
+  author       = {Ryan Sleevi},
+  title        = {{StartCom} Log misbehaving: Failure to incorporate {SCTs}},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/g/ct-policy/c/92HIh2vG6GA/m/hBEHxcpoCgAJ}, accessed 2023-04-30}},
+}
+
+@misc{wosign-err,
+  author       = {Graham Edgecombe},
+  title        = {{WoSign} log failure to incorporate entry within the {MMD}},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/g/ct-policy/c/-eV4Xe8toVk/m/pC5gSjJKCwAJ}, accessed 2023-04-30},
+}
+
+@misc{digicert-err,
+  author       = {Andrew Ayer},
+  title        = {Retiring {DigiCert} Log Server (aka {``CT1''}) in {Chrome}},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/g/ct-policy/c/P5aj4JEBFPM/m/9AEcvY01EQAJ}, accessed 2023-04-30},
+}
+
+@misc{digicert-kc,
+  title        = {{CT2} Log Compromised via {Salt} Vulnerability},
+  author       = {Jeremy Rowley},
+  howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/aKNbZuJzwfM}, accessed 2023-04-30},
+}
+
+%%%
+% Tor and traffic analysis
+%%%
+@misc{tpo,
+  author = {Tor Project},
+  title = {Browse Privately.  {Explore} Freely.  {Defend} yourself against tracking and surveillance. {Circumvent} censorship.},
+  howpublished = {\url{https://www.torproject.org/}, accessed 2022-04-30},
+}
+
+@inproceedings{tor,
+  author    = {Roger Dingledine and Nick Mathewson and Paul F. Syverson},
+  title     = {Tor: The Second-Generation Onion Router},
+  booktitle = {{USENIX Security}},
+  year      = {2004},
+}
+
+@misc{tb,
+  author       = {Mike Perry and Erinn Clark and Steven Murdoch and Georg Koppen},
+  title        = {The Design and Implementation of the {Tor Browser [DRAFT]}},
+  howpublished = {\url{https://2019.www.torproject.org/projects/torbrowser/design/}, accessed 2023-04-30},
+}
+
+@inproceedings{mani,
+  author    = {Akshaya Mani and
+               T. Wilson{-}Brown and
+               Rob Jansen and
+               Aaron Johnson and
+               Micah Sherr},
+  title     = {Understanding {Tor} Usage with Privacy-Preserving Measurement},
+  booktitle = {{IMC}},
+  year      = {2018}
+}
+
+@inproceedings{johnson13,
+  author    = {Aaron Johnson and Chris Wacek and Rob Jansen and Micah Sherr and Paul F. Syverson},
+  title     = {Users get routed: traffic correlation on {Tor} by realistic adversaries},
+  booktitle = {{CCS}},
+  year      = {2013}
+}
+
+@inproceedings{nasr18,
+  author    = {Milad Nasr and Alireza Bahramali and Amir Houmansadr},
+  title     = {{DeepCorr}: Strong Flow Correlation Attacks on {Tor} Using Deep Learning},
+  booktitle = {{CCS}},
+  year      = {2018}
+}
+
+@article{rimmer22,
+  author       = {Vera Rimmer and
+                  Theodor Schnitzler and
+                  Tom van Goethem and
+                  Abel Rodr{\'{\i}}guez Romero and
+                  Wouter Joosen and
+                  Katharina Kohls},
+  title        = {Trace Oddity: Methodologies for Data-Driven Traffic Analysis on {Tor}},
+  journal      = {PETS},
+  volume       = {2022},
+  number       = {3},
+}
+
+@inproceedings{oh22,
+  author       = {Se Eun Oh and
+                  Taiji Yang and
+                  Nate Mathews and
+                  James K. Holland and
+                  Mohammad Saidur Rahman and
+                  Nicholas Hopper and
+                  Matthew Wright},
+  title        = {{DeepCoFFEA}: Improved Flow Correlation Attacks on {Tor} via Metric Learning and Amplification},
+  booktitle    = {{IEEE} {S\&P}},
+  year         = {2022},
+}
+
+@article{cheng98,
+  title   = {Traffic analysis of {SSL} encrypted web browsing},
+  author  = {Cheng, Heyning and Avnur, Ron},
+  journal = {Project paper, University of Berkeley},
+  year    = {1998}
+}
+
+@inproceedings{herrmann09,
+  author    = {Dominik Herrmann and Rolf Wendolsky and Hannes Federrath},
+  title     = {Website fingerprinting: attacking popular privacy enhancing technologies with the multinomial na{\"{\i}}ve-bayes classifier},
+  booktitle = {{CCSW}},
+  year      = {2009}
+}
+
+@inproceedings{hintz02,
+  author    = {Andrew Hintz},
+  title     = {Fingerprinting Websites Using Traffic Analysis},
+  booktitle = {{PETS}},
+  year      = {2002}
+}
+
+@inproceedings{liberatore06,
+  author    = {Marc Liberatore and Brian Neil Levine},
+  title     = {Inferring the source of encrypted {HTTP} connections},
+  booktitle = {{CCS}},
+  year      = {2006}
+}
+
+@inproceedings{panchenko11,
+  author    = {Andriy Panchenko and Lukas Niessen and Andreas Zinnen and Thomas Engel},
+  title     = {Website fingerprinting in onion routing based anonymization networks},
+  booktitle = {{WPES}},
+  year      = {2011}
+}
+
+@inproceedings{sun02,
+  author    = {Qixiang Sun and Daniel R. Simon and Yi{-}Min Wang and Wilf Russell and Venkata N. Padmanabhan and Lili Qiu},
+  title     = {Statistical Identification of Encrypted Web Browsing Traffic},
+  booktitle = {{IEEE S\&P}},
+  year      = {2002}
+}
+
+@inproceedings{juarez14,
+  author    = {Marc Ju{\'{a}}rez and Sadia Afroz and Gunes Acar and Claudia D{\'{\i}}az and Rachel Greenstadt},
+  title     = {A Critical Evaluation of Website Fingerprinting Attacks},
+  booktitle = {{CCS}},
+  year      = {2014},
+}
+
+@misc{perryCrit,
+  author       = {Mike Perry},
+  title        = {A Critique of Website Traffic Fingerprinting Attacks},
+  howpublished = {\url{https://blog.torproject.org/critique-website-traffic-fingerprinting-attacks}, accessed 2023-04-30},
+}
+
+@article{realistic,
+  author    = {Tao Wang and Ian Goldberg},
+  title     = {On Realistically Attacking {Tor} with Website Fingerprinting},
+  journal   = {PETS},
+  volume    = {2016},
+  number    = {4},
+}
+
+@inproceedings{onlinewf,
+  title={Online Website Fingerprinting: Evaluating Website Fingerprinting Attacks on {Tor} in the Real World},
+  author={Cherubin, Giovanni and Jansen, Rob and Troncoso, Carmela},
+  booktitle={{USENIX Security}},
+  year={2022}
+}
+
+@inproceedings{df,
+  author    = {Payap Sirinam and
+               Mohsen Imani and
+               Marc Ju{\'{a}}rez and
+               Matthew Wright},
+  title     = {Deep Fingerprinting: Undermining Website Fingerprinting Defenses with
+               Deep Learning},
+  booktitle = {{CCS}},
+  year      = {2018}
+}
+
+@article{tiktok,
+  author    = {Mohammad Saidur Rahman and
+               Payap Sirinam and
+               Nate Mathews and
+               Kantha Girish Gangadhara and
+               Matthew Wright},
+  title     = {{Tik-Tok}: The Utility of Packet Timing in Website Fingerprinting Attacks},
+  journal   = {{PETS}},
+  volume    = {2020},
+  number    = {3},
+}
+
+@inproceedings{wfdef,
+  title={{SoK}: A Critical Evaluation of Efficient Website Fingerprinting Defenses},
+  author={Mathews, Nate and Holland, James K and Oh, Se Eun and Rahman, Mohammad Saidur and Hopper, Nicholas and Wright, Matthew},
+  booktitle = {{IEEE} S{\&}P},
+  year={2023}
+}
+
+@inproceedings{spoiled-onions,
+  author    = {Philipp Winter and Richard K{\"{o}}wer and Martin Mulazzani and Markus Huber and Sebastian Schrittwieser and Stefan Lindskog and Edgar R. Weippl},
+  title     = {Spoiled Onions: Exposing Malicious {Tor} Exit Relays},
+  booktitle = {PETS},
+  year      = {2014},
+}
+
+@inproceedings{murdoch05,
+  author       = {Steven J. Murdoch and George Danezis},
+  title        = {Low-Cost Traffic Analysis of {Tor}},
+  booktitle    = {{IEEE S\&P}},
+  year         = {2005},
+}
+
+@inproceedings{chakravarty10,
+  author       = {Sambuddho Chakravarty and Angelos Stavrou and Angelos D. Keromytis},
+  title        = {Traffic Analysis against Low-Latency Anonymity Networks Using Available Bandwidth Estimation},
+  booktitle    = {{ESORICS}},
+  year         = {2010},
+}
+
+@inproceedings{mittal11,
+  author       = {Prateek Mittal and
+                  Ahmed Khurshid and
+                  Joshua Juen and
+                  Matthew Caesar and
+                  Nikita Borisov},
+  title        = {Stealthy traffic analysis of low-latency anonymous communication using throughput fingerprinting},
+  booktitle    = {{CCS}},
+  year         = {2011},
+}
+
+@inproceedings{greschbach,
+  author    = {Benjamin Greschbach and
+               Tobias Pulls and
+               Laura M. Roberts and
+               Phillip Winter and
+               Nick Feamster},
+  title     = {The Effect of {DNS} on {Tor}'s Anonymity},
+  booktitle = {{NDSS}},
+  year      = {2017},
+}
+
+@inproceedings{siby20,
+  author    = {Sandra Siby and Marc Ju{\'{a}}rez and Claudia D{\'{\i}}az and Narseo Vallina{-}Rodriguez and Carmela Troncoso},
+  title     = {Encrypted {DNS} -{\textgreater} Privacy? {A} Traffic Analysis Perspective},
+  booktitle = {NDSS},
+  year      = {2020},
+}
+
+@misc{anonterm,
+  title={A terminology for talking about privacy by data minimization: Anonymity, unlinkability, undetectability, unobservability, pseudonymity, and identity management},
+  author={Pfitzmann, Andreas and Hansen, Marit},
+  publisher={Dresden, Germany},
+  year={2010},
+}
+
+###
+# Side-channels
+###
+@inproceedings{kocher96,
+  author       = {Paul C. Kocher},
+  title        = {Timing Attacks on Implementations of {Diffie-Hellman}, {RSA}, {DSS}, and Other Systems},
+  booktitle    = {{CRYPTO}},
+  year         = {1996},
+}
+
+@inproceedings{dbrumley03,
+  author       = {David Brumley and Dan Boneh},
+  title        = {Remote Timing Attacks Are Practical},
+  booktitle    = {{USENIX} Security},
+  year         = {2003},
+}
+
+@inproceedings{tsunoo03,
+  author       = {Yukiyasu Tsunoo and
+                  Teruo Saito and
+                  Tomoyasu Suzaki and
+                  Maki Shigeri and
+                  Hiroshi Miyauchi},
+  title        = {Cryptanalysis of {DES} Implemented on Computers with Cache},
+  booktitle    = {{CHES}},
+  year         = {2003},
+}
+
+@article{crosby09,
+  author       = {Scott A. Crosby and Dan S. Wallach and Rudolf H. Riedi},
+  title        = {Opportunities and Limits of Remote Timing Attacks},
+  journal      = {{ACM} Trans. Inf. Syst. Secur.},
+  volume       = {12},
+  number       = {3},
+  year         = {2009},
+}
+
+@inproceedings{bbrumley11,
+  author       = {Billy Bob Brumley and Nicola Tuveri},
+  title        = {Remote Timing Attacks Are Still Practical},
+  booktitle    = {{ESORICS}},
+  year         = {2011},
+}
+
+@article{ge18,
+  author       = {Qian Ge and
+                  Yuval Yarom and
+                  David A. Cock and
+                  Gernot Heiser},
+  title        = {A survey of microarchitectural timing attacks and countermeasures on contemporary hardware},
+  journal      = {JCEN},
+  volume       = {8},
+  number       = {1},
+  year         = {2018},
+}
+
+@inproceedings{mart21,
+  author       = {Macarena C. Mart{\'{\i}}nez{-}Rodr{\'{\i}}guez and
+                  Ignacio M. Delgado{-}Lozano and
+                  Billy Bob Brumley},
+  title        = {{SoK}: Remote Power Analysis},
+  booktitle    = {{ARES}},
+  year         = {2021},
+}
+
+@inproceedings{lucky13,
+  author       = {Nadhem J. AlFardan and Kenneth G. Paterson},
+  title        = {Lucky Thirteen: Breaking the {TLS} and {DTLS} Record Protocols},
+  booktitle    = {{IEEE} {S\&P}},
+  year         = {2013},
+}
+
+@inproceedings{heist,
+  author    = {Mathy Vanhoef and Tom Van Goethem},
+  title     = {{HEIST}: {HTTP} Encrypted Information can be
+Stolen through {TCP}-windows},
+  booktitle = {Black Hat US Briefings},
+  year      = {2016},
+}
+
+@inproceedings{timeless,
+  author    = {Tom van Goethem and Christina P{\"{o}}pper and Wouter Joosen and Mathy Vanhoef},
+  title     = {Timeless Timing Attacks: Exploiting Concurrency to Leak Secrets over Remote Connections},
+  booktitle = {{USENIX} Security},
+  year      = {2020},
+}
+
+@inproceedings{wang22,
+  author       = {Yingchen Wang and
+                  Riccardo Paccagnella and
+                  Elizabeth Tang He and
+                  Hovav Shacham and
+                  Christopher W. Fletcher and
+                  David Kohlbrenner},
+  title        = {Hertzbleed: Turning Power Side-Channel Attacks Into Remote Timing Attacks on x86},
+  booktitle    = {{USENIX} Security},
+  year         = {2022},
+}
+
+%%%
+% Research methods
+%%%
+@inproceedings{sse,
+  author    = {Cormac Herley and Paul C. van Oorschot},
+  title     = {{SoK}: Science, Security and the Elusive Goal of Security as a Scientific Pursuit},
+  booktitle = {{IEEE} {S\&P}},
+  year      = {2017},
+}
+
+@inproceedings{smics,
+  author    = {Dodig-Crnkovic, Gordana},
+  title     = {Scientific methods in computer science},
+  booktitle = {Proceedings of the Conference for the Promotion of Research in IT at New Universities and at University Colleges in Sk\"{o}vde, Sweden},
+  year      = {2002},
+}
+
+@article{icss,
+  author  = {Denning, Peter J},
+  title   = {Is computer science science?},
+  journal = {CACM},
+  volume  = {48},
+  number  = {4},
+  year    = {2005},
+}
+
+@article{rfenr,
+  author    = {Vaibhav Bajpai and
+               Anna Brunstr{\"{o}}m and
+               Anja Feldmann and
+               Wolfgang Kellerer and
+               Aiko Pras and
+               Henning Schulzrinne and
+               Georgios Smaragdakis and
+               Matthias W{\"{a}}hlisch and
+               Klaus Wehrle},
+  title     = {The Dagstuhl beginners guide to reproducibility for experimental networking research},
+  journal   = {CCR},
+  volume    = {49},
+  number    = {1},
+  year      = {2019},
+}
+
+% "There are several reasons why definitions are important [...]"
+% "[...] focusing their efforts on devising attacks that are outside the model"
+@article{secdefs,
+  author       = {Neal Koblitz and Alfred Menezes},
+  title        = {Another look at security definitions},
+  journal      = {AMC},
+  volume       = {7},
+  number       = {1},
+  year         = {2013},
+}
+
+% §1.1 gives the background of the first reduction proofs / provable security
+@article{provsec,
+  author       = {Neal Koblitz and
+                  Alfred Menezes},
+  title        = {Another Look at ``Provable Security''},
+  journal      = {J. Cryptol.},
+  volume       = {20},
+  number       = {1},
+  year         = {2007},
+}
+
+
+%%%
+% Naming of onion services
+%%%
+@misc{onion-location,
+  author       = {Tor Project},
+  title        = {{Onion-Location}},
+  howpublished = {\url{https://community.torproject.org/onion-services/advanced/onion-location/}, accessed 2023-04-30}, 
+}
+
+@misc{kadianakis,
+  author       = {George Kadianakis and Yawning Angel and David Goulet},
+  title        = {A Name System {API} for {Tor} Onion Services},
+  howpublished = {\url{https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/279-naming-layer-api.txt}, accessed 2023-04-30},
+}
+
+@misc{muffet-onions,
+  author       = {Alec Muffett},
+  title        = {Real-World Onion Sites},
+  howpublished = {\url{https://github.com/alecmuffett/real-world-onion-sites}, accessed 2023-04-30},
+}
+
+@phdthesis{nurmi,
+  author = {Nurmi, Juha},
+  title  = {Understanding the Usage of Anonymous Onion Services},
+  year   = {2019},
+  school = {Tampere University, Finland},
+}
+
+@Misc{h-e-securedrop,
+  author       = {SecureDrop},
+  title        = {Getting an Onion Name for Your {SecureDrop}},
+  howpublished = {\url{https://securedrop.org/faq/getting-onion-name-your-securedrop/}, accessed 2023-04-30},
+}
+
+@article{onio-ns,
+  author    = {Jesse Victors and Ming Li and Xinwen Fu},
+  title     = {The Onion Name System},
+  journal   = {PETS},
+  volume    = {2017},
+  number    = {1},
+}
+
+%%%
+% Other
+%%%
+@inproceedings{le,
+  author    = {Josh Aas and
+               Richard Barnes and
+               Benton Case and
+               Zakir Durumeric and
+               Peter Eckersley and
+               Alan Flores{-}L{\'{o}}pez and
+               J. Alex Halderman and
+               Jacob Hoffman{-}Andrews and
+               James Kasten and
+               Eric Rescorla and
+               Seth D. Schoen and
+               Brad Warren},
+  title     = {{Let's Encrypt}: An Automated Certificate Authority to Encrypt the Entire Web},
+  booktitle = {{CCS}},
+  year      = {2019},
+}
+
+@inproceedings{sok-https,
+  author    = {Jeremy Clark and Paul C. van Oorschot},
+  title     = {{SoK}: {SSL} and {HTTPS:} Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements},
+  booktitle = {{IEEE} {S\&P}},
+  year      = {2013},
+}
+
+@inproceedings{browser-ui,
+  author    = {Emanuel von Zezschwitz and Serena Chen and Emily Stark},
+  title     = {``{It} builds trust with the customers''---Exploring User Perceptions of the Padlock Icon in Browser {UI}},
+  booktitle = {{IEEE} SPW},
+  year      = {2022},
+}
+
+@article{tls-timeline,
+  author    = {Ralph Holz and
+               Jens Hiller and
+               Johanna Amann and
+               Abbas Razaghpanah and
+               Thomas Jost and
+               Narseo Vallina{-}Rodriguez and
+               Oliver Hohlfeld},
+  title     = {Tracking the deployment of {TLS} 1.3 on the web: a story of experimentation and centralization},
+  journal   = {CCR},
+  volume    = {50},
+  number    = {3},
+  year      = {2020},
+}
+
+@misc{mls,
+  author       = {Nick Sullivan and Sean Turner},
+  title        = {Messaging Layer Security: Secure and Usable End-to-End Encryption},
+  howpublished = {\url{https://www.ietf.org/blog/mls-secure-and-usable-end-to-end-encryption/}, accessed 2023-04-30},
+}
+
+@inproceedings{wireguard,
+  author    = {Jason A. Donenfeld},
+  title     = {WireGuard: Next Generation Kernel Network Tunnel},
+  booktitle = {{NDSS}},
+  year      = {2017},
+}
+
+@techreport{rfc8484,
+  author       = {Paul Hoffman and Patrick McManus},
+  title        = {{DNS} Queries over {HTTPS} ({DoH})},
+  number       = {8484},
+  type         = {RFC},
+  institution  = {IETF},
+  year         = {2018},
+  howpublished = {https://tools.ietf.org/html/rfc8484},
+}
+
+@misc{zerodium,
+  author       = {{Zerodium}},
+  title        = {We pay big bounties},
+  howpublished = {\url{https://zerodium.com/}, accessed 2023-04-30},
+}
+
+@misc{ca/b,
+  author       = {{CA/Browser Forum}},
+  title        = {Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates},
+  howpublished = {\url{https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.7.pdf}, accessed 2023-04-30},
+}
+
+@misc{crt:www.example.com,
+  author       = {{Sectigo Limited}},
+  title        = {crt.sh: certificate search {ID = '8913351873'}},
+  howpublished = {\url{https://crt.sh/?id=8913351873}, accessed 2023-04-30},
+}
+
+@inproceedings{merkle,
+  author    = {Ralph C. Merkle},
+  title     = {A Digital Signature Based on a Conventional Encryption Function},
+  booktitle = {{CRYPTO}},
+  year      = {1987},
+}
+
+@inproceedings{history-trees,
+  author    = {Scott A. Crosby and Dan S. Wallach},
+  title     = {Efficient Data Structures For Tamper-Evident Logging},
+  booktitle = {{USENIX} Security},
+  year      = {2009},
+}
+
+@techreport{black-tulip,
+  author       = {Hans Hoogstraaten},
+  title        = {Black Tulip---Report of the investigation into the {DigiNotar} Certificate Authority breach},
+  institution  = {Fox-IT},
+  year         = {2012},
+}
+
+@inproceedings{bambo-cas,
+  author    = {Henry Birge{-}Lee and
+               Yixin Sun and
+               Anne Edmundson and
+               Jennifer Rexford and
+               Prateek Mittal},
+  title     = {Bamboozling Certificate Authorities with {BGP}},
+  booktitle = {{USENIX Security}},
+  year      = {2018},
+}
+
+@article{rtb,
+  author    = {Jun Wang and
+               Weinan Zhang and
+               Shuai Yuan},
+  title     = {Display Advertising with Real-Time Bidding {(RTB)} and Behavioural
+               Targeting},
+  journal   = {Foundations and Trends in Information Retrieval},
+  year      = {2017}
+}
+
+@techreport{ocsp,
+  author      = {Santesson, Stefan and Myers, Michael and Ankney, Rich and Malpani, Ambarish and Galperin, Slava and Adams, Carlisle},
+  title       = {X.509 {Internet} Public Key Infrastructure Online Certificate Status Protocol---{OCSP}},
+  number      = {6960},
+  type        = {RFC},
+  institution = {IETF},
+  year        = {2013},
+  url         = {https://tools.ietf.org/html/rfc2560},
+}
+
+@misc{trsb,
+  author = {Tor Project},
+  title = {Research Safety Board},
+  howpublished = {\url{https://research.torproject.org/safetyboard/}, accessed 2023-04-30},
+}
diff --git a/summary/src/lwm/.gitignore b/summary/src/lwm/.gitignore
new file mode 100644
index 0000000..8bb88c8
--- /dev/null
+++ b/summary/src/lwm/.gitignore
@@ -0,0 +1,9 @@
+main.pdf
+*.blg
+*.bbl
+*.fls
+*.fdb_latexmk
+*.log
+*.out
+*.aux
+*.swp
diff --git a/summary/src/lwm/img/mt.tex b/summary/src/lwm/img/mt.tex
new file mode 100644
index 0000000..a62b333
--- /dev/null
+++ b/summary/src/lwm/img/mt.tex
@@ -0,0 +1,28 @@
+\begin{tikzpicture}[
+  sibling distance=32pt,
+  -latex,
+  apnode/.style = {
+    draw=black,
+    dashed,
+  },
+  ap/.style = {
+    draw=black,
+    dashed,
+  },
+]
+  \Tree [
+    .$r\gets\hash(h_{ab}\concat h_{cd})$ [
+      .\node[apnode]{$h_{ab}\gets\hash(h_a\concat h_b)$}; [
+        .$h_a\gets\hash(a)$
+      ] [
+        .$h_b\gets\hash(b)$
+      ]
+    ] \edge[ap]; [
+      .$h_{cd}\gets\hash(h_c\concat h_d)$ [
+        .\node[apnode]{$h_c\gets\hash(c)$};
+      ] \edge[ap]; [
+        .$h_d\gets\hash(d)$
+      ]
+    ]
+  ]   
+\end{tikzpicture}
diff --git a/summary/src/lwm/img/overview.tex b/summary/src/lwm/img/overview.tex
new file mode 100644
index 0000000..9f3a9d0
--- /dev/null
+++ b/summary/src/lwm/img/overview.tex
@@ -0,0 +1,75 @@
+\scalebox{0.9}{\begin{tikzpicture}[
+  -latex,
+  rrs/.style = {
+    draw = gray!30,
+    thick,
+    rounded rectangle,
+    fill = white,
+    minimum width = 2cm,
+    minimum height = 0.7cm,
+    font = \fontsize{10}{10}\selectfont,
+    text = white,
+  },
+  ls/.style = {
+    font=\fontsize{9}{8}\selectfont,
+  },
+]
+\draw (0, 1) node[rrs, fill=rgddTeal] (Log) {Log};
+\draw (0, -1) node[rrs, fill=rgddLime] (Subject) {Subject};
+\draw (3.5, 0) node[rrs, fill=rgddPurple] (Endpoint) {Notifier};
+\draw (-3.5, 0) node[rrs, fill=rgddRed] (Monitor) {Monitor};
+
+
+\path [draw, ->, rounded corners]
+  (Log.north) |-
+  ($ (Log.north) + (Log.west) - (Log) + (-0.25, 0.25) $)
+    node[ls, above, pos=0.75]{
+      STH with snapshot extension
+    } |-
+  (Log.west);
+
+\path [draw, ->, rounded corners]
+  (Monitor.south) |-
+  ($ (Monitor.south) + (Monitor.west) - (Monitor) + (-0.25, -0.25) $)
+    node[ls, below, pos=0.75]{
+      verify STH extension
+    } |-
+  (Monitor.west);
+
+\path [draw, ->, rounded corners]
+  (Subject.south) |-
+  ($ (Subject.south) + (Subject.east) - (Subject) + (0.25, -0.25) $)
+    node[ls, below, pos=0.75]{
+      verify notification
+    } |-
+  (Subject.east);
+
+\path [draw, <-, dashed, rounded corners]
+  (Endpoint.north) |-
+  ($ (Endpoint.east) + (Endpoint.north) - (Endpoint) + (0.25, 0.25) $)
+    node[ls, above, pos=0.75]{
+      optional verify
+    } |-
+  (Endpoint.east);
+
+\draw [->]
+  (Log.south east) --
+    node[ls, sloped, anchor=center, above]{%
+      batch, STH
+    }
+  (Endpoint.north west);
+
+\draw [->]
+  (Endpoint.south west) --
+    node[ls, sloped, anchor=center, above]{%
+      notification
+    }
+  (Subject.north east);
+
+\path [draw, ->]
+  (Log.south west) --
+    node[ls, sloped, pos=.59, above]{%
+      batch, STH
+    }
+  (Monitor.north east);
+\end{tikzpicture}}
diff --git a/summary/src/lwm/img/proofcom.pdf b/summary/src/lwm/img/proofcom.pdf
new file mode 100644
index 0000000..473d817
--- /dev/null
+++ b/summary/src/lwm/img/proofcom.pdf
diff --git a/summary/src/lwm/img/proofgen.pdf b/summary/src/lwm/img/proofgen.pdf
new file mode 100644
index 0000000..deb7ca4
--- /dev/null
+++ b/summary/src/lwm/img/proofgen.pdf
diff --git a/summary/src/lwm/img/proofvf.pdf b/summary/src/lwm/img/proofvf.pdf
new file mode 100644
index 0000000..a2db9d1
--- /dev/null
+++ b/summary/src/lwm/img/proofvf.pdf
diff --git a/summary/src/lwm/img/snapshot.pdf b/summary/src/lwm/img/snapshot.pdf
new file mode 100644
index 0000000..df185f6
--- /dev/null
+++ b/summary/src/lwm/img/snapshot.pdf
diff --git a/summary/src/lwm/img/wildcard.tex b/summary/src/lwm/img/wildcard.tex
new file mode 100644
index 0000000..73f4262
--- /dev/null
+++ b/summary/src/lwm/img/wildcard.tex
@@ -0,0 +1,22 @@
+\begin{tikzpicture}[
+  sibling distance=6pt,
+  level distance=100pt,
+  -latex,
+  grow=left,
+]
+  \Tree [
+    .$r\gets\hash(h_{01}\concat h_{23})$ [
+      .$h_{01}\gets\hash(h_0\concat h_1)$ [
+        .$h_0\gets\hash(\mathsf{gro.elpmaxe})$
+      ] [
+        .$h_1\gets\hash(\mathsf{moc.elpmaxe})$
+      ]
+    ] [
+      .$h_{23}\gets\hash(h_2\concat h_3)$ [
+        .$h_2\gets\hash(\mathsf{moc.elpmaxe.bus})$
+      ] [
+        .$h_3\gets\hash(\mathsf{ten.elpmaxe})$
+      ]
+    ]
+  ]   
+\end{tikzpicture}
diff --git a/summary/src/lwm/main.tex b/summary/src/lwm/main.tex
new file mode 100644
index 0000000..e6951b4
--- /dev/null
+++ b/summary/src/lwm/main.tex
@@ -0,0 +1,54 @@
+\begin{kaupaper}[
+    author={%
+      \textbf{Rasmus Dahlberg} and Tobias Pulls
+    },
+    title={%
+      Verifiable Light-Weight Monitoring for Certificate Transparency Logs
+    },
+    reference={%
+      NordSec (2018)
+    },
+    summary={%
+      An often overlooked part of Certificate Transparency is that domain owners
+      are expected to inspect the logs for mis-issued certificates continuously.
+      The cost and required expertise to do so have led to the emergence of
+      third-party monitoring services that notify domain owners of newly issued
+      certificates that they subscribe to.  For example, one may subscribe to
+      email notifications whenever a certificate is issued for
+      \texttt{*.example.com}.  One downside of such third-party monitoring is
+      that these notification services become trusted parties with little or no
+      accountability with regard to omitted certificate notifications.  We show
+      how to add this accountability and tie it to the gossip-audit model
+      employed by the Certificate Transparency ecosystem by proposing
+      verifiable light-weight monitoring.  The idea is for logs to batch
+      appended certificates into an additional data structure that
+      supports \emph{wild-card (non-)membership proofs}.  As a result,
+      third-party monitors can prove cryptographically that they did not omit
+      any certificate notifications selectively.  Our experimental performance
+      evaluation shows that overhead can be tuned to be small for all involved
+      parts.
+    },
+    participation={\vspace{-0.75cm}
+      I had the initial idea and conducted most of the work myself.  Tobias
+      mainly contributed with discussions that lead to the final design.
+    },
+    label={
+      paper:lwm
+    },
+]
+  \maketitle
+  \begin{abstract}
+    \input{src/lwm/src/abstract}
+  \end{abstract}
+  
+  \input{src/lwm/src/introduction}
+  \input{src/lwm/src/background}
+  \input{src/lwm/src/lwm}
+  \input{src/lwm/src/evaluation}
+  \input{src/lwm/src/conclusion} 
+
+  \input{src/lwm/src/acknowledgments}
+  
+  \bibliographystyle{plain}
+  \bibliography{src/lwm/src/references}
+\end{kaupaper}
diff --git a/summary/src/lwm/src/abstract.tex b/summary/src/lwm/src/abstract.tex
new file mode 100644
index 0000000..f5a68b7
--- /dev/null
+++ b/summary/src/lwm/src/abstract.tex
@@ -0,0 +1,21 @@
+\noindent
+Trust in publicly verifiable Certificate Transparency (CT) logs is reduced
+through
+  cryptography,
+  gossip,
+  auditing, and
+  monitoring.
+The role of a monitor is to observe each and every log entry, looking for
+suspicious certificates that interest the entity running the monitor.
+While anyone can run a monitor, it requires
+  continuous operation and
+  copies of the logs to be inspected.
+This has lead to the emergence of monitoring as-a-service:
+  a trusted third-party runs the monitor and provides registered subjects with
+  selective certificate notifications.
+We present a CT/bis extension for verifiable \emph{light-weight monitoring} that
+enables subjects to verify the correctness of such certificate notifications,
+making it easier to distribute and reduce the trust which is otherwise placed in
+these monitors. Our extension
+supports verifiable monitoring of wild-card domains and piggybacks on CT's
+existing gossip-audit security model.
diff --git a/summary/src/lwm/src/acknowledgments.tex b/summary/src/lwm/src/acknowledgments.tex
new file mode 100644
index 0000000..b3e7d56
--- /dev/null
+++ b/summary/src/lwm/src/acknowledgments.tex
@@ -0,0 +1,3 @@
+\section*{Acknowledgments}
+We would like to thank Linus Nordberg for valuable feedback. This research was
+funded by the Swedish Knowledge Foundation as part of the HITS research profile.
diff --git a/summary/src/lwm/src/background.tex b/summary/src/lwm/src/background.tex
new file mode 100644
index 0000000..bac403b
--- /dev/null
+++ b/summary/src/lwm/src/background.tex
@@ -0,0 +1,119 @@
+\section{Background} \label{lwm:sec:background}
+Suppose that a trusted content provider would like to outsource its operation to
+an untrusted third-party. This is often referred to as the three-party setting,
+in which a trusted source maintains an authenticated data structure through a
+responder that answers client queries on the source's behalf~\cite{ads}.
+The data structure is authenticated in the sense that every answer is
+accompanied by a cryptographic proof that can be verified for correctness by
+only trusting the source.
+While there are many settings and flavors of authenticated data
+structures~\cite{history-tree,pad,accumulator}, our scope is narrowed down to CT
+which builds upon Merkle trees.
+
+\subsection{Merkle Trees} \label{lwm:sec:background:mt}
+The seminal work by Merkle~\cite{mt} proposed a \emph{static}  binary tree where
+each leaf stores the hash of a value and every interior node hashes its children
+  (Figure~\ref{lwm:fig:mt}).
+The root hash serves as a succinct snapshot of the tree's structure and content,
+and by revealing a logarithmic number of hashes it can be reconstructed to prove
+whether a value is stored in a leaf. These hashes compose an audit path for
+a value, and it is obtained by taking every sibling hash while traversing the
+tree from the root down towards the leaf being authenticated. An audit path is
+verified by reversing the traversal used during generation, first reconstructing
+the leaf hash and then every interior node recursively
+  (using the provided sibling hashes) 
+until finally reaching the root. Given a collision resistant hash function,
+an audit path proves that a given leaf contains a value iff the reconstructed
+root hash is known to be authentic. For example, the trusted source might sign
+it.
+\begin{figure}
+  \centering
+  \input{src/lwm/img/mt.tex}
+  \caption{%
+    Merkle tree containing four values $a$--$d$. The dashed arrows show the
+    traversal used to generate an audit path for the right-most leaf (dashed
+    nodes).
+  }
+  \label{lwm:fig:mt}
+\end{figure}
+
+While non-membership of a value can be proven by providing the entire data
+structure, this is generally too inefficient since it requires linear space and
+time. A better approach is to structure the tree such that the node which should
+contain a value is known if it exists. This property is often discussed in
+relation to certificate revocation:
+  as opposed to downloading a list of serial numbers that represent the set of
+    revoked certificates,
+  each leaf in a static Merkle tree could (for example) contain an interval
+    $[a, b)$ where $a$ is revoked and the open interval $(a,b)$
+    current~\cite{crt}.
+Given a serial number $x$, an audit path can be generated in logarithmic space
+and time for the leaf where $x \in [a,b)$ to prove (non-)membership. Similar
+constructions that are \emph{dynamic} support updates more
+efficiently~\cite{pad,vds,coniks}.
+
+\subsection{Certificate Transparency} \label{lwm:sec:bac:ct}
+The CA ecosystem involves hundreds of trusted third-parties that issue TLS
+certificates~\cite{ca-ecosystem}. Once in a while \emph{somebody} gets this process
+wrong, and as a result a fraudulent identity-to-key binding may be issued for
+\emph{any} subject~\cite{enisa}.
+It is important to detect such incidents because mis-issued certificates can
+be used to intercept TLS connections. However, detection is hard unless the
+subjects \emph{who can distinguish between anything benign and fraudulent}
+get a concise view of the certificates that are being served to the clients.
+By requiring that every CA-issued certificate must be disclosed in a public
+and append-only log, CT layers on-top of the error-prone CA ecosystem to provide
+such a view:
+  in theory anyone can inspect a log and determine for herself if a certificate
+  is mis-issued~\cite{ct}.
+
+It would be counter-intuitive to `solve' blind trust in CAs by suggesting that
+everybody should trust a log. Therefore, CT is designed such that the log can
+be distrusted based on two components:
+  a dynamic append-only Merkle tree that supports verifiable membership and
+    consistency queries~\cite{history-tree}, as well as
+  a gossip protocol that detects split-views~\cite{sthnp,ietf-gossip}.
+We already introduced the principles of membership proofs in
+Section~\ref{lwm:sec:background:mt}, and consistency proofs are similar in that
+a logarithmic number of hashes are revealed to prove two snapshots consistent.
+In other words, anyone can verify that a certificate is included in the log
+without fully downloading it, and whatever was in the log before still remains
+unmodified. Unlike the three-party setting, gossip is needed because there is no
+trusted source that signs-off the authenticated data structure:
+  consistency and inclusion proofs have limited value if everybody observes
+  different (but valid) versions of the log.
+
+\subsubsection*{Terminology, Policy Parameters, and Status Quo}
+A new STH---recall that this is short for Signed Tree Head---is issued by the
+log at least every Maximum Merge Delay (MMD) and no faster than allowed by an
+STH frequency~\cite{ct/bis}. An MMD is the
+longest time until a certificate must be included in the log after promising to
+include it. This promise is referred to as a Signed Certificate Timestamp (SCT).
+An STH frequency is relative to the MMD, and limits the number of STHs that can
+be issued. These parameters (among others) are defined in a log's policy, and if
+a violation is detected there are non-repudiable proofs of log misbehavior that
+can be presented. For example, show
+  an SCT that is not included after an MMD,
+  too many STHs during the period of an MMD, or
+  two STHs that are part of two inconsistent versions of the log.
+In other words, rather than being a trusted source a log signs statements to be
+held accountable.
+
+Ideally we would have all of these components in place at once: anyone that
+interacts with a log audits it for correctness based on partial information
+  (SCTs, STHs, served certificates, and proofs),
+subjects monitor the logs for newly included certificates to check that they are
+free from mis-issuance (full download), and a gossip protocol detects or deters
+logs from presenting split-views. This is not the case in practice, mainly
+because CT is being deployed incrementally~\cite{sth-push}
+but also because the cost and complexity of self-monitoring is relatively high.
+For example,
+a subject that wants rapid detection of mis-issuance needs continuous operation
+and full downloads of the logs. It appears that the barrier towards self-%
+monitoring have lead to the emergence of monitoring as-a-service, where a
+trusted third-party monitors the logs on a subject's behalf by selectively
+notifying her of relevant certificates, e.g., mail the operator of
+$\mathsf{example.com}$ if $\mathsf{*.example.com}$ certificates are ever found.
+Third-party monitoring is convenient for logs too because it reduces the
+bandwidth required to serve many subjects. However, for CT it is an unintuitive
+concept given that it requires blind trust.
diff --git a/summary/src/lwm/src/conclusion.tex b/summary/src/lwm/src/conclusion.tex
new file mode 100644
index 0000000..e071935
--- /dev/null
+++ b/summary/src/lwm/src/conclusion.tex
@@ -0,0 +1,15 @@
+\section{Conclusion} \label{lwm:sec:conclusion}
+We proposed a backwards-compatible CT/bis extension that enables light-weight
+monitoring (in short LWM). At the cost of a few hundred Kb per day, a subject
+can either self-monitor or subscribe to verifiable certificate notifications for
+a dozen of logs via an untrusted notifier. The security of LWM piggybacks on the
+gossip-audit model of CT, and it relies only on the existence of at least one
+honest monitor that verifies our extension. The cost of a compliant log is
+overhead during the tree head construction, and this overhead is insignificant
+in comparison to a log's STH frequency. A notifier can generate verifiable
+certificate notifications---even for wild-card queries for all domains under a
+top-level domain---in the order of milliseconds on a single core. Given an
+STH frequency of one hour and 288~M LWM subjects, the incurred bandwidth
+overhead is roughly 640~Mbps for proofs. As such, a log could easily be its
+own notifier on a 1~Gbps connection. Further, any willing third-party could
+notify for a dozen of logs on a 10~Gbps connection.
diff --git a/summary/src/lwm/src/evaluation.tex b/summary/src/lwm/src/evaluation.tex
new file mode 100644
index 0000000..d9d508d
--- /dev/null
+++ b/summary/src/lwm/src/evaluation.tex
@@ -0,0 +1,186 @@
+\section{Evaluation} \label{lwm:sec:evaluation}
+First we discuss assumptions and sketch on relevant security properties for LWM.
+Next, we examine performance properties of our open-source proof-of-concept
+implementation experimentally and reason about bandwidth overhead in theory.
+Finally, we present differences and similarities between LWM and related work.
+
+\subsection{Assumptions and Security Notions} \label{lwm:sec:eval:security}
+The primary threat is a computationally bound attacker that attempts to forge or omit a
+certificate notification without being detected.
+We rely on standard cryptographic assumptions, namely an unforgeable digital
+signature scheme and a collision resistant hash function $\hash$ with
+$2\secpar$-bit output for a security parameter~$\secpar$.
+The former means that an LWM snapshot must originate from the (untrusted) log in
+question. While an incorrect snapshot could be created intentionally to hide a
+mis-issued certificate, it would be detected if at least one honest monitor
+exists because our STH extension piggybacks on the gossip-audit model of CT
+(that we assume is secure).\footnote{%
+  Suppose that witness cosigning is used~\cite{cosi}. Then we rely on at least
+  one witness to verify our extension. Or, suppose that STH pollination is
+  used~\cite{ietf-gossip}. Then we rely on the most recent window of STHs to
+  reach a monitor that verifies our extension.
+}
+A subject can further detect missing notifications by checking the STH index for
+monotonic increases and the STH timestamp for freshness. Thus, given secure
+audit paths and correct verification checks as described in
+Section~\ref{lwm:sec:lwm:wildcard}, no certificate notification can be forged or
+omitted.  Our cryptographic assumptions ensure that every leaf is fixed by a
+secure audit path as in CT, i.e., a leaf hash with value $v$ is encoded as
+$\hash(0x00 \concat v$) and an interior hash with children $L,R$ as
+$\hash(0x01 \concat L \concat R)$~\cite{history-tree,ct}. To exclude any
+unnecessary data on the ends of a range, the value $v$ is a subject name
+concatenated with a hashed list of associated certificates in LWM (subject
+names suffice to verify $\Omega$~order).
+
+CT makes no attempt to offer security in the multi-instance setting~\cite{katz}.
+Here, an attacker that targets many different Merkle trees in parallel should
+gain no advantage while trying to forge \emph{any} valid (non-)membership
+proof. By design there will be many different wild-card Merkle trees in LWM, and
+so the (strictly stronger) multi-instance setting is reasonable. We can
+provide full bit-security in this setting by ensuring that no node's pre-image
+is valid across different trees by incorporating a unique tree-wide
+constant $c_t$ in leaf and empty hashes \emph{per batch}, e.g.,
+$c_t \sample \set{0,1}^\secpar$. Melera \emph{et~al.}~\cite{coniks}
+describe this in detail while also ensuring that no node's pre-image is valid
+across different locations within a Merkle tree.
+
+In an ecosystem where CT is being deployed incrementally without gossip, the
+benefit of LWM is that a subject who subscribes for certificate notifications
+can trust the log only (as opposed to \emph{also} trusting the notifier).
+Therefore, today's trust in third-party monitoring services can be reduced
+significantly. A log must also present a split-view or an invalid snapshot to
+deceive a subject with false notifications. As such, subjects accumulate binding
+evidence of log misbehavior that can be audited sometime in the future if
+suspicion towards a log is raised. Long-term the benefit of LWM is that it is
+easier to distribute the trust which is placed in third-party monitors, i.e.,
+anyone who processes a (small in comparison to the entire log) batch of
+certificates can full-audit it without being a notifier.
+
+\subsection{Implementation and Performance} \label{lwm:sec:eval:perf}
+We implemented multi-instance secure LWM in less than 400 lines of
+Go~\cite{artifact}.
+Our wild-card structure uses an existing implementation of a radix tree to find
+leaf indices and data. To minimize proof-generation times, all hashes are
+cached in an in-memory Merkle tree which uses SHA-256. We benchmarked snapshot
+creation, proof generation, and proof verification times on a single core as the
+batch size increases from 1024--689,245~certificates using 
+  Go's built-in benchmarking tool,
+  an Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, and
+  2x8 Gb DDR3 RAM.
+We assumed real subject names from Alexa's top-1M~\cite{alexa}.  and
+average-sized certificates of 1500~bytes~\cite{cert-size}, where a batch of $n$
+subject names refers to the $n$ most popular domains.  Notably 689,245
+certificates is the largest batch observed by us in Google's Icarus log between
+2017-01-25 and 2018-08-05, corresponding to an STH interarrival time of
+27.1~hours. The median (average) batch size and STH interarrival time were 22818
+(23751) certificates and 60.1 (61.6) minutes.  Only two batches were larger than
+132077 certificates. Considering that Icarus is one of the logs that see largest
+loads~\cite{log-growth}, we can make non-optimistic conclusions regarding the
+performance overhead of LWM without inspecting other logs.
+
+Figure~\ref{lwm:fig:snapshot} shows snapshot creation time as a function of batch
+size. Nearby the median ($2^{15}$) it takes 0.39~seconds to create a
+snapshot from scratch, initializing state from an unordered dictionary and
+caching all hashes for the first time. For the largest batch, the snapshot
+creation time is roughly 10 seconds. Arguably this overhead is still
+insignificant for logs, monitors, and notifiers because the associated STH
+interarrival times are orders of magnitude larger.
+\begin{figure}[!t]
+  \centering
+  \includegraphics[width=.9\columnwidth]{src/lwm/img/snapshot.pdf}
+  \caption{%
+    Snapshot creation time as a function of batch size.
+  }
+  \label{lwm:fig:snapshot}
+\end{figure}
+
+\begin{figure}[!t]
+  \centering
+  \includegraphics[width=.9\columnwidth]{src/lwm/img/proofgen.pdf}
+  \caption{%
+    Membership and non-membership proof query time as a function of batch
+    size for a single and no match, respectively.
+  }
+  \label{lwm:fig:proofgen}
+\end{figure}
+
+Figure~\ref{lwm:fig:proofgen} shows proof generation time as a function of batch size
+while querying for the longest wild-card prefix with a single match
+(membership), as well as another wild-card prefix without any match in com's
+top-level domain (non-membership).
+There is little or no difference between the generation time for these types
+of wild-card proofs, and nearby the median it takes
+around 7~$\mu s$. For the largest batch, this increased to $12.5$~$\mu s$.
+A notifier can thus generate 288 million non-membership
+notifications per hour \emph{on a single core}. Verification is also in the
+order of $\mu s$, which should be negligible for a subject
+(see Figure~\ref{lwm:fig:proofvf}).
+
+\begin{figure}[!t]
+  \centering
+  \includegraphics[width=.9\columnwidth]{src/lwm/img/proofvf.pdf}
+  \caption{%
+    Membership and non-membership verification time as a function of batch
+    size for a single and no match, respectively.
+  }
+  \label{lwm:fig:proofvf}
+\end{figure}
+
+To evaluate the cost of generating and verifying a wild-card notification with
+a large number of matches, we queried for com's entire top-level domain
+  (see Figure~\ref{lwm:fig:proofcom}).
+In the largest batch where there are 352,383 matches, the proof
+generation time is still relatively low: 134~ms. This corresponds to 28.9k
+notifications per hour on a single core. The verification time is much larger:
+3.5~seconds. This is expected since verification involves reconstructing the
+root from all the matching leaves, which is at least as costly as creating a
+snapshot of the same size
+  (cf.\ $2^{18}$ in Figure~\ref{lwm:fig:snapshot}).
+While these are relevant performance numbers, anyone who is interested in a
+top-level domain would likely just download the entire batch.
+\begin{figure}[!t]
+  \centering
+  \includegraphics[width=.9\columnwidth]{src/lwm/img/proofcom.pdf}
+  \caption{%
+    Membership query and verification time for $\mathsf{*.com}$.
+  }
+  \label{lwm:fig:proofcom}
+\end{figure}
+
+Finally, the space \emph{overhead} of a verifiable wild-card notification is
+dominated by the two audit paths that enclose the matching subject names. Given
+that an audit path contains at most $\ceil{\log_2 n}$ sibling hashes for a batch
+of size $n$, the median overhead is roughly one Kb per STH, log, and LWM
+subject.  Viewed from the perspective of a self-monitor, this is a significant
+bandwidth improvement:
+  as opposed to downloading the median batch of 32.6~Mb,
+  one Kb and any matching certificate(s) suffice.
+In the case of multiple logs, the bandwidth improvement is even greater. For
+the notifier we already established that it is relatively cheap to generate new
+notifications. Namely, in the single-core case of 288~M notifications per hour
+the bandwidth overhead would be 640~Mbs (i.e., all proofs must be distributed
+before the next STH is issued). A notifier can thus notify for a dozen of logs
+and a significant amount of LWM subjects without running into any CPU or
+bandwidth restrictions. Notably this is under the assumption of a sound STH
+frequency---one hour in our evaluation, as used by Icarus and many other logs.
+
+\subsection{Related Work} \label{lwm:sec:eval:related}
+Earlier work related to transparent certificate and key management often use
+dynamic authenticated dictionaries~\cite{pad,accumulator,vds,aki}.
+CONIKS maps a user's mail address to her public key in a binary Merkle prefix
+tree, and after each update a client self-monitors her own key-binding by
+fetching an exact-match (non-)membership proof~\cite{coniks}. While our work
+is conceptually similar to CONIKS since a subject receives one (non-)membership
+proof per log update, the main difference is that LWM builds a new Merkle tree
+for each update in which wild-card queries are supported. This idea is
+inapplicable for CONIKS because a user is potentially interested in the public
+key of any mail address (hence the ability to query the entire data structure
+on an exact-match).
+CONIKS is similarly inapplicable for self-monitors in CT because a subject cares
+about \emph{wild-card queries} and \emph{new certificates}.
+Without the need for wild-cards, any authenticated dictionary could be used as
+a batch building block to instantiate LWM.
+While a radix tree viewed as a Merkle tree could support efficient wild-card
+proofs~\cite{patricia}, it is more complex than necessary.  Therefore, we built
+upon the work of Kocher~\cite{crt} and Nuckolls~\cite{range-mt} with a twist on
+how to group the data for a new use-case: LWM.
diff --git a/summary/src/lwm/src/introduction.tex b/summary/src/lwm/src/introduction.tex
new file mode 100644
index 0000000..fce2bcf
--- /dev/null
+++ b/summary/src/lwm/src/introduction.tex
@@ -0,0 +1,76 @@
+\section{Introduction}
+Certificate Transparency (CT)~\cite{ct} is an experimental standard that
+enhances the public-key infrastructure by adding transparency for certificates
+that are issued by Certificate Authorities (CAs). The idea is to mandate
+that every certificate must be publicly logged in an append-only tamper-evident
+data structure~\cite{history-tree}, such that anyone can observe what has been
+issued for whom. This means that a subject can determine for herself if anything
+is mis-issued by downloading all certificates; so called \emph{self-monitoring}.
+An alternative monitoring approach is to rely on a trusted third-party that
+\emph{notifies} the subject if relevant certificates are ever found. Given that
+self-monitoring involves set-up, continuous operation, and exhaustive
+communication effort, the concept of subscribing for monitoring
+\emph{as-a-service} is simpler for the subject. This model is already prevalent
+in the wild, and is provided both by CAs and industry vendors---see for example
+SSLMate's Cert Spotter~\cite{certspotter} or Facebook's monitoring
+tool~\cite{fbmon}.  Third-party monitors can also offer related services, such
+as searching for certificates interactively or inspecting other log properties.
+The former is provided by Facebook and Comodo's \texttt{crt.sh}; the latter by
+Graham Edgecombe's CT monitoring tool~\cite{grahmon}.
+
+It would be an unfortunate short-coming if CT did not change the status quo of
+centralized trust by forcing subjects who cannot operate a self-monitor to trust
+certificate notifications that are provided by a third-party monitor. While it
+is true that a subject could subscribe to a large number of monitors to reduce
+this trust, it is overall cumbersome and does not scale well beyond a handful
+of notifying monitors (should they exist). To this end, we suggest a CT/bis
+extension for verifiable Light-Weight Monitoring (LWM) that makes it easier to
+distribute the trust which is otherwise placed in these monitors by decoupling
+the notifier from the full-audit function of inspecting all certificates. Our
+idea is best described in terms of a self-monitor that polls for new updates,
+but as opposed to processing all certificates we can filter on wild-card
+prefixes such as \texttt{*.example.com} in a verifiable manner.
+LWM relies on the ability to define a new Signed Tree Head (STH) extension, and
+thus a CT/bis compliant log is necessary~\cite{ct/bis}. At the time of writing
+CT/bis have yet to be published as an IETF standard. We are not aware of any log
+that deploys a drafted version.
+
+As a brief overview, each batch of newly included certificates are grouped as a
+static Merkle tree in LWM. The resulting snapshot (also know as a fingerprint or
+a root hash) is then incorporated into the corresponding STH as an extension.
+An LWM subject receives one verifiable certificate notification per log update
+from an untrusted \emph{notifier}
+  (who could be the log, a monitor, or anyone else),
+and this notification is based on the smaller static Merkle tree rather than the
+complete log. This is because monitoring as-a-service is mainly about
+identifying newly included certificates. Moreover, we can order each static
+Merkle tree so that verifiable wild-card filtering is possible. For security we
+rely on at least one entity to verify that each snapshot is correct---which is
+a general monitoring function that is independent of the subjects using LWM---as
+well as a gossip protocol that detects split-views~\cite{sthnp}. Since our
+extension is part of an STH, we piggyback on any gossip-like protocol that deals
+with the exchange and/or distribution of (verified)
+STHs~\cite{ctga,ietf-gossip,sth-push,cosi}.  Our contributions are as follows:
+\begin{itemize}
+  \item The design of a backwards-compatible CT/bis extension for light-weight
+    monitoring of wild-card prefixes such as \texttt{*.example.com}
+      (Section~\ref{lwm:sec:lwm}).
+  \item A security sketch showing that an attacker cannot omit a certificate
+    notification without being detected, relying on standard cryptographic
+    assumptions and piggybacking on the proposed gossip-audit models of CT
+      (Section~\ref{lwm:sec:eval:security}).
+  \item An open-source proof-of-concept implementation written in Go, as well
+    as a performance evaluation that considers computation time and bandwidth
+    requirements (Section~\ref{lwm:sec:eval:perf}). In particular we find that the
+    overhead during tree head construction is small in comparison to a sound STH
+    frequency of one hour; a notifier can easily notify 288~M subjects in a
+    verifiable manner for Google's Icarus log on a single core and a 1~Gbps
+    connection; and a subject receives about 24~Kb of proofs per day and log
+    which is verified in negligible time (the order of $\mu$s for the common
+    case of non-membership, and seconds in the extreme case of verifying
+    membership for \emph{an entire top-level domain}).
+\end{itemize}
+
+Background on Merkle trees and CT is provided in Section~\ref{lwm:sec:background}.
+Related work is discussed in Section~\ref{lwm:sec:eval:related}.
+Conclusions are presented in Section~\ref{lwm:sec:conclusion}.
diff --git a/summary/src/lwm/src/lwm.tex b/summary/src/lwm/src/lwm.tex
new file mode 100644
index 0000000..70641a8
--- /dev/null
+++ b/summary/src/lwm/src/lwm.tex
@@ -0,0 +1,148 @@
+\section{Light-Weight Monitoring} \label{lwm:sec:lwm}
+To reduce the trust which is placed in today's third-party monitors,
+the idea of LWM is to lower the barrier towards self-monitoring. As shown in
+Figure~\ref{lwm:fig:idea}, an untrusted notifier provides a subject with
+efficient\footnote{%
+  Efficient iff less than a linear number of log entries are received per log
+	update.
+} certificate notifications that can be cryptographically verified: each batch
+of certificates is represented by an additional Merkle tree that supports
+wild-card (non-)membership queries
+  (described further in Section~\ref{lwm:sec:lwm:wildcard}),
+and the resulting snapshot is signed by the log as part of an STH extension.
+As such, a subject can deal only with those certificates that are relevant,
+relying on wild-card proofs to verify correctness and completeness:
+  said certificates are included and nothing is being omitted.
+Anyone can check that an LWM snapshot is correct by inspecting the corresponding
+batch of certificates. Notably this is \emph{a general monitoring function},
+rather than a \emph{selective notification component} which is verifiable in
+LWM. This decoupling allows anyone to be a notifier, including logs and
+monitors that a subject distrust.
+\begin{figure}
+  \centering
+  \input{src/lwm/img/overview}
+  \caption{%
+    An overview of LWM. In addition to normal operation, a log creates an
+    additional (smaller) Merkle tree that supports wild-card (non-)membership
+    queries. The resulting snapshot is signed as part of an STH extension that
+    can be verified by any monitor that downloads the corresponding batch. A
+    subject receives one verifiable certificate notification per STH from an
+    untrusted notifier.
+  }
+  \label{lwm:fig:idea}
+\end{figure}
+
+\subsection{Authenticated Wild-Card Queries} \label{lwm:sec:lwm:wildcard}
+Thus far we only discussed Merkle trees in terms of verifying whether a single
+value is a (non-)member:
+  membership is proven by presenting an audit path down to the leaf in question,
+    while
+  non-membership requires a lexicographical ordering that allows a verifier
+    to conclude that a value is absent unless provided in a particular location.
+The latter concept naturally extends to \emph{prefix wild-card queries}---such
+as $\mathsf{*.example.com}$ and $\mathsf{*.sub.example.com}$---by finding a
+suitable ordering function $\Omega$ which ensures that related leaves are
+grouped together as a consecutive range. We found that this requirement is
+satisfied by sorting on reversed subject names:
+  suppose that we have a batch of certificates
+    $\mathsf{example.com}$,
+    $\mathsf{example.org}$,
+    $\mathsf{example.net}$, and
+    $\mathsf{sub.example.com}$.
+After applying $\Omega$ we get the static Merkle tree in
+Figure~\ref{lwm:fig:wildcard}. A prefix wild-card proof is constructed by
+finding the relevant range in question, generating an audit path for the
+leaves that are right outside of the range~\cite{range-mt}. Such a proof is
+verified by checking that
+  (i) $\Omega$ indicates that the left (right) end is less (larger) than the
+    queried prefix,
+ (ii) the leaves are ordered as dictated by $\Omega$, and
+(iii) the recomputed root hash is valid.
+
+\begin{figure}
+  \centering
+  \input{src/lwm/img/wildcard}
+  \caption{%
+    Merkle tree where the leaves are ordered on reversed subject names.
+  }
+  \label{lwm:fig:wildcard}
+\end{figure}
+
+The exact details of reconstructing the root hash is a bit tedious because there
+are several corner cases. For example, either or both of the two audit paths may
+be empty depending on batch size (${\leq}1$) and location of the relevant range
+(left/right-most side). Therefore, we omit the details and
+focus on the concept:
+  given two audit paths and a sequence of data items ordered by $\Omega$ that
+    includes the left leaf, matching range, and right leaf, repeatedly
+    reconstruct interior nodes to the largest extent possible and then use the
+    sibling hash which is furthest from the root to continue.
+For example, consider a proof for $\mathsf{*sub.example.com}$ in
+Figure~\ref{lwm:fig:wildcard}: it is composed of
+  (i) the left leaf data and its audit path $h_0,h_{23}$ on index 1,
+ (ii) the right leaf data and its audit path $h_2,h_{01}$ on index 3, and
+(iii) the matching range itself which is a single certificate.
+After verifying $\Omega$~order, recompute the root hash $r'$ and check if
+it matches an authentic root $r$ as follows:
+\begin{enumerate}
+  \item Compute leaf hashes $h_1'$, $h_2'$, and $h_3'$ from the provided data.
+    Next, compute the interior node $h_{23}' \gets \hash(h_2'\concat h_3')$.
+    Because no additional interior node can be computed without a sibling hash,
+    consider $h_0$ in the left audit path.
+  \item Compute the interior node $h_{01}' \gets \hash(h_0\concat h_1')$, then
+    $r' \gets \hash(h_{01}'\concat h_{23}')$.\footnote{%
+      Two audit paths may contain redundancy, but we ignored this favouring
+      simplicity.
+    }
+\end{enumerate}
+
+Given an $\Omega$~ordered list of certificates it is trivial to locate where
+a subject's wild-card matches are:
+  binary search to find the index of an exact match (if any), then up to
+  $t$ matches follow in order.
+This is not the only way to find the right range and matches. For example, a
+radix tree could be used with the main difference being $\bigO{t+\log n}$
+against $\bigO{t+k}$ complexity for a batch of size $n$, a wild-card string of
+length $k$, and $t$ matches. Since the complexity of generating two audit
+paths is $\bigO{\log n}$ for any number of matches, the final space and time
+complexity for a wild-card structure based on an ordered list is
+$\bigO{t+\log n}$.
+
+\subsection{Notifier} \label{lwm:sec:lwm:notifier}
+A notifier must obtain every STH to generate wild-card proofs that can be traced
+back to the log. Albeit error-prone in case of network issues, the simplest
+way to go about this is to poll the log's get-STH endpoint \emph{frequently
+enough}.\footnote{%%
+  It would be better if logs supported verifiable and historical get-STH
+  queries.
+}
+Once an updated is spotted every new certificate is downloaded and the wild-card
+structure is reconstructed. A subject receives her verifiable certificate
+notifications from the notifier via a push (`monitoring as-a-service') or pull
+(`self-monitoring') model. For example, emails could be delivered after every
+update or in daily digests. Another option is to support queries like
+  ``what's new since STH~$x$''.
+
+A subject can verify that a certificate notification is fresh by inspecting the
+STH timestamp. However, it is hard to detect missing certificate notifications
+unless every STH trivially follows from the previous one. While there are
+several methods to achieve this---%
+  for example using indices (Section~\ref{lwm:sec:lwm:instantiation}) or
+  hash chains~\cite{coniks}---%
+the log must always sign a snapshot per STH using an extension.
+
+\subsection{Instantiation Example} \label{lwm:sec:lwm:instantiation}
+Instantiating LWM depends upon the ability to support an STH extension. In the
+latest version of CT, this takes the form of a sorted list of
+key-value pairs where the key is unique and the value an opaque byte
+array~\cite{ct/bis}. We could reserve the keywords \emph{lwm} for snapshots and
+\emph{index} for monotonically increasing counters.\footnote{%
+		Instead of an index to detect missing notifications (STHs), a log could
+    announce STHs as part of a verifiable get-STH endpoint. See the sketch of
+    Nordberg~\cite{nordberg-sketch}.
+} Besides an LWM-compliant log, an untrusted notifier must support pushed or
+pulled certificate notifications that are verifiable by tracking the most recent
+or every wild-card structure. Examples of likely notifiers include
+  logs (who benefit from the reduced bandwidth) and
+  monitors (who could market increased transparency)
+that already process all certificates regardless of LWM.
diff --git a/summary/src/lwm/src/references.bib b/summary/src/lwm/src/references.bib
new file mode 100644
index 0000000..f3fe96a
--- /dev/null
+++ b/summary/src/lwm/src/references.bib
@@ -0,0 +1,255 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%                                 References                                   %
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+@misc{patricia,
+  author = {Ethereum/wiki},
+  title = {Patricia Tree},
+  howpublished = {\url{https://github.com/ethereum/wiki/wiki/Patricia-Tree}, accessed 2018-08-15},
+} 
+
+@misc{log-growth,
+  author = {SSLMate},
+  title = {{Certificate Transparency} Log Growth},
+  howpublished = {\url{https://sslmate.com/labs/ct_growth/}, accessed 2018-08-15},
+} 
+
+@misc{cert-size,
+  author = {Graham Edgecombe},
+  title = {Compressing {X.509} certificates},
+  howpublished = {\url{https://www.grahamedgecombe.com/blog/2016/12/22/compressing-x509-certificates}, accessed 2018-08-15},
+} 
+
+@misc{alexa,
+  author = {Amazon},
+  title = {Alexa {top-1M}},
+  howpublished = {\url{http://s3.amazonaws.com/alexa-static/top-1m.csv.zip}, accessed 2018-08-05},
+} 
+
+@misc{artifact,
+  title = {Paper artifact},
+  howpublished = {\url{https://github.com/rgdd/lwm}},
+  year = {2018},
+} 
+
+@misc{nordberg-sketch,
+  author = {Linus Nordberg},
+  title = {{Re: [Trans] Providing} the history of {STHs} a log has issued (in 6962-bis)},
+  howpublished = {\url{https://mailarchive.ietf.org/arch/msg/trans/JbFiwO90PjcYzXrEgh-Y7bFG5Fw}, accessed 2018-09-16},
+} 
+
+@misc{grahmon,
+  author = {Graham Edgecombe},
+  title = {{Certificate Transparency} Monitor},
+  howpublished = {\url{https://ct.grahamedgecombe.com/}, accessed 2018-09-15.},
+} 
+
+@misc{fbmon,
+  author = {Facebook},
+  title = {{Certificate Transparency} Monitoring},
+  howpublished = {\url{https://developers.facebook.com/tools/ct/}, accessed 2018-09-15},
+} 
+
+@misc{certspotter,
+  author = {SSLMate},
+  title = {Better uptime and security with {Cert Spotter}},
+  howpublished = {\url{https://sslmate.com/certspotter/}, accessed 2018-09-15},
+} 
+
+@article{ctga,
+  author    = {Rasmus Dahlberg and
+               Tobias Pulls and
+               Jonathan Vestin and
+               Toke H{\o}iland{-}J{\o}rgensen and
+               Andreas Kassler},
+  title     = {Aggregation-Based Gossip for {Certificate Transparency}},
+  journal   = {CoRR abs/1806.08817},
+  year      = {2018},
+}
+
+@misc{enisa,
+  author      = {ENISA},
+  title       = {Certificate Authorities---The Weak Link of Internet Security},
+  howpublished = {\url{https://www.enisa.europa.eu/publications/info-notes/certificate-authorities-the-weak-link-of-internet-security}, accessed 2018-09-16},
+}
+
+@inproceedings{sthnp, 
+  author    = {Laurent Chuat and Pawel Szalachowski and Adrian Perrig and Ben Laurie and Eran Messeri}, 
+  title     = {Efficient gossip protocols for verifying the consistency of Certificate logs}, 
+  booktitle = {CNS},
+  year      = {2015}, 
+}
+
+@misc{sth-push,
+  author      = {Ryan Sleevi and Eran Messeri},
+  title       = {{Certificate Transparency} in {Chrome}: Monitoring {CT} Logs consistency},
+  howpublished = {\url{https://docs.google.com/document/d/1FP5J5Sfsg0OR9P4YT0q1dM02iavhi8ix1mZlZe_z-ls/edit?pref=2&pli=1}, accessed 2018-09-16},
+}
+
+@misc{chrome-policy,
+  author        = {Ben Laurie},
+  title         = {Improving the Security of {EV} Certificates},
+  howpublished  = {\url{https://goo.gl/DdEKz1}, accessed 2018-09-16},
+}
+
+@misc{vds,
+  author        = {Adam Eijdenberg and Ben Laurie and Al Cutter},
+  title         = {Verifiable Data Structures},
+  howpublished  = {\url{https://github.com/google/trillian/blob/master/docs/VerifiableDataStructures.pdf}, accessed 2018-09-16},
+}
+
+@inproceedings{cosi,
+  author    = {Ewa Syta and
+               Iulia Tamas and
+               Dylan Visher and
+               David Isaac Wolinsky and
+               Philipp Jovanovic and
+               Linus Gasser and
+               Nicolas Gailly and
+               Ismail Khoffi and
+               Bryan Ford},
+  title     = {Keeping Authorities ``Honest or Bust'' with Decentralized Witness Cosigning},
+  booktitle = {{IEEE S\&P}},
+  year      = {2016},
+  month     = {May},
+}
+
+@inproceedings{ads,
+  author    = {Roberto Tamassia},
+  title     = {Authenticated Data Structures},
+  booktitle = {{ESA}},
+  year      = {2003},
+}
+
+@inproceedings{history-independence,
+ author     = {Moni Naor and Vanessa Teague},
+ title      = {Anti-persistence: History Independent Data Structures},
+ booktitle  = {{STOC}},
+ year       = {2001},
+}
+
+@techreport{ct,
+  author      = {Ben Laurie and Adam Langley and Emilia Kasper},
+  title       = {{Certificate Transparency}},
+  type        = {RFC},
+  number      = {6962},
+  institution = {IETF},
+  year        = {2013},
+}
+
+@techreport{dns-name-ref,
+  author      = {Mockapetris, Paul},
+  title       = {Domain Names---Implementation and specification},
+  type        = {RFC},
+  number      = {1035},
+  institution = {IETF},
+  year        = {1987},
+}
+
+@techreport{ct/bis,
+  author      = {Ben Laurie and Adam Langley and Emilia Kasper and Eran Messeri and Rob Stradling},
+  title       = {{Certificate Transparency} Version 2.0},
+  number      = {draft-ietf-trans-rfc6962-bis-28},
+  type        = {Internet-draft},
+  institution = {IETF},
+  year        = {2018},
+}
+
+@techreport{ietf-gossip,
+  author      = {Linus Nordberg and Daniel Kahn Gillmor and Tom Ritter},
+  title       = {Gossiping in {CT}},
+  number      = {draft-ietf-trans-gossip-05},
+  type        = {Internet-draft},
+  institution = {IETF},
+  year        = {2018},
+}
+
+@inproceedings{balloon,
+  author    = {Tobias Pulls and Roel Peeters},
+  title     = {Balloon: A Forward-Secure Append-Only Persistent Authenticated Data Structure},
+  booktitle = {{ESORICS}},
+  year      = {2015},
+}
+
+@inproceedings{mt,
+  author    = {Ralph C. Merkle},
+  title     = {A Digital Signature Based on a Conventional Encryption Function},
+  booktitle = {{CRYPTO}},
+  year      = {1987},
+}
+
+@inproceedings{coniks,
+  author    = {Marcela S. Melara and
+               Aaron Blankstein and
+               Joseph Bonneau and
+               Edward W. Felten and
+               Michael J. Freedman},
+  title     = {{CONIKS:} {Bringing} Key Transparency to End Users},
+  booktitle = {{USENIX} Security},
+  year      = {2015},
+}
+
+@inproceedings{aki,
+  author    = {Tiffany Hyun{-}Jin Kim and
+               Lin{-}Shung Huang and
+               Adrian Perrig and
+               Collin Jackson and
+               Virgil D. Gligor},
+  title     = {Accountable key infrastructure {(AKI):} {A} proposal for a public-key validation infrastructure},
+  booktitle = {{WWW}},
+  year      = {2013},
+}
+
+@inproceedings{history-tree,
+  author    = {Scott A. Crosby and Dan S. Wallach},
+  title     = {Efficient Data Structures For Tamper-Evident Logging},
+  booktitle = {{USENIX} Security},
+  year      = {2009},
+}
+
+@article{pad,
+  author    = {Scott A. Crosby and Dan S. Wallach},
+  title     = {Authenticated Dictionaries: {Real}-World Costs and Trade-Offs},
+  journal   = {{ACM} {TISSEC}},
+  volume    = {14},
+  number    = {2},
+  year      = {2011},
+}
+
+@inproceedings{katz,
+  author    = {Jonathan Katz},
+  title     = {Analysis of a Proposed Hash-Based Signature Standard},
+  booktitle = {{SSR}},
+  year      = {2016},
+}
+
+@inproceedings{ca-ecosystem,
+  author    = {Zakir Durumeric and
+    James Kasten and
+    Michael Bailey and
+    J. Alex Halderman},
+  title     = {Analysis of the {HTTPS} certificate ecosystem},
+  booktitle = {{IMC}},
+  year      = {2013},
+}
+
+@inproceedings{accumulator,
+  author    = {David Derler and Christian Hanser and Daniel Slamanig},
+  title     = {Revisiting Cryptographic Accumulators, Additional Properties and
+    Relations to Other Primitives},
+  booktitle = {{CT-RSA}},
+  year      = {2015},
+}
+
+@inproceedings{crt,
+  author    = {Paul C. Kocher},
+  title     = {On Certificate Revocation and Validation},
+  booktitle = {{FC}},
+  year      = {1998},
+}
+
+@inproceedings{range-mt,
+  author    = {Glen Nuckolls},
+  title     = {Verified Query Results from Hybrid Authentication Trees},
+  booktitle = {{IFIP} {WG} 11.3 Working Conference on Data and Application Security},
+  year      = {2005},
+}
diff --git a/summary/src/other.tex b/summary/src/other.tex
new file mode 100644
index 0000000..dda33d4
--- /dev/null
+++ b/summary/src/other.tex
@@ -0,0 +1,36 @@
+\section*{List of Other Contributions}
+
+Throughout and before my PhD studies, I also contributed to the following:
+
+\begin{itemize}
+  \item The Sigsum Project.
+    \url{https://www.sigsum.org/} (2020-present).
+
+    Sigsum is a free and open-source software project that brings transparency
+    to signed checksums.  The design is simple and uses a proactive gossip-audit
+    model.  I founded Sigsum with Linus Nordberg and Fredrik Str\"{o}mberg while
+    working at Mullvad VPN as a side-line occupation.
+
+  \item Tobias Pulls and \textbf{Rasmus Dahlberg}.
+    Steady:
+    A Simple End-to-End Secure Logging System.
+    NordSec (2018).
+
+    Tobias was the main driver.  I mostly contributed with design discussions
+    and a security formalization.
+
+  \item \textbf{Rasmus Dahlberg}, Tobias Pulls, and Roel Peeters.
+    Efficient Sparse Merkle Trees:
+    Caching Strategies and Secure (Non-)Membership Proofs.
+    NordSec (2016).
+    
+    This work started with my Bachelor's thesis.  I did most writing with
+    input from Tobias and Roel.  Tobias did our benchmarking experiments.
+
+  \item \textbf{Rasmus Dahlberg} and Tobias Pulls.
+    Standardized Syslog Processing:
+    Revisiting Secure Reliable Data Transfer and Message Compression.
+    Technical Report, Karlstad University (2016).
+
+    I was the main driver.  Tobias contributed with continuous feedback.
+\end{itemize}
diff --git a/summary/src/sammanfattning.tex b/summary/src/sammanfattning.tex
new file mode 100644
index 0000000..dbc68d5
--- /dev/null
+++ b/summary/src/sammanfattning.tex
@@ -0,0 +1,41 @@
+Projektet \emph{Certificate Transparency} är ett ekosystem av loggar, övervakare
+och granskare som håller certifikatutfärdare till svars för utfärdade
+webbcertifikat.  Vi visar hur säkerheten kan höjas i ekosystemet för både
+domäninnehavare och TLS-klienter i nuvarande system samt som del av
+anonymitetsnätverket Tor.  Bland våra större bidrag är
+  förbättrad övervakning av loggarna,
+  ett skvallerprotokoll som integrerats med DNS,
+  ett skvaller- och granskningsprotokoll som utformats specifikt för Tors
+    webbläsare och
+  ett förslag på hur domännamn med adresser i Tor kan bli mer tillgängliga.
+De metoder som använts varierar från säkerhetsbevis till internetmätningar och
+utvärderingar av forskningsprototyper.
+En viktig del av vår utvärdering i Tor är att avgöra hur protokoll som
+används av webbläsare påverkar möjligheten att koppla ihop användare med besökta
+webbplatser.  Detta inkluderar existerande protokoll samt nya tillägg för att
+verifiera om webbplatsers certifikat är transparensloggade.  Våra resultat visar
+att i många fall kan falska positiva utslag filtreras bort vid
+mönsterigenkänning av Tor-användares krypterade trafik
+(eng: \emph{website fingerprinting}).
+Orsaken är att besök till de flesta webbplatser kan uteslutas till följd av hur
+internetprotokoll fungerar: kommunikation är observerbar och involverar ofta
+interaktioner med tredjeparter.  Vissa protokoll har dessutom sidokanaler som
+kan analyseras.  Vi visar exempelvis att Tors DNS-cache kan undersökas med olika
+varianter av tidtagningsattacker.  Dessa attacker är enkla att utföra över
+internet och avslöjar vilka domännamn som slagits upp vid angivna tidpunkter.
+De förbättrade mönsterigenkänningsattackerna mot webbplatser är realistiska och
+hotar därför Tors anonymitet.
+Vår slutsats är att framtida försvar bör utvärderas utifrån att angripare har
+tillgång till ett så kallat webbplatsorakel.
+
+\paragraph{Nyckelord:}
+  Granskning,
+  Certificate Transparency,
+  DNS,
+  Skvaller,
+  Sidokanaler,
+  Tidtagningsattacker,
+  Tor,
+  Tors webbläsare,
+  Mönsterigenkänning,%
+  Webbplatsorakel
diff --git a/summary/src/sauteed/.gitignore b/summary/src/sauteed/.gitignore
new file mode 100644
index 0000000..8bb88c8
--- /dev/null
+++ b/summary/src/sauteed/.gitignore
@@ -0,0 +1,9 @@
+main.pdf
+*.blg
+*.bbl
+*.fls
+*.fdb_latexmk
+*.log
+*.out
+*.aux
+*.swp
diff --git a/summary/src/sauteed/img/onion-location.pdf b/summary/src/sauteed/img/onion-location.pdf
new file mode 100644
index 0000000..21fde5f
--- /dev/null
+++ b/summary/src/sauteed/img/onion-location.pdf
diff --git a/summary/src/sauteed/img/onion-search.pdf b/summary/src/sauteed/img/onion-search.pdf
new file mode 100644
index 0000000..5867270
--- /dev/null
+++ b/summary/src/sauteed/img/onion-search.pdf
diff --git a/summary/src/sauteed/main.tex b/summary/src/sauteed/main.tex
new file mode 100644
index 0000000..e0c7cda
--- /dev/null
+++ b/summary/src/sauteed/main.tex
@@ -0,0 +1,64 @@
+\begin{kaupaper}[
+    author={%
+      \textbf{Rasmus Dahlberg},
+      Paul Syverson,
+      Linus Nordberg, and
+      Matthew Finkel
+    },
+    title={%
+      Sauteed Onions: Transparent Associations from Domain Names to Onion Addresses
+    },
+    reference={%
+      WPES (2022)
+    },
+    summary={%
+      Many prominent websites are also hosted as Tor onion services.  Onion
+      services are identified by their public keys and subject to onion routing,
+      thus offering self-authenticated connections and censorship resistance.
+      However, the non-mnemonic names are a limitation due to being hard to
+      discover and remember.  We explore how certificates with onion addresses
+      may improve the status quo by proposing sauteed onions, \emph{transparent
+      associations from domain names to onion addresses} with the help of
+      Certificate Transparency logs.  The idea is to extend a website's regular
+      certificate with an associated onion address.  This makes it possible to
+      offer certificate-based onion location that is no less targeted than the
+      HTTPS connection facilitating the discovery, as well as name-to-onion
+      search engines that use the append-only logs for verifiable population of
+      their databases.  The achieved goals are
+        consistency of available onion associations,
+        improved third-party discovery of onion associations, and
+        forward censorship-resistance.
+      To be discovered, sites must opt-in by obtaining a sauteed onion
+      certificate.  Our prototypes for certificate-based onion location and
+      third-party search engines use an existing backward-compatible format.  We
+      discuss this trade-off and note that a certificate extension may be used
+      in the future.
+    },
+    participation={\vspace{-.25cm}
+      Paul, Linus, and I had the initial idea of exploring how onion addresses
+      fit into Certificate Transparency.  Paul and I did most of the writing.  I
+      implemented our monitor, Linus our search engine, Matt our web extension.
+    },
+    label={
+      paper:sauteed
+    },
+]
+  \maketitle
+  \begin{abstract}
+    \input{src/sauteed/src/abstract}
+  \end{abstract}
+  
+  \input{src/sauteed/src/intro}
+  \input{src/sauteed/src/preliminaries}
+  \input{src/sauteed/src/sauteed}
+  \input{src/sauteed/src/related}
+  \input{src/sauteed/src/conc}
+  \input{src/sauteed/src/acks}
+  
+  \bibliographystyle{plain}
+  \bibliography{src/sauteed/src/refs}
+
+  \begin{appendices}
+    \input{src/sauteed/src/appendix}
+  \end{appendices}
+\end{kaupaper}
diff --git a/summary/src/sauteed/src/abstract.tex b/summary/src/sauteed/src/abstract.tex
new file mode 100644
index 0000000..8bdcd81
--- /dev/null
+++ b/summary/src/sauteed/src/abstract.tex
@@ -0,0 +1,22 @@
+\noindent
+Onion addresses offer valuable features such as lookup and routing
+security, self-authenticated connections, and censorship resistance.
+Therefore, many websites are also available as onionsites in Tor.  The way
+registered domains and onion addresses are associated is however a weak link.
+We introduce \emph{sauteed onions}, \emph{transparent associations from domain
+names to onion addresses}.
+Our approach relies on TLS certificates to establish onion associations.  It is
+much like today's onion location which relies on Certificate Authorities (CAs)
+due to its HTTPS requirement, but has the added benefit of becoming public for
+everyone to see in Certificate Transparency (CT) logs.  We propose and prototype
+two uses of sauteed onions:
+  certificate-based onion location and
+  search engines that use CT logs as the underlying database.
+The achieved goals are
+  \emph{consistency of available onion associations}, which mitigates attacks
+    where users are partitioned depending on which onion addresses they are
+    given,
+  \emph{forward censorship-resistance} after a TLS site has been configured
+    once, and
+  \emph{improved third-party discovery of onion associations}, which requires
+    less trust while easily scaling to all onionsites that opt-in.
diff --git a/summary/src/sauteed/src/acks.tex b/summary/src/sauteed/src/acks.tex
new file mode 100644
index 0000000..590558a
--- /dev/null
+++ b/summary/src/sauteed/src/acks.tex
@@ -0,0 +1,9 @@
+\section*{Acknowledgments}
+We would like to thank
+  Kushal Das,
+  Daniel Kahn Gillmor,
+  Silvio Rhatto, and
+  Tobias Pulls
+for helpful discussions and comments.
+Rasmus Dahlberg was supported by the Swedish Foundation for Strategic Research.
+Paul Syverson was supported by ONR\@.
diff --git a/summary/src/sauteed/src/appendix.tex b/summary/src/sauteed/src/appendix.tex
new file mode 100644
index 0000000..7850d49
--- /dev/null
+++ b/summary/src/sauteed/src/appendix.tex
@@ -0,0 +1,79 @@
+\section{Onion Association Search Examples} \label{sauteed:app:search}
+We host the search engine described in Section~\ref{sauteed:sec:search-engine} on a
+Debian VM with 1GB RAM, 20GB SSD, and a single vCPU.  It is available at
+\texttt{api.sauteed-onions.o
+rg} as well as
+\texttt{zpadxxmoi42k45iifrzuktwqktihf5didbaec3xo4dhvlw2hj54
+doiqd.onion}.
+Please note that we operate this prototype on a best-effort level until
+December, 2022.
+
+An example for the \texttt{search} endpoint is provided in
+Figure~\ref{sauteed:fig:search}, followed by extracting additional certificate
+information using the \texttt{get} endpoint in Figure~\ref{sauteed:fig:get}.  There are
+many CT-logged certificates for the same onion association because certificates
+are renewed periodically and typically submitted to multiple CT logs.
+
+\begin{sidewaysfigure}[!t]
+    \centering
+    \begin{lstlisting}
+        $ curl -s https://api.sauteed-onions.org/search?in=www.sauteed-onions.org | json_pp
+        [
+           {
+              "identifiers" : [
+                 "2",
+                 "3",
+                 "24",
+                 "25",
+                 "28",
+                 "29",
+                 "37"
+              ],
+              "onion_addr" : "qvrbktnwsztjnbga6yyjbwzsdjw7u5a6vsyzv6hkj75clog4pdvy4cyd.onion",
+              "domain_name" : "www.sauteed-onions.org"
+           }
+        ]
+    \end{lstlisting}
+    \caption{Find onion associations for \texttt{www.sauteed-onions.org}.}
+    \label{sauteed:fig:search}
+\end{sidewaysfigure}
+
+\begin{sidewaysfigure}[!t]
+    \centering
+    \begin{lstlisting}
+	$ curl -s https://api.sauteed-onions.org/get?id=2 | json_pp
+        {
+           "onion_addr" : "qvrbktnwsztjnbga6yyjbwzsdjw7u5a6vsyzv6hkj75clog4pdvy4cyd.onion",
+           "domain_name" : "www.sauteed-onions.org",
+           "log_id" : "b1N2rDHwMRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RM=",
+           "log_index" : 582362461,
+           "cert_path" : "db/logs/Mammoth/582362461.pem"
+        }
+        $ curl -L https://api.sauteed-onions.org/db/logs/Mammoth/582362461.pem | \
+	  openssl x509 -text -noout
+	...
+    \end{lstlisting}
+    \caption{Get further information relating to the certificate with identifier ``2''.}
+    \label{sauteed:fig:get}
+\end{sidewaysfigure}
+
+\section{Configuration Example} \label{sauteed:app:setup}
+
+We used \texttt{certbot} to set up sauteed onions using Let's Encrypt and
+\texttt{apache} on a Debian system.  The difference when
+compared to the usual \texttt{certbot} instructions is that the \texttt{-d} flag
+must be specified to enumerate all SANs as a comma-separated
+list~\cite{certbot}.  The domain name with an associated onion address as a
+subdomain also needs to be reachable via DNS for Let's Encrypt to perform domain
+validation.  Therefore, an appropriate A/AAAA or CNAME record is required.  A
+sanity-check for \texttt{www.sauteed-onions.org} would be to verify that
+	\texttt{dig qvrbktnwsztjnbga6yyjbwzsdjw7u5a6vsyzv6hkj75clog4pdvy4cydonion
+	.www.sauteed-onions.org}
+returns the same IP address as
+	\texttt{dig www.sauteed
+	-onions.org}
+before running
+	\texttt{certbot --apache -d~www.sauteed-onions.
+	org,qvrbktnwsztjnbga6yyjbwzsdjw7u5a6vsyzv6hkj75clog4pdvy4cydo
+	nion.www.sauteed-onions.org}.
+See \texttt{crt.sh} for an example certificate~\cite{sauteed-onion-cert}.
diff --git a/summary/src/sauteed/src/conc.tex b/summary/src/sauteed/src/conc.tex
new file mode 100644
index 0000000..2b26a56
--- /dev/null
+++ b/summary/src/sauteed/src/conc.tex
@@ -0,0 +1,16 @@
+\section{Conclusion} \label{sauteed:sec:conclusion}
+Sauteed onions declare unidirectional associations from domain names to onion
+addresses.  These onion associations are established in CA-issued and CT-logged
+TLS certificates, thereby making them public for everyone to see.  We propose
+two immediate applications:
+	certificate-based onion location and
+	more automated verifiable search.
+Both applications are opt-in for domain owners, and rely on similar assumptions
+as today's onion location.  The added benefit is more transparency, which
+facilitates a higher degree of consistency between found onion associations as
+well as more censorship-resistance for TLS sites after setup.  Configuration of
+sauteed onions requires one more DNS record and a domain-validated certificate
+from any CA (such as Let's Encrypt).  In the future, the additional DNS record
+may be replaced by an X.509v3 extension.  We leave it as a fun exercise to find
+the onion address of a TLS site that is intentionally being censored by us:
+\texttt{blocked.sauteed-onions.org}.
diff --git a/summary/src/sauteed/src/intro.tex b/summary/src/sauteed/src/intro.tex
new file mode 100644
index 0000000..bfad238
--- /dev/null
+++ b/summary/src/sauteed/src/intro.tex
@@ -0,0 +1,45 @@
+\section{Introduction} \label{sauteed:sec:intro}
+Onion addresses are domain names with many useful properties.  For example, an
+onion address is self-authenticated due to encoding its own public key.  It
+also makes integral use of the anonymity network Tor to provide secure and
+private lookups as well as routing~\cite{tor-design}.  A major usability concern
+is that onion addresses are random-looking strings; they are difficult to
+discover, update, and remember~\cite{winter}.  Existing solutions approach these
+limitations in different ways, e.g., ranging from setting onion addresses in
+HTTP headers over HTTPS with so-called \emph{onion
+location}~\cite{onion-location} and bookmarking found results to making use of
+manually curated third-party
+lists~\cite{muffet-onions,onion-service-overview,h-e-securedrop} as well as
+search engines like DuckDuckGo or \texttt{ahmia.fi}~\cite{nurmi,winter}.
+
+Herein we refer to the unidirectional association from a domain name to an onion
+address as an \emph{onion association}.  The overall goal is to facilitate
+transparent discovery of onion associations.  To achieve this we rely on the
+observation that today's onion location can be implemented in certificates
+issued by Certificate Authorities (CAs).  This is not an additional dependency
+because onion location already requires HTTPS~\cite{onion-location}.  The main
+benefit of transitioning from HTTP headers to TLS certificates is that all such
+onion associations become signed and sequenced in tamper-evident Certificate
+Transparency (CT) logs~\cite{ct/a,ct-rfc}, further tightening the relation
+between CAs and onion keys~\cite{cab-ballot144,cab-onion-dv,secdev19} as well as
+public CT logging and Tor~\cite{ctor-popets,muffet-onions}.
+
+Our first contribution is to make onion associations identical for all Tor
+users, and otherwise the possibility of inconsistencies becomes public via CT.
+Consistency of available onion associations mitigates the threat of users
+being partitioned without anyone noticing into subsets according to which
+onion address they received during onion association.
+Our second contribution is to construct a search engine that allows Tor users to
+look up onion associations without having to trust the service provider
+completely.  Other than being helpful to validate onion addresses as
+authentic~\cite{winter}, such discovery can continue to work \emph{after} a TLS
+site becomes censored.
+
+Section~\ref{sauteed:sec:preliminaries} briefly covers CT preliminaries.
+Section~\ref{sauteed:sec:trans} describes \emph{sauteed onions}, an approach that makes
+discovery of onion associations more transparent and censorship-resistant
+compared to today.  Section~\ref{sauteed:sec:related} discusses related work.
+Section~\ref{sauteed:sec:conclusion} concludes the paper.
+Appendix~\ref{sauteed:app:search} contains query examples for our search engine.
+Appendix~\ref{sauteed:app:setup} outlines an example setup.
+All artifacts are online~\cite{sauteed-onion-artifacts}.
diff --git a/summary/src/sauteed/src/preliminaries.tex b/summary/src/sauteed/src/preliminaries.tex
new file mode 100644
index 0000000..f01aeba
--- /dev/null
+++ b/summary/src/sauteed/src/preliminaries.tex
@@ -0,0 +1,25 @@
+\section{Certificate Logging Preliminaries} \label{sauteed:sec:preliminaries}
+CT is a system of public append-only logs that store TLS certificates issued by
+trusted CAs~\cite{ct/a,ct-rfc}.  If web browsers add the criterion that a
+certificate must be logged before accepting it as valid, certificate issuance
+practices by CAs effectively become transparent so that mistakes and malfeasance
+can be detected by anyone that observes the logs.  These observers are
+called \emph{monitors} because they download every certificate from all logs.
+One can self-host a monitor, or use a third-party service like
+\texttt{crt.sh}, or follow other models based on
+subscriptions~\cite{lwm,li}.  To avoid introducing more parties that are trusted
+blindly as in the CA ecosystem, CT stands on a cryptographic foundation that
+permits efficient verification of inclusion (a certificate is in the log) and
+the append-only property (no certificate has been removed or
+modified)~\cite{ct-foundation}.  A party engaging in verification of these
+(logarithmic) proofs is called an \emph{auditor}.
+
+In practice, CT has been rolled-out gradually to not break the
+web~\cite{does-ct-break-the-web}.  One facilitating factor has been the
+introduction of Signed Certificate Timestamps (SCTs).  An SCT is a log's
+\emph{promise} to include a certificate within a certain amount of time;
+typically 24~hours.  This guarantees low-latency certificate issuance so that
+CAs can \emph{embed} SCTs in certificates to keep web servers oblivious to CT.
+Google Chrome and Apple's Safari require SCTs before accepting a certificate as
+valid, and steps towards further SCT verification have been taken
+recently~\cite{ct-in-chrome}.  Tor Browser does not require CT yet~\cite{ctor-popets}.
diff --git a/summary/src/sauteed/src/refs.bib b/summary/src/sauteed/src/refs.bib
new file mode 100644
index 0000000..876fed4
--- /dev/null
+++ b/summary/src/sauteed/src/refs.bib
@@ -0,0 +1,325 @@
+@misc{ahmia.fi,
+  author       = {Ahmia},
+  title        = {Indexing and crawling},
+  howpublished = {\url{https://ahmia.fi/documentation/indexing/}, accessed 2022-08-01},
+}
+
+@misc{sauteed-onion-artifacts,
+  title        = {Paper artifact},
+  howpublished = {\url{https://gitlab.torproject.org/tpo/onion-services/sauteed-onions}}, 
+  year         = {2022}
+}
+
+@inproceedings{le,
+  author    = {Josh Aas and Richard Barnes and Benton Case and Zakir Durumeric and Peter Eckersley and Alan Flores{-}L{\'{o}}pez and J. Alex Halderman and Jacob Hoffman{-}Andrews and James Kasten and Eric Rescorla and Seth D. Schoen and Brad Warren},
+  title     = {{Let's Encrypt}: An Automated Certificate Authority to Encrypt the Entire Web},
+  booktitle = {{CCS}},
+  year      = {2019},
+}
+
+@inproceedings{le-multi-path,
+  author    = {Henry Birge{-}Lee and Liang Wang and Daniel McCarney and Roland Shoemaker and Jennifer Rexford and Prateek Mittal},
+  title     = {Experiences Deploying Multi-Vantage-Point Domain Validation at {Let's Encrypt}},
+  booktitle = {{USENIX} Security},
+  year      = {2021},
+}
+
+@Misc{cab-ballot144,
+  author       = {\relax{{CA}/Browser Forum}},
+  title        = {Ballot 144 -- Validation rules for .onion names},
+  howpublished = {\url{https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/}, accessed 2022-08-01},
+}
+
+@misc{cab-onion-dv,
+  author = {\relax{{CA}/Browser Forum}},
+  title = {Ballot SC27v3: Version 3 Onion Certificates},
+  howpublished = {\url{https://cabforum.org/2020/02/20/ballot-sc27v3-version-3-onion-certificates/}, accessed 2022-08-01},
+}
+
+@inproceedings{chuat-gossip,
+  author    = {Laurent Chuat and Pawel Szalachowski and Adrian Perrig and Ben Laurie and Eran Messeri},
+  title     = {Efficient gossip protocols for verifying the consistency of Certificate logs},
+  booktitle = {{CNS}},
+  year      = {2015},
+}
+
+@inproceedings{lwm,
+  author    = {Rasmus Dahlberg and Tobias Pulls},
+  title     = {Verifiable Light-Weight Monitoring for {Certificate Transparency} Logs},
+  booktitle = {NordSec},
+  year      = {2018},
+}
+
+@inproceedings{smt,
+  author    = {Rasmus Dahlberg and Tobias Pulls and Roel Peeters},
+  title     = {Efficient Sparse {Merkle} Trees - Caching Strategies and Secure (Non-)Membership Proofs},
+  booktitle = {NordSec},
+  year      = {2016},
+}
+
+@article{ctor-popets,
+  author  = {Rasmus Dahlberg and Tobias Pulls and Tom Ritter and Paul Syverson}, 
+  title   = {Privacy-Preserving \& Incrementally-Deployable Support for {Certificate Transparency} in {Tor}}, 
+  journal = {PETS},
+  volume  = {2021},
+  number  = {2},
+}
+
+@misc{digicert-onion,
+  author       = {\relax{DigiCert Inc.}},
+  title        = {Ordering a .onion certificate from {DigiCert}},
+  howpublished = {\url{https://www.digicert.com/blog/ordering-a-onion-certificate-from-digicert}, accessed 2022-08-01},
+}
+
+@inproceedings{tor-design,
+  title     = {Tor: The Second-Generation Onion Router},
+  author    = {Roger Dingledine and Nick Mathewson and Paul Syverson},
+  booktitle = {USENIX Security},
+  year      = {2004},
+}
+
+@inproceedings{ct-foundation,
+  author    = {Benjamin Dowling and Felix G{\"{u}}nther and Udyani Herath and Douglas Stebila},
+  title     = {Secure Logging Schemes and {Certificate Transparency}},
+  booktitle = {{ESORICS}},
+  year      = {2016},
+}
+
+@misc{vds,
+  author       = {Adam Eijdenberg and Ben Laurie and Al Cutter},
+  title        = {Verifiable Data Structures},
+  howpublished = {\url{https://github.com/google/trillian/blob/111e9369ab032e493a2f19f9be6d16c4f78ccca5/docs/papers/VerifiableDataStructures.pdf}, accessed 2022-08-01},
+}
+
+@misc{certbot,
+  key          = {EFF},
+  title        = {Changing a Certificate's Domain},
+  howpublished = {\url{https://eff-certbot.readthedocs.io/en/stable/using.html\#changing-a-certificate-s-domains}, accessed 2022-08-01},
+}
+
+@misc{fink,
+  author       = {Alex Fink},
+  title        = {Mnemonic .onion {URLs}},
+  howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/proposals/194-mnemonic-urls.txt}, accessed 2022-08-01},
+}
+
+@techreport{dangerous-labels,
+  author      = {Daniel Kahn Gillmor},
+  title       = {{Dangerous Labels in DNS and E-mail}},
+  type        = {Internet-Draft},
+  number      = {draft-dkg-intarea-dangerous-labels-01},
+  institution = {IETF},
+  year        = {2022},
+}
+
+@misc{chrome-logs,
+  title        = {{Google LLC.}},
+  key          = {Known Logs},
+  howpublished = {\url{https://github.com/google/certificate-transparency-community-site/blob/master/docs/google/known-logs.md}, accessed 2022-08-01},
+}
+
+@misc{harica-onion,
+  author       = {\relax{Harica}},
+  title        = {{DV} certificates for Onion websites},
+  howpublished = {\url{https://news.harica.gr/article/onion_announcement/}, accessed 2022-08-01},
+}
+
+@misc{kadianakis,
+  author       = {George Kadianakis and Yawning Angel and David Goulet},
+  title        = {A Name System {API} for {Tor} Onion Services},
+  howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txt}, accessed 2022-08-01},
+}
+
+@article{ct/a,
+  author    = {Ben Laurie},
+  title     = {Certificate transparency},
+  journal   = {CACM},
+  volume    = {57},
+  number    = {10},
+  year      = {2014},
+}
+
+@misc{trans-laurie,
+  title        = {{Re: [Trans] Mozilla's} basic take on Binary Transparency},
+  author       = {Ben Laurie},
+  howpublished = {\url{https://mailarchive.ietf.org/arch/msg/trans/1FxzTkn4LVxU6KN2P3YfbVsKpho/}, accessed 2022-08-01},
+}
+
+@techreport{ct-rfc,
+  author      = {Ben Laurie and Adam Langley and Emilia Kasper},
+  title       =	 {{Certificate Transparency}},
+  type        = {RFC},
+  number      = {6962},
+  institution = {IETF},
+  year        = {2013},
+}
+
+@inproceedings{li,
+  author    = {Bingyu Li and Jingqiang Lin and Fengjun Li and Qiongxiao Wang and Qi Li and Jiwu Jing and Congli Wang},
+  title     = {{Certificate Transparency} in the Wild: Exploring the Reliability of Monitors},
+  booktitle = {{CCS}},
+  year      = {2019},
+}
+
+@inproceedings {coniks,
+  author    = {Marcela S. Melara and Aaron Blankstein and Joseph Bonneau and Edward W. Felten and Michael J. Freedman}, 
+  title     = {{CONIKS}: Bringing Key Transparency to End Users},
+  booktitle = {USENIX Security},
+  year      = {2015},
+}
+
+@misc{russia-blocks,
+  author       = {Simon Migliano and Samuel Woodhams},
+  title        = {Websites Blocked in {Russia} Since {Ukraine} Invasion},
+  howpublished = {\url{https://www.top10vpn.com/research/websites-blocked-in-russia/}, accessed 2022-08-01},
+}
+
+@misc{vanity-address,
+  title        = {mkp224o---vanity address generator for ed25519 onion services},
+  howpublished = {\url{https://github.com/cathugger/mkp224o}, accessed 2022-08-01},
+}
+
+@misc{mozilla-bt,
+  author       = {Mozilla},
+  title        = {Security/Binary Transparency},
+  howpublished = {\url{https://wiki.mozilla.org/Security/Binary_Transparency}, accessed 2022-08-01},
+}
+
+@misc{muffet-onions,
+  author       = {Alec Muffett},
+  title        = {Onion {Certificate Transparency} Log},
+  howpublished = {\url{https://github.com/alecmuffett/real-world-onion-sites}, accessed 2022-08-01},
+}
+
+@misc{sooc,
+  author       = {Alec Muffett},
+  title        = {Same Origin Onion Certificates},
+  howpublished = {\url{https://crt.sh/?id=6819596552}, accessed 2022-08-01},
+}
+
+@misc{namecoin,
+  title        = {Namecoin},
+  howpublished = {\url{https://www.namecoin.org/}, accessed 2022-08-01},
+}
+
+@misc{nordberg-tor,
+  author       = {Linus Nordberg},
+  title        = {{Tor} Consensus Transparency},
+  howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/proposals/267-tor-consensus-transparency.txt}, accessed 2022-08-01},
+}
+
+@phdthesis{nurmi,
+  author = {Nurmi, Juha},
+  title  = {Understanding the Usage of Anonymous Onion Services},
+  year   = {2019},
+  school = {Tampere University, Finland},
+}
+
+@Misc{haroi-tor-dev,
+  author       = {nusenu},
+  title        = {{HAROI}: Human Readable Authenticated Relay Operator Identifier},
+  howpublished = {\url{https://lists.torproject.org/pipermail/tor-dev/2021-December/014688.html}, accessed 2022-08-01},
+}
+
+@misc{onion-location,
+  author       = {Tor Project},
+  title        = {Onion-Location},
+  howpublished = {\url{https://community.torproject.org/onion-services/advanced/onion-location/}, accessed 2022-08-01}, 
+}
+
+@misc{onion-service-overview,
+  author       = {Tor Project},
+  title        = {Onion Services},
+  howpublished = {\url{https://community.torproject.org/onion-services/}, accessed 2022-08-01},
+}
+
+@misc{rhatto,
+  author       = {Silvio Rhatto},
+  title        = {Sauteed Week {API} Backend},
+  howpublished = {\url{https://gitlab.torproject.org/rhatto/sauteed-week/-/blob/main/docs/api.md}, accessed 2022-08-01},
+}
+
+@misc{sauteed-onion-cert,
+  title        = {Sauteed Onion Certificate},
+  howpublished = {\url{https://crt.sh/?id=5957691193}, accessed 2022-08-01},
+}
+
+@inproceedings{onion-dns,
+  author    = {Nolen Scaife and Henry Carter and Patrick Traynor},
+  title     = {{OnionDNS}: A seizure-resistant top-level Domain},
+  booktitle = {{CNS}},
+  year      = {2015},
+}
+
+@article{ct-in-chrome,
+  author    = {Emily Stark and Joe DeBlasio and Devon O'Brien and Davide Balzarotti and William Enck and Samuel King and Angelos Stavrou},
+  title     = {{Certificate Transparency} in {Google Chrome}: Past, Present, and Future},
+  journal   = {{IEEE} Secur. Priv.},
+  volume    = {19},
+  number    = {6},
+  year      = {2021},
+}
+
+@inproceedings{does-ct-break-the-web,
+  author    = {Emily Stark and Ryan Sleevi and Rijad Muminovic and Devon O'Brien and Eran Messeri and Adrienne Porter Felt and Brendan McMillion and Parisa Tabriz},
+  title     = {Does {Certificate Transparency} Break the Web? {Measuring} Adoption and Error Rate},
+  booktitle = {{IEEE S\&P}},
+  year      = {2019},
+}
+
+@inproceedings{once-and-future,
+  author    = {Paul Syverson},
+  title     = {The Once and Future Onion},
+  booktitle = {ESORICS},
+  year      = {2017},
+}
+
+@inproceedings{onion-discovery-attacks,
+  author    = {Paul Syverson and Matt Finkel and Saba Eskandarian and Dan Boneh},
+  title     = {Attacks on Onion Discovery and Remedies via Self-Authenticating Traditional Addresses}, 
+  booktitle = {WPES},
+  year      = {2021},
+}
+
+@inproceedings{secdev19,
+  author    = {Paul Syverson and Matt Traudt},
+  title     = {Self-Authenticating Traditional Domain Names},
+  booktitle = {{SecDev}},
+  year      = {2019},
+}
+
+@misc{plex,
+  title        = {How {Plex} is doing {HTTPS} for all its users},
+  author       = {Filippo Valsorda},
+  howpublished = {\url{https://words.filippo.io/how-plex-is-doing-https-for-all-its-users/}, accessed 2022-08-01},
+}
+
+@Misc{h-e-securedrop,
+  author       = {SecureDrop},
+  title        = {Getting an Onion Name for Your {SecureDrop}},
+  howpublished = {\url{https://securedrop.org/faq/getting-onion-name-your-securedrop/}, accessed 2022-08-01},
+}
+
+@article{onio-ns,
+  author    = {Jesse Victors and Ming Li and Xinwen Fu},
+  title     = {The Onion Name System},
+  journal   = {PETS},
+  volume    = {2017},
+  number    = {1},
+}
+
+@inproceedings{winter,
+  author    = {Philipp Winter and Anne Edmundson and Laura M. Roberts and Agnieszka Dutkowska{-}Zuk and Marshini Chetty and Nick Feamster},
+  title     = {How Do {Tor} Users Interact With Onion Services?},
+  booktitle = {{USENIX} Security},
+  year      = {2018},
+}
+
+@techreport{nordberg-gossip,
+  author      = {Linus Nordberg and Daniel Kahn Gillmor and Tom Ritter},
+  title       = {Gossiping in {CT}},
+  type        = {Internet-draft},
+  number      = {draft-ietf-trans-gossip-05},
+  institution = {IETF},
+  year        = {2018},
+}
diff --git a/summary/src/sauteed/src/related.tex b/summary/src/sauteed/src/related.tex
new file mode 100644
index 0000000..d772d0d
--- /dev/null
+++ b/summary/src/sauteed/src/related.tex
@@ -0,0 +1,62 @@
+\section{Related Work} \label{sauteed:sec:related}
+The CA/B forum accepts certificates with \texttt{.onion}
+addresses~\cite{cab-ballot144,cab-onion-dv}.  DigiCert supports extended
+validation of \texttt{.onion} addresses~\cite{digicert-onion}, and HARICA domain
+validation~\cite{harica-onion}.  Muffett proposed same-origin onion certificates
+that permit clients to omit verification of the CA trust chain for
+onionsites~\cite{sooc}.  Sauteed onions help Tor users \emph{discover}
+domain names with associated onion addresses.  Therefore, it is a
+complement to approaches that bring HTTPS to onionsites.
+
+Syverson suggested that traditional domain names and \texttt{.onion} addresses
+can be glued into a single registered domain~\cite{once-and-future}.  Nusenu
+proposed long-term Tor relay identifiers based on domain names to retrieve lists
+of relevant public keys via HTTPS~\cite{haroi-tor-dev}.  Sauteed onions may be
+used for such associations with the benefit of transparency, and it is further a
+\emph{lighter} version of Syverson and Traudt's self-authenticated traditional
+addresses which favors early deployment over properties like bidirectional onion
+associations, guaranteed timeliness of revocation, and addressing all known
+threats~\cite{onion-discovery-attacks,secdev19}.
+
+Winter~\emph{et al.} studied how users engage with onion services~\cite{winter}.
+A gist is that Tor users have a hard time discovering onion addresses and
+verifying them as authentic.  Common discovery mechanisms that are associated
+with human-meaningful identifiers include
+  personal communication,
+  webpage links,
+  onion-location redirects~\cite{onion-location},
+  third-party lists~\cite{onion-service-overview}, and
+  search engines like DuckDuckGo.
+Prior work has also focused on enumerating onion addresses without any
+associated identity, e.g., through CT-logged certificates with \texttt{.onion}
+addresses~\cite{muffet-onions} and crawling~\cite{ahmia.fi,nurmi}.
+Sauteed onions enhance onion location by making the claimed associations
+transparent in CT, and facilitate third-party solutions with less blind trust
+and without assumptions about TLS sites not becoming blocked in the future.
+
+Several ideas were proposed that mitigate or bypass the problem of
+random-looking onion addresses.  Some sites generate vanity addresses that,
+e.g., start with a prefix and have other memorable traits~\cite{vanity-address}.
+Fink sketched out how to map onion addresses to a set of words~\cite{fink}.
+Kadianakis~\emph{et al.} defined a common API to hook into alternative
+naming systems that give onion addresses pet names~\cite{kadianakis}.
+SecureDrop Onion Names is one such example that is, however,
+implemented directly
+in Tor Browser as an HTTPS Everywhere ruleset for selected news sites.  Other
+alternative naming systems include Namecoin~\cite{namecoin} and
+OnioNS~\cite{onio-ns}.  Sauteed onions is also an alternative naming system, but
+one that relies on CAs and CT logs.
+It may be possible to construct sauteed onions via DNSSEC, but then relying on
+the DNS hierarchy without transparency logging.
+Scaife~\emph{et~al.}~\cite{onion-dns} proposed the \texttt{.o} TLD as an
+onionsite with DNSSEC.
+
+Nordberg connected transparency logs and the consensus mechanism that Tor
+uses~\cite{nordberg-tor}.  Dahlberg~\emph{et~al.} proposed CT in Tor for all
+certificate validations~\cite{ctor-popets}.  We only check signatures of
+embedded SCTs in relation to onion location, and our search engine is
+a simple application of CT monitoring.
+There is a large body of orthogonal work that improve CAs and CT.  For example,
+multi-path domain-validation makes it harder to hijack onion
+associations~\cite{le-multi-path}, and deployment of gossip would harden our
+CT log assumptions~\cite{chuat-gossip,nordberg-gossip}.
diff --git a/summary/src/sauteed/src/sauteed.tex b/summary/src/sauteed/src/sauteed.tex
new file mode 100644
index 0000000..06a581c
--- /dev/null
+++ b/summary/src/sauteed/src/sauteed.tex
@@ -0,0 +1,260 @@
+\section{Saut\'{e} Onions Until Discovery is Transparent and Confection is Firm} \label{sauteed:sec:trans}
+
+\subsection{System Goals} \label{sauteed:sec:system-goals}
+Let an onion association be unidirectional from a traditional domain name to an
+onion address.  Three main system goals are as follows:
+
+\begin{description}
+  \item[Privacy-Preserving Onion Associations] Users should discover the same
+    onion associations, and otherwise the possibility of an
+    inconsistency must become public knowledge.
+  \item[Forward Censorship Resistance] Unavailability of a TLS
+    site must not impede discovery of past onion associations.
+  \item[Automated Verifiable Discovery] Onion association search should be
+    possible without requiring blind trust in third-parties.  It must be hard to
+    fabricate non-empty answers, and easy to automate the setup for scalability
+    and robustness.
+\end{description}
+
+For comparison, today's onion location~\cite{onion-location} does not assure a
+user that the same HTTP header is set for them as for everyone else.  Classes of
+users that connect to a domain at different times or via different
+links can be given targeted redirects to distinct onion addresses
+without detection~\cite{onion-discovery-attacks}.  Onion location also
+does not work if a regular site becomes unavailable due to censorship.
+The \emph{search engine approach} is further a frequent ask by Tor
+users~\cite{winter}.  The solutions that exist in practice rely on
+manually curated
+lists~\cite{muffet-onions,onion-service-overview,h-e-securedrop}, notably with
+little or no retroactive accountability.  As specified above, we aim for a
+similar utility but with a setup that can be automated for all onion
+associations and without the ability to easily fabricate non-empty answers
+without trivial detection.  We sketch out how these security properties are
+achieved in Section~\ref{sauteed:sec:security-sketch}.
+
+\subsection{Threat Model and Scope} \label{sauteed:sec:threat-model}
+We consider an attacker that wants to trick a user into visiting a targeted
+onionsite without anyone noticing the possibility of such behavior.  Users are
+assumed to know the right traditional domain name that is easy to remember (such
+as \texttt{torproject.org}), but not its corresponding onion address.  We
+further assume that the attacker either controls a trusted CA sufficiently to
+issue certificates or is able to deceive them sufficiently during certificate
+issuance to obtain a valid certificate
+from that CA\@.  Any misbehavior is however assumed to be detectable in CT.  So,
+the certificate ecosystem is treated as a \emph{building block} that we make no
+attempt to improve.
+
+We permit the attacker to make TLS sites unavailable after setup, but
+we assume it is difficult to censor the CT log ecosystem because it can
+be mirrored by anyone. Also, as part of the Internet authentication
+infrastructure, adversaries may have equities conflicts in blocking CT logs,
+and if concerned at all about appearance would have a
+harder time justifying such a block versus, e.g., a political,
+journalism, or social media site.
+Similar to CT, we do not attempt to solve certificate revocation and
+especially not in relation to certificates that are connected to
+discovery of onion associations.  This is consistent with Tor Browser's existing
+model for revocation with onion location, which similarly depends on the
+certificate for the redirecting domain. There is no formal counterpart to revoke
+a result in a search engine, but we outline future work related to this.
+
+Our threat model includes countries that block direct access to HTTPS
+sites~\cite{russia-blocks}.
+This is arguably a capable attacker, as no country is currently known to
+completely block indirect access via the Tor network (though in some places
+Tor bridges and/or obfuscated transport is needed).  Our threat model also
+considers the plethora of blindly trusted parties that help users discover onion
+addresses with little or no retroactive
+accountability~\cite{ahmia.fi,muffet-onions,onion-service-overview,h-e-securedrop}.
+In other words, it is in-scope to pave the path towards more accountability.
+
+\subsection{Description of Sauteed Onions} \label{sauteed:sec:sauteed-onions}
+An observation that inspired work on sauteed onions is that onion
+location requires HTTPS~\cite{onion-location}.  This means that
+discovery of onion associations \emph{already} relies on the CA ecosystem.  By
+incorporating the use of CT, it is possible to add accountability to CAs and
+other parties that help with onion address discovery while also raising the bar
+for censoring sites and reducing anonymity.  The name sauteed onions is a cooking pun;
+the association of an onion address with a domain name becomes transparent for
+everyone to see in CT logs.
+
+For background, a CA-issued certificate can contain both a traditional domain
+name and a \texttt{.onion address}~\cite{cab-ballot144,cab-onion-dv}.  This can
+be viewed as a mutual association because the issuing CA must verify the
+traditional domain name \emph{and} the specified onion address.  An immediate
+problem is that this would be ambiguous if there are multiple domain names;
+which one (if any) should be associated with an onion address with such
+certificate coalescence?  A more appropriate path forward would therefore be to
+define an X.509v3 extension for sauteed onions which clearly \emph{declares that
+a domain-validated name wants to be associated with an onion address}.
+
+We describe two uses of sauteed onions that achieve our goals; first assuming it
+is easy to get CA-issued certificates that contain associated onion addresses
+for domain-validated names, and then a short-term roll-out approach that
+could make it a reality now.  A sauteed onion is simply a CT-logged certificate
+that claims \texttt{example.com} wants to be associated with
+\texttt{<addr>.onion} but not necessarily the other way around, i.e., a
+unidirectional association.
+
+\subsubsection{Onion Location} \label{sauteed:sec:onion-location}
+Figure~\ref{sauteed:fig:onion-location} illustrates onion location that uses
+certificates.  A user establishes a TLS connection to a site as usual.  Upon
+encountering a certificate that is CT-logged with an associated onion address
+for the visited site \texttt{example.com}, an onion-location prompt becomes
+available in Tor Browser or the onion site is visited automatically.  This is the same type
+of redirect behavior as today's onion location~\cite{onion-location}, except
+that the possibility of such a redirect is disclosed in public CT logs.
+Attempts at targeted redirects would thus be visible to site owners and
+independent third-parties.  A redirect to someone else's onion address would
+also be visible to the respective site owners.  Notably the ability to detect
+inappropriate redirects acts as a deterrence while also being the first step
+towards remediation, e.g., if users bookmarked onion addresses~\cite{winter}
+to achieve trust on first use or to avoid visiting a regular site \emph{and} an
+onionsite in a way that might reduce a user's anonymity set.
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=.6\columnwidth]{src/sauteed/img/onion-location}
+	\caption{Onion location based on a CT-logged certificate.}
+	\label{sauteed:fig:onion-location}
+\end{figure}
+
+A key observation is that onion location has always been a feature
+facilitated by TLS.  By implementing it in certificates rather than HTTP
+headers that are delivered via HTTPS connections, TLS applications that are ``not
+web'' can use it too without rolling their own mechanisms.  The addition of
+requiring CT to follow onion-location redirects is also an improvement compared
+to today, although one that could be achieved with an HTTP-based approach as
+well (or more ambitiously, for all Tor Browser certificate
+validations~\cite{ctor-popets}).
+
+We prototyped the above in a web extension that is free and open
+source~\cite{sauteed-onion-artifacts}.  The criterion for CT logging is at least
+one embedded SCT from a log in the policy used by Google
+Chrome~\cite{chrome-logs}.  If an onion-location redirect is followed, the
+path of the current webpage is preserved, similar to a typical configuration of
+today's HTTP-based onion location header that instead lists a complete
+URL~\cite{onion-location}.
+
+\subsubsection{Search Engine} \label{sauteed:sec:search-engine}
+A significant challenge for third-parties that help users discover TLS sites
+that are available as onion services is to gain confidence in the underlying
+dataset at scale.  For example, SecureDrop onion names are scoped to news
+sites~\cite{h-e-securedrop}; the list by Muffett is scoped as ``no sites for tech
+with less than (arbitrary) 10,000 users''~\cite{muffet-onions}; and
+\texttt{ahmia.fi} does not even attempt to give onion addresses human-meaningful
+names~\cite{nurmi}.  To make matters worse, solutions based on manually curated
+lists and third-party search are currently implemented with little or no
+accountability.
+
+Figure~\ref{sauteed:fig:search-engine} shows what our approach brings to the table.
+All CT logs can be monitored by a third-party to discover sauteed onions.
+A search API can then be presented to users for the resulting dataset, similar
+to existing monitoring services but scoped specifically for discovery of onion
+associations.  The utility of such a search API is:
+``\emph{what onion addresses are available for \texttt{www.example.com}}''.
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=.6\columnwidth]{src/sauteed/img/onion-search}
+	\caption{Verifiable domain name to onion address search.}
+	\label{sauteed:fig:search-engine}
+\end{figure}
+
+The expected behavior of the search API is that an answer can not be fabricated
+without controlling a CA or hijacking certificate issuance, and any CA
+malfeasance should further be caught by CT\@.  This
+means that no party can fabricate inappropriate answers without detection.
+This is a major improvement compared to the alternative of no verifiability at
+all, although one that in and of itself does not prevent \emph{false negatives}.
+In other words, available answers could trivially be omitted.  This is a
+limitation with the authenticated data structure in CT that can be fixed; see
+security sketch in Section~\ref{sauteed:sec:security-sketch} for an intuition of how to
+work around it.
+
+We specified an HTTP REST API that facilitates search using a domain name; the
+API also makes available additional information like the actual certificate and
+its exact index in a CT log.  In total there are two endpoints: \texttt{search}
+(list of matches with identifiers to more info) and \texttt{get} (more info).  The
+complete API specification is available online together with our implementation,
+which is free and open source~\cite{sauteed-onion-artifacts}.  An independent
+implementation from Tor's hack week is also available by Rhatto~\cite{rhatto}.
+Our prototype runs against all CT logs in Google Chrome for certificates
+logged after July 16, 2022.  A few query examples are available in
+Appendix~\ref{sauteed:app:search}.
+
+\subsubsection{Certificate Format} \label{sauteed:sec:cert-format}
+Until now we assumed that a sauteed onion is easily set up, e.g., using an
+X.509v3 extension.  The bad news is that such an extension does not exist, and
+it would likely be a long journey to standardize and see deployment by CAs.
+Therefore, our prototypes rely on a backwards-compatible approach that encodes
+onion addresses as subdomains~\cite{once-and-future}.  To declare that
+\texttt{example.com} wants to be associated with \texttt{<addr>.onion}, one can
+request a domain-validated certificate that contains both \texttt{example.com}
+and \texttt{<addr>onion.example.com}~\cite{secdev19}.  The inclusion of
+\texttt{example.com} ensures that such a setup does not result in a dangerous
+label~\cite{dangerous-labels}.  The \emph{hack to encode an onion address as a
+subdomain} makes it part of the certificate without requiring changes to CAs.
+Appendix~\ref{sauteed:app:setup} details the necessary setup-steps further.  The gist
+is the addition of a subdomain DNS record and using the \texttt{-d} option in
+\texttt{certbot}~\cite{certbot}.
+
+Although the subdomain approach is easy to deploy right now, it is by
+no means a perfect solution.  An X.509v3 extension would not require
+the configuration of an
+additional DNS record.  In other words, the unidirectional sauteed onions
+property works just as well if the subdomain is not domain-validated.  The
+important part is that the CA validates \texttt{example.com}, and that the
+associated onion address can be declared somewhere in the issued certificate
+without an ambiguous intent.
+Another imperfection that goes hand-in-hand with backwards-compatibility is that
+CAs would have to \emph{opt-out} from sauteed onions, unlike site owners
+that instead have to \emph{opt-in}.
+
+To avoid recommending a pattern that is discouraged by CAs, the Tor Project
+should at least have a dialog with Let's Encrypt which issues the most
+certificates~\cite{le}.  Somewhat similar subdomain hacks related to CAs exist,
+but then with explicit negotiations~\cite{plex}.
+Subdomain hacks without a relation to CAs and TLS were discouraged in the
+past~\cite{trans-laurie}.  We argue that sauteed onions is related because
+CA-validated names are at the heart of our approach.  For example, this is
+unlike Mozilla's binary transparency idea that just wanted to reuse a public
+log~\cite{mozilla-bt}.  Sauteed onions also do not result in more issued
+certificates; it is just the number of domain-validated names that increase by
+one for TLS sites that do the setup.
+
+\subsubsection{Security Sketch} \label{sauteed:sec:security-sketch}
+Our threat model disallows the attacker to tamper with CT and to make the log
+ecosystem unavailable.  Onion location as described in
+Section~\ref{sauteed:sec:onion-location} therefore ensures that a redirect becomes
+public, achieving detectability as defined in our privacy-preserving onion
+association goal.  The search engine in Section~\ref{sauteed:sec:search-engine}
+trivially achieves the same goal because onion associations are \emph{found}
+via CT.  Blocking a TLS site is additionally \emph{too late} if an association
+is already in a CT log, thus achieving forward censorship resistance.
+Our search engine approach further makes it hard to forge non-answers without
+detection because it requires control of a CA and defeating the tamper-evidence
+of CT logs.  While it is possible to omit available answers, this can be
+mitigated by having multiple search APIs, domains that check the integrity of
+their own onion associations similar to the proposed verification pattern in
+CONIKS~\cite{coniks}, or to represent the sauteed onion dataset as a sparse
+Merkle tree to get a verifiable log-backed map that additionally supports
+efficient non-membership proofs that CT lacks~\cite{smt,vds}.
+
+\subsection{Future Work}
+It would be valuable to implement proofs of no omissions as well as native
+lookups in a web extension or Tor Browser to verify everything before showing
+the user a result (certificates, proofs of logging, etc).  The entire or
+selected parts of the sauteed onion dataset may further be delivered to Tor
+Browser similar to SecureDrop onion names~\cite{h-e-securedrop}.  The difference
+would be that the list is automated using a selection criteria from CT logs
+rather than doing it manually on a case-by-case basis.  A major benefit is that
+the sauteed onion dataset can then be queried locally, completely avoiding
+third-party queries and visits to the regular site.  Another approach to explore
+is potential integration of the sauteed onion dataset into Tor's DHT: a
+cryptographic source of truth for available onion associations is likely a
+helpful starting point so that there is \emph{something to distribute}.  It
+would also be interesting to consider other search-engine policies than
+\emph{show everything} as in our work, e.g., only first association or last
+association.  (These policies can be verified with \emph{full
+audits}~\cite{vds}.)
diff --git a/summary/src/tlwo/.gitignore b/summary/src/tlwo/.gitignore
new file mode 100644
index 0000000..8bb88c8
--- /dev/null
+++ b/summary/src/tlwo/.gitignore
@@ -0,0 +1,9 @@
+main.pdf
+*.blg
+*.bbl
+*.fls
+*.fdb_latexmk
+*.log
+*.out
+*.aux
+*.swp
diff --git a/summary/src/tlwo/img/.gitkeep b/summary/src/tlwo/img/.gitkeep
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/summary/src/tlwo/img/.gitkeep
@@ -0,0 +1 @@
+
diff --git a/summary/src/tlwo/img/attack.pdf b/summary/src/tlwo/img/attack.pdf
new file mode 100644
index 0000000..c99c22c
--- /dev/null
+++ b/summary/src/tlwo/img/attack.pdf
diff --git a/summary/src/tlwo/img/cached.pdf b/summary/src/tlwo/img/cached.pdf
new file mode 100644
index 0000000..c0a4524
--- /dev/null
+++ b/summary/src/tlwo/img/cached.pdf
diff --git a/summary/src/tlwo/img/plot_cache_entries-permissive.pdf b/summary/src/tlwo/img/plot_cache_entries-permissive.pdf
new file mode 100644
index 0000000..2016a3f
--- /dev/null
+++ b/summary/src/tlwo/img/plot_cache_entries-permissive.pdf
diff --git a/summary/src/tlwo/img/plot_cache_entries-web.pdf b/summary/src/tlwo/img/plot_cache_entries-web.pdf
new file mode 100644
index 0000000..1373ed0
--- /dev/null
+++ b/summary/src/tlwo/img/plot_cache_entries-web.pdf
diff --git a/summary/src/tlwo/img/plot_cache_hits-permissive.pdf b/summary/src/tlwo/img/plot_cache_hits-permissive.pdf
new file mode 100644
index 0000000..6a92fe9
--- /dev/null
+++ b/summary/src/tlwo/img/plot_cache_hits-permissive.pdf
diff --git a/summary/src/tlwo/img/plot_cache_hits-web.pdf b/summary/src/tlwo/img/plot_cache_hits-web.pdf
new file mode 100644
index 0000000..f56588b
--- /dev/null
+++ b/summary/src/tlwo/img/plot_cache_hits-web.pdf
diff --git a/summary/src/tlwo/img/plot_lookups-permissive.pdf b/summary/src/tlwo/img/plot_lookups-permissive.pdf
new file mode 100644
index 0000000..172046d
--- /dev/null
+++ b/summary/src/tlwo/img/plot_lookups-permissive.pdf
diff --git a/summary/src/tlwo/img/plot_lookups-web.pdf b/summary/src/tlwo/img/plot_lookups-web.pdf
new file mode 100644
index 0000000..8936b14
--- /dev/null
+++ b/summary/src/tlwo/img/plot_lookups-web.pdf
diff --git a/summary/src/tlwo/img/plot_popularity_match-permissive.pdf b/summary/src/tlwo/img/plot_popularity_match-permissive.pdf
new file mode 100644
index 0000000..ccd2d4c
--- /dev/null
+++ b/summary/src/tlwo/img/plot_popularity_match-permissive.pdf
diff --git a/summary/src/tlwo/img/plot_popularity_match-web.pdf b/summary/src/tlwo/img/plot_popularity_match-web.pdf
new file mode 100644
index 0000000..fc49a4b
--- /dev/null
+++ b/summary/src/tlwo/img/plot_popularity_match-web.pdf
diff --git a/summary/src/tlwo/img/plot_preload_entries-permissive.pdf b/summary/src/tlwo/img/plot_preload_entries-permissive.pdf
new file mode 100644
index 0000000..a08e43a
--- /dev/null
+++ b/summary/src/tlwo/img/plot_preload_entries-permissive.pdf
diff --git a/summary/src/tlwo/img/plot_preload_entries-web.pdf b/summary/src/tlwo/img/plot_preload_entries-web.pdf
new file mode 100644
index 0000000..e3f3ebf
--- /dev/null
+++ b/summary/src/tlwo/img/plot_preload_entries-web.pdf
diff --git a/summary/src/tlwo/img/plot_preload_hits-permissive.pdf b/summary/src/tlwo/img/plot_preload_hits-permissive.pdf
new file mode 100644
index 0000000..1f6cacc
--- /dev/null
+++ b/summary/src/tlwo/img/plot_preload_hits-permissive.pdf
diff --git a/summary/src/tlwo/img/plot_preload_hits-web.pdf b/summary/src/tlwo/img/plot_preload_hits-web.pdf
new file mode 100644
index 0000000..ce38004
--- /dev/null
+++ b/summary/src/tlwo/img/plot_preload_hits-web.pdf
diff --git a/summary/src/tlwo/img/plot_preload_lists-permissive.pdf b/summary/src/tlwo/img/plot_preload_lists-permissive.pdf
new file mode 100644
index 0000000..9c79a77
--- /dev/null
+++ b/summary/src/tlwo/img/plot_preload_lists-permissive.pdf
diff --git a/summary/src/tlwo/img/plot_preload_lists-web.pdf b/summary/src/tlwo/img/plot_preload_lists-web.pdf
new file mode 100644
index 0000000..a864f65
--- /dev/null
+++ b/summary/src/tlwo/img/plot_preload_lists-web.pdf
diff --git a/summary/src/tlwo/img/preload.pdf b/summary/src/tlwo/img/preload.pdf
new file mode 100644
index 0000000..9f06a14
--- /dev/null
+++ b/summary/src/tlwo/img/preload.pdf
diff --git a/summary/src/tlwo/img/preload.svg b/summary/src/tlwo/img/preload.svg
new file mode 100644
index 0000000..e507b66
--- /dev/null
+++ b/summary/src/tlwo/img/preload.svg
@@ -0,0 +1,1009 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   width="284.57263mm"
+   height="251.33842mm"
+   viewBox="0 0 284.57263 251.33843"
+   version="1.1"
+   id="svg5"
+   inkscape:version="1.1.2 (0a00cf5339, 2022-02-04)"
+   sodipodi:docname="preload.svg"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:xlink="http://www.w3.org/1999/xlink"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg">
+  <sodipodi:namedview
+     id="namedview7"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageshadow="2"
+     inkscape:pageopacity="0.0"
+     inkscape:pagecheckerboard="0"
+     inkscape:document-units="mm"
+     showgrid="false"
+     inkscape:zoom="0.58081186"
+     inkscape:cx="445.06667"
+     inkscape:cy="513.93579"
+     inkscape:window-width="1870"
+     inkscape:window-height="1000"
+     inkscape:window-x="20"
+     inkscape:window-y="50"
+     inkscape:window-maximized="1"
+     inkscape:current-layer="layer1"
+     inkscape:showpageshadow="2"
+     inkscape:deskcolor="#d1d1d1" />
+  <defs
+     id="defs2">
+    <marker
+       style="overflow:visible"
+       id="Arrow1Lstart"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lstart"
+       inkscape:isstock="true">
+      <path
+         transform="matrix(0.8,0,0,0.8,10,0)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path20233" />
+    </marker>
+    <marker
+       style="overflow:visible"
+       id="Arrow1Lend"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend"
+       inkscape:isstock="true">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path20236" />
+    </marker>
+    <marker
+       style="overflow:visible"
+       id="EmptyTriangleOutL"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="EmptyTriangleOutL"
+       inkscape:isstock="true">
+      <path
+         transform="matrix(0.8,0,0,0.8,-4.8,0)"
+         style="fill:context-fill;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path20393" />
+    </marker>
+    <clipPath
+       id="clipPath4258"
+       clipPathUnits="userSpaceOnUse">
+      <path
+         id="path4260"
+         d="M 0,11.34 H 11.34 V 0 H 0 Z" />
+    </clipPath>
+    <clipPath
+       id="clipPath4258-3"
+       clipPathUnits="userSpaceOnUse">
+      <path
+         id="path4260-6"
+         d="M 0,11.34 H 11.34 V 0 H 0 Z" />
+    </clipPath>
+    <clipPath
+       id="clipPath4258-7"
+       clipPathUnits="userSpaceOnUse">
+      <path
+         id="path4260-0"
+         d="M 0,11.34 H 11.34 V 0 H 0 Z" />
+    </clipPath>
+    <marker
+       style="overflow:visible"
+       id="Arrow1Lstart-3"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lstart"
+       inkscape:isstock="true">
+      <path
+         transform="matrix(0.8,0,0,0.8,10,0)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path20233-6" />
+    </marker>
+    <marker
+       style="overflow:visible"
+       id="Arrow1Lend-1"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend"
+       inkscape:isstock="true">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path20236-0" />
+    </marker>
+    <clipPath
+       id="clipPath4258-0"
+       clipPathUnits="userSpaceOnUse">
+      <path
+         id="path4260-61"
+         d="M 0,11.34 H 11.34 V 0 H 0 Z" />
+    </clipPath>
+    <symbol
+       id="AuxillaryOp">
+      <title
+         id="title18961">Auxiliary Operation</title>
+      <desc
+         id="desc18963">Offline operation.</desc>
+      <rect
+         x="9.260417"
+         y="9.260417"
+         width="21.166666"
+         height="21.166666"
+         style="stroke-width:0.529167"
+         id="rect18965" />
+    </symbol>
+    <symbol
+       id="Connector">
+      <title
+         id="title19024">Connector</title>
+      <desc
+         id="desc19026">Exit to or entry from another part of chart.</desc>
+      <circle
+         cx="19.84375"
+         cy="19.84375"
+         r="5.2916665"
+         style="stroke-width:0.529167"
+         id="circle19028" />
+    </symbol>
+    <marker
+       style="overflow:visible"
+       id="Arrow1Lstart-8"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lstart"
+       inkscape:isstock="true">
+      <path
+         transform="matrix(0.8,0,0,0.8,10,0)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path20233-5" />
+    </marker>
+    <marker
+       style="overflow:visible"
+       id="Arrow1Lend-6"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend"
+       inkscape:isstock="true">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path20236-1" />
+    </marker>
+    <filter
+       inkscape:collect="always"
+       style="color-interpolation-filters:sRGB"
+       id="filter350648"
+       x="-0.10917709"
+       y="-0.10917709"
+       width="1.2183542"
+       height="1.2183542">
+      <feGaussianBlur
+         inkscape:collect="always"
+         stdDeviation="0.85263812"
+         id="feGaussianBlur350650" />
+    </filter>
+    <clipPath
+       id="clipPath4258-9"
+       clipPathUnits="userSpaceOnUse">
+      <path
+         id="path4260-7"
+         d="M 0,11.34 H 11.34 V 0 H 0 Z" />
+    </clipPath>
+    <marker
+       style="overflow:visible"
+       id="Arrow1Lend-3"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend"
+       inkscape:isstock="true">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+         d="M 0,0 5,-5 -12.5,0 5,5 Z"
+         id="path20236-6" />
+    </marker>
+  </defs>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-39.016081,-39.231054)">
+    <use
+       xlink:href="#AuxillaryOp"
+       style="fill:#800080;stroke:#59316b;stroke-width:0.0822417;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;filter:url(#filter350648)"
+       id="use132437"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(6.4761141,0,0,4.2447218,50.339004,138.18261)" />
+    <use
+       xlink:href="#AuxillaryOp"
+       style="fill:#ffffff;stroke:#000000"
+       id="use265468"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(1.3391931,0,0,0.9961219,170.10623,195.62004)" />
+    <text
+       xml:space="preserve"
+       style="font-size:7.76111px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="120.89084"
+       y="279.25372"
+       id="text39324-8-9"><tspan
+         sodipodi:role="line"
+         style="font-size:7.76111px;stroke-width:0.264583"
+         x="120.89084"
+         y="279.25372"
+         id="tspan193052"><tspan
+   style="font-weight:bold"
+   id="tspan161473-6">Phase 3</tspan> - periodically resolve</tspan><tspan
+         sodipodi:role="line"
+         style="font-size:7.76111px;stroke-width:0.264583"
+         x="120.89084"
+         y="288.95511"
+         id="tspan191514">all domains in allowlist locally</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:7.76111px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="204.31744"
+       y="151.77661"
+       id="text39324-8"><tspan
+         sodipodi:role="line"
+         style="font-size:7.76111px;stroke-width:0.264583"
+         x="204.31744"
+         y="151.77661"
+         id="tspan123782"><tspan
+   style="font-weight:bold"
+   id="tspan161473">Phase 2</tspan> - compile allowlist</tspan><tspan
+         sodipodi:role="line"
+         style="font-size:7.76111px;stroke-width:0.264583"
+         x="204.31744"
+         y="161.478"
+         id="tspan28648">with unqiue domain names</tspan></text>
+    <g
+       id="g42075"
+       transform="translate(0,-4.7923209)">
+      <image
+         preserveAspectRatio="none"
+         inkscape:svg-dpi="96"
+         width="31.920643"
+         height="41.946896"
+         xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIj8+CjxzdmcKICAgIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5v cmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyIKICAgIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy8yMDAwL3N2ZyIKICAgIHhtbG5zOmNjPSJodHRwOi8vd2ViLnJlc291cmNlLm9yZy9jYy8iCiAg ICB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIKICAgIHhtbG5zOmRj PSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIKICAgIHhtbG5zOnN2Zz0iaHR0cDov L3d3dy53My5vcmcvMjAwMC9zdmciCiAgICB4bWxuczppbmtzY2FwZT0iaHR0cDovL3d3dy5pbmtz Y2FwZS5vcmcvbmFtZXNwYWNlcy9pbmtzY2FwZSIKICAgIHhtbG5zOnNvZGlwb2RpPSJodHRwOi8v c29kaXBvZGkuc291cmNlZm9yZ2UubmV0L0RURC9zb2RpcG9kaS0wLmR0ZCIKICAgIHhtbG5zOm5z MT0iaHR0cDovL3NvemkuYmFpZXJvdWdlLmZyIgogICAgYmFzZVByb2ZpbGU9ImZ1bGwiCiAgICB2 ZXJzaW9uPSIxLjEiCiAgICB2aWV3Qm94PSIwIDAgMzUwIDUwMCIKICA+CiAgPGRlZnMKICAgID4K ICAgIDxwYXRoCiAgICAgICAgaWQ9ImNvZyIKICAgICAgICB0cmFuc2Zvcm09InNjYWxlKC40KSIK ICAgICAgICBmaWxsPSJkYXJrcmVkIgogICAgICAgIGQ9Im0yMTMgMGwtNCAzOS01IDM5LTIwIDkt MjAgOS0zMi0yNi0zMS0yNS0yNyAyNy0yNyAyNyAyNSAzMSAyNSAzMi05IDE5LTkgMTktMzUgNWMt MjAgMy0zNyA1LTQwIDZzLTQgMTItNCAzOXYzN2wzOSA0YzI0IDMgNDAgNiA0MCA4czMgMTIgOCAy MWw4IDE4LTI1IDMwLTI1IDMxIDI3IDI3IDI3IDI3IDMwLTIzIDMwLTI0IDE4IDljMTAgNSAyMCAx MCAyMiAxMCAxIDEgNCAxNiA3IDM0IDIgMTggNCAzNCA1IDM3czExIDQgMzggNGgzOGw0LTM2YzMt MjggNS0zNyAxMC0zOCAzLTEgMTMtNSAyMy0xMGwxNy04IDI5IDI0IDMwIDIzIDI2LTI3YzIwLTIw IDI2LTI4IDI0LTMxcy0xMy0xNi0yMy0yOWwtMjAtMjUgOS0xOGM1LTEwIDgtMjAgOC0yMiAwLTQg OC02IDUyLTExbDIyLTMgMS0zOCAxLTM4LTM4LTRjLTIzLTMtMzgtNi0zOC04cy0zLTEyLTgtMjJs LTktMTkgMjQtMjkgMjQtMzAtMjctMjctMjctMjctMzAgMjQtMzAgMjQtMjEtOS0yMS05LTUtMzct NS0zOC0zOC0xLTM4LTF6bTM3IDE3MGM0NCAwIDgwIDM2IDgwIDgwcy0zNiA4MC04MCA4MC04MC0z Ni04MC04MCAzNi04MCA4MC04MHoiCiAgICAvPgogIDwvZGVmcwogID4KICA8dXNlCiAgICAgIG9w YWNpdHk9Ii4zIgogICAgICB4bGluazpocmVmPSIjY29nIgogIC8+CiAgPHVzZQogICAgICBvcGFj aXR5PSIuNiIKICAgICAgeGxpbms6aHJlZj0iI2NvZyIKICAgICAgdHJhbnNmb3JtPSJ0cmFuc2xh dGUoMTIwLDEyMCkgcm90YXRlKDIyLjUgMTAwLDEwMCkiCiAgLz4KICA8dXNlCiAgICAgIHhsaW5r OmhyZWY9IiNjb2ciCiAgICAgIHRyYW5zZm9ybT0idHJhbnNsYXRlKDAsMjQwKSIKICAvPgogIDxt ZXRhZGF0YQogICAgPgogICAgPHJkZjpSREYKICAgICAgPgogICAgICA8Y2M6V29yawogICAgICAg ID4KICAgICAgICA8ZGM6Zm9ybWF0CiAgICAgICAgICA+aW1hZ2Uvc3ZnK3htbDwvZGM6Zm9ybWF0 CiAgICAgICAgPgogICAgICAgIDxkYzp0eXBlCiAgICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0 cDovL3B1cmwub3JnL2RjL2RjbWl0eXBlL1N0aWxsSW1hZ2UiCiAgICAgICAgLz4KICAgICAgICA8 Y2M6bGljZW5zZQogICAgICAgICAgICByZGY6cmVzb3VyY2U9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1v bnMub3JnL2xpY2Vuc2VzL3B1YmxpY2RvbWFpbi8iCiAgICAgICAgLz4KICAgICAgICA8ZGM6cHVi bGlzaGVyCiAgICAgICAgICA+CiAgICAgICAgICA8Y2M6QWdlbnQKICAgICAgICAgICAgICByZGY6 YWJvdXQ9Imh0dHA6Ly9vcGVuY2xpcGFydC5vcmcvIgogICAgICAgICAgICA+CiAgICAgICAgICAg IDxkYzp0aXRsZQogICAgICAgICAgICAgID5PcGVuY2xpcGFydDwvZGM6dGl0bGUKICAgICAgICAg ICAgPgogICAgICAgICAgPC9jYzpBZ2VudAogICAgICAgICAgPgogICAgICAgIDwvZGM6cHVibGlz aGVyCiAgICAgICAgPgogICAgICAgIDxkYzp0aXRsZQogICAgICAgICAgPlBpbmsgY29nd2hlZWxz PC9kYzp0aXRsZQogICAgICAgID4KICAgICAgICA8ZGM6ZGF0ZQogICAgICAgICAgPjIwMTMtMDkt MTRUMTY6MDA6NDE8L2RjOmRhdGUKICAgICAgICA+CiAgICAgICAgPGRjOmRlc2NyaXB0aW9uCiAg ICAgICAgICA+U29tZSBjb2d3aGVlbHMgZnJvbSBodHRwczovL2NvbW1vbnMud2lraW1lZGlhLm9y Zy93aWtpL0ZpbGU6Q29nLXNjcmlwdGVkLXN2Zy5zdmc8L2RjOmRlc2NyaXB0aW9uCiAgICAgICAg PgogICAgICAgIDxkYzpzb3VyY2UKICAgICAgICAgID5odHRwczovL29wZW5jbGlwYXJ0Lm9yZy9k ZXRhaWwvMTgzNDM2L3BpbmstY29nd2hlZWxzLWJ5LWxpZnRhcm4tMTgzNDM2PC9kYzpzb3VyY2UK ICAgICAgICA+CiAgICAgICAgPGRjOmNyZWF0b3IKICAgICAgICAgID4KICAgICAgICAgIDxjYzpB Z2VudAogICAgICAgICAgICA+CiAgICAgICAgICAgIDxkYzp0aXRsZQogICAgICAgICAgICAgID5s aWZ0YXJuPC9kYzp0aXRsZQogICAgICAgICAgICA+CiAgICAgICAgICA8L2NjOkFnZW50CiAgICAg ICAgICA+CiAgICAgICAgPC9kYzpjcmVhdG9yCiAgICAgICAgPgogICAgICAgIDxkYzpzdWJqZWN0 CiAgICAgICAgICA+CiAgICAgICAgICA8cmRmOkJhZwogICAgICAgICAgICA+CiAgICAgICAgICAg IDxyZGY6bGkKICAgICAgICAgICAgICA+Y29nPC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAg ICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmNvZ3doZWVsPC9yZGY6bGkKICAgICAgICAgICAg PgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmNvZ3doZWVsczwvcmRmOmxpCiAg ICAgICAgICAgID4KICAgICAgICAgICAgPHJkZjpsaQogICAgICAgICAgICAgID5nZWFyPC9yZGY6 bGkKICAgICAgICAgICAgPgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmdlYXJz PC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAg PnBpbms8L3JkZjpsaQogICAgICAgICAgICA+CiAgICAgICAgICAgIDxyZGY6bGkKICAgICAgICAg ICAgICA+cmVkPC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAgICAgPC9yZGY6QmFnCiAgICAg ICAgICA+CiAgICAgICAgPC9kYzpzdWJqZWN0CiAgICAgICAgPgogICAgICA8L2NjOldvcmsKICAg ICAgPgogICAgICA8Y2M6TGljZW5zZQogICAgICAgICAgcmRmOmFib3V0PSJodHRwOi8vY3JlYXRp dmVjb21tb25zLm9yZy9saWNlbnNlcy9wdWJsaWNkb21haW4vIgogICAgICAgID4KICAgICAgICA8 Y2M6cGVybWl0cwogICAgICAgICAgICByZGY6cmVzb3VyY2U9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1v bnMub3JnL25zI1JlcHJvZHVjdGlvbiIKICAgICAgICAvPgogICAgICAgIDxjYzpwZXJtaXRzCiAg ICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjRGlz dHJpYnV0aW9uIgogICAgICAgIC8+CiAgICAgICAgPGNjOnBlcm1pdHMKICAgICAgICAgICAgcmRm OnJlc291cmNlPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9ucyNEZXJpdmF0aXZlV29ya3Mi CiAgICAgICAgLz4KICAgICAgPC9jYzpMaWNlbnNlCiAgICAgID4KICAgIDwvcmRmOlJERgogICAg PgogIDwvbWV0YWRhdGEKICA+Cjwvc3ZnCj4K "
+         id="image746-2"
+         x="212.19563"
+         y="87.908249" />
+      <g
+         id="g42049"
+         transform="translate(-12.160676,6.5898579)">
+        <image
+           preserveAspectRatio="none"
+           inkscape:svg-dpi="96"
+           width="45.069122"
+           height="49.637085"
+           xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjwh LS0gQ3JlYXRlZCB3aXRoIElua3NjYXBlIChodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy8pIC0tPgo8 c3ZnIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5z IyIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczpjYz0iaHR0cDovL2Ny ZWF0aXZlY29tbW9ucy5vcmcvbnMjIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1l bnRzLzEuMS8iIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOmlu a3NjYXBlPSJodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy9uYW1lc3BhY2VzL2lua3NjYXBlIiB4bWxu czpzb2RpcG9kaT0iaHR0cDovL3NvZGlwb2RpLnNvdXJjZWZvcmdlLm5ldC9EVEQvc29kaXBvZGkt MC5kdGQiIHhtbG5zOm5zMT0iaHR0cDovL3NvemkuYmFpZXJvdWdlLmZyIiB4bWxuczp4bGluaz0i aHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgaWQ9InN2ZzM2MDkiIHZpZXdCb3g9IjAgMCAx NzAuMzQgMjI1LjIzIiB2ZXJzaW9uPSIxLjEiIGlua3NjYXBlOnZlcnNpb249IjAuOTEgcjEzNzI1 Ij4KICA8dGl0bGUgaWQ9InRpdGxlMzYzMCI+RG9jdW1lbnQ8L3RpdGxlPgogIDxnIGlkPSJsYXll cjEiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yMTQuODMgLTQyMi42KSI+CiAgICA8ZyBpZD0iZzU1 MDgiIHRyYW5zZm9ybT0ibWF0cml4KC43NTI0OSAwIDAgLjc0MDI4IC0yMDUuMzkgNTI5LjgxKSI+ CiAgICAgIDxwYXRoIGlkPSJyZWN0NTQ5OCIgc3R5bGU9InN0cm9rZTojMDAwMDAwO3N0cm9rZS13 aWR0aDoxMy4zOTg7ZmlsbDpub25lIiBkPSJtNTY1LjEyLTEzOC4xMnYyOTAuODhoMjEyLjc1di0y MjAuMDlsLTEzMi42OS03MC43ODFoLTgwLjA2MnoiLz4KICAgICAgPHBhdGggaWQ9InJlY3Q1NTAw IiBzdHlsZT0iZmlsbDojYzhiN2I3IiBkPSJtNzMzLjUyLTAuMTUyMTEgMzguMDc4LTUyLjQwMy0x MzIuNTUtNzUuMTU5IDg5LjU0OCAxMjEuMjYgNC45MjM0IDYuMzAyNHoiLz4KICAgICAgPHBhdGgg aWQ9InBhdGg1NTAzIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZTojMDAwMDAw O3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS13aWR0aDoxMy4zOTg7ZmlsbDojZmZmZmZmIiBk PSJtNzQ2LjM1LTM4LjY5MiAzMS43Ny0zOC41OTktMTI5LjI1LTU3LjkyNyA5Ny40ODMgOTYuNTI2 eiIvPgogICAgPC9nPgogIDwvZz4KICA8bWV0YWRhdGE+CiAgICA8cmRmOlJERj4KICAgICAgPGNj Oldvcms+CiAgICAgICAgPGRjOmZvcm1hdD5pbWFnZS9zdmcreG1sPC9kYzpmb3JtYXQ+CiAgICAg ICAgPGRjOnR5cGUgcmRmOnJlc291cmNlPSJodHRwOi8vcHVybC5vcmcvZGMvZGNtaXR5cGUvU3Rp bGxJbWFnZSIvPgogICAgICAgIDxjYzpsaWNlbnNlIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0 aXZlY29tbW9ucy5vcmcvbGljZW5zZXMvcHVibGljZG9tYWluLyIvPgogICAgICAgIDxkYzpwdWJs aXNoZXI+CiAgICAgICAgICA8Y2M6QWdlbnQgcmRmOmFib3V0PSJodHRwOi8vb3BlbmNsaXBhcnQu b3JnLyI+CiAgICAgICAgICAgIDxkYzp0aXRsZT5PcGVuY2xpcGFydDwvZGM6dGl0bGU+CiAgICAg ICAgICA8L2NjOkFnZW50PgogICAgICAgIDwvZGM6cHVibGlzaGVyPgogICAgICAgIDxkYzp0aXRs ZT5Eb2N1bWVudDwvZGM6dGl0bGU+CiAgICAgICAgPGRjOmRhdGU+MjAxMi0wNC0wOFQwNjo1MDoz MzwvZGM6ZGF0ZT4KICAgICAgICA8ZGM6ZGVzY3JpcHRpb24+QSBkb2N1bWVudCBpY29uIGZyb20g dGhlIGZhY2lsaXRhdGlvbiBzZXQuPC9kYzpkZXNjcmlwdGlvbj4KICAgICAgICA8ZGM6c291cmNl Pmh0dHBzOi8vb3BlbmNsaXBhcnQub3JnL2RldGFpbC8xNjk0MTYvZG9jdW1lbnQtYnktYml0dGVy anVnPC9kYzpzb3VyY2U+CiAgICAgICAgPGRjOmNyZWF0b3I+CiAgICAgICAgICA8Y2M6QWdlbnQ+ CiAgICAgICAgICAgIDxkYzp0aXRsZT5iaXR0ZXJqdWc8L2RjOnRpdGxlPgogICAgICAgICAgPC9j YzpBZ2VudD4KICAgICAgICA8L2RjOmNyZWF0b3I+CiAgICAgICAgPGRjOnN1YmplY3Q+CiAgICAg ICAgICA8cmRmOkJhZz4KICAgICAgICAgICAgPHJkZjpsaT5Eb2N1bWVudDwvcmRmOmxpPgogICAg ICAgICAgICA8cmRmOmxpPmFic3RyYWN0PC9yZGY6bGk+CiAgICAgICAgICAgIDxyZGY6bGk+Y29y bmVyPC9yZGY6bGk+CiAgICAgICAgICAgIDxyZGY6bGk+Zm9sZDwvcmRmOmxpPgogICAgICAgICAg ICA8cmRmOmxpPnBhcGVyPC9yZGY6bGk+CiAgICAgICAgICA8L3JkZjpCYWc+CiAgICAgICAgPC9k YzpzdWJqZWN0PgogICAgICA8L2NjOldvcms+CiAgICAgIDxjYzpMaWNlbnNlIHJkZjphYm91dD0i aHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbGljZW5zZXMvcHVibGljZG9tYWluLyI+CiAgICAg ICAgPGNjOnBlcm1pdHMgcmRmOnJlc291cmNlPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9u cyNSZXByb2R1Y3Rpb24iLz4KICAgICAgICA8Y2M6cGVybWl0cyByZGY6cmVzb3VyY2U9Imh0dHA6 Ly9jcmVhdGl2ZWNvbW1vbnMub3JnL25zI0Rpc3RyaWJ1dGlvbiIvPgogICAgICAgIDxjYzpwZXJt aXRzIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjRGVyaXZhdGl2 ZVdvcmtzIi8+CiAgICAgIDwvY2M6TGljZW5zZT4KICAgIDwvcmRmOlJERj4KICA8L21ldGFkYXRh Pgo8L3N2Zz4K "
+           id="image844-6"
+           x="258.59555"
+           y="74.910477" />
+        <text
+           xml:space="preserve"
+           style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+           x="269.35754"
+           y="97.615578"
+           id="text47096-4"><tspan
+             sodipodi:role="line"
+             id="tspan47094-3"
+             style="font-size:6.35px;stroke-width:0.264583"
+             x="269.35754"
+             y="97.615578">foo.org</tspan></text>
+        <text
+           xml:space="preserve"
+           style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+           x="263.29333"
+           y="105.99963"
+           id="text47096-2-1"><tspan
+             sodipodi:role="line"
+             id="tspan47094-0-4"
+             style="font-size:6.35px;stroke-width:0.264583"
+             x="263.29333"
+             y="105.99963">cdn.foo.org</tspan></text>
+        <text
+           xml:space="preserve"
+           style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+           x="263.32269"
+           y="114.00768"
+           id="text47096-23-9"><tspan
+             sodipodi:role="line"
+             style="font-size:6.35px;stroke-width:0.264583"
+             x="263.32269"
+             y="114.00768"
+             id="tspan115821">ads.foo.org</tspan></text>
+        <text
+           xml:space="preserve"
+           style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+           x="278.09979"
+           y="117.81873"
+           id="text118919-0"><tspan
+             sodipodi:role="line"
+             style="stroke-width:0.264583"
+             x="278.09979"
+             y="117.81873"
+             id="tspan118921-6">...</tspan></text>
+      </g>
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-size:9.87778px;line-height:1.25;font-family:sans-serif;stroke-width:0.384866"
+       x="150.32043"
+       y="46.735851"
+       id="text141573-3"><tspan
+         sodipodi:role="line"
+         style="font-weight:bold;font-size:9.87778px;stroke-width:0.384866"
+         x="150.32043"
+         y="46.735851"
+         id="tspan141583-5">central party</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:9.87778px;line-height:1.25;font-family:sans-serif;stroke-width:0.384866"
+       x="163.69237"
+       y="172.31128"
+       id="text141573-3-3"><tspan
+         sodipodi:role="line"
+         style="font-weight:bold;font-size:9.87778px;stroke-width:0.384866"
+         x="163.69237"
+         y="172.31128"
+         id="tspan141583-5-5">relay</tspan></text>
+    <use
+       xlink:href="#AuxillaryOp"
+       style="fill:#ffffff;stroke:#000000"
+       id="use195341"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(2.7111909,0,0,3.0465015,91.170814,167.07129)" />
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="125.21515"
+       y="207.75603"
+       id="text197942"><tspan
+         sodipodi:role="line"
+         id="tspan197940"
+         style="stroke-width:0.264583"
+         x="125.21515"
+         y="207.75603">foo.org    &lt;IP&gt;</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="124.58415"
+       y="237.75603"
+       id="text197942-2"><tspan
+         sodipodi:role="line"
+         style="stroke-width:0.264583"
+         x="124.58415"
+         y="237.75603"
+         id="tspan216926">bar.org    &lt;IP&gt;</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="123.3081"
+       y="247.79585"
+       id="text197942-2-2"><tspan
+         sodipodi:role="line"
+         style="stroke-width:0.264583"
+         x="123.3081"
+         y="247.79585"
+         id="tspan216926-2">baz.org    &lt;IP&gt;</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="117.81051"
+       y="217.75603"
+       id="text197942-0"><tspan
+         sodipodi:role="line"
+         id="tspan197940-4"
+         style="stroke-width:0.264583"
+         x="117.81051"
+         y="217.75603">cdn.foo.org &lt;IP&gt;</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="117.7795"
+       y="227.75603"
+       id="text197942-0-8"><tspan
+         sodipodi:role="line"
+         style="stroke-width:0.264583"
+         x="117.7795"
+         y="227.75603"
+         id="tspan205582">ads.foo.org &lt;IP&gt;</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="132.48187"
+       y="253.71907"
+       id="text222454"><tspan
+         sodipodi:role="line"
+         style="stroke-width:0.264583"
+         x="132.48187"
+         y="253.71907"
+         id="tspan243464">... </tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="159.98187"
+       y="253.71907"
+       id="text242464"><tspan
+         sodipodi:role="line"
+         id="tspan242462"
+         style="stroke-width:0.264583"
+         x="159.98187"
+         y="253.71907">...</tspan></text>
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.188829;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Lend-3)"
+       d="M 87.769169,229.39894 H 110.90383"
+       id="path245597-7" />
+    <text
+       xml:space="preserve"
+       style="font-size:5.64444px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583"
+       x="146.05469"
+       y="184.60161"
+       id="text247911"><tspan
+         sodipodi:role="line"
+         id="tspan247909"
+         style="font-weight:bold;font-size:5.64444px;text-align:center;text-anchor:middle;fill:#e3dbdb;stroke-width:0.264583"
+         x="146.05469"
+         y="184.60161">Shared</tspan><tspan
+         sodipodi:role="line"
+         style="font-weight:bold;font-size:5.64444px;text-align:center;text-anchor:middle;fill:#e3dbdb;stroke-width:0.264583"
+         x="146.05469"
+         y="191.65717"
+         id="tspan249695">preload cache</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:5.64444px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583"
+       x="212.68121"
+       y="184.60161"
+       id="text247911-0"><tspan
+         sodipodi:role="line"
+         style="font-weight:bold;font-size:5.64444px;text-align:center;text-anchor:middle;fill:#e3dbdb;stroke-width:0.264583"
+         x="212.68121"
+         y="184.60161"
+         id="tspan249695-1">Per-circuit caches</tspan><tspan
+         sodipodi:role="line"
+         style="font-weight:bold;font-size:5.64444px;text-align:center;text-anchor:middle;fill:#e3dbdb;stroke-width:0.264583"
+         x="212.68121"
+         y="191.65717"
+         id="tspan252089">without any sharing</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583"
+       x="182.99969"
+       y="203.61807"
+       id="text267626"><tspan
+         sodipodi:role="line"
+         id="tspan267624"
+         style="font-size:6.35px;fill:#e3dbdb;stroke-width:0.264583"
+         x="182.99969"
+         y="203.61807">Circuit A</tspan></text>
+    <use
+       xlink:href="#AuxillaryOp"
+       style="fill:#ffffff;stroke:#000000"
+       id="use265468-0"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(1.3391931,0,0,0.9961219,201.44371,195.62004)" />
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583"
+       x="214.33716"
+       y="203.61807"
+       id="text267626-9"><tspan
+         sodipodi:role="line"
+         id="tspan267624-1"
+         style="font-size:6.35px;fill:#e3dbdb;stroke-width:0.264583"
+         x="214.33716"
+         y="203.61807">Circuit B</tspan></text>
+    <use
+       xlink:href="#AuxillaryOp"
+       style="fill:#ffffff;stroke:#000000"
+       id="use265468-7"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(1.3391931,0,0,0.9961219,170.10592,219.76682)" />
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583"
+       x="182.70322"
+       y="256.8056"
+       id="text267626-7"><tspan
+         sodipodi:role="line"
+         id="tspan267624-11"
+         style="font-size:6.35px;fill:#e3dbdb;stroke-width:0.264583"
+         x="182.70322"
+         y="256.8056">Circuit C</tspan></text>
+    <use
+       xlink:href="#AuxillaryOp"
+       style="fill:#ffffff;stroke:#000000"
+       id="use265468-0-5"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(1.3391931,0,0,0.9961219,201.4434,219.76683)" />
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583"
+       x="214.04068"
+       y="256.8056"
+       id="text267626-9-9"><tspan
+         sodipodi:role="line"
+         id="tspan267624-1-7"
+         style="font-size:6.35px;fill:#e3dbdb;stroke-width:0.264583"
+         x="214.04068"
+         y="256.8056">Circuit D</tspan></text>
+    <use
+       xlink:href="#Connector"
+       style="fill:#000000;stroke:#000000"
+       id="use286452"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="translate(260.60151,203.49378)" />
+    <use
+       xlink:href="#Connector"
+       style="fill:#000000;stroke:#000000"
+       id="use286485"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(0.62627983,0,0,0.62627983,287.26915,201.16267)" />
+    <use
+       xlink:href="#Connector"
+       style="fill:#000000;stroke:#000000"
+       id="use286514"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(1.7675124,0,0,1.8148081,267.16148,197.49215)" />
+    <use
+       xlink:href="#Connector"
+       style="fill:#000000;stroke:#000000"
+       id="use286543"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(0.32203591,0,0,0.32203591,285.88929,214.32011)" />
+    <use
+       xlink:href="#Connector"
+       style="fill:#000000;stroke:#000000"
+       id="use286572"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(0.22896026,0,0,0.22896026,271.99081,227.94076)" />
+    <use
+       xlink:href="#Connector"
+       style="fill:#000000;stroke:#000000"
+       id="use286601"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(0.41887097,0,0,0.41887097,276.71473,232.09806)" />
+    <use
+       xlink:href="#Connector"
+       style="fill:#000000;stroke:#000000"
+       id="use286630"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(0.59805015,0,0,0.59805015,308.39824,225.69642)" />
+    <use
+       xlink:href="#Connector"
+       style="fill:#000000;stroke:#000000"
+       id="use286659"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(0.18981869,0,0,0.18981869,312.59608,214.1791)" />
+    <use
+       xlink:href="#Connector"
+       style="fill:#000000;stroke:#000000"
+       id="use286688"
+       x="0"
+       y="0"
+       width="100%"
+       height="100%"
+       transform="matrix(0.17756172,0,0,0.17756172,314.32185,218.07642)" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 282.84226,224.72766 16.89521,8.22082"
+       id="path286788" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 282.84226,224.72766 9.24705,-3.97375"
+       id="path286792" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 318.13979,221.99684 2.58324,15.8614"
+       id="path286794" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 316.41794,217.92136 -15.95991,-4.4174"
+       id="path286796" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 276.92327,233.15939 8.19229,7.47513"
+       id="path286798" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 285.11556,240.63452 -3.56695,-13.33556"
+       id="path286800" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 301.54124,225.40244 -1.44981,-9.58557"
+       id="path286915" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 309.50144,235.61937 9.20475,2.17804"
+       id="path287030" />
+    <text
+       xml:space="preserve"
+       style="font-size:7.05556px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="277.85809"
+       y="205.14281"
+       id="text291742"><tspan
+         sodipodi:role="line"
+         id="tspan291740"
+         style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583"
+         x="277.85809"
+         y="205.14281">DNS</tspan><tspan
+         sodipodi:role="line"
+         style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583"
+         x="277.85809"
+         y="213.96225"
+         id="tspan300714">hierarchy</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="193.21259"
+       y="216.56465"
+       id="text310768"><tspan
+         sodipodi:role="line"
+         style="stroke-width:0.264583"
+         x="193.21259"
+         y="216.56465"
+         id="tspan310770">...</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="224.71259"
+       y="216.26466"
+       id="text310768-8"><tspan
+         sodipodi:role="line"
+         style="stroke-width:0.264583"
+         x="224.71259"
+         y="216.26466"
+         id="tspan310770-4">...</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="224.71259"
+       y="240.26466"
+       id="text315480"><tspan
+         sodipodi:role="line"
+         style="stroke-width:0.264583"
+         x="224.71259"
+         y="240.26466"
+         id="tspan315482">...</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="193.21259"
+       y="240.26466"
+       id="text320216"><tspan
+         sodipodi:role="line"
+         id="tspan320214"
+         style="stroke-width:0.264583"
+         x="193.21259"
+         y="240.26466">...</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="114.83587"
+       y="53.926041"
+       id="text86572"><tspan
+         sodipodi:role="line"
+         style="text-align:center;text-anchor:middle;stroke-width:0.264583"
+         x="114.83587"
+         y="53.926041"
+         id="tspan86594">Store domains found</tspan><tspan
+         sodipodi:role="line"
+         style="text-align:center;text-anchor:middle;stroke-width:0.264583"
+         x="114.83587"
+         y="61.863541"
+         id="tspan12129">while loading foo.org,</tspan><tspan
+         sodipodi:role="line"
+         style="text-align:center;text-anchor:middle;stroke-width:0.264583"
+         x="114.83587"
+         y="69.801041"
+         id="tspan12237">bar.org, baz.org, ..., from</tspan><tspan
+         sodipodi:role="line"
+         style="text-align:center;text-anchor:middle;stroke-width:0.264583"
+         x="114.83587"
+         y="77.738541"
+         id="tspan262940">several vantage points</tspan><tspan
+         sodipodi:role="line"
+         style="text-align:center;text-anchor:middle;stroke-width:0.264583"
+         x="114.83587"
+         y="85.676041"
+         id="tspan12670" /></text>
+    <text
+       xml:space="preserve"
+       style="font-size:7.76111px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="75.484276"
+       y="151.77661"
+       id="text141573"><tspan
+         sodipodi:role="line"
+         style="font-size:7.76111px;stroke-width:0.264583"
+         x="75.484276"
+         y="151.77661"
+         id="tspan141579"><tspan
+   style="font-weight:bold"
+   id="tspan149241">Phase 1</tspan> - visit sites</tspan><tspan
+         sodipodi:role="line"
+         style="font-size:7.76111px;stroke-width:0.264583"
+         x="75.484276"
+         y="161.478"
+         id="tspan141583">on a popularity list</tspan></text>
+    <g
+       id="g42025"
+       transform="translate(5.2384051,-10.302621)">
+      <image
+         preserveAspectRatio="none"
+         inkscape:svg-dpi="96"
+         width="45.069122"
+         height="49.637085"
+         xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjwh LS0gQ3JlYXRlZCB3aXRoIElua3NjYXBlIChodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy8pIC0tPgo8 c3ZnIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5z IyIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczpjYz0iaHR0cDovL2Ny ZWF0aXZlY29tbW9ucy5vcmcvbnMjIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1l bnRzLzEuMS8iIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOmlu a3NjYXBlPSJodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy9uYW1lc3BhY2VzL2lua3NjYXBlIiB4bWxu czpzb2RpcG9kaT0iaHR0cDovL3NvZGlwb2RpLnNvdXJjZWZvcmdlLm5ldC9EVEQvc29kaXBvZGkt MC5kdGQiIHhtbG5zOm5zMT0iaHR0cDovL3NvemkuYmFpZXJvdWdlLmZyIiB4bWxuczp4bGluaz0i aHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgaWQ9InN2ZzM2MDkiIHZpZXdCb3g9IjAgMCAx NzAuMzQgMjI1LjIzIiB2ZXJzaW9uPSIxLjEiIGlua3NjYXBlOnZlcnNpb249IjAuOTEgcjEzNzI1 Ij4KICA8dGl0bGUgaWQ9InRpdGxlMzYzMCI+RG9jdW1lbnQ8L3RpdGxlPgogIDxnIGlkPSJsYXll cjEiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yMTQuODMgLTQyMi42KSI+CiAgICA8ZyBpZD0iZzU1 MDgiIHRyYW5zZm9ybT0ibWF0cml4KC43NTI0OSAwIDAgLjc0MDI4IC0yMDUuMzkgNTI5LjgxKSI+ CiAgICAgIDxwYXRoIGlkPSJyZWN0NTQ5OCIgc3R5bGU9InN0cm9rZTojMDAwMDAwO3N0cm9rZS13 aWR0aDoxMy4zOTg7ZmlsbDpub25lIiBkPSJtNTY1LjEyLTEzOC4xMnYyOTAuODhoMjEyLjc1di0y MjAuMDlsLTEzMi42OS03MC43ODFoLTgwLjA2MnoiLz4KICAgICAgPHBhdGggaWQ9InJlY3Q1NTAw IiBzdHlsZT0iZmlsbDojYzhiN2I3IiBkPSJtNzMzLjUyLTAuMTUyMTEgMzguMDc4LTUyLjQwMy0x MzIuNTUtNzUuMTU5IDg5LjU0OCAxMjEuMjYgNC45MjM0IDYuMzAyNHoiLz4KICAgICAgPHBhdGgg aWQ9InBhdGg1NTAzIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZTojMDAwMDAw O3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS13aWR0aDoxMy4zOTg7ZmlsbDojZmZmZmZmIiBk PSJtNzQ2LjM1LTM4LjY5MiAzMS43Ny0zOC41OTktMTI5LjI1LTU3LjkyNyA5Ny40ODMgOTYuNTI2 eiIvPgogICAgPC9nPgogIDwvZz4KICA8bWV0YWRhdGE+CiAgICA8cmRmOlJERj4KICAgICAgPGNj Oldvcms+CiAgICAgICAgPGRjOmZvcm1hdD5pbWFnZS9zdmcreG1sPC9kYzpmb3JtYXQ+CiAgICAg ICAgPGRjOnR5cGUgcmRmOnJlc291cmNlPSJodHRwOi8vcHVybC5vcmcvZGMvZGNtaXR5cGUvU3Rp bGxJbWFnZSIvPgogICAgICAgIDxjYzpsaWNlbnNlIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0 aXZlY29tbW9ucy5vcmcvbGljZW5zZXMvcHVibGljZG9tYWluLyIvPgogICAgICAgIDxkYzpwdWJs aXNoZXI+CiAgICAgICAgICA8Y2M6QWdlbnQgcmRmOmFib3V0PSJodHRwOi8vb3BlbmNsaXBhcnQu b3JnLyI+CiAgICAgICAgICAgIDxkYzp0aXRsZT5PcGVuY2xpcGFydDwvZGM6dGl0bGU+CiAgICAg ICAgICA8L2NjOkFnZW50PgogICAgICAgIDwvZGM6cHVibGlzaGVyPgogICAgICAgIDxkYzp0aXRs ZT5Eb2N1bWVudDwvZGM6dGl0bGU+CiAgICAgICAgPGRjOmRhdGU+MjAxMi0wNC0wOFQwNjo1MDoz MzwvZGM6ZGF0ZT4KICAgICAgICA8ZGM6ZGVzY3JpcHRpb24+QSBkb2N1bWVudCBpY29uIGZyb20g dGhlIGZhY2lsaXRhdGlvbiBzZXQuPC9kYzpkZXNjcmlwdGlvbj4KICAgICAgICA8ZGM6c291cmNl Pmh0dHBzOi8vb3BlbmNsaXBhcnQub3JnL2RldGFpbC8xNjk0MTYvZG9jdW1lbnQtYnktYml0dGVy anVnPC9kYzpzb3VyY2U+CiAgICAgICAgPGRjOmNyZWF0b3I+CiAgICAgICAgICA8Y2M6QWdlbnQ+ CiAgICAgICAgICAgIDxkYzp0aXRsZT5iaXR0ZXJqdWc8L2RjOnRpdGxlPgogICAgICAgICAgPC9j YzpBZ2VudD4KICAgICAgICA8L2RjOmNyZWF0b3I+CiAgICAgICAgPGRjOnN1YmplY3Q+CiAgICAg ICAgICA8cmRmOkJhZz4KICAgICAgICAgICAgPHJkZjpsaT5Eb2N1bWVudDwvcmRmOmxpPgogICAg ICAgICAgICA8cmRmOmxpPmFic3RyYWN0PC9yZGY6bGk+CiAgICAgICAgICAgIDxyZGY6bGk+Y29y bmVyPC9yZGY6bGk+CiAgICAgICAgICAgIDxyZGY6bGk+Zm9sZDwvcmRmOmxpPgogICAgICAgICAg ICA8cmRmOmxpPnBhcGVyPC9yZGY6bGk+CiAgICAgICAgICA8L3JkZjpCYWc+CiAgICAgICAgPC9k YzpzdWJqZWN0PgogICAgICA8L2NjOldvcms+CiAgICAgIDxjYzpMaWNlbnNlIHJkZjphYm91dD0i aHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbGljZW5zZXMvcHVibGljZG9tYWluLyI+CiAgICAg ICAgPGNjOnBlcm1pdHMgcmRmOnJlc291cmNlPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9u cyNSZXByb2R1Y3Rpb24iLz4KICAgICAgICA8Y2M6cGVybWl0cyByZGY6cmVzb3VyY2U9Imh0dHA6 Ly9jcmVhdGl2ZWNvbW1vbnMub3JnL25zI0Rpc3RyaWJ1dGlvbiIvPgogICAgICAgIDxjYzpwZXJt aXRzIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjRGVyaXZhdGl2 ZVdvcmtzIi8+CiAgICAgIDwvY2M6TGljZW5zZT4KICAgIDwvcmRmOlJERj4KICA8L21ldGFkYXRh Pgo8L3N2Zz4K "
+         id="image844"
+         x="33.777676"
+         y="213.74522" />
+      <text
+         xml:space="preserve"
+         style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+         x="44.5397"
+         y="236.45029"
+         id="text47096"><tspan
+           sodipodi:role="line"
+           id="tspan47094"
+           style="font-size:6.35px;stroke-width:0.264583"
+           x="44.5397"
+           y="236.45029">foo.org</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+         x="38.428299"
+         y="244.90999"
+         id="text47096-2"><tspan
+           sodipodi:role="line"
+           id="tspan47094-0"
+           style="font-size:6.35px;stroke-width:0.264583"
+           x="38.428299"
+           y="244.90999">cdn.foo.org</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+         x="38.571056"
+         y="252.73021"
+         id="text47096-23"><tspan
+           sodipodi:role="line"
+           id="tspan47094-7"
+           style="font-size:6.35px;stroke-width:0.264583"
+           x="38.571056"
+           y="252.73021">ads.foo.org</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+         x="52.293133"
+         y="257.54556"
+         id="text118919"><tspan
+           sodipodi:role="line"
+           style="stroke-width:0.264583"
+           x="52.293133"
+           y="257.54556"
+           id="tspan118921">...</tspan></text>
+    </g>
+    <image
+       preserveAspectRatio="none"
+       inkscape:svg-dpi="96"
+       width="31.920643"
+       height="41.946896"
+       xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIj8+CjxzdmcKICAgIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5v cmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyIKICAgIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy8yMDAwL3N2ZyIKICAgIHhtbG5zOmNjPSJodHRwOi8vd2ViLnJlc291cmNlLm9yZy9jYy8iCiAg ICB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIKICAgIHhtbG5zOmRj PSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIKICAgIHhtbG5zOnN2Zz0iaHR0cDov L3d3dy53My5vcmcvMjAwMC9zdmciCiAgICB4bWxuczppbmtzY2FwZT0iaHR0cDovL3d3dy5pbmtz Y2FwZS5vcmcvbmFtZXNwYWNlcy9pbmtzY2FwZSIKICAgIHhtbG5zOnNvZGlwb2RpPSJodHRwOi8v c29kaXBvZGkuc291cmNlZm9yZ2UubmV0L0RURC9zb2RpcG9kaS0wLmR0ZCIKICAgIHhtbG5zOm5z MT0iaHR0cDovL3NvemkuYmFpZXJvdWdlLmZyIgogICAgYmFzZVByb2ZpbGU9ImZ1bGwiCiAgICB2 ZXJzaW9uPSIxLjEiCiAgICB2aWV3Qm94PSIwIDAgMzUwIDUwMCIKICA+CiAgPGRlZnMKICAgID4K ICAgIDxwYXRoCiAgICAgICAgaWQ9ImNvZyIKICAgICAgICB0cmFuc2Zvcm09InNjYWxlKC40KSIK ICAgICAgICBmaWxsPSJkYXJrcmVkIgogICAgICAgIGQ9Im0yMTMgMGwtNCAzOS01IDM5LTIwIDkt MjAgOS0zMi0yNi0zMS0yNS0yNyAyNy0yNyAyNyAyNSAzMSAyNSAzMi05IDE5LTkgMTktMzUgNWMt MjAgMy0zNyA1LTQwIDZzLTQgMTItNCAzOXYzN2wzOSA0YzI0IDMgNDAgNiA0MCA4czMgMTIgOCAy MWw4IDE4LTI1IDMwLTI1IDMxIDI3IDI3IDI3IDI3IDMwLTIzIDMwLTI0IDE4IDljMTAgNSAyMCAx MCAyMiAxMCAxIDEgNCAxNiA3IDM0IDIgMTggNCAzNCA1IDM3czExIDQgMzggNGgzOGw0LTM2YzMt MjggNS0zNyAxMC0zOCAzLTEgMTMtNSAyMy0xMGwxNy04IDI5IDI0IDMwIDIzIDI2LTI3YzIwLTIw IDI2LTI4IDI0LTMxcy0xMy0xNi0yMy0yOWwtMjAtMjUgOS0xOGM1LTEwIDgtMjAgOC0yMiAwLTQg OC02IDUyLTExbDIyLTMgMS0zOCAxLTM4LTM4LTRjLTIzLTMtMzgtNi0zOC04cy0zLTEyLTgtMjJs LTktMTkgMjQtMjkgMjQtMzAtMjctMjctMjctMjctMzAgMjQtMzAgMjQtMjEtOS0yMS05LTUtMzct NS0zOC0zOC0xLTM4LTF6bTM3IDE3MGM0NCAwIDgwIDM2IDgwIDgwcy0zNiA4MC04MCA4MC04MC0z Ni04MC04MCAzNi04MCA4MC04MHoiCiAgICAvPgogIDwvZGVmcwogID4KICA8dXNlCiAgICAgIG9w YWNpdHk9Ii4zIgogICAgICB4bGluazpocmVmPSIjY29nIgogIC8+CiAgPHVzZQogICAgICBvcGFj aXR5PSIuNiIKICAgICAgeGxpbms6aHJlZj0iI2NvZyIKICAgICAgdHJhbnNmb3JtPSJ0cmFuc2xh dGUoMTIwLDEyMCkgcm90YXRlKDIyLjUgMTAwLDEwMCkiCiAgLz4KICA8dXNlCiAgICAgIHhsaW5r OmhyZWY9IiNjb2ciCiAgICAgIHRyYW5zZm9ybT0idHJhbnNsYXRlKDAsMjQwKSIKICAvPgogIDxt ZXRhZGF0YQogICAgPgogICAgPHJkZjpSREYKICAgICAgPgogICAgICA8Y2M6V29yawogICAgICAg ID4KICAgICAgICA8ZGM6Zm9ybWF0CiAgICAgICAgICA+aW1hZ2Uvc3ZnK3htbDwvZGM6Zm9ybWF0 CiAgICAgICAgPgogICAgICAgIDxkYzp0eXBlCiAgICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0 cDovL3B1cmwub3JnL2RjL2RjbWl0eXBlL1N0aWxsSW1hZ2UiCiAgICAgICAgLz4KICAgICAgICA8 Y2M6bGljZW5zZQogICAgICAgICAgICByZGY6cmVzb3VyY2U9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1v bnMub3JnL2xpY2Vuc2VzL3B1YmxpY2RvbWFpbi8iCiAgICAgICAgLz4KICAgICAgICA8ZGM6cHVi bGlzaGVyCiAgICAgICAgICA+CiAgICAgICAgICA8Y2M6QWdlbnQKICAgICAgICAgICAgICByZGY6 YWJvdXQ9Imh0dHA6Ly9vcGVuY2xpcGFydC5vcmcvIgogICAgICAgICAgICA+CiAgICAgICAgICAg IDxkYzp0aXRsZQogICAgICAgICAgICAgID5PcGVuY2xpcGFydDwvZGM6dGl0bGUKICAgICAgICAg ICAgPgogICAgICAgICAgPC9jYzpBZ2VudAogICAgICAgICAgPgogICAgICAgIDwvZGM6cHVibGlz aGVyCiAgICAgICAgPgogICAgICAgIDxkYzp0aXRsZQogICAgICAgICAgPlBpbmsgY29nd2hlZWxz PC9kYzp0aXRsZQogICAgICAgID4KICAgICAgICA8ZGM6ZGF0ZQogICAgICAgICAgPjIwMTMtMDkt MTRUMTY6MDA6NDE8L2RjOmRhdGUKICAgICAgICA+CiAgICAgICAgPGRjOmRlc2NyaXB0aW9uCiAg ICAgICAgICA+U29tZSBjb2d3aGVlbHMgZnJvbSBodHRwczovL2NvbW1vbnMud2lraW1lZGlhLm9y Zy93aWtpL0ZpbGU6Q29nLXNjcmlwdGVkLXN2Zy5zdmc8L2RjOmRlc2NyaXB0aW9uCiAgICAgICAg PgogICAgICAgIDxkYzpzb3VyY2UKICAgICAgICAgID5odHRwczovL29wZW5jbGlwYXJ0Lm9yZy9k ZXRhaWwvMTgzNDM2L3BpbmstY29nd2hlZWxzLWJ5LWxpZnRhcm4tMTgzNDM2PC9kYzpzb3VyY2UK ICAgICAgICA+CiAgICAgICAgPGRjOmNyZWF0b3IKICAgICAgICAgID4KICAgICAgICAgIDxjYzpB Z2VudAogICAgICAgICAgICA+CiAgICAgICAgICAgIDxkYzp0aXRsZQogICAgICAgICAgICAgID5s aWZ0YXJuPC9kYzp0aXRsZQogICAgICAgICAgICA+CiAgICAgICAgICA8L2NjOkFnZW50CiAgICAg ICAgICA+CiAgICAgICAgPC9kYzpjcmVhdG9yCiAgICAgICAgPgogICAgICAgIDxkYzpzdWJqZWN0 CiAgICAgICAgICA+CiAgICAgICAgICA8cmRmOkJhZwogICAgICAgICAgICA+CiAgICAgICAgICAg IDxyZGY6bGkKICAgICAgICAgICAgICA+Y29nPC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAg ICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmNvZ3doZWVsPC9yZGY6bGkKICAgICAgICAgICAg PgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmNvZ3doZWVsczwvcmRmOmxpCiAg ICAgICAgICAgID4KICAgICAgICAgICAgPHJkZjpsaQogICAgICAgICAgICAgID5nZWFyPC9yZGY6 bGkKICAgICAgICAgICAgPgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmdlYXJz PC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAg PnBpbms8L3JkZjpsaQogICAgICAgICAgICA+CiAgICAgICAgICAgIDxyZGY6bGkKICAgICAgICAg ICAgICA+cmVkPC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAgICAgPC9yZGY6QmFnCiAgICAg ICAgICA+CiAgICAgICAgPC9kYzpzdWJqZWN0CiAgICAgICAgPgogICAgICA8L2NjOldvcmsKICAg ICAgPgogICAgICA8Y2M6TGljZW5zZQogICAgICAgICAgcmRmOmFib3V0PSJodHRwOi8vY3JlYXRp dmVjb21tb25zLm9yZy9saWNlbnNlcy9wdWJsaWNkb21haW4vIgogICAgICAgID4KICAgICAgICA8 Y2M6cGVybWl0cwogICAgICAgICAgICByZGY6cmVzb3VyY2U9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1v bnMub3JnL25zI1JlcHJvZHVjdGlvbiIKICAgICAgICAvPgogICAgICAgIDxjYzpwZXJtaXRzCiAg ICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjRGlz dHJpYnV0aW9uIgogICAgICAgIC8+CiAgICAgICAgPGNjOnBlcm1pdHMKICAgICAgICAgICAgcmRm OnJlc291cmNlPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9ucyNEZXJpdmF0aXZlV29ya3Mi CiAgICAgICAgLz4KICAgICAgPC9jYzpMaWNlbnNlCiAgICAgID4KICAgIDwvcmRmOlJERgogICAg PgogIDwvbWV0YWRhdGEKICA+Cjwvc3ZnCj4K "
+       id="image746"
+       x="85.593079"
+       y="83.116173" />
+    <g
+       style="stroke:#58928a;stroke-opacity:1"
+       clip-path="url(#clipPath4258)"
+       id="g4256"
+       transform="matrix(2.0735697,-0.38889921,-0.43078373,-1.8719593,173.29626,93.1446)">
+      <g
+         style="stroke:#58928a;stroke-opacity:1"
+         transform="translate(0.563,5.6699)"
+         id="g4262">
+        <path
+           id="path4264"
+           style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1"
+           d="m 0,0 c 0,2.82 2.287,5.107 5.107,5.107 2.82,0 5.107,-2.287 5.107,-5.107 0,-2.82 -2.287,-5.107 -5.107,-5.107 C 2.287,-5.107 0,-2.82 0,0 Z" />
+      </g>
+      <g
+         style="stroke:#6c6c6c;stroke-opacity:1"
+         transform="translate(8.4111,5.6704)"
+         id="g4266">
+        <path
+           id="path4268"
+           style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1"
+           d="m 0,0 c 0,2.819 -1.259,5.106 -2.811,5.106 -1.552,0 -2.811,-2.287 -2.811,-5.106 0,-2.823 1.259,-5.108 2.811,-5.108 C -1.259,-5.108 0,-2.823 0,0 Z" />
+      </g>
+      <g
+         style="stroke:#6c6c6c;stroke-opacity:1"
+         transform="translate(5.6699,10.647)"
+         id="g4270">
+        <path
+           id="path4272"
+           style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1"
+           d="M 0,0 V -9.855" />
+      </g>
+      <g
+         style="stroke:#6c6c6c;stroke-opacity:1"
+         transform="translate(0.563,5.6699)"
+         id="g4274">
+        <path
+           id="path4276"
+           style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1"
+           d="M 0,0 H 10.214" />
+      </g>
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
+       x="171.64845"
+       y="97.92038"
+       id="text3572"><tspan
+         sodipodi:role="line"
+         id="tspan3570"
+         style="font-size:7.05556px;stroke-width:0.264583"
+         x="171.64845"
+         y="97.92038">foo.org</tspan><tspan
+         sodipodi:role="line"
+         style="font-size:7.05556px;stroke-width:0.264583"
+         x="171.64845"
+         y="106.73983"
+         id="tspan68806" /></text>
+    <g
+       style="stroke:#58928a;stroke-opacity:1"
+       clip-path="url(#clipPath4258-9)"
+       id="g4256-3"
+       transform="matrix(2.0735697,-0.38889921,-0.43078373,-1.8719593,173.29628,139.42531)">
+      <g
+         style="stroke:#58928a;stroke-opacity:1"
+         transform="translate(0.563,5.6699)"
+         id="g4262-6">
+        <path
+           id="path4264-1"
+           style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1"
+           d="m 0,0 c 0,2.82 2.287,5.107 5.107,5.107 2.82,0 5.107,-2.287 5.107,-5.107 0,-2.82 -2.287,-5.107 -5.107,-5.107 C 2.287,-5.107 0,-2.82 0,0 Z" />
+      </g>
+      <g
+         style="stroke:#6c6c6c;stroke-opacity:1"
+         transform="translate(8.4111,5.6704)"
+         id="g4266-2">
+        <path
+           id="path4268-9"
+           style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1"
+           d="m 0,0 c 0,2.819 -1.259,5.106 -2.811,5.106 -1.552,0 -2.811,-2.287 -2.811,-5.106 0,-2.823 1.259,-5.108 2.811,-5.108 C -1.259,-5.108 0,-2.823 0,0 Z" />
+      </g>
+      <g
+         style="stroke:#6c6c6c;stroke-opacity:1"
+         transform="translate(5.6699,10.647)"
+         id="g4270-3">
+        <path
+           id="path4272-1"
+           style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1"
+           d="M 0,0 V -9.855" />
+      </g>
+      <g
+         style="stroke:#6c6c6c;stroke-opacity:1"
+         transform="translate(0.563,5.6699)"
+         id="g4274-9">
+        <path
+           id="path4276-4"
+           style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1"
+           d="M 0,0 H 10.214" />
+      </g>
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583"
+       x="171.64847"
+       y="144.20119"
+       id="text3572-7"><tspan
+         sodipodi:role="line"
+         id="tspan3570-8"
+         style="font-size:7.05556px;stroke-width:0.264583"
+         x="171.64847"
+         y="144.20119">foo.org</tspan><tspan
+         sodipodi:role="line"
+         style="font-size:7.05556px;stroke-width:0.264583"
+         x="171.64847"
+         y="153.02063"
+         id="tspan68806-4" /></text>
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow1Lstart);marker-end:url(#Arrow1Lend)"
+       d="m 120.28722,108.51063 19.30483,7.65883 3.56213,-4.825 -1.72511,10.81668 5.84978,-8.92633 -0.47502,5.37605 18.52116,7.40042"
+       id="path9445" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Arrow1Lstart);marker-end:url(#Arrow1Lend)"
+       d="m 119.75925,97.003192 20.08697,-6.068938 -1.26348,-7.255973 5.72206,10.656067 -1.48746,-11.573417 3.69027,6.41613 18.3502,-5.493549"
+       id="path9471" />
+    <text
+       xml:space="preserve"
+       style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583"
+       x="142.28778"
+       y="103.97533"
+       id="text22310"><tspan
+         sodipodi:role="line"
+         id="tspan22308"
+         style="stroke-width:0.264583"
+         x="142.28778"
+         y="103.97533">...</tspan></text>
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:1.5, 1.5;stroke-dashoffset:0;stroke-opacity:1;marker-start:url(#Arrow1Lstart);marker-end:url(#Arrow1Lend)"
+       d="m 271.47134,228.65635 -24.769,0.0425"
+       id="path42256" />
+    <image
+       preserveAspectRatio="none"
+       inkscape:svg-dpi="96"
+       width="21.618526"
+       height="34.065556"
+       xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHN2ZyB3aWR0aD0iNjZweCIg aGVpZ2h0PSIxMDRweCIgdmlld0JveD0iMCAwIDY2IDEwNCIgdmVyc2lvbj0iMS4xIiB4bWxucz0i aHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9y Zy8xOTk5L3hsaW5rIj4KICAgIDwhLS0gR2VuZXJhdG9yOiBTa2V0Y2ggNDcuMSAoNDU0MjIpIC0g aHR0cDovL3d3dy5ib2hlbWlhbmNvZGluZy5jb20vc2tldGNoIC0tPgogICAgPHRpdGxlPm9uaW9u LWJnPC90aXRsZT4KICAgIDxkZXNjPkNyZWF0ZWQgd2l0aCBTa2V0Y2guPC9kZXNjPgogICAgPGRl ZnM+PC9kZWZzPgogICAgPGcgaWQ9IlBhZ2UtMSIgc3Ryb2tlPSJub25lIiBzdHJva2Utd2lkdGg9 IjEiIGZpbGw9Im5vbmUiIGZpbGwtcnVsZT0iZXZlbm9kZCI+CiAgICAgICAgPGcgaWQ9InN0eWxl Z3VpZGUtcG9ydGFsIiB0cmFuc2Zvcm09InRyYW5zbGF0ZSgtMi4wMDAwMDAsIC0yMy4wMDAwMDAp IiBmaWxsLXJ1bGU9Im5vbnplcm8iPgogICAgICAgICAgICA8ZyBpZD0ib25pb24tYmciIHRyYW5z Zm9ybT0idHJhbnNsYXRlKDIuMDAwMDAwLCAyMy4wMDAwMDApIj4KICAgICAgICAgICAgICAgIDxn IGlkPSJsYXllcjVfMTdfIj4KICAgICAgICAgICAgICAgICAgICA8ZyBpZD0icGF0aDI1NTRfMjhf IiB0cmFuc2Zvcm09InRyYW5zbGF0ZSgzMC4yOTcxNDMsIDAuMDAwMDAwKSIgZmlsbD0iIzY4QjA0 NCI+CiAgICAgICAgICAgICAgICAgICAgICAgIDxwYXRoIGQ9Ik04LjEzMjM5MTA1LDcuNzUyNTA1 NDUgTDUuNDIxNTk0MDMsMTguNzM1MjIxNSBDOS4yNDg2MDE1OSwxMC45ODI3MTYgMTUuNDY3NDg4 OSw1LjE2ODMzNjk2IDIyLjQ4MzY2OTQsLTcuMTA1NDI3MzZlLTE1IEMxNy4zODA5OTI2LDYuMTM3 NDAwMTUgMTIuNTk3MjMzMiwxMi4xMTMyODk4IDkuNzI2OTc3NTMsMTguMjUwNjg5OSBDMTQuNjcw MTk1NiwxMS4zMDU3MzcxIDIxLjIwODAwMDIsNy40Mjk0ODQzOSAyOC41NDMwOTgsNS4wMDY4MjY0 MyBDMTguNjU2NjYxOCwxMy44ODk5MDU2IDExLjAwMjY0NjcsMjMuNDE5MDI2OSA0Ljk0MzIxODA5 LDMyLjk0ODE0ODEgTDAuMTU5NDU4NjQ4LDMwLjg0ODUxMTMgQzEuMTE2MjEwNTQsMjMuMDk2MDA1 OCAzLjk4NjQ2NjIsMTUuMzQzNTAwNCA4LjEzMjM5MTA1LDcuNzUyNTA1NDUgTDguMTMyMzkxMDUs Ny43NTI1MDU0NSBaIiBpZD0iU2hhcGUiPjwvcGF0aD4KICAgICAgICAgICAgICAgICAgICA8L2c+ CiAgICAgICAgICAgICAgICAgICAgPGcgaWQ9InBhdGgyNTM0XzdfIiB0cmFuc2Zvcm09InRyYW5z bGF0ZSgwLjAwMDAwMCwgMjguMjI3MTYwKSIgZmlsbD0iI0Y1RjhERSI+CiAgICAgICAgICAgICAg ICAgICAgICAgIDxwYXRoIGQ9Ik0yNS44MzIzMDEsMC41MjE3MTM4NzEgTDM0Ljc2MTk4NTMsNC4y MzY0NTYwNiBDMzQuNzYxOTg1Myw2LjQ5NzYwMzQ5IDM0LjYwMjUyNjYsMTMuNjA0MDY2OCAzNi4w Mzc2NTQ1LDE1LjcwMzcwMzcgQzUxLjAyNjc2NzQsMzUuMjQ2NDc3OSA0OC40NzU0MjksNzQuMTcw NTE1NiAzMy4wMDc5NDAxLDc1LjEzOTU3ODggQzkuNTY3NTE4ODgsNzUuMTM5NTc4OCAwLjQ3ODM3 NTk0NCw1OC45ODg1MjU4IDAuNDc4Mzc1OTQ0LDQ0LjEyOTU1NyBDMC40NzgzNzU5NDQsMzAuNTYy NjcyNSAxNi41ODM2OTk0LDIxLjUxODA4MjggMjYuMTUxMjE4MywxMy42MDQwNjY4IEMyOC43MDI1 NTY2LDExLjUwNDQyOTkgMjguMjI0MTgwNyw2LjY1OTExNDAyIDI1LjgzMjMwMSwwLjUyMTcxMzg3 MSBMMjUuODMyMzAxLDAuNTIxNzEzODcxIFoiIGlkPSJTaGFwZSI+PC9wYXRoPgogICAgICAgICAg ICAgICAgICAgIDwvZz4KICAgICAgICAgICAgICAgICAgICA8ZyBpZD0icGF0aDI1MzZfMThfIiB0 cmFuc2Zvcm09InRyYW5zbGF0ZSgzNC44MTkyOTEsIDMyLjMwMjEwNikiIGZpbGw9IiM2MjM2NzYi PgogICAgICAgICAgICAgICAgICAgICAgICA8cGF0aCBkPSJNMC4xMDIxNTMxOTYsMCBMMy4yOTEz MjYxNiwxLjYxNTEwNTMgQzIuOTcyNDA4ODYsMy43MTQ3NDIxOSAzLjQ1MDc4NDgsOC41NjAwNTgx IDUuNTIzNzQ3MjMsOS44NTIxNDIzNCBDMTQuOTMxODA3NSwxNS44MjgwMzIgMjMuODYxNDkxOCwy Mi4yODg0NTMyIDI3LjM2OTU4MiwyOC43NDg4NzQ0IEMzOS44MDczNTY2LDUxLjUyMTg1OTEgMTgu NTk5MzU2NCw3Mi42Nzk3Mzg2IDAuMjYxNjExODQ0LDcwLjU4MDEwMTcgQzEwLjE0ODA0OCw2My4x NTA2MTczIDEzLjE3Nzc2MjMsNDcuODA3MTE2OSA5LjM1MDc1NDc4LDMxLjAxMDAyMTggQzcuNzU2 MTY4MywyNC4zODgwOTAxIDUuNTIzNzQ3MjMsMTguNTczNzExIDEuMjE4MzYzNzMsMTEuNzkwMjY4 NyBDLTAuMzc2MjIyNzQ4LDguNzIxNTY4NjMgMC4yNjE2MTE4NDQsNC42ODM4MDUzNyAwLjEwMjE1 MzE5NiwwIEwwLjEwMjE1MzE5NiwwIFoiIGlkPSJTaGFwZSI+PC9wYXRoPgogICAgICAgICAgICAg ICAgICAgIDwvZz4KICAgICAgICAgICAgICAgIDwvZz4KICAgICAgICAgICAgICAgIDxnIGlkPSJs YXllcjRfMTdfIiB0cmFuc2Zvcm09InRyYW5zbGF0ZSg5LjAwMDAwMCwgMzIuMDAwMDAwKSIgZmls bD0iIzAxMDEwMSI+CiAgICAgICAgICAgICAgICAgICAgPGcgaWQ9InBhdGgyNTQwXzE4XyIgdHJh bnNmb3JtPSJ0cmFuc2xhdGUoMC4wMDAwMDAsIDEwLjMyOTY2MSkiPgogICAgICAgICAgICAgICAg ICAgICAgICA8cGF0aCBkPSJNMjIuOTY0NjY3OCwwLjUwMjY1MDQwNSBDMjIuMzM1NDk4OSw0LjAw NzIyMTYzIDIxLjU0OTAzNzYsMTAuMzc5MTY5MyAxOC41NjA0ODUsMTIuNjA5MzUxIEMxNy4zMDIx NDcsMTMuNTY1MTQzMSAxNi4wNDM4MDksMTQuMzYxNjM2NiAxNC42MjgxNzg4LDE1LjMxNzQyODgg QzkuMjgwMjQyNDksMTguOTgxMjk4NyAzLjc3NTAxMzg5LDIyLjQ4NTg2OTkgMS40MTU2MzAyMSwz MS41NjU4OTUzIEMwLjk0Mzc1MzQ3MywzMy40Nzc0Nzk2IDEuNDE1NjMwMjEsMzUuNTQ4MzYyNiAx LjczMDIxNDcsMzcuNDU5OTQ2OSBDMy4xNDU4NDQ5MSw0Mi44NzYxMDI1IDYuOTIwODU4OCw0OC45 Mjk0NTI3IDkuOTA5NDExNDcsNTIuMjc0NzI1MyBDOS45MDk0MTE0Nyw1Mi40MzQwMjQgMTAuNTM4 NTgwNCw1Mi43NTI2MjE0IDEwLjUzODU4MDQsNTIuOTExOTIgQzEzLjA1NTI1NjQsNTUuOTM4NTk1 MiAxMy44NDE3MTc2LDU2LjczNTA4ODYgMjMuMTIxOTYwMSw1OC44MDU5NzE2IEwyMi45NjQ2Njc4 LDU5LjkyMTA2MjUgQzE3LjMwMjE0Nyw1OC4zMjgwNzU2IDEyLjc0MDY3MTksNTcuMDUzNjg2IDku NzUyMTE5MjIsNTMuNTQ5MTE0OCBDOS43NTIxMTkyMiw1My41NDkxMTQ4IDkuMjgwMjQyNDksNTIu OTExOTIgOS4yODAyNDI0OSw1Mi45MTE5MiBDNi4xMzQzOTc1OCw0OS4yNDgwNTAxIDIuMzU5Mzgz NjgsNDMuMTk0Njk5OCAwLjk0Mzc1MzQ3MywzNy40NTk5NDY5IEMwLjQ3MTg3NjczNywzNS4yMjk3 NjUyIC04Ljg4MTc4NDJlLTE0LDMzLjQ3NzQ3OTYgMC42MjkxNjg5ODIsMzEuMDg3OTk5MyBDMy4x NDU4NDQ5MSwyMS44NDg2NzUxIDguODA4MzY1NzUsMTguMTg0ODA1MiAxNC4zMTM1OTQzLDE0LjM2 MTYzNjYgQzE1LjU3MTkzMjMsMTMuNTY1MTQzMSAxNy4xNDQ4NTQ4LDEyLjc2ODY0OTcgMTguMjQ1 OTAwNSwxMS44MTI4NTc1IEMyMC40NDc5OTE5LDEwLjA2MDU3MTkgMjEuNzA2MzI5OSw0LjgwMzcx NTA5IDIyLjk2NDY2NzgsMC41MDI2NTA0MDUgTDIyLjk2NDY2NzgsMC41MDI2NTA0MDUgWiIgaWQ9 IlNoYXBlIj48L3BhdGg+CiAgICAgICAgICAgICAgICAgICAgPC9nPgogICAgICAgICAgICAgICAg ICAgIDxnIGlkPSJwYXRoMjU0Ml8xOF8iIHRyYW5zZm9ybT0idHJhbnNsYXRlKDYuMjkxNjkwLCAy NS4yMjIyOTMpIj4KICAgICAgICAgICAgICAgICAgICAgICAgPHBhdGggZD0iTTE5LjAzMjM2MTcs MC4xMDYxOTkxMjggQzE5LjAzMjM2MTcsNC4wODg2NjY0MyAxOC43MTc3NzcyLDYuMDAwMjUwNzMg MTkuNjYxNTMwNyw4Ljg2NzYyNzE4IEMyMC4yOTA2OTk3LDEwLjQ2MDYxNDEgMjIuMzM1NDk4OSwx Mi44NTAwOTQ1IDIyLjk2NDY2NzgsMTUuMDgwMjc2MiBDMjMuNzUxMTI5MSwxOC4xMDY5NTEzIDI0 LjY5NDg4MjUsMjEuMjkyOTI1MiAyNC41Mzc1OTAzLDIzLjM2MzgwODEgQzI0LjUzNzU5MDMsMjUu NTkzOTg5OCAyNC4zODAyOTgxLDI5Ljg5NTA1NDUgMjMuNDM2NTQ0NiwzNC41MTQ3MTY2IEMyMi42 NTAwODM0LDM4LjMzNzg4NTIgMjAuOTE5ODY4Nyw0MS41MjM4NTkgMTguMDg4NjA4Miw0My4yNzYx NDQ2IEMxNS4xMDAwNTU2LDQyLjYzODk0OTkgMTEuNjM5NjI2Miw0MS42ODMxNTc3IDkuNTk0ODI2 OTgsMzkuNzcxNTczNCBDNS42NjI1MjA4NCwzNi4yNjcwMDIyIDIuMDQ0Nzk5MTksMzAuMzcyOTUw NiAxLjU3MjkyMjQ2LDI1LjI3NTM5MjQgQzEuMjU4MzM3OTYsMjEuMTMzNjI2NSA1LjAzMzM1MTg2 LDE0LjkyMDk3NzUgMTAuMzgxMjg4MiwxMS44OTQzMDIzIEMxNC45NDI3NjMzLDkuMTg2MjI0NTcg MTUuODg2NTE2OCw2LjE1OTU0OTQyIDE2LjgzMDI3MDMsMS4zODA1ODg2NiBDMTUuNDE0NjQwMSw1 LjY4MTY1MzM0IDE0LjE1NjMwMjEsOS4xODYyMjQ1NyA5LjkwOTQxMTQ3LDExLjQxNjQwNjMgQzMu NjE3NzIxNjUsMTQuNzYxNjc4OCAwLjMxNDU4NDQ5MSwyMC4zMzcxMzMgMC42MjkxNjg5ODIsMjUu NzUzMjg4NSBDMS4xMDEwNDU3MiwzMi42MDMxMzIzIDMuNzc1MDEzODksMzcuMjIyNzk0MyA5LjEy Mjk1MDI0LDQwLjg4NjY2NDMgQzExLjMyNTA0MTcsNDIuNDc5NjUxMiAxNS41NzE5MzIzLDQ0LjIz MTkzNjggMTguMjQ1OTAwNSw0NC41NTA1MzQyIEwxOC4yNDU5MDA1LDQ0LjIzMTkzNjggQzIwLjI5 MDY5OTcsNDMuOTEzMzM5NCAyMi44MDczNzU2LDQwLjU2ODA2NjkgMjQuMDY1NzEzNiwzNi4xMDc3 MDM1IEMyNS4xNjY3NTkzLDMyLjEyNTIzNjIgMjUuNjM4NjM2LDI2Ljg2ODM3OTQgMjUuNDgxMzQz OCwyMy42ODI0MDU1IEMyNS40ODEzNDM4LDIxLjc3MDgyMTIgMjQuNTM3NTkwMywxNy42MjkwNTUy IDIzLjEyMTk2MDEsMTMuOTY1MTg1MyBDMjIuMzM1NDk4OSwxMS44OTQzMDIzIDIxLjA3NzE2MDks OS44MjM0MTkzMyAyMC4xMzM0MDc0LDguMzg5NzMxMTEgQzE5LjUwNDIzODQsNi45NTYwNDI4OCAx OS41MDQyMzg0LDMuNzcwMDY5MDQgMTkuMDMyMzYxNywwLjEwNjE5OTEyOCBaIiBpZD0iU2hhcGUi PjwvcGF0aD4KICAgICAgICAgICAgICAgICAgICA8L2c+CiAgICAgICAgICAgICAgICAgICAgPGcg aWQ9InBhdGgyNTQ0XzE4XyIgdHJhbnNmb3JtPSJ0cmFuc2xhdGUoMTcuMzAyMTQ3LCA0MC41OTY0 MTIpIj4KICAgICAgICAgICAgICAgICAgICAgICAgPHBhdGggZD0iTTcuMzkyNzM1NTQsMC4zNDMz NTE3MTMgQzcuMzkyNzM1NTQsMy4wNTE0Mjk0OCA4LjQ5Mzc4MTI2LDYuMzk2NzAyMDEgOC45NjU2 NTc5OSw5LjkwMTI3MzIzIEM5LjI4MDI0MjQ5LDEyLjQ1MDA1MjMgOS4xMjI5NTAyNCwxNS4xNTgx MzAxIDkuMTIyOTUwMjQsMTcuMzg4MzExNyBDOS4xMjI5NTAyNCwyMC4wOTYzODk1IDguMTc5MTk2 NzcsMjQuNzE2MDUxNiA2LjkyMDg1ODgsMjcuMTA1NTMyIEM1LjgxOTgxMzA4LDI2LjYyNzYzNTkg NS4zNDc5MzYzNSwyNS45OTA0NDExIDQuNTYxNDc1MTIsMjUuMDM0NjQ5IEMzLjYxNzcyMTY1LDIz Ljc2MDI1OTQgMi45ODg1NTI2NiwyMi40ODU4Njk5IDIuNTE2Njc1OTMsMjAuODkyODgzIEMyLjA0 NDc5OTE5LDE5Ljc3Nzc5MjEgMS41NzI5MjI0NiwxOC41MDM0MDI2IDEuMjU4MzM3OTYsMTYuOTEw NDE1NyBDMC45NDM3NTM0NzMsMTQuNjgwMjM0IDEuMTAxMDQ1NzIsMTEuMDE2MzY0MSAzLjYxNzcy MTY1LDcuMzUyNDk0MTYgQzUuNTA1MjI4NTksNC40ODUxMTc3IDUuOTc3MTA1MzMsNC4xNjY1MjAz MiA2Ljc2MzU2NjU2LDAuOTgwNTQ2NDgxIEM1LjgxOTgxMzA4LDQuMDA3MjIxNjMgNS4xOTA2NDQx LDQuMTY2NTIwMzIgMy4xNDU4NDQ5MSw2LjcxNTI5OTM5IEMwLjc4NjQ2MTIyOCw5LjQyMzM3NzE1 IDAuNDcxODc2NzM3LDEzLjQwNTg0NDQgMC40NzE4NzY3MzcsMTYuNzUxMTE3IEMwLjQ3MTg3Njcz NywxOC4xODQ4MDUyIDAuOTQzNzUzNDczLDE5LjYxODQ5MzQgMS41NzI5MjI0NiwyMS4wNTIxODE3 IEMyLjIwMjA5MTQ0LDIyLjY0NTE2ODYgMi42NzM5NjgxNywyNC4wNzg4NTY4IDMuNDYwNDI5NCwy NS4xOTM5NDc3IEM0LjcxODc2NzM3LDI3LjEwNTUzMiA2LjI5MTY4OTgyLDI4LjA2MTMyNDEgNy4w NzgxNTEwNSwyOC4yMjA2MjI4IEM3LjA3ODE1MTA1LDI4LjIyMDYyMjggNy4wNzgxNTEwNSwyOC4y MjA2MjI4IDcuMDc4MTUxMDUsMjguMjIwNjIyOCBDNy4wNzgxNTEwNSwyOC4yMjA2MjI4IDcuMDc4 MTUxMDUsMjguMjIwNjIyOCA3LjA3ODE1MTA1LDI4LjIyMDYyMjggTDcuMDc4MTUxMDUsMjguMDYx MzI0MSBDOC40OTM3ODEyNiwyNi40NjgzMzcyIDkuNDM3NTM0NzMsMjQuNzE2MDUxNiA5Ljc1MjEx OTIyLDIzLjEyMzA2NDcgQzEwLjA2NjcwMzcsMjEuMjExNDgwNCAxMC4yMjM5OTYsMTkuMTQwNTk3 NCAxMC4zODEyODgyLDE2Ljc1MTExNyBDMTAuNTM4NTgwNCwxNC44Mzk1MzI3IDEwLjM4MTI4ODIs MTIuMTMxNDU0OSA5LjkwOTQxMTQ3LDkuNDIzMzc3MTUgQzkuMTIyOTUwMjQsNi4yMzc0MDMzMSA3 Ljg2NDYxMjI4LDIuNzMyODMyMDkgNy4zOTI3MzU1NCwwLjM0MzM1MTcxMyBMNy4zOTI3MzU1NCww LjM0MzM1MTcxMyBaIiBpZD0iU2hhcGUiPjwvcGF0aD4KICAgICAgICAgICAgICAgICAgICA8L2c+ CiAgICAgICAgICAgICAgICAgICAgPGcgaWQ9InBhdGgyNTUwXzE4XyIgdHJhbnNmb3JtPSJ0cmFu c2xhdGUoMjQuMzczODM3LCA3LjE0MzY4NykiPgogICAgICAgICAgICAgICAgICAgICAgICA8cGF0 aCBkPSJNMC43OTI5MjI0NTUsMC4zNDMzNTE3MTMgQzAuNzkyOTIyNDU1LDQuMzI1ODE5MDEgMS4x MDc1MDY5NSwxMS42NTM1NTg4IDIuMjA4NTUyNjYsMTQuNTIwOTM1MyBDMi41MjMxMzcxNiwxNS40 NzY3Mjc0IDUuMzU0Mzk3NTgsMTkuNzc3NzkyMSA3LjI0MTkwNDUyLDI1LjAzNDY0OSBDOC42NTc1 MzQ3MywyOC42OTg1MTg5IDguODE0ODI2OTgsMzIuMDQzNzkxNCA5LjEyOTQxMTQ3LDMyLjk5OTU4 MzYgQzEwLjA3MzE2NDksMzcuMzAwNjQ4MiA4Ljk3MjExOTIyLDQ0LjYyODM4ODEgNy4zOTkxOTY3 Nyw1MS40NzgyMzE4IEM2LjYxMjczNTU0LDU1LjE0MjEwMTcgNC4wOTYwNTk2MSw1OS43NjE3NjM4 IDEuMTA3NTA2OTUsNjEuNjczMzQ4MSBMMC40NzgzMzc5NjQsNjIuNzg4NDM4OSBDMi4wNTEyNjA0 Miw2Mi43ODg0Mzg5IDYuMTQwODU4OCw1OC42NDY2NzMgNy41NTY0ODkwMSw1My43MDg0MTM1IEM5 LjkxNTg3MjcsNDUuMjY1NTgyOCAxMC44NTk2MjYyLDQxLjI4MzExNTUgOS43NTg1ODA0NSwzMS44 ODQ0OTI3IEM5LjYwMTI4ODIsMzAuOTI4NzAwNiA5LjI4NjcwMzcxLDI3LjkwMjAyNTQgNy44NzEw NzM1LDI0LjU1Njc1MjkgQzUuODI2Mjc0MzEsMTkuNDU5MTk0NyAyLjgzNzcyMTY1LDE0LjY4MDIz NCAyLjM2NTg0NDkxLDEzLjU2NTE0MzEgQzEuODkzOTY4MTcsMTEuOTcyMTU2MiAwLjk1MDIxNDcw MSw1LjEyMjMxMjQ3IDAuNzkyOTIyNDU1LDAuMzQzMzUxNzEzIEwwLjc5MjkyMjQ1NSwwLjM0MzM1 MTcxMyBaIiBpZD0iU2hhcGUiPjwvcGF0aD4KICAgICAgICAgICAgICAgICAgICA8L2c+CiAgICAg ICAgICAgICAgICAgICAgPGcgaWQ9InBhdGgyNTUyXzE4XyIgdHJhbnNmb3JtPSJ0cmFuc2xhdGUo MjQuMzczODM3LCAwLjAwMDAwMCkiPgogICAgICAgICAgICAgICAgICAgICAgICA8cGF0aCBkPSJN Mi4yMDg1NTI2NiwwLjQ3Nzg5NjA3NiBDMi4wNTEyNjA0Miw0LjQ2MDM2MzM3IDEuODkzOTY4MTcs Ny44MDU2MzU5IDIuNjgwNDI5NCwxMC42NzMwMTI0IEMzLjQ2Njg5MDYzLDE0LjAxODI4NDkgNy43 MTM3ODEyNiwxOC42Mzc5NDcgOS40NDM5OTU5NiwyNC4wNTQxMDI1IEMxMi43NDcxMzMxLDM0LjQw ODUxNzUgMTEuOTYwNjcxOSw0Ny45NDg5MDYzIDkuNDQzOTk1OTYsNTguNDYyNjE5OSBDOC41MDAy NDI0OSw2Mi4xMjY0ODk4IDQuMjUzMzUxODYsNjcuNTQyNjQ1NCAwLjAwNjQ2MTIyNzU4LDY5LjI5 NDkzMSBMMy4xNTIzMDYxNCw3MC4wOTE0MjQ0IEM0Ljg4MjUyMDg0LDcwLjA5MTQyNDQgOS4yODY3 MDM3MSw2NS43OTAzNTk4IDExLjAxNjkxODQsNjEuMDExMzk5IEMxMy44NDgxNzg4LDUzLjUyNDM2 MDUgMTQuMzIwMDU1Niw0NC42MDM2MzM3IDEzLjIxOTAwOTksMzUuMDQ1NzEyMiBDMTMuMjE5MDA5 OSwzNC4wODk5MjAxIDExLjY0NjA4NzQsMjUuOTY1Njg2OCAxMC4yMzA0NTcyLDIyLjYyMDQxNDMg QzguMTg1NjU3OTksMTcuNTIyODU2MSA1LjAzOTgxMzA4LDE0LjAxODI4NDkgMy43ODE0NzUxMiwx MC44MzIzMTEgQzIuODM3NzIxNjUsOC40NDI4MzA2NyAyLjUyMzEzNzE2LDIuMjMwMTgxNjkgMy4x NTIzMDYxNCwwLjc5NjQ5MzQ2IEwyLjIwODU1MjY2LDAuNDc3ODk2MDc2IFoiIGlkPSJTaGFwZSI+ PC9wYXRoPgogICAgICAgICAgICAgICAgICAgIDwvZz4KICAgICAgICAgICAgICAgIDwvZz4KICAg ICAgICAgICAgPC9nPgogICAgICAgIDwvZz4KICAgIDwvZz4KPC9zdmc+ "
+       id="image1098"
+       x="99.816887"
+       y="168.93225" />
+  </g>
+</svg>
diff --git a/summary/src/tlwo/img/repeat-attack.pdf b/summary/src/tlwo/img/repeat-attack.pdf
new file mode 100644
index 0000000..36e2f73
--- /dev/null
+++ b/summary/src/tlwo/img/repeat-attack.pdf
diff --git a/summary/src/tlwo/img/resolve.pdf b/summary/src/tlwo/img/resolve.pdf
new file mode 100644
index 0000000..ff7ab6e
--- /dev/null
+++ b/summary/src/tlwo/img/resolve.pdf
diff --git a/summary/src/tlwo/img/setting.pdf b/summary/src/tlwo/img/setting.pdf
new file mode 100644
index 0000000..aee9012
--- /dev/null
+++ b/summary/src/tlwo/img/setting.pdf
diff --git a/summary/src/tlwo/img/uncached.pdf b/summary/src/tlwo/img/uncached.pdf
new file mode 100644
index 0000000..2a83a17
--- /dev/null
+++ b/summary/src/tlwo/img/uncached.pdf
diff --git a/summary/src/tlwo/main.tex b/summary/src/tlwo/main.tex
new file mode 100644
index 0000000..09110c4
--- /dev/null
+++ b/summary/src/tlwo/main.tex
@@ -0,0 +1,69 @@
+\begin{kaupaper}[
+    author={%
+      \textbf{Rasmus Dahlberg} and
+      Tobias Pulls
+    },
+    title={%
+      Timeless Timing Attacks and Preload Defenses in Tor's DNS Cache
+    },
+    reference={%
+      USENIX Security (2023)
+    },
+    summary={%
+      Tor relays cache resolved domains with constant time-to-live values not to
+      reveal information about past exit traffic while boosting performance.  We
+      show that this caching strategy and its implementation in the live Tor
+      network can be exploited by a \emph{timeless timing attack} that leaks if a
+      domain is (not) cached.  Further, the time that a domain was inserted into
+      the cache can be inferred by repeated probes.  Our attack prototype's
+      experimental evaluation in real conditions shows that there are neither
+      false positives nor false negatives (10M~repetitions).  Thus, it is useful
+      for instantiating a real-world website oracle without requiring any special attacker
+      capabilities or reach (just a modest computer that can create a Tor
+      circuit).  One of our mitigations has been merged in Tor: probabilistic
+      time-to-live values that make the time-of-insertion fuzzy.  Long-term,
+      Tor's DNS cache could be redesigned to \emph{preload} the same domains at all
+      exits.  Such preloading would eliminate all (timeless) timing attacks in
+      Tor's DNS cache because the same domains would always be (un)cached across
+      different circuits.  To retain performance within the same circuit, we
+      propose that the preloaded domains should be complemented by a dynamic
+      same-circuit cache that is not shared across circuits.  Our
+      four-month-long DNS cache measurement at two 100~Mbit/s exit relays
+      informs on today's baseline performance.  It is compared to a preloaded
+      DNS cache based on different variations of three popularity lists: Alexa,
+      Tranco, and Umbrella.  A preloaded DNS cache can be as performant as today
+      with similar resource usage or significantly improve cache-hit ratios by
+      2-3x. However, the increased cache-hit ratios have the cost of modest
+      increases in memory and resolver load.
+    },
+    participation={\vspace{-.25cm}
+      Tobias and I collaborated closely from start to finish with the following
+      exceptions.  I did most implementation work.  Volunteers from DFRI---a
+      Swedish non-profit and non-partisan organization that promotes digital
+      rights---operated our exit relays.  Tobias did most DNS cache data
+      analysis.  Tobias also had the initial idea, which was refined with
+      feedback~from~Roger~Dingledine.
+    },
+    label={
+      paper:tlwo
+    },
+]
+  \maketitle
+  \begin{abstract}
+    \input{src/tlwo/src/abstract}
+  \end{abstract}
+
+  \input{src/tlwo/src/introduction}
+  \input{src/tlwo/src/background}
+  \input{src/tlwo/src/tor-cache}
+  \input{src/tlwo/src/attack}
+  \input{src/tlwo/src/short}
+  \input{src/tlwo/src/long}
+  \input{src/tlwo/src/related}
+  \input{src/tlwo/src/conclusion}
+  \input{src/tlwo/src/acknowledgements}
+  \input{src/tlwo/src/availability}
+  
+  \bibliographystyle{plain}
+  \bibliography{src/tlwo/src/ref}
+\end{kaupaper}
diff --git a/summary/src/tlwo/src/abstract.tex b/summary/src/tlwo/src/abstract.tex
new file mode 100644
index 0000000..df4fa1b
--- /dev/null
+++ b/summary/src/tlwo/src/abstract.tex
@@ -0,0 +1,25 @@
+\noindent
+We show that Tor's DNS cache is vulnerable to a timeless timing attack, allowing
+anyone to determine if a domain is cached or not  without any false positives.
+The attack requires sending a single TLS record. It can be repeated to determine
+when a domain is no longer cached to leak the insertion time.  Our evaluation in
+the Tor network shows no instances of cached domains being reported as uncached
+and vice versa after 12M repetitions while only targeting our own domains. This
+shifts DNS in Tor from an unreliable side-channel---using traditional timing
+attacks with network jitter---to being perfectly reliable.  We responsibly
+disclosed the attack and suggested two short-term mitigations.
+
+As a long-term defense for the DNS cache in Tor against all types of (timeless)
+timing attacks, we propose a redesign where only an allowlist of domains is
+preloaded to always be cached across circuits.  We compare the performance of a
+preloaded DNS cache to Tor's current solution towards DNS by measuring
+aggregated statistics for four months from two exits (after engaging with the
+Tor Research Safety Board and our university ethical review process). The
+evaluated preload lists are variants of the following top-lists: Alexa, Cisco
+Umbrella, and Tranco. Our results show that four-months-old preload lists can be
+tuned to offer comparable performance under similar resource usage or to
+significantly improve shared cache-hit ratios (2--3x) with a modest increase in
+memory usage and resolver load compared to a 100 Mbit/s exit.  We conclude that
+Tor's current DNS cache is mostly a privacy harm because the majority of cached
+domains are unlikely to lead to cache hits but remain there to be probed by
+attackers.
diff --git a/summary/src/tlwo/src/acknowledgements.tex b/summary/src/tlwo/src/acknowledgements.tex
new file mode 100644
index 0000000..84302c0
--- /dev/null
+++ b/summary/src/tlwo/src/acknowledgements.tex
@@ -0,0 +1,20 @@
+\section*{Acknowledgments}
+Many thanks to
+  Georg Koppen and
+  Marc Juarez
+for engaging with us in continuous Tor Research Safety Board discussions, as
+well as
+  Elias Rudberg,
+  Johan Nilsson, and
+  Linus Nordberg
+who operated our modified Tor relays at the premises of DFRI.
+We would further like to thank our shepherd, the anonymous reviewers,
+  Mike Perry,
+  Nick Mathewson,
+  Paul Syverson, and
+  Roger Dingledine
+for their valuable feedback.
+The authors were supported by
+  Mullvad VPN,
+  the Swedish Foundation for Strategic Research, and
+  the Swedish Internet Foundation.
diff --git a/summary/src/tlwo/src/attack.tex b/summary/src/tlwo/src/attack.tex
new file mode 100644
index 0000000..542cdb3
--- /dev/null
+++ b/summary/src/tlwo/src/attack.tex
@@ -0,0 +1,247 @@
+\section{Timeless Timing Attack} \label{tlwo:sec:attack}
+
+Past work demonstrated timing attacks against Tor's DNS cache~\cite{wfwo}. In
+short, anyone can observe the latency of a domain lookup to determine if it is
+more or less likely that an answer is (not) cached.  A quick response is more
+likely to be cached, thereby leaking information about past traffic on an exit.
+A downside of such a remote timing attack is that it is subject to network
+jitter while traversing hops in the Tor network.  We show how to bypass this
+limitation by constructing a timeless timing attack that is immune to network
+jitter~\cite{timeless}.  Notably the attack only requires Internet access and a
+very modest computer.
+
+Section~\ref{tlwo:sec:attack:detailed} outlines the attack, followed by a description
+of our prototype implementation in Section~\ref{tlwo:sec:attack:prototype},
+evaluation in Section~\ref{tlwo:sec:attack:measurements}, as well as ethical
+considerations in Section~\ref{tlwo:sec:attack:ethical}.
+
+\subsection{Detailed Description} \label{tlwo:sec:attack:detailed}
+An exit's processing of an incoming RESOLVE cell depends on if an answer is
+cached or not, see Figure~\ref{tlwo:fig:resolve}.  An answer may already be available
+and a RESOLVED cell can be scheduled for sending immediately (``cached'').
+Otherwise an answer is not yet available and a resolve process needs to take
+place concurrently to avoid blocking (``uncached''). We construct a timeless
+timing attack by exploiting the fact that scheduling RESOLVED cells for sending
+with different concurrent timings depend on if an answer is cached (send
+immediately) or uncached (send based on an event later on)~\cite{ctor-1}.
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=.67\columnwidth]{src/tlwo/img/resolve}
+	\caption{%
+		Processing of an incoming RESOLVE cell at an exit relay.
+		Answers of concurrent resolves are triggered by events.
+	}
+	\label{tlwo:fig:resolve}
+\end{figure}
+
+\subsubsection{Attack Outline}
+
+Suppose that we craft two RESOLVE cells for \texttt{example.com} and
+\texttt{evil.com} such that they are processed by an exit \emph{directly after
+each other without any events in between}.  Further suppose that
+\texttt{evil.com} is cached.  The first RESOLVE cell is \texttt{example.com}.
+The second RESOLVE cell is \texttt{evil.com}.  Following from the flow in
+Figure~\ref{tlwo:fig:resolve}, we can determine if \texttt{example.com} is (un)cached
+by observing only the order in which the two RESOLVED cells come back.  The
+order will be switched if \texttt{example.com} needs concurrent resolving
+because \emph{the answer is not available until after an event} (uncached).
+Otherwise the order is preserved (cached).  Sending two requests to be processed
+at the same time and exploiting concurrency as well as differences in processing
+time that affects the response order is what makes it
+\emph{timeless}~\cite{timeless}.
+
+Figure~\ref{tlwo:fig:timeless} provides a detailed description on how to satisfy the
+presumed setup.  The attacker starts by looking up its own domain name for a
+selected exit.  This ensures that \texttt{evil.com} is cached. Next, two RESOLVE
+cells are sent in the same TLS record from a hop proceeding the exit. Both cells
+will be unpacked at the same time by TLS~\cite{ctor-2},
+% Note: input parameter at_most is set to -1 by tor's main loop
+and when processing starts all available cells will be handled before giving
+control back to Tor's main loop~\cite{ctor-3}.
+Now recall that Tor is single-threaded.  An event from any concurrent DNS
+resolve can thus not be completed before all unpacked cells were fully
+processed.  This ensures that the order in which our two RESOLVED cells come
+back in is guaranteed to leak if \texttt{example.com} is (un)cached as long as
+both RESOLVE cells arrived together in-order and \texttt{evil.com} is really
+cached.
+
+\begin{figure}[!t]
+	\centering
+	\subfloat[][uncached]{%
+		\includegraphics[width=.7\columnwidth]{src/tlwo/img/uncached}
+		\label{tlwo:fig:timeless:a}
+	}\\
+	\subfloat[][cached]{%
+		\includegraphics[width=.7\columnwidth]{src/tlwo/img/cached}
+		\label{tlwo:fig:timeless:b}
+	}
+	\caption{%
+		The attacker ensures a domain \texttt{evil.com} is cached. Next, two
+		RESOLVE cells are sent to arrive at the same time in-order.  The relay
+		processes both cells before triggering any resolve event.  This means
+		that answers can only be sent directly if no resolving is needed.  The
+		order of RESOLVED cells switch if \texttt{example.com} is uncached.
+		Otherwise the order is preserved. }
+	\label{tlwo:fig:timeless}
+\end{figure}
+
+It should be noted that an attacker can gain full control of how their TLS
+records are packed to exits by either running a modified Tor relay or creating
+one-hop circuits.  In practise, it is also possible to omit the step of caching
+\texttt{evil.com} and instead send a \texttt{RESOLVE} cell containing an IP
+address.  Tor will simply echo the IP as if it was cached~\cite{ctor-4}.  We
+describe the attack without this optimization because it is more general.
+
+\subsubsection{Repeated Attack to Learn Insertion Time}
+So far we described how to determine if a domain is (un)cached at an exit.
+Figure~\ref{tlwo:fig:attack-repeated} shows how to derive the exact time that a
+domain was added to an exit's DNS cache.  First determine whether the domain's
+TTL will be clipped to 300 or 3,600 seconds by observing the TTL returned from
+the authoritative name server or the configured resolvers of the
+exit~\cite{GreschbachPRWF17}.  Then repeat the timeless timing attack
+periodically until the domain is no longer cached, say, once per second. Suppose
+the expected clip is 300 seconds and the attack started at time $t$.  If it
+takes $x < 300$ seconds for the entry to become uncached, it was added to the
+exit's DNS cache at time $t+x - 300\textrm{s}$.  Observing $x > 300$ seconds
+means that a different party inserted the entry into the cache between probes
+(may happen for some of the most frequently looked-up domains, depending on
+probing frequency).  To recover, the attacker can perform the same steps again
+until they succeed.  For example, with two tries the initial insertion happened
+at $t+x - 600\textrm{s}$. Notably these estimates cannot be more precise than
+the attacker's repetition interval.
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=.53\columnwidth]{src/tlwo/img/repeat-attack}
+	\caption{%
+		Repeated timeless timing attack to infer the exact time that a domain
+		was cached by someone at an exit relay.  For example, if the expected
+		clip is 300s ($\mathsf{ttl}\le300$s), the attack is repeated every
+		second, and the observed $x$ is 40s, then caching of
+		\texttt{example.com} happened at time $\approx t-260$s. }
+	\label{tlwo:fig:attack-repeated}
+\end{figure}
+
+\subsubsection{Discussion}
+While an attacker can determine if a domain is cached by an exit and if so the
+exact time it was added, the attacker cannot determine the number or timings of
+lookups for a domain after entering the cache.  In isolation, the attacker also
+cannot determine which identifiable user cached a given domain.
+
+It is easy to conduct the attack in parallel because
+probing for the status of \texttt{foo.org} is completely independent from
+\texttt{bar.org} at the same relay as well as other probes on different relays.
+In other words, an attacker can probe a single domain on all exits
+simultaneously, many different domains at a single exit, or both.  Network-wide
+probes for the same domain may be detectable by observing the DNS caches of
+multiple relays and correlating their contents. However, note that a risk-averse
+attacker~\cite{AumannL07} may spread their probes over time (five or sixty
+minutes) and domains (expected twelve domains per website on Alexa top-1M
+websites~\cite{GreschbachPRWF17}), if the goal is to confirm a website visit.
+
+An example use-case for a parallel attack is answering network-wide queries, for
+example, ``is \texttt{foo.org} visited more frequently than \texttt{bar.org}, or
+did any Tor user visit \texttt{baz.org} at a particular point in time?'' The
+latter is an instantiation of a so-called website oracle~\cite{wfwo}.  Website
+oracles remove virtually all false positives in WF attacks for all but the most
+popular websites on the web, and WF attacks may connect identifiable users with
+visited websites.  See Figure~\ref{tlwo:fig:setting} in
+Section~\ref{tlwo:sec:introduction} for an overview of this attack setting.
+
+\subsection{Prototype Implementation} \label{tlwo:sec:attack:prototype}
+
+We prototyped our timeless timing attack so that it runs for a given exit and a
+list of domains.  Figure~\ref{tlwo:fig:attack} shows the overall setup which consists
+of \texttt{carml},
+\texttt{tor-resolve}, a locally patched Tor process, and a Python script
+automating the entire setup. First Tor is started, a \emph{one-hop circuit} is
+built to the selected exit, and all streams are attached to it using
+\texttt{carml}.  Next, \texttt{tor-resolve} is used to send a special lookup
+query for \texttt{example.com} by simply appending a magic string
+\texttt{---sc}.  The patched Tor process splits such requests into two RESOLVE
+cells in the same TLS record: one for the specified domain, and another one that
+is guaranteed to not need any concurrent resolving. Finally Tor sets the output
+to \texttt{0.0.0.0} if the resulting RESOLVED cells switched order, otherwise
+\texttt{1.1.1.1} (arbitrary constants).
+After processing all domains Tor is closed and the output
+is a list where each item is zero (uncached), one (cached), or negative
+(unknown, e.g., due to a resolve timeout, a stream attach failure, or a vanished
+circuit).
+The complete attack required less than 100 lines of C to patch Tor, as well as
+200 lines of Python to make it fully automated.
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=.53\columnwidth]{src/tlwo/img/attack}
+	\caption{%
+		Local attack setup consisting of \texttt{carml} to build one-hop
+		circuits, \texttt{tor-resolve} to inject queries, and a patched
+		tor process that transforms them into timeless timing attacks.
+	}
+	\label{tlwo:fig:attack}
+\end{figure}
+
+\subsection{Network Measurements} \label{tlwo:sec:attack:measurements}
+
+We conducted measurements in the live Tor network to evaluate the reliability of
+our prototype with four parallel instances of
+the setup in Figure~\ref{tlwo:fig:attack} on a system with an Intel(R) Xeon(R) CPU
+E5-2630 @ 2.30GHz and 4GB of DRAM. All targeted domains were our own, see
+ethical considerations in Section~\ref{tlwo:sec:attack:ethical}. In total there were
+$14,446$ runs between May 17--26, 2022.  Each run used an exit that was sampled
+uniformly at random.  Assuming $1,000$ exits at all times (conservative), the
+individual select probability should not exceed $0.004$ per run.  Each run
+performed up to $1,000$ timeless timing attacks, chunked into $500$ attacks per
+circuit and alternating between uncached and cached lookups by specifying a
+unique domain twice in a row: \texttt{<counter>.<timestamp>.<instance
+id>.example.com}. The maximum runtime was set to ten minutes.  Each query also
+had a ten second timeout.  In the advent of errors like circuit failure or
+timeouts, the remainder of the run was canceled but all results up until that
+point were collected.  The average number of DNS requests leaving the Tor
+network from \emph{all four combined instances} was $8.6$ per second.  The
+effective queries per second was slightly higher due to brief pauses while
+setting up a new run.  For reference, Sonntag reported in 2018 that the DNS
+resolver of an exit with $200$Mbit/s received an average and maximum of $18$ and
+$81$ requests per second~\cite{sonntag-metrics}. Earlier,
+Figure~\ref{tlwo:fig:lookups} also showed significant variability in lookups.
+Handling our per-exit overhead during a couple of minutes should thus be
+insignificant when compared to regular patterns for DNS traffic in the network.
+
+Table~\ref{tlwo:tab:attack} summarizes our results.  After 12M timeless timing
+attacks, there were no cases of uncached lookups being reported as cached and
+vice versa.  This is consistent with the description in
+Section~\ref{tlwo:sec:attack:detailed}: neither false positives nor false negatives
+are expected.  The observed probability to not get an answer due to
+detectable failures were $0.00025$.
+
+\begin{table}[!t]
+	\centering
+	\caption{%
+		Timeless timing attack results.  Neither false negatives nor
+		false positives were observed with 6M repetitions each.
+	}
+	\begin{tabular}{c|ccc}
+		Type       & Got uncached & Got cached  & Failures \\
+		\hline
+		Uncached   & $6,034,779$  & $0$         & $2,858$  \\
+		Cached     & $0$          & $6,034,594$ & $142$    \\
+	\end{tabular}
+	\label{tlwo:tab:attack}
+\end{table}
+
+\subsection{Ethical Considerations} \label{tlwo:sec:attack:ethical}
+
+We responsibly disclosed our attack to the Tor Project through their security
+list. The submitted disclosure included a theoretical attack description, a
+prototype implementation with measurements showing how reliable it was, as well
+as a sketch of short-term and long-term defenses. As part of our dialog, we also
+coordinated with the Tor Project on submitting this paper to USENIX Security to
+get peer review.
+
+The conducted network measurements targeted domains under our own control. This
+ensured that we did not learn anything about real Tor users.  Performance
+overhead on exits and the Tor network at large was also modest, see
+Section~\ref{tlwo:sec:attack:measurements}.  In other words, the downsides were
+negligible while the significance of evaluating \emph{real-world reliability}
+was helpful to inform and motivate the need for mitigations and defenses.
diff --git a/summary/src/tlwo/src/availability.tex b/summary/src/tlwo/src/availability.tex
new file mode 100644
index 0000000..cff4dbc
--- /dev/null
+++ b/summary/src/tlwo/src/availability.tex
@@ -0,0 +1,19 @@
+\section*{Availability}  \label{tlwo:sec:availability}
+We make the following three artifacts available:
+
+\begin{enumerate}
+    \item Patches to Tor, associated scripts and data, and documentation for
+    performing timeless timing attacks.
+    \item The measurement data from our two exits, a detailed timeline of
+    operations, scripts for creating extended preload lists, and associated
+    Python scripts for parsing all stats and generating figures.
+    Sharing of the dataset was discussed as part of the contact with the Tor
+    Research Safety Board and our university ethical review process. Relevant
+    parts of our research safety board contact are included in our artifact.
+    \item Contributions to the Tor Project, including source code and associated
+    tooling for our Fuzzy TTLs mitigation and preload defense.
+\end{enumerate}
+
+See
+\url{https://gitlab.torproject.org/rgdd/ttapd}
+to locate the above.
diff --git a/summary/src/tlwo/src/background.tex b/summary/src/tlwo/src/background.tex
new file mode 100644
index 0000000..719dec6
--- /dev/null
+++ b/summary/src/tlwo/src/background.tex
@@ -0,0 +1,73 @@
+\section{Background} \label{tlwo:sec:background}
+The remainder of the paper requires preliminaries about DNS
+(Section~\ref{tlwo:sec:background:dns}), in particular in relation to Tor
+(Section~\ref{tlwo:sec:background:tor}).
+
+\subsection{DNS} \label{tlwo:sec:background:dns} DNS is a hierarchical system that
+maps domain names (``domains'') to IP addresses.  The hierarchy is composed of
+root servers, top-level domain (TLD) servers, and authoritative name servers.
+Root servers are aware of TLD servers like \texttt{.com}.  TLD servers are aware
+of authoritative name servers in their zone like \texttt{example.com}.
+Authoritative name servers are aware of the actual answers to a domain lookup.
+A domain lookup for \texttt{example.com} involves asking the root server for the
+TLD server of \texttt{.com}; the TLD server for the authoritative name server of
+\texttt{example.com}; and finally the authoritative name server for the IP
+address of \texttt{example.com}.  The resolve process is typically performed
+iteratively in plaintext over UDP by a third-party resolver that caches
+responses, e.g., to improve performance.  The default is usually to rely on ISP
+DNS resolvers.  It is also possible to configure other ones, e.g., Google's
+\texttt{8.8.8.8} or self-hosted using \texttt{unbound}, \texttt{bind}, etc.
+
+Of note is that the resolved domains are associated with a Time To Live (TTL)
+value.  As the name suggest, it is the amount of time that a resolved domain
+should be considered fresh.  TTL values are sometimes overridden in caches to
+improve reliability~\cite{rfc8767,MouraHMSD18} or preserve
+privacy~\cite{GreschbachPRWF17}.
+
+\subsection{Tor} \label{tlwo:sec:background:tor}
+The Tor network is composed of thousands of relays that route encrypted traffic
+on behalf of millions of daily users~\cite{tor,ManiWJJS18}.  Ordinary uses of
+Tor include preserving privacy, safety and freedom as well as facilitating
+dissent and circumventing censorship~\cite{tpo-russia,tpo-who-uses-tor}.  Access
+to the Tor network is easy using Tor Browser (TB), which is configured to proxy
+all traffic through a local Tor process that takes care of routing.  TB adds
+many other protections that are orthogonal to our work~\cite{tb}.
+
+During a regular website visit a circuit is built through a guard, middle, and
+exit relay. The first relay is fixed in a small guard set that rarely changes
+once selected, while the middle and exit relays are randomly selected weighted
+by bandwidth for each new circuit.  A circuit may have many streams (analogous
+to TCP/IP connections), typically corresponding to separate flows for a
+particular destination.  Control traffic and data is transported through the
+network in fixed-size cells that are encrypted in layers.  At each hop in a
+circuit, one layer of encryption is peeled-off. Outstanding cells from relay A
+to relay B are sent in a shared channel that is TLS protected.  Public keys,
+relay identities, and more are discovered in Tor's consensus, which is secure if
+a threshold of trusted directory authorities act honestly.
+
+We are particularly interested in how Tor interacts with DNS.  To look up a
+domain, the user's Tor process may send a RESOLVE cell that requests resolution
+by the exit.  Some exits are configured with their own iterative resolvers,
+while others rely on DNS from their ISP or other
+third-parties~\cite{GreschbachPRWF17}.  The answer to a lookup is stored in the
+exit's cache, but with the TTL \emph{clipped} to 300 or 3600 seconds depending
+on if the TTL is $\le 300$ seconds or not.  A RESOLVED cell is then sent to the
+user, who only gets to see the clipped TTL regardless of how long it has been
+stored in the cache to avoid leaking information about past exit traffic (like
+the insertion time which would be trivial to infer from a counted-down TTL).  If
+too many entries are added to Tor's DNS cache and memory becomes a scarce
+resource, an Out-Of-Memory (OOM) job deletes domains until freeing enough
+memory.  This is all controlled by an event-driven single-threaded main loop.
+
+Of further note is that TB is based on Firefox.  As part of connecting to a
+website, DNS is handled transparently through a SOCKS proxy provided by the
+local Tor process. Requests to connect to a domain through the SOCKS proxy
+results in the user's Tor process sending a BEGIN cell to establish a connection
+to the destination, which in turn triggers domain resolution at the exit.  In
+other words, there are two ways to look up domains: RESOLVE cells and BEGIN
+cells.  At no point is any resolved IP address cached in TB or in the user's Tor
+process.  This prevents shared state (the cache) from being used to
+fingerprint a user's activity across different circuits.
+
+We continue our introduction to Tor's DNS cache next while describing the
+first measurement of its performance.
diff --git a/summary/src/tlwo/src/conclusion.tex b/summary/src/tlwo/src/conclusion.tex
new file mode 100644
index 0000000..485c593
--- /dev/null
+++ b/summary/src/tlwo/src/conclusion.tex
@@ -0,0 +1,52 @@
+\section{Conclusion} \label{tlwo:sec:conclusion} 
+Our timeless timing attack on Tor's DNS cache is virtually perfect,
+significantly improving over earlier timing attacks~\cite{wfwo}. Based on 12
+million measurements in the live Tor network, we only observed a 0.00025 failure
+rate due to vanished circuits and other transient networking errors that are
+easy to account for. We responsibly disclosed the attack to the Tor Project
+and coordinated the process around defenses with them.
+
+Our proposed mitigations are just that---mitigations---and do not completely
+address the underlying issues. The fuzzy TTLs mitigation primarily addresses
+confirmation with WF attacks involving moderately popular domains. Cover
+lookups, while valuable if done, does not scale and requires continuous efforts
+that are not easily automated on a large scale.
+
+Setting out to find long-term solutions, we landed in redesigning Tor's DNS
+cache completely with a preload design. To inform the design and to evaluate its
+feasibility, we ran a four-month experiment starting in May 2022 measuring key
+performance metrics. To ensure that our measurements were safe, we repeatedly
+consulted the Tor Research Safety Board and completed our university ethical
+review process. We received positive feedback as well as invaluable suggestions
+along the way to minimize any potential harm to the Tor network and its users.
+
+First, the preload design is immune to timing and timeless attacks due to never
+sharing any data in the DNS cache injected due to user activity across circuits.
+Secondly, the preload lists of domains based on extended Alexa, extended Tranco,
+and Cisco Umbrella all show impressive cache-hit ratios. Depending on list, it
+is possible to get comparable cache-hit ratios, memory usage, and resolver load
+as Tor today. More extensive lists can trade modest increases in memory and
+resolver load with significantly higher cache-hit ratios, especially for web
+traffic. Important future work is improving how the extended lists are
+generated---e.g., by tailoring them specifically for relays in certain regions
+(location sensitivity), excluding unique tracking domains, or crawling websites
+to discover subdomains---which is likely to lead to higher cache-hit ratios and
+smaller lists.
+
+One of the biggest downsides of the preload design is that the most effective
+preload lists are extended lists based on Alexa or Tranco, requiring continuous
+efforts to update. Fortunately, our measurements show that even four-month-old
+extended lists remain effective with significant improvement over baseline Tor.
+It is likely feasible for the Tor Project to generate and ship hard-coded
+preload lists as part of regular Tor releases and still improve performance
+compared to today.
+
+Like Mani \emph{et~al.}~\cite{ManiWJJS18}, we see that traffic in the Tor
+network appears to reasonably match website/domain popularity lists like Alexa,
+Tranco, and Umbrella. This is fundamental for the preload design, and likely
+also a contributing factor for the observed long stability of the extended
+preload lists, since the most popular sites see relatively little
+churn~\cite{PochatGJ19}. Finally, our measurements indicate that the Tor network
+has grown by about 300\% in terms of number of streams since 2018, and that the
+large majority of Tor's current DNS caching is a privacy harm rather than a
+cross-circuit performance boost.
diff --git a/summary/src/tlwo/src/introduction.tex b/summary/src/tlwo/src/introduction.tex
new file mode 100644
index 0000000..04dd6bc
--- /dev/null
+++ b/summary/src/tlwo/src/introduction.tex
@@ -0,0 +1,151 @@
+\section{Introduction} \label{tlwo:sec:introduction}
+Tor~\cite{tor} is a volunteer-operated anonymity network composed of relays that
+route encrypted traffic with low latency.
+One of Tor's trade-offs is to not provide anonymity against a global passive
+attacker that observes traffic as it enters and leaves the
+network~\cite{trilemma,tor}.
+A typical attacker setting is therefore to only observe encrypted traffic as it
+enters the network from an identifiable user, forcing traffic analysis of the
+encrypted packets to classify the user's behavior.  An attacker that tries to
+classify visited websites is said to perform Website Fingerprinting
+(WF)~\cite{cheng1998traffic,HerrmannWF09,Hintz02,DBLP:conf/ccs/LiberatoreL06,PanchenkoNZE11,DBLP:conf/sp/SunSWRPQ02}.
+Many questions about the practicality of WF attacks have been raised, ranging
+from how to keep a trained dataset updated to managing false
+positives~\cite{onlinewf,JuarezAADG14,perryCrit,realistic}. False positives in
+WF may be ruled out using side-channels~\cite{JuarezAADG14,wfwo}.  For example,
+an attacker with access to (traffic to~\cite{SibyJDVT20}) Google's public DNS
+resolver can use it to confirm if a website visit really happened over
+Tor~\cite{GreschbachPRWF17}.
+
+Side-channels that leak information about exiting traffic are in fact
+many~\cite{wfwo}.  For example, during the course of a website visit there may
+be interactions with DNS resolvers, OCSP responders, real-time bidding
+platforms, and CDNs.  An attacker that is able to query or gain access to the
+resulting datasets learns partial information about destination traffic, notably
+without ever observing any of the exiting TCP flows typically associated with
+correlation attacks on Tor~\cite{JohnsonWJSS13,deepcorr}.  Depending on the ease
+of accessibility (e.g., does it require Google reach), reliability (e.g., are
+there any false positives), and coverage (e.g., is it only applicable for a
+small fraction of exit traffic), the impact of a given side-channel will be more
+or less urgent to address with mitigations and/or defenses~\cite{tor}.
+
+\subsection{Timeless Timing Attacks in Tor's DNS}
+Timing attacks exploit that an operation takes more or less time to execute
+depending on something secret.  The attacker's goal is to infer the secret
+information by merely observing the non-constant execution times, e.g., to
+recover a private key~\cite{timing-attack}, decrypt a ciphertext~\cite{lucky13},
+or check if a domain is cached by a Tor exit~\cite{wfwo}.  A remote timing
+attack takes place over a network.  Repeated measurements and statistics are
+usually required to account for network jitter, which adds noise to the observed
+timings~\cite{remote-timing-attacks}.  Van Goethem~\emph{et~al.}~\cite{timeless}
+proposed a technique that eliminates all network jitter in remote attacks.  It is applicable if
+two requests can be sent to arrive at the same time, request processing is
+concurrent, and the order in which responses are returned reflects differences in
+execution time.
+
+We find that Tor's DNS cache at exits fulfills all three criteria of a timeless
+timing attack, allowing anyone to determine if a domain is cached or not by
+sending a single TLS record.  The attack is reliable (neither false positives
+nor negatives), confirmed by using our prototype to make 12M network
+measurements against our own domains.  The attack is also repeatable, making the
+exact time that a domain was inserted into the cache inferable due to
+determinism in Tor's TTL logic.
+
+Figure~\ref{tlwo:fig:setting} provides a summary of how the ability to infer whether
+domains are (un)cached at exits make WF attacks more practical.
+The attacker observes encrypted traffic from a client
+to a guard relay at time $t$, classifying the network trace as associated with
+\texttt{foo.org}.  The attacker then conducts timeless timing attacks against
+all exits in the Tor network to determine if \texttt{foo.org} was really visited
+by \emph{someone} at time $t$.  If the answer is yes the classification is
+accepted, otherwise it is rejected.  Prior work by Pulls and Dahlberg show that
+the capability to determine whether a website was visited from Tor at time $t$
+removes virtually all false positives in WF attacks for all but the most popular
+websites on the web~\cite{wfwo}.  We provide further evidence that this is a
+realistic capability to assume by demonstrating that \emph{any attacker with an
+Internet connection could have used it in attacks for the last two decades}.
+While it is a powerful capability to eliminate false positives, the overall
+success in linking users with their website visits also depends on the WF
+attack~\cite{onlinewf,JuarezAADG14,perryCrit,realistic}.
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=0.67\columnwidth]{src/tlwo/img/setting}
+	\caption{%
+		WF with an attacker that rules out false positives by checking
+		that the expected DNS records were cached at the right time by
+		conducting timeless timing attacks against exits.
+	}
+	\label{tlwo:fig:setting}
+\end{figure}
+
+\subsection{Preload Defenses and Measurements}
+Patching Tor's DNS cache to resist (timeless) timing attacks is challenging
+without hurting performance.  For example, making all DNS lookups constant time
+would defeat the purpose of having a cache.  The idea of our long-term defense
+is to remove harmful cross-circuit caching that is unlikely to boost performance
+while still safely caching useful domains.  The Tor-network measurements of Mani
+\emph{et~al.}~\cite{ManiWJJS18} tell us that web-traffic from the Tor network
+matches that of the rest of the Internet, following popularity lists like
+Alexa~\cite{alexa}. What should boost cross-circuit performance is the upper
+parts of a representative popularity list; not the long tail of infrequently
+visited sites. This is the intuition of our defense.  Preload a list of popular
+domains that are cached and continuously refreshed by all exits.  A domain name
+is either always cached as part of the preload list or not shared across
+circuits at all.
+
+We conduct four months of measurements in the live Tor network to evaluate 400
+popularity lists derived from Alexa~\cite{alexa}, Cisco
+Umbrella~\cite{umbrella}, and Tranco~\cite{tranco}.  To put our results into
+perspective, we also measure a baseline of Tor's current DNS cache performance.
+The measurement method is to collect aggregated counters every 15 minutes, e.g.,
+the number of lookups cache-hits, and memory overhead, from two 100 Mbit/s
+relays with web and permissive exit port policies.
+
+Tor's mean \emph{cross-circuit} cache-hit ratio is currently 11\% (web) and 17\%
+(permissive).  Variants of Alexa/Tranco top-200 (web) and Alexa/Tranco top-700
+(permissive) achieve the same cross-circuit cache-hit ratios.  A preload list
+from the top-10k can achieve 2--3 times higher cross-circuit cache-hit ratios at
+the cost of at most 60 MiB memory and some increased resolver load (manageable
+in part due to RFC 8767~\cite{rfc8767}).  Throughout the entire measurement we
+noted only a slight decline in effectiveness while using stale preload lists
+(i.e., when using four-month-old lists at the end). This adds to the feasibility
+of using preload lists, as in practice someone has to assemble and deliver them
+to all exits in the Tor network.
+
+\subsection{Contributions and Outline}
+Our contributions are as follows:
+
+\begin{itemize}
+	\item Performance measurements of the DNS cache in Tor over four months from
+	two exits, showing an average 80--83\% cache-hit ratio with approximately
+	10,000 entries in the cache; around 11--17\% of the observed cache hits are
+	due to the cache being shared across circuits, and the number of lookups
+	appears weakly correlated with exit probability
+	(Section~\ref{tlwo:sec:torcache}).
+	\item Demonstration of a timeless timing attack that probes for cached
+		domains in Tor's DNS cache without any false positives or false
+		negatives after 12M repetitions against our own domain in the Tor
+		network (Section~\ref{tlwo:sec:attack}).
+	\item Mitigations based on fuzzy TTLs and cover lookups that add some
+		limited short-term protections (Section~\ref{tlwo:sec:short}).
+	\item A long-term redesign of Tor's DNS cache that defends against
+		(timeless) timing attacks.  Cache-hit ratios can be tuned to offer
+		comparable performance under similar resource usage as today or to
+		significantly improve shared cache-hit ratios (2--3x) with a modest
+		increase in memory usage and resolver load, notably invariant to
+		exit probability as preload lists are fixed (Section~\ref{tlwo:sec:long}).
+\end{itemize}
+
+Section~\ref{tlwo:sec:background} provides necessary background on DNS and Tor,
+Section~\ref{tlwo:sec:related} discusses related work, and
+Section~\ref{tlwo:sec:conclusion} offers conclusions, followed by the availability of
+our research artifacts.
+
+We would like to highlight that Sections~\ref{tlwo:sec:torcache:ethics},
+\ref{tlwo:sec:attack:ethical}, and \ref{tlwo:sec:long:preload:ethics} describe ethical and
+safety precautions to ensure that no users were harmed by our research and to
+maximize its positive impact. We responsibly disclosed our timeless timing
+attack to the Tor Project and engaged with the Tor Research Safety Board as well
+as our university's ethical review process as part of performing network
+measurements to inform our defenses.
diff --git a/summary/src/tlwo/src/long.tex b/summary/src/tlwo/src/long.tex
new file mode 100644
index 0000000..16331ac
--- /dev/null
+++ b/summary/src/tlwo/src/long.tex
@@ -0,0 +1,473 @@
+\section{Redesigning Tor's DNS Cache} \label{tlwo:sec:long} 
+To address (timeless) timing attacks in Tor's DNS cache we considered a
+number of possible smaller changes.  All of them failed for different reasons,
+however.  Section~\ref{tlwo:sec:long:strawman} presents a straw-man design that is
+helpful to understand \emph{why}, while at the same time being closely related
+to the properties achieved by the preload DNS cache design in
+Section~\ref{tlwo:sec:long:preload}.  Section~\ref{tlwo:sec:long:evaluation} presents an
+extensive evaluation that answers questions about how feasible and performant
+our proposal is.
+
+\subsection{Straw-man Design} \label{tlwo:sec:long:strawman}
+We omit all but one
+straw-man design that is particularly important to understand the proposed
+redesign in Section~\ref{tlwo:sec:long:preload}: \emph{simply remove Tor's DNS
+cache}.  If there is no DNS cache to speak of in Tor, it is easy to see that
+there cannot be any (timeless) timing attacks against Tor's DNS cache (because
+it does not exist).  What these attacks would instead target is the exit's DNS
+resolver which also has a cache.  At a first glance it may seem like an
+insignificant improvement that just moves the problem elsewhere. This would be
+the case if every exit used its own dedicated DNS resolver. However, an exit may
+share a resolver with other exits or most importantly clients outside of the Tor
+network.  A prime example is the resolver of the ISP of the exit.  Any inference
+made from the state of shared resolvers would thus not be directly attributable
+to activity on the Tor network. This would therefore make \emph{false positives}
+a reality with regards to if a domain was cached or not as a consequence of
+activity in the Tor network.
+
+Introducing false positives to the timeless timing attack itself is in general
+challenging because an answer needs to be available at the same time regardless
+of there being a cache hit or miss. False negatives may seem easier and could
+make the attacker discard otherwise correct classifications, e.g., because an
+attack only works half of the time. However, without false positives, attackers
+are still able to reliably remove otherwise incorrect classification through
+confirmation~\cite{wfwo}. Because websites typically make use of multiple domain
+names, defenses that add random delays to responses (to cause false negatives)
+would need to consistently add similar delays for all relevant domains tied to
+websites or other user activity the attacker is trying to infer. The semantics
+surrounding user activity is hard if not impossible to capture at the DNS level.
+Therefore, all false negative defenses we could think of failed.
+
+Now suppose that Tor has no DNS cache and exits always use a shared resolver
+that may introduce false positives.
+A major downside is that performance would take a significant hit due to the
+lack of a cache in Tor, especially since a shared resolver is likely not running
+locally, but provided by the ISP or some third-party.  It is likely that both
+page-load latency and resolver load would increase. Worsening performance and
+especially latency is the opposite of what the Tor project is working
+towards~\cite{tor,tor-congestion}.  Next we show how to get the good properties
+of not having a DNS cache in Tor (potential for false positives) while improving
+performance.
+
+\subsection{The Preload DNS Cache} \label{tlwo:sec:long:preload} 
+This is not only a defense against (timeless) timing attacks in the DNS cache,
+but a complete redesign of Tor's DNS cache. Ultimately, \emph{what we want to
+achieve is false positives for an attacker trying to determine client activity
+in the Tor network with the help of DNS}. The only way to achieve this---upon
+learning that a domain associated with some activity has been looked up---is if
+there is a possibility that this domain lookup was caused from outside of the
+Tor network. Therefore, as a starting point, we assume that the Tor Project
+would strongly encourage exit operators to not run local resolvers dedicated to
+exits. Instead, exit operators should configure their systems to use their ISP
+resolvers or use a third-party provider. Greschbach
+\emph{et~al.}~\cite{GreschbachPRWF17} investigated the effect of DNS on Tor's
+anonymity, including resolver configuration, and found that using the ISP's
+resolver would be preferable.
+
+First remove all of Tor's current DNS caching as in our straw-man design.  The
+preloaded DNS cache instead contains two types of caches: a same-circuit cache
+and a shared preload cache, see Figure~\ref{tlwo:fig:preload}.  The preloaded cache
+only contains domains from an allowlist.  This allowlist is compiled by a
+central party (e.g., by the Network Health team in the Tor Project) by visiting
+popular sites from several different vantage points. The allowed domains are
+then delivered to exits and continuously resolved to IPs by each exit. During
+domain resolution on a circuit, the client's lookup first hits the preload
+cache.  If the domain is preloaded, a cache hit is guaranteed regardless of if
+anyone performed a lookup before. Therefore, it is safe to share this cache
+across circuits without leaking information about past exit traffic.  On a cache
+miss, the circuit's same-circuit cache is consulted.  As the name suggests, this
+cache is shared for streams on the same circuit but not across different
+circuits.  Due to Tor's circuit isolation, an attacker is unable to probe any
+other cache than their own.  Therefore, (timeless) timing attacks are eliminated
+(similar to if Tor did not have a DNS cache at all), but without removing the
+possibility of cache hits.
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=.85\columnwidth]{src/tlwo/img/preload}
+	\caption{%
+		Overview of the preloaded DNS cache design.  A central party
+		visits sites on a popularity list from different vantage points
+		to compile an allowlist of domains that each relay keeps
+		preloaded at all times by resolving them continuously.  DNS
+		looks-ups start in the shared preload cache and moves on to a
+		dynamic cache that is never shared across circuits on cache
+		misses.
+	}
+	\label{tlwo:fig:preload}
+\end{figure}
+
+Including a same-circuit cache in the defense is motivated by Tor's significant
+same-circuit caching to retain performance, see
+Figures~\ref{tlwo:fig:metrics:hitsweb} and~\ref{tlwo:fig:metrics:hitsperm} in
+Section~\ref{tlwo:sec:torcache:metrics}. One can confirm that this is most likely due
+to Tor Browser opening several concurrent connections by referring to the
+\texttt{network.http.max-persistent-con
+nections-per-proxy} option and/or
+enabling debug logging,\footnote{%
+	Enable debug logging in Tor Browser: \url{https://gitlab.torproject.org/tpo/applications/tor-browser/-/wikis/Hacking\#debugging-the-tor-browser}
+} observing that multiple streams are often created to the same destination.
+Note that these destinations are domains and not IPs, and that neither TB nor
+the client-side Tor process has any notion of a DNS cache to prevent
+cross-circuit fingerprinting (see Section~\ref{tlwo:sec:background:tor}).  While a
+hypothetical \emph{per-circuit client-side cache} would be an option, it would
+per definition not be able to generate cache hits for concurrent resolves
+(without violating circuit isolation, potentially leading to cross-circuit
+fingerprinting) and put pressure on exits unless they do the appropriate
+caching.  This is why our design places the same-circuit cache at exits instead
+of clients.
+
+A preload cache is also motivated by performance, however without any of the
+harmful cross-circuit sharing.  The remainder of this section explores the
+performance impact of compiling an allowlist from popularity lists---like
+Alexa~\cite{alexa}, Cisco Umbrella~\cite{umbrella}, and
+Tranco~\cite{tranco}---by comparing the resulting cache-hit ratios to baseline
+Tor today.  The preloaded DNS cache is inspired by RFC 8767~\cite{rfc8767} which
+allows resolvers to serve stale data in some cases (see
+Section~\ref{tlwo:sec:related}). Here, exits keep domains on a preloaded allowlist
+fresh on a best-effort level, serving stale records if necessary. Upon shutdown,
+exits could persist IPs in the preload cache to disk as a starting point on
+startup.  Upon startup, if the preload cache have yet to be populated with IPs,
+simply treat lookups as cache misses.  We discuss periodic refresh overhead
+further in Section~\ref{tlwo:sec:long:preload:resolverload}.
+
+\subsection{Data Collection} \label{tlwo:sec:long:preload:collection}
+
+As part of understanding Tor's DNS cache (Section~\ref{tlwo:sec:torcache}) we also
+collected data to be able to evaluate the performance of the preload design. In
+particular, we evaluate different popularity lists, the impact on cache-hit
+ratio, estimated DNS cache size, and how these change over time.
+
+Central to the preload design is domain popularity lists. We included the Alexa
+list~\cite{alexa} because that is what Mani \emph{et~al.} showed to be accurate for
+Tor~\cite{ManiWJJS18}, the newer Tranco list because it may be more
+accurate~\cite{tranco}, and the Cisco Umbrella list because it also contains
+``non-web'' domains~\cite{umbrella}.
+
+In addition to considering the popularity lists, we also created \emph{extended}
+lists from Alexa and Tranco by visiting each domain on those lists using the
+Chromium browser and recording all requests for additional domains. We repeated
+this three times from Europe, twice from the US, and twice from Hong Kong by
+using a popular VPN service. Each visit was given a timeout of 20 seconds. No
+pruning of the resulting extended lists of domains was done. Much can likely be
+done to make these lists of domains significantly more comprehensive (e.g., by
+considering popular subpages that might contain domains not on the front-page of
+websites) and smaller (e.g., by pruning unique tracking domains: in one of our
+biggest lists, \texttt{*.safeframe.googlesyndication.com} makes up 8\% of
+domains with unique tracking subdomains with no value for caching).  Another
+direction to explore that could result in lists that are smaller and/or more
+comprehensive would be to tailor them specifically for relays in certain
+regions.  For example, website visits from Europe may be treated differently by
+website operators due to regulations like the GDPR. (In other words, there could
+be differences with regards to \emph{domains}---not to be confused with IPs that
+each relay already resolves locally---that are encountered during website
+visits.)
+
+Based on the regular and extended popularity lists, we made several lists from
+top-10 up to and including top-10,000 in increments. Further, the weekend before
+each of the \emph{first four weeks} of data collection (see
+Section~\ref{tlwo:sec:torcache}), we downloaded fresh popularity lists (Fridays) and
+generated new extended lists (Saturdays and Sundays). We generated in total
+$4*20*5 = 400$ lists: for the first four weeks, 20 lists each for \{Alexa,
+Tranco, Umbrella, extended Alexa, extended Tranco\}.
+
+Our data collection involving the lists took place in three phases. The first
+phase consisted of the first four weeks with increasingly more lists, which was
+followed by two weeks of analysis of our results and dialog with the Tor
+Research Safety Board. This lead us to the third and final phase of data
+collection where we excluded the vast majority of lists, focusing only on
+getting extended data for about eleven more weeks on the most informative and
+useful lists (see Section~\ref{tlwo:sec:long:evaluation}).
+
+\subsection{Further Ethical Considerations} \label{tlwo:sec:long:preload:ethics}
+
+We discussed the preload additions as part of our other data collection,
+received feedback from the Tor Research Safety Board, and passed our
+university's ethical review process. 
+
+Our rationale for why including counters for preload lists is safe was as
+follows. We collect counters of aggregate lookups that would have been
+cache-hits on each list over 15 minutes. Except for the top-10 lists
+(non-extended), all other lists contain in the order of 100--1,000 unique
+domains aggregated into a single counter. The main harm associated with the
+dataset is if they enable an attacker to \emph{rule out} that a particular
+website or Tor-user activity took place at our exits (see following paragraph).
+So, little to no zero counters in our data is what we set out to achieve.  As an
+additional safety precaution our exits only have a $0.1$\% exit probability,
+further making any zero counter less useful.
+
+Let us look more closely at the potential harm. For websites, the results of Mani
+\emph{et~al.}~\cite{ManiWJJS18} tell an attacker to expect a power-law-like
+distribution of website popularity in the network. As discussed in
+Section~\ref{tlwo:sec:torcache:ethics}, we expect on average about 725 website visits
+to each exit per 15 minute period. This is \emph{the prior of an attacker}
+wishing to perform confirmation or correlation attacks. Most of the visits
+should be to popular websites (per definition) and if the dataset allows an
+attacker to rule such visits out it may cause harm because it is useful
+information to the attacker~\cite{wfwo}. Because of this, we grouped our lists
+into intervals of 100s (for top-?00) and 1000s (for top-?000). We stopped at
+top-10k because we estimated little utility of caching domains of even less
+popular websites. Further, to illustrate when the type of data we collect can be
+harmful, the results of Mani \emph{et~al.}~\cite{ManiWJJS18} and Pulls and
+Dahlberg~\cite{wfwo} tell us that at some point the logic becomes flipped in
+terms of attacker utility: confirming that it was possible that a visit took
+place to a \emph{rarely visited website} is useful. The popularity (i.e.,
+network base rate) of websites is central. We set out to only collect data on
+the most popular of websites/domains, so for us, the focus is on when the
+attacker can rule out website visits or some user activity: an attacker already
+expects that popular websites/domains are visited.
+
+We analyzed the 1,330,400 sample counters we collected over the first four weeks
+for different popularity lists. We found 33 zero counters. All of them belonged
+to Alexa top-10 lists from different weeks! Besides Alexa top-10, the next list
+with the lowest counter was Tranco top-100 from 20 May with 39 hits. Finding
+empty counters for Alexa top-10 was at first very surprising, because the list
+contains the most popular websites on the web (e.g., from 20 May:
+\texttt{google.com}, \texttt{youtube.com}, \texttt{baidu.com},
+\texttt{facebook.com}, \texttt{instagram.com}, \texttt{bilibili.com},
+\texttt{qq.com}, \texttt{wikipedia.org}, \texttt{amazon.com}, and
+\texttt{yahoo.com}).  H-owever, note how the actual \emph{domains} on the list (of
+\emph{websites}) do not contain the \texttt{www} prefix nor any other popular subdomain
+associated with the sites. This highlights how poor the regular non-extended
+lists are at capturing actual \emph{website} traffic. We can further see this
+for both Alexa and Tranco in Figure~\ref{tlwo:fig:preload:heatmap}, presented next in
+Section~\ref{tlwo:sec:long:preload:lists}. Even the top-10k lists have low
+cache-hit ratios.
+
+By comparing a list with a more popular list (which should be a strict subset)
+and observing the same counter value it is also possible to infer that
+\emph{likely} no visits took place to the unique domains on the less popular
+list. (This could happen by chance though.) We found 16,055 (1.2\%) such
+samples: 5,073 to top-10k lists, 3,703 to top-[1k,10k) lists, and 7,279 to
+top-[200,1k) lists. None of them were to top-100 lists. This might seem alarming
+at first glance, but taking a closer look at the lists we find that only 135 of
+the samples were to extended lists (77 to x-Tranco top-10k, the highest rank
+list was x-Tranco top-600 with one sample). Further, only five of the samples
+belonged to a list from Umbrella. The remaining 15,915 samples were to the
+regular (non-extended) Alexa and Tranco lists. This is of limited use to
+attackers for popular domains, because while the lists capture popular
+\emph{websites}, our dataset contains counters of \emph{aggregate domain
+lookups}. An inferred zero counter \emph{does not mean that no visits took
+place} to \emph{websites} for the \emph{non-extended} lists. For example, if you
+enter \texttt{www.google.com} or \texttt{www.wikipedia.org} into Tor Browser,
+neither \texttt{google.com} nor \texttt{wikipedia.org} are actually connected
+to. The recursive resolver of the exit may perform the lookup, but Tor will not,
+so it is not captured in our dataset for the non-extended lists. The extended
+lists, due to being generated from actual website visits, include domains
+typically connected to by Tor Browser. Another example is users visiting direct
+links to websites and not entering the domain manually in the browser, such as
+when following links from search engines or sent through social media.
+
+When designing our measurements the above detail was not considered. We included
+the regular popularity lists for sake of comparison. Ideally the non-extended
+lists would have been effective sources for preload lists. This was evidently
+not the case for Alexa and Tranco (see later results), but was the case for
+Umbrella. So while what we did learn helped us understand the value of using
+extended lists to improve cache hits, in hindsight we could have come to the
+same conclusion without the same granularity for non-extended lists.
+
+In the second phase of our data collection (see
+Section~\ref{tlwo:sec:long:preload:collection}), we discussed the above detail with
+the Tor Research Safety Board and concluded to stop collecting data for
+(non-extended) Alexa and Tranco, and to minimize the lists for future collection
+to those necessary to determine the longevity of potentially useful preload
+lists (based on our findings). Out of an abundance of caution, we will only
+share the collected counters for non-extended Alexa and Tranco lists with
+researchers for research purposes (the rest of the data is public). The counters
+collected during the second phase were consistent with the data from the first
+phase.
+
+During the third phase of data collection, we limited the collection to extended
+Tranco top-\{10, 100, 1k, 2k, 4k, 5k, 7k, 10k\} lists and the Umbrella top-10k
+list, all from April 29. The goal was to learn how cache hits get worse over
+time with old lists. Out of 141,624 sample counters collected, three were zero
+and 59 were relatively zero when compared to the more popular list.
+
+\subsection{Performance Evaluation} \label{tlwo:sec:long:evaluation}
+
+The goal of our evaluation is to determine over time:
+  cache-hit ratio of potential preload lists (Section~\ref{tlwo:sec:long:preload:lists}),
+  memory usage at exits (Section~\ref{tlwo:sec:long:preload:entries}), and
+  resolver load (Section~\ref{tlwo:sec:long:preload:resolverload}).
+
+\subsubsection{Results: Preload Lists} \label{tlwo:sec:long:preload:lists}
+
+\begin{figure}
+	\centering
+	\subfloat[][web]{%
+		\includegraphics[width=.75\columnwidth]{src/tlwo/img/plot_preload_lists-web.pdf}
+		\label{tlwo:fig:preload:heatmap:web}
+	}\\
+	\subfloat[][permissive]{%
+		\includegraphics[width=.75\columnwidth]{src/tlwo/img/plot_preload_lists-permissive.pdf}
+		\label{tlwo:fig:preload:heatmap:perm}
+	}
+	\caption{%
+	Shared cross-circuit cache-hit ratios (\%) for selected preload lists during
+	the first six weeks (x-axis) of data collection. The plotted values are medians over
+	24h, and dates on the y-axis show the date of original list download.}
+	\label{tlwo:fig:preload:heatmap}
+\end{figure}
+
+Our dataset is extensive with 2,498,424 sample counters from 400 popularity
+lists spanning about four months. Figure~\ref{tlwo:fig:preload:heatmap} shows
+comprehensive heatmaps of shared cross-circuit cache-hit ratios for the web
+(Figure~\ref{tlwo:fig:preload:heatmap:web}) and permissive
+(Figure~\ref{tlwo:fig:preload:heatmap:perm}) exits over the first six weeks of data
+collection (first and second phases). Cache-hit ratios are medians (very similar
+to the mean) for 24h periods. In each figure, the groupings of the four weeks
+when we added new lists are visible (top to bottom), as well as baseline Tor at
+the bottom row for sake of comparison. Note how the regular Alexa and Tranco
+top-10k lists perform poorly: the two black ($<5\%$ cache-hit ratio) lines at
+the top of each grouping. Even Umbrella 1k is better, with Umbrella 10k being
+comparable to baseline Tor. The extended lists clearly improve over baseline
+Tor, with the extended 10k-lists even reaching over 30\% cross-circuit cache-hit
+ratios some days. Look at how the lists change over time: we see no real
+difference between lists generated at end of April and those generated during
+May, but consistent changes across all lists over time, likely due to varying
+traffic at the exits. The differences between using Alexa or Tranco to generate
+extended lists are negligible, so we focus on Tranco for the remainder of this
+analysis as it is open, maintained, and a more recent source of website
+popularity~\cite{tranco}.
+
+
+\begin{figure}[!t]
+	\centering
+	\subfloat[][web]{%
+		\includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_preload_hits-web.pdf}
+		\label{tlwo:fig:preload:hits:web}
+	}\\
+	\subfloat[][permissive]{%
+		\includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_preload_hits-permissive.pdf}
+		\label{tlwo:fig:preload:hits:perm}
+	}
+	\caption{%
+	Shared cross-circuit cache-hit ratios for eight different extended Tranco
+	lists, Umbrella top-10k, and Tor baseline during four months in 2022.}
+	\label{tlwo:fig:preload:hits}
+\end{figure}
+
+Figure~\ref{tlwo:fig:preload:hits} shows the observed \emph{cross-circuit} cache-hit
+ratios for eight different extended Tranco lists, Umbrella top-10k, and Tor
+baseline. We used lists from the end of April because they have the most data.
+As a baseline, Tor's current DNS cache has a mean cache-hit ratio of 11\% for
+web and 17\% for permissive. In terms of different popularity lists, the regular
+(non-extended) Tranco and Alexa lists are ineffective: the top-10k lists are
+regularly below $5\%$ for web and permissive (see
+Figure~\ref{tlwo:fig:preload:heatmap}). Umbrella top-10k does much better with mean
+17\% (web) and 16\% (permissive). This is slightly worse (permissive) and
+comparable (web) to baseline Tor.
+
+The extended lists show a further improvement, comparable in terms of
+\emph{average} (full duration of lists) cross-circuit cache-hit ratios to
+baseline Tor at top-200 for Alexa and Tranco for web and at top-700 for
+permissive. The extended lists from top-1k get (depending on which of the
+compiled extended Tranco lists) 20--24\% (web) and 15--18\% (permissive) and up
+to 27--32\% (web) and 22--27\% (permissive) at 10k. There is very little gain
+between top-7k and top-10k. In general, the extended lists do relatively worse
+on the permissive exit and the Tor baseline is higher: this makes sense, since
+Alexa and Tranco are focused on websites. This is further confirmed by Umbrella
+doing better as a more general-purpose domain popularity list.
+
+Note that Figure~\ref{tlwo:fig:preload:hits} shows the cross-circuit cache-hit ratios
+for a selection of the very first preload lists we created on the April 29. The
+results are very encouraging: time seems to have only a slight detrimental
+impact on cache hits. After four months the larger extended lists show a
+noticable performance improvement over baseline, with the exception of an odd
+spike in baseline in early September (we speculate that this is DDoS-related).
+The robustness of preload lists removes one of the main downsides of the preload
+design, i.e., to maintain and deliver a current list to exits. It is likely
+feasible to ship hard-coded preload lists as part of regular Tor releases and
+still improve performance, assuming that exit operators upgrade their software a
+couple of times per year.
+
+\subsubsection{Results: Cache Entries} \label{tlwo:sec:long:preload:entries}
+
+\begin{figure}
+	\centering
+	\subfloat[][web]{%
+		\includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_preload_entries-web.pdf}
+		\label{tlwo:fig:preload:entries:web}
+	}\\
+	\subfloat[][permissive]{%
+		\includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_preload_entries-permissive.pdf}
+		\label{tlwo:fig:preload:entries:perm}
+	}
+	\caption{%
+	Estimated cache entries for eight different extended Tranco lists, Umbrella
+	top-10k, and Tor baseline.}
+	\label{tlwo:fig:preload:entries}
+\end{figure}
+
+Figure~\ref{tlwo:fig:preload:entries} shows the number of cache entries needed in Tor
+as-is (``baseline Tor'') and for the preload design for a range of different
+popularity lists. We can accurately estimate an upper bound because we collected
+the total number of entires in all same-circuit caches as part of our
+measurements. This count is an upper bound, because some of those entries would
+have already been cached in the preload cache. The popularity lists have static
+sizes, and to be an accurate upper bound we used the largest observed size for
+each list over the four weeks.
+
+Starting with the same-circuit cache, look at the line for extended Tranco
+top-10 (``x-Tranco 10'') in Figure~\ref{tlwo:fig:preload:entries}: this extended list
+contains only 90 entries, so the lines at the bottom show mostly the number of
+entries used by the same circuit cache. The size of the same-circuit caches
+should be proportional to the number of open circuits, and therefore follow exit
+probability. Based on the data from Figure~\ref{tlwo:fig:preload:entries}, we do not
+suspect this to be a significant burden. It would be trivial to cap the size
+and/or prune the size as part of OOM-management, or dropping entries based on
+their age would probably have little impact on performance (presumably most
+value is at the start of the circuit when most streams are attached).
+
+Recall from Section~\ref{tlwo:sec:torcache:metrics} and
+Figures~\ref{tlwo:fig:metrics:cacheweb} and~\ref{tlwo:fig:metrics:cacheperm} that the
+permissive exit had a mean of 12,130 entries compared to the web exit's 7,672
+mean. We see the same figures for the baseline in
+Figure~\ref{tlwo:fig:preload:entries}. Albeit slightly higher on average for the web
+exit but more stable, we see that Umbrella 10k as well as extended Tranco top-1k
+are about the same as Tor baseline. So with about the same memory usage as now
+the preload design would offer slightly (permissive) or noticeably (web) better
+cache-hit ratios. Looking at the top-2k up until top-10k extended lists we see a
+significant higher memory usage (only slightly sublinear) but that comes with
+significantly higher cache-hit ratios, as seen in Figure~\ref{tlwo:fig:preload:hits}.
+In absolute terms, for extended Tranco top-10k, about 60,000 cache
+entries---even if pessimistically assuming 1 KiB per entry---would end up using
+about 60 MiB of memory for the cache. Since domains can be at most 255 bytes and
+most domains are much shorter, one could clearly implement the cache
+more memory-efficiently. Also, as mentioned earlier, it is likely possible to
+reduce the size of the extended top-10k lists by removing useless tracking
+domains. Further note that the memory needed to cache the preload list---unlike
+the same-circuit cache---only depends on the size of the list, not the number
+circuits or streams created at the exit.
+
+\subsubsection{Results: Resolver Load} \label{tlwo:sec:long:preload:resolverload}
+
+In general, on the one hand, improving cache-hit ratios will reduce resolver load
+and scale well with increased traffic. On the other hand, continuously
+refreshing domains on the preload list increases resolver load. Consider the
+mean number of lookups at the web exit, 17,529, and its mean/median cache-hit
+ratio of 0.80 (see Section~\ref{tlwo:sec:torcache}). This implies an expected
+$3.9\gets\frac{17529(1-0.80)}{15\cdot60}$ requests per second to the exit's
+resolver.  For the permissive exit we observed about 7.8 requests per second. As
+a source of comparison, Sonntag~\cite{sonntag-metrics,Sonntag19} reports for a
+DNS resolver dedicated to a 200 Mbit/s exit in 2018 an average of 18.5 requests
+per second.
+
+The resolver load for the different preload lists should be proportional to the
+estimated number of cache entries shown in Figure~\ref{tlwo:fig:preload:entries}. The
+estimated load for an extended top-1k list would be similar to current Tor,
+while the extended top-10k list would see about a seven-fold increase without
+changes. This may or may not be problem. Given the variability of lookups we
+observed throughout our data collection (Figure~\ref{tlwo:fig:lookups}) and reported
+by Sonntag, resolvers are clearly capable of dealing with increased loads.
+Requests due to the preload list should be predictable, consistent, and cheap in
+terms of bandwidth even for a low-capacity exit.
+
+Regardless, the load on resolvers could be lowered by reducing the number of
+domains, e.g., the increased cache-hit ratio from top-7k to top-10k is very
+small ($\approx$1\%) for a 20--30\% increase in entries. One could also increase
+the internal TTLs, i.e., the frequency of refreshing the entries in the preload
+cache. In Tor, this is especially practical since circuits use random exits. In
+the rare case of stale data causing issues, simply create a fresh circuit.
+Serving stale data is not uncommon in DNS~\cite{rfc8767}, further discussed next
+in Section~\ref{tlwo:sec:related}.
diff --git a/summary/src/tlwo/src/ref.bib b/summary/src/tlwo/src/ref.bib
new file mode 100644
index 0000000..c62bea8
--- /dev/null
+++ b/summary/src/tlwo/src/ref.bib
@@ -0,0 +1,352 @@
+@misc{ctor-1,
+  author       = {Tor Project},
+  title        = {{Tor source code}},
+  howpublished = {\url{https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.7/src/feature/relay/dns.c\#L600-689}, accessed 2022-06-01},
+}
+
+@misc{ctor-2,
+  author       = {Tor Project},
+  title        = {{Tor source code}},
+  howpublished = {\url{https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.7/src/lib/tls/buffers\_tls.c\#L43-100}, accessed 2022-06-01},
+}
+
+@misc{ctor-3,
+  author       = {Tor Project},
+  title        = {{Tor source code}},
+  howpublished = {\url{https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.7/src/core/or/connection\_or.c\#L2361-2426}, accessed 2022-06-01},
+}
+
+@misc{ctor-4,
+  author       = {Tor Project},
+  title        = {{Tor source code}},
+  howpublished = {\url{https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.7/src/feature/relay/dns.c\#L725-732}, accessed 2022-06-01},
+}
+
+@misc{network-ddos,
+  author       = {Tor Project},
+  title        = {{Tor Project status}},
+  howpublished = {\url{https://web.archive.org/web/20220906145324/https://status.torproject.org/}},
+}
+
+@article{jung,
+  author    = {Jaeyeon Jung and Emil Sit and Hari Balakrishnan and Robert Tappan Morris},
+  title     = {{DNS} performance and the effectiveness of caching},
+  journal   = {{IEEE/ACM} Trans. Netw.},
+  volume    = {10},
+  number    = {5},
+  year      = {2002},
+}
+
+@article{hao-and-wang,
+  author    = {Shuai Hao and Haining Wang},
+  title     = {Exploring Domain Name Based Features on the Effectiveness of {DNS} Caching},
+  journal   = {CCR},
+  volume    = {47},
+  number    = {1},
+  year      = {2017},
+}
+
+
+
+@inproceedings{trilemma,
+  author    = {Debajyoti Das and Sebastian Meiser and Esfandiar Mohammadi and Aniket Kate},
+  title     = {Anonymity Trilemma: Strong Anonymity, Low Bandwidth Overhead, Low Latency---Choose Two},
+  booktitle = {{IEEE} {S\&P}},
+  year      = {2018},
+}
+
+@article{remote-timing-attacks,
+  author    = {Scott A. Crosby and Dan S. Wallach and Rudolf H. Riedi},
+  title     = {Opportunities and Limits of Remote Timing Attacks},
+  journal   = {{ACM} Trans. Inf. Syst. Secur.},
+  volume    = {12},
+  number    = {3},
+  year      = {2009},
+}
+
+
+@inproceedings{lucky13,
+  author    = {Nadhem J. AlFardan and Kenneth G. Paterson},
+  title     = {Lucky Thirteen: Breaking the {TLS} and {DTLS} Record Protocols},
+  booktitle = {{IEEE} {S\&P}},
+  year      = {2013},
+}
+
+@inproceedings{timing-attack,
+  author    = {Paul C. Kocher},
+  title     = {Timing Attacks on Implementations of {Diffie-Hellman}, {RSA}, {DSS}, and Other Systems},
+  booktitle = {{CRYPTO}},
+  year      = {1996},
+}
+
+@inproceedings{tor,
+  author    = {Roger Dingledine and Nick Mathewson and Paul F. Syverson},
+  title     = {Tor: The Second-Generation Onion Router},
+  booktitle = {USENIX Security},
+  year      = {2004},
+}
+
+@article{wfwo,
+  author    = {Tobias Pulls and Rasmus Dahlberg},
+  title     = {Website Fingerprinting with Website Oracles},
+  journal   = {PETS},
+  volume    = {2020},
+  number    = {1},
+}
+
+@inproceedings{timeless,
+  author    = {Tom van Goethem and Christina P{\"{o}}pper and Wouter Joosen and Mathy Vanhoef},
+  title     = {Timeless Timing Attacks: Exploiting Concurrency to Leak Secrets over Remote Connections},
+  booktitle = {{USENIX} Security},
+  year      = {2020},
+}
+
+@inproceedings{sonntag-metrics,
+  author    = {Michael Sonntag},
+  title     = {{DNS} Traffic of a {Tor} Exit Node---An Analysis},
+  booktitle = {{SpaCCS}},
+  year      = {2018},
+}
+
+@inproceedings{ManiWJJS18,
+  author    = {Akshaya Mani and T. Wilson{-}Brown and Rob Jansen and Aaron Johnson and Micah Sherr},
+  title     = {Understanding {Tor} Usage with Privacy-Preserving Measurement},
+  booktitle = {{IMC}},
+  year      = {2018},
+}
+
+@inproceedings{tranco,
+   author    = {{Le Pochat}, Victor and {Van Goethem}, Tom and Tajalizadehkhoob, Samaneh and Korczy\'{n}ski, Maciej and Joosen, Wouter},
+   title     = {Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation},
+   booktitle = {NDSS},
+   year      = {2019},
+}
+
+@misc{umbrella,
+  author       = {Cisco},
+  title        = {Umbrella Popularity List},
+  howpublished = {\url{https://umbrella-static.s3-us-west-1.amazonaws.com/index.html}, accessed 2022-04-29},
+}
+
+@misc{alexa,
+  author       = {Amazon},
+  title        = {Alexa Top 1 Million},
+  howpublished = {\url{https://www.alexa.com/}, accessed 2022-04-29},
+}
+
+@inproceedings{GreschbachPRWF17,
+  author    = {Benjamin Greschbach and Tobias Pulls and Laura M. Roberts and Philipp Winter and Nick Feamster},
+  title     = {The Effect of {DNS} on {Tor}'s Anonymity},
+  booktitle = {NDSS},
+  year      = {2017},
+}
+
+@techreport{rfc8767,
+  author       = {David C Lawrence and Warren Kumari and Puneet Sood},
+  title        = {Serving Stale Data to Improve {DNS} Resiliency},
+  type         = {RFC},
+  institution  = {IETF},
+  number       = {8767},
+  year         = {2020},
+}
+
+@inproceedings{Sonntag19,
+  title     = {Malicious {DNS} Traffic in {Tor}: Analysis and Countermeasures},
+  author    = {Sonntag, Michael},
+  booktitle = {ICISSP},
+  year      = {2019}
+}
+
+@inproceedings{privcount,
+  author    = {Rob Jansen and Aaron Johnson},
+  title     = {Safely Measuring {Tor}},
+  booktitle = {{CCS}},
+  year      = {2016},
+}
+
+@inproceedings{privex,
+  author    = {Tariq Elahi and George Danezis and Ian Goldberg},
+  title     = {{PrivEx}: Private Collection of Traffic Statistics for Anonymous Communication Networks},
+  booktitle = {{CCS}},
+  year      = {2014},
+}
+
+
+@inproceedings{FenskeMJS17,
+  author    = {Ellis Fenske and Akshaya Mani and Aaron Johnson and Micah Sherr},
+  title     = {Distributed Measurement with Private Set-Union Cardinality},
+  booktitle = {{CCS}},
+  year      = {2017},
+}
+
+@inproceedings{JansenTH18,
+  author    = {Rob Jansen and Matthew Traudt and Nicholas Hopper},
+  title     = {Privacy-Preserving Dynamic Learning of {Tor} Network Traffic},
+  booktitle = {{CCS}},
+  year      = {2018},
+}
+
+@inproceedings{MouraHMSD18,
+  author    = {Giovane C. M. Moura and John S. Heidemann and Moritz M{\"{u}}ller and Ricardo de Oliveira Schmidt and Marco Davids},
+  title     = {When the Dike Breaks: Dissecting {DNS} Defenses During {DDoS}},
+  booktitle = {{IMC}},
+  year      = {2018},
+}
+
+@misc{unbound,
+  author       = {{NLnet Labs}},
+  title        = {Serving Stale Data---Unbound 1.14.0 documentation},
+  howpublished = {\url{https://unbound.docs.nlnetlabs.nl/en/latest/topics/serve-stale.html}, accessed 2022-06-01},
+}
+
+@article{cheng1998traffic,
+  title   = {Traffic analysis of {SSL} encrypted web browsing},
+  author  = {Cheng, Heyning and Avnur, Ron},
+  journal = {Project paper, University of Berkeley},
+  year    = {1998}
+}
+
+@inproceedings{DBLP:conf/sp/SunSWRPQ02,
+  author    = {Qixiang Sun and Daniel R. Simon and Yi{-}Min Wang and Wilf Russell and Venkata N. Padmanabhan and Lili Qiu},
+  title     = {Statistical Identification of Encrypted Web Browsing Traffic},
+  booktitle = {{IEEE S\&P}},
+  year      = {2002}
+}
+
+@inproceedings{Hintz02,
+  author    = {Andrew Hintz},
+  title     = {Fingerprinting Websites Using Traffic Analysis},
+  booktitle = {{PETS}},
+  year      = {2002}
+}
+
+@inproceedings{DBLP:conf/ccs/LiberatoreL06,
+  author    = {Marc Liberatore and Brian Neil Levine},
+  title     = {Inferring the source of encrypted {HTTP} connections},
+  booktitle = {{CCS}},
+  year      = {2006}
+}
+
+@inproceedings{HerrmannWF09,
+  author    = {Dominik Herrmann and Rolf Wendolsky and Hannes Federrath},
+  title     = {Website fingerprinting: attacking popular privacy enhancing technologies with the multinomial na{\"{\i}}ve-bayes classifier},
+  booktitle = {{CCSW}},
+  year      = {2009}
+}
+
+@inproceedings{PanchenkoNZE11,
+  author    = {Andriy Panchenko and Lukas Niessen and Andreas Zinnen and Thomas Engel},
+  title     = {Website fingerprinting in onion routing based anonymization networks},
+  booktitle = {{WPES}},
+  year      = {2011}
+}
+
+@inproceedings{PochatGJ19,
+  author    = {Victor Le Pochat and Tom van Goethem and Wouter Joosen},
+  title     = {Evaluating the Long-term Effects of Parameters on the Characteristics of the {Tranco} Top Sites Ranking},
+  booktitle={{USENIX Security}},
+  year={2019}
+}
+
+@inproceedings{JuarezAADG14,
+  author    = {Marc Ju{\'{a}}rez and Sadia Afroz and Gunes Acar and Claudia D{\'{\i}}az and Rachel Greenstadt},
+  title     = {A Critical Evaluation of Website Fingerprinting Attacks},
+  booktitle = {{CCS}},
+  year      = {2014},
+}
+
+@misc{perryCrit,
+  author       = {Mike Perry},
+  title        = {A Critique of Website Traffic Fingerprinting Attacks},
+  howpublished = {\url{https://blog.torproject.org/critique-website-traffic-fingerprinting-attacks}, accessed 2022-06-01},
+}
+
+@article{realistic,
+  author    = {Tao Wang and Ian Goldberg},
+  title     = {On Realistically Attacking {Tor} with Website Fingerprinting},
+  journal   = {PETS},
+  volume    = {2016},
+  number    = {4},
+}
+
+@inproceedings{JohnsonWJSS13,
+  author    = {Aaron Johnson and Chris Wacek and Rob Jansen and Micah Sherr and Paul F. Syverson},
+  title     = {Users get routed: traffic correlation on {Tor} by realistic adversaries},
+  booktitle = {{CCS}},
+  year      = {2013}
+}
+
+@inproceedings{deepcorr,
+  author    = {Milad Nasr and Alireza Bahramali and Amir Houmansadr},
+  title     = {DeepCorr: Strong Flow Correlation Attacks on {Tor} Using Deep Learning},
+  booktitle = {{CCS}},
+  year      = {2018}
+}
+
+@inproceedings{AumannL07,
+  author    = {Yonatan Aumann and Yehuda Lindell},
+  title     = {Security Against Covert Adversaries: Efficient Protocols for Realistic Adversaries},
+  booktitle = {{TCC}},
+  year      = {2007},
+}
+
+@inproceedings{chen,
+  author    = {Yizheng Chen and Manos Antonakakis and Roberto Perdisci and Yacin Nadji and David Dagon and Wenke Lee},
+  title     = {{DNS} Noise: Measuring the Pervasiveness of Disposable Domains in Modern {DNS} Traffic},
+  booktitle = {{IEEE/IFIP} {DSN}},
+  year      = {2014},
+}
+
+
+@inproceedings{exitmap,
+  author    = {Philipp Winter and Richard K{\"{o}}wer and Martin Mulazzani and Markus Huber and Sebastian Schrittwieser and Stefan Lindskog and Edgar R. Weippl},
+  title     = {Spoiled Onions: Exposing Malicious {Tor} Exit Relays},
+  booktitle = {{PETS}},
+  year      = {2014},
+}
+
+@inproceedings{SibyJDVT20,
+  author    = {Sandra Siby and Marc Ju{\'{a}}rez and Claudia D{\'{\i}}az and Narseo Vallina{-}Rodriguez and Carmela Troncoso},
+  title     = {Encrypted {DNS} -{\textgreater} Privacy? {A} Traffic Analysis Perspective},
+  booktitle = {NDSS},
+  year      = {2020},
+}
+
+@misc{tpo-russia,
+  author       = {Gustavo Gus},
+  title        = {Responding to {Tor} censorship in {Russia}},
+  year         = {2021},
+  howpublished = {\url{https://blog.torproject.org/tor-censorship-in-russia/}, accessed 2022-06-01},
+}
+
+@misc{tpo-who-uses-tor,
+  author       = {Al Smith},
+  title        = {Tor and the humans who use it},
+  howpublished = {\url{https://blog.torproject.org/tor-and-the-humans-who-use-it/}, accessed 2022-06-01},
+}
+
+@misc{tb,
+  author       = {Mike Perry and Erinn Clark and Steven Murdoch and Georg Koppen},
+  title        = {The Design and Implementation of the {Tor Browser} {[DRAFT]}},
+  howpublished = {\url{https://2019.www.torproject.org/projects/torbrowser/design/}, accessed 2022-06-01},
+}
+
+@misc{tor-congestion,
+  author       = {Mike Perry},
+  title        = {Congestion Control Arrives in {Tor} 0.4.7-stable!},
+  howpublished = {\url{https://blog.torproject.org/congestion-contrl-047/}, accessed 2022-06-01},
+}
+
+@inproceedings{histor,
+  author    = {Akshaya Mani and Micah Sherr},
+  title     = {HisTor{\(\epsilon\)}: Differentially Private and Robust Statistics Collection for {Tor}},
+  booktitle = {NDSS},
+  year      = {2017},
+}
+
+@inproceedings{onlinewf,
+  title={Online Website Fingerprinting: Evaluating Website Fingerprinting Attacks on {Tor} in the Real World},
+  author={Cherubin, Giovanni and Jansen, Rob and Troncoso, Carmela},
+  booktitle={{USENIX Security}},
+  year={2022}
+}
diff --git a/summary/src/tlwo/src/related.tex b/summary/src/tlwo/src/related.tex
new file mode 100644
index 0000000..3521d45
--- /dev/null
+++ b/summary/src/tlwo/src/related.tex
@@ -0,0 +1,174 @@
+\section{Related Work} \label{tlwo:sec:related}
+
+Van Goethem \emph{et~al.}~\cite{timeless} originally proposed timeless timing
+attacks, showing significant improvements against HTTP/2 web servers, Tor onion
+services, and EAP-pwd.  All timeless timing attacks exploit concurrent
+processing, e.g., in HTTP/2, by filling buffers at the relay closest to an onion
+service, or packing two authentication requests in EAP-pwd into the same RadSec
+(TLS over TCP) packet. The latter was the inspiration for our timeless timing
+attack on Tor's DNS cache, i.e., packing two RESOLVE cells into a single TLS
+record.
+
+There has been a long body of work on how to safely perform measurements of the
+Tor network~\cite{privex,FenskeMJS17,privcount,histor}, laying the foundation
+for safely performing large-scale measurements~\cite{JansenTH18,ManiWJJS18}. Our
+timeless timing attack enables anyone to do network-wide measurements for exact
+domains on specific exits with a precision of at least one second.  This is
+highly invasive and a useful resource to deanonymize Tor-users, discussed
+further shortly. Our network measurements to inform the design of defenses have
+been focused around the DNS in Tor.  Similar to other related work (see below),
+we focused on how to make those limited measurements safe; not on how to broadly
+perform a much wider range of measurements safely.
+
+%% ATTACK
+Greschbach \emph{et~al.}~\cite{GreschbachPRWF17} investigated the effect of DNS on
+Tor's anonymity. They quantified the use of DNS resolvers in the network, the
+impact of choice of resolver on correlation and confirmation attacks, and how to
+incorporate observed DNS traffic with website fingerprinting
+attacks~\cite{cheng1998traffic,HerrmannWF09,Hintz02,DBLP:conf/ccs/LiberatoreL06,PanchenkoNZE11,DBLP:conf/sp/SunSWRPQ02}
+to make improved correlation attacks. In their construction, DNS traffic is used
+to either reduce the number of websites to consider during classification or to
+confirm classification. A key observation was that Tor, due to a bug, clipped
+all TTLs to 60 seconds. This was resolved and lead to the current approach of
+clipping to 300 or 3,600 seconds.  One of our short-time mitigations update
+these clips to be fuzzy.
+
+Greschbach \emph{et~al.}~\cite{GreschbachPRWF17} also measured DNS requests from
+an exit for both web and a more permissive exit policy in 2016. The collection
+was done by observing DNS requests to the exit's resolver and aggregating
+results into five-minute buckets. Similarly, we aggregate over time in 15-minute
+buckets and do not directly collect resolved domains. They found a small
+difference between exit policies, with the permissive exit having slightly fewer
+(3\% smaller median) lookups. Our results are very different: the permissive
+exit policy resulted in significantly more (double the median) lookups.
+
+Pulls and Dahlberg~\cite{wfwo} generalized the classifier confirmation attack of
+Greschbach \emph{et~al.}~\cite{GreschbachPRWF17} into a new security notion for website
+fingerprinting attacks, and further explored the use of DNS. They showed that
+timing attacks were possible in Tor's DNS cache, performing network-wide
+measurements on a domain under their control with a true positive
+rate of 17.3\% when attempting to minimize false positives. We use a similar
+method for measurements, but our attack is significantly better with a
+100\% true positive rate and no false positives at all.
+
+Sonntag collected hourly data from the resolver of an exit during five months in
+2018~\cite{sonntag-metrics,Sonntag19}. In terms of frequency, they noted about
+18.5 requests per second, with a peak of 291,472 requests in an hour. The
+average is higher than ours (3.9 and 7.8 requests per second) while the peak
+significantly smaller (1,183,275 requests in 15 minutes). Sonntag also analyzed
+the actual domains looked up, including categorization (porn, social network,
+shopping, advertisement etc). We do not collect domains; only cache-hits as part
+of popularity lists by aggregating domains into buckets like top-100, top-1k,
+etc.
+
+Mani \emph{et~al.}~\cite{ManiWJJS18} used PrivCount~\cite{privcount} and
+PSC~\cite{FenskeMJS17} to safely make extensive network-wide measurements of the
+Tor network. They measured, e.g., circuits, streams, destination ports, and exit
+domains at exits, as well as client connections, churn, composition, and
+diversity at clients. Their exit probability ranged between 1.5--2.2\%, compared
+to our peak of 0.1\%. While our data is much more limited and targeted around
+DNS, there are two interesting comparisons to consider:
+\begin{itemize}
+    % mean lookups: 17529.813 and 41099.697
+    % 15 minutes x4 = 1h, 24h per day
+    % mean exit probabilities: 0.041% and 0.049%
+    % (17529.813+41099.697)×4×24÷(0.01×(0.041+0.049)) = 6,253,814,400
+
+    \item Mani \emph{et~al.} observed 2.1 billion exit streams inferred in the
+    network every 24 hours. Extrapolating on our lookup statistics we have an
+    average of 6.3 billion lookups, which corresponds to the number of
+    streams.\footnote{Streams either do a lookup with RELAY\_BEGIN or are closed
+    after a RELAY\_RESOLVE cell. Timeout and retries are possible on resolver
+    failure, but the way we measure hides those extra lookups.} This suggests a
+    significant increase ($\approx3x$) in the number of streams in the Tor network since 2018.
+    \item Mani \emph{et~al.} measured the frequency of how well the primary
+    domain on a circuit matched the Alexa top-one-million list. We transform
+    their reported relative counts and compare it to the relative count of
+    average lookups in the same intervals in our dataset for top-10k, shown in
+    Figure~\ref{tlwo:fig:mani:popularity}. Note that this only uses data from phase
+    one of our data collection. Broadly, we see that their results show
+    significantly more traffic to top-10 than any of the lists we use. That
+    said, our data supports one of Mani \emph{et~al.}'s conclusion that the
+    popularity lists are reasonably accurate representations of traffic from the
+    Tor network.
+\end{itemize}
+
+\begin{figure}[!t]
+    \centering
+    \subfloat[][web]{%
+        \includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_popularity_match-web.pdf}
+        \label{tlwo:fig:mani:popularity:web}
+    }\\
+    \subfloat[][permissive]{%
+        \includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_popularity_match-permissive.pdf}
+        \label{tlwo:fig:mani:popularity:perm}
+    }
+    \caption{%
+    Comparison of \emph{relative popularity} of popularity rankings with the
+    results of Mani \emph{et~al.}~\cite{ManiWJJS18}.}
+    \label{tlwo:fig:mani:popularity}
+\end{figure}
+
+%% DNS prefetching paragraphs and software from there
+% Defenses can expand on DNS prefetching
+% https://datatracker.ietf.org/doc/html/rfc8767
+% https://unbound.docs.nlnetlabs.nl/en/latest/topics/serve-stale.html
+
+The relatively recent RFC 8767~\cite{rfc8767} allows for DNS data to be served
+``stale'', i.e., after expiry according to its TTL, in the exceptional
+circumstance that a recursive resolver is unable to refresh the information. In
+case data goes stale, RFC 8767 suggests serving it for at most one to three days.
+The background of RFC 8767 aptly motivates this with the saying that
+\emph{``stale bread is better than no bread''}. In addition to serving
+potentially stale data, modern resolvers like Unbound~\cite{unbound} further
+support prefetching: preemptively refreshing domains in the cache before TTL
+expiry. These measures all serve to improved reliability and have been found to
+be used for sake of resiliency~\cite{MouraHMSD18}. Tor already clips TTLs, in a
+sense serving stale data for the vast majority of domains. Our preload design
+takes this further by introducing continuous prefetching of domains on a fixed
+allowlist.
+
+Two decades ago, Jung \emph{et~al.}~\cite{jung} found that cache-hit ratios on
+the order of 80--87\% are achieved if a resolver has ten or more clients and
+TTLs are at least ten minutes.  More recently Hao and Wang~\cite{hao-and-wang}
+reported that 100k cached entries are required to achieve a baseline of 86\%
+cache-hits for a first-come first-serve cache in a university network.  Their
+dataset had similar characteristics to a DNS trace collected for an ISP resolver
+by Chen \emph{et~al.}~\cite{chen} with regards to \emph{disposable domains} that
+are never requested more than once in the long-tail of DNS; out of the 11\% of
+domains that are not disposable, 5\% and 30\% of them have cache-hit ratios of
+at least 95\% and 80\% respectively.  It appears that fewer disposable domains
+are resolved in Tor because the observed cache sizes are not large enough for
+89\% unique lookups.  Achieving an 80\% cache-hit ratio with a cache of 10k
+entries does not seem to be an outlier.
+
+% Chen et al. (2014), DNS noise: Measuring the pervasiveness of disposable domains in modern DNS traffic
+% - ISP data set from end of 2011
+% - Fig 3, long-tail of domains with no additional look-ups (89%)
+% - Fig 4, cache hit distribution
+% - Fig 7, 30% of all non-unique domain names have at least 80% cache hit ratio
+% and 5% have at least 95% cache-hit ratios.
+%
+% Hao and Wang. (2017) Exploring Domain Name Based Features on the Effectiveness of DNS Caching
+% - University data set
+% - "we observe that a size of 100,000 entries would have a cache hit rate of about 86%"
+% - (context is to use this baseline for other policies than fifo/lru etc.)
+%
+% Avoiding to cache "disposable domains", i.e., domains that are only used
+% once seems to be a thing to research.  This is what Hao and Wang does.
+%
+% Jung et al. (2002) DNS Performance and the Effectiveness of Caching
+% - MIT network 80-86% cache hits, much because multiple TCP connections from
+% browsers
+% - "We find that the distribution of names is Zipf-like, which immeaditely
+% limits even the theoretical effectivness of caching"
+% - 10 min TTL yields almost the same cache-hit ratio as a longer TTL
+% - Already with 10 clients, same cache-hit ratio as 1000 clients
+%
+% https://developers.google.com/speed/public-dns/docs/performance
+% - "While a few sites (and consequently DNS names) are very popular, most are of
+% interest to only a few users and are accessed rarely; so the majority of
+% requests result in cache misses"
+% - (Could not find anything about Google/Cloudflare cache-hit ratios for DNS)
+% - (Found a white paper saying 70-90%, but not a good source)
+%   - https://www.senki.org/wp-content/uploads/2017/08/213049567-How-to-Measure-Resolver-Performance.pdf
diff --git a/summary/src/tlwo/src/short.tex b/summary/src/tlwo/src/short.tex
new file mode 100644
index 0000000..6d06c86
--- /dev/null
+++ b/summary/src/tlwo/src/short.tex
@@ -0,0 +1,63 @@
+\section{Mitigations} \label{tlwo:sec:short}
+
+Until a more comprehensive defense can be deployed we propose two short-term
+mitigations that require little (fuzzy TTLs) or no (cover lookups) changes to
+Tor.  The former adds some uncertainty with regards to when a domain was added
+to an exit's DNS cache. The latter can remove or reduce the attacker's ability
+to conduct attacks against specific domains but is limited in its scalability.
+
+\subsection{Fuzzy TTLs} \label{tlwo:sec:short:fuzzy}
+Recall that it is possible to determine when a domain was inserted into an
+exit's DNS cache (Section~\ref{tlwo:sec:attack:detailed}) once you know the time $t$
+when the timeless timing attack started, the duration until the domain was no
+longer cached $x$ (repeated probes), and the expected clip value
+$\mathsf{clipped\_ttl}$ of the domain.  The idea of fuzzy TTLs is to add
+uncertainty by randomizing the length of time that an entry is cached.
+
+In more detail, keep Tor's DNS cache as-is but sample the cache duration
+uniformly at random from $[m, \mathsf{clipped\_ttl}]$, where $m$ is the minimum
+duration to cache.  Upon observing the exact time of removal $t+x$, the attacker
+now learns that the domain has been in the cache for the duration $x$ and was
+thus cached between $[t+x-\mathsf{clipped\_ttl}, t-m]$. Note that if $m =
+\mathsf{clipped\_ttl}$, then $x = 0$; the same as in Tor today.
+
+The reality of websites is unfortunately that they consist of multiple domains,
+reducing the effectiveness of fuzzy TTLs because the attacker uses the most
+lucky sample. For a list of domains $d_1,\hdots,d_k$ that were added at the same
+time with identical clips, then $x \leftarrow \mathsf{max}(x_1,\hdots,x_k)$.
+Based on our preload list measurements presented in
+Section~\ref{tlwo:sec:long:preload}, we expect around 8--13 domains per site
+available for an attacker to potentially query for. Earlier work found
+a median of two unique domains out of ten domains in total per website on Alexa
+top 1M~\cite{GreschbachPRWF17}.
+
+Fuzzy TTLs are an ineffective mitigation if the attacker just wants to confirm
+suspected activity with a low base rate, i.e., the mere existence of cached
+domains anywhere in the network is enough of a signal~\cite{wfwo}. Fuzzy TTLs
+are a plus for websites that are modestly popular in the network, since the
+attacker has to determine which of several exits with cached domains is the
+correct one. Having to consider multiple domains and exits (to narrow down the
+exact time) is more noisy in the network and increases the risk of
+detection~\cite{AumannL07}. Attackers may be forced to consider a time-window of
+several seconds or even minutes, which is a big win for defending against
+correlation and confirmation attacks~\cite{GreschbachPRWF17,wfwo}.
+
+\subsection{Cover Lookups}
+The idea of the cover lookups mitigation is to simply inject domains into DNS
+caches in the Tor network to create false positives.   Injected domains must be
+indistinguishable from domains cached from real Tor user activity. For this, a
+distribution that models website visits for a particular base rate should be
+used rather than running, e.g., a deterministic cron job.  Further, care has to
+be taken to capture all predictable domains for each website to defend.
+
+A more drastic mitigation would be to keep a site's domains cached at every exit
+all the time, e.g., by running \texttt{exitmap}~\cite{exitmap} every five
+minutes. This obviously scales poorly.  The network overhead would already be
+significant for a few hundred sites, e.g., estimates based on Alexa top-1k would
+add about 26.7~requests per second to each exit.
+
+Cover lookups do not scale, even if just injected at few exits probabilistically
+according to some target base rate. It is a last resort mitigation for site
+operators that fear that their users are targeted by motivated attackers and
+where, for some reason, the site cannot transition to being completely (no
+resources loaded from other domains) hosted as an onion service.
diff --git a/summary/src/tlwo/src/tor-cache.tex b/summary/src/tlwo/src/tor-cache.tex
new file mode 100644
index 0000000..392b755
--- /dev/null
+++ b/summary/src/tlwo/src/tor-cache.tex
@@ -0,0 +1,167 @@
+\section{Tor's DNS Cache Today} \label{tlwo:sec:torcache}
+
+To better understand the DNS cache of Tor today, we set out to collect
+performance metrics from exits in the live Tor network.
+Section~\ref{tlwo:sec:torcache:ethics} covers ethical considerations, followed by
+data collection in Section~\ref{tlwo:sec:torcache:collection} and resulting metrics
+in Section~\ref{tlwo:sec:torcache:metrics}.
+
+\subsection{Ethical Considerations} \label{tlwo:sec:torcache:ethics}
+
+We submitted a proposal to the Tor Research Safety Board describing measurements
+that would ultimately inform the design of a long-term defense
+(Section~\ref{tlwo:sec:long}) against our improved attack (Section~\ref{tlwo:sec:attack}).
+To be able to assess the impact of the defense we needed to better understand
+the DNS cache Tor has today as a baseline. After a couple of iterations with the
+Tor Research Safety Board we reached consensus, and then successfully completed
+our university's ethical review process. The proposal also included measurements
+needed for our defense, described later in
+Section~\ref{tlwo:sec:long:preload:collection}. During the measurements period of
+four months we consulted the Tor Research Safety Board to discuss our results.
+
+The intuition of our measurement is as follows.  Two exit relays are operated to
+collect counters related to domain lookups.  For example, the number of lookups
+and cache hits (Section~\ref{tlwo:sec:torcache:collection}). These counters are the
+result of all traffic at the exit, aggregated over 15 minutes intervals before
+being written to disk and then reset in memory. Based on an exit probability of
+about $0.0005$ ($\approx 100$Mbit/s), we extrapolated from the measurements of
+Mani \emph{et~al.}~\cite{ManiWJJS18} that we should expect about 725 website
+visits during 15 minutes.  Each website visit typically triggers multiple domain
+lookups~\cite{GreschbachPRWF17} that affect our global counters.  A collection
+interval of 15 minutes should thus aggregate hundreds of website visits for a
+small fraction of the network, making the resulting dataset hardly useful for an
+attacker performing correlation or confirmation attacks on the network.
+This sketch appears to be confirmed by our measurement results: out of 23,632
+15-minute intervals, only 18 contained less than 1,000 lookups.  
+Our conclusion together with the Tor Research Safety Board was that the
+resulting dataset should be safe to make public (further discussed later).
+
+\subsection{Data Collection} \label{tlwo:sec:torcache:collection}
+
+Two 100 Mbit/s exit relays were operated by volunteers on the premises of
+DFRI\footnote{More information about DFRI can be found at their website:
+\url{https://www.dfri.se}.}
+from May 2 until September 3, 2022.  One exit was configured in its exit policy
+with \emph{web} ports.\footnote{%
+	Reject all ports except 80 and 443.  (The exit can still do DNS for users.)
+} The other relay was configured with
+\emph{permissive} ports to also allow non-web traffic.\footnote{%
+	Allow all ports except 25, 119, 135--139, 445, 563, 1214, 4661--4666,
+	6346--6429, 6699, and 6881--6999.
+}  Otherwise the two exits were identical,
+running on the same VM with a dedicated \texttt{unbound} process that had
+caching disabled by setting the \texttt{rrset-cache-size} to zero (to avoid TTL
+biases). We collected the following counters every 15 minutes at both exits:
+
+\begin{description}
+	\item[timestamp] UNIX timestamp when the data was collected.
+	\item[lookups] Total number of observed domain lookups.
+	\item[hits\_5m] Number of cache hits with a TTL of 300 seconds.
+	\item[hits\_60m] Number of cache hits with a TTL of 3,600 seconds.
+	\item[hits\_pending] Number of cache hits with a pending resolve, i.e.,
+		an answer has been requested but is not yet available.
+	\item[hits\_same\_circuit] Number of streams that looked up a domain
+		that was previously looked up on the same circuit. 
+	\item[num\_cache\_entries] Number of entries in Tor's DNS cache.
+\end{description}
+
+A timestamp is needed to plot metrics as a function of time.  Timestamps are
+also crucial for the additional counters described in
+Section~\ref{tlwo:sec:long:preload:collection}.  The number of lookups and different
+types of cache hits are needed to get a baseline of cache-hit ratios.  The
+number of entries in Tor's DNS cache (at the time of collection) is needed to
+get a baseline of memory usage. The necessary Tor changes to collect all metrics
+(including Section~\ref{tlwo:sec:long:preload:collection}) were relatively modest:
+400 lines of code.
+
+\subsection{Metrics} \label{tlwo:sec:torcache:metrics}
+
+Regarding lookups per 15 minutes, the web exit processed a mean of 17,530 and
+median of 13,393 lookups (Figure~\ref{tlwo:fig:metrics:lookweb}), and the permissive
+exit processed a mean of 41,100 and median of 26,940 lookups
+(Figure~\ref{tlwo:fig:metrics:lookperm}). The permissive exit policy results in
+significantly more lookups. Around August 1, our exits experienced downtime,
+visible as dips in lookups in both figures (at times fewer than 1,000 lookups,
+as noted in Section~\ref{tlwo:sec:torcache:ethics}). Exit probability is weakly
+correlated with lookups: Pearson correlation 0.30 (web) and 0.16 (permissive).
+
+\begin{figure}[!t]
+	\centering
+	\subfloat[][web]{%
+		\includegraphics[width=.5\columnwidth]{src/tlwo/img/plot_lookups-web.pdf}
+		\label{tlwo:fig:metrics:lookweb}
+	}
+	\subfloat[][permissive]{%
+		\includegraphics[width=.5\columnwidth]{src/tlwo/img/plot_lookups-permissive.pdf}
+		\label{tlwo:fig:metrics:lookperm}
+	}
+	\caption{Lookups every 15 minutes and exit probability.}
+	\label{tlwo:fig:lookups}
+\end{figure}
+
+Figures~\ref{tlwo:fig:metrics:cacheweb} and~\ref{tlwo:fig:metrics:cacheperm} show the
+number of entries in Tor's DNS cache.  The web exit has a mean of 7,672 and
+median of 7,325 entries, and the permissive exit a mean of 12,130 and median of
+11,408 entries. Both appear relatively stable compared to the number of lookups
+(note log-scale y-axis in Figure~\ref{tlwo:fig:lookups}).  Likely, this is
+because traffic on the Tor network is not uniformly distributed, but rather
+concentrated to relatively few destinations, e.g., as shown with website
+popularity~\cite{ManiWJJS18}.
+
+\begin{figure}[!t]
+	\centering
+	\subfloat[][web]{%
+		\includegraphics[width=.5\columnwidth]{src/tlwo/img/plot_cache_entries-web.pdf}
+		\label{tlwo:fig:metrics:cacheweb}
+	}
+	\subfloat[][permissive]{%
+		\includegraphics[width=.5\columnwidth]{src/tlwo/img/plot_cache_entries-permissive.pdf}
+		\label{tlwo:fig:metrics:cacheperm}
+	}
+	\caption{Cache entries every 15 minutes.}
+	\label{tlwo:fig:cache}
+\end{figure}
+
+Central to a DNS cache is its \emph{cache-hit} ratio: how often lookups can be
+resolved using cached entries instead of asking DNS resolvers.
+Figures~\ref{tlwo:fig:metrics:hitsweb} and~\ref{tlwo:fig:metrics:hitsperm} show the
+cache-hit ratios for the two exits, with a mean cache-hit ratio of 0.80 (web)
+and 0.83 (permissive). We also show if the cache hits occurred due to a cache
+entry used earlier on the same circuit (``same'') or from another circuit
+(``shared''). Further, over all the cache hits, we show if the hits were because
+of DNS entries with a five-minute cached TTL (``5min''), a 60-minute cached TTL
+(``60min''), or pending entries in the DNS cache (``pending''). Same circuit
+hits are likely due to Tor Browser improving performance by creating multiple
+streams to the same destination. The cross-circuit cache-hit ratio is much
+smaller (``shared'') with a mean of 0.11 (web) and 0.17 (permissive). We return
+to these ratios in Section~\ref{tlwo:sec:long:evaluation} to compare with our
+defense.
+
+\begin{figure}[!t]
+	\centering
+	\subfloat[][web]{%
+	\includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_cache_hits-web.pdf}
+	\label{tlwo:fig:metrics:hitsweb}
+	}\\
+	\subfloat[][permissive]{%
+	\includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_cache_hits-permissive.pdf}
+	\label{tlwo:fig:metrics:hitsperm}
+	}
+	\caption{%
+		Cache-hit ratio every 15 minutes. The total ratio can be split
+		by same+shared hits or 60min+5min+pending hits.
+	}
+	\label{tlwo:fig:hits}
+\end{figure}
+
+During the four months of measurements, our exits experienced sporadic downtime
+(early August) and the Tor-network endured significant network DDoS
+activities~\cite{network-ddos}. This shows in our data, e.g., with the drop to
+close to zero lookups in Figure~\ref{tlwo:fig:lookups}, huge spikes of cached entries
+in Figure~\ref{tlwo:fig:cache}, and periods where the cache-hit ratio was almost
+one in Figure~\ref{tlwo:fig:hits}.
+
+To summarize, Tor's DNS cache has a cache-hit ratio over 80\% using a modestly
+sized DNS cache.  About 11--17\% of these hits are due to sharing the cache
+across circuits.  The number of lookups are weakly correlated to exit
+probability.
author	Rasmus Dahlberg <rasmus@rgdd.se>	2024-10-15 16:08:16 +0200
committer	Rasmus Dahlberg <rasmus@rgdd.se>	2024-10-15 16:08:16 +0200
commit	385cc92bc91e1a6c3724085c060e76bf40c13ed3 (patch)
tree	26d0a8f81f2caa472830fd40a51844bb202c1355 /summary