kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Added translation tags to comparison/*

Browse Source
This commit is contained in:
str4d
2013-01-18 22:42:23 +00:00
parent 2fbd7c78c5
commit a796ae5d04
4 changed files with 247 additions and 145 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
i2p2www/pages/site/comparison/freenet.html
View File

@@ -1,17 +1,20 @@
{% extends "global/layout.html" %}
{% block title %}I2P Compared to Freenet{% endblock %}
{% block title %}{{ _('I2P Compared to Freenet') }}{% endblock %}
{% block content %}
<h2>Freenet</h2>
<i><a href="http://freenetproject.org/">[Freenet]</a></i>
<p>Freenet is a fully distributed, peer to peer anonymous publishing network, offering
<p>{% trans -%}
Freenet is a fully distributed, peer to peer anonymous publishing network, offering
secure ways to store data, as well as some approaches attempting to address the loads
of a flash flood. While Freenet is designed as a distributed data store, people have
built applications on top of it to do more generic anonymous communication, such as
static websites and message boards.</p>
static websites and message boards.
{%- endtrans %}</p>
<p>Compared to I2P, Freenet offers some substantial benefits - it is a distributed data
<p>{% trans -%}
Compared to I2P, Freenet offers some substantial benefits - it is a distributed data
store, while I2P is not, allowing people to retrieve the content published by others
even when the publisher is no longer online. In addition, it should be able to
distribute popular data fairly efficiently. I2P itself does not and will not provide
@@ -20,15 +23,18 @@ communicate with each other anonymously through websites, message boards, file s
programs, etc. There have also been some attempts to develop a distributed data
store to run on top of I2P,
(most recently a port of <a href="http://tahoe-lafs.org/trac/tahoe-lafs">Tahoe-LAFS</a>)
but nothing is yet ready for general use.</p>
but nothing is yet ready for general use.
{%- endtrans %}</p>
<p>However, even ignoring any implementations issues, there are some concerns
<p>{% trans -%}
However, even ignoring any implementations issues, there are some concerns
about Freenet's algorithms from both a scalability and anonymity perspective, owing
largely to Freenet's heuristic driven routing. The interactions of various techniques
certainly may successfully deter various attacks, and perhaps some aspects of the
routing algorithms will provide the hoped for scalability. Unfortunately, not much
analysis of the algorithms involved has resulted in positive results, but there is still
hope. At the very least, Freenet does provide substantial anonymity against an attacker
who does not have the resources necessary to analyze it further.</p>
who does not have the resources necessary to analyze it further.
{%- endtrans %}</p>
{% endblock %}

20
i2p2www/pages/site/comparison/index.html
View File

@@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}Comparing I2P to other projects{% endblock %}
{% block title %}{{ _('Comparing I2P to other projects') }}{% endblock %}
{% block content %}
<p>
<p>{% trans -%}
There are a great many other applications and projects working on anonymous
communication and I2P has been inspired by much of their efforts. This is not
a comprehensive list of anonymity resources - both freehaven's
@@ -9,7 +9,7 @@ a comprehensive list of anonymity resources - both freehaven's
and GNUnet's <a href="https://www.gnunet.org/links/">related projects</a>
serve that purpose well. That said, a few systems stand out for further
comparison. The following have individual comparison pages:
</p>
{%- endtrans %}</p>
<ul>
<li><a href="{{ site_url('comparison/tor') }}">Tor / Onion Routing</a></li>
@@ -17,21 +17,21 @@ comparison. The following have individual comparison pages:
{#<li><a href="{{ site_url('comparison/gnunet') }}">GNUnet</a></li>#}
</ul>
<p>
The following are discussed on the <a href="{{ site_url('comparison/other-networks') }}">other networks page:</a>
</p>
<p>{% trans othernetworks=site_url('comparison/other-networks') -%}
The following are discussed on the <a href="{{ othernetworks }}">other networks page:</a>
{%- endtrans %}</p>
<ul>
<li>Morphmix and Tarzan</li>
<li>Morphmix / Tarzan</li>
<li>Mixminion / Mixmaster</li>
<li>JAP</li>
<li>MUTE / AntsP2P</li>
<li>Haystack</li>
</ul>
<p>
<p>{% trans trac=i2pconv('trac.i2p2.i2p') -%}
The content of this page is subject to update, discussion and dispute, and we welcome comments and additions.
You may contribute an analysis by entering a <a href="http://{{ i2pconv('trac.i2p2.i2p') }}/report/1">new ticket on Trac</a>.
</p>
You may contribute an analysis by entering a <a href="http://{{ trac }}/report/1">new ticket on Trac</a>.
{%- endtrans %}</p>
{% endblock %}

78
i2p2www/pages/site/comparison/other-networks.html
View File

@@ -1,38 +1,42 @@
{% extends "global/layout.html" %}
{% block title %}I2P Compared to Other Anonymous Networks{% endblock %}
{% block title %}{{ _('I2P Compared to Other Anonymous Networks') }}{% endblock %}
{% block content %}
<p>The following networks are discussed on this page.
</p>
<p>{% trans -%}
The following networks are discussed on this page.
{%- endtrans %}</p>
<ul>
<li>Morphmix and Tarzan</li>
<li>Morphmix / Tarzan</li>
<li>Mixminion / Mixmaster</li>
<li>JAP</li>
<li>MUTE / AntsP2P</li>
<li>Haystack</li>
</ul>
<p>Most of the following sections are fairly old, and may not be accurate.
<p>{% trans comparison=site_url('comparison'), trac=i2pconv('trac.i2p2.i2p') -%}
Most of the following sections are fairly old, and may not be accurate.
For an overview of available comparisons, see the
<a href="{{ site_url('comparison') }}">main network comparisons page</a>.
<a href="{{ comparison }}">main network comparisons page</a>.
You may contribute an analysis by entering a
<a href="http://{{ i2pconv('trac.i2p2.i2p') }}/report/1">new ticket on trac.i2p2.de</a>.
</p>
<a href="http://{{ trac }}/report/1">new ticket on {{ trac }}</a>.
{%- endtrans %}</p>
<h2>Morphmix and Tarzan</h2>
<h2>Morphmix / Tarzan</h2>
<i><a href="http://www.tik.ee.ethz.ch/~morphmix/">[Morphmix]</a>
<a href="http://www.pdos.lcs.mit.edu/tarzan/">[Tarzan]</a></i>
<p>Morphmix and Tarzan are both fully distributed, peer to peer networks of
<p>{% trans threatmodel=site_url('docs/how/threat-model') -%}
Morphmix and Tarzan are both fully distributed, peer to peer networks of
anonymizing proxies, allowing people to tunnel out through the low latency
mix network. Morphmix includes some very interesting collusion detection
algorithms and Sybil defenses, while Tarzan makes use of the scarcity of IP
addresses to accomplish the same. The two primary differences between
these systems and I2P are related to I2P's <a href="{{ site_url('docs/how/threatmodel') }}">threat model</a>
these systems and I2P are related to I2P's <a href="{{ threatmodel }}">threat model</a>
and their out-proxy design (as opposed to providing both sender and receiver
anonymity). There is source code available to both systems, but we are not aware
of their use outside of academic environments.</p>
of their use outside of academic environments.
{%- endtrans %}</p>
<!--
Table needs correction, disabled for now.
@@ -146,7 +150,8 @@ comparison of Tarzan, Crowds, Onion Routing (OR), and I2P:</p>
<i><a href="http://mixminion.net/">[Mixminion]</a>
<a href="http://mixmaster.sourceforge.net/">[Mixmaster]</a></i>
<p>Mixminion and Mixmaster are networks to support anonymous email against a very
<p>{% trans %}
Mixminion and Mixmaster are networks to support anonymous email against a very
powerful adversary.
High-latency messaging applications running on top of I2P
(for example
@@ -157,16 +162,20 @@ model of those adversaries, while running in parallel along side the needs of lo
a significantly larger anonymity set.
High-latency support within the I2P router itself may or may not be added in a distant future release.
It is too early to say if I2P will meet the needs of users requiring extreme protection for email.
</p>
{%- endtrans %}</p>
<p>{% trans -%}
As with Tor and Onion Routing,
both Mixminion and Mixmaster take the directory based approach as well.</p>
both Mixminion and Mixmaster take the directory based approach as well.
{%- endtrans %}</p>
<h2>JAP</h2>
<i><a href="http://anon.inf.tu-dresden.de/index_en.html">[JAP]</a></i>
<p>JAP (Java Anonymous Proxy) is a network of mix cascades for anonymizing web requests,
<p>{% trans -%}
JAP (Java Anonymous Proxy) is a network of mix cascades for anonymizing web requests,
and as such it has a few centralized nodes (participants in the cascade) that blend
and mix requests from clients through the sequence of nodes (the cascade) before
proxying out onto the web. The scope, threat model, and security is substantially
@@ -180,13 +189,15 @@ on the network. Even though the method of this attack was later found to be ill
in the German courts, the fact that the data was successfully collected is the
concern. Courts change their minds based upon circumstance, and this is evidence that
if a government body or intelligence agency wanted to, they could gather the data, even
if it may be found inadmissible in some courts later)</p>
if it may be found inadmissible in some courts later)
{%- endtrans %}</p>
<h2>MUTE / AntsP2P</h2>
<i><a href="http://mute-net.sourceforge.net/">[MUTE]</a>
<a href="http://www.myjavaserver.com/~gwren/home.jsp?page=custom&xmlName=ants">[AntsP2P]</a></i>
<p>Both of these systems work through the same basic
<p>{% trans -%}
Both of these systems work through the same basic
<a href="http://citeseer.ist.psu.edu/57701.html">antnet</a> routing, providing some degree of
anonymity based on the threat model of providing plausible deniability against a simple
non-colluding adversary. With the antnet routing, they first either do a random walk or a
@@ -194,37 +205,40 @@ broadcast search to find some peer with the data or identity desired, and then u
algorithm to optimize that found path. This works well for applications that merely want to know
what other people around them have to offer - "How are y'all doing" vs. "Hey Alice, how are you" -
you basically get a local cluster of nodes that can share files with and maintain some degree of
anonymity (though you don't have much control over who is in that group of peers).</p>
anonymity (though you don't have much control over who is in that group of peers).
{%- endtrans %}</p>
<p>However, the algorithm does not scale well at all - if the application wants to speak with a
<p>{% trans -%}
However, the algorithm does not scale well at all - if the application wants to speak with a
particular peer it ends up doing a broadcast search or random walk (though if they are lucky enough
for that to succeed, the antnet routing should optimize that found connection). This means that
while these networks can work great at small scales, they are not suitable for large networks where
someone wants to get in touch with another specific peer. That does not mean that there is no
value in these systems, just that their applicability is limited to situations where their
particular issues can be addressed.</p>
particular issues can be addressed.
{%- endtrans %}</p>
<h2>Haystack</h2>
<p>
<p>{% trans docs=site_url('docs') -%}
This was a closed-source network targeted at Iranian users.
Tor did a
<a href="http://blog.torproject.org/blog/ten-things-look-circumvention-tool">good writeup on what to look for in a circumvention tool</a>.
Suffice it to say that being closed source and publicly targeting a specific country are not good ideas.
I2P is, of course, open source. However, that source, and our
<a href="{{ site_url('docs') }}">technical documentation</a>, need much more review.
</p>
<a href="{{ docs }}">technical documentation</a>, need much more review.
{%- endtrans %}</p>
<h2>Paid VPN Services</h2>
<p>
<h2>{{ _('Paid VPN Services') }}</h2>
<p>{% trans trac=i2pconv('trac.i2p2.i2p') -%}
You may contribute an analysis by entering a
<a href="http://{{ i2pconv('trac.i2p2.i2p') }}/report/1">new ticket on trac.i2p2.de</a>.
</p>
<a href="http://{{ trac }}/report/1">new ticket on {{ trac }}</a>.
{%- endtrans %}</p>
<h2>Others</h2>
<p>
<h2>{{ _('Others') }}</h2>
<p>{% trans trac=i2pconv('trac.i2p2.i2p') -%}
You may contribute an analysis by entering a
<a href="http://{{ i2pconv('trac.i2p2.de') }}/report/1">new ticket on trac.i2p2.de</a>.
</p>
<a href="http://{{ trac }}/report/1">new ticket on {{ trac }}</a>.
{%- endtrans %}</p>
{% endblock %}

274
i2p2www/pages/site/comparison/tor.html
View File

@@ -1,11 +1,12 @@
{% extends "global/layout.html" %}
{% block title %}I2P Compared to Tor{% endblock %}
{% block title %}{{ _('I2P Compared to Tor') }}{% endblock %}
{% block content %}
<h2>Tor / Onion Routing</h2>
<i><a href="http://www.torproject.org/">[Tor]</a>
<a href="http://www.onion-router.net">[Onion Routing]</a></i>
<p>Tor and Onion Routing are both anonymizing proxy networks,
<p>{% trans netdb=site_url('docs/how/network-database'), peerselection=site_url('docs/how/peer-selection') -%}
Tor and Onion Routing are both anonymizing proxy networks,
allowing people to tunnel out through their low latency mix
network. The two primary differences between Tor /
Onion-Routing and I2P are again related to differences in
@@ -14,10 +15,12 @@ supports hidden services as well). In addition, Tor
takes the directory-based approach - providing a
centralized point to manage the overall 'view' of the
network, as well as gather and report statistics, as
opposed to I2P's distributed <a href="{{ site_url('docs/how/networkdatabase') }}">network
database</a> and <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a>.</p>
opposed to I2P's distributed <a href="{{ netdb }}">network
database</a> and <a href="{{ peerselection }}">peer selection</a>.
{%- endtrans %}</p>
<p>The I2P/Tor outproxy functionality does have a few
<p>{% trans -%}
The I2P/Tor outproxy functionality does have a few
substantial weaknesses against certain attackers -
once the communication leaves the mixnet, global passive
adversaries can more easily mount traffic analysis. In
@@ -25,121 +28,200 @@ addition, the outproxies have access to the cleartext
of the data transferred in both directions, and
outproxies are prone to abuse, along with all of the
other security issues we've come to know and love with
normal Internet traffic.</p>
normal Internet traffic.
{%- endtrans %}</p>
<p>However, many people don't need to worry about those
<p>{% trans -%}
However, many people don't need to worry about those
situations, as they are outside their threat model. It
is, also, outside I2P's (formal) functional scope (if people want
to build outproxy functionality on top of an anonymous
communication layer, they can). In fact, some I2P users
currently take advantage of Tor to outproxy.</p>
currently take advantage of Tor to outproxy.
{%- endtrans %}</p>
<!--
<p>See also the
<a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ComparisonI2P">the Tor FAQ</a>
for a Tor/I2P comparison from the Tor perspective.</p>
-->
<h3>Comparison of Tor and I2P Terminology</h3>
<h3>{{ _('Comparison of Tor and I2P Terminology') }}</h3>
<p>{% trans -%}
While Tor and I2P are similar in many ways, much of the terminology is different.
{%- endtrans %}</p>
<table>
<tr><th align="left">Tor<th align="left">I2P
<tr><td>Cell<td>Message
<tr><td>Client<td>Router or Client
<tr><td>Circuit<td>Tunnel
<tr><td>Directory<td>NetDb
<tr><td>Directory Server<td>Floodfill Router
<tr><td>Entry Guards<td>Fast Peers
<tr><td>Entry Node<td>Inproxy
<tr><td>Exit Node<td>Outproxy
<tr><td>Hidden Service<td>Eepsite or Destination
<tr><td>Hidden Service Descriptor<td>LeaseSet
<tr><td>Introduction point<td>Inbound Gateway
<tr><td>Node<td>Router
<tr><td>Onion Proxy<td>I2PTunnel Client (more or less)
<tr><td>Relay<td>Router
<tr><td>Rendezvous Point<td>somewhat like Inbound Gateway + Outbound Endpoint
<tr><td>Router Descriptor<td>RouterInfo
<tr><td>Server<td>Router
<tr><td>{{ _('Cell') }}<td>{{ _('Message') }}
<tr><td>{{ _('Client') }}<td>{{ _('Router or Client') }}
<tr><td>{{ _('Circuit') }}<td>{{ _('Tunnel') }}
<tr><td>{{ _('Directory') }}<td>{{ _('NetDb') }}
<tr><td>{{ _('Directory Server') }}<td>{{ _('Floodfill Router') }}
<tr><td>{{ _('Entry Guards') }}<td>{{ _('Fast Peers') }}
<tr><td>{{ _('Entry Node') }}<td>{{ _('Inproxy') }}
<tr><td>{{ _('Exit Node') }}<td>{{ _('Outproxy') }}
<tr><td>{{ _('Hidden Service') }}<td>{{ _('Eepsite or Destination') }}
<tr><td>{{ _('Hidden Service Descriptor') }}<td>{{ _('LeaseSet') }}
<tr><td>{{ _('Introduction point') }}<td>{{ _('Inbound Gateway') }}
<tr><td>{{ _('Node') }}<td>{{ _('Router') }}
<tr><td>{{ _('Onion Proxy') }}<td>{{ _('I2PTunnel Client (more or less)') }}
<tr><td>{{ _('Relay') }}<td>{{ _('Router') }}
<tr><td>{{ _('Rendezvous Point') }}<td>{{ _('somewhat like Inbound Gateway + Outbound Endpoint') }}
<tr><td>{{ _('Router Descriptor') }}<td>{{ _('RouterInfo') }}
<tr><td>{{ _('Server') }}<td>{{ _('Router') }}
</table>
<h3>Benefits of Tor over I2P</h3>
<h3>{{ _('Benefits of Tor over I2P') }}</h3>
<ul>
<li>Much bigger user base; much more visibility in the academic and hacker communities; benefits from
formal studies of anonymity, resistance, and performance;
has a non-anonymous, visible, university-based leader</li>
<li>Has already solved some scaling issues I2P has yet to address</li>
<li>Has significant funding</li>
<li>Has more developers, including several that are funded</li>
<li>More resistant to state-level blocking due to TLS transport layer and bridges
(I2P has proposals for "full restricted routes" but these are not yet implemented)</li>
<li>Big enough that it has had to adapt to blocking and DOS attempts</li>
<li>Designed and optimized for exit traffic, with a large number of exit nodes</li>
<li>Better documentation, has formal papers and specifications, better website, many more translations</li>
<li>More efficient with memory usage</li>
<li>Tor client nodes have very low bandwidth overhead</li>
<li>Centralized control reduces the complexity at each
node and can efficiently address Sybil attacks</li>
<li>A core of high capacity nodes provides higher
throughput and lower latency</li>
<li>C, not Java (ewww)</li>
<li>
{% trans -%}
Much bigger user base; much more visibility in the academic and hacker communities; benefits from
formal studies of anonymity, resistance, and performance;
has a non-anonymous, visible, university-based leader
{%- endtrans %}
</li>
<li>{% trans %}Has already solved some scaling issues I2P has yet to address{% endtrans %}</li>
<li>{% trans %}Has significant funding{% endtrans %}</li>
<li>{% trans %}Has more developers, including several that are funded{% endtrans %}</li>
<li>
{% trans -%}
More resistant to state-level blocking due to TLS transport layer and bridges
(I2P has proposals for "full restricted routes" but these are not yet implemented)
{%- endtrans %}
</li>
<li>{% trans %}Big enough that it has had to adapt to blocking and DOS attempts{% endtrans %}</li>
<li>{% trans %}Designed and optimized for exit traffic, with a large number of exit nodes{% endtrans %}</li>
<li>
{% trans -%}
Better documentation, has formal papers and specifications,
better website, many more translations
{%- endtrans %}
</li>
<li>{% trans %}More efficient with memory usage{% endtrans %}</li>
<li>{% trans %}Tor client nodes have very low bandwidth overhead{% endtrans %}</li>
<li>
{% trans -%}
Centralized control reduces the complexity at each
node and can efficiently address Sybil attacks
{%- endtrans %}
</li>
<li>
{% trans -%}
A core of high capacity nodes provides higher
throughput and lower latency
{%- endtrans %}
</li>
<li>{% trans %}C, not Java (ewww){% endtrans %}</li>
</ul>
<h3>Benefits of I2P over Tor</h3>
<h3>{{ _('Benefits of I2P over Tor') }}</h3>
<ul>
<li>Designed and optimized for hidden services, which are much faster than in Tor</li>
<li>Fully distributed and self organizing</li>
<li>Peers are selected by continuously profiling and ranking performance,
rather than trusting claimed capacity</li>
<li>Floodfill peers ("directory servers") are varying and untrusted,
rather than hardcoded</li>
<li>Small enough that it hasn't been blocked or DOSed much, or at all</li>
<li>Peer-to-peer friendly</li>
<li>Packet switched instead of circuit switched
<li>{% trans %}Designed and optimized for hidden services, which are much faster than in Tor{% endtrans %}</li>
<li>{% trans %}Fully distributed and self organizing{% endtrans %}</li>
<li>
{% trans -%}
Peers are selected by continuously profiling and ranking performance,
rather than trusting claimed capacity
{%- endtrans %}
</li>
<li>
{% trans -%}
Floodfill peers ("directory servers") are varying and untrusted,
rather than hardcoded
{%- endtrans %}
</li>
<li>{% trans %}Small enough that it hasn't been blocked or DOSed much, or at all{% endtrans %}</li>
<li>{% trans %}Peer-to-peer friendly{% endtrans %}</li>
<li>{% trans %}Packet switched instead of circuit switched{% endtrans %}
<ul>
<li>implicit transparent load balancing of messages
across multiple peers, rather than a single path</li>
<li>resilience vs. failures by running multiple
tunnels in parallel, plus rotating tunnels</li>
<li>scale each client's connections at O(1) instead
of O(N) (Alice has e.g. 2 inbound tunnels that are
used by all of the peers Alice is talking with,
rather than a circuit for each)</li>
</ul></li>
<li>Unidirectional tunnels instead of bidirectional
circuits, doubling the number of nodes a peer has to
compromise to get the same information.</li>
<li>Protection against detecting client activity, even
when an attacker is participating in the tunnel, as
tunnels are used for more than simply passing end
to end messages (e.g. netDb, tunnel management,
tunnel testing)</li>
<li>Tunnels in I2P are short lived, decreasing the number
of samples that an attacker can use to mount an
active attack with, unlike circuits in Tor, which are
typically long lived.</li>
<li>I2P APIs are designed specifically for anonymity and
security, while SOCKS is designed for functionality.</li>
<li>Essentially all peers participate in routing for others</li>
<li>The bandwidth overhead of being a full peer is low,
while in Tor, while client nodes don't require much
bandwidth, they don't fully participate in the mixnet.</li>
<li>Integrated automatic update mechanism</li>
<li>Both TCP and UDP transports</li>
<li>Java, not C (ewww)</li>
<li>
{% trans -%}
implicit transparent load balancing of messages
across multiple peers, rather than a single path
{%- endtrans %}
</li>
<li>
{% trans -%}
resilience vs. failures by running multiple
tunnels in parallel, plus rotating tunnels
{%- endtrans %}
</li>
<li>
{% trans -%}
scale each client's connections at O(1) instead
of O(N) (Alice has e.g. 2 inbound tunnels that are
used by all of the peers Alice is talking with,
rather than a circuit for each)
{%- endtrans %}
</li>
</ul>
</li>
<li>
{% trans -%}
Unidirectional tunnels instead of bidirectional
circuits, doubling the number of nodes a peer has to
compromise to get the same information.
{%- endtrans %}
</li>
<li>
{% trans -%}
Protection against detecting client activity, even
when an attacker is participating in the tunnel, as
tunnels are used for more than simply passing end
to end messages (e.g. netDb, tunnel management,
tunnel testing)
{%- endtrans %}
</li>
<li>
{% trans -%}
Tunnels in I2P are short lived, decreasing the number
of samples that an attacker can use to mount an
active attack with, unlike circuits in Tor, which are
typically long lived.
{%- endtrans %}
</li>
<li>
{% trans -%}
I2P APIs are designed specifically for anonymity and
security, while SOCKS is designed for functionality.
{%- endtrans %}
</li>
<li>{% trans %}Essentially all peers participate in routing for others{% endtrans %}</li>
<li>
{% trans -%}
The bandwidth overhead of being a full peer is low,
while in Tor, while client nodes don't require much
bandwidth, they don't fully participate in the mixnet.
{%- endtrans %}
</li>
<li>{% trans %}Integrated automatic update mechanism{% endtrans %}</li>
<li>{% trans %}Both TCP and UDP transports{% endtrans %}</li>
<li>{% trans %}Java, not C (ewww){% endtrans %}</li>
</ul>
<h3>Other potential benefits of I2P but not yet implemented</h3>
<p>...and may never be implemented, so don't count on them!</p>
<h3>{{ _('Other potential benefits of I2P but not yet implemented') }}</h3>
<p>{% trans %}...and may never be implemented, so don't count on them!{% endtrans %}</p>
<ul>
<li>Defense vs. message count analysis by garlic wrapping
multiple messages</li>
<li>Defense vs. long term intersection by adding delays
at various hops (where the delays are not discernible
by other hops)</li>
<li>Various mixing strategies at the tunnel level (e.g.
create a tunnel that will handle 500 messages / minute,
where the endpoint will inject dummy messages if there
are insufficient messages, etc)</li>
<li>
{% trans -%}
Defense vs. message count analysis by garlic wrapping
multiple messages
{%- endtrans %}
</li>
<li>
{% trans -%}
Defense vs. long term intersection by adding delays
at various hops (where the delays are not discernible
by other hops)
{%- endtrans %}
</li>
<li>
{% trans -%}
Various mixing strategies at the tunnel level (e.g.
create a tunnel that will handle 500 messages / minute,
where the endpoint will inject dummy messages if there
are insufficient messages, etc)
{%- endtrans %}
</li>
</ul>
{% endblock %}