Log In     Register    

Help and Support
Ask a question, report a problem, request a feature...
<<  Back To Forum

I2P Only Mode with a Click!!
Page 1 of 2     <<   <   12>>>
by Guest on 2026/05/17 09:46:41 AM    
Hi,

It would be a great option if Tixati could have an option that would make Tixati I2P only mode and nothing else. Right now, to make Tixati I2P is a bit of a puzze and that reflects in this forum.

Several ticks on . off, here and there.

Please consider to do that, since with the current torrent police, it is getting harder and dangerous.

Thanks
by Guest on 2026/05/18 07:58:28 AM    
I2P is not a single click solution for anonymity. Those do not exist. Moreover, if we assume typical torrenting speeds, you would be pretty noticeable among other nodes, and not anonymous at all. In that case, it only protects you if no one wants to find you in the first place.

I2P is also not a substitute for typical tunnels (VPN) and seedboxes used to evade detection when torrenting.

I think you can simply disable IPv4 and IPv6 interfaces to get what you want. It does not seem like a lot of work to me. However, it is not enough to get a secure system. You need to put software into controlled virtual or hardware compartments, and encrypt the data at rest. This is not some kind of spy tech, a typical employee of a typical corporation already uses many of those safeguards set by system administrators according to common best practices, and you should do at least as much.
by Guest on 2026/05/18 09:48:40 AM    
The above post if totally wrong, 100%. Using I2P ONLY mode, correctly set, others can only see that you are using I2P "protocol" (not sure how we can call it). They can't see what you are doing, chat, email, torrent etc etc.

The Tixati support or/and dev pls comment on that.
by Guest on 2026/05/18 10:25:50 PM    
If you go to Settings-Network-Connections, then go to Local IPv4/IPv6 address or interface and click the ... button and set them both to disabled no further traffic will go out that way. You will have to stop/start your transfers and probably clear all IPv4/IPv6 peers in your transfers. Or there are various right click ways to only use I2P with just transfers or just channels.
by Guest on 2026/05/19 01:12:23 AM    
The above post is totally right, 100%. :)

Please go to the I2P project website immediately, and read everything that it says about attacks and security model that you have skipped as uninteresting.

Let's say you got the Half-Life 3 leak, and seed it inside I2P as fast as possible. Average I2P node produces a certain amount of outgoing traffic, yours is doing megabytes per second. Also, if the torrent is public, anyone can try to connect a number of peers to it, then at once stop or start requesting data from all of them. If your traffic fluctuates in the same fashion, it is obvious that you are the source. No decryption of traffic is required.

This is not something theoretical, a typical system administrator should be able to do that to all the nodes in the network that can be observed. Anonymity means hiding something hardly noticeable in others' traffic, not pretending that elephant in the room is invisible to everyone.
by Guest on 2026/05/19 09:10:53 AM    
I2P is extremely slow, so the"traffic" is barely noticable. Also it has TREMENDOUS fluctuations as speed.

Actually is is the same logic with VPN (almost). I see you are using VPN, so you are a criminal.

Please do not scare people from using it.
by Guest on 2026/05/20 04:19:02 PM    
External observers have much less luck noticing “fluctuations” in traffic to correlate them with traffic patterns in I2P, because I2P intentionally mixes in routing traffic from other peers, and as far as I'm aware it uses the same kind of tunneling protocols and transport protocols both for traffic originating/destined from/to your host, and for relaying others' traffic. So please don't spread FUD about traffic fluctuations. If at all, Tor should have this issue, because Tor doesn't mix in traffic from other users, and both Tor clients and Tor Onion services are dedicated to browsing Tor/hosting on Tor (respectively) without relaying.

Furthermore, I2P doesn't require paths to by symmetric, the path packets do to travel back can go over other nodes, which further complicates observing I2P traffic because it requires the attacker to observe more nodes compared to a symmetric path like in Tor.

Going even further, I believe the newer I2P transport protocols have obfuscation built into them. Tor has it separate (obfs4, etc). There's no central list of I2P nodes either, although it might be easy to collect the list of all non-hidden I2P nodes (hidden nodes are automatically enabled in restricted countries by the I2P software, this makes them not publish themselves so they don't get incoming relay traffic, they act more like a Tor client in this sense). Tor, as far as I know, has a list of all Tor nodes that aren't hidden bridges published in the Tor directory authorities, and is publicly downloadable.

Finally, I2P is built to only forward traffic inside the network, rather than connecting to external public sites/servers like Tor. An observer watching a Tor exit node can see the traffic going out of the Tor network; an observer watching an I2P node has, as far as I know, no way to know if the traffic stopped there as a destination or is further relayed. I2P also starts many connections for maintaining tunnels and discovering nodes, so traffic can easily be started at nodes and isn't limited to traffic with any browsing content, but can be random-like connections like these.
by Guest on 2026/05/21 02:05:53 AM    
You imagine the best case scenario, then reassure yourself that it is true with feel-good reasoning. That does not work in security. You need to methodically go through every potential option attackers have, and check to which extent it is neutralised.

Start seeding some I2P torrent at 500 KB/s. Look at the network traffic graph. Stop seeding it. Look at the graph again. There is an Everest-sized peak, and anyone who is observing your traffic, can see it, too. Who does? Well, Snowden papers can give you an estimate, and in 15 years since that all the other countries rushed to get themselves something similar, so someone is always watching. Various shady companies also collect traffic data directly from ISPs to resell it.

I2P nodes are public by design. So-called hidden nodes still make direct connections to public ones. They only slightly increase the difficulty for active traffic censorship systems, and in most countries they are actively analysing and blocking live traffic, and not passively collecting data. Running I2P is not safe in locations where it can get you in trouble, and hidden mode does not protect against it. It is stated clearly in descriptions of I2P security.

The reasoning about delays and traffic analysis assumes small transfers of data that are hidden among many others. If you send a 15 KB text document over I2P, it would be hard to detect for external observers. If you send multi-gigabyte video files, you are naked on a city square wearing just a fig leaf.

I understand that you want to have a magical solution, and promote it, but it does not work like that. You need to understand that different activities have different visibility, and attract different attention. It is true that Hollywood probably won't pay much attention to all 5 people slowly sharing the movies over anonymous network, but it's also true that regular torrenting over VPN seems to shield users from it just as well.
by Guest on 2026/05/21 12:39:19 PM    
How about increasing the bandwidth share in I2P settings? That easily causes multi-gigabyte traffic from what I've personally tried. Have you tried this before writing your comment? Because then a multi-gigabyte file can blend in with the traffic.

I did say it might be easy to collect all I2P nodes, I just said it isn't as trivial as collecting Tor nodes because there's no need to collect them independently when the directory authorities keep a central up-to-date list of them. Have you missed that I said that? I'm aware that hidden I2P nodes connect to the “public” nodes, I wasn't implying otherwise. I wouldn't call I2P nodes “public-by-design”, I think it's more like “semi-public”. I believe the I2P team tries make it hard to scrape nodes, especially in recent versions. (Side note: There's nothing preventing the I2P team from starting a project like Tor's BridgeDB to have hidden nodes that do relay traffic like Tor bridges do. Perhaps the reason they haven't done it yet is because it isn't needed? I don't know.)

I'm in no interest to look for “magical solutions” nor to promote anything. I started my reply by debunking FUD about traffic analysis, and this is what my post was focused about. (By the way, it was the first time I participated in this thread, to be clear.)
by Guest on 2026/05/21 02:04:39 PM    
You can monitor your up/down traffic, using this open source and free little tool, that stays sticked on your desktop.

https://github.com/zhongyang219/TrafficMonitor
by Guest on 2026/05/22 07:36:21 AM    
Imagine the censorship agency is some country. You see some unknown traffic from local address (host and port) to multiple addresses outside. You don't need to grab all the I2P nodes that exist from the I2P network, or even most of them. Once you see that just a couple of those addresses belong to known I2P nodes, you know it is a local I2P node, and block it. The end. No one is going to argue with you in case of mistake anyway.

Hidden nodes are just made for some plausible deniability in cases where the law still protects you somehow. They could work 20 years ago, but today's Internet is much more hostile.

Imagine that you observe the traffic of a busy I2P node. At a first glance, you see opaque encrypted megabits. However, you can also measure connection to each peer individually, get the combined ingress and egress amounts for small periods of time, and figure out what amount of traffic has a high chance of being in transit, and what amount comes to or from your node. Then it is also possible to manipulate connection speed (or just drop the connections) to check the consequences on, say, some peer you control.

Also, according to checki2p.com metrics, there is a significant disproportion between reachable and unreachable (NAT'ed) nodes. The latter receive much less transit traffic.

It is all explained on the project website. If it is “FUD”, then what isn't?

Anonymity is not a binary property, it is a chance, a chance to be found in certain crowd. In various circumstances, you can be both anonymous to one kind of observer, and easily detected by the other. I gave an example of someone running an active public torrent inside I2P. However, that same torrent that is not public (only shared with a couple of friends) would not be that easy to detect.
by Guest on 2026/05/23 05:19:36 PM    
“Once you see that just a couple of those addresses belong to known I2P nodes, you know it is a local I2P node, and block it.”
The main point that was brought up is that it's possible to correlate specific I2P traffic to determine that it's BitTorrent. The main point wasn't whether I2P as a whole is easy to block (although we did talk about it as well). (Also I'm not sure what you mean exactly by “local I2P node”.)

“Hidden nodes are just made for some plausible deniability in cases where the law still protects you somehow. They could work 20 years ago, but today's Internet is much more hostile.”
My comment about hidden nodes was in parantheses. It was mentioned to make my reply fuller with more relevant details, but it's not a point of argument in the discussed issue. As I said, the I2P project could start something like Tor's BridgeDB, and maybe they haven't done it yet because they think the status quo is sufficient. This is besides the topic.

“figure out what amount of traffic has a high chance of being in transit”
All traffic is always by definition “in transit”, so it's unclear what you mean here.

“what amount comes to or from your node”
As I said, all I2P nodes (basically) are relays too, and they create many connections for testing and maintaining tunnels, and generate lots of random traffic. And as I said, an external observer can't really see if traffic is stopping at a node or continuing further, because the protocol doesn't leak this metadata (as far as I know), and there's lots of other traffic mixed in. Different messages are also bundled together in the same tunnel sometimes due to garlic routing compared to Tor's onion routing. So this problem you're describing is basically speculation/FUD you're making up.

“Then it is also possible to manipulate connection speed (or just drop the connections) to check the consequences on, say, some peer you control.”
So now we're assuming the adversary can monitor both one user and all other users? As I said, I2P makes this much harder than Tor, but ultimately neither Tor nor I2P are designed to work well when an adversary can monitor such a significant amount of nodes. This is a classic correlation attack. There's nothing novel or shocking about it, it's well known, and again, I2P has much better protections against that compared to Tor. So again, presenting this speculated issue as if I2P is mostly useless or broken, is FUD. Unless you have a source to back up a claim that an organization/entity is monitoring a significant portion of I2P nodes right now?
Should be said that since I2P traffic isn't limited to just the BitTorrent traffic you do over it, the network administrator limiting the speed of I2P on the network might not correspond well to a slowdown in the BitTorrent traffic inside I2P.

“It is all explained on the project website. If it is “FUD”, then what isn't?”
The problem isn't the project's official documentation, which describes technical qualities of the software. The problem is making alarmist claims presented as if I2P is practically broken for users right now, which isn't necessarily the case. That's the FUD.
Furthermore, it was claimed that an adversary can figure out spikes in traffic to figure out that it's BitTorrent — I refuted that and backed my refutation with facts as examples of how I2P does better than Tor in this regard.

“Anonymity is not a binary property, it is a chance, a chance to be found in certain crowd. In various circumstances, you can be both anonymous to one kind of observer, and easily detected by the other. I gave an example of someone running an active public torrent inside I2P. However, that same torrent that is not public (only shared with a couple of friends) would not be that easy to detect.”
I've never claimed anonymity was a binary thing.
Once again, I2P has the protections I described in place to try to prevent traffic analysis, making it harder even if an adversary monitors a significant portion of the I2P network, even though I2P/Tor aren't expected to work well if an attacker can monitor the entire path to correlate traffic. Presenting this attack as if it's easy to pull up is FUD. Quote (example):
“This is not something theoretical, a typical system administrator should be able to do that to all the nodes in the network that can be observed. Anonymity means hiding something hardly noticeable in others' traffic, not pretending that elephant in the room is invisible to everyone.”
I2P does hide BitTorrent traffic with other kinds of traffic and even other users' traffic, even if you don't use I2P for any kind of online activity other than BitTorrent.

Has anyone here actually tried setting up two I2P nodes within their network, seeding a torrent in one and downloading it in the other, blocking/disconnecting the seeding node and then watching the downloading node's traffic to see if it's possible to see a change in I2P traffic that can be attributed to the BitTorrent seed going down? This simulates a case where the adversary watching both nodes can only see the overall traffic at the network-level, and suspects one is a BitTorrent seed.

If the attacker can connect to the torrent in question (which is indeed much easier with a public torrent as you said), then the attacker certainly has the potential to detect a peer/seed going down at the BitTorrent level. However, if the BitTorrent seed periodically (in randomly varying intervals) randomizes its peer ID and drops the ongoing state (i.e. drops the ongoing connections to other nodes), with a randomly varying delay between disconnecting and dropping state to reconnecting again to the swarm with a new peer ID, then BitTorrent-level identifiers are no longer persistent to correlate them with network-level events and connect them to past/future peer IDs of the same peer. (It might also be wise for peers/seeds after reappearing with a new randomized peer ID to randomly hide the fact that they hold a certain percentage of torrent pieces they do in fact hold already, to make it harder to “fingerprint” BitTorrent peers/seeds based on their held pieces. The exact pieces should be determined before reappearing with the new peer ID, rather than a random chance when a piece is requested, and the exact pieces chosen to be hidden should stay hidden until either the peer ID is randomized again or the piece is received from another peer, which is as if the piece was just downloaded so there's no need to hide the fact that we already held this piece before. Also it shouldn't advertise pieces it doesn't have, because that can be detected as a lie when the piece isn't provided.) This would make it significantly harder to have an advantage to know which suspected I2P node is a BitTorrent seed of a suspected torrent by observing the BitTorrent swarm for a suspected torrent. I don't know whether Tixati or I2P's built-in BitTorrent client do these things already. Note that none of this is an I2P issue, but a BitTorrent issue. It's well known that traffic carried over I2P/Tor can deanonymize you. I2P makes you more anonymous on the network level but can't magically fix anonymity issues above it.
by Guest on 2026/05/23 05:42:29 PM    
I couldn't edit my message to add this:
The BitTorrent client program can also drop state and randomize the peer ID after all connections have timed out for a while, to make peers going down from network-level issues indistinguishable from peers intentionally dropping state and randomizing their ID, and prevent turning off the network or I2P access being a useful way to detect whether a specific BitTorrent peer disappears/reappears in the swarm.
by Guest on 2026/05/24 01:03:08 PM    
> All traffic is always by definition “in transit”

Transit traffic is the one you relay for others as part of the transit tunnels. Traffic that goes to/from your local applications through incoming or outgoing tunnels is not transit.

If you have a couple of transit tunnels giving your I2P node 5 KB/s of incoming and outgoing traffic, and you also seed some torrent at 1 MB/s, any observer can figure out that your node is the source, and it sends around 1 MB/s of some data to someone.

> all I2P nodes (basically) are relays too, and they create many connections for testing and maintaining tunnels, and generate lots of random traffic

Nodes with limited connectivity (behind NAT) get 20-40 KB/s of transit traffic on average. Nodes with limited connectivity make 3/4ths of the I2P network.

> as if I2P is mostly useless or broken

I've stated that certain activities can remain hidden (depending on what you do, and who wants to get you), and others are absolutely not. Transferring terabytes of data is the latter.

> a source to back up a claim that an organization/entity is monitoring a significant portion of I2P nodes right now

Go read presentations released by Snowden, then extrapolate the growth of that cancer to current year. Governments, corporations, security intelligence brokers all want to observe as much as possible, either without asking, or by simply buying the data.

Also, someone does not really need to observer the whole network. It can start with observing the nodes that are available. Yours, for example.

> the project's official documentation, which describes technical qualities of the software

Go read the central ideas you've skipped:

https://i2p.net/en/docs/overview/threat-model/
by Guest on 2026/05/24 10:14:17 PM    
I2P's Threat Model

Analysis of attacks considered in I2P's design and the mitigations in place
Updated: 2010-11
Accurate for: 0.8.1

Your link is from 2011 !!!!


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Updated: 2010-11
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
by Guest on 2026/05/25 01:56:03 AM    
“Transit traffic is the one you relay for others as part of the transit tunnels. Traffic that goes to/from your local applications through incoming or outgoing tunnels is not transit.”
So you were using I2P-specific terminology. I called that relayed traffic.

“If you have a couple of transit tunnels giving your I2P node 5 KB/s of incoming and outgoing traffic, and you also seed some torrent at 1 MB/s, any observer can figure out that your node is the source, and it sends around 1 MB/s of some data to someone.”
I already debunked this. How would the network administrator know what percentage of the data coming into/out of an I2P-running host is due to traffic generated for tunnel maintenance and network discovery, versus original traffic? You're being rude to me while ignoring things I've already said.

“Nodes with limited connectivity (behind NAT) get 20-40 KB/s of transit traffic on average. Nodes with limited connectivity make 3/4ths of the I2P network.”
How does this refute the claim you wrote this in reply to?
Nodes with lower bandwidth would get proportionally lower bandwidth for all network activity in and out of I2P. I still don't see how this would help a network administrator figure out what percentage of the I2P traffic belong to original traffic versus traffic generated as part of tunnel maintenance and network discovery.
I fail to see the relation between bandwidth and NAT. Hosts can be not behind NAT and have low bandwidth, and can be behind NAT and have high bandwidth.

“I've stated that certain activities can remain hidden (depending on what you do, and who wants to get you), and others are absolutely not. Transferring terabytes of data is the latter.”
You seem to be implying that no matter what bandwidth an I2P node has, torrenting within I2P always uses proportionally many times more I2P traffic than otherwise, and that a network monitor can easily point out that node as a BitTorrent user simply by looking at the incoming/outgoing byte rates in combination with presuming/knowing it's an I2P node. You've failed so far to provide solid proof for this, and I already debunked this.

“Go read presentations released by Snowden, then extrapolate the growth of that cancer to current year. Governments, corporations, security intelligence brokers all want to observe as much as possible, either without asking, or by simply buying the data.”
Slight paranoia can be healthy in today's world that's highly monitored and has broad security/privacy violations that are made more sophisticated but also more accessible and widespread.
With that said, there was FUD in this thread saying that I2P is broken and can be easily broken, which is an extraordinary claim. Extrapolation doesn't satisfy me, you need to start backing up your alarmist claims with actual data/evidence (no need to completely prove anything, just provide some solid data or source which has some credibility showing that I2P has been successfully broken).

“Also, someone does not really need to observer the whole network. It can start with observing the nodes that are available. Yours, for example.”
This implies that you don't understand the purpose of onion routing/garlic routing/etc. The whole point of I2P/Tor is that someone monitoring just my computer's network traffic can understand nothing from it. It's not just encrypted in transit, it's obfuscated at the network-level because of onion/garlic requests with multiple hops, etc.
You're not refuting anything I've said.

“Go read the central ideas you've skipped:”
You're rude for no good reason while also not refuting my arguments.

https://i2p.net/en/docs/overview/threat-model/”
I skimmed through this page, and discovered nothing really surprising to me. If at all, it seems to confirm the way I think about I2P and my claims.
Instead of rudely sending me to read a whole page, how about you quote something I claimed, quote something from the link you provided (I2P's official website), and explain how the quote from the link refutes/contradicts with the quote from my posts?
by Guest on 2026/05/25 03:39:32 PM    
> Your link is from 2011 !!!!

Theory behind I2P has not changed since the beginning. Some might even say that Opennet was insecure™ from the start.

> How would the network administrator know what percentage of the data coming into/out of an I2P-running host is due to traffic generated for tunnel maintenance and network discovery, versus original traffic?

No problem, subtract 1 KB/s or maintenance traffic, we still get 1023 KB/s difference between bytes coming to certain port, and bytes leaving it.

> I fail to see the relation between bandwidth and NAT.

Two nodes behind NAT can't connect to each other, they have to use some active node as a next hop for any of the participating tunnels. Nodes with open ports become over-loaded, nodes with closed ports become under-loaded.

> Hosts can be not behind NAT and have low bandwidth, and can be behind NAT and have high bandwidth.

You can have unlimited bandwidth in settings, the amount of transit traffic you get is still tiny, for the same reason.

> torrenting within I2P always uses proportionally many times more I2P traffic than otherwise

If you don't deliberately limit it to a small percentage of transit traffic, as intended.

> Slight paranoia

As you haven't read the documents, you still haven't realised that mass observation became real two decades ago, with passive and active cooperation from various corporations.

> I skimmed through this page

Well, that's your problem. You don't understand how I2P operates, what it can and can not do for the user, what others can learn about you. Instead of that, you enjoy the sound of terms like “garlic routing” and “obfuscation”. Those do nothing if you don't understand what they mean. For the same reason, you keep insisting that I call I2P “broken”, while I merely point out that you can hide a piece of paper in the room, but not the elephant.
by Guest on 2026/05/26 12:39:29 PM    
... This is getting hairy ....
by Guest on 2026/05/26 10:08:12 PM    
“No problem, subtract 1 KB/s or maintenance traffic, we still get 1023 KB/s difference between bytes coming to certain port, and bytes leaving it.”
You keep saying that the traffic generated by I2P that's not relayed traffic or user traffic is a mere 1 KB/s. I remember that being much greater from the last time I used I2P. It can also fluctuate, as was said by other people here.

“Two nodes behind NAT can't connect to each other, they have to use some active node as a next hop for any of the participating tunnels. Nodes with open ports become over-loaded, nodes with closed ports become under-loaded.”
Firstly, I believe that nodes can initiate a connection to other nodes to receive traffic. The direction of the connection doesn't necessarily correspond to the direction of the traffic, at best I believe it limits the relations that can be formed between nodes. BitTorrent does that, for example.
Secondly, you're still not explaining what this has to do with refuting what you quoted when you replied this. Here's the quote you gave:
all I2P nodes (basically) are relays too, and they create many connections for testing and maintaining tunnels, and generate lots of random traffic
Full context:
“(figure out what amount comes to or from your node) As I said, all I2P nodes (basically) are relays too, and they create many connections for testing and maintaining tunnels, and generate lots of random traffic. And as I said, an external observer can't really see if traffic is stopping at a node or continuing further, because the protocol doesn't leak this metadata (as far as I know), and there's lots of other traffic mixed in. Different messages are also bundled together in the same tunnel sometimes due to garlic routing compared to Tor's onion routing.”

“You can have unlimited bandwidth in settings, the amount of transit traffic you get is still tiny, for the same reason.”
Once again, this isn't just about relayed traffic being mixed in. There's lots of other traffic generated by I2P.
Furthermore, I don't remember that being my experience the last time I used I2P, but maybe I don't remember well.

“If you don't deliberately limit it to a small percentage of transit traffic, as intended.”
You seem to not understand what you're saying. You're all talking in absolute units, I'm talking about proportions. If the overall bandwidth allocated to I2P is, let's say, 2 KB/s, and you're claiming that I2P-generated traffic is always about 1 KB/s, then surely BitTorrent over I2P would have at most roughly 1 KB/s bandwidth to utilize, which means traffic without BitTorrent would amount to roughly 1 KB/s whereas traffic with BitTorrent would reach at most 2 KB/s, which is definitely not “proportionally many times more I2P traffic than otherwise”.
And once again, this isn't necessarily just about “transit traffic” (i.e. relayed traffic).

Now that I'm thinking, if I'm recalling correctly, I2P has a rather conservative overall bandwidth limit applied by default. It's well known that changing configuration of anonymity software (Tor Browser for example) can degrade the protection, and most users will stick to the defaults. (Note that I'm not saying the user is 100% responsible if a change harms their protection, if for example the software recommends the user to tweak the settings.)

“As you haven't read the documents, you still haven't realised that mass observation became real two decades ago, with passive and active cooperation from various corporations.”
False. The way you derived this conclusion is fallacious, rude, and contradicts what I said myself:
“Slight paranoia can be healthy in today's world that's highly monitored and has broad security/privacy violations that are made more sophisticated but also more accessible and widespread.”
Saying there's giant effort and largely lots of success in violating people's privacy and security is one thing, but claiming that security mechanisms that have a lot in their favor to say that they still work in the way they're intended and not much against to say that they may not work anymore, with the only reason to back it up is “THE GOVERNMENTS OF ALL COUNTRIES EVERYWHERE MONITOR EVERYONE AND SEE EVERYTHING” is religious conspiratorial zealotry. You could use the same reasoning to say that the new post-quantum cryptographic standards (ML-KEM, ML-DSA…) are broken because they were standardized by a US agency that previously standardized an NSA-compromised algorithm (Dual_EC_DRBG), which doesn't make sense because they made a public competition and scrutiny for ML-KEM, ML-DSA…
A government wanting to violate someone's privacy, for example deanonymize them in I2P, has a lot more things they can do that isn't breaking I2P privacy guarantees. It's the same argument that sometimes people say against Tor, that criminals using Tor were caught in the past. That doesn't mean Tor's protections were broken.
I'd prefer if you focus on technical substance than bring up rude and incorrect accusations that I “don't know” there's surveillance and privacy violations widespread (which, by the way, is much more widespread and sophisticated today than “two decades ago” as you said), or claiming that reading certain documents is necessary to reach this understanding.

You're not arguing in good faith.

“You don't understand how I2P operates”
False, and I've shown otherwise.

“what it can and can not do for the user”
False. I've also not been necessarily claiming that BitTorrent over I2P is definitely private and anonymous, rather I refuted an argument that claimed otherwise, and have been asking you to improve your argument, which you've failed so far and resorted to ad hominem accusations instead at parts.

“you enjoy the sound of terms like ‘garlic routing’ and ‘obfuscation’ ”
False and rude. I don't “enjoy the sound” of anything. These features all help contribute to I2P's comparative strengths to Tor which lacks them. They're also relevant to the discussion because they all contribute to I2P's potential capability to better resist traffic analysis. This is why I mentioned these things, and it's rude and fallacious to claim I mentioned them because I like how they sound (which also rudely implies I don't understand what they mean, even though I briefly explained them).

“Those do nothing if you don't understand what they mean.”
False. I2P's features' effectiveness is unchanged depending on the user understanding of them. That doesn't mean the user is equally likely well protected when they do or don't have understanding of anonymity risks in general, it simply means it's false to claim that the protection provided by these specific features is weaker if the user doesn't understand specifically these features.

“you keep insisting that I call I2P ‘broken’, while I merely point out that you can hide a piece of paper in the room, but not the elephant.”
You're the one who brought up the argument of mass surveillance, and even implied that the government can break I2P protections completely:
“I've stated that certain activities can remain hidden (depending on what you do, and who wants to get you), and others are absolutely not.”
(Emphasis mine.)
I think it's unheard of to call Tor/I2P/encryption “unbroken” if we knew a government knew how to break it. These kinds of projects are intended to protect users from all threats, including governments.

Since you've failed so far to discuss the technical topic and refute my arguments, and it seems like you can't/don't want to because you're not arguing in good faith, I'll probably stop engaging with you now.
by Guest on 2026/05/26 10:44:43 PM    
Important clarification I should've added in my post:
Since I2P-generated traffic (tunnel maintenance, network discovery, etc) and user-generated traffic over I2P both can be formed in both directions (inbound and outbound), relayed traffic does help mask the traffic because the trick of calculating the difference in throughput between the two directions doesn't help anymore. For example, you could be downloading a large file (user-generated incoming traffic) at the same time as you're seeding a large file in BitTorrent (user-generated outgoing traffic). Suddenly, your easy trick doesn't work anymore, because it assumes that one of the directions carries only relayed traffic and the other direction carries both the relayed traffic and original (user-generated or I2P-generated) traffic, and this assumption is broken.
Page 1 of 2     <<   <   12>>>
<<  Back To Forum




This web site is powered by Super Simple Server