commit 87981946bb08a21fd247a1ea344fc8e36533e382 Author: Karsten Loesing <karsten.loesing@gmx.net> Date: Wed Oct 24 11:11:11 2012 -0400 Add new report on counting daily bridge users. --- 2012/counting-daily-bridge-users/.gitignore | 3 + 2012/counting-daily-bridge-users/bridgesets.pdf | Bin 0 -> 26476 bytes .../compare-totalusers-q3-2012.pdf | Bin 0 -> 6366 bytes .../compare-totalusers.pdf | Bin 0 -> 10156 bytes 2012/counting-daily-bridge-users/consensuses.pdf | Bin 0 -> 6512 bytes .../counting-daily-bridge-users.bib | 30 ++ .../counting-daily-bridge-users.tex | 533 ++++++++++++++++++++ .../extrapolated-responses.pdf | Bin 0 -> 13134 bytes .../responses-single-bridges.png | Bin 0 -> 37038 bytes 2012/counting-daily-bridge-users/responses.pdf | Bin 0 -> 7211 bytes 2012/counting-daily-bridge-users/syusers.pdf | Bin 0 -> 7460 bytes 2012/counting-daily-bridge-users/tortechrep.cls | 1 + .../totalusers-q3-2012.pdf | Bin 0 -> 5307 bytes 2012/counting-daily-bridge-users/totalusers.pdf | Bin 0 -> 7185 bytes 14 files changed, 567 insertions(+), 0 deletions(-) diff --git a/2012/counting-daily-bridge-users/.gitignore b/2012/counting-daily-bridge-users/.gitignore new file mode 100644 index 0000000..b36a48e --- /dev/null +++ b/2012/counting-daily-bridge-users/.gitignore @@ -0,0 +1,3 @@ +counting-daily-bridge-users.pdf +counting-daily-bridge-users-2012-10-24.pdf + diff --git a/2012/counting-daily-bridge-users/bridgesets.pdf b/2012/counting-daily-bridge-users/bridgesets.pdf new file mode 100644 index 0000000..2328f54 Binary files /dev/null and b/2012/counting-daily-bridge-users/bridgesets.pdf differ diff --git a/2012/counting-daily-bridge-users/compare-totalusers-q3-2012.pdf b/2012/counting-daily-bridge-users/compare-totalusers-q3-2012.pdf new file mode 100644 index 0000000..5539e94 Binary files /dev/null and b/2012/counting-daily-bridge-users/compare-totalusers-q3-2012.pdf differ diff --git a/2012/counting-daily-bridge-users/compare-totalusers.pdf b/2012/counting-daily-bridge-users/compare-totalusers.pdf new file mode 100644 index 0000000..180a6ea Binary files /dev/null and b/2012/counting-daily-bridge-users/compare-totalusers.pdf differ diff --git a/2012/counting-daily-bridge-users/consensuses.pdf b/2012/counting-daily-bridge-users/consensuses.pdf new file mode 100644 index 0000000..916711d Binary files /dev/null and b/2012/counting-daily-bridge-users/consensuses.pdf differ diff --git a/2012/counting-daily-bridge-users/counting-daily-bridge-users.bib b/2012/counting-daily-bridge-users/counting-daily-bridge-users.bib new file mode 100644 index 0000000..1037cbc --- /dev/null +++ b/2012/counting-daily-bridge-users/counting-daily-bridge-users.bib @@ -0,0 +1,30 @@ +@techreport{tor-2012-04-001, + author = {Karsten Loesing}, + title = {What fraction of our bridges are not reporting usage statistics?}, + institution = {The Tor Project}, + number = {2012-04-001}, + year = {2012}, + month = {April}, + note = {\url{https://research.torproject.org/techreports/bridge-report-usage-stats-2012-04-30.pdf}}, +} + +@techreport{tor-2010-11-001, + author = {Sebastian Hahn and Karsten Loesing}, + title = {Privacy-preserving Ways to Estimate the Number of {Tor} Users}, + institution = {The Tor Project}, + number = {2010-11-001}, + year = {2010}, + month = {November}, + note = {\url{https://research.torproject.org/techreports/countingusers-2010-11-30.pdf}}, +} + +@inproceedings{loesing2010case, + title = {A Case Study on Measuring Statistical Data in the {Tor} Anonymity Network}, + author = {Karsten Loesing and Steven J. Murdoch and Roger Dingledine}, + booktitle = {Proc.\ Workshop on Ethics in Computer Security Research}, + year = {2010}, + month = Jan, + address = {Tenerife, Canary Islands, Spain}, + note = {\url{https://metrics.torproject.org/papers/wecsr10.pdf}}, +} + diff --git a/2012/counting-daily-bridge-users/counting-daily-bridge-users.tex b/2012/counting-daily-bridge-users/counting-daily-bridge-users.tex new file mode 100644 index 0000000..81eca55 --- /dev/null +++ b/2012/counting-daily-bridge-users/counting-daily-bridge-users.tex @@ -0,0 +1,533 @@ +\documentclass{tortechrep} +\usepackage{url} +\usepackage{graphicx} +\begin{document} + +\title{Counting daily bridge users} +\author{Karsten Loesing} +\contact{karsten@torproject.org} +\reportid{2012-10-001} +\date{October 24, 2012} +\maketitle + +\begin{abstract} +As part of the Tor Metrics Project, we want to learn how many people use +the Tor network on a daily basis. +Counting users in an anonymity network is, obviously, a difficult task +for which we cannot collect too sensitive usage data. +We came up with a privacy-preserving approach for estimating directly +connecting user numbers by counting requests to the directory mirrors and +deriving approximate user numbers from there. +In this report we describe a modified approach for estimating the number +of users connecting via bridges by evaluating directory requests made to +bridges. +We compare this new approach to our current approach that estimates bridge +user numbers from total unique IP addresses seen at bridges. +We think that results from the new approach are closer to reality, even +though that means there are significantly fewer daily bridge users than +originally expected. +\end{abstract} + +\section{Introduction to our new approach to count bridge users} + +In this report we describe a new approach for estimating the number of +daily users connecting to the Tor network via a bridge. +This new approach uses counts of directory requests made to bridges as its +main data sources. +This is similar to how we estimate daily directly connecting users that +connect to the Tor network via a non-bridge relay. +Our current approach for estimating daily bridge users is to count unique +IP addresses of connecting clients at bridges. +We refer to our earlier report~\cite{tor-2010-11-001} for an overview of +estimating user numbers in the Tor network. + +We estimate daily bridge users by first summing up directory requests per +day reported by bridges (Section~\ref{sec:reports}). +We extrapolate these reported requests to the expected total number of +directory requests in the network (Section~\ref{sec:requests}). +We then assume that there is an average number of 10 directory requests +that every client makes per day and derive daily user numbers by dividing +by that average number (Section~\ref{sec:users}). +We further derive users per country by including country information of +connecting IP addresses (Section~\ref{sec:country}). +There are at least two ways to remove unwanted artifacts from results: +we may have to ignore reports from bridges that have been running as +non-bridge relays and that might still report directly connecting users +(Section~\ref{ref:nonbridge}); +and we may need to ignore days when there were problems with the consensus +process, leading to an increase in directory requests which is likely not +caused by an actual increase in users (Section~\ref{ref:consensus}). + +\section{Counting reported directory requests to bridges per day} +\label{sec:reports} + +All relays running a recent enough Tor version contain code to collect and +report statistics on processed directory requests over 24-hour periods. +We refer to our previous work~\cite{loesing2010case} for more details on +aggregating usage statistics in Tor. + +Bridges were originally not supposed to report directory request +statistics, because bridge users were estimated based on unique IP address +counts, and we wanted to avoid collecting any more data than needed. +But due to a bug, only part of directory request statistics were +suppressed when running in bridge relay mode. +As a result, bridges report a trimmed version of directory request +statistics, which are however still enough to estimate daily users. +As an example, the following directory request statistics were reported by +a bridge in September 2012. + +%All examples come from descriptor FE2E5A0E7B15F5C1E102791BC957A6F9BE9DDC2E +\begin{quotation}\noindent\footnotesize +\texttt{% +extra-info goinpostal 7363FF835F5D79EA1F0CC2EB757B03866D4515F7\\ +dirreq-stats-end 2012-09-18 15:26:38 (86400 s)\\ +dirreq-v3-resp ok=5040,not-enough-sigs=0,unavailable=0,not-found=0,not-modified=0,busy=0} +\end{quotation} + +From this example we learn that this bridge successfully processed 5,040 +version 3 directory requests in the 24 hours preceding September 18, 2012, +15:26:38 UTC. +We have no information how many of these requests happened in the 8.5 +hours of September 17 or in the 15.5 hours of September 18. +We assume a uniform distribution of requests over the 24-hour interval and +count 1,797 requests for September 17 and 3,243 requests for September 18. +We extract these data points for all bridges publishing their descriptors +to the bridge authority and sum up responses per day. +Figure~\ref{fig:responses} contains the number of reported requests per +day. +\begin{figure} +\includegraphics[width=\textwidth]{responses.pdf} +\caption{Daily sums of directory requests reported by all bridges} +\label{fig:responses} +\end{figure} +A few observations: + +\label{lab:discuss-responses} +\begin{enumerate} +\item There were hardly any reported requests until September 2011. +The likely explanation is that, before Tor version 0.2.3.1-alpha, +collecting and reporting directory request statistics was disabled by +default. +This default was changed in Tor version 0.2.3.1-alpha which was released +on May 5, 2011. +With more and more bridges upgrading to the 0.2.3 series, the number of +reported directory requests increased, too. +\item The reported request numbers in September and October 2011 have +quite high volatility, making it difficult to use these request numbers +for actual user number estimates. +\item There are at least three unusual spikes in request numbers in +November 2011, January 2012, and April 2012, which were unlikely caused by +sudden increases and decreases in user numbers. +\item From November 2011 on, there is a general downward trend from around +60,000 requests per day to just 30,000 in September 2012. +\end{enumerate} + +\section{Extrapolating to total directory requests in the network} +\label{sec:requests} + +So far, we only know how many directory requests were processed by the +bridges reporting them. +We need to take into account that not all bridges report these statistics +for various reasons: +bridges may not be configured to report directory request statistics, +which in particular applies to bridges running an earlier version than +0.2.3.1-alpha; +bridges may run for less than 24 hours, thus not finishing a 24 hour +statistics interval and discarding requests processed up to that time; +bridges may have finished a 24-hour statistics interval, but went offline +before publishing statistics to the bridge authority. +(We analyzed in more detail what fraction of our bridges are not reporting +usage statistics in~\cite{tor-2012-04-001}.) +As a result, we need to extrapolate reported requests to what we expect as +the total number of requests in the network. + +A straight-forward way to extrapolate to the total number of directory +requests in the network would be to make the following assumption: +every bridge that does not report directory request statistics, on +average, processes as many directory requests as a bridge that reports +them. +Under this assumption, we could count the number of running bridges per +day and the number of bridges reporting directory request statistics, +compute the fraction of reporting bridges, and divide reported requests by +that fraction. +This assumption works fine as long as the variance between request numbers +processed by bridges is small, or as long as the fraction of reporting +bridges is high. +However, the former is not the case, because there are some hard-coded +bridge addresses in bundles distributed on the Tor website, leading to +these bridges processing and maybe reporting far more directory requests +than others. +The latter is not always the case either, in particular before September +2011, as we could see in Figure~\ref{fig:responses}. + +A better way to extrapolate to total requests in the network is to +consider a second statistic published by a subset of bridges: the number +of bytes written to respond to directory requests. +We assume that this number is proportional to the number of processed +directory requests, even though we do not assume an exact linear relation. +The subset of bridges reporting byte statistics is not necessarily the +same subset thas is reporting directory request statistics. +By taking into account byte histories, we can better estimate how many +directory requests have not been reported by bridges that at least have +reported byte histories. +An example for reported written directory bytes, coming from the same +extra-info descriptor as the example above, is as follows: + +\begin{quotation}\noindent\footnotesize +\texttt{% +extra-info goinpostal 7363FF835F5D79EA1F0CC2EB757B03866D4515F7\\ +dirreq-write-history 2012-09-19 05:17:32 (900 s) 13370368,10539008,56751104,27235328,\\ +14555136,10524672,63341568,37339136,24343552,22490112,29155328,17792000,3502080,[...]} +\end{quotation} + +From these write histories we can extract how many bytes a bridge has +spent on answering directory requests on a given day. +By looking at the reported directory request history values, we can learn +how many bytes were written while the bridge was also collecting and later +reporting directory request statistics, and we can learn how many bytes +were written outside of those statistics intervals. +Similarly, we can learn how many directory requests were processed at +times when the bridge did not report byte histories. + +On a side note, as one can see from the example, byte history intervals +are only 15 minutes long and thereby much shorter than directory request +statistics intervals. +It might be that this level of detail has privacy implications, in +particular on bridges with only very few users. +We probably don't need byte histories on this level of detail. +We leave the analysis what level of detail is required as future work. +Results could lead to increasing the history interval length on bridges to +1 hour or more. + +In the following, we define $R$ as the subset of bridges reporting +directory request statistics, $H$ as the subset reporting byte histories, +and $N$ as the entire set of bridges in the network. +Figure~\ref{fig:bridgesets} illustrates these subsets and the variable +names. +Also, we define $r()$ as the number of directory requests reported by a +given set of bridges, $h()$ as the number of bytes reported by the bridges +in a given set, and $n()$ as the absolute number of bridges in a set. + +\begin{figure} +\centering +\includegraphics[width=.5\textwidth]{bridgesets.pdf} +\caption{Subsets of bridges reporting write histories and directory +request statistics} +\label{fig:bridgesets} +\end{figure} + +Knowing the number of reported directory requests, $r(R)$, we can +extrapolate to the expected total number of directory requests, $r(N)$, by +multiplying with the reciprocal of the fraction of written directory +requests that got reported to us, $\frac{h(N)}{h(R)}$: + +\begin{equation} +r(N) = r(R) \times \frac{h(N)}{h(R)} +\end{equation} + +Estimating total written directory request bytes in the network, $h(N)$, +is easy. +We assume here that the bridges that didn't report directory request bytes +wrote the same number of bytes per bridge on average as reporting bridges. + +\begin{equation} +h(N) = h(H) \times \frac{n(N)}{n(H)} +\label{equation} +\end{equation} + +Estimating written directory request bytes by the bridges that reported +directory request statistics, $h(R)$, is somewhat harder. +We first split the set into the set of bridges reporting both statistics +and the set of bridges reporting only statistics and no write histories. + +\begin{equation} +h(R) = {h(R \cap H) + h(R \setminus H)} +\end{equation} + +The first number is something we can read from the descriptors. +The second number requires us to apply the same assumption from above, +namely that bridges that didn't report byte histories wrote the same +number of bytes, on average, as reporting bridges. +(Note how this equation is very similar to equation \ref{equation}.) + +\begin{equation} +h(R \setminus H) = h(H) \times \frac{n(R \setminus H)}{n(H)} +\end{equation} + +Putting everything together, we come up with a way to compute estimated +directory requests in the network: + +\begin{equation} +r(N) = r(R) \times \frac{h(H) \times n(N)}{h(R \cap H) \times n(H) + h(H) \times n(R \setminus H)} +\end{equation} + +Figure~\ref{fig:totalrequests} +\begin{figure}[t] +\includegraphics[width=\textwidth]{extrapolated-responses.pdf} +\caption{Reported directory requests, estimated fraction of bridges +reporting directory requests, and estimated directory requests in the +network} +\label{fig:totalrequests} +\end{figure} +shows reported directory requests, estimated +fraction of directory requests that got reported by bridges, and estimated +total directory requests in the network. +A few observations: + +\begin{enumerate} +\item The top-most graph is the same as in Figure~\ref{fig:responses} which +we already discussed on page~\pageref{lab:discuss-responses}. +\item The middle graph shows an upwards trend of the fraction of bridges +reporting directory request statistics. +Fractions of under 25\% as seen until end of October 2011 make it +difficult to extrapolate to the total number of requests in the network. +These fractions also explain the observed volatility of reported requests +until end of October 2011. +Beginning with November 2011, fractions are at 50\% or higher, exceeding +75\% in most of 2012. +\item The bottom-most graph is the result of dividing request numbers in +the top-most graph by fractions in the middle graph. +The low fractions in late August and early September 2011 lead to very +high estimated total requests in the network. +We'll want to treat these surprisingly high numbers with care, but so far, +there is no reason to believe they're totally wrong. +From November 2011 to September 2012, the continuously decreasing reported +request numbers combined with the increasing fraction of reported requests +lead to a continuous decrease in estimated directory requests in the +network. +From this graph it seems that bridge usage has steadily decreased in the +past 11 months. +\end{enumerate} + +\section{Dividing by 10 for estimating number of users} +\label{sec:users} + +With the estimated number of daily directory requests in the network we +can now estimate the number of daily users. +We make the assumption that there is an average number of directory +requests per day that every client makes to keep their network information +up-to-date. +As of writing this report, network status consensuses are fresh for three +hours, requiring clients to download a new document every 2 to 3 hours. +Hence, a client that is online all day would make 8 to 12 directory +requests on that day. +Not all clients are online all day, thus reducing the average number of +directory requests made by clients. +We, somewhat arbitrarily, chose 10 as the number of directory requests +that the average client makes every day. +10 is also the number that we use in directly connecting user statistics, +so that both estimates for non-censored and censored users will be easy +to compare. +We could evaluate whether 10 is a good number by asking volunteers to have +their Tor clients record directory request numbers made on a given day, +and use these actual numbers to come up with a better number. +But given that we apply the same number of requests per client to all +days, the actual value does not influence development over time, allowing +us to observe trends over time and still have a rough idea of absolute +numbers. + +Now we can derive user numbers from total directory requests in the +network. +Figures~\ref{fig:totalusers} and \ref{fig:totalusers-q3-2012} +show the total number of users connecting via bridges over time, for the +entire period for which we have data and for the third quarter of 2012. +These graphs contain the same data as the bottom-most graph in +Figure~\ref{fig:totalrequests}, but divided by 10. +The most surprising result is that there are only 3,500 daily bridge users +these days. + +\begin{figure} +\includegraphics[width=\textwidth]{totalusers.pdf} +\caption{Estimated daily bridge users from all countries from July 2011 to +September 2012} +\label{fig:totalusers} +\end{figure} +\begin{figure} +\includegraphics[width=\textwidth]{totalusers-q3-2012.pdf} +\caption{Estimated daily bridge users from all countries in the third +quarter of 2012} +\label{fig:totalusers-q3-2012} +\end{figure} + +\section{Breaking down to user numbers by country} +\label{sec:country} + +So far, we only have an estimate of daily bridge users in the network, but +no user numbers per country. +In contrast to directory request statistics reported by relays, bridges +do not report request numbers by country code. +But we still have statistics on originating countries in the unique IP +address statistics reported by bridges. +These are the statistics we have been using for estimating daily bridge +users so far. +We assume that the country distribution of connecting bridge clients is +similar to bridge clients downloading directory requests. +As an example, these are the statistics on connecting clients reported by +the same bridge from earlier examples: + +\begin{quotation}\noindent\footnotesize +\texttt{% +extra-info goinpostal 7363FF835F5D79EA1F0CC2EB757B03866D4515F7\\ +bridge-stats-end 2012-09-18 15:27:00 (86400 s)\\ +bridge-ips ir=32,??=16,at=8,eg=8,jp=8,lv=8,pk=8,us=8} +\end{quotation} + +We sum up unique IP addresses and calculate a fraction of IP addresses for +every country and day. +(We could also have weighted country information of reporting bridges with +the bridge's fraction of written directory request bytes, but this seemed +like overkill for this analysis, so we left it for future work.) +We multiply the estimated number of total users in the network with the +fraction of unique IP addresses coming from a country and come up with the +estimated number of users in that country. +Figure~\ref{fig:syusers.pdf} shows the result for estimated daily bridge +users coming from Syria. +We chose Syria for this example, because that's one of the countries with +most bridge users these days. +The approach would work for all other countries, too. + +\begin{figure} +\includegraphics[width=\textwidth]{syusers.pdf} +\caption{Estimated daily bridge users from Syria} +\label{fig:syusers.pdf} +\end{figure} +\section{Ignoring bridges that were running as non-bridge relays} + +\label{ref:nonbridge} + +One aspect that we have been ignoring so far is that there are bridges +that were running as non-bridge relays before. +It is likely that these bridges report directory requests coming from +directly connecting clients of which there are far more than bridge +clients. + +Figure~\ref{fig:responses-single-bridges} shows reported directory +requests of bridges that have or have not been seen as non-bridge relays. +The focus here is on data points which are seemingly outliers. +Two noteworthy examples are the 30,000+ requests in April 2012 and the +25,000+ requests in September 2012. + +In our current approach to count daily bridge users, we ignore any such +bridge, because they could skew results. +We'd like to exclude data points coming from bridges that report +unrealistic statistics. +However, it seems that ignoring all bridges that have been seen as +non-bridge relays would mean removing too many data points. +More research is needed to define criteria when a data point probably +contains directory requests by non-bridge clients and should be ignored. + +\begin{figure} +\includegraphics[width=\textwidth]{responses-single-bridges.png} +\caption{Reported directory requests by bridges that have or have not been +seen as non-bridge relays} +\label{fig:responses-single-bridges} +\end{figure} + +\section{Ignoring days with too few network status consensuses} +\label{ref:consensus} + +A closer look at spikes in total estimated directory requests and at +archives of network status consensuses reveals an interesting correlation: +in 4 out of 5 cases when less than 20 consensuses were published on a given +day, the number of directory requests went up a lot. +Figure~\ref{fig:consensuses} shows the number of published consensuses per +day. + +\begin{figure} +\includegraphics[width=\textwidth]{consensuses.pdf} +\caption{Published consensuses per day} +\label{fig:consensuses} +\end{figure} + +By default, the directory authorities publish a new consensus every hour. +Missing consensuses indicate a problem with the consensus process, meaning +that the available consensuses become outdated and that clients send out +more requests to get a recent enough consensus, thus raising the number of +directory requests in the network. + +We could decline providing bridge usage statistics for days when the +archives had less than 20 consensuses. +This would fix the spike in late November 2011 and especially the huge one +in early January 2012. +However, we decided not to remove these days yet and left it as future +work to analyze how we can detect problems with the consensus process +leading to higher directory request numbers. + +\section{Comparing old and new approaches to count bridge users} + +We briefly compare results from our new approach based on directory +requests to results from our existing approach based on unique IP +addresses. +Figures~\ref{fig:compare-totalusers} and +\ref{fig:compare-totalusers-q3-2012} show the estimates of daily bridge +users in the new and in the old approach, for the entire observed period +and for the third quarter of 2012. +The general trend is about the same, though the new +approach only outputs about one tenth as many daily bridge users as the old +approach did. +We think that results from the new approach are closer to reality, because +the reasoning behind it is much more plausible than the design of the old +approach. +We refer to our earlier report~\cite{tor-2010-11-001} for details of the +old approach to count daily bridge users including a discussion of its +weaknesses. + +\begin{figure}[t] +\includegraphics[width=\textwidth]{compare-totalusers.pdf} +\caption{Estimated daily bridge users in the new and in the old approach +from July 2011 to September 2012} +\label{fig:compare-totalusers} +\end{figure} + +\begin{figure}[t] +\includegraphics[width=\textwidth]{compare-totalusers-q3-2012.pdf} +\caption{Estimated daily bridge users in the new and in the old approach +in the third quarter of 2012} +\label{fig:compare-totalusers-q3-2012} +\end{figure} + +\section{Suggesting next steps} + +We identified a few starting points for further improving the described +approach in this report: + +\begin{itemize} +\item We should re-run the analysis under the assumption that bridges use +a larger time period for byte histories than 15 minutes. +There are potential privacy problems with seldomly used bridges reporting +usage statistics on such a high detail level. +The described approach to estimate daily users should work as well with +byte histories on a detail of a few hours. +Once we know what detail is required, we should change the default in the +Tor sources, and we could update the bridge descriptor sanitizing code to +increase the byte history interval in sanitized bridge descriptors. +\item We should evaluate whether 10 is a reasonable average number of +directory requests made by a client per day. +One way to do this evaluation is to ask volunteers to have their Tor +clients record directory request numbers made on a given day. +\item We should look closer at weighting country information reported by +bridges. +Maybe we'll have to weight unique IP address fractions by country with the +reporting bridge's written directory request byte fraction to get more +accurate user numbers by country. +\item We should further investigate how bridges that have been seen as +non-bridge relays affect the results. +If we need to ignore reported statistics by these bridges, we'll want to +make sure to only exclude as few reports as necessary. +\item We should further analyze problems with the consensus process and +how they affect directory request numbers. +Both statistics of daily directly connecting and of daily bridge users +could benefit from new insights here. +\end{itemize} + +\section*{Acknowledgements} + +Thanks to George Kadianakis for his valuable input on a draft of this +report, especially by reviewing the math part of extrapolating reported +requests to total requests in the network, and for pointing out the +potential privacy problem of too short byte history intervals. + +\bibliography{counting-daily-bridge-users} + +\end{document} + diff --git a/2012/counting-daily-bridge-users/extrapolated-responses.pdf b/2012/counting-daily-bridge-users/extrapolated-responses.pdf new file mode 100644 index 0000000..24d3fb1 Binary files /dev/null and b/2012/counting-daily-bridge-users/extrapolated-responses.pdf differ diff --git a/2012/counting-daily-bridge-users/responses-single-bridges.png b/2012/counting-daily-bridge-users/responses-single-bridges.png new file mode 100644 index 0000000..199be4e Binary files /dev/null and b/2012/counting-daily-bridge-users/responses-single-bridges.png differ diff --git a/2012/counting-daily-bridge-users/responses.pdf b/2012/counting-daily-bridge-users/responses.pdf new file mode 100644 index 0000000..f974b19 Binary files /dev/null and b/2012/counting-daily-bridge-users/responses.pdf differ diff --git a/2012/counting-daily-bridge-users/syusers.pdf b/2012/counting-daily-bridge-users/syusers.pdf new file mode 100644 index 0000000..ff52022 Binary files /dev/null and b/2012/counting-daily-bridge-users/syusers.pdf differ diff --git a/2012/counting-daily-bridge-users/tortechrep.cls b/2012/counting-daily-bridge-users/tortechrep.cls new file mode 120000 index 0000000..4c24db2 --- /dev/null +++ b/2012/counting-daily-bridge-users/tortechrep.cls @@ -0,0 +1 @@ +../../tortechrep.cls \ No newline at end of file diff --git a/2012/counting-daily-bridge-users/totalusers-q3-2012.pdf b/2012/counting-daily-bridge-users/totalusers-q3-2012.pdf new file mode 100644 index 0000000..a2d27d5 Binary files /dev/null and b/2012/counting-daily-bridge-users/totalusers-q3-2012.pdf differ diff --git a/2012/counting-daily-bridge-users/totalusers.pdf b/2012/counting-daily-bridge-users/totalusers.pdf new file mode 100644 index 0000000..1a982ef Binary files /dev/null and b/2012/counting-daily-bridge-users/totalusers.pdf differ