#i2p-dev (irc2p) | dev build 2.5.0-4 | please test!

anonymousmaybe web.archive.org/web/20210414030400/trac.I2P2.de/ticket/726

anonymousmaybe how can i find this ticket in current gitlab ?

eyedeekay anonymousmaybe it looks like it was assigned to www/i2p on Trac which probably means it was re-filed as an issue on i2p.www

eyedeekay confirmed: i2pgit.org/i2p-hackers/i2p.www/-/issues/5

eyedeekay However, this isn't really an i2p.www

eyedeekay issue

eyedeekay It's more of an i2p.firefox issue or an I2PIPB issue. I2PIPB expressly addresses it only to the limit of the webextension/container tabs API's

eyedeekay So if you think it's not adequately addressed by i2p.firefox, then we should move the issue there.

eyedeekay If we are to re-open discussion of it, I'd like us to be a little more granular about what the attack can and cannot do, and how reliable it is.

eyedeekay What it's actually doing is establishing a modicum of "intersession linkability" which is a little different from actually de-anonymizing somebody especially if they're following reasonable baselines for their browser configuration, which I've tried to automate

eyedeekay The main defense against intersession linkability caused by browser fingerprinting is to get rid of uniqueness among browser user agents, and to block or break components that intrinsically create uniqueness, which perhaps more of a social project than a code one

eyedeekay In fact, the code mostly exists.

eyedeekay Not entirely unlike I2P itself, it works better if more people use it

anonymousmaybe eyedeekay im actually working on updating whonix wiki links, this was one of the broken links which i couldnt find

anonymousmaybe thanks for pointing that

anonymousmaybe yeah i agree its more of browser issue OR multiple services listening/using one tunnel e.g IRC with Matrix

eyedeekay As a broad category I would call them "Application-Specific Identity Management Properties"

eyedeekay IMO the easiest to think about is 1-app, 1-identity, and establish all "desirable" linkability manually(i.e. if you want to be the same identity in two contexts, offload that to GPG signatures on your messages)

anonymousmaybe yeah different between tor and i2p is that tor does it automatically but i2p need to be manually configured (for apps only, web browser is not done in I2P)

anonymousmaybe although with Tor stream isolation with apps not that of an automatic it need a manually configured ports

anonymousmaybe so yeah.. i2p and tor actually same in application/distro level just when using browser different

eyedeekay Yes and no. Tor's got other ways of isolating apps too, and creative people have turned them into API's and libraries, but the thing that devs should be leaning on for that kind of functionality in their apps in I2P is SAMv3 IMO.

eyedeekay Browser is basically the hardest version of the identity-management thing for applications though

eyedeekay Because it's giving you all this different identifying characteristics that exist at all these different meaningful layers with different impacts

eyedeekay On top of that it's presenting you with a UI for managing all of this which gives you very little information about what the implications of all of this existing in the same shared application are

eyedeekay And it's a moving target. A relatively fast-moving target

eyedeekay And slowing it down? Makes you more unique.

anonymousmaybe i see so samv3 if X service using it and Y service also using it then both gonna have 2 different paths by default? or need some tweaks for that to be achieved?

eyedeekay That's how it works by default

anonymousmaybe ah great

eyedeekay You pass in the parameters of your tunnel, you get a socket and a key

eyedeekay more-or-less

anonymousmaybe cant this be used with the browser?

anonymousmaybe if yes then it solve the issue of stream isolation for each website

eyedeekay Sort of, what you have to do is give it some way to know when it needs a new identity, and the question remains "When," and you have to give it a way to make the socket "Stick" to whatever concept of identity you choose

eyedeekay So if your concept of identity is that you should have a different identity per-site, you need to make the socket stick to the site

eyedeekay If your concept of identity is a container tab, it should stick to the container tab

anonymousmaybe any new TLD or base32 it give new circuits simialr to Tor

eyedeekay Only if that kind of isolation is meaningful and not causing worse problems than it might solve

eyedeekay I've showed you github.com/eyedeekay/httptunnel/tree/master/multiproxy right? It does the thing I mentioned above

anonymousmaybe no idea in I2P, not sure how much its capable of opening new tunnel/paths in one router

anonymousmaybe multi proxy i didnt test but i tested the apt over i2p

eyedeekay There's a limit on client-tunnels, it came up in a reddit thread I'll look up shortly

eyedeekay I think a reasonable browsing session would not hit the limit without lots of other apps going

eyedeekay But I don't know for sure

anonymousmaybe i see, yeah worth to check out or put in todo list for sure

anonymousmaybe i have one more question

eyedeekay BTW the Tor-Like scenario is "Socket sticks to the site" above^

eyedeekay git.idk.i2p/i2p-hackers/i2p.i2p/-/merge_requests/61

eyedeekay Wrong tab

anonymousmaybe if lets say 1000 I2P user decided to use 0 inboud and 0 outbound will that effect an I2P user going to connect x outbound then server and x inbound then back to user

anonymousmaybe so instead of the diagram we always see about i2p which is 3 hops out and 3 in its going to be just user -> x -> eepsite outbound and user <- x (same node) or y <- eepsite (inbound)

eyedeekay Other user's decisions wouldn't affect the length of the tunnels which the user tells their router to construct, if that's what you mean, whether individual users want to make direct connections is up to them

anonymousmaybe i see, so to be clear if I2P user want to connect to xyz eepsite it doesnt matter what the I2P routers inbetween their router configuration is right?

anonymousmaybe it doesnt matter what the I2P routers configured inbetween the path to the eepsite*

eyedeekay No, your client tunnels belong to you, their client tunnels belong to them, they don't directly affect eachother

anonymousmaybe i see so they dont contradict when eepsite saying i want 3 out and 3 in and all the clients available saying i want only 0 in and 0 out

anonymousmaybe thats cool then

anonymousmaybe eyedeekay thank you <3

eyedeekay when the client says that all it means is that their "half" of the tunnel is shorter, the other client still decides the other half

eyedeekay no problem

eyedeekay Here's the reddit thread about active client dest limits: old.reddit.com/r/i2p/comments/v63v0k/is_it_practical_to_create_lots_of_destinations

eyedeekay it's 100

dr|z3d don't forget about Firefox's electrolysis stuff, I think that's live now in release builds (site isolation).

dr|z3d or maybe fission's what I meant, either way, should be live now.

dr|z3d wiki.mozilla.org/Project_Fission

eyedeekay Yeah isolating sites at the proxy level is not very meaningful if the browser is leaking information across sites and tabs, it's important to have meaningful isolation through the whole process

dr|z3d I still think auto-rekeying is worth pursuing to that end, but maybe we've moved on..

eyedeekay My problem with auto-rekeying is that AFAICT it only impacts retro-linkability(Any # of colluding sites, different sessions) and not contemporary-linkability(Any # of colluding sites, same session), and we already have a way to deal with retro-linkability by rekeying when idle

eyedeekay IMO rekeying when idle might be best because that is is as close as the HTTP proxy can get to identifying something that might correspond to a "browsing session" on it's own without some way to communicate with the apps are using it, and managing a map of context->identity

dr|z3d sure, rekey on idle would be a step up from shutdown tunnel on idle.

dr|z3d set the idle period before rekey and you're more or less acheiving the same end goal.

dr|z3d ie allow the user to set the idle period.

eyedeekay Which do you mean:

eyedeekay the idle period as in how long the tunnel must be idle in order to shut down and optionally re-key? <-We already have options which configure this

eyedeekay or how long the tunnel has been shut down before hypothetically re-keying and starting itself again? <-This is the easiest version of "re-key on idle" implementation, which is basically shutdown, then immediately wake up after you finish generating keys

dr|z3d the former, which is already in the UI, with a slight mod to the UI to accomodate rekeying instead of shutdown on idle. that seems to me to be the most logical method.

eyedeekay I think the only way to do it is actually to shut the tunnel down, then re-key, then restart IIRC

eyedeekay but since the tunnel is idle I don't think the user would notice the tunnel being rebuilt affecting performance, which they might if it was shut down when they started trying to use it

dr|z3d sure, that's about the size of it. rekey on idle instead of shutdown on idle and wait for further activity means less potential lag for user.

eyedeekay Fair enough

dr|z3d could be two separate time fields.. one for rekey (idle tunnel time), and a second for shutdown.

dr|z3d so for example rekey on idle (5 minute), shutdown on idle (30m) or whatever.

dr|z3d not essential, an either or shutdown/rekey would be fine enough.

eyedeekay I think that probably makes the most sense, and user-observed performance is the best reason for re-key on idle

eyedeekay *immediate re-key on idle

dr|z3d sure, makes sense to me too.