<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN" "journalpublishing.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xml:lang="en" article-type="research-article">
  <front>
    <journal-meta>
      <journal-id journal-id-type="publisher-id">futureinternet</journal-id>
      <journal-title>Future Internet</journal-title>
      <abbrev-journal-title abbrev-type="publisher">Future Internet</abbrev-journal-title>
      <abbrev-journal-title abbrev-type="pubmed">futureinternet</abbrev-journal-title>
      <issn pub-type="epub">1999-5903</issn>
      <publisher>
        <publisher-name>MDPI</publisher-name>
      </publisher>
    </journal-meta>
    <article-meta>
      <article-id pub-id-type="doi">10.3390/fi4020488</article-id>
      <article-id pub-id-type="publisher-id">futureinternet-04-00488</article-id>
      <article-categories>
        <subj-group>
          <subject>Article</subject>
        </subj-group>
      </article-categories>
      <title-group>
        <article-title>Distributed Performance Measurement and Usability Assessment of the Tor Anonymization Network</article-title>
      </title-group>
      
      <contrib-group>
        <contrib contrib-type="author">
          <name>
            <surname>Müller</surname>
            <given-names>Sebastian</given-names>
          </name>
          <xref rid="af1-futureinternet-04-00488" ref-type="aff">1</xref>
          <xref rid="c1-futureinternet-04-00488" ref-type="corresp">*</xref>
        </contrib>
        <contrib contrib-type="author">
          <name>
            <surname>Brecht</surname>
            <given-names>Franziska</given-names>
          </name>
          <xref rid="af2-futureinternet-04-00488" ref-type="aff">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <name>
            <surname>Fabian</surname>
            <given-names>Benjamin</given-names>
          </name>
          <xref rid="af2-futureinternet-04-00488" ref-type="aff">2</xref>
          <xref rid="c1-futureinternet-04-00488" ref-type="corresp">*</xref>
        </contrib>
        <contrib contrib-type="author">
          <name>
            <surname>Kunz</surname>
            <given-names>Steffen</given-names>
          </name>
          <xref rid="af2-futureinternet-04-00488" ref-type="aff">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <name>
            <surname>Kunze</surname>
            <given-names>Dominik</given-names>
          </name>
          <xref rid="af2-futureinternet-04-00488" ref-type="aff">2</xref>
        </contrib>
      </contrib-group>
      <aff id="af1-futureinternet-04-00488"><label>1 </label>Institute of Computer Science, Freie Universität Berlin, Takustraβe 9, 14195 Berlin, Germany</aff>
      <aff id="af2-futureinternet-04-00488"><label>2 </label>Institute of Information Systems, Humboldt-Universität zu Berlin, Spandauer Straβe 1, 10178 Berlin, Germany; Email: <email>franziska.brecht@wiwi.hu-berlin.de</email> (F.B.); <email>steffen.kunz@wiwi.hu-berlin.de</email> (S.K.); <email>dominik.kunze@wiwi.hu-berlin.de</email> (D.K.)</aff>
      <author-notes>
        <corresp id="c1-futureinternet-04-00488"><label>*</label> Authors  to whom correspondence should be addressed; Email: <email>sebastian.mueller@fu-berlin.de</email> (S.M.); <email>bfabian@wiwi.hu-berlin.de</email> (B.F.); Tel.: +49-30-838-75136; Fax: +49-30-838-75109.</corresp>
      </author-notes>
      <pub-date pub-type="epub">
        <day>15</day>
        <month>05</month>
        <year>2012</year>
      </pub-date>
      <pub-date pub-type="collection">
        <month>06</month>
        <year>2012</year>
      </pub-date>
      <volume>4</volume>
      <issue>2</issue>
      <fpage>488</fpage>
      <lpage>513</lpage>
      <history>
        <date date-type="received">
          <day>01</day>
          <month>11</month>
          <year>2011</year>
        </date>
        <date date-type="rev-recd">
          <day>02</day>
          <month>03</month>
          <year>2012</year>
        </date>
        <date date-type="accepted">
          <day>08</day>
          <month>05</month>
          <year>2012</year>
        </date>
      </history>
      <permissions>
        <copyright-statement>© 2012 by the authors; licensee MDPI, Basel, Switzerland.</copyright-statement>
        <copyright-year>2012</copyright-year>
        <license xmlns:xlink="http://www.w3.org/1999/xlink" license-type="open-access" xlink:href="http://creativecommons.org/licenses/by/3.0/">
          <p>This article is an open-access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/).</p>
        </license>
      </permissions>
      <abstract>
        <p>While the Internet increasingly permeates everyday life of individuals around the world, it becomes crucial to prevent unauthorized collection and abuse of personalized information. Internet anonymization software such as Tor is an important instrument to protect online privacy. However, due to the performance overhead caused by Tor, many Internet users refrain from using it. This causes a negative impact on the overall privacy provided by Tor, since it depends on the size of the user community and availability of shared resources. Detailed measurements about the performance of Tor are crucial for solving this issue. This paper presents comparative experiments on Tor latency and throughput for surfing to 500 popular websites from several locations around the world during the period of 28 days. Furthermore, we compare these measurements to critical latency thresholds gathered from web usability research, including our own user studies. Our results indicate that without massive future optimizations of Tor performance, it is unlikely that a larger part of Internet users would adopt it for everyday usage. This leads to fewer resources available to the Tor community than theoretically possible, and increases the exposure of privacy-concerned individuals. Furthermore, this could lead to an adoption barrier of similar privacy-enhancing technologies for a Future Internet.</p>
      </abstract>
      <kwd-group>
        <kwd>internet anonymity</kwd>
        <kwd>onion routing</kwd>
        <kwd>Tor</kwd>
        <kwd>web latency</kwd>
        <kwd>usability</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec sec-type="intro">
      <title>1. Introduction</title>
      <p>The Internet increasingly permeates everyday life of individuals around the world. On the other hand, information technology allows data analysis to a degree which was inconceivable a few years ago. Simultaneously to the increasing amount and availability of information about Internet users, new information retrieval, data mining and further technologies allow to automatically collect, filter and analyze personal information and to draw conclusions based on this process. Democratic societies should further advocate environments that respect user privacy for citizens and should support individuals who face repressive censorship to access public information without being identified or traced. In political regimes, where personal rights, the freedom of speech, and in particular free access to information is restricted, these possibilities of modern data collection can lead to persecution of individuals if their identity is unveiled. Another restraint is censorship, which may be used to restrict free access to information [<xref ref-type="bibr" rid="B1-futureinternet-04-00488">1</xref>].</p>
      <p>By using anonymization tools such as the Tor onion routing network [<xref ref-type="bibr" rid="B2-futureinternet-04-00488">2</xref>,<xref ref-type="bibr" rid="B3-futureinternet-04-00488">3</xref>], Internet users can conceal their virtual tracks to a certain degree by obfuscating their IP addresses, allowing for a more anonymous Internet access. With Tor, application messages are not directly routed to the receiver, but are encrypted and forwarded through ephemeral paths of Tor relays through an overlay network, using more complicated routes that are difficult to analyze for third parties. The more users participate, the harder it is to correlate senders and receivers, and the less likely it is for any user to raise suspicions simply by using Tor: “Anonymity loves company" [<xref ref-type="bibr" rid="B4-futureinternet-04-00488">4</xref>]. The anonymity provided within the Tor network attracts many different groups of users, such as journalists and activists or business, governmental, military, and private users [<xref ref-type="bibr" rid="B5-futureinternet-04-00488">5</xref>,<xref ref-type="bibr" rid="B6-futureinternet-04-00488">6</xref>]. A recent study showed significant growth of Tor users in China as the governmental censorship increased and also in Iran when the riots after the presidential election took place [<xref ref-type="bibr" rid="B7-futureinternet-04-00488">7</xref>].</p>
      <p>However, due to usability problems caused by Tor, many “average" Internet users refrain from using it. This causes a negative impact on the potential overall privacy provided by Tor, since it depends on the size of the user community and availability of shared resources such as Tor relays. Besides one-time installation and configuration efforts, the main usability loss when using an anonymization tool such as Tor is an increase in latency. Several authors already discussed technically why Tor is slowing down a client’s Internet speed and proposed how to improve the performance [<xref ref-type="bibr" rid="B7-futureinternet-04-00488">7</xref>,<xref ref-type="bibr" rid="B8-futureinternet-04-00488">8</xref>,<xref ref-type="bibr" rid="B9-futureinternet-04-00488">9</xref>]. However, detailed comparative measurements about the performance of Tor are crucial for assessing and solving this issue.</p>
      <p>This paper presents distributed measurements on Tor latency and throughput for surfing to 500 popular websites from several PlanetLab nodes around the world during the period of 28 days (PlanetLab [<xref ref-type="bibr" rid="B10-futureinternet-04-00488">10</xref>] provides a globally distributed testbed for network research). Furthermore, we compare these measurements to critical latency thresholds gathered from web usability research, including our own user studies. The resulting expected user cancelation rate—<italic>i.e.</italic>, the percentage of users who abandon the wait during a certain time interval—is an indicator how easy it would be to keep existing users and to attract new, “average” Web users to Tor for increasing their own anonymity as well as the anonymity of the whole user community. Our results could also be relevant for integrating similar privacy-enhancing technologies into a “Future Internet".</p>
      <p>The structure of the paper is the following. We present related work in <xref ref-type="sec" rid="sec2-futureinternet-04-00488">Section 2</xref>, followed by a description of our measurement setup in <xref ref-type="sec" rid="sec3-futureinternet-04-00488">Section 3</xref>. The experimental results are presented in <xref ref-type="sec" rid="sec4-futureinternet-04-00488">Section 4</xref>. An interpretation of those results from the perspective of web usability is given in <xref ref-type="sec" rid="sec5-futureinternet-04-00488">Section 5</xref>. <xref ref-type="sec" rid="sec6-futureinternet-04-00488">Section 6</xref> discusses limitations and future work. <xref ref-type="sec" rid="sec7-futureinternet-04-00488">Section 7</xref> concludes the paper.</p>
    </sec>
    <sec id="sec2-futureinternet-04-00488">
      <title>2. Related Work</title>
      <p>Even though Internet privacy is increasingly being covered in the media, many Internet users are still not aware of the attacks that threaten the privacy of their daily communication links. One important countermeasure against attacks on communication privacy is anonymization [<xref ref-type="bibr" rid="B11-futureinternet-04-00488">11</xref>], the obfuscation of the identity of communication partners, especially of clients contacting a public server. As an important example, the Tor onion routing network provides privacy for Internet users by fundamentally enhancing their anonymity when using the Internet [<xref ref-type="bibr" rid="B2-futureinternet-04-00488">2</xref>].</p>
      <p>However, a fundamental problem associated with many of today’s security and privacy solutions is not primarily that the level of security they provide is insufficient, but rather their lack of usability. If the usability for certain security features is too low, end users are not willing to apply them, increasing the users’ personal risk of exposure to adversary attacks. Recent studies indicate that too complex security features are not applied unless they are mandatory, see for example the usage of security in banking scenarios [<xref ref-type="bibr" rid="B12-futureinternet-04-00488">12</xref>]. The amount of time or money users are willing to spend for more security is restricted and differs individually.</p>
      <p>There exist two ways to foster a broader application of security mechanisms: either (i) to increase the awareness of security risks in order to raise the willingness to pay money or time; or (ii) to increase the usability of the security features. In the case of Tor, we argue that due to its poor usability in terms of network latency, Tor is not as frequently and intensively used as would be desirable. A larger user base—with proportionate number of additional Tor relays—could enhance the privacy of its users indirectly by making Tor traffic (<italic>i.e.</italic>, connections to well-known relays) less rare and suspicious. This argument is supported by research on economic network effects and the role of usability in anonymity systems [<xref ref-type="bibr" rid="B4-futureinternet-04-00488">4</xref>,<xref ref-type="bibr" rid="B13-futureinternet-04-00488">13</xref>].</p>
      <p>Moreover, generalizing from current Tor adoption to future privacy infrastructures, if anonymity mechanisms are to be deployed to protect user privacy in a Future Internet [<xref ref-type="bibr" rid="B14-futureinternet-04-00488">14</xref>], the performance expectations of average users need to be respected.</p>
      <p>An important aspect of usability is the latency overhead caused by anonymization systems. Classical anonymity systems are mix networks, which were invented by David Chaum for anonymous email [<xref ref-type="bibr" rid="B15-futureinternet-04-00488">15</xref>] and were later generalized to arbitrary anonymous communication [<xref ref-type="bibr" rid="B16-futureinternet-04-00488">16</xref>]. In comparison to mix networks, Tor already provides much lower latency because traffic of different senders is not stored for a time and sent out in batches in order to counter timing attacks [<xref ref-type="bibr" rid="B2-futureinternet-04-00488">2</xref>]. Recent studies provide a simulation analysis of the interrelation of network topology, additional synchronization and <italic>dummy traffic</italic> against timing attacks, anonymity, and overhead [<xref ref-type="bibr" rid="B17-futureinternet-04-00488">17</xref>]. Even though Tor does not (yet) apply these additional protection measures, end user latency is still high.</p>
      <p>Several authors have already qualitatively discussed why Tor is by design slow, or have proposed ideas how to improve the performance, e.g., [<xref ref-type="bibr" rid="B9-futureinternet-04-00488">9</xref>] or [<xref ref-type="bibr" rid="B8-futureinternet-04-00488">8</xref>]. An analysis of the number and the reported bandwidth of Tor relay servers from 2006 until 2008 gives an aggregated view on global Tor capacity and actual load [<xref ref-type="bibr" rid="B9-futureinternet-04-00488">9</xref>]. Another study investigates the impact of different Tor path selection algorithms on anonymity and performance [<xref ref-type="bibr" rid="B18-futureinternet-04-00488">18</xref>]. Further studies investigate the performance of Tor hidden services [<xref ref-type="bibr" rid="B19-futureinternet-04-00488">19</xref>] and [<xref ref-type="bibr" rid="B20-futureinternet-04-00488">20</xref>], which is different from our focus on accessing standard websites through Tor. Related research also includes demographic studies on Tor, e.g., number and countries of exit nodes or estimation of user numbers and origin [<xref ref-type="bibr" rid="B7-futureinternet-04-00488">7</xref>].</p>
      <p>In the Tor Metrics project [<xref ref-type="bibr" rid="B21-futureinternet-04-00488">21</xref>], statistics such as number of users, relays, and bridges are collected. Furthermore, the duration and percentage of timeouts and failures of downloading files over Tor from a few data repositories are measured. These statistics also indicate that the performance of Tor is in general volatile over time, but the measurement of latency overhead compared to a direct connection is not provided. Furthermore, the number of servers used for these measurements is very small. In an earlier pre-study, we conducted three-day experiments from Germany to 50 websites [<xref ref-type="bibr" rid="B22-futureinternet-04-00488">22</xref>]. There is also a report on Tor usage, including performance measurements [<xref ref-type="bibr" rid="B23-futureinternet-04-00488">23</xref>] and the software TorFlow, a toolset for onion router performance analysis and measurements [<xref ref-type="bibr" rid="B24-futureinternet-04-00488">24</xref>]. Another study [<xref ref-type="bibr" rid="B25-futureinternet-04-00488">25</xref>] experimentally reveals a principal reason of Tor’s weak performance, namely frequent delays (as high as a few seconds) contributed by single, overloaded onion routers with low bandwidths. An interesting twist of our problem at hand is discussed in [<xref ref-type="bibr" rid="B26-futureinternet-04-00488">26</xref>], where the impact of different latency values on de-anonymizing communication partners is investigated.</p>
      <p>In contrast to these studies, our current paper focuses on an extensive quantitative assessment of the latency overhead of Tor, comparing the latency of Internet access from several countries with and without the application of Tor, using a list of 500 popular websites. Furthermore, we provide an analysis and mapping of these measurements to latency acceptance studies. For this, we define measures in order to estimate when users cancel their Web page request, or in other words, how much waiting time users tolerate for a request. These measures are based on related work and previous user studies conducted by the authors [<xref ref-type="bibr" rid="B27-futureinternet-04-00488">27</xref>].</p>
      <p>In the area of e-commerce research, there is a common understanding that waiting time impedes online commerce [<xref ref-type="bibr" rid="B28-futureinternet-04-00488">28</xref>,<xref ref-type="bibr" rid="B29-futureinternet-04-00488">29</xref>,<xref ref-type="bibr" rid="B30-futureinternet-04-00488">30</xref>,<xref ref-type="bibr" rid="B31-futureinternet-04-00488">31</xref>], although the authors do not agree on a single, exact classification and threshold for latency acceptance. <xref ref-type="table" rid="futureinternet-04-00488-t001">Table 1</xref> summarizes the existing literature about critical latency thresholds for Internet users, showing the different classifications.</p>
      <table-wrap id="futureinternet-04-00488-t001" position="anchor">
        <object-id pub-id-type="pii">futureinternet-04-00488-t001_Table 1</object-id>
        <label>Table 1</label>
        <caption>
          <p>Classification of Critical Latency Thresholds.</p>
        </caption>
        <table>
          <thead>
            <tr>
              <th align="left" valign="middle">Author</th>
              <th align="center" valign="middle">Critical Latency Thresholds (s)</th>
              <th align="center" valign="middle">Description</th>
              <th align="center" valign="middle">Year</th>
              <th align="center" valign="middle">Source Classification</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" valign="middle">Tolia [<xref ref-type="bibr" rid="B32-futureinternet-04-00488">32</xref>]</td>
              <td align="center" valign="middle">1</td>
              <td align="left" valign="top">Thin client response time—annoying</td>
              <td align="center" valign="middle">2006</td>
              <td align="center" valign="middle">Journal</td>
            </tr>
            <tr>
              <td align="left" valign="middle">Nah [<xref ref-type="bibr" rid="B33-futureinternet-04-00488">33</xref>]</td>
              <td align="center" valign="middle">2</td>
              <td align="left" valign="top">For simple information retrieval tasks</td>
              <td align="center" valign="middle">2004</td>
              <td align="center" valign="middle">Journal</td>
            </tr>
            <tr>
              <td align="left" valign="middle">Tolia [<xref ref-type="bibr" rid="B32-futureinternet-04-00488">32</xref>] </td>
              <td align="center" valign="middle">2</td>
              <td align="left" valign="top">Thin client response time—unacceptable</td>
              <td align="center" valign="middle">2006</td>
              <td align="center" valign="middle">Journal</td>
            </tr>
            <tr>
              <td align="left" valign="middle">Tolia [<xref ref-type="bibr" rid="B32-futureinternet-04-00488">32</xref>]</td>
              <td align="center" valign="middle">5</td>
              <td align="left" valign="top">Thin client response time—unusable</td>
              <td align="center" valign="middle">2006</td>
              <td align="center" valign="middle">Journal</td>
            </tr>
            <tr>
              <td align="left" valign="middle">AccountingWEB [<xref ref-type="bibr" rid="B34-futureinternet-04-00488">34</xref>]</td>
              <td align="center" valign="middle">8</td>
              <td align="left" valign="top">Optimal web page waiting time</td>
              <td align="center" valign="middle">2000</td>
              <td align="center" valign="middle">Practical advise </td>
            </tr>
            <tr>
              <td align="left" valign="middle">Bhatti [<xref ref-type="bibr" rid="B35-futureinternet-04-00488">35</xref>]</td>
              <td align="center" valign="middle">8.57</td>
              <td align="left" valign="top">Average tolerable delay (but high standard deviation of 5.85)</td>
              <td align="center" valign="middle">2000</td>
              <td align="center" valign="middle">Conference </td>
            </tr>
            <tr>
              <td align="left" valign="middle">Selvidge [<xref ref-type="bibr" rid="B36-futureinternet-04-00488">36</xref>]</td>
              <td align="center" valign="middle">10</td>
              <td align="left" valign="top">Tolerable delay by users</td>
              <td align="center" valign="middle">1999</td>
              <td align="center" valign="middle">Practical advise </td>
            </tr>
            <tr>
              <td align="left" valign="middle">Nielson [<xref ref-type="bibr" rid="B28-futureinternet-04-00488">28</xref>]</td>
              <td align="center" valign="middle">10</td>
              <td align="left" valign="top">Optimal web page waiting time</td>
              <td align="center" valign="middle">1999</td>
              <td align="center" valign="middle">Practical advise </td>
            </tr>
            <tr>
              <td align="left" valign="middle">Galetta [<xref ref-type="bibr" rid="B37-futureinternet-04-00488">37</xref>]</td>
              <td align="center" valign="middle">12</td>
              <td align="left" valign="top">Start of significant decrease in user satisfaction</td>
              <td align="center" valign="middle">2004</td>
              <td align="center" valign="middle">Journal</td>
            </tr>

            <tr>
              <td align="left" valign="middle">Nah [<xref ref-type="bibr" rid="B33-futureinternet-04-00488">33</xref>]</td>
              <td align="center" valign="middle">15</td>
              <td align="left" valign="top">Free user from physical and mental captivity</td>
              <td align="center" valign="middle">2004</td>
              <td align="center" valign="middle">Journal</td>
            </tr>
            <tr>
              <td align="left" valign="middle">Ramsay [<xref ref-type="bibr" rid="B38-futureinternet-04-00488">38</xref>] </td>
              <td align="center" valign="middle">41</td>
              <td align="left" valign="top">Suggestion as cut-off for long delays</td>
              <td align="center" valign="middle">1998</td>
              <td align="center" valign="middle">Journal</td>
            </tr>
          </tbody>
  </table>
      </table-wrap>
    </sec>
    <sec id="sec3-futureinternet-04-00488">
      <title>3. Measurement Setup</title>
      <sec>
        <title>3.1. Introduction to Tor</title>
        <p>Tor can be described as an anonymizing overlay network on top of the existing Internet protocol infrastructure. Tor nodes serve as additional intermediate “hops” that obfuscate the relation between a client and the application-layer messages it sends or receives, such as HTTP requests and responses while accessing a website. Each communication hop between Tor nodes during such a message exchange is protected by layers of encryption and authentication and involves a different IP address than the original IP address of the client, thereby enhancing client anonymity [<xref ref-type="bibr" rid="B2-futureinternet-04-00488">2</xref>]. The final connection between an exit node, <italic>i.e.</italic>, the last node of the Tor network that is used for the current communication flow, and the destination server is not protected by Tor. But during this step, the origin IP address is only that of the exit node, not of the original client. Since the connection via Tor usually involves more routers and a large amount of cryptographic operations (<xref ref-type="fig" rid="futureinternet-04-00488-f001">Figure 1</xref>), it is expected to be slower than the direct connection (<xref ref-type="fig" rid="futureinternet-04-00488-f002">Figure 2</xref>). Furthermore, analyses conducted by Tor developers [<xref ref-type="bibr" rid="B8-futureinternet-04-00488">8</xref>] revealed several other contributing factors to slow performance such as negative interactions with TCP congestion control, abusive users, low Tor network capacity, and imperfect path selection. Our goal is to quantify the total performance overhead of Tor as it would be perceived by end users and to assess its impact on usability.</p>
        
        <p>We use a distributed setup of web clients, each represented by a different computer and Perl scripts for automatically executing web requests (see <xref ref-type="sec" rid="sec3dot3-futureinternet-04-00488">Section 3.3</xref>). Those scripts will measure the performance of connections via the Tor network as well as of direct connections without Tor. In addition the exit node will be recorded providing the IP address and the country of origin. <xref ref-type="table" rid="futureinternet-04-00488-t002">Table 2</xref> is a summary view of our complete setup and the results we present within this paper. In the following we describe what metrics, locations, and time frame we chose, and why. In the next sections we present our measurement results.</p>
        <fig id="futureinternet-04-00488-f001" position="anchor">
          <label>Figure 1</label>
          <caption>
            <p>Anonymous Web Access via Tor.</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g001.tif"/>
        </fig>
        <fig id="futureinternet-04-00488-f002" position="anchor">
          <label>Figure 2</label>
          <caption>
            <p>Direct Web Access without Tor.</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g002.tif"/>
        </fig>
        <table-wrap id="futureinternet-04-00488-t002" position="anchor">
          <object-id pub-id-type="pii">futureinternet-04-00488-t002_Table 2</object-id>
          <label>Table 2</label>
          <caption>
            <p>Setup Overview.</p>
          </caption>
          <table>
            <tbody>
              <tr>
                <td colspan="5" align="center" valign="middle">
                  <bold>
                    <italic>Setup</italic>
                  </bold>
                </td>
              </tr>
              <tr style="border-top: solid thin">
                <td colspan="3" align="center" valign="middle">
                  <bold>Metrics</bold>
                </td>
                <td align="left" valign="middle">
                  <bold>Locations</bold>
                </td>
                <td align="center" valign="middle">
                  <bold>Time frame</bold>
                </td>
              </tr>
              <tr style="border-top: solid thin">
                <td rowspan="3" align="center" valign="middle">HTTP</td>
                <td rowspan="2" align="center" valign="middle">Latency</td>
                <td align="center" valign="middle">Core</td>
                <td align="left" valign="middle">Australia</td>
                <td rowspan="8" align="center" valign="middle">28 days</td>
              </tr>
              <tr>
                <td align="center" valign="middle" style="border-top: solid thin">Page</td>
                <td align="left" valign="middle">Brazil</td>
              </tr>
              <tr>
                <td colspan="2" align="center" valign="middle" style="border-top: solid thin">Download Throughput</td>
                <td align="left" valign="middle">Canada</td>
              </tr>
              <tr>
                <td rowspan="5" colspan="3" align="center" valign="middle" style="border-top: solid thin"/>
                <td align="left" valign="middle">Germany</td>
              </tr>
              <tr>
                <td valign="middle">Russia</td>
              </tr>
              <tr>
                <td valign="middle">Taiwan</td>
              </tr>
              <tr>
                <td valign="middle">UK</td>
              </tr>
              <tr>
                <td valign="middle">USA (2 x)</td>
              </tr>
              <tr style="border-top: solid thin">
                <td colspan="5" align="center" valign="middle">
                  <bold>
                    <italic>Results</italic>
                  </bold>
                </td>
              </tr>
              <tr style="border-top: solid thin">
                <td colspan="2" align="center" valign="middle">Tor vs. direct</td>
                <td align="center" valign="middle">Exit Nodes</td>
                <td align="center" valign="middle">Daytime Comparison</td>
                <td align="center" valign="middle">Mapping of User Cancelation Rates</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
      </sec>
      <sec>
        <title>3.2. Metrics</title>
        <p>The most common use case for Tor is browsing web pages anonymously, which is supported by studies on Tor exit traffic protocols [<xref ref-type="bibr" rid="B23-futureinternet-04-00488">23</xref>,<xref ref-type="bibr" rid="B39-futureinternet-04-00488">39</xref>]. Therefore we focus on HTTP requests in our metrics. Moreover, in order to include bandwidth performance, we also measure throughput of upload and download requests. The throughput metric captures another important use case: transferring larger amounts of data from and to the web via the HTTP protocol.</p>
        <p>The “anatomy” of requesting a website without Tor is shown in <xref ref-type="fig" rid="futureinternet-04-00488-f003">Figure 3</xref>. This figure displays line-by-line the corresponding exchange of network packets that could be captured by any router on the path between client and server. After the client (192.168.178.20) has learned the current IP address (95.100.157.15) of the web server (here an Akamai mirror of apple.com) via DNS (not shown in the trace), it establishes a TCP connection via a so-called <italic>three-way handshake</italic> (first three lines of the network trace). Now, the client issues the HTTP request for the main page with the “GET / HTTP/1.1” command, and the server returns an “OK” message as well as initial data. In later exchanges, the client requests additional data via further GET commands to download the complete web page.</p>
        <fig id="futureinternet-04-00488-f003" position="anchor">
          <label>Figure 3</label>
          <caption>
            <p>Network Packets of a Direct Web Access.</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g003.tif"/>
        </fig>
        <sec>
          <title>3.2.1. Core Latency: Duration of the First HTTP Request</title>
          <p>Core latency involves the time needed for the first HTTP request and the return of corresponding data (often, a basic HTML document only, without pictures). This is an indicator for a first data response that can indicate progress in the browser window. In order to measure the impact of Tor on surfing to important websites around the world, a Top 500 list of domains was selected. The list was provided by SEOmoz [<xref ref-type="bibr" rid="B40-futureinternet-04-00488">40</xref>] and represents the 500 most linked-to websites on the Internet. During any single run of the experiment the Perl script triggers an HTTP request for each website (from the Top 500 list), measuring the performance once with Tor and once without Tor. All Tor requests were directed over the Socks proxy <italic>Privoxy</italic>. Privoxy then forwarded the request to the Tor network. The fact that current Tor client installations based on the <italic>Tor Browser Bundle</italic> do not need a proxy server increases ease of installation and use, but cannot significantly influence connection speed. Therefore, our results are transferrable to this case. Using the Privoxy filter option could slow down the browsing experience because every page is first completely downloaded by Privoxy and than forwarded. However, we did not activate Privoxy filters during our experiments, therefore pages were directly and continuously transferred.</p>
          <p>Tor clients were running as daemons on our nodes over the whole time of the experiment. There might be some influence on certain measurements (temporarily increased latency) in the moment when Tor builds new circuits. Nevertheless, this reflects best the browsing experience since also in normal web browsing the user will be confronted with Tor building new circuits. Static data like images, videos or Javascript files were excluded from the experiment. For each request, date, time, request duration and received bytes were logged. This script was built in order to run until it has made a request to all 500 web sites.</p>
        </sec>
        <sec>
          <title>3.2.2. Page Latency: Duration of a Complete Web Page Download</title>
          <p>Page latency is an estimated measure for the download time of the complete web page (including pictures, scripts, external content <italic>etc</italic>.), an indicator for whole web page presentation in the browser window. There are many uncontrollable factors that have an influence on page latency, including current dynamic content, script execution, externally hosted content (mash-up), server reaction time, and the kind and version of web browser used.</p>
          <p>In order to provide a reproducible and browser independent estimate for extrapolating page latency from core latency, we utilized the GNU Wget tool for downloading multiple complete web pages of the Top 500 lists via the command line. Our comparison is based on the <italic>wget</italic> and <italic>wget -p</italic> commands, where <italic>wget -p</italic> serves as an estimator for retrieving entire web pages including inline images, sounds, and referenced stylesheets.</p>
          <p>We calculated an extrapolation factor <inline-graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-i001.tif"/>, where <italic>n</italic> is the number of web pages (here 500), <italic>lp</italic> the latency with <italic>wget -p</italic>, and <italic>l</italic> the latency with <italic>wget</italic>. Both latencies were measured 5 times in order to flatten one-time effects. Our results indicate an extrapolation factor <italic>F</italic> of 2.4, which means that on the average the following approximation holds: Page Latency <inline-graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-i002.tif"/> Core Latency. Parallel control experiments using the <italic>Yslow</italic> plugin for Firefox indicated that this approach provides a good estimation in the average case for our set of websites. However, current web browser download web pages via parallel connections which should speed up the download of a complete web page.</p>
          <p>To take this into account, we repeated our calculation of the extrapolation factor with the Parallel URL fetcher (<italic>puf</italic>) which is comparable in usage and functionality to <italic>wget</italic> and is able to retrieve web pages with parallel connections. The results show that with <italic>puf -p</italic> the extrapolation factor is in average 20% lower due to the use of parallel connections. Although parallel connections simulate a more realistic browsing experience because all common web browsers support them, we also have to take into account this could underestimate the loading of a complete web page. The reason for this is the inability of both <italic>wget -p</italic> and <italic>puf -p</italic> to retrieve all page-requisites a browser would need, since for example they will not gather any content requested via Javascript. Therefore, we have a reason why <italic>wget -p</italic> would overestimate the extrapolation factor (no use of parallel connections), but also why it would underestimate this factor (content not retrieved). For the purpose of this paper and backed by initial tests, we suppose that these inaccurate estimations on the average balance each other, and therefore adhere to the extrapolation factor calculated by using <italic>wget -p</italic>.</p>
        </sec>
        <sec>
          <title>3.2.3. Download Throughput via HTTP</title>
          <p>For download throughput, we compare the transfer time with and without Tor while downloading 50 KB and 1 MB of data via HTTP. Pre-tests showed that 50 KB and 1 MB are sufficient in order to have a good throughput indicator. Furthermore, these are also steps chosen by the Tor metrics project [<xref ref-type="bibr" rid="B21-futureinternet-04-00488">21</xref>]. By choice, the target URL for this part of the experiment was fixed throughout the experiment, since download of arbitrary files from multiple sites could lead to practical problems and could cause random errors. The downloaded file was located on Google’s servers (<uri>http://dl.google.com/picasa/picasa3-setup.exe</uri>). Since this file is larger then required, the download was canceled after 1 MB. In this paper, throughput is used in the sense of effective “goodput”, referring to application-layer throughput and not the actually larger amount of bytes sent via the network. Transmission overhead such as a TCP header is not being considered according to the definition of goodput [<xref ref-type="bibr" rid="B41-futureinternet-04-00488">41</xref>]. The Perl script was executed twice an hour in order to measure the traffic being downloaded. This was once done directly and once using Tor via the Socks proxy Privoxy.</p>
        </sec>
      </sec>
      <sec id="sec3dot3-futureinternet-04-00488">
        <title>3.3. Experimental Setup on PlanetLab</title>
        <p>The aim of our experimental setup is to provide a long-time and international measurement of the performance of Tor compared to a direct connection. Therefore, we compare the direct access of multiple clients to multiple servers on the Internet with the same connections established via the Tor network. (Note that this is the case of page latency measurements. For the download experiments we used only one target server.) Moreover, we deploy clients internationally with the help of the network research platform PlanetLab (<uri>http://www.planet-lab.org/</uri>) [<xref ref-type="bibr" rid="B42-futureinternet-04-00488">42</xref>]. For this, PlanetLab nodes from most continents were chosen. It was not possible to find reliable PlanetLab nodes in Africa during the time of our experiment. </p>
        <table-wrap id="futureinternet-04-00488-t003" position="anchor">
          <object-id pub-id-type="pii">futureinternet-04-00488-t003_Table 3</object-id>
          <label>Table 3</label>
          <caption>
            <p>Experimental Statistics.</p>
          </caption>
          <table>
            <thead>
              <tr>
                <th align="left" valign="middle">PlanetLab Nodes as Web Clients</th>
                <th align="left" valign="middle">Country</th>
                <th align="center" valign="middle">Uptime (days)</th>
                <th align="center" valign="middle">HTTP Requests</th>
                <th align="center" valign="middle">Downloads</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" valign="middle">pl2.eng.monash.edu.au </td>
                <td align="left" valign="middle">Australia</td>
                <td align="center" valign="middle">38</td>
                <td align="center" valign="middle">592,773</td>
                <td align="center" valign="middle">43,212</td>
              </tr>
              <tr>
                <td align="left" valign="middle">planetlab2.pop-parnp.br </td>
                <td align="left" valign="middle">Brazil</td>
                <td align="center" valign="middle">38</td>
                <td align="center" valign="middle">525,863</td>
                <td align="center" valign="middle">42,712</td>
              </tr>
              <tr>
                <td align="left" valign="middle">mercury.silicon-valley.ru </td>
                <td align="left" valign="middle">Russia</td>
                <td align="center" valign="middle">38</td>
                <td align="center" valign="middle">605,313</td>
                <td align="center" valign="middle">44,850</td>
              </tr>
              <tr>
                <td align="left" valign="middle">planetlab2.aston.ac.uk </td>
                <td align="left" valign="middle">United Kingdom</td>
                <td align="center" valign="middle">36</td>
                <td align="center" valign="middle">418,217</td>
                <td align="center" valign="middle">37,023</td>
              </tr>
              <tr>
                <td align="left" valign="middle">planetlab2.wiwi.hu-berlin.de </td>
                <td align="left" valign="middle">Germany</td>
                <td align="center" valign="middle">33</td>
                <td align="center" valign="middle">464,604</td>
                <td align="center" valign="middle">37,700</td>
              </tr>
              <tr>
                <td align="left" valign="middle">planet-lab1.cs.ucr.edu </td>
                <td align="left" valign="middle">USA (West Coast)</td>
                <td align="center" valign="middle">30</td>
                <td align="center" valign="middle">325,305</td>
                <td align="center" valign="middle">38,759</td>
              </tr>
              <tr>
                <td align="left" valign="middle">orbpl1.rutgers.edu</td>
                <td align="left" valign="middle">USA (East Coast)</td>
                <td align="center" valign="middle">25</td>
                <td align="center" valign="middle">279,339</td>
                <td align="center" valign="middle">24,684</td>
              </tr>
              <tr>
                <td align="left" valign="middle">planetlab02.erin.utoronto.ca </td>
                <td align="left" valign="middle">Canada</td>
                <td align="center" valign="middle">24</td>
                <td align="center" valign="middle">355,481</td>
                <td align="center" valign="middle">32,747</td>
              </tr>
              <tr>
                <td align="left" valign="middle">adam.ee.ntu.edu.tw </td>
                <td align="left" valign="middle">Taiwan</td>
                <td align="center" valign="middle">23</td>
                <td align="center" valign="middle">252,936</td>
                <td align="center" valign="middle">25,598</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
        <p>Each PlanetLab node provides its users with a minimal <italic>Fedora Core 8</italic> Linux installation [<xref ref-type="bibr" rid="B10-futureinternet-04-00488">10</xref>]. For our experiments, additional software needed to be installed. On all PlanetLab nodes we used <italic>Tor</italic> in version 0.2.0.32, <italic>Privoxy</italic> in version 3.0.6, <italic>Perl</italic> in version 5.8.8, <italic>Perl-CPAN</italic> in version 1.76_02, and <italic>LWP::UserAgent</italic> in version v5.835.</p>
        <p><xref ref-type="table" rid="futureinternet-04-00488-t003">Table 3</xref> shows the PlanetLab nodes that were selected for the experiment and experimental statistics. All nodes were capable of executing the Perl scripts for our experiments. Some other nodes we initially selected had to be excluded from the experiment. For example, our supposition why a PlanetLab node in China was not able to connect to the Tor network via public relays is that since September 2009 Chinese authorities started to block the Tor network in China [<xref ref-type="bibr" rid="B43-futureinternet-04-00488">43</xref>,<xref ref-type="bibr" rid="B44-futureinternet-04-00488">44</xref>].</p>
        
      </sec>
      <sec>
        <title>3.4. Time Frame</title>
        <p>In order to gain representative data from the tests, a time span of 28 days was chosen, starting on the 20th of December 2010. For the purpose of a direct comparison we had to leave out days when not all of the nodes were running. Observing such a long period, however, will prevent a biasing of the results caused by random load effects of PlanetLab nodes and their network connections. Initially, nodes started the HTTP script twice and the throughput scripts four times within an hour. Because some of the nodes provided only a very slow connection and the scripts would not finish before the next was started, this frequency was reduced. The HTTP script was then started once and the throughput scripts twice during an hour. But even with this change in the setup, scripts were sometimes started a second time before the last script was finished, but this did not impair the quality of the measurements.</p>
      </sec>
    </sec>
    <sec id="sec4-futureinternet-04-00488">
      <title>4. Measurement Results</title>
      <p>Each of the following subsections will describe the results of one of our metrics (http, download). Furthermore, we will present results concerning specific nodes and a comparison between different times of the day.</p>
      <sec>
        <title>4.1. HTTP Requests</title>
        <p>In this section the speed of usual web browsing between Tor and a direct connection is compared. The speed and duration were measured by executing an HTTP request. <xref ref-type="table" rid="futureinternet-04-00488-t003">Table 3</xref> provides an overview of all PlanetLab nodes, their uptime, and number of successful requests.</p>
        <p><xref ref-type="fig" rid="futureinternet-04-00488-f004">Figure 4</xref> compares the durations of a request run with Tor and without Tor, displaying the 25% and 75% quantile of all requests. In this figure, all nine nodes are listed and it shows that all Tor connections are by far slower than a direct connection irrespective of the request’s origin. Only the node in Canada sticks out because it took 4.7 s for the 75%-quantile of direct connection requests, which is by far the highest value for a direct connection. The figure also shows a comparison between the several median durations of a request. It shows that Tor requests from Canada are by far the slowest in our experiment. When comparing direct requests with requests tunneled through Tor, one can observe that the ratio (Tor/direct), which yields 4.8, is similar to the ratios measured at the other PlanetLab nodes. An explanation for this phenomenon could be a high traffic load that slowed down both the Tor connection and the direct connection. The average ratio of HTTP request durations (Tor/direct) of all nine PlanetLab nodes is 4.1. </p>
        <fig id="futureinternet-04-00488-f004" position="anchor">
          <label>Figure 4</label>
          <caption>
            <p>Averages of Core Latency for HTTP Requests.</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g004.tif"/>
        </fig>
        <p>Another observation is that the four nodes located in Germany, UK, and USA always have the fastest Tor connection compared to the other nodes—only these four nodes have the 75%-quantile below 8.7 s, and all other nodes are at least above 11 s up to 25.9 s. When regarding the median time of a request through the Tor network, the nodes located in Taiwan and Australia are almost as fast as the aforementioned four. Only the PlanetLab nodes in Brazil, Russia and Canada were significantly slower in terms of average, median and quantiles. The fact that connections from Germany, UK and USA are the fastest could probably be related to the fact that more than 50% of all Tor nodes are located in these countries [<xref ref-type="bibr" rid="B45-futureinternet-04-00488">45</xref>]. One reason supporting this supposition might be a smaller geographical distance for the first entry point. Other studies showed that distance influences latency [<xref ref-type="bibr" rid="B24-futureinternet-04-00488">24</xref>,<xref ref-type="bibr" rid="B46-futureinternet-04-00488">46</xref>].</p>
      </sec>
      <sec>
        <title>4.2. Download Requests</title>
        <p><xref ref-type="fig" rid="futureinternet-04-00488-f005">Figure 5</xref> and <xref ref-type="fig" rid="futureinternet-04-00488-f006">Figure 6</xref> show a comparison between the two connection types (with/without using Tor) from every PlanetLab node and the time it took to download 50 KB (<xref ref-type="fig" rid="futureinternet-04-00488-f005">Figure 5</xref>) and 1 MB (<xref ref-type="fig" rid="futureinternet-04-00488-f006">Figure 6</xref>). Most of the nodes have nearly the same median download speed, which is contributed by the fact that Google makes the downloaded file accessible with high download speed around the world, rendering the location of the node less significant [<xref ref-type="bibr" rid="B47-futureinternet-04-00488">47</xref>,<xref ref-type="bibr" rid="B48-futureinternet-04-00488">48</xref>]. Similar to the HTTP request results, the node in Canada was the slowest one, confirming the hypothesis that it had a lower bandwidth available for this experiment. This is also indicated by the median connection times.</p>
        <fig id="futureinternet-04-00488-f005" position="anchor">
          <label>Figure 5</label>
          <caption>
            <p>Average Download Throughput (Time for 50 KB).</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g005.tif"/>
        </fig>
        <fig id="futureinternet-04-00488-f006" position="anchor">
          <label>Figure 6</label>
          <caption>
            <p>Average Download Throughput (Time for 1 MB).</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g006.tif"/>
        </fig>
        <p>Download measurements (from different web servers) are also conducted by the Tor metrics project [<xref ref-type="bibr" rid="B21-futureinternet-04-00488">21</xref>]. During the timeframe of our experiments, the median value for downloading of 50 KB was reported as between 3 and 4 s, and for downloading of 1 MB between 9 and 15 s. Our results of downloading 50 KB were between 3 and 11 s (median), and for the download of 1 MB between 12 and 26 s (median). We see them as comparable. The difference is that the Tor metrics results were measured on the same nodes and differ in time, whereas our results differ in nodes and are averaged over time, probably causing a higher variation.</p>
      </sec>
      <sec>
        <title>4.3. Exit Nodes</title>
        <p>In order to empirically verify Tor statistics in practice, we also measured the exit node distribution depending on the source of the request. For each Tor request, the IP address of the exit node was recorded. Exit node locations were identified with the help of Utrace [<xref ref-type="bibr" rid="B49-futureinternet-04-00488">49</xref>]. During the experiment, over 2.2 million records for exit nodes were recorded, which were located in 65 different countries.</p>
        <p>With respect to the two connection types (HTTP single request, download), no significant differences were noticed. An intuitive explanation is that the Tor architecture and route calculation is the same for all connection types. Taking the usage of the exit nodes into account, we observe that the distribution of exit nodes used during the experiment is proportional to the distribution of exit nodes of the whole Tor network as reported by official Tor statistics. Comparing the amount and usage of exit nodes, one can confirm that exit nodes in countries known to be hosting a lot of Tor nodes were in fact used more frequently than nodes in countries hosting only a few. <xref ref-type="fig" rid="futureinternet-04-00488-f007">Figure 7</xref> shows where the exit nodes were located during the entire experiment.</p>
        <fig id="futureinternet-04-00488-f007" position="anchor">
          <label>Figure 7</label>
          <caption>
            <p>Exit Node Distribution.</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g007.tif"/>
        </fig>
      </sec>
      <sec>
        <title>4.4. Daytime View</title>
        <p>In the following, we investigate if and to what extent the daytime has an effect on the performance of a request of the two connections types, <italic>i.e.</italic>, via the Tor network and the direct connection. In <xref ref-type="fig" rid="futureinternet-04-00488-f008">Figure 8</xref>, the average core latency of all nine nodes for every hour of a day for both connection types (Tor and direct) is displayed. (We tested for the node in Germany that the average has a similar progression like the median, the 25% and the 75% quantile.) The other metrics show very similar results, therefore we did not visualize them. In order to allow for a better comparability and to take the time shift of the geographical location of the nodes into account, we represented the timestamps for every request in GMT. Furthermore, we highlighted the local time at noon by means of a vertical dotted line in <xref ref-type="fig" rid="futureinternet-04-00488-f008">Figure 8</xref>.</p>
        <fig id="futureinternet-04-00488-f008" position="anchor">
          <label>Figure 8</label>
          <caption>
            <p>GMT Daytime Comparison (Core Latency; +: Direct, x: via Tor). (<bold>a</bold>) Australia; (<bold>b</bold>) Taiwan; (<bold>c</bold>) Russia; (<bold>d</bold>) Germany; (<bold>e</bold>) UK; (<bold>f</bold>) Brazil; (<bold>g</bold>) Canada; (<bold>h</bold>) USA (East Coast); (<bold>i</bold>) USA (West Coast).</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g008.tif"/>
        </fig>
        <p>Our results indicate that the latency of direct connections is nearly constant over time of the day on most nodes. Especially Australia, Russia, UK, Brazil and USA (West Coast) show very little differences regarding the performance during different hours of a day. Only the nodes in Germany and Taiwan have a noticeable peak after noon (local time). The node in Canada shows a peak at 10 AM local time, and in the USA at 9 AM local time. The other metric, download throughput, confirms these results. We argue that this stability of the performance of the direct connection is provided by the mature backbone infrastructure of the Internet which has enough capacity available for web access even during Internet “prime-time” when approximately 25% of all traffic is generated [<xref ref-type="bibr" rid="B50-futureinternet-04-00488">50</xref>] and Internet traffic is about 72% higher than during an average hour [<xref ref-type="bibr" rid="B51-futureinternet-04-00488">51</xref>].</p>
        <p>Comparing both connection types, <italic>i.e.</italic>, the direct connection and through Tor, we can state that the daytime has a stronger influence on the Tor network than it has on the direct connection. This finding is consistent for all metrics. The Tor connection does not show a stable performance and seems to be affected by daytime. There does not seem to exist an exact common pattern explaining the performance variation of the Tor connection (cf. <xref ref-type="fig" rid="futureinternet-04-00488-f008">Figure 8</xref>). However, in general the overall performance appears to be decreasing during GMT evening hours independently of the location of the PlanetLab node.</p>
        <p>Contrasting this with the results for direct connections, we argue that this effect is more dependent on the performance of Tor than on the geographical location of the client nodes. Tor nodes are usually selected worldwide in a random fashion, without preference for nodes which are physically close [<xref ref-type="bibr" rid="B52-futureinternet-04-00488">52</xref>]. Although it is not part of the Tor route selection process, traffic is often routed through nodes located in different countries, and every node adds some latency. Since Tor nodes are not evenly distributed around the globe, Tor speed could correlate with the current local daytime of the majority of nodes in use (such as UK and Germany). This leads us to the conclusion that the diurnal behavior of Tor latency is in general more influenced by global factors than by local factors at the client.</p>
      </sec>
      </sec>
      <sec id="sec5-futureinternet-04-00488">
        <title>5. Interpretation of Results with Respect to Usability</title>
        <p>In this section, we focus on the combination of our technical measurements with studies of user behaviour while browsing the web. The aim is to reason about the influence of the latency that we measured on user acceptance. We already introduced critical latency values gained from experimental research (cf. <xref ref-type="sec" rid="sec2-futureinternet-04-00488">Section 2</xref>). According to this related work, in particular in <xref ref-type="table" rid="futureinternet-04-00488-t001">Table 1</xref>, we assume that user tolerance of waiting for web-page requests decreases after 2 s; it falls sharply within the interval between 7 s and 15 s, and ends with 50 s when the user stops waiting. In our opinion, the related research conducted by Nah <italic>et al</italic>. [<xref ref-type="bibr" rid="B33-futureinternet-04-00488">33</xref>] is best suited for our experiment due to its empirical grounding and most recent data in comparison to the other studies. However, we extend these experimentally measured lab results [<xref ref-type="bibr" rid="B33-futureinternet-04-00488">33</xref>] with results stated by users from our own survey [<xref ref-type="bibr" rid="B27-futureinternet-04-00488">27</xref>].</p>
        <p><xref ref-type="fig" rid="futureinternet-04-00488-f009">Figure 9</xref> shows four different scenarios with cancelation rates over time. The curve labeled “Nah without FB” is referencing the “first-attempt waiting” scenario of Nah in which the user is confronted with a broken link while not getting any feedback from the web browser [<xref ref-type="bibr" rid="B33-futureinternet-04-00488">33</xref>]. Here, an important metric is introduced: the percentage of users who abandoned the wait during the time interval specified.</p>
        <fig id="futureinternet-04-00488-f009" position="anchor">
          <label>Figure 9</label>
          <caption>
            <p>Cancelation Rate of Different Scenarios.</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g009.tif"/>
        </fig>
        <p>We adopt this <italic>cancelation rate</italic> as a good indicator for the user’s waiting tolerance in our setting. The curve labeled “Nah with Feedback” is referencing the first attempt waiting scenario in which the user is confronted with a broken link while getting feedback in form of a progress bar from the web browser [<xref ref-type="bibr" rid="B33-futureinternet-04-00488">33</xref>]. The other two scenarios are derived from our own survey and show stated tolerated waiting times for normal and anonymous web browsing. Those two cancelation rate curves indicate that people surfing anonymously have a higher tolerance in terms of latency. Nevertheless, the gap between the curves is small: The correlation is 0.989, the medians are 18.556 and 21.096 s, respectively. There are 948 data points. The maximum difference D between the cumulative distributions according to the Kolmogorov–Smirnov comparison is: 0.0854, with a corresponding p-value of: 0.002 (statistically significant at 0.5% level). Furthermore, we note that our survey results also confirmed the results of Nah’s lab experiments.</p>
        <p>In order to reason about expected cancelation rates for browsing the web via Tor, we map our technical latency results to corresponding user cancelation rates. On the technical side, we apply our core and page latency measurements for both direct connections and connections over Tor. Page latency, estimated by the applying the measured factor 2.4 to core latency, increases the median of core latency for HTTP requests via Tor from 13.36 s to 32.06 s. The median of HTTP requests without Tor increases from 1.72 s to 4.13 s.</p>
        <p>From a usability perspective, we are provided with stated as well as experimentally measured user cancelation rates. As stated cancelation rates, we have statements for direct connection and anonymized connection. Experimental cancelation rates can be divided in those with and without feedback. Out of the <inline-graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-i003.tif"/> possible combinations, <xref ref-type="table" rid="futureinternet-04-00488-t004">Table 4</xref> shows the meaningful mappings. The results from the lab experiment with feedback can be mapped to page latency because the user is given feedback during loading of the page (the page builds up stepwise). The lab experiment without feedback should be mapped to core latency because the user gets no detailed visual progress feedback until first data is retrieved. </p>
        <table-wrap id="futureinternet-04-00488-t004" position="anchor">
          <object-id pub-id-type="pii">futureinternet-04-00488-t004_Table 4</object-id>
          <label>Table 4</label>
          <caption>
            <p>Comparing Cancelation Rates from User Studies to our Latency Measurements.</p>
          </caption>
          <table>
            <thead>
              <tr>
                <th align="left" valign="middle">Type of Cancelation Rate</th>
                <th align="center" valign="middle">Direct, Core Latency</th>
                <th align="center" valign="middle">Tor, Core Latency</th>
                <th align="center" valign="middle">Direct, Page Latency</th>
                <th align="center" valign="middle">Tor, Page Latency</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" valign="middle">Lab with Feedback</td>
                <td align="center" valign="middle">–</td>
                <td align="center" valign="middle">–</td>
                <td align="center" valign="middle">X</td>
                <td align="center" valign="middle">X</td>
              </tr>
              <tr>
                <td align="left" valign="middle">Lab without Feedback</td>
                <td align="center" valign="middle">X</td>
                <td align="center" valign="middle">X</td>
                <td align="center" valign="middle">–</td>
                <td align="center" valign="middle">–</td>
              </tr>
              <tr>
                <td align="left" valign="middle">Stated Direct</td>
                <td align="center" valign="middle">X</td>
                <td align="center" valign="middle">–</td>
                <td align="center" valign="middle">X</td>
                <td align="center" valign="middle">–</td>
              </tr>
              <tr>
                <td align="left" valign="middle">Stated Anonymous</td>
                <td align="center" valign="middle">–</td>
                <td align="center" valign="middle">X</td>
                <td align="center" valign="middle">–</td>
                <td align="center" valign="middle">X</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
        <p>In <xref ref-type="fig" rid="futureinternet-04-00488-f010">Figure 10</xref>, <xref ref-type="fig" rid="futureinternet-04-00488-f011">Figure 11</xref>, <xref ref-type="fig" rid="futureinternet-04-00488-f012">Figure 12</xref>, <xref ref-type="fig" rid="futureinternet-04-00488-f013">Figure 13</xref>, we present our mappings of technical latency results (LT) and corresponding user cancelation rates (CR) of <xref ref-type="fig" rid="futureinternet-04-00488-f009">Figure 9</xref>. Each of the four figures describes a different type of cancelation rate and the meaningful mappings for technical latency (from <xref ref-type="table" rid="futureinternet-04-00488-t004">Table 4</xref>). The extrapolated page latency (full page download) is referenced by <italic>PAGE</italic>, the core latency (HTTP request duration) by <italic>CORE</italic>, while requests directed via the Tor network are referenced by <italic>Tor</italic>, and direct requests by <italic>Direct</italic>.</p>
        
        
        <p>The mapping in <xref ref-type="fig" rid="futureinternet-04-00488-f010">Figure 10</xref> shows technical measurements of page latency (<italic>i.e.</italic>, page loading time) and the resulting cancelation rates of users who are provided with feedback while loading the page. This figure indicates a high increase in user cancelation when sending requests via Tor. The median of page latency via Tor corresponds to a median of 67% cancelation rate, while user frustration for the median of direct page latency maps to only 2% cancelation. This gap between cancelation rates indicates a critical jump in expected user cancelation when using the Tor network, which we aim to investigate further by our own set of user studies in future work.</p>
        <p>Moreover, the user cancelation rate follows a saturation curve. Therefore, early user loss (in terms of cancelation rates) caused by latency is massive. Lowering the page latency via Tor by 7 s would decrease the user cancelation rate by 12%. A reduction of Tor-based page latency by 12 s would reduce the cancelation rate by 33%. Hence, an only minimal optimization of the Tor network latency will not gain a substantial effect. Only if the optimization is massive, a real improvement would be made.</p>
        <p>In <xref ref-type="fig" rid="futureinternet-04-00488-f011">Figure 11</xref>, a mapping is provided between technical measurements of core latency and the resulting cancelation rates of users who are not provided with feedback while loading the page. This indicates an even higher, disproportionate increase in user cancelation when sending requests via Tor. The median of the core latency via Tor maps to a median of 78% cancelation rate, while user frustration for the median of direct page latency maps to 14% cancelation (lowest measured cancelation rate, we assume an even lower cancelation rate here if cancelation rate data would be more precise).</p>
        <p>Lowering core latency via Tor by 3 s would decrease user cancelation rate by 17%. A reduction of Tor-based core latency by 8 s would reduce the cancelation rate to the same level as when using a direct connection—of course with the caveat of non-exact measurement data of the laboratory studies for direct access. These results indicate an expected massive gain in user acceptance if Tor network latency is reduced significantly. Both mappings provide a combined line of argument. Their results indicate the same amount of performance improvements necessary for Tor.</p>
        <p>The results shown in <xref ref-type="fig" rid="futureinternet-04-00488-f010">Figure 10</xref> and <xref ref-type="fig" rid="futureinternet-04-00488-f011">Figure 11</xref> do not distinguish between user acceptance of anonymous <italic>vs.</italic> non-anonymous browsing because this was not tested in the lab studies we refer to. </p>
        <fig id="futureinternet-04-00488-f010" position="anchor">
          <label>Figure 10</label>
          <caption>
            <p>Page Latency and Cancelation Rate (Lab Experiment with Feedback).</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g010.tif"/>
        </fig>
        <fig id="futureinternet-04-00488-f011" position="anchor">
          <label>Figure 11</label>
          <caption>
            <p>Core Latency and Cancelation Rate (Lab Experiment without Feedback).</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g011.tif"/>
        </fig>
        <fig id="futureinternet-04-00488-f012" position="anchor">
          <label>Figure 12</label>
          <caption>
            <p>Latency and Cancelation Rate for Normal Web Browsing (Survey Statements).</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g012.tif"/>
        </fig>
        <p><xref ref-type="fig" rid="futureinternet-04-00488-f012">Figure 12</xref> displays technical measurements of core and page latency using a direct connection, which are mapped to the resulting cancelation rates of users asked for their acceptance of latency during normal browsing (referenced by <italic>Norm</italic>). This mapping indicates that core and page latency of an average direct connection are accepted by more than 96% of the users.</p>
        <p>Finally, <xref ref-type="fig" rid="futureinternet-04-00488-f013">Figure 13</xref> shows the mapping of technical measurements of core and page latency using a connection over Tor to the cancelation rates of users who have been asked for their acceptance of latency while browsing anonymously (referenced by <italic>Anon</italic>). The resulting cancelation rates indicate that core and page latency of an average connection over Tor are accepted only by less than 30% of the users. The reason for the low acceptance are that only a few people are willing to wait longer in order to surf anonymously, while anonymous web browsing using the Tor network has a massively adverse effect on latency.</p>
        <fig id="futureinternet-04-00488-f013" position="anchor">
          <label>Figure 13</label>
          <caption>
            <p>Latency and Cancelation Rate for Anonymous Web Browsing (Survey Statements).</p>
          </caption>
          <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="futureinternet-04-00488-g013.tif"/>
        </fig>
      </sec>
    
    <sec id="sec6-futureinternet-04-00488">
      <title>6. Limitations and Future Work</title>
      <p>In order to assess usability implications on a global scale, we treated Tor explicitly as a “black box” in this paper. We measured what end users around the world are confronted with in terms of performance. Our experiments do not aim for a detailed white-box analysis of Tor or technical improvements for latency, but serve as basis for assessing Tor usability based on tolerated waiting time. Important related literature on the technical details of improving Tor is presented in the <xref ref-type="sec" rid="sec2-futureinternet-04-00488">Section 2</xref>.</p>
      <p>Moreover, the global experiments we conducted have some limitations in terms of node reliability, comparability, and estimation of page latency. When using the PlanetLab environment, traffic generated by other experiments on the same node could influence the experiment results. During the execution of the test scripts, the resources of the nodes have been shared with other experiments. Accordingly, the overall traffic speed might not be accurate and the performance of the direct and Tor connections should only be compared against each other and are (quantitatively) not exactly comparable across machines. However, the results from experiments conducted on the same node (<italic>i.e.</italic>, direct <italic>vs.</italic> Tor) are still comparable since both traffic types used the same connection and the ratio between them was considered for analysis. On the one hand, our experiments might be overestimating the speed of normal web browsing, e.g., at home, because the PlanetLab environment provides in most cases server-grade computers with a good Internet connection. On the other hand, they may be underestimating the speed of normal web browsing because of the heavy load these PlanetLab nodes suffer. Though we suppose that these differences between PlanetLab nodes and common personal computers are insignificant, further research should include tests to strengthen this hypothesis. All in all, the relative ratio of both traffic types will be comparable.</p>
      <p>Our approach for calculating the extrapolation factor for downloading complete web pages, though most suited for our experimental setting, has some limitations: (i) The results vary between different websites, while extrapolating does not cover this issue. We do not consider this as crucial due to the fact that we focus on page latency; (ii) When downloading the complete web page, additional variations in terms of time and coverage for different browsers and individual browser settings may be experienced. An alternative method, which could better reflect a real user’s browsing behavior, would be to provide a Tor exit node and use the requested websites for live measurement experiments. However, even though such alternative experiments could in theory be conducted without affecting the privacy of Tor users, this could nonetheless raise strong privacy concerns and potentially also cause legal issues in our university environment.</p>
      <p>We focused on clear-cut technical metrics that can be measured via automated requests. In the real world, the perceived latency of the user depends on various other aspects. Additional studies about influence factors for perceived latency such as cultural issues, the task at hand, or individual user settings of the browser or operating system could provide valuable information about how latency is experienced by users and what countermeasures could be applied, such as introducing a loading progress bar for Tor users. In future work, we plan a set of user studies on capturing those further, more individual or subjective aspects of latency acceptance and usability. In addition, we will investigate user acceptances correlation to educational and ethnical background and if IT knowledge has an influence on users acceptance. Furthermore, we will ask if risk awareness and risk aversion have an influence on the willingness to use Tor. First results in this direction were recently published by us [<xref ref-type="bibr" rid="B27-futureinternet-04-00488">27</xref>].</p>
      <p>Future research will also focus on performance improvements, which according to our studies will help to gain a wider user acceptance. We would like to investigate if changing parameters such as the number of hops in an anonymization network could have a positive influence on anonymity and usability, e.g., decreasing the number of hops could result in lower latency. This could result in broader user acceptance, leading to more users and increasing anonymity in general, but possibly leaving routes much more open to compromise. Another approach could be a performance-oriented one in which the behavior of the anonymization network is not focused on guaranteeing a certain degree of anonymity, but on a guarantee of performance. For example, one could include statistics such as number of participants and latency of nodes when calculating the route within the anonymization network. Such an approach is adopted by the I2P anonymity system, which takes the performance of the peers into account when calculating routes through the network. This is of course a compromise between performance and privacy [<xref ref-type="bibr" rid="B53-futureinternet-04-00488">53</xref>].</p>
    </sec>
    <sec sec-type="conclusions" id="sec7-futureinternet-04-00488">
      <title>7. Conclusions</title>
      <p>In this paper, we extended previous research on measuring Tor latency and usability: for the technical measurement in terms of diversification and duration and for the user acceptance in terms of user cancelation rates. We included further statistics from web usability studies and we included our own results based on an interactive survey. Both extensions helped us to improve the significance and clarity of the usability analysis of the Tor anonymization tool. In particular, we analyzed the performance of the Tor network by comparing direct Internet access against a Tor-anonymized Internet access. Those tests were performed on different nodes around the world to gather data based on various locations. Enormous amounts of data were accumulated during a period of 38 days totaling nearly 4.5 million requests for each connection type.</p>
      <p>The experiment results quantitatively confirmed the common intuition that one has to accept performance losses while using the Tor network. User waiting times exhibit a large spread, ranging from taking twice as long as to nearly a hundred times longer while using the Tor network. The median ratio while using the Tor network is around 7.8 times slower. Concerning the loss of usability in exchange for improved anonymity while browsing the web via Tor, we can say that for core latency, the median of all Tor requests was 7.8 times higher than the median of the direct connection. Furthermore, the experiments revealed that Tor latency seems to fluctuate more, <italic>i.e.</italic>, the actual duration of an HTTP request via Tor is harder to anticipate for the user. The overall latency that a user finally experiences is approximated by page latency, estimating the download of a complete web page. Our results indicate that at least 75% of all direct requests are faster than 75% of all Tor requests.</p>
      <p>Based on the results of our experiments, we provided a mapping that measures the expected increase in web user cancelation rate while using Tor. Comparing page latency between Tor-based and direct requests, there is a difference of 64% or 65% according to the lab experiment, respectively the user survey, in expected cancelation rate. This is a strong indicator for potentially high user frustration when using the Tor anonymization network.</p>
      <p>We suggest that a usability improvement in terms of a massive latency reduction would significantly increase the adoption of Tor by new users, and thereby increase the anonymity of current users as well. On the other hand, if anonymization technology should become part of a Future Internet [<xref ref-type="bibr" rid="B14-futureinternet-04-00488">14</xref>], our research offers first steps towards an empirically grounded analysis of corresponding performance requirements.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <title>References</title>
      <ref id="B1-futureinternet-04-00488">
        <label>1.</label>
        <citation citation-type="web">
          <collab>Amnesty International</collab>
          <article-title>Undermining Freedom of Expression in China</article-title>
          <year>2006</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.amnestyusa.org/business/Undermining_Freedom_of_Expression_in_China.pdf" ext-link-type="uri">http://www.amnestyusa.org/business/Undermining_Freedom_of_Expression_in_China.pdf</ext-link></comment>
        </citation>
      </ref>
      <ref id="B2-futureinternet-04-00488">
        <label>2.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Dingledine</surname>
              <given-names>R.</given-names>
            </name>
            <name>
              <surname>Mathewson</surname>
              <given-names>N.</given-names>
            </name>
            <name>
              <surname>Syverson</surname>
              <given-names>P.</given-names>
            </name>
          </person-group>
          <article-title>Tor: The Second-Generation Onion Router</article-title>
          <source>Proceedings of the 13th USENIX Security Symposium</source>
          <conf-loc>San Diego, CA, USA</conf-loc>
          <conf-date>9–13 August 2004</conf-date>
        </citation>
      </ref>
      <ref id="B3-futureinternet-04-00488">
        <label>3.</label>
        <citation citation-type="web">
          <article-title>Tor Project Web Site</article-title>
          <year>2010</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.torproject.org/" ext-link-type="uri">https://www.torproject.org/</ext-link></comment>
        </citation>
      </ref>
      <ref id="B4-futureinternet-04-00488">
        <label>4.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Dingledine</surname>
              <given-names>R.</given-names>
            </name>
            <name>
              <surname>Mathewson</surname>
              <given-names>N.</given-names>
            </name>
          </person-group>
          <article-title>Anonymity Loves Company: Usability and the Network Effect</article-title>
          <source>Proceedings of the 5th Workshop on the Economics of Information Security (WEIS 2006)</source>
          <conf-loc>Cambridge, UK</conf-loc>
          <conf-date>26–28 June 2006</conf-date>
        </citation>
      </ref>
      <ref id="B5-futureinternet-04-00488">
        <label>5.</label>
        <citation citation-type="web">
          <person-group person-group-type="author">
            <name>
              <surname>Palme</surname>
              <given-names>J.</given-names>
            </name>
            <name>
              <surname>Berglund</surname>
              <given-names>M.</given-names>
            </name>
          </person-group>
          <article-title>Anonymity on the Internet</article-title>
          <year>2002</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://people.dsv.su.se/jpalme/society/anonymity.html" ext-link-type="uri">http://people.dsv.su.se/jpalme/society/anonymity.html</ext-link></comment>
        </citation>
      </ref>
      <ref id="B6-futureinternet-04-00488">
        <label>6.</label>
        <citation citation-type="web">
          <person-group person-group-type="author">
            <name>
              <surname>Vitone</surname>
              <given-names>D.</given-names>
            </name>
          </person-group>
          <article-title>Anonymous Networks</article-title>
          <year>2008</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://blag.cerebralmind.net/wp-content/uploads/2008/05/tor.pdf" ext-link-type="uri">http://blag.cerebralmind.net/wp-content/uploads/2008/05/tor.pdf</ext-link></comment>
        </citation>
      </ref>
      <ref id="B7-futureinternet-04-00488">
        <label>7.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Loesing</surname>
              <given-names>K.</given-names>
            </name>
            <name>
              <surname>Murdoch</surname>
              <given-names>S.J.</given-names>
            </name>
            <name>
              <surname>Dingledine</surname>
              <given-names>R.</given-names>
            </name>
          </person-group>
          <article-title>A Case Study on Measuring Statistical Data in the Tor Anonymity Network</article-title>
          <source>Proceedings of the Workshop on Ethics in Computer Security Research (WECSR 2010)</source>
          <conf-loc>Canary Islands, Spain</conf-loc>
          <conf-date>28–29 January 2010</conf-date>
        </citation>
      </ref>
      <ref id="B8-futureinternet-04-00488">
        <label>8.</label>
        <citation citation-type="web">
          <person-group person-group-type="author">
            <name>
              <surname>Dingledine</surname>
              <given-names>R.</given-names>
            </name>
            <name>
              <surname>Murdoch</surname>
              <given-names>S.J.</given-names>
            </name>
          </person-group>
          <article-title>Performance Improvements on Tor</article-title>
          <year>2009</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.torproject.org/press/presskit/2009-03-11-performance.pdf" ext-link-type="uri">https://www.torproject.org/press/presskit/2009-03-11-performance.pdf</ext-link></comment>
        </citation>
      </ref>
      <ref id="B9-futureinternet-04-00488">
        <label>9.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Loesing</surname>
              <given-names>K.</given-names>
            </name>
          </person-group>
          <article-title>Measuring the Tor Network from Public Directory Information</article-title>
          <source>Proceedings of the 2nd Hot Topics in Privacy Enhancing Technologies (HotPETs)</source>
          <conf-loc>Seattle, WA, USA</conf-loc>
          <conf-date>5–7 August 2009</conf-date>
        </citation>
      </ref>
      <ref id="B10-futureinternet-04-00488">
        <label>10.</label>
        <citation citation-type="web">
          <article-title>PlanetLab User’s Guide</article-title>
          <year>2011</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.planet-lab.org/doc/guides/user" ext-link-type="uri">http://www.planet-lab.org/doc/guides/user</ext-link></comment>
        </citation>
      </ref>
      <ref id="B11-futureinternet-04-00488">
        <label>11.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Wright</surname>
              <given-names>T.</given-names>
            </name>
          </person-group>
          <article-title>Security, privacy, and anonymity</article-title>
          <source>ACM</source>
          <year>2004</year>
          <volume>11</volume>
          <pub-id pub-id-type="doi">10.1145/1144403.1144408</pub-id>
        </citation>
      </ref>
      <ref id="B12-futureinternet-04-00488">
        <label>12.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Mannan</surname>
              <given-names>M.</given-names>
            </name>
            <name>
              <surname>van Oorschot</surname>
              <given-names>P.C.</given-names>
            </name>
          </person-group>
          <article-title>Security and Usability: The Gap in Real-World Online Banking</article-title>
          <source>Proceedings of the 2007 Workshop on New Security Paradigms</source>
          <conf-loc>North Conway, NH, USA</conf-loc>
          <conf-date>18–21 September 2007</conf-date>
          <fpage>1</fpage>
          <lpage>14</lpage>
        </citation>
      </ref>
      <ref id="B13-futureinternet-04-00488">
        <label>13.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Acquisti</surname>
              <given-names>A.</given-names>
            </name>
            <name>
              <surname>Dingledine</surname>
              <given-names>R.</given-names>
            </name>
            <name>
              <surname>Syverson</surname>
              <given-names>P.</given-names>
            </name>
          </person-group>
          <article-title>On the Economics of Anonymity</article-title>
          <source>Proceedings of the Financial Cryptography (FC ’03)</source>
          <person-group person-group-type="editor">
            <name>
              <surname>Wright</surname>
              <given-names>R.N.</given-names>
            </name>
          </person-group>
          <publisher-name>Springer</publisher-name>
          <publisher-loc>Berlin, Germany</publisher-loc>
          <year>2003</year>
          <fpage>84</fpage>
          <lpage>102</lpage>
        </citation>
      </ref>
      <ref id="B14-futureinternet-04-00488">
        <label>14.</label>
        <citation citation-type="web">
          <person-group person-group-type="author">
            <name>
              <surname>Bellovin</surname>
              <given-names>S.M.</given-names>
            </name>
            <name>
              <surname>Clark</surname>
              <given-names>D.D.</given-names>
            </name>
            <name>
              <surname>Perrig</surname>
              <given-names>A.</given-names>
            </name>
          </person-group>
          <article-title>A Clean-Slate Design for the Next-Generation Secure Internet</article-title>
          <access-date>(accessed on 10 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://mars.cs.kent.edu/peyravi/Net208S/Lec/NextGenInternet.pdf" ext-link-type="uri">http://mars.cs.kent.edu/peyravi/Net208S/Lec/NextGenInternet.pdf</ext-link></comment>
        </citation>
      </ref>
      <ref id="B15-futureinternet-04-00488">
        <label>15.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Chaum</surname>
              <given-names>D.</given-names>
            </name>
          </person-group>
          <article-title>Untraceable electronic mail, return addresses, and digital pseudonyms</article-title>
          <source>Commun. ACM</source>
          <year>1981</year>
          <volume>24</volume>
          <fpage>84</fpage>
          <lpage>88</lpage>
          <pub-id pub-id-type="doi">10.1145/358549.358563</pub-id>
        </citation>
      </ref>
      <ref id="B16-futureinternet-04-00488">
        <label>16.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Danezis</surname>
              <given-names>G.</given-names>
            </name>
          </person-group>
          <article-title>Mix-Networks with Restricted Routes</article-title>
          <source>Proceedings of the 3rd Privacy Enhancing Technologies Workshop (PET 2003)</source>
          <person-group person-group-type="editor">
            <name>
              <surname>Dingledine</surname>
              <given-names>R.</given-names>
            </name>
          </person-group>
          <publisher-name>Springer</publisher-name>
          <publisher-loc>Berlin, Germany</publisher-loc>
          <year>2003</year>
          <volume>2760</volume>
          <fpage>1</fpage>
          <lpage>17</lpage>
        </citation>
      </ref>
      <ref id="B17-futureinternet-04-00488">
        <label>17.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Diaz</surname>
              <given-names>C.</given-names>
            </name>
            <name>
              <surname>Murdoch</surname>
              <given-names>S.J.</given-names>
            </name>
            <name>
              <surname>Troncoso</surname>
              <given-names>C.</given-names>
            </name>
          </person-group>
          <article-title>Impact of Network Topology on Anonymity and Overhead in Low-Latency Anonymity Networks</article-title>
          <source>Proceedings of the 10th International Symposium on Privacy Enhancing Technologies (PETS 2010)</source>
          <conf-loc>Berlin, Germany</conf-loc>
          <conf-date>21–23 July 2010</conf-date>
        </citation>
      </ref>
      <ref id="B18-futureinternet-04-00488">
        <label>18.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Murdoch</surname>
              <given-names>S.J.</given-names>
            </name>
            <name>
              <surname>Watson</surname>
              <given-names>R.N.M.</given-names>
            </name>
          </person-group>
          <article-title>Metrics for Security and Performance in Low-Latency Anonymity Networks</article-title>
          <source>Proceedings of the 8th International Symposium on Privacy Enhancing Technologies (PETS 2008)</source>
          <publisher-name>Springer</publisher-name>
          <publisher-loc>Berlin, Germany</publisher-loc>
          <year>2008</year>
          <fpage>115</fpage>
          <lpage>132</lpage>
        </citation>
      </ref>
      <ref id="B19-futureinternet-04-00488">
        <label>19.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Loesing</surname>
              <given-names>K.</given-names>
            </name>
            <name>
              <surname>Sandmann</surname>
              <given-names>W.</given-names>
            </name>
            <name>
              <surname>Wilms</surname>
              <given-names>C.</given-names>
            </name>
            <name>
              <surname>Wirtz</surname>
              <given-names>G.</given-names>
            </name>
          </person-group>
          <article-title>Performance Measurements and Statistics of Tor Hidden Services</article-title>
          <source>Proceedings of the 2008 International Symposium on Applications and the Internet (SAINT)</source>
          <publisher-name>IEEE CS Press</publisher-name>
          <publisher-loc>Turku, Finland</publisher-loc>
          <year>2008</year>
        </citation>
      </ref>
      <ref id="B20-futureinternet-04-00488">
        <label>20.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Lenhard</surname>
              <given-names>J.</given-names>
            </name>
            <name>
              <surname>Loesing</surname>
              <given-names>K.</given-names>
            </name>
            <name>
              <surname>Wirtz</surname>
              <given-names>G.</given-names>
            </name>
          </person-group>
          <article-title>Performance Measurements of Tor Hidden Services in Low-Bandwidth Access Networks</article-title>
          <source>Proceedings of the 7th International Conference on Applied Cryptography and Network Security (ACNS 09)</source>
          <conf-loc>Paris-Rocquencourt, France</conf-loc>
          <conf-date>2–5 June 2009</conf-date>
          <volume>5536</volume>
        </citation>
      </ref>
      <ref id="B21-futureinternet-04-00488">
        <label>21.</label>
        <citation citation-type="web">
          <article-title>Tor Metrics Portal</article-title>
          <year>2010</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://metrics.torproject.org/" ext-link-type="uri">http://metrics.torproject.org/</ext-link></comment>
        </citation>
      </ref>
      <ref id="B22-futureinternet-04-00488">
        <label>22.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Fabian</surname>
              <given-names>B.</given-names>
            </name>
            <name>
              <surname>Goertz</surname>
              <given-names>F.</given-names>
            </name>
            <name>
              <surname>Kunz</surname>
              <given-names>S.</given-names>
            </name>
            <name>
              <surname>Müller</surname>
              <given-names>S.</given-names>
            </name>
            <name>
              <surname>Nitzsche</surname>
              <given-names>M.</given-names>
            </name>
          </person-group>
          <article-title>Privately Waiting—A Usability Analysis of the Tor Anonymity Network</article-title>
          <source>Proceedings of the 16th Americas Conference on Information Systems (AMCIS 2010)</source>
          <publisher-name>Springer</publisher-name>
          <publisher-loc>Berlin, Germany</publisher-loc>
          <year>2010</year>
          <volume>58</volume>
        </citation>
      </ref>
      <ref id="B23-futureinternet-04-00488">
        <label>23.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>McCoy</surname>
              <given-names>D.</given-names>
            </name>
            <name>
              <surname>Bauer</surname>
              <given-names>K.</given-names>
            </name>
            <name>
              <surname>Grunwald</surname>
              <given-names>D.</given-names>
            </name>
            <name>
              <surname>Kohno</surname>
              <given-names>T.</given-names>
            </name>
            <name>
              <surname>Sicker</surname>
              <given-names>D.</given-names>
            </name>
          </person-group>
          <article-title>Shining Light in Dark Places: Understanding the Tor Network</article-title>
          <source>Proceedings of the 8th International Symposium on Privacy Enhancing Technologies (PETS 2008)</source>
          <publisher-name>Springer</publisher-name>
          <publisher-loc>Berlin, Germany</publisher-loc>
          <year>2008</year>
          <fpage>63</fpage>
          <lpage>76</lpage>
        </citation>
      </ref>
      <ref id="B24-futureinternet-04-00488">
        <label>24.</label>
        <citation citation-type="web">
          <person-group person-group-type="author">
            <name>
              <surname>Perry</surname>
              <given-names>M.</given-names>
            </name>
          </person-group>
          <source>TorFlow: Tor Network Analysis</source>
          <access-date>(accessed on 10 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://fscked.org/talks/TorFlow-HotPETS-final.pdf" ext-link-type="uri">http://fscked.org/talks/TorFlow-HotPETS-final.pdf</ext-link></comment>
        </citation>
      </ref>
      <ref id="B25-futureinternet-04-00488">
        <label>25.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Dhungel</surname>
              <given-names>P.</given-names>
            </name>
            <name>
              <surname>Steiner</surname>
              <given-names>M.</given-names>
            </name>
            <name>
              <surname>Rimac</surname>
              <given-names>I.</given-names>
            </name>
            <name>
              <surname>Hilt</surname>
              <given-names>V.</given-names>
            </name>
            <name>
              <surname>Ross</surname>
              <given-names>K.W.</given-names>
            </name>
          </person-group>
          <article-title>Waiting for Anonymity: Understanding Delays in the Tor Overlay</article-title>
          <source>Proceedings of the IEEE 10th International Conference on Peer-to-Peer Computing (P2P 2010)</source>
          <conf-loc>Delft, The Netherlands</conf-loc>
          <conf-date>25–27 August 2010</conf-date>
        </citation>
      </ref>
      <ref id="B26-futureinternet-04-00488">
        <label>26.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Hopper</surname>
              <given-names>N.</given-names>
            </name>
            <name>
              <surname>Vasserman</surname>
              <given-names>E.Y.</given-names>
            </name>
            <name>
              <surname>Chan-Tin</surname>
              <given-names>E.</given-names>
            </name>
          </person-group>
          <article-title>How much anonymity does network latency leak?</article-title>
          <source>ACM Trans. Inf. Syst. Secur.</source>
          <year>2010</year>
          <volume>13</volume>
          <pub-id pub-id-type="doi">10.1145/1698750.1698753</pub-id>
        </citation>
      </ref>
      <ref id="B27-futureinternet-04-00488">
        <label>27.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Brecht</surname>
              <given-names>F.</given-names>
            </name>
            <name>
              <surname>Fabian</surname>
              <given-names>B.</given-names>
            </name>
            <name>
              <surname>Kunz</surname>
              <given-names>S.</given-names>
            </name>
            <name>
              <surname>Müller</surname>
              <given-names>S.</given-names>
            </name>
          </person-group>
          <article-title>Are You Willing to Wait Longer for Internet Privacy?</article-title>
          <source>Proceedings of the European Conference on Information Systems (ECIS 2011)</source>
          <conf-loc>Helsinki, Finland</conf-loc>
          <conf-date>9–11 June 2011</conf-date>
        </citation>
      </ref>
      <ref id="B28-futureinternet-04-00488">
        <label>28.</label>
        <citation citation-type="web">
          <person-group person-group-type="author">
            <name>
              <surname>Nielson</surname>
              <given-names>J.</given-names>
            </name>
          </person-group>
          <article-title>“Top Ten Mistakes" in Web design—Revisited Three Years Later</article-title>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.useit.com/alertbox/990502.html" ext-link-type="uri">http://www.useit.com/alertbox/990502.html</ext-link></comment>
        </citation>
      </ref>
      <ref id="B29-futureinternet-04-00488">
        <label>29.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Rose</surname>
              <given-names>G.</given-names>
            </name>
            <name>
              <surname>Khoo</surname>
              <given-names>H.</given-names>
            </name>
            <name>
              <surname>Straub</surname>
              <given-names>D.W.</given-names>
            </name>
          </person-group>
          <article-title>Current technological impediments to business-to-consumer electronic commerce</article-title>
          <source>Commun. AIS</source>
          <year>1999</year>
          <volume>1</volume>
          <fpage>1</fpage>
        </citation>
      </ref>
      <ref id="B30-futureinternet-04-00488">
        <label>30.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Ryan</surname>
              <given-names>G.</given-names>
            </name>
            <name>
              <surname>Valverde</surname>
              <given-names>M.</given-names>
            </name>
          </person-group>
          <article-title>Waiting online: A review and research agenda</article-title>
          <source>Int. Res. Electron. Netw. Appl. Policy</source>
          <year>2003</year>
          <volume>13</volume>
          <fpage>195</fpage>
          <lpage>205</lpage>
          <pub-id pub-id-type="doi">10.1108/10662240310478213</pub-id>
        </citation>
      </ref>
      <ref id="B31-futureinternet-04-00488">
        <label>31.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Stockport</surname>
              <given-names>G.J.</given-names>
            </name>
            <name>
              <surname>Kunnath</surname>
              <given-names>G.</given-names>
            </name>
            <name>
              <surname>Sedick</surname>
              <given-names>R.</given-names>
            </name>
          </person-group>
          <article-title>Boo.com—The path to failure</article-title>
          <source>J. Interact. Mark.</source>
          <year>2001</year>
          <volume>15</volume>
          <fpage>56</fpage>
          <lpage>70</lpage>
          <pub-id pub-id-type="doi">10.1002/dir.1023</pub-id>
        </citation>
      </ref>
      <ref id="B32-futureinternet-04-00488">
        <label>32.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Tolia</surname>
              <given-names>N.</given-names>
            </name>
            <name>
              <surname>Andersen</surname>
              <given-names>D.</given-names>
            </name>
            <name>
              <surname>Satyanarayanan</surname>
              <given-names>M.</given-names>
            </name>
          </person-group>
          <article-title>Quantifying interactive user experience on thin clients</article-title>
          <source>IEEE Comput.</source>
          <year>2006</year>
          <volume>39</volume>
          <fpage>46</fpage>
          <lpage>52</lpage>
        </citation>
      </ref>
      <ref id="B33-futureinternet-04-00488">
        <label>33.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Nah</surname>
              <given-names>F.F.</given-names>
            </name>
          </person-group>
          <article-title>A study on tolerable waiting time: How long are web users willing to wait?</article-title>
          <source>Behav. Inf. Technol.</source>
          <year>2004</year>
          <volume>23</volume>
          <fpage>153</fpage>
          <lpage>163</lpage>
          <pub-id pub-id-type="doi">10.1080/01449290410001669914</pub-id>
        </citation>
      </ref>
      <ref id="B34-futureinternet-04-00488">
        <label>34.</label>
        <citation citation-type="web">
          <collab>AccountingWEB</collab>
          <article-title>Is Your Web Site Too Big?</article-title>
          <year>2000</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.accountingweb.com/item/29331" ext-link-type="uri">http://www.accountingweb.com/item/29331</ext-link></comment>
        </citation>
      </ref>
      <ref id="B35-futureinternet-04-00488">
        <label>35.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Bhatti</surname>
              <given-names>N.</given-names>
            </name>
            <name>
              <surname>Bouch</surname>
              <given-names>A.</given-names>
            </name>
            <name>
              <surname>Kuchinsky</surname>
              <given-names>A.</given-names>
            </name>
          </person-group>
          <article-title>Integrating user-perceived quality into Web server design</article-title>
          <source>Comput. Netw. (Amst. Neth. 1999)</source>
          <year>2000</year>
          <volume>33</volume>
          <fpage>1</fpage>
          <lpage>16</lpage>
        <pub-id pub-id-type="doi">10.1016/S1389-1286(00)00087-6</pub-id></citation>
      </ref>
      <ref id="B36-futureinternet-04-00488">
        <label>36.</label>
        <citation citation-type="web">
          <person-group person-group-type="author">
            <name>
              <surname>Selvidge</surname>
              <given-names>P.</given-names>
            </name>
          </person-group>
          <article-title>How Long is Too Long to Wait for a Website to Load?</article-title>
          <year>1999</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.surl.org/usabilitynews/12/time_delay.asp" ext-link-type="uri">http://www.surl.org/usabilitynews/12/time_delay.asp</ext-link></comment>
        </citation>
      </ref>
      <ref id="B37-futureinternet-04-00488">
        <label>37.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Galletta</surname>
              <given-names>D.F.</given-names>
            </name>
            <name>
              <surname>Henry</surname>
              <given-names>R.M.</given-names>
            </name>
            <name>
              <surname>McCoy</surname>
              <given-names>S.</given-names>
            </name>
            <name>
              <surname>Polak</surname>
              <given-names>P.</given-names>
            </name>
          </person-group>
          <article-title>Web site delays: How tolerant are users?</article-title>
          <source>J. AIS</source>
          <year>2004</year>
          <volume>5</volume>
          <fpage>1</fpage>
          <lpage>28</lpage>
        </citation>
      </ref>
      <ref id="B38-futureinternet-04-00488">
        <label>38.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Ramsay</surname>
              <given-names>J.</given-names>
            </name>
            <name>
              <surname>Barbesi</surname>
              <given-names>A.</given-names>
            </name>
            <name>
              <surname>Preece</surname>
              <given-names>J.</given-names>
            </name>
          </person-group>
          <article-title>A psychological investigation of long retrieval times on the World Wide Web</article-title>
          <source>Interact. Comput.</source>
          <year>1998</year>
          <volume>10</volume>
          <fpage>77</fpage>
          <lpage>86</lpage>
          <pub-id pub-id-type="doi">10.1016/S0953-5438(97)00019-2</pub-id>
        </citation>
      </ref>
      <ref id="B39-futureinternet-04-00488">
        <label>39.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Huber</surname>
              <given-names>M.</given-names>
            </name>
            <name>
              <surname>Mulazzani</surname>
              <given-names>M.</given-names>
            </name>
            <name>
              <surname>Weippl</surname>
              <given-names>E.</given-names>
            </name>
          </person-group>
          <article-title>Tor HTTP Usage and Information Leakage</article-title>
          <source>Proceedings of the Communications and Multimedia Security</source>
          <publisher-name>Springer</publisher-name>
          <publisher-loc>Berlin, Germany</publisher-loc>
          <year>2010</year>
          <volume>6109</volume>
          <fpage>245</fpage>
          <lpage>255</lpage>
        </citation>
      </ref>
      <ref id="B40-futureinternet-04-00488">
        <label>40.</label>
        <citation citation-type="web">
          <article-title>SEOmoz: The 500 Most Important Websites on the Internet</article-title>
          <year>2011</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.seomoz.org/top500" ext-link-type="uri">http://www.seomoz.org/top500</ext-link></comment>
        </citation>
      </ref>
      <ref id="B41-futureinternet-04-00488">
        <label>41.</label>
        <citation citation-type="web">
          <collab>Wikipedia</collab>
          <article-title>Goodput</article-title>
          <year>2011</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://secure.wikimedia.org/wikipedia/en/wiki/Goodput" ext-link-type="uri">https://secure.wikimedia.org/wikipedia/en/wiki/Goodput</ext-link></comment>
        </citation>
      </ref>
      <ref id="B42-futureinternet-04-00488">
        <label>42.</label>
        <citation citation-type="journal">
          <person-group person-group-type="author">
            <name>
              <surname>Peterson</surname>
              <given-names>L.</given-names>
            </name>
            <name>
              <surname>Pai</surname>
              <given-names>V.S.</given-names>
            </name>
          </person-group>
          <article-title>Experience-driven experimental systems research</article-title>
          <source>Commun. ACM</source>
          <year>2007</year>
          <volume>50</volume>
          <fpage>38</fpage>
          <lpage>44</lpage>
          <pub-id pub-id-type="doi">10.1145/1297797.1297820</pub-id>
        </citation>
      </ref>
      <ref id="B43-futureinternet-04-00488">
        <label>43.</label>
        <citation citation-type="web">
          <article-title>Tor partially blocked in China</article-title>
          <year>2009</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://blog.torproject.org/blog/tor-partially-blocked-china/" ext-link-type="uri">https://blog.torproject.org/blog/tor-partially-blocked-china/</ext-link></comment>
        </citation>
      </ref>
      <ref id="B44-futureinternet-04-00488">
        <label>44.</label>
        <citation citation-type="web">
          <person-group person-group-type="author">
            <name>
              <surname>Talbot</surname>
              <given-names>D.</given-names>
            </name>
          </person-group>
          <article-title>China Cracks Down on Tor Anonymity Network. Technology Review</article-title>
          <year>2009</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.technologyreview.com/web/23736/" ext-link-type="uri">http://www.technologyreview.com/web/23736/</ext-link></comment>
        </citation>
      </ref>
      <ref id="B45-futureinternet-04-00488">
        <label>45.</label>
        <citation citation-type="web">
          <person-group person-group-type="author">
            <name>
              <surname>Berger</surname>
              <given-names>M.</given-names>
            </name>
          </person-group>
          <article-title>Tor Nodes Statistics</article-title>
          <year>2011</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.dianacht.de/torstat/" ext-link-type="uri">http://www.dianacht.de/torstat/</ext-link></comment>
        </citation>
      </ref>
      <ref id="B46-futureinternet-04-00488">
        <label>46.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Panchenko</surname>
              <given-names>A.</given-names>
            </name>
            <name>
              <surname>Renner</surname>
              <given-names>J.</given-names>
            </name>
          </person-group>
          <article-title>Path Selection Metrics for Performance-Improved Onion Routing</article-title>
          <source>Proceedings of the 2009 9th Annual International Symposium on Applications and the Internet</source>
          <publisher-name>IEEE Computer Society</publisher-name>
          <publisher-loc>Washington, DC, USA</publisher-loc>
          <year>2009</year>
          <fpage>114</fpage>
          <lpage>120</lpage>
        </citation>
      </ref>
      <ref id="B47-futureinternet-04-00488">
        <label>47.</label>
        <citation citation-type="web">
          <article-title>Map of all Google data center locations. Pingdom Blog</article-title>
          <year>2008</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://royal.pingdom.com/2008/04/11/map-of-all-google-data-center-locations/" ext-link-type="uri">http://royal.pingdom.com/2008/04/11/map-of-all-google-data-center-locations/</ext-link></comment>
        </citation>
      </ref>
      <ref id="B48-futureinternet-04-00488">
        <label>48.</label>
        <citation citation-type="web">
          <article-title>CDN performance</article-title>
          <year>2010</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://royal.pingdom.com/2010/05/11/cdn-performance-downloading-jquery-from-google-microsoft-and-edgecast-cdns/" ext-link-type="uri">http://royal.pingdom.com/2010/05/11/cdn-performance-downloading-jquery-from-google-microsoft-and-edgecast-cdns/</ext-link></comment>
        </citation>
      </ref>
      <ref id="B49-futureinternet-04-00488">
        <label>49.</label>
        <citation citation-type="web">
          <article-title>Utrace—Locate IP Addresses and Domain Names</article-title>
          <year>2011</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.utrace.de/" ext-link-type="uri">http://www.utrace.de/</ext-link></comment>
        </citation>
      </ref>
      <ref id="B50-futureinternet-04-00488">
        <label>50.</label>
        <citation citation-type="web">
          <article-title>New Cisco Study Reveals Peak Internet Traffic Increases Due to Social Networking and Broadband Video Usage</article-title>
          <year>2009</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://newsroom.cisco.com/dlls/2009/prod_102109.html" ext-link-type="uri">http://newsroom.cisco.com/dlls/2009/prod_102109.html</ext-link></comment>
        </citation>
      </ref>
      <ref id="B51-futureinternet-04-00488">
        <label>51.</label>
        <citation citation-type="web">
          <article-title>Cisco Visual Networking Index: Usage Study</article-title>
          <year>2010</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/Cisco_VNI_Usage_WP.html" ext-link-type="uri">http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/Cisco_VNI_Usage_WP.html</ext-link></comment>
        </citation>
      </ref>
      <ref id="B52-futureinternet-04-00488">
        <label>52.</label>
        <citation citation-type="web">
          <article-title>Roger Dingledine and Nick Mathewson</article-title>
          <year>2011</year>
          <access-date>(accessed on 8 May 2012)</access-date>
          <comment>Available online:<ext-link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://git.torproject.org/checkout/tor/master/doc/spec/path-spec.txt" ext-link-type="uri">https://git.torproject.org/checkout/tor/master/doc/spec/path-spec.txt</ext-link></comment>
        </citation>
      </ref>
      <ref id="B53-futureinternet-04-00488">
        <label>53.</label>
        <citation citation-type="confproc">
          <person-group person-group-type="author">
            <name>
              <surname>Herrmann</surname>
              <given-names>M.</given-names>
            </name>
            <name>
              <surname>Grothoff</surname>
              <given-names>C.</given-names>
            </name>
          </person-group>
          <article-title>Privacy-Implications of Performance-Based Peer Selection by Onion-Routers: A Real-World Case Study Using I2P</article-title>
          <source>Proceedings of the 11th International Symposium on Privacy Enhancing Technologies (PETS 2011)</source>
          <publisher-name>Springer</publisher-name>
          <publisher-loc>Berlin, Germany</publisher-loc>
          <year>2011</year>
          <fpage>155</fpage>
          <lpage>174</lpage>
        </citation>
      </ref>
    </ref-list>
  </back>
</article>
