What information is given to the other other side of the tunnel(focus is on tracking)?
Generally if I visit some website in private window and close it so cookies go away, can website still identify me because I only have 3 tunnels (Exploratory tunnels will be reused I guess) OR is the new tunnel build in a secure way for each website(after I reopen the browser).
The mail service(http://hq.postman.i2p) (generously) offers up to 3 (or 5) accounts (limit was there before,maybe they removed that now). How could they try and enforce the limit (they would need some kind of fingerprinting)? Or is it impossible? Using a normal browser even without JS can still be use by other party for maybe good enough fingerprinting I believe.
Torrenting and trackers
Because person/client has usually unique torrents seeding(and sometimes unique %) after receiving announces tracker can identify it almost always. I guess this information can not be used for anything as far as the torrenting identity is separated from all the others.
Question: Tunnels and "fingerprinting"
-
- Posts: 6
- Joined: 19 Oct 2024 10:18
Re: Question: Tunnels and "fingerprinting"
A brief response to the first paragraph. As a participant, you will receive an identifier, an ID. This ID is unique and is valid for the entire duration of the I2P session. Different IDs are assigned for different applications. For example, visiting websites runs separately from BitTorrent. So let’s concentrate here on visiting websites.
Digression: To put it simply, the number of tunnels is not responsible for anonymity. It is the hops, i.e. the jumps across other participants to the destination and back. This is what is meant by the tunnel length. Only the hops whose number you can influence are counted.
This is not important in the case of tracking. No matter how many hops the tunnels have, it is ultimately the ID that identifies the participant as the sender. This also eliminates the »private window in the web browser« argument.
In summary, every operator of one or more websites recognizes returning visitors by their ID.
Digression: To put it simply, the number of tunnels is not responsible for anonymity. It is the hops, i.e. the jumps across other participants to the destination and back. This is what is meant by the tunnel length. Only the hops whose number you can influence are counted.
This is not important in the case of tracking. No matter how many hops the tunnels have, it is ultimately the ID that identifies the participant as the sender. This also eliminates the »private window in the web browser« argument.
In summary, every operator of one or more websites recognizes returning visitors by their ID.
Luther H. Gillis · Private Investigator · Discreet & Confidential
Re: Question: Tunnels and "fingerprinting"
I'll expand:
The IDs that lgillis refers to are actually called "Destinations".
The Destination of the HTTP proxy (the ID assigned to browsing i2p sites) can be changed in Java I2P by either:
a) restarting the router; or
b) enabling some options in the i2p webconsole (something like "close on idle" and "new keys on reopen") - this will change Destination after some inactivity; or
c) creating multiple HTTP proxies (i'm not sure whether it's possible in java i2p, but it surely is possible in i2pd - just add a new config entry with type something like "httpproxy")
The destination identifies a single network resource (it's assigned to both clients and servers). It has two display forms: the long one (a string of ~400-500 Base64 characters) and the short one (SHA hash in base32 + ".b32.i2p"). Destinations can be thought of like IP addresses but inside I2P, and based on cryptographic keys, and you can create them as much as you want.
Multiple tunnels do not improve anonymity, they are needed to improve performance (one data stream goes over one tunnel, so multiple data streams can go over many tunnels). Excessive tunnel quantity is not recommended except in extreme cases.
The IDs that lgillis refers to are actually called "Destinations".
The Destination of the HTTP proxy (the ID assigned to browsing i2p sites) can be changed in Java I2P by either:
a) restarting the router; or
b) enabling some options in the i2p webconsole (something like "close on idle" and "new keys on reopen") - this will change Destination after some inactivity; or
c) creating multiple HTTP proxies (i'm not sure whether it's possible in java i2p, but it surely is possible in i2pd - just add a new config entry with type something like "httpproxy")
The destination identifies a single network resource (it's assigned to both clients and servers). It has two display forms: the long one (a string of ~400-500 Base64 characters) and the short one (SHA hash in base32 + ".b32.i2p"). Destinations can be thought of like IP addresses but inside I2P, and based on cryptographic keys, and you can create them as much as you want.
Multiple tunnels do not improve anonymity, they are needed to improve performance (one data stream goes over one tunnel, so multiple data streams can go over many tunnels). Excessive tunnel quantity is not recommended except in extreme cases.
-
- Posts: 6
- Joined: 19 Oct 2024 10:18
Re: Question: Tunnels and "fingerprinting"
Thank you anikey and lgillis for this fast and helpful responses.
lgillis->
"In summary, every operator of one or more websites recognizes returning visitors by their ID."
Hidden Services Manager->
By default, most of your client services (email, HTTP proxy, IRC) will share the same set of tunnels and be listed as "Shared Clients".
So assuming I only used my shared clients(set up by default), if we had a set/group of people/websites sharing data, even after I change my destination(by default it's restarting), just by seeing me login on one of their services(email, HTTP proxy, IRC) all off them can once more track me and build a profile. This would also of course allow them to connect my different identity's on the same site or different ones.
Am I understanding this correctly?
Coming from TOR Browser it would seem I made some (very) bad assumptions.
lgillis->
"In summary, every operator of one or more websites recognizes returning visitors by their ID."
Hidden Services Manager->
By default, most of your client services (email, HTTP proxy, IRC) will share the same set of tunnels and be listed as "Shared Clients".
So assuming I only used my shared clients(set up by default), if we had a set/group of people/websites sharing data, even after I change my destination(by default it's restarting), just by seeing me login on one of their services(email, HTTP proxy, IRC) all off them can once more track me and build a profile. This would also of course allow them to connect my different identity's on the same site or different ones.
Am I understanding this correctly?
Coming from TOR Browser it would seem I made some (very) bad assumptions.
Re: Question: Tunnels and "fingerprinting"
A restart does not necessarily generate a new identifier in the form of an I2P address (ID/Destination). With I2Pd, the addresses for IRC, SMTP and POP3 are retained after the restart. The addresses for the HTTP and SOCKS proxy are newly created.
(To check this, I have taken screenshots over several restarts. If you use Java-I2P, you can also do it this way, it saves you the trouble of writing.)
So your assumption goes in the right direction. As long as the I2P addresses do not change, you will remain the same for the others. An I2P address is nothing other than the TCP/IP address for the Internet. I2P does not hide the fact that you are here, but who you are. Keeping certain addresses can have advantages and disadvantages, depending on what you expect or want. Service providers must also have rights and be able to defend themselves.
If the I2P addresses are renewed by restarting or manually resetting them, the participant is immediately a tabula rasa. It is then up to the participants to decide whether they want to make it easy or difficult for their supposed opponents to recognize them. Because often enough, their own personality shines through in conversations, recurring favorite phrases are used or, in the simplest case, no spell check is carried out and the same spelling mistake crops up again and again.
Shared tunnels, on the other hand, are something else. Just as two trains can travel through the same railroad tunnel, two addresses can also be sent through one tunnel.
(To check this, I have taken screenshots over several restarts. If you use Java-I2P, you can also do it this way, it saves you the trouble of writing.)
So your assumption goes in the right direction. As long as the I2P addresses do not change, you will remain the same for the others. An I2P address is nothing other than the TCP/IP address for the Internet. I2P does not hide the fact that you are here, but who you are. Keeping certain addresses can have advantages and disadvantages, depending on what you expect or want. Service providers must also have rights and be able to defend themselves.
If the I2P addresses are renewed by restarting or manually resetting them, the participant is immediately a tabula rasa. It is then up to the participants to decide whether they want to make it easy or difficult for their supposed opponents to recognize them. Because often enough, their own personality shines through in conversations, recurring favorite phrases are used or, in the simplest case, no spell check is carried out and the same spelling mistake crops up again and again.
Shared tunnels, on the other hand, are something else. Just as two trains can travel through the same railroad tunnel, two addresses can also be sent through one tunnel.
Luther H. Gillis · Private Investigator · Discreet & Confidential
Re: Question: Tunnels and "fingerprinting"
In general, "clients" have transient destinations - they are not persisted across restarts. You may also configure them in the hidden services manager to close-on-idle and generate different destinations on resume.
"servers" must have known destinations so you can find them even when they restart. Those destinations are stored in your address book.
"servers" must have known destinations so you can find them even when they restart. Those destinations are stored in your address book.
-
- Posts: 6
- Joined: 19 Oct 2024 10:18
Re: Question: Tunnels and "fingerprinting"
@lgillis-"you can also do it this way, it saves you the trouble of writing"
1. I'm saving a lot of time by writing because with the info you have given me reading the docs and understanding the router console is much easier.
2. @anikey, yes Java version does offer a nice wizard for creating new tunnels(HTTP proxies...) in i2ptunnel
3. I did not know you cloud check your destination address. While I can check(in the i2ptunnelmgr) my pop and smtp destination(they are same), I don't see HTTP/HTTPS destination. How could I try and do that?
Note: I don't have Persistent private key so when I restart router or configclients->Application tunnels the destination of pop/smtp changes even without using New Keys on Reopen option.
@lgillis-"Service providers must also have rights and be able to defend themselves."
Well sure, if I tried being abusive with my previous knowledge they would of got me, but I don't think that's a good defense.
Service providers have ways to protect them self and only thing we should be worried about is how the extra tunnels will affect the I2P network.
/performance/future->
expensive tunnel creation messages
@lgillis-"Because often enough, their own personality shines through..."
Definitely!
@lgillis-"Just as two trains can travel through the same railroad tunnel..."
Thank you for mentioning it. My only mistake initially is that I assumed HTTP proxy works like a TOR Browser.
I did found it ...
I2CP Specification->Multisession Notes->
Subsessions share the same inbound and outbound tunnel pools as the primary session. (...) Subsessions must use different signing keys in the destination, so the destination hash is different from the primary session. As subsessions use the same encryption keys and tunnels as the primary session, it is apparent to all that the Destinations are running on the same router, so the usual anti-correlation anonymity guarantees do not apply.
This (in my opinion) is only here to improve the performance/efficiency of the network. Different destinations help in avoiding correlation but would that be enough for most threat models? I'm asking if the correlation is more or less trivial.
The following is something of interest(before I started this post).
https://i2pforum.net/viewtopic.php?t=272
Shared Clients, Correlation, and Collusion->
@zzz-"Every client that has the 'shared clients' option checked uses the same destination, which is static until restart."
I'm guessing that has been changed when Subsessions(I2CP Specification) where introduced.(?)
Is at the moment impossible to have more then one shared client pool?
To connect to a different httpproxy at the same time I'm planing to have more then one firefox profile with corresponding proxy settings. I'm interested if someone could recommend a better way of doing it?
1. I'm saving a lot of time by writing because with the info you have given me reading the docs and understanding the router console is much easier.
2. @anikey, yes Java version does offer a nice wizard for creating new tunnels(HTTP proxies...) in i2ptunnel
3. I did not know you cloud check your destination address. While I can check(in the i2ptunnelmgr) my pop and smtp destination(they are same), I don't see HTTP/HTTPS destination. How could I try and do that?
Note: I don't have Persistent private key so when I restart router or configclients->Application tunnels the destination of pop/smtp changes even without using New Keys on Reopen option.
@lgillis-"Service providers must also have rights and be able to defend themselves."
Well sure, if I tried being abusive with my previous knowledge they would of got me, but I don't think that's a good defense.
Service providers have ways to protect them self and only thing we should be worried about is how the extra tunnels will affect the I2P network.
/performance/future->
expensive tunnel creation messages
@lgillis-"Because often enough, their own personality shines through..."
Definitely!
@lgillis-"Just as two trains can travel through the same railroad tunnel..."
Thank you for mentioning it. My only mistake initially is that I assumed HTTP proxy works like a TOR Browser.
I did found it ...
I2CP Specification->Multisession Notes->
Subsessions share the same inbound and outbound tunnel pools as the primary session. (...) Subsessions must use different signing keys in the destination, so the destination hash is different from the primary session. As subsessions use the same encryption keys and tunnels as the primary session, it is apparent to all that the Destinations are running on the same router, so the usual anti-correlation anonymity guarantees do not apply.
This (in my opinion) is only here to improve the performance/efficiency of the network. Different destinations help in avoiding correlation but would that be enough for most threat models? I'm asking if the correlation is more or less trivial.
The following is something of interest(before I started this post).
https://i2pforum.net/viewtopic.php?t=272
Shared Clients, Correlation, and Collusion->
@zzz-"Every client that has the 'shared clients' option checked uses the same destination, which is static until restart."
I'm guessing that has been changed when Subsessions(I2CP Specification) where introduced.(?)
Is at the moment impossible to have more then one shared client pool?
To connect to a different httpproxy at the same time I'm planing to have more then one firefox profile with corresponding proxy settings. I'm interested if someone could recommend a better way of doing it?
Re: Question: Tunnels and "fingerprinting"
you can do that to keep your idents separate. make some other http tunnels, do like zzz said and that way whenever you use the http tunnel after the amount of time you tell it to close you'll get a new dest. librewolf could be worth checking out
as far as i know java cannot do more than one pool of shared tunnels, i2pd i'm pretty sure you can by giving the ones you want in one pool the same key.
as far as i know java cannot do more than one pool of shared tunnels, i2pd i'm pretty sure you can by giving the ones you want in one pool the same key.