Shared Clients, Correlation, and Collusion

Misc topics about I2P
Post Reply
slumlord

Shared Clients, Correlation, and Collusion

Post by slumlord »

Mirrored from zzz.i2p/topics/217 (currently offline) for inclusion in updated FAQs

A discussion from 2009:
zzz wrote:
Every client that has the 'shared clients' option checked uses the same destination, which is static until restart. So if you (for example) use a shared clients IRC client tunnel, and a shared clients HTTP tunnel, then those have the same destination.

So if the IRC ops share information with the HTTP outproxy op, then they can correlate the websites you visit to your IRC nick. Or share with tracker ops to correlate bittorrent infohashes you are announcing to your identity. Note that two of the three tracker ops in I2P also run IRC servers.

Or a eepsite that uses registration and cookies (like this one) could associate your nick with a destination, then share that information with a $badsite.i2p op.

Possible countermeasures:

- Don't use a shared client for IRC, monotone, SMTP/POP, or other services where login is required
- Or the reverse - use shared clients for all of those, but not for the HTTP proxy
- Create a separate HTTP proxy client for your bittorrent client to use
- Use different non-shared clients for HTTP proxy to the outproxy and for HTTP proxy to .i2p eepsites
- The new generate-new-client-destination-on-idle option in i2ptunnel, which looks nice and shiny in the GUI, but isn't implemented yet :(

As always, try to keep your 'identified' or registered or pseudonymous activities separate from those you want truly anonymous.
devzero wrote:
I am impressed to imagine that. It helps collecting data of user identities and their actions. Data collectors doing so at an anonymous network shouldn't be able to do so by default.

There is analytical software out there, which can analyse postings of different nicks at different forums and is able to reveal identities posting under differnt nicks. It is stupid to help data collectors to give them the possibility to prove those assumptions.
zzz wrote:
Here's a proposal for a high-anonymity yet efficient setup using the new advanced i2ptunnel features. I'd like to make this the default in a future release, after the new features are well-debugged.

Please comment on this proposal, and test out these settings. Thanks.

eepProxy
non-shared
reduce on idle 10 minutes

ircProxy
non-shared
delay open
close on idle 5 minutes

smtp
shared
delay open
close on idle 5 minutes

pop3
shared
delay open
close on idle 5 minutes
Lurker wrote:
i think, as you don't browse eepsites 24/7 it couuld also be set to close on idle.
maybe reduce after 5 mins and close after 15 mins.

I think the settings you outlined here sound very reasonable, so I vote for making them default, as not all users will mess around with their settings nor even _know_ anough about the workings of anonymity to be fully aware, even if they wanted to set their settings they wouldn't know it matters...
so any objections on making it default?
zzz wrote:
My proposal above is to make it the default. Once it works. That's what I said.

Close-on-idle for eepProxy may delay browsing unacceptably. Depends how fast you can build a tunnel.
Lurker wrote:
as long as tunnels don't reliably close I cannot tell from own experience how fast it works....
but I will keep an eye on it
Lurker wrote:
Ok, my experiences so far

I have the following settings:

eepProxy
non-shared
reduce on idle 5 minutes
close on idle 15 minutes

ircProxy
non-shared
delay open
close on idle 5 minutes

smtp
shared
delay open
close on idle 5 minutes

pop3
shared
delay open
close on idle 5 minutes

Works splendidly, with exception to current network situation where nothing works splendidly anymore.
But same issues arise with normal settings.
Current running version: 0.7.4-2
Lurker wrote:
oh, forgot the delay open for eepproxy.
Post Reply