The most critical reason to pick GNUnet is the long-term need of secushare to have a strategy for many-to-many scalability. Both Tor and I2P can scale well in the number of one-to-one communications, but this only re-enforces the client/server paradigm which is threatening the privacy and thus the democratic civil rights of billions of human beings. Actual scalable, serverless, distributed social interaction requires a pubsub system over a distributed scalable multicast backbone, natively capable of spawning distribution trees somewhat like BitTorrent. You can also compare it to cloud technology, only that the cloud is diverse and belongs to its users (easily said but quite hard to implement). In unison with the GNUnet team we are working on this. cjdns could be a nice intermediate solution on this front if anonymity wasn't a goal.

As also discussed in comparison, both I2P and Tor have some open issues with their use of Distributed Hashtable (DHT) technology prone to sybil attacks. GNUnet has designed its routing (core) and GNU Name System (GNS) in ways that are resistant to such attacks.

Also, both Tor and I2P suffer from their will to deliver best-effort real-time service, making the traffic susceptible to shaping and fingerprinting and therefore traceable by a global active attacker such as certain spook agencies. The measures discussed in the Tor community for dealing with this problem are just what GNUnet has already been providing from the start: a constant bandwidth stream between nodes which in Tor would only be network load while in GNUnet it is used to deliver unrelated yet useful information such as file sharing replication or low-priority social networking chatter. These measures can make parts of the journey along the onion circuit resistant to fingerprinting. There is also a proposal to improve Tor's resistance against traffic fingerprinting called alpha mixing, but it has been lying around unimplemented since 2006. A decade later, research has come up with other ways to protect onion routing against fingerprinting attacks. These strategies make even more sense when deployed in GNUnet, since decoy traffic isn't just overhead, it is useful to other purposes.

Both Tor and GNUnet provide us with excellent code quality and sound conceptual foundations coming from a scientific background. Yet, an authority-free onion routing strategy for GNUnet is still in the making. That doesn't mean that GNUnet is not enhancing anonymity already. The secushare/GNUnet anonymity strategy stands on four feet:

While Tor puts all bets on strategy 4 and I2P is somewhere closer to strategy 2, we think to achieve anonymity it's best to use all strategies and only leave out some of them when inevitable.

For example we can afford not to have a permanent bandwidth allocation if we have framing and onion routing, thus allowing for distributed social networking apps on mobile phones.

Or we can afford to reduce the onion routing for real-time traffic if we can segment and mix it with file sharing data, this way also defeating phoneme detection attacks on voice traffic. (1) (2) (3) (4) (5)

Or we can surf the insecure web and risk fingerprinting attacks if the traffic then goes through onion routes over constant bandwidth channels.

And nothing keeps us from securing our best secrets like our political views, commentaries and intimate nudities by using all strategies at once.

Since GNUnet is already implementing two of the strategies (#1 and #2 above), it is currently not scientifically obvious, whether it serves a better or worse job at achieving anonymity than Tor, under the condition that you do not disable the anonymous file sharing service (which is stellar, by the way).

We have reason to assume that once onion routing over GNUnet comes available, GNUnet should become safer than its predecessors, even with file sharing disabled.

Maybe Tor will remain the tool of choice to access the unsafe World Wide Web and browsing the web in a guaranteed anonymous way may never be possible again. Or maybe, if we combine the other two strategies being cover traffic and onion routing, we can afford to leave out framing.

Something we can certainly do is to produce a new kind of secure web which leverages the pubsub philosophy of secushare. A web that has no artificial best-effort requirements. This is described a bit in the business document, but it actually applies to any kind of content we like to share with people.

When using onion routing each person is addressed via the other end of one of its onion circuits rather than its actual node location. In the source code this doesn't even make a difference: in both cases there is a "PeerID" which knows how to deliver data to its destination, regardless of how long or short an onion route follows. Therefore in our code the PeerID may contain the onion meeting point rather than the factual node address of a person (unless a direct communication is fine for some purposes, but "direct" is merely a special case of onion routing with zero hops in-between, so it must not make any difference in the code and be not obviously discernable by outside observers).

Also our onion routing does not necessarily need to be using Tor's three hops. Even if we only have one onion hop, that hop would not know that the next node is already the last one. How much this may reduce the anonymity isn't researched as yet, but it only affects people who have chosen convenience over anonymity while some apps like video telephony may not seriously leave us a choice.

Other circuits may have more hops than usual with Tor. The PISCES paper mentioned above worked out a method for better onion routing which involves the social graph and an increased number of hops rather then the traditional three. Within Tor it is not recommended to use four-hops circuits, because the unusual behaviour could single the user out of the masses. This worry of course does not apply if all nodes use rather unpredictable numbers of hops for their circuits. What remains are circuits, the onion skins are optional.

secushare is a tool meant to throw in a reasonable amount of anonymity where it is easily feasible while giving people a user experience of a properly performing Internet. While people currently need to separate tools to decide if they are going to do something over Tor or in the nude, in secushare this choice is intelligently automated and never really fully naked. Even if only two GNUnet nodes are exchanging a large chunk of data, that data may still be a submission to a mixnet which the receiving node will forward elsewhere at a completely different point in time.

We are also discussing the possibilities of optimization of anonymity when combining onion routing with multicast. And then it also makes sense to make topological choices for onion hops to reduce latency. If you have a thousand nodes to choose from in your city, why use a direct connection for a phone call if you can have an onion-routed one? Tor developers see a threat in reducing anonymity this way, which is still subject to be proven or disproven, but if the alternative is to totally give into convenience, we have nothing to lose in preferring topologically optimized onion routing.