The potential for timing attacks has been known since the beginning of Tor. In other words, more than a decade. But that doesn't mean you can't defend against it. One way to defend against it is by having more nodes. Another way is to write clients that take into account the potential for timing attacks. Both of these were specifically mentioned in the article.
Based on what was in the article and what's in the history books, I'm not sure how to interpret your comment in a constructive way. Is there anything more specific you meant, that isn't contradicted by what's in the article?
Before you use I2P, use Basic Computer Hygiene Always! Apply your OS vendor provided software updates in a prompt manner. Be aware of the state of your firewall and anti-virus status if you use one. Always get your software from authentic sources.
It may be dangerous to use I2P in what the project calls "Strict Countries"
Most I2P peers are not in those strict countries and the ones that are, are placed in "Hidden Mode" where they interact with the rest of the network in more limited ways, so that they are less visible to network observers.
Unlike Tor, "exit nodes" - or "outproxies" as they are referred to on the I2P network - are not an inherent part of the network. Only volunteers who specifically set up and run separate applications will relay traffic to the regular Internet. There are very, very few of these.
There is an outproxy guide available on our forums, if you would like to learn more about running an outproxy.
If you are hosting something sensitive, then your services will go down at the same time that your router goes down. Someone who observes your downtime and correlates it to real-world events could probably de-anonymize you with enough effort.
I2P has defenses available against this like multihoming or Tahoe-LAFS
I2P does not encrypt the Internet, neither does Tor - for example, through Transport Layer Security (TLS). I2P and Tor both aim to transport your traffic as-is securely and anonymously over the corresponding network, to its destination.
In addition, you may be vulnerable to collusion between the outproxy operator and operators of other I2P services, if you use the same tunnels ("shared clients").
In theory, if you're accessing the clearnet, then it is no better or worse than TOR. It is a little better if you're stay in I2P land.
Don't listen to me or him. If you're reading this, go to the FAQ (https://geti2p.net/en/faq) and make your own decisions.
TOR is obvious too to someone snooping on your network, unless you're using bridges (and that's hit or miss). If you don't want someone to know you're using I2P, use OpenVPN and mask your traffic as HTTPS.
You're going to have to explain better about "I2P not masking your traffic" and especially about "someone identifying you" - timing attacks are possible in both cases and the I2P Devs have mitigations against it. Please provide sources which define how I2P is weaker and more susceptible to TOR against network forensics
it has higher latency, even variable latency if you set up variable hops, and everyone routes the traffic of a lot of other users, so a lot of data they can gather from timing info is noise by default
Yes it has better defenses against timing attacks. Just alone the fact that multiple packets are bundled together makes it harder to identify the route a single package used.
Also, it seems that I2P is more vulnerable against deanonymization when leaving the hidden network, i think the official I2P faq has some info about that, but have not read up upon it myself.
Also, it seems that I2P is more vulnerable against deanonymization when leaving the hidden network, i think the official I2P faq has some info about that, but have not read up upon it myself.
on a quick look I did not find such a mention, but in any case in addition to that, I2P users often don't have such a fortified browser as Tor users do, so that's also something to count with.
and maybe it's not a good idea either to just reconfigure a Tor browser profile for I2P
Garlic routing[1] is a variant of onion routing that encrypts multiple messages together to make it more difficult[2] for attackers to perform traffic analysis and to increase the speed of data transfer.[3]
First sentence. Check up the linked article as source.