&eche|on
&zzz
+R4SAS
+RN
+RN_
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+eche|off
+not_bob_afk
+orignal
+postman
+snex
+wodencafe
Arch
BubbRubb
Chrono
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest16752
Irc2PGuest33667
Irc2PGuest51880
Onn4l7h
Over
Sisyphus
Sleepy_
Teeed
aargh2
ac9f_
b3t4f4c3__
b4dab00m
bak83_
duanin2
duck
john231
leopold
makoto
mareki2p_
nilbog-
poriori_
profetik1
r00tobo
rapidash
shiver_
solidx66
thetia
u5657
uop23ip
vivid_reader56
x74a6
xHarr
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
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
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.
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.